[Lsr] [Errata Rejected] RFC2328 (5611)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 28 January 2019 17:06 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 B6BED131083; Mon, 28 Jan 2019 09:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GkZwHtETIyx6; Mon, 28 Jan 2019 09:06:51 -0800 (PST)
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 772F213107E; Mon, 28 Jan 2019 09:06:51 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id F0178B82548; Mon, 28 Jan 2019 09:06:43 -0800 (PST)
To: mandru@versa-networks.com, jmoy@casc.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: aretana.ietf@gmail.com, iesg@ietf.org, lsr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20190128170643.F0178B82548@rfc-editor.org>
Date: Mon, 28 Jan 2019 09:06:43 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_iRCAd7xa4L0_2GfZilEu7Ss-Vg>
Subject: [Lsr] [Errata Rejected] 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: Mon, 28 Jan 2019 17:06:53 -0000

The following errata report has been rejected for RFC2328,
"OSPF Version 2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5611

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Anil Chaitanya Mandru <mandru@versa-networks.com>;
Date Reported: 2019-01-22
Rejected by: Alvaro Retana (IESG)

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?
 --VERIFIER NOTES-- 
See WG discussion here: https://mailarchive.ietf.org/arch/msg/lsr/ACVzdktoiFbIcMyQck1RCGn50es 

>From Acee Lindem: "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. "

Note also that the proposed text would result in a modification of the process to calculate the routing table, not just a correction.  A change like that should be discussed in the WG/mailing list instead.


--------------------------------------
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