Given what I have seen, I would argue for semantics of 0=valid only on virtual link. On others, must not be 0 and must reflect actual interface MTU.
Owen > On Sep 20, 2023, at 12:34, Tony Przygienda <[email protected]> wrote: > > 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] > <mailto:[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] >> > <mailto:[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] <mailto:[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] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
