Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
> Hi Robert,
>
>
>
> On Sep 18, 2023, at 07:50, Robert Raszuk <[e-mail]> 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 <[e-mail]> wrote:
>
>>
>>
>> > On Sep 17, 2023, at 22:07, Owen DeLong <[e-mail]> 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 <[e-mail]> 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 <
>> [e-mail]> 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 <[e-mail]>
>> >>>
>> >>> 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
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/lsr
>> >>
>> >
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>
>