> On Sep 21, 2023, at 10:50, Alexander Okonnikov > <[email protected]> wrote: > > Hi WG, > > Regarding the errata - the errata claims that cause of it is the bug in an > implementation, sending DBD with Interface MTU = 0. Maybe it is so, but it > seems that real bug is in implementation(s), receiving and dropping such DPD. > > Both RFCs - 5838 and 5340 - inherit rules for receiving DBD from RFC 2328. > RFC 2328 says follow (section 10.6): > > "... If the Interface MTU field in the Database Description packet indicates > an IP datagram size that is larger than the router can accept on the > receiving interface without fragmentation, the Database Description packet is > rejected. ..." > > Obviously, 0 is not larger than IP datagram size that can be accepted on the > receiving interface. I guess that the size is greater than 0, but, even if it > is equal to 0, then 0 (Interface MTU value in DBD) is not larger than 0 > (acceptable size of receiving datagram). >
The problem isn’t rejection due to MTU too large, but rejection due to MTU mismatch. Router A from virtually any other vendor sees MTU on (e.g. GRE) interface as 1476 and sends 1476 in DBD. Router B from vendor J has MTU on interface as 1476, but instead sends 0 in DBD. Router A detects MTU mismatch and shuts down the session unless configured for ignore-mtu-mismatch. So the discussion of what routers should do if the MTU is too large is kind of not relevant to the errata. > Now regarding essense of the problem. I don't agree with the errata - it is > clear enough that 'virtual links' are mentioned in context of OSPF, hence, > 'OSPF virtual links' rather than some other 'virtual links' or 'IP virtual > links' are implied there. > But, I think that decision taken in the subjected implementation is good > trade-off for tunnel interfaces, which doesn't violate procedure for receiver > side, and, thus, even doesn't require implementation of 'ignore-mtu' > functionality on receiving side. Actually, issues, related to path MTU > discovery nature and applicable to OSPF virtual links, are equally applicable > to OSPF interfaces deployed as tunnels. I don't see how DBD Interface MTU can > help in solving problems with possible fragmentation, PMTU blackholes on > transit and so on. My view is that actual problem, which DBD Interface MTU is > intended to mitigate, is on tunnel egress OSPF router. Due to nature of > tunnels, tunneled IP datagrams can ingress OSPF router via any of multiple > transport interfaces, each of which may have its own MRU. What will be MRU of > tunnel interface in this case? It is OK if all those transport interfaces > have the same MRU value, and tunnel interface MRU will be stable, but what if > it is not the case? We would need to adjust tunnel MRU every time some > transport interface added/removed. It seems that omitting MRU check via DBD > Interface MTU for tunnel interfaces would be more or less good solution which > doesn't require OSPF spec modification (beside writing '0' into Interface MTU > field). Any way, current OSPF (per my knowledge) doesn't provide mechanism > for OSPF DBD receiver to signal actual MRU to OSPF DBD sender, and thus > rejecting DBD on receive doesn't look better than broken PMTUD (PMTUD > blackhole). I don’t disagree with your point here, but my point is that the RFC should provide some clear choice of behaviors that doesn’t result in a session being stuck due to a detected, but non-obvious MTU mismatch that requires one to analyze a packet capture to find. If router A sends 0 and router B drops the session for MTU mismatch, but “show interface” reports on both A and B show an MTU of 1476, I think we should all be able to agree that isn’t a desirable outcome. > Sorry in advance for long complicated speech. Nothing wrong with a good detailed analysis. Frankly, I have no problem if we want to go the other way and say that all tunnel interfaces should send MTU 0 in the DBD or find some other way to ensure that implementations are compatible without creating unnecessary problems. Some phrase that notes the inherent fictional nature of tunnel interface MTUs and requires routers to use the smaller of the DBD MTUs (sent or received), requiring sending the actual interface MTU, or requiring sending 0 MTU would all be acceptable outcomes as far as I’m concerned. The problem here is ambiguity resulting in incompatible implementations. You’ve amusingly explained why one vendor’s interpretation is both logical and nonsensical presenting a great detailed argument for both sides. From my perspective, the key here is to improve the specification such that one cannot create an incompatible, yet compliant implementation. I have no dog in the fight of which set of choices we use to achieve that. Owen > > Thanks. > >> 21 сент. 2023 г., в 12:49, Acee Lindem <[email protected]> написал(а): >> >> >> >>> 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 > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
