> 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
