Subject: [Lsr] [Technical Errata Reported] RFC2328 (5956)

From: RFC Errata System <[email-masked]>
Date: Wed, 8 Jan 2020 13:58:10 -0800 (PST)

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

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

--------------------------------------
Type: Technical
Reported by: Marcelo Bustani <[email-masked]>

Section: 12.4.1

Original Text
-------------
Router-LSAs

If the state of the interface is Loopback, add a Type 3
link (stub network) as long as this is not an interface
to an unnumbered point-to-point network.  The Link ID
should be set to the IP interface address, the Link Data
set to the mask 0xffffffff (indicating a host route),
and the cost set to 0.

===================================
12.4.1.4.  Describing Point-to-MultiPoint interfaces

                For operational Point-to-MultiPoint interfaces, one or
                more link descriptions are added to the router-LSA as
                follows:

                o   A single Type 3 link (stub network) is added with
                    Link ID set to the router's own IP interface
                    address, Link Data set to the mask 0xffffffff
                    (indicating a host route), and cost set to 0.
=============================================================================
C.3 Router interface parameters
 
 Interface output cost
            The cost of sending a packet on the interface, expressed in
            the link state metric.  This is advertised as the link cost
            for this interface in the router's router-LSA. The interface
            output cost must always be greater than 0.

Corrected Text
--------------
"cost set to 0" to at least "greater than 0"

Notes
-----
The section 12.4.1 and 12.4.1.4 are inconsistent with the appendix c.3.

These both section we find the cost to stub networks have to be set to 0, but in appendix c.3 we see that the interfaces must have greater than 0.

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 9 Jan 2020 16:13:23 +0000

All, 
I don't agree this change is required. The non-normative appendix C text clearly states that this is the "cost of sending a packet on the interface". The examples cited are cases where reachability to a local address is provided. Now, there are cases where it is useful to specify a non-zero cost for a loopback address (e.g., Anycast addresses) but these scenarios are out of scope.
Thanks,
Acee

On 1/8/20, 4:58 PM, "RFC Errata System" <[email-masked]> wrote:

    
    
    Section: 12.4.1
    
    Original Text
    -------------
    Router-LSAs

    

     Interface output cost

    Corrected Text
    --------------
    
    Notes
    -----

    Instructions:
    -------------

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 9 Jan 2020 12:02:36 -0800

On January 9, 2020 at 11:13:26 AM, Acee Lindem wrote:

[Trimming the distribution list.]

Hi!

I agree with Acee, but for different reasons.

> I don't agree this change is required. The non-normative appendix C text
> clearly states that this is the "cost of sending a packet on the interface".
> The examples cited are cases where reachability to a local address is
> provided. Now, there are cases where it is useful to specify a non-zero cost
> for a loopback address (e.g., Anycast addresses) but these scenarios are out
> of scope.

I always thought that the Appendices were normative...among other
things because of how they are referenced in the text, they define the
LSA formats, etc.   But §9 (The Interface Data Structure) contains the
same text anyway:

   Interface output cost(s)
       The cost of sending a data packet on the interface, expressed in
       the link state metric.  This is advertised as the link cost for
       this interface in the router-LSA. The cost of an interface must
       be greater than zero.

Acee is right in pointing out that the text above doesn't apply
because "reachability to a local address is provided"; in fact, both
the examples mentioned say that the information is "indicating a host
route"...

§12.4.1 (Router-LSAs):

   A host route is represented as a Type 3 link (stub network)
   whose Link ID is the host's IP address, Link Data is the mask
   of all ones (0xffffffff), and cost the host's configured cost
   (see Section C.7).

...and from §C.7 (Host route parameters):

   Cost of link to host
       The cost of sending a packet to the host, in terms of the
       link state metric.  However, since the host probably has
       only a single connection to the internet, the actual
       configured cost in many cases is unimportant (i.e., will
       have no effect on routing).

The specification says that for a host route the cost doesn't matter,
so the fact that the examples indicate "cost set to 0" is not in
conflict.

Alvaro.

> On 1/8/20, 4:58 PM, "RFC Errata System" wrote:
>
> Reported by: Marcelo Bustani
>
> Section: 12.4.1
>
> Original Text
> -------------
> Router-LSAs
>
> These both section we find the cost to stub networks have to be set to 0, but
> in appendix c.3 we see that the interfaces must have greater than 0.
>
> Instructions:
> -------------

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 9 Jan 2020 15:11:17 -0800

On January 9, 2020 at 3:51:51 PM, Marcelo Bustani wrote:

[Trimming the distribution.]

Marcelo:

Hi!

> I believe this is interesting to make this consistent, because I`m facing
> different usage for this situation. For example, Cisco uses cost 1 for this
> type of interface and Juniper cost 0.
> I think that RFC as a document of standardization must be followed by all,
> mainly for an open protocol as OSPF.

We're all in agreement about the purpose of the RFC. :-)

As far as the Errata Report, no change to the RFC is needed.  Unless
anyone on the list disagrees, I am them going to mark the report as
Rejected.

You should be able to point the vendors to the RFC text and this discussion.

Best regards,

Alvaro.

---

From: Marcelo Bustani <[email-masked]>
Date: Thu, 9 Jan 2020 21:53:03 -0300

Hi Retana,

I appreciate your time and of all involved, but it is very inadmissible we
have a document used as a reference that is not used appropriately, or by
misunderstanding or by convenience.

I will internally advertise AT&T and IBM, because we work together with
both Cisco and Juniper equipment, and by the way with OSPF
interoperability. Beyond this tinny found, we can have another one that can
bring a big problem. This one, sincerely, I don't know what kind of issue
can bring, but at least I already know and it will save our time of
troubleshooting or delivering. My intention was to mitigate a possible
misunderstanding or a multiple different interpretations, that I guess it
is happening with Cisco and Juniper; both are not wrong depending from the
section they are based on.

So, I will try, following your recommendation, also to contact Cisco and
Juniper to make this all clear. As I said, my concern is that we have more
inconsistency between vendors and about something bigger.

Thank you guys!!
Happy 2020.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 10 Jan 2020 10:15:00 -0800

On January 9, 2020 at 7:53:17 PM, Marcelo Bustani wrote:

Marcelo:

Olá!

> My intention was to mitigate a possible misunderstanding or a multiple
> different interpretations, that I guess it is happening with Cisco and
> Juniper; both are not wrong depending from the section they are based on.

That should not be the case.

In the two specific cases that you initially mentioned, for Loopbacks
and the stub link to describe a p2mp, the text is clear: "cost set to
0".  I don't understand how it is possible to have a different
interpretation of that.

I do understand how vendors can and do provide knobs that can change
the configured cost...but the default is still clear in the RFC: "cost
set to 0".  If that is not the default, then I think it is a bug in
the implementation and not in the RFC.

The Errata Reporting process is in place to correct errors in the
RFCs.  In this case, I don't think there is an error.

If you have suggestions to change the text to clarify (which is
different than correcting an error), then that is something that
should be discussed in the WG ([email-masked]).  rfc2328 is far from
perfect; I'm sure there is room for improvement.

Thanks!

Alvaro.