Given that they are responding to customers “Working as designed” and pointing to those RFCs as the reason, yes, I think enabling customers to point back at the RFCs and say “You got it wrong and the RFC now says so” will actually help.
Owen > On Sep 18, 2023, at 09:07, Robert Raszuk <[email protected]> wrote: > > > 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] > <mailto:[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] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Robert, >>> >>> >>> >>>> On Sep 18, 2023, at 07:50, Robert Raszuk <[email protected] >>>> <mailto:[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] >>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> > On Sep 17, 2023, at 22:07, Owen DeLong <[email protected] >>>>> > <mailto:[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] >>>>> >> <mailto:[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] <mailto:[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] <mailto:[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] <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
