[Lsr] [Technical Errata Reported] RFC5185 (6506)
RFC Errata System <rfc-editor@rfc-editor.org> Fri, 02 April 2021 12:29 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 832D93A12EA for <lsr@ietfa.amsl.com>; Fri, 2 Apr 2021 05:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW2OdnuwEtho for <lsr@ietfa.amsl.com>; Fri, 2 Apr 2021 05:29:36 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0E13A133A for <lsr@ietf.org>; Fri, 2 Apr 2021 05:29:35 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 687E1F40743; Fri, 2 Apr 2021 05:29:31 -0700 (PDT)
To: sina@nuovasystems.com, ppsenak@cisco.com, acee@redback.com, aoswal@redback.com, aretana.ietf@gmail.com, jgs@juniper.net, martin.vigoureux@nokia.com, akr@cisco.com, acee@cisco.com
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ketant@cisco.com, lsr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210402122931.687E1F40743@rfc-editor.org>
Date: Fri, 02 Apr 2021 05:29:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/sMKfptO3htGHdMHMDRzbtZ7slYA>
Subject: [Lsr] [Technical Errata Reported] RFC5185 (6506)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 02 Apr 2021 12:29:42 -0000
The following errata report has been submitted for RFC5185, "OSPF Multi-Area Adjacency". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6506 -------------------------------------- Type: Technical Reported by: Ketan Talaulikar <ketant@cisco.com> Section: 2.7 Original Text ------------- Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with: Link ID = Remote's Router ID Link Data = Neighbor's IP Address or IfIndex (if the underlying interface is unnumbered). Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. Corrected Text -------------- Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with: Link ID = Remote's Router ID Link Data = Router interface's IP Address or IfIndex (if the underlying interface is unnumbered). Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. Notes ----- The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues. More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510. This topic has been discussed in the LSR WG recently and this errata is being raised to track this issue : https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/ 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. -------------------------------------- RFC5185 (draft-ietf-ospf-multi-area-adj-09) -------------------------------------- Title : OSPF Multi-Area Adjacency Publication Date : May 2008 Author(s) : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG
- [Lsr] [Technical Errata Reported] RFC5185 (6506) RFC Errata System
- Re: [Lsr] [Technical Errata Reported] RFC5185 (65… John Scudder
- Re: [Lsr] [Technical Errata Reported] RFC5185 (65… Acee Lindem (acee)
- Re: [Lsr] [Technical Errata Reported] RFC5185 (65… Peter Psenak
- Re: [Lsr] [Technical Errata Reported] RFC5185 (65… Ketan Talaulikar (ketant)