RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Held for Document Update (1)

RFC 5185, "OSPF Multi-Area Adjacency", May 2008

Source of RFC: ospf (rtg)

Errata ID: 1437
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Stéphane Bortzmeyer
Date Reported: 2008-06-12
Held for Document Update by: Stewart Bryant

Section 2.1 says:

  Multi-area adjacencies are configured between two routers having a
   common interface. 

It should say:

  Multi-area adjacencies are configured between two routers having an
   interface to the same network.

Notes:

Unless "interface" is used in an unusual meaning?

Status: Rejected (2)

RFC 5185, "OSPF Multi-Area Adjacency", May 2008

Source of RFC: ospf (rtg)

Errata ID: 3595
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Marek Karasek
Date Reported: 2013-04-17
Rejected by: Stewart Bryant
Date Rejected: 2013-05-06

Section 4 says:

   A link-LSA SHOULD NOT be advertised for a multi-area adjacency.  The
   neighbor's IPv6 link local address can be learned in other ways,
   e.g., it can be extracted from the IPv6 header of Hello packets
   received over the multi-area adjacency.  The neighbor IPv6 link local
   address is required for the OSPFv3 route next-hop calculation on
   multi-access networks (refer to Section 3.8.1.1 of [OSPFV3]).

It should say:

OSPFv3 supports two Address Families (AF), AF IPv6 and AF IPv4, using
separate instances [RFC 5338]. The route calculation differs for the
IPv4 and IPv6 address families with respect to the next-hop
determination. OSPFv3 instances supporting an IPv6 AF SHOULD learn the
IPv6 next-hop address from the IPv6 Header source address and SHOULD
NOT advertise a Link-LSA for a multi-area adjacency. However, for
OSPFv3 instances supporting an IPv4 AF, the next-hop address cannot be
learned from the OSPFv3 hellos and require advertisement of the
Link-LSA. Hence, OSPFv3 instances supporting an IPv4 AF SHOULD
advertise a Link-LSA for the a multi-area adjacency (refer to section
2.5 of [RFC 5838]). If the Link-LSA is not advertised, the OSPFv3
instance MAY learn the IPv4 next-hop address from the Link-LSA
advertised on the primary adjacency.

Notes:

RFC5185 describes next-hop calculation which is not applicable to OSPFv3 process supporting AF IPv4 as defined in RFC5838. Errata defines how RFC5838 OSPFv3 process supporting AF IPv4 calculates next-hop address on multi-area interface.
--VERIFIER NOTES--
This is a technical change and is thus cannot be addressed through the errata process. The correct process for addressing this concern is by writing a draft that updates RFC5158 and testing whether there is OSPF WG and IETF consensus for publication of the proposed update.

Errata ID: 6506
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Ketan Talaulikar
Date Reported: 2021-04-02
Rejected by: John Scudder
Date Rejected: 2021-05-17

Section 2.7 says:

   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.

It should say:

   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.

Report New Errata