> On Sep 20, 2023, at 7:02 PM, Owen DeLong <[email protected]> wrote: > > 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.
If you feel further specification is necessary, it should be done in a draft rather than an Errata (as John already mentioned). However, note that this is a solved problem as most vendors have implemented the “ip ospf ignore-mtu” interface configuration. Thanks, Acee > > 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]> 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
