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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>> >>>> 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 >>>> [email protected] >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmWKATRhUo$ >> > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
