errata is _not_ precise enough and the errata as proposed will cause more problems than it solves from my experience
1. what is the semantics of 0 here? Don't care? Then 0 can be sent on tunnel MTU and tunnel must stay up if one side sends "don't care"? If semantics of 0 is "no value" then same consideration applies AFAIS. So the errata would need to say "0 is a reserved value that means in ospf virtual link case that the field is not semantically valid and in other cases represents value of 0" (which seems nonsensical a bit but seems to aim towards what the errata tries to say) 2. fragmenting/non-fragmenting tunnels need be considered and explained in the errata. GRE can optionally fragment (but not in v6 case AFAIR except optionally for some wild header cases). In case of IPv6 we have additionally the 1280 consideration on top AFAIR so if parts of the network runs bigger MTU, GRE does NOT fragment and more than 1280 shows up we end up with fragmented network IGP wise possibly. And I didn't even start to talk about extension headers on which the RFC is really quiet about ;-) 3. the MTU "largest datagram" needs to be errate'd to something more precise on top. Is that _with_ tunnel headers, with/without tunnel encaps etc (observe that e.g. vxlan is really an ip in ip and then ospf could be carried in that) or _purely_ the OSPF IPv6 packet? we fought those problems in ISIS forever with ugly corner cases (PPoE) I need to explain every couple of years to another batch of system engineers . I personally strongly suggest from experience to say "0 value" semantics is everywhere a "don't care" value which implicitly does remove MTU mismatch considerations in all kinds of interesting, ugly deployment cases. Other option is that to mean "same value as set on my interface" or "default value the protocol has set as constant" (in rift we chose that route from experience but we were driven by strong ZTP requirements) And BTW, any hardened stack has "ignore-mtu-mismatch" since this is a pretty common case to find implementations advertising mismatched values in weird tunnel/encaps cases (VLAN taggin' cases are a classic culprit beside PPoE IME) and stuff gets knob'ed out then ... that's of top of my head here ... -- tony On Wed, Sep 20, 2023 at 8:06 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://www.rfc-editor.org/errata/eid7649 > > > > -------------------------------------- > > 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://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
