[Lsr] [Errata Rejected] RFC5838 (7644)
RFC Errata System <rfc-editor@rfc-editor.org> Thu, 11 January 2024 22:28 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCE4C14F6AE; Thu, 11 Jan 2024 14:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.659
X-Spam-Level:
X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJNDAHtQB_5Z; Thu, 11 Jan 2024 14:28:43 -0800 (PST)
Received: from rfcpa.amsl.com (rfcpa.amsl.com [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A24C14F6AD; Thu, 11 Jan 2024 14:28:43 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 3E69C1A2161E; Thu, 11 Jan 2024 14:28:43 -0800 (PST)
To: owen@delong.com, acee.lindem@ericsson.com, smirtora@cisco.com, akr@cisco.com, mjbarnes@cisco.com, rahul@juniper.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: jgs@juniper.net, iesg@ietf.org, lsr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240111222843.3E69C1A2161E@rfcpa.amsl.com>
Date: Thu, 11 Jan 2024 14:28:43 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/AcoFLdw9EmRkvqxGel_vL1yLxSc>
Subject: [Lsr] [Errata Rejected] RFC5838 (7644)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jan 2024 22:28:45 -0000
The following errata report has been rejected for RFC5838, "Support of Address Families in OSPFv3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7644 -------------------------------------- Status: Rejected Type: Technical Reported by: Owen DeLong <owen@delong.com> Date Reported: 2023-09-17 Rejected by: John Scudder (IESG) 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. --VERIFIER NOTES-- See discussion at https://mailarchive.ietf.org/arch/msg/lsr/wXdOtU9H2vIoA1xs10xZ4oh8bwU/ -------------------------------------- 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] [Errata Rejected] RFC5838 (7644) RFC Errata System