Re: [Lsr] [Technical Errata Reported] RFC2328 (5611)
"Acee Lindem (acee)" <acee@cisco.com> Tue, 22 January 2019 20:50 UTC
Return-Path: <acee@cisco.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 066191310F1 for <lsr@ietfa.amsl.com>; Tue, 22 Jan 2019 12:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.642
X-Spam-Level:
X-Spam-Status: No, score=-14.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 kx7sSl8amYmH for <lsr@ietfa.amsl.com>; Tue, 22 Jan 2019 12:50:05 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0496B1310EE for <lsr@ietf.org>; Tue, 22 Jan 2019 12:50:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3680; q=dns/txt; s=iport; t=1548190205; x=1549399805; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DPjh7h8NvlYVJs5GNOroqOUuw9DswXusLdpQ0zNWJdw=; b=I/pWfvQUm64Iezulsm5D8x7TG2NEmbrm3Aw+Xa0B6ELj8HHvfo96WNR3 XOUBgthzQKIg/GpRhOxX6u6apDAds8smkfLiLqR//0xCuPSSSVhKsJF0S 2KiZmklhpTr/lCutWERwVu80xRCLHBrHv6JJvMPtRpxlHajetqAaIqBIN E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACfgEdc/49dJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVUuZoECJwqDd4gai2yaDoF7CwEBI4RJAheCViI0CQ0BAwEBAgEBAm0cDIVLBiMRRRACAQgaAiYCAgIwFRACBAENBYMiAYIBD61DgS+EAgEBhiyBC4s2F4F/gREnH4JMgUGDQIMJMYImAollJodXkD4JApIZEgaBZoUuiUSBPIoEkHICERSBJx84gVZwFRpLAYJBCYIqiGqFCAE2QTGJeIEfAQE
X-IronPort-AV: E=Sophos;i="5.56,508,1539648000"; d="scan'208";a="229712634"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2019 20:50:03 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x0MKo1KQ001788 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Jan 2019 20:50:03 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 22 Jan 2019 15:50:01 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Tue, 22 Jan 2019 15:50:01 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "jmoy@casc.com" <jmoy@casc.com>, "db3546@att.com" <db3546@att.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "martin.vigoureux@nokia.com" <martin.vigoureux@nokia.com>, "akr@cisco.com" <akr@cisco.com>
CC: "mandru@versa-networks.com" <mandru@versa-networks.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Technical Errata Reported] RFC2328 (5611)
Thread-Index: AQHUso5bgTGc8brNQk2IVql/Ka04c6W7wvgA
Date: Tue, 22 Jan 2019 20:50:01 +0000
Message-ID: <E96ED7EE-F4BA-49DB-A7D8-A387F308BC96@cisco.com>
References: <20190122200910.CE3B0B80E83@rfc-editor.org>
In-Reply-To: <20190122200910.CE3B0B80E83@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.197]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A68931399B47434D98BC63BB9CF83313@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/2cipgj66icQ3k8VXeFFy5LT4buw>
Subject: Re: [Lsr] [Technical Errata Reported] RFC2328 (5611)
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: Tue, 22 Jan 2019 20:50:07 -0000
Hi Anil, This is the case where the transit network vertex corresponding to a network-LSA is newly added to the current intra-area graph and an intra-area route corresponding to the SPF in progress already exists. This implies that there was another network-LSA. So, either the network corresponding to the subnet is partitioned or there is a network configuration error with the same subnet configured for multiple multi-access networks. In either case, I don't really see the benefit of an ECMP route. In fact, it could make trouble-shooting the problem more difficult. Hence, I would advise Alvaro, the responsible AD, to reject this Errata. Thanks, Acee On 1/22/19, 3:09 PM, "RFC Errata System" <rfc-editor@rfc-editor.org> wrote: The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5611 -------------------------------------- Type: Technical Reported by: Anil Chaitanya Mandru <mandru@versa-networks.com> Section: 16.1 (4) Original Text ------------- In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. Corrected Text -------------- In this case, if the newly found path is just as short, then both the paths should be added to the routing table. Notes ----- If the newly found path is just as short then both the paths should be considered for ECMP. Why should the smaller Link State ID path overwrite the current one even if the paths are equi distant? 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. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG
- [Lsr] [Technical Errata Reported] RFC2328 (5611) RFC Errata System
- Re: [Lsr] [Technical Errata Reported] RFC2328 (56… Acee Lindem (acee)
- Re: [Lsr] [Technical Errata Reported] RFC2328 (56… Alvaro Retana