Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

[Acee Lindem <[e-mail]>]

Hi Robert, 



> On Sep 18, 2023, at 07:50, Robert Raszuk <[e-mail]> wrote:
> 
> Acee,
> 
> I agree with your assessment. 
> 
> But looking at the RFC I would say it is missing a Terminology section. If such section would clearly define meaning of virtual link in the context of this RFC there would be no ambiguity. 
> 
> Otherwise those not skilled in OSPF art may take a document and apply casual meaning to virtual link (which does indeed include a tunnel of any sort :). 
> 
> Of course this entire RFC is about OSPFv3 so this should be very intuitive to read it in such context not as casual IETF issued paper. 

Right. 

> 
> If any errara is needed here IMHO is just to add terminology section unless there is some formal definition that in all IETF RFCs terms apply only to the context of given subject doc. I am honestly not sure if there is one. 

I believe you could take almost any Routing RFC and improve it with editing and the addition of more context. This was clearly the case for https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/

This started out as a respin of the document for inclusive language but I also made significant edits to improve the readability (as well as address errata and other minor errors). After that, I received some really good input from reviewers (e.g., Quentin Arimitage provided around 70 comments and suggestions, most of which were incorporated). 

However, improvements such as these are usually not done with an Errata. 

Thanks,
Acee



> 
> Thx,
> R.
> 
> On Mon, Sep 18, 2023 at 1:27 PM Acee Lindem <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> > On Sep 17, 2023, at 22:07, Owen DeLong <[e-mail] <mailto:[e-mail]>> wrote:
>> > 
>> > You say they are unnecessary, then why do we have vendors doing this wrong and pointing to this requirement of the RFC as their reason for doing so?
>> > 
>> > While there may be a valid argument that they shouldn’t be necessary, I would argue that real world implementation experience suggests that they are
>> > most definitely necessary and are a minor edit to provide additional clarity.
>> 
>> An OSPF virtual link and a tunnel (e.g., GRE tunnel) are totally different constructs. The vendor is incorrect in arguing that this text specifics operation over a GRE tunnel. Rather, they should be arguing that OSPF doesn’t have any path MTU capabilities and since a tunnel can be multi-hop, OSPF doesn’t know the MTU. 
>> 
>> Thanks,
>> Acee
>> 
>> 
>> > 
>> > Are you really arguing to preserve ambiguous language when the problem is so easy to solve?
>> > 
>> > Owen
>> > 
>> > 
>> > 
>> >> On Sep 17, 2023, at 15:25, Acee Lindem <[e-mail] <mailto:[e-mail]>> wrote:
>> >> 
>> >> Given that the context of the “Interface MTU” is specifically the “interface MTU” field in OSPFv3 Database Description packets and OSPF virtual links (RFC 2328), the additions recommended in this Errata are unnecessary. The Errata should be rejected. 
>> >> 
>> >> Thanks,
>> >> Acee
>> >>> On Sep 17, 2023, at 15:58, RFC Errata System <[e-mail] <mailto:[e-mail]>> wrote:
>> >>> 
>> >>> The following errata report has been submitted for RFC5838,
>> >>> "Support of Address Families in OSPFv3".
>> >>> 
>> >>> --------------------------------------
>> >>> You may review the report below and at:
>> >>> https://www.rfc-editor.org/errata/eid7644
>> >>> 
>> >>> --------------------------------------
>> >>> Type: Technical
>> >>> Reported by: Owen DeLong <[e-mail] <mailto:[e-mail]>>
>> >>> 
>> >>> Section: 2.7
>> >>> 
>> >>> Original Text
>> >>> -------------
>> >>> Interface MTU
>> >>>    The size in octets of the largest address family specific datagram
>> >>>    that can be sent on the associated interface without
>> >>>    fragmentation.  The MTUs of common Internet link types can be
>> >>>    found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>> >>>    to 0 in Database Description packets sent over virtual links.
>> >>> 
>> >>> 
>> >>> Corrected Text
>> >>> --------------
>> >>> Interface MTU
>> >>>    The size in octets of the largest address family specific datagram
>> >>>    that can be sent on the associated interface without
>> >>>    fragmentation.  The MTUs of common Internet link types can be
>> >>>    found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>> >>>    to 0 in Database Description packets sent over (OSPF3) virtual links.
>> >>>    This recommendation MUST NOT be applied to tunnel and other virtual
>> >>>    or software interfaces which carry traffic other than OSPF protocol packets.
>> >>> 
>> >>> Notes
>> >>> -----
>> >>> Currently, the language is ambiguous and at least one vendor has implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of the RFC is to refer strictly to OSPF virtual-links which carry only OSPF protocol data and therefore have no meaningful MTU. When this is mistakenly applied to other forms of "virtual" interfaces such as tunnels, the results can be quite harmful.
>> >>> 
>> >>> As such, I think that clarification is in order, since the vendor in question is unrepentant and claims their current implementation to be compliant with the RFC.
>> >>> 
>> >>> 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. 
>> >>> 
>> >>> --------------------------------------
>> >>> RFC5838 (draft-ietf-ospf-af-alt-10)
>> >>> --------------------------------------
>> >>> Title               : Support of Address Families in OSPFv3
>> >>> Publication Date    : April 2010
>> >>> Author(s)           : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. Aggarwal
>> >>> Category            : PROPOSED STANDARD
>> >>> Source              : Open Shortest Path First IGP
>> >>> Area                : Routing
>> >>> Stream              : IETF
>> >>> Verifying Party     : IESG
>> >>> 
>> >>> _______________________________________________
>> >>> Lsr mailing list
>> >>> [e-mail] <mailto:[e-mail]>
>> >>> https://www.ietf.org/mailman/listinfo/lsr
>> >> 
>> > 
>> 
>> _______________________________________________
>> Lsr mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/lsr