Re: [Lsr] [Technical Errata Reported] RFC2328 (5611)

"Acee Lindem (acee)" <> Tue, 22 January 2019 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 066191310F1 for <>; Tue, 22 Jan 2019 12:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.642
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kx7sSl8amYmH for <>; Tue, 22 Jan 2019 12:50:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0496B1310EE for <>; Tue, 22 Jan 2019 12:50:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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: =?us-ascii?q?A0ADAACfgEdc/49dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVUuZoECJwqDd4gai2yaDoF7CwEBI4R?= =?us-ascii?q?JAheCViI0CQ0BAwEBAgEBAm0cDIVLBiMRRRACAQgaAiYCAgIwFRACBAENBYM?= =?us-ascii?q?iAYIBD61DgS+EAgEBhiyBC4s2F4F/gREnH4JMgUGDQIMJMYImAollJodXkD4?= =?us-ascii?q?JApIZEgaBZoUuiUSBPIoEkHICERSBJx84gVZwFRpLAYJBCYIqiGqFCAE2QTG?= =?us-ascii?q?JeIEfAQE?=
X-IronPort-AV: E=Sophos;i="5.56,508,1539648000"; d="scan'208";a="229712634"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2019 20:50:03 +0000
Received: from ( []) by (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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 22 Jan 2019 15:50:01 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Tue, 22 Jan 2019 15:50:01 -0500
From: "Acee Lindem (acee)" <>
To: RFC Errata System <>, "" <>, "" <>, "" <>, "" <>, "" <>
CC: "" <>, "" <>
Thread-Topic: [Technical Errata Reported] RFC2328 (5611)
Thread-Index: AQHUso5bgTGc8brNQk2IVql/Ka04c6W7wvgA
Date: Tue, 22 Jan 2019 20:50:01 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Lsr] [Technical Errata Reported] RFC2328 (5611)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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. 


´╗┐On 1/22/19, 3:09 PM, "RFC Errata System" <>; wrote:

    The following errata report has been submitted for RFC2328,
    "OSPF Version 2".
    You may review the report below and at:
    Type: Technical
    Reported by: Anil Chaitanya Mandru <>;
    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. 
    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?
    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