[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    [Lsr] [Errata Rejected] RFC5185 (6506)
From:       RFC Errata System <rfc-editor () rfc-editor ! org>
Date:       2021-05-17 22:08:18
Message-ID: 20210517220818.5062AF4079B () rfc-editor ! org
[Download RAW message or body]

The following errata report has been rejected for RFC5185,
"OSPF Multi-Area Adjacency".

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

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

Reported by: Ketan Talaulikar <ketant@cisco.com>
Date Reported: 2021-04-02
Rejected by: John Scudder (IESG)

Section: 2.7

Original Text
-------------
   Multi-area adjacencies are announced as point-to-point links.  Once
   the router's multi-area adjacency reaches the FULL state, it will be
   added as a link type 1 to the Router Link State Advertisement (LSA)
   with:

      Link ID = Remote's Router ID

      Link Data = Neighbor's IP Address or IfIndex (if the underlying
      interface is unnumbered).

   Unlike numbered point-to-point links, no type 3 link is advertised
   for multi-area adjacencies.


Corrected Text
--------------
   Multi-area adjacencies are announced as point-to-point links.  Once
   the router's multi-area adjacency reaches the FULL state, it will be
   added as a link type 1 to the Router Link State Advertisement (LSA)
   with:

      Link ID = Remote's Router ID

      Link Data = Router interface's IP Address or IfIndex (if the underlying
      interface is unnumbered).

   Unlike numbered point-to-point links, no type 3 link is advertised
   for multi-area adjacencies.


Notes
-----
The encoding of Link Data as specified in RFC5185 is not consistent with the base \
OSPF specification in RFC2328. This has resulted in different behaviors in deployed \
implementations where some follow RFC2328 (i.e. the corrected text) while others \
follow the Original text of RFC5185 leading to interop issues.

More importantly, for implementations of RFC5185, it is not possible to determine the \
Neighbor's interface IfIndex unless some additional mechanisms (that have not been \
specified or referenced by RFC5185) are implemented - viz. RFC8510.

This topic has been discussed in the LSR WG recently and this errata is being raised \
to track this issue : \
                https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/
                
 --VERIFIER NOTES-- 
As discussed here (https://mailarchive.ietf.org/arch/msg/lsr/9IAkRCbZN39loWcwKjtNWfUW_qA/) \
this would be a technical change vs. the WG consensus when the document was \
progressed, and should be rejected (see \
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ #7). The \
appropriate way to pursue this looks to be an update or bis.


--------------------------------------
RFC5185 (draft-ietf-ospf-multi-area-adj-09)
--------------------------------------
Title               : OSPF Multi-Area Adjacency
Publication Date    : May 2008
Author(s)           : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal
Category            : PROPOSED STANDARD
Source              : Open Shortest Path First IGP
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[prev in list] [next in list] [prev in thread] [next in thread]