Looks like this problem is known for over 13 years - Looks like a day one implementation bug:
https://juniper-nsp.puck.nether.narkive.com/2DmYT8s6/j-nsp-ospfv3-junos-sends-zero-mtu-in-dbd-stuck-in-exstart Do you think fixing a few RFCs which are pretty obvious what the behaviour should be will really help ? Cheers, R. On Mon, Sep 18, 2023 at 5:46 PM Owen DeLong <[email protected]> wrote: > Happy to achieve the desired result (clarification) through whatever is > the best mechanism, whether that be reattached, addition of a terminology > section, or some other process not yet expressed. > > The vendor I referred to as getting this wrong is a very large router > vendor. Multiple parties that have reported this issue through their TAC > have been told “working as designed” with reference to this section and to > section A.3.3 of RFC 5343 (for which I have submitted a similar errata > report (7645). > > I’m trying to do this without public shaming of the vendor in question, > but they are one of the domains in the CC list of this message. > > As such, I don’t think this mistake is limited to casual readers. > > Owen > > > On Sep 18, 2023, at 05:13, Acee Lindem <[email protected]> wrote: > > Hi Robert, > > > > On Sep 18, 2023, at 07:50, Robert Raszuk <[email protected]> wrote: > > Acee, > > I agree with your assessment. > > But looking at the RFC I would say it is missing a Terminology section. If > such section would clearly define meaning of virtual link in the context of > this RFC there would be no ambiguity. > > Otherwise those not skilled in OSPF art may take a document and apply > casual meaning to virtual link (which does indeed include a tunnel of any > sort :). > > Of course this entire RFC is about OSPFv3 so this should be very intuitive > to read it in such context not as casual IETF issued paper. > > > Right. > > > If any errara is needed here IMHO is just to add terminology section > unless there is some formal definition that in all IETF RFCs terms > apply only to the context of given subject doc. I am honestly not sure if > there is one. > > > I believe you could take almost any Routing RFC and improve it with > editing and the addition of more context. This was clearly the case for > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/ > > This started out as a respin of the document for inclusive language but I > also made significant edits to improve the readability (as well as address > errata and other minor errors). After that, I received some really good > input from reviewers (e.g., Quentin Arimitage provided around 70 comments > and suggestions, most of which were incorporated). > > However, improvements such as these are usually not done with an Errata. > > Thanks, > Acee > > > > > Thx, > R. > > On Mon, Sep 18, 2023 at 1:27 PM Acee Lindem <[email protected]> wrote: > >> >> >> > On Sep 17, 2023, at 22:07, Owen DeLong <[email protected]> wrote: >> > >> > You say they are unnecessary, then why do we have vendors doing this >> wrong and pointing to this requirement of the RFC as their reason for doing >> so? >> > >> > While there may be a valid argument that they shouldn’t be necessary, I >> would argue that real world implementation experience suggests that they are >> > most definitely necessary and are a minor edit to provide additional >> clarity. >> >> An OSPF virtual link and a tunnel (e.g., GRE tunnel) are totally >> different constructs. The vendor is incorrect in arguing that this text >> specifics operation over a GRE tunnel. Rather, they should be arguing that >> OSPF doesn’t have any path MTU capabilities and since a tunnel can be >> multi-hop, OSPF doesn’t know the MTU. >> >> Thanks, >> Acee >> >> >> > >> > Are you really arguing to preserve ambiguous language when the problem >> is so easy to solve? >> > >> > Owen >> > >> > >> > >> >> On Sep 17, 2023, at 15:25, Acee Lindem <[email protected]> wrote: >> >> >> >> Given that the context of the “Interface MTU” is specifically the >> “interface MTU” field in OSPFv3 Database Description packets and OSPF >> virtual links (RFC 2328), the additions recommended in this Errata are >> unnecessary. The Errata should be rejected. >> >> >> >> Thanks, >> >> Acee >> >>> On Sep 17, 2023, at 15:58, RFC Errata System < >> [email protected]> wrote: >> >>> >> >>> The following errata report has been submitted for RFC5838, >> >>> "Support of Address Families in OSPFv3". >> >>> >> >>> -------------------------------------- >> >>> You may review the report below and at: >> >>> https://www.rfc-editor.org/errata/eid7644 >> >>> >> >>> -------------------------------------- >> >>> Type: Technical >> >>> Reported by: Owen DeLong <[email protected]> >> >>> >> >>> Section: 2.7 >> >>> >> >>> Original Text >> >>> ------------- >> >>> Interface MTU >> >>> The size in octets of the largest address family specific datagram >> >>> that can be sent on the associated interface without >> >>> fragmentation. The MTUs of common Internet link types can be >> >>> found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set >> >>> to 0 in Database Description packets sent over virtual links. >> >>> >> >>> >> >>> Corrected Text >> >>> -------------- >> >>> Interface MTU >> >>> The size in octets of the largest address family specific datagram >> >>> that can be sent on the associated interface without >> >>> fragmentation. The MTUs of common Internet link types can be >> >>> found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set >> >>> to 0 in Database Description packets sent over (OSPF3) virtual >> links. >> >>> This recommendation MUST NOT be applied to tunnel and other virtual >> >>> or software interfaces which carry traffic other than OSPF >> protocol packets. >> >>> >> >>> Notes >> >>> ----- >> >>> Currently, the language is ambiguous and at least one vendor has >> implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly >> others such as IPIP, IPSEC, etc., as I have not tested these). I believe >> that the intent of the RFC is to refer strictly to OSPF virtual-links which >> carry only OSPF protocol data and therefore have no meaningful MTU. When >> this is mistakenly applied to other forms of "virtual" interfaces such as >> tunnels, the results can be quite harmful. >> >>> >> >>> As such, I think that clarification is in order, since the vendor in >> question is unrepentant and claims their current implementation to be >> compliant with the RFC. >> >>> >> >>> 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. >> >>> >> >>> -------------------------------------- >> >>> RFC5838 (draft-ietf-ospf-af-alt-10) >> >>> -------------------------------------- >> >>> Title : Support of Address Families in OSPFv3 >> >>> Publication Date : April 2010 >> >>> Author(s) : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. >> Barnes, R. Aggarwal >> >>> 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
