Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

[Sandy Ginoza]

Hi all,

Thanks for your replies, and apologies for my confusion! 

Note that a new errata report has been submitted [1] and the erroneous report 
(EID 7645) has been deleted. 

Thank you,
RFC Editor/sg

[1] https://www.rfc-editor.org/errata/eid7649

> On Sep 19, 2023, at 7:41 AM, Joe Clarke (jclarke)  wrote:
> 
> The erratum was supposed to be for RFC 5340, which came from the OSPF WG.  
> This is why I suggested it might be easier to simply reject the erratum as 
> reported and have the submitter open a new one on the correct RFC so 
> everything is directed to the right places and people.
>  
> Joe
>  
> From: Sandy Ginoza 
> Date: Tuesday, September 19, 2023 at 10:03
> To: Jürgen Schönwälder 
> Cc: Chris Smiley , j.schoenwael...@jacobs-university.de 
> , Warren Kumari , 
> Rob Wilton (rwilton) , Henk Birkholz 
> , Joe Clarke (jclarke) , 
> zhoutian...@huawei.com , o...@delong.com 
> , opsawg@ietf.org , RFC Editor 
> 
> Subject: Re: [Technical Errata Reported] RFC5343 (7645)
> 
> Hi Jürgen,
>  
> From the datatracker: 
>  
> Was draft-ietf-opsawg-snmp-engineid-discovery (opsawg WG)
>  
> This document is the product of the Operations and Management Area Working
> Group. 
>  
>  
> Is OPSAWG incorrect, or are you suggesting that the right place to discuss 
> this RFC now is OSPF?
>  
> Thanks,
> RFC Editor/sg
> 
> 
> 
> On Sep 18, 2023, at 11:30 PM, Jürgen Schönwälder 
>  wrote:
> 
> You have to make sure that the right people and WG receive the
> erratum, RFC 5340 belongs to the OSPF WG.
> 
> /js
> 
> On Mon, Sep 18, 2023 at 04:32:02PM -0700, Chris Smiley wrote:
> 
> 
> Greetings,
> 
> This errata reports a problem with Section A.3.3/RFC 5343.  It has been 
> corrected to Section A.3.3/RFC 5340
> 
> Please let us know any concerns. 
> 
> Thank you.
> 
> RFC Editor/cs
> 
> 
> 
> On Sep 17, 2023, at 10:49 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC5343,
> "Simple Network Management Protocol (SNMP) Context EngineID Discovery".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7645
> 
> --
> Type: Technical
> Reported by: Owen DeLong 
> 
> Section: A.3.3
> 
> Original Text
> -
> Section A.3.3 (in part) reads:
> 
> Interface MTU
> The size in bytes of the largest IPv6 datagram that can be sent
> out the associated interface without fragmentation.  The MTUs of
> common Internet link types can be found in Table 7-1 of [MTUDISC].
> Interface MTU should be set to 0 in Database Description packets
> sent over virtual links.
> 
> 
> Corrected Text
> --
> Interface MTU
> The size in bytes of the largest IPv6 datagram that can be sent
> out the associated interface without fragmentation.  The MTUs of
> common Internet link types can be found in Table 7-1 of [MTUDISC].
> Interface MTU should be set to 0 in Database Description packets
> sent over OSPF virtual links. This rule should not be applied to tunnel
> or other software interfaces.
> 
> 
> Notes
> -
> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
> and this provision makes sense. For interfaces that have an actual MTU, even 
> though they may be "virtual" interfaces, they are not "virtual links" in the 
> intended meaning of this paragraph. As such, this change will provide 
> clarification and remove ambiguity from the current standard. At least one 
> popular router vendor implements this RFC as MTU = 0 sent on all GRE 
> interfaces which results in incompatibilities with most other router 
> platforms which expect an actual value. The router vendor points to this 
> provision in the RFCs as justification for their implementation. It is 
> (arguably) a legitimate, if nonsensical interpretation of the existing text.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
> --
> Title   : Simple Network Management Protocol (SNMP) Context 
> EngineID Discovery
> Publication Date: September 2008
> Author(s)   : J. Schoenwaelder
> Category: PROPOSED STANDARD
> Source  : Operations and Management Area Working Group
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 
>  
> 
> -- 
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-02.txt

[Randy Bush]

> I will work on items 1-4 for the next version.

thanks.  and thanks job for the careful eyeballs

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] R: [EXT] Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model

[Peruzzini Fabio]

Hi all,

I fully agree with Italo's proposal and all the comments written by Jeff.

I would add that having structured the work into modules will allow us to work 
in parallel reducing the time to complete the task.

Br

Fabio





Gruppo TIM - Uso Interno - Tutti i diritti riservati.
Da: Inventory-yang  Per conto di JEAN-FRANCOIS 
BOUQUIER, Vodafone
Inviato: martedì 19 settembre 2023 16:20
A: Daniele Ceccarelli ; maqiufang (A) 

Cc: inventory-y...@ietf.org; ivy-cha...@ietf.org; opsawg ; 
cc...@ietf.org
Oggetto: [EXT] Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network 
inventory base model

Dear Daniele/Qiufang and all,

From operator side, we definitely have use cases for an IETF data model 
covering HW network inventory only for the MPI interface (e.g. between P-PNC 
and O-PNC and MDSC).

As mentioned already several times, this has been identified as a gap for a 
long time now in 
draft-ietf-teas-actn-poi-applicability-09
 (section 4) in multi-layer scenarios and this is what triggered the work on 
the HW network inventory draft with the original goal to be a technology 
agnostic HW network inventory data model that could be then augmented to 
include any additional technology specific information required.

The HW network inventory data model looks quite mature now and this would bring 
an important benefit from operators’ point of view in terms of interoperability 
(for MDSC & P-PNC and/or MDSC & O-PNC) instead of using proprietary APIs from 
the different Suppliers’ implementations as per today.

So I share completely the modular approach view which could allow to address 
all different use cases along with the time constraints we have: HW only 
(taking as reference the draft-ietf-ccamp-network-inventory-yang and fixing the 
different comments on equipment-room etc .so that everybody is fine ). In that 
way we could have a data model for HW only use cases in a relatively short time 
to be implemented in NBI of P-PNCs and O-PNCs. But also HW+SW (reusing most of 
the work done so far draft-wzwb-opsawg-network-inventory-management for SW) 
would be develop further for the HW+SW use cases.

Hope it helps.

Kind regards,

Jeff




C2 General
De: Inventory-yang 
mailto:inventory-yang-boun...@ietf.org>> En 
nombre de Daniele Ceccarelli
Enviado el: viernes, 15 de septiembre de 2023 10:45
Para: maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>
CC: inventory-y...@ietf.org; 
ivy-cha...@ietf.org; opsawg 
mailto:opsawg@ietf.org>>; cc...@ietf.org
Asunto: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network 
inventory base model

This is an external email. Do you know who has sent it? Can you be sure that 
any links and attachments contained within it are safe? If in any doubt, use 
the Report Message button in your Outlook client to report this mail.
Hi working group,

Thanks a lot for all the useful comments on the different drafts.
There seems to be a split of preferences between option 1 and option 3. Given 
that the interinm meeting is soon (next week), we suggest to use it to further 
discuss suggestions and concerns from the working group and defer the decision 
by 1 week (Sep 22nd) immediately after the interim meeting.

In order to have a fruitful discussion at the interim meeting please consider 
the following inputs:


  *   Italo made a very good proposal on the split between HW only and HW+SW 
use cases. Is this something we want to pursue? Do you think it makes sense to 
start focusing on e.g. HW and then add SW on top of it?
  *   When asking to adopt one draft or the other we were asking (as per IETF 
process) which you consider to be a good starting point for the working group 
to work on, not something that is ready for publication. This means that 
whatever draft we decide to adopt, we can significantly update it to properly 
cover all the different aspects of invently. With this regard Alex did a very 
good analysis in his mail. Maybe we don't need to make an hard choice between 
the draft but take the best of each. For example: we can take 30% of one draft 
and 20% of the other and build a new one as per option 3, if on the other side 
we decide to take 80% from one draft, then it makes more sense to start from it 
and build on top of that.
  *   Another good point touched by Alex is the "equipment-room". We are 
supposed to cover also sites and location of the inventory. Are these things 
connected? it seems so. If the WG prefers not to address this in the core model 
and add it on top, that fine, otherwise we would suggest to have sites and 
location added (whetehr in che core model or added on top can be discussed).
Again we have a good proposal from Alex on the way forward, which is:


"For example, one could start with draft-ietf-ccamp-network-inventory-yang, 
modifying it to remove the 

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-02.txt

[Russ Housley]

I will work on items 1-4 for the next version.

Russ

> On Sep 19, 2023, at 1:11 AM, Job Snijders  
> wrote:
> 
> Dear authors,
> 
> There still are a few nits with the examples in this document.
> 
> 1/ The sbgp-autonomousSysNum extension in the Trust Anchor MUST be
>   marked critical (RFC 6487 section 4.8.11), it currently is not.
> 
> 2/ The sbgp-autonomousSysNum extension in the CA cert MUST be
>   marked critical (RFC 6487 section 4.8.11), it currently is not.
> 
> 3/ On the EE certificate, the basicConstraints extension MUST be absent
>   if the CA bit is set to false. Only CA certificates are expected to
>   carry a basicConstraints extension. (RFC 6487 section 4.8.1)
> 
> 4/ the lack of CRLs in the example makes it much harder to truly verify
>   the provided geofeed files, please consider including the 2 missing
>   CRLs so a complete example is presented.
> 
> 5/ Section 3 still lists RSC as 'complex', and RPKI-RTA as 'applicable
>   in the long run'; but draft-ietf-sidrops-rpki-rta-00 has long since
>   expired, and also marked 'replaced by RFC9232'. Can the authors
>   explain what kind of applicability of RTA they envision in the long
>   run? It's also not clear to me how the RTA 'applicability' relates to
>   using a self-signed trust anchor?
> 
> Kind regards,
> 
> Job
> 
> On Mon, Sep 18, 2023 at 06:40:36PM -0700, internet-dra...@ietf.org wrote:
>> Internet-Draft draft-ietf-opsawg-9092-update-02.txt is now available. It is a
>> work item of the Operations and Management Area Working Group (OPSAWG) WG of
>> the IETF.
>> 
>>   Title:   Finding and Using Geofeed Data
>>   Authors: Randy Bush
>>Massimo Candela
>>Warren Kumari
>>Russ Housley
>>   Name:draft-ietf-opsawg-9092-update-02.txt
>>   Pages:   26
>>   Dates:   2023-09-18
>> 
>> Abstract:
>> 
>>   This document specifies how to augment the Routing Policy
>>   Specification Language inetnum: class to refer specifically to
>>   geofeed data files and describes an optional scheme that uses the
>>   Resource Public Key Infrastructure to authenticate the geofeed
>>   datafiles.
>> 
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/
>> 
>> There is also an HTMLized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-9092-update-02
>> 
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-9092-update-02
>> 
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>> 
>> 
>> ___
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] OPSAWG: Examples for IDevID "identifier" field formats (X520SerialNumber or the like)

[Alexander Clemm]

Adding IVY (network inventory).
For the network inventory and hardware YANG models, UUID is used (per RFC 6991 
and RFC 4122), which does not prescribe a structure but does not preclude it 
either.  (See e.g. RFC 8348 or 
https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-network-inventory-yang-02)
--- Alex

-Original Message-
From: OPSAWG  On Behalf Of Toerless Eckert
Sent: Tuesday, September 19, 2023 9:09 AM
To: opsawg@ietf.org
Subject: [OPSAWG] OPSAWG: Examples for IDevID "identifier" field formats 
(X520SerialNumber or the like)

Dear OPSAWG,

I am looking for concrete examples of device certificates, specifically the 
format of any "identifier" field that is uniquely identifying the device, such 
as the X520SerialNumber field.

I was hoping this WG would actually have folks who can look at real equipment 
for example ;-))

I have found no good examples in RFCs. I hope / suspect that some vendors would 
use a more structured format, such as X520SerialNumber = "PID:ANI-SDEV-7X9 
SN:FBC1234X97A", e.g.:
contatenation of device type and actual serial number.

If you are aware of any specific standards or other recommendations as to the 
format of such a field, i welcome points (e.g.: OPC UA has one for their own 
ProductInstanceUri, but its not clear to me if this is being adopted in 
reality).

Thank you so much
Toerless

P.S.: reason for asking: In ANIMA/BRSKI, we have the case where we need to use 
network discovery to find devices based on such information, and we're 
pondering if/how well enough the information is cross-product-family and 
cross-vendor unique enough, and/or how much we need to think of further 
qualification.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] OPSAWG: Examples for IDevID "identifier" field formats (X520SerialNumber or the like)

[Toerless Eckert]

Dear OPSAWG,

I am looking for concrete examples of device certificates, specifically the 
format of any
"identifier" field that is uniquely identifying the device, such as the 
X520SerialNumber field.

I was hoping this WG would actually have folks who can look at real equipment 
for example ;-))

I have found no good examples in RFCs. I hope / suspect that some vendors would 
use a more
structured format, such as X520SerialNumber = "PID:ANI-SDEV-7X9 
SN:FBC1234X97A", e.g.:
contatenation of device type and actual serial number.

If you are aware of any specific standards or other recommendations as to the 
format of
such a field, i welcome points (e.g.: OPC UA has one for their own 
ProductInstanceUri, but
its not clear to me if this is being adopted in reality).

Thank you so much
Toerless

P.S.: reason for asking: In ANIMA/BRSKI, we have the case where we need to use 
network discovery
to find devices based on such information, and we're pondering if/how well 
enough the information
is cross-product-family and cross-vendor unique enough, and/or how much we need 
to think of
further qualification.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model

[daniele.ietf]

Thanks a lot Jeff,

 

Comments like this one are extremely helpful.

 

Thanks,
Daniele  

 

From: JEAN-FRANCOIS BOUQUIER, Vodafone  
Sent: Tuesday, September 19, 2023 4:20 PM
To: Daniele Ceccarelli ; maqiufang (A) 

Cc: inventory-y...@ietf.org; ivy-cha...@ietf.org; opsawg ; 
cc...@ietf.org
Subject: RE: [Inventory-yang] [CCAMP] [inventory-yang] poll for network 
inventory base model

 

Dear Daniele/Qiufang and all,

 

>From operator side, we definitely have use cases for an IETF data model 
>covering HW network inventory only for the MPI interface (e.g. between P-PNC 
>and O-PNC and MDSC). 

 

As mentioned already several times, this has been identified as a gap for a 
long time now in  

 draft-ietf-teas-actn-poi-applicability-09 (section 4) in multi-layer scenarios 
and this is what triggered the work on the HW network inventory draft with the 
original goal to be a technology agnostic HW network inventory data model that 
could be then augmented to include any additional technology specific 
information required. 

 

The HW network inventory data model looks quite mature now and this would bring 
an important benefit from operators’ point of view in terms of interoperability 
(for MDSC & P-PNC and/or MDSC & O-PNC) instead of using proprietary APIs from 
the different Suppliers’ implementations as per today. 

 

So I share completely the modular approach view which could allow to address 
all different use cases along with the time constraints we have: HW only 
(taking as reference the draft-ietf-ccamp-network-inventory-yang and fixing the 
different comments on equipment-room etc .so that everybody is fine ). In that 
way we could have a data model for HW only use cases in a relatively short time 
to be implemented in NBI of P-PNCs and O-PNCs. But also HW+SW (reusing most of 
the work done so far draft-wzwb-opsawg-network-inventory-management for SW) 
would be develop further for the HW+SW use cases. 

 

Hope it helps.

 

Kind regards,

 

Jeff

 

 

 

C2 General

De: Inventory-yang mailto:inventory-yang-boun...@ietf.org> > En nombre de Daniele Ceccarelli
Enviado el: viernes, 15 de septiembre de 2023 10:45
Para: maqiufang (A) mailto:maqiufang1=40huawei@dmarc.ietf.org> >
CC: inventory-y...@ietf.org  ; 
ivy-cha...@ietf.org  ; opsawg mailto:opsawg@ietf.org> >; cc...@ietf.org  
Asunto: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network 
inventory base model

 

This is an external email. Do you know who has sent it? Can you be sure that 
any links and attachments contained within it are safe? If in any doubt, use 
the Report Message button in your Outlook client to report this mail. 

Hi working group, 

 

Thanks a lot for all the useful comments on the different drafts.

There seems to be a split of preferences between option 1 and option 3. Given 
that the interinm meeting is soon (next week), we suggest to use it to further 
discuss suggestions and concerns from the working group and defer the decision 
by 1 week (Sep 22nd) immediately after the interim meeting.

 

In order to have a fruitful discussion at the interim meeting please consider 
the following inputs:

 

*   Italo made a very good proposal on the split between HW only and HW+SW 
use cases. Is this something we want to pursue? Do you think it makes sense to 
start focusing on e.g. HW and then add SW on top of it?
*   When asking to adopt one draft or the other we were asking (as per IETF 
process) which you consider to be a good starting point for the working group 
to work on, not something that is ready for publication. This means that 
whatever draft we decide to adopt, we can significantly update it to properly 
cover all the different aspects of invently. With this regard Alex did a very 
good analysis in his mail. Maybe we don't need to make an hard choice between 
the draft but take the best of each. For example: we can take 30% of one draft 
and 20% of the other and build a new one as per option 3, if on the other side 
we decide to take 80% from one draft, then it makes more sense to start from it 
and build on top of that.
*   Another good point touched by Alex is the "equipment-room". We are 
supposed to cover also sites and location of the inventory. Are these things 
connected? it seems so. If the WG prefers not to address this in the core model 
and add it on top, that fine, otherwise we would suggest to have sites and 
location added (whetehr in che core model or added on top can be discussed).

Again we have a good proposal from Alex on the way forward, which is:

 

"For example, one could start with draft-ietf-ccamp-network-inventory-yang, 
modifying it to remove the network-hardware-inventory container and splitting 
the remaining module in two (for equipment-room and network-elements, both of 
which will now be 

Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

[Joe Clarke (jclarke)]

The erratum was supposed to be for RFC 5340, which came from the OSPF WG.  This 
is why I suggested it might be easier to simply reject the erratum as reported 
and have the submitter open a new one on the correct RFC so everything is 
directed to the right places and people.

Joe

From: Sandy Ginoza 
Date: Tuesday, September 19, 2023 at 10:03
To: Jürgen Schönwälder 
Cc: Chris Smiley , j.schoenwael...@jacobs-university.de 
, Warren Kumari , Rob 
Wilton (rwilton) , Henk Birkholz 
, Joe Clarke (jclarke) , 
zhoutian...@huawei.com , o...@delong.com 
, opsawg@ietf.org , RFC Editor 

Subject: Re: [Technical Errata Reported] RFC5343 (7645)
Hi Jürgen,

>From the datatracker:

Was draft-ietf-opsawg-snmp-engineid-discovery (opsawg WG)

This document is the product of the Operations and Management Area Working
Group.


Is OPSAWG incorrect, or are you suggesting that the right place to discuss this 
RFC now is OSPF?

Thanks,
RFC Editor/sg



On Sep 18, 2023, at 11:30 PM, Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>
 wrote:

You have to make sure that the right people and WG receive the
erratum, RFC 5340 belongs to the OSPF WG.

/js

On Mon, Sep 18, 2023 at 04:32:02PM -0700, Chris Smiley wrote:


Greetings,

This errata reports a problem with Section A.3.3/RFC 5343.  It has been 
corrected to Section A.3.3/RFC 5340

Please let us know any concerns.

Thank you.

RFC Editor/cs



On Sep 17, 2023, at 10:49 PM, RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>> wrote:

The following errata report has been submitted for RFC5343,
"Simple Network Management Protocol (SNMP) Context EngineID Discovery".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7645

--
Type: Technical
Reported by: Owen DeLong 

Section: A.3.3

Original Text
-
Section A.3.3 (in part) reads:

Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation.  The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over virtual links.


Corrected Text
--
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation.  The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over OSPF virtual links. This rule should not be applied to tunnel
or other software interfaces.


Notes
-
OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and 
this provision makes sense. For interfaces that have an actual MTU, even though 
they may be "virtual" interfaces, they are not "virtual links" in the intended 
meaning of this paragraph. As such, this change will provide clarification and 
remove ambiguity from the current standard. At least one popular router vendor 
implements this RFC as MTU = 0 sent on all GRE interfaces which results in 
incompatibilities with most other router platforms which expect an actual 
value. The router vendor points to this provision in the RFCs as justification 
for their implementation. It is (arguably) a legitimate, if nonsensical 
interpretation of the existing text.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
--
Title   : Simple Network Management Protocol (SNMP) Context 
EngineID Discovery
Publication Date: September 2008
Author(s)   : J. Schoenwaelder
Category: PROPOSED STANDARD
Source  : Operations and Management Area Working Group
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG


--
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model

[JEAN-FRANCOIS BOUQUIER, Vodafone]

Dear Daniele/Qiufang and all,

From operator side, we definitely have use cases for an IETF data model 
covering HW network inventory only for the MPI interface (e.g. between P-PNC 
and O-PNC and MDSC).

As mentioned already several times, this has been identified as a gap for a 
long time now in 
draft-ietf-teas-actn-poi-applicability-09
 (section 4) in multi-layer scenarios and this is what triggered the work on 
the HW network inventory draft with the original goal to be a technology 
agnostic HW network inventory data model that could be then augmented to 
include any additional technology specific information required.

The HW network inventory data model looks quite mature now and this would bring 
an important benefit from operators’ point of view in terms of interoperability 
(for MDSC & P-PNC and/or MDSC & O-PNC) instead of using proprietary APIs from 
the different Suppliers’ implementations as per today.

So I share completely the modular approach view which could allow to address 
all different use cases along with the time constraints we have: HW only 
(taking as reference the draft-ietf-ccamp-network-inventory-yang and fixing the 
different comments on equipment-room etc .so that everybody is fine ). In that 
way we could have a data model for HW only use cases in a relatively short time 
to be implemented in NBI of P-PNCs and O-PNCs. But also HW+SW (reusing most of 
the work done so far draft-wzwb-opsawg-network-inventory-management for SW) 
would be develop further for the HW+SW use cases.

Hope it helps.

Kind regards,

Jeff




C2 General
De: Inventory-yang  En nombre de Daniele 
Ceccarelli
Enviado el: viernes, 15 de septiembre de 2023 10:45
Para: maqiufang (A) 
CC: inventory-y...@ietf.org; ivy-cha...@ietf.org; opsawg ; 
cc...@ietf.org
Asunto: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network 
inventory base model

This is an external email. Do you know who has sent it? Can you be sure that 
any links and attachments contained within it are safe? If in any doubt, use 
the Report Message button in your Outlook client to report this mail.
Hi working group,

Thanks a lot for all the useful comments on the different drafts.
There seems to be a split of preferences between option 1 and option 3. Given 
that the interinm meeting is soon (next week), we suggest to use it to further 
discuss suggestions and concerns from the working group and defer the decision 
by 1 week (Sep 22nd) immediately after the interim meeting.

In order to have a fruitful discussion at the interim meeting please consider 
the following inputs:


  *   Italo made a very good proposal on the split between HW only and HW+SW 
use cases. Is this something we want to pursue? Do you think it makes sense to 
start focusing on e.g. HW and then add SW on top of it?
  *   When asking to adopt one draft or the other we were asking (as per IETF 
process) which you consider to be a good starting point for the working group 
to work on, not something that is ready for publication. This means that 
whatever draft we decide to adopt, we can significantly update it to properly 
cover all the different aspects of invently. With this regard Alex did a very 
good analysis in his mail. Maybe we don't need to make an hard choice between 
the draft but take the best of each. For example: we can take 30% of one draft 
and 20% of the other and build a new one as per option 3, if on the other side 
we decide to take 80% from one draft, then it makes more sense to start from it 
and build on top of that.
  *   Another good point touched by Alex is the "equipment-room". We are 
supposed to cover also sites and location of the inventory. Are these things 
connected? it seems so. If the WG prefers not to address this in the core model 
and add it on top, that fine, otherwise we would suggest to have sites and 
location added (whetehr in che core model or added on top can be discussed).
Again we have a good proposal from Alex on the way forward, which is:


"For example, one could start with draft-ietf-ccamp-network-inventory-yang, 
modifying it to remove the network-hardware-inventory container and splitting 
the remaining module in two (for equipment-room and network-elements, both of 
which will now be top-level containers).  Remaining modifications can be made 
from there.  I guess this makes me a proponent of option 3, but with the caveat 
that this would not need to restart from scratch - really an option 4 that says 
merge (for overall structure and common parts, which in this case is possible) 
and split the remaining difference."
We don't really care whether this is called option 1, 3 or 4 but seems to be 
the most meaningful one...which is: use ccamp draft as a starting point, 
implementing the modifications suggested by Alex and then incorporate the 
material from the opsawg draft.

Given this deferral of the polling decision, if anyone else 

[OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-01.txt

[internet-drafts]

Internet-Draft draft-ietf-opsawg-ipfix-tcpo-v6eh-01.txt is now available. It
is a work item of the Operations and Management Area Working Group (OPSAWG) WG
of the IETF.

   Title:   Extended TCP Options and IPv6 Extension Headers IPFIX Information 
Elements
   Authors: Mohamed Boucadair
Benoit Claise
   Name:draft-ietf-opsawg-ipfix-tcpo-v6eh-01.txt
   Pages:   9
   Dates:   2023-09-19

Abstract:

   This document specifies new IP Flow Information Export (IPFIX)
   Information Elements (IEs) to solve some issues with existing
   ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability
   to export any observed IPv6 extension headers or TCP options.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-tcpo-v6eh-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

[Sandy Ginoza]

Hi Jürgen,

From the datatracker: 

Was draft-ietf-opsawg-snmp-engineid-discovery (opsawg WG)

This document is the product of the Operations and Management Area Working
Group. 


Is OPSAWG incorrect, or are you suggesting that the right place to discuss this 
RFC now is OSPF?

Thanks,
RFC Editor/sg


> On Sep 18, 2023, at 11:30 PM, Jürgen Schönwälder 
>  wrote:
> 
> You have to make sure that the right people and WG receive the
> erratum, RFC 5340 belongs to the OSPF WG.
> 
> /js
> 
> On Mon, Sep 18, 2023 at 04:32:02PM -0700, Chris Smiley wrote:
>> 
>> Greetings,
>> 
>> This errata reports a problem with Section A.3.3/RFC 5343.  It has been 
>> corrected to Section A.3.3/RFC 5340
>> 
>> Please let us know any concerns. 
>> 
>> Thank you.
>> 
>> RFC Editor/cs
>> 
>> 
>>> On Sep 17, 2023, at 10:49 PM, RFC Errata System  
>>> wrote:
>>> 
>>> The following errata report has been submitted for RFC5343,
>>> "Simple Network Management Protocol (SNMP) Context EngineID Discovery".
>>> 
>>> --
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid7645
>>> 
>>> --
>>> Type: Technical
>>> Reported by: Owen DeLong 
>>> 
>>> Section: A.3.3
>>> 
>>> Original Text
>>> -
>>> Section A.3.3 (in part) reads:
>>> 
>>> Interface MTU
>>> The size in bytes of the largest IPv6 datagram that can be sent
>>> out the associated interface without fragmentation.  The MTUs of
>>> common Internet link types can be found in Table 7-1 of [MTUDISC].
>>> Interface MTU should be set to 0 in Database Description packets
>>> sent over virtual links.
>>> 
>>> 
>>> Corrected Text
>>> --
>>> Interface MTU
>>> The size in bytes of the largest IPv6 datagram that can be sent
>>> out the associated interface without fragmentation.  The MTUs of
>>> common Internet link types can be found in Table 7-1 of [MTUDISC].
>>> Interface MTU should be set to 0 in Database Description packets
>>> sent over OSPF virtual links. This rule should not be applied to tunnel
>>> or other software interfaces.
>>> 
>>> 
>>> Notes
>>> -
>>> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
>>> and this provision makes sense. For interfaces that have an actual MTU, 
>>> even though they may be "virtual" interfaces, they are not "virtual links" 
>>> in the intended meaning of this paragraph. As such, this change will 
>>> provide clarification and remove ambiguity from the current standard. At 
>>> least one popular router vendor implements this RFC as MTU = 0 sent on all 
>>> GRE interfaces which results in incompatibilities with most other router 
>>> platforms which expect an actual value. The router vendor points to this 
>>> provision in the RFCs as justification for their implementation. It is 
>>> (arguably) a legitimate, if nonsensical interpretation of the existing text.
>>> 
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party  
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --
>>> RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
>>> --
>>> Title   : Simple Network Management Protocol (SNMP) Context 
>>> EngineID Discovery
>>> Publication Date: September 2008
>>> Author(s)   : J. Schoenwaelder
>>> Category: PROPOSED STANDARD
>>> Source  : Operations and Management Area Working Group
>>> Area: Operations and Management
>>> Stream  : IETF
>>> Verifying Party : IESG
>>> 
>> 
> 
> -- 
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

[mohamed . boucadair]

Hi Paul,

Yes, that's what I was referring to in my previous messages when I said "FWIW, 
(1) is what was followed in RFC5102 but changed since then by errata.".

I'm having trouble with that errata as I don't understand why the reversal was 
only made at the octet level and not the full IE + how to link that with 
"Option number X is mapped to bit X".

Thank you.

Cheers,
Med

De : Aitken, Paul 
Envoyé : mardi 19 septembre 2023 12:13
À : BOUCADAIR Mohamed INNOV/NET ; opsawg 
; Benoit Claise 
Objet : Re: draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

Med, this figure originally appeared in section 5.8.8 of 
draft-ietf-ipfix-info-13, -14, and RFC 5102 with the bits in this order:

  0 1 2 3 4 5 6 7

  +-+-+-+-+-+-+-+-+

  |   0 |   1 |   2 |   3 |   4 |   5 |   6 |   7 |  ...

  +-+-+-+-+-+-+-+-+

The bits were reversed by this errata: https://www.rfc-editor.org/errata/eid2946

Also see https://www.rfc-editor.org/errata/eid1739

P.

On 19/09/2023 09:49, 
mohamed.boucad...@orange.com wrote:
Hi all,

The description of these IEs says that "Options are mapped to bits according to 
their option numbers. Option number X is mapped to bit X", however the drawing 
does not reflect that (tcpOptions):

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   7 |   6 |   5 |   4 |   3 |   2 |   1 |   0 |  ...
+-+-+-+-+-+-+-+-+

8 9101112131415
+-+-+-+-+-+-+-+-+
... |  15 |  14 |  13 |  12 |  11 |  10 |   9 |   8 |...
+-+-+-+-+-+-+-+-+

   1617181920212223
+-+-+-+-+-+-+-+-+
... |  23 |  22 |  21 |  20 |  19 |  18 |  17 |  16 |...
+-+-+-+-+-+-+-+-+

  . . .

   5657585960616263
+-+-+-+-+-+-+-+-+
... |  63 |  62 |  61 |  60 |  59 |  58 |  57 |  56 |
+-+-+-+-+-+-+-+-+

I suspect that the confusion is rooted in the interpretation of "bit X": as (1) 
"bit position X" or the resulting (2) "binary value":

  1.  If (1) is followed, then bit#0 would be mapped to option 0, bit#1 to 
option 1, and so on. This logic is followed, e.g., for ipv6ExtensionHeaders.
  2.  If (2) is followed, then bit#63 would be mapped to option 0, bit#62 to 
option 1, and so on.

In both cases, the drawing is not aligned with the narrative text. We may 
either consider updating the drawing or the text.

Which change is likely to have less impact on existing implementations? FWIW, 
(1) is what was followed in RFC5102 but changed since then by errata.

Thank you.

Cheers,
Med



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: [OPSAWG] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

[Aitken, Paul]

Med, this figure originally appeared in section 5.8.8 of 
draft-ietf-ipfix-info-13, -14, and RFC 5102 with the bits in this order:


  0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |   0 |   1 |   2 |   3 |   4 |   5 |   6 |   7 |  ...
  +-+-+-+-+-+-+-+-+

The bits were reversed by this errata: https://www.rfc-editor.org/errata/eid2946

Also see https://www.rfc-editor.org/errata/eid1739

P.


On 19/09/2023 09:49, 
mohamed.boucad...@orange.com wrote:
Hi all,

The description of these IEs says that “Options are mapped to bits according to 
their option numbers. Option number X is mapped to bit X”, however the drawing 
does not reflect that (tcpOptions):

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   7 |   6 |   5 |   4 |   3 |   2 |   1 |   0 |  ...
+-+-+-+-+-+-+-+-+

8 9101112131415
+-+-+-+-+-+-+-+-+
... |  15 |  14 |  13 |  12 |  11 |  10 |   9 |   8 |...
+-+-+-+-+-+-+-+-+

   1617181920212223
+-+-+-+-+-+-+-+-+
... |  23 |  22 |  21 |  20 |  19 |  18 |  17 |  16 |...
+-+-+-+-+-+-+-+-+

  . . .

   5657585960616263
+-+-+-+-+-+-+-+-+
... |  63 |  62 |  61 |  60 |  59 |  58 |  57 |  56 |
+-+-+-+-+-+-+-+-+

I suspect that the confusion is rooted in the interpretation of “bit X”: as (1) 
“bit position X” or the resulting (2) “binary value”:

  *   If (1) is followed, then bit#0 would be mapped to option 0, bit#1 to 
option 1, and so on. This logic is followed, e.g., for ipv6ExtensionHeaders.
  *   If (2) is followed, then bit#63 would be mapped to option 0, bit#62 to 
option 1, and so on.

In both cases, the drawing is not aligned with the narrative text. We may 
either consider updating the drawing or the text.

Which change is likely to have less impact on existing implementations? FWIW, 
(1) is what was followed in RFC5102 but changed since then by errata.

Thank you.

Cheers,
Med


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] IVY Interim meeting agenda

[daniele.ietf]

Hi working group,

 

We uploaded the agenda for the interim meeting, you can find it at the
following link:
https://datatracker.ietf.org/meeting/interim-2023-ivy-01/materials/agenda-in
terim-2023-ivy-01-ivy-01-01.htm

 

Please let us have your slides by tomorrow.

 

Thank you,

Qiufang & Daniele  

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

[mohamed . boucadair]

Hi all,

The description of these IEs says that "Options are mapped to bits according to 
their option numbers. Option number X is mapped to bit X", however the drawing 
does not reflect that (tcpOptions):

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   7 |   6 |   5 |   4 |   3 |   2 |   1 |   0 |  ...
+-+-+-+-+-+-+-+-+

8 9101112131415
+-+-+-+-+-+-+-+-+
... |  15 |  14 |  13 |  12 |  11 |  10 |   9 |   8 |...
+-+-+-+-+-+-+-+-+

   1617181920212223
+-+-+-+-+-+-+-+-+
... |  23 |  22 |  21 |  20 |  19 |  18 |  17 |  16 |...
+-+-+-+-+-+-+-+-+

  . . .

   5657585960616263
+-+-+-+-+-+-+-+-+
... |  63 |  62 |  61 |  60 |  59 |  58 |  57 |  56 |
+-+-+-+-+-+-+-+-+

I suspect that the confusion is rooted in the interpretation of "bit X": as (1) 
"bit position X" or the resulting (2) "binary value":

  *   If (1) is followed, then bit#0 would be mapped to option 0, bit#1 to 
option 1, and so on. This logic is followed, e.g., for ipv6ExtensionHeaders.
  *   If (2) is followed, then bit#63 would be mapped to option 0, bit#62 to 
option 1, and so on.

In both cases, the drawing is not aligned with the narrative text. We may 
either consider updating the drawing or the text.

Which change is likely to have less impact on existing implementations? FWIW, 
(1) is what was followed in RFC5102 but changed since then by errata.

Thank you.

Cheers,
Med

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] draft-ietf-opsawg-ipfix-fixes: ipv6ExtensionHeaders

[mohamed . boucadair]

Hi all,

draft-ietf-opsawg-ipfix-fixes creates a sub-registry to mirror the assignments 
in the IPv6 EH registry. The current text [1] says that codes are not assigned 
directly from the IPFIX sub-registry. Please let us know if we need to change 
that policy ? For example, whether we need to also include a provision for 
direct control via DE.

When checking the EHs listed in the IPFIX registry, we noted that 108 is listed 
as an EH, while this is not tagged as so in [2][3]. [1] tags bit position #15 
as unassigned to align with other authoritative registries. Please let us know 
whether you have concerns with this change. Thanks.

Cheers,
Med

[1] 
https://boucadair.github.io/simple-ipfix-fixes/#go.draft-ietf-opsawg-ipfix-fixes.diff
[2] https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
[3] 
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

[Jürgen Schönwälder]

You have to make sure that the right people and WG receive the
erratum, RFC 5340 belongs to the OSPF WG.

/js

On Mon, Sep 18, 2023 at 04:32:02PM -0700, Chris Smiley wrote:
> 
> Greetings,
> 
> This errata reports a problem with Section A.3.3/RFC 5343.  It has been 
> corrected to Section A.3.3/RFC 5340
> 
> Please let us know any concerns. 
> 
> Thank you.
> 
> RFC Editor/cs
> 
> 
> > On Sep 17, 2023, at 10:49 PM, RFC Errata System  
> > wrote:
> > 
> > The following errata report has been submitted for RFC5343,
> > "Simple Network Management Protocol (SNMP) Context EngineID Discovery".
> > 
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7645
> > 
> > --
> > Type: Technical
> > Reported by: Owen DeLong 
> > 
> > Section: A.3.3
> > 
> > Original Text
> > -
> > Section A.3.3 (in part) reads:
> > 
> > Interface MTU
> >  The size in bytes of the largest IPv6 datagram that can be sent
> >  out the associated interface without fragmentation.  The MTUs of
> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
> >  Interface MTU should be set to 0 in Database Description packets
> >  sent over virtual links.
> > 
> > 
> > Corrected Text
> > --
> > Interface MTU
> >  The size in bytes of the largest IPv6 datagram that can be sent
> >  out the associated interface without fragmentation.  The MTUs of
> >  common Internet link types can be found in Table 7-1 of [MTUDISC].
> >  Interface MTU should be set to 0 in Database Description packets
> >  sent over OSPF virtual links. This rule should not be applied to tunnel
> >  or other software interfaces.
> > 
> > 
> > Notes
> > -
> > OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
> > and this provision makes sense. For interfaces that have an actual MTU, 
> > even though they may be "virtual" interfaces, they are not "virtual links" 
> > in the intended meaning of this paragraph. As such, this change will 
> > provide clarification and remove ambiguity from the current standard. At 
> > least one popular router vendor implements this RFC as MTU = 0 sent on all 
> > GRE interfaces which results in incompatibilities with most other router 
> > platforms which expect an actual value. The router vendor points to this 
> > provision in the RFCs as justification for their implementation. It is 
> > (arguably) a legitimate, if nonsensical interpretation of the existing text.
> > 
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party  
> > can log in to change the status and edit the report, if necessary. 
> > 
> > --
> > RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
> > --
> > Title   : Simple Network Management Protocol (SNMP) Context 
> > EngineID Discovery
> > Publication Date: September 2008
> > Author(s)   : J. Schoenwaelder
> > Category: PROPOSED STANDARD
> > Source  : Operations and Management Area Working Group
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> > 
> 

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg