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.
—John > On Sep 20, 2023, at 2:05 PM, Acee Lindem <[email protected]> wrote: > > > I’m beginning to get a feeling of Deja MTU… > > Acee > >> On Sep 19, 2023, at 19:15, RFC Errata System <[email protected]> >> wrote: >> >> The following errata report has been submitted for RFC5340, >> "OSPF for IPv6". >> >> -------------------------------------- >> You may review the report below and at: >> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7649__;!!NEt6yMaO-gk!BYmUJjHFQ4KMZJsCjZgl_d0_PYcaJK_iJ6PuAAKdEtrss5IOJOR_WhubhtnyFvmisUP-WbpxnM0kOok$ >> >> -------------------------------------- >> Type: Technical >> Reported by: Owen DeLong <[email protected]> >> >> Section: A.3.3 (in part) >> >> Original 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 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. >> >> -------------------------------------- >> RFC5340 (draft-ietf-ospf-ospfv3-update-23) >> -------------------------------------- >> Title : OSPF for IPv6 >> Publication Date : July 2008 >> Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem >> 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!BYmUJjHFQ4KMZJsCjZgl_d0_PYcaJK_iJ6PuAAKdEtrss5IOJOR_WhubhtnyFvmisUP-Wbpxjmyny-M$ > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
