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

Alvaro Retana <> Mon, 28 January 2019 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AAD8131062 for <>; Mon, 28 Jan 2019 08:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IhZa9dvPm3Cj for <>; Mon, 28 Jan 2019 08:52:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A2BC13105F for <>; Mon, 28 Jan 2019 08:52:53 -0800 (PST)
Received: by with SMTP id t204so13575812oie.7 for <>; Mon, 28 Jan 2019 08:52:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=E1l5Ef/QwHmqGqKes+Jm/wah8thRjYNB1Fra955+WmQ=; b=fZH0TCaco1iPPWbgXMnzKxi3X8LZLbbDRQXyqIPPd9NO0cM9tXiZD4trmENI7zV58m 6RjcJ+rojOvNcC6GNnWcZ3EP4lW4D64RmM28Buf9XlVB9ClV4182DTihnm3d8U2SVOZ5 CVAkHz00Q6ptniZw4UFzWO/kI5nf0cQXDVrb7uq0/H8pWkuSByghB9i3LsbrzW57sfFH ZPr048PyJG3s1ZfuiI3hb80qD5ODE/vyhSsYmxkSilGqSNqQusrBtVXOVj9Sg88xrjgI QaJbDtpxe4jaSmywWCXHamFVq5b6Mk5gB8dAC7inDhYY1MlMolYxUDgFNOQ2ulQuo4LS 2Kmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=E1l5Ef/QwHmqGqKes+Jm/wah8thRjYNB1Fra955+WmQ=; b=LE5kJj/L6sa4EK1UsDKtsEIVCkwjpNfiwauCnXpK9nMKL9xDhvv8hGFK4HvxWXuopP Ip7F2Q7sjcscOAwy2bilLV+NYexkPLqYyKt5bn1L6d4pnRnox67/pd/FnskVTtKWtLyL eu9B73s5rDuHp9qTYzIeGR97D9BHbJ+I9pb0eCpFttllKrb6s5z3Y2s3/SHKo4sAWawj pQFfdjDBMkhlOMpikq9jfH0O+cp+0UTD+L03eZ6bIVJWvv098NjNATN3ZX9Y205O4fZj IxHzUC3L3cJ/S8Fw2ZpZlXMkBSAUUobEJBMWTdNaZI5AB7av3lOJTD3R7EjXHTIxS2Gj cMNw==
X-Gm-Message-State: AHQUAubzhIeaoMK620ayE2cMzaqIoSlXdxIHukJoZ7RVZJX21ZmYrSGs VnwGGrkjVThsM9rzNkjZpr081455M6s4lchPwwk+mQ==
X-Google-Smtp-Source: AHgI3IbAsTFI8/o5Q17ixhTXCh9cIMV7MONBJJ1+UBfvWdLNPpejJWxJ6VBqZC6uDiHpwBB2P9u3KHIG1xxwGFb2SNM=
X-Received: by 2002:aca:a881:: with SMTP id r123mr6779023oie.207.1548694372439; Mon, 28 Jan 2019 08:52:52 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 28 Jan 2019 08:52:51 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Mon, 28 Jan 2019 08:52:51 -0800
Message-ID: <>
To: "Acee Lindem (acee)" <>, "" <>
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000ef5b0a05808781b3"
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: Mon, 28 Jan 2019 16:52:55 -0000

[Took the RFC Editor off..and removed Abhay’s e-mail as it is out of date.
I’m pretty sure John’s e-mail is also not accurate anymore, I moved that to
bcc…. In short, everyone interested should be in the lsr list. :-)]


I am marking this report as Rejected…both because of Acee’s explanation,
but also because the intent of the system is to correct mistakes, not
change the specification.  In this case, the proposed text would result in
a modification of the process to calculate the routing table.  A change
like that should be discussed in the WG/mailing list instead.



On January 22, 2019 at 3:50:04 PM, Acee Lindem (acee) (

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

Hence, I would advise Alvaro, the responsible AD, to reject this Errata.


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

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
Source : Open Shortest Path First IGP
Area : Routing
Stream : IETF
Verifying Party : IESG