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

Hi John, 

I now recall this discussion. In the context of OSPFv3, an OSPFv3 adjacency over a tunnel should NOT be misconstrued as an OSPFv3 virtual link and the Errata is invalid. 

Thanks,
Acee

> On Jan 11, 2024, at 14:30, John Scudder <jgs@juniper.net> wrote:
> 
> Quickly reversing myself, and to quote my other reply just now: "Actually, upon reviewing this one, I'm leaning back toward simply rejecting both this erratum and erratum 7644. As we discussed earlier in the thread on this one, the best fix (assuming the working group agrees is a fix is merited, of course) is a draft to update or replace the base spec.”
> 
> In short, “never mind!”
> 
> —John
> 
>> On Jan 11, 2024, at 2:24 PM, John Scudder <jgs@juniper.net> wrote:
>> 
>> Hi Acee, WG,
>> 
>> I'm convinced this doesn't meet the criteria to be verified as a technical erratum. I am considering verifying it as "Hold for Document Update”, though. The definition for HFDU is "The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update.” [1]
>> 
>> Please let me know soon if you have any concerns about that disposition.
>> 
>> --John
>> 
>> [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
>> 
>> 
>>> On Sep 17, 2023, at 6:25 PM, Acee Lindem <acee.ietf@gmail.com> 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 <rfc-editor@rfc-editor.org> 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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7644__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmW7pFbpMU$
>>>> 
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Owen DeLong <owen@delong.com>
>>>> 
>>>> 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
>>>> Lsr@ietf.org
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmWKATRhUo$
>> 
> 