RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 29 records.

Status: Verified (11)

RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 2953
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Joel Gannett
Date Reported: 2011-08-31
Verifier Name: Stewart Bryant
Date Verified: 2011-09-02

Section 3.4 says:

                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         20         27
                   N6            16         15
                   N7            20         19
                   N8            18         18
                   N9-N11,H1     29         36
                   _________________________________
                   RT5           14         8
                   RT7           20         14

              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.

It should say:

                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         20         27
                   N6            16         15
                   N7            20         19
                   N8            18         25
                   N9-N11,H1     29         36
                   _________________________________
                   RT5           14         8
                   RT7           20         14

              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.

Notes:

The distance from RT4 to N8 should be changed from 18 to 25. Unless there is a virtual link between RT7 and RT10, the shortest path from RT4 to N8 is 25, not 18. Although a virtual link from RT7 and RT10 is discussed in the last paragraph of Section 3.4, it is not assume part of the network design. Moreover, this change is needed to make the N9-N11,H1 row consistent with the N8 row, as each entry in the N9-N11,H1 row must be 11 greater than the same-column entry in the N8 row.

Errata ID: 3746
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ramakrishna DTV
Date Reported: 2013-10-09
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10

Throughout the document, when it says:

*. Section 3.3. (Classification of routers) says:

        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router
            advertises AS external routing information throughout the
            Autonomous System.  The paths to each AS boundary router are
            known by every router in the AS.  This classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.

*. Section 10.6 (Receiving Database Description Packets) says:

	      When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, generate the neighbor event SeqNumberMismatch and
        stop processing the packet.

*. Section 13. (The Flooding Procedure) says:

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, and none of router's neighbors are in states Exchange

It should say:

*. Section 3.3. (Classification of routers) should say:

        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router
            advertises AS external routing information throughout the
            Autonomous System.  The paths to each AS boundary router are
            known by every router in the AS (except stub areas).  This
            classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.

*. Section 10.6 (Receiving Database Description Packets) should say:

	      When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, or if this is a type-4 summary LSA and the neighbor
		is associated with a stub area, generate the neighbor event
        SeqNumberMismatch and stop processing the packet.

*. Section 13. (The Flooding Procedure) should say:

There should be an additional step in between steps 3 and 4  in
Section 13. The additional step below is denoted 3.5:

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (3.5) Else if this is a type-4 Summary LSA (LS type = 4), and the
        area has been configured as a stub area, discard the LSA and get
        the next one from the Link State Update Packet.  Type-4 Summary
        LSAs are not flooded into/throughout stub areas.

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, and none of router's neighbors are in states Exchange

Notes:

This whole note is regarding stub areas.

RFC 2328 is already consistent with respect to AS-external-LSAs
(LS type =5). The RFC explicitly indicates that they should be neither
sent nor received in stub areas.

But RFC 2328 seems to have some omissions with respect to type-4
Summary LSA (LS type = 4). The RFC explicitly indicates that these
LSAs should never be sent in stub areas. But it does not mention what
should be done if these LSAs are received in stub areas.

The above updates try to remedy this omission.

If the neighbor is associated with a stub area, then we should never
receive a type-4 summary LSA from that neighbor. Here are the relevant
quotes from the RFC:

Section 12.4.3.1.(Originating summary-LSAs into stub areas):

"As specified in Section 12.4.3, Type 4 summary-LSAs
(ASBR-summary-LSAs) are never originated into stub
areas."

Section 4.2. (AS external routes):

"To utilize external routing information, the path to all routers
advertising external information must be known throughout the AS
(excepting the stub areas). For that reason, the locations of
these AS boundary routers are summarized by the (non-stub) area
border routers."


This is an omission from RFC 2328.

http://www.ietf.org/mail-archive/web/ospf/current/msg06720.html

Errata ID: 3974
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Mike Dubrovsky
Date Reported: 2014-04-24
Verifier Name: Alia Atlas
Date Verified: 2014-05-12

Section 13 says:

    (6) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

    (7) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

It should say:

    (6) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

    (7) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

Notes:

The problem arises when the routing domain has two instances of LSA
with the same sequence number and the same checksum,
but with an age difference bigger than MaxAgeDiff.

The above could take place in multiple scenarios. Here are two examples:

1) There is a demand circuit somewhere in the routing domain
2) The router lost its ASBR status and therefore flushed the self-originated Type 5 LSAs
but later on gained the ASBR status back and re-originated Type 5.
If the network was partitioned, each partition can have two instances of LSA
with an age difference bigger than MaxAgeDiff.

The two instances of LSA can temporarily prevent the adjacency formation.

Consider the example below:


Topology
========


RT1 ----- RT2

Initial state:
==============
The physical link between RT1 and R2 just came up
The routers are about to form ospf adjacency.

Initial link-state databases:
=============================
R1 ospf database has LSA 10.0.0.1 age 910 seq # 0x80000001
R2 ospf database has the same LSA 10.0.0.1 age 9 seq # 0x80000001

RT1 Event Sequence:
===============

RT1 is starting to form adjacency with RT2.

1) During the Database Exchange, RT2's LSA instance is more recent because of more than 900 (MaxAgeDiff) seconds age difference (section 13.1 of RFC 2328).
2) So RT1 requests the LSA
3) RT2 sends the LSA after incrementing the age by 1 (InfTransDelay).
4) When the LSA instance arrives to RT1, it is identical (the difference is exactly 900 seconds now).

So RT1 aborts Loading according to step (6) of section 13.


Solution:
=========

Swap steps (6) and (7) of section 13.

Acee Lindem adds:
"This situation comes into play when a router views an LSA as being
more recent when the LSA is requested (via Link-State Request) but as the
same instance when the LSA is actually received."

Errata ID: 4022
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander Okonnikov
Date Reported: 2014-06-23
Verifier Name: Alia Atlas
Date Verified: 2014-06-24

Section 10.5 says:

When receiving an Hello Packet from a neighbor on a broadcast,
Point-to-MultiPoint or NBMA network, set the neighbor
structure's Neighbor ID equal to the Router ID found in the
packet's OSPF header. For these network types, the neighbor
structure's Router Priority field, Neighbor's Designated Router
field, and Neighbor's Backup Designated Router field are also
set equal to the corresponding fields found in the received
Hello Packet; changes in these fields should be noted for
possible use in the steps below. When receiving an Hello on a
point-to-point network (but not on a virtual link) set the
neighbor structure's Neighbor IP address to the packet's IP
source address.

It should say:

When receiving an Hello Packet from a neighbor on a broadcast,
Point-to-MultiPoint or NBMA network, set the neighbor
structure's Neighbor ID equal to the Router ID found in the
packet's OSPF header. For broadcast and NBMA network types, the neighbor
structure's Router Priority field, Neighbor's Designated Router
field, and Neighbor's Backup Designated Router field are also
set equal to the corresponding fields found in the received
Hello Packet; changes in these fields should be noted for
possible use in the steps below. When receiving an Hello on a
point-to-point network (but not on a virtual link) set the
neighbor structure's Neighbor IP address to the packet's IP
source address.

Notes:

This is unnecessary in case of Point-to-MultiPoint network type to hold neighbor's Router Priority, DR, and BDR values.

Errata ID: 3734
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ramakrishna DTV
Date Reported: 2013-09-23
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10

Section 8.2 says:

            The AuType specified in the packet must match the AuType
            specified for the associated area.

It should say:

            The AuType specified in the packet must match the AuType
            specified for the associated interface.

Notes:

In OSPFv2, authentication is configured per interface and not per area.
Appendix D clarifies this: "The authentication type is configurable on a per-interface
(or equivalently, on a per-network/subnet) basis."

Errata ID: 4023
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alexander Okonnikov
Date Reported: 2014-06-24
Verifier Name: Alia Atlas
Date Verified: 2014-06-24

Section 12.4.1 says:

o Otherwise, the link descriptions added to the router-LSA
depend on the OSPF interface type. Link descriptions
used for point-to-point interfaces are specified in
Section 12.4.1.1, for virtual links in Section 12.4.1.2,
for broadcast and NBMA interfaces in 12.4.1.3, and for
Point-to-MultiPoint interfaces in 12.4.1.4.

It should say:

o Otherwise, the link descriptions added to the router-LSA
depend on the OSPF interface type. Link descriptions
used for point-to-point interfaces are specified in
Section 12.4.1.1, for broadcast and NBMA interfaces in 12.4.1.2,
for virtual links in Section 12.4.1.3, and for 
Point-to-MultiPoint interfaces in 12.4.1.4.

Notes:

Incorrect references.

Errata ID: 4330
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ramakrishna Rao DTV
Date Reported: 2015-04-08
Verifier Name: Alia Atlas
Date Verified: 2015-04-09

Section 3.4 says:

        The link-state database for the backbone is shown in Figure 8.
        The set of routers pictured are the backbone routers.  Router
        RT11 is a backbone router because it belongs to two areas.  In
        order to make the backbone connected, a virtual link has been
        configured between Routers R10 and R11.

It should say:

        The link-state database for the backbone is shown in Figure 8.
        The set of routers pictured are the backbone routers.  Router
        RT11 is a backbone router because it belongs to two areas.  In
        order to make the backbone connected, a virtual link has been
        configured between Routers RT10 and RT11.

Notes:

s/R10/RT10
s/R11/RT11

Errata ID: 5041
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Adam Augustyn
Date Reported: 2017-06-13
Verifier Name: Alia Atlas
Date Verified: 2017-06-13

Section 10.2 says:

1-Way
    An Hello packet has been received from the neighbor, in
    which the router is not mentioned.  This indicates that
    communication with the neighbor is not bidirectional.

It should say:

1-WayReceived
    An Hello packet has been received from the neighbor, in
    which the router is not mentioned.  This indicates that
    communication with the neighbor is not bidirectional.

Notes:

RFC2328 defines The Neighbor state machine and it's states. One of the states is defined/named as 1-WayReceived ([Page 95] 10.3.).
1-WayReceived is also mentioned on page 84 and 98.

Pages 85 and 88 use event 1Way which should be renamed to 1-WayReceived for consistency with definition of the state.

[Page 85]
Event 1-Way forces Init state,


[Page 88]
10.2. Events causing neighbor state changes
1-Way
An Hello packet has been received from the neighbor, in
which the router is not mentioned. This indicates that
communication with the neighbor is not bidirectional.

On p. 85 after Figure 13, it says "Figure 13: Neighbor state changes (Database Exchange)
....
Event 1-Way forces Init state,
"
and Event 1-Way should be replaced with 1-WayReceived

Errata ID: 6679
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2021-09-07
Verifier Name: John Scudder
Date Verified: 2022-05-09

Section 3.4 says:

        The area border routers RT3, RT4, RT7, RT10 and RT11 condense
        the routing information of their attached non-backbone areas for
        distribution via the backbone; these are the dashed stubs that
        appear in Figure 8.  Remember that the third area has been
        configured to condense Networks N9-N11 and Host H1 into a single
        route.  This yields a single dashed line for networks N9-N11 and
        Host H1 in Figure 8.  Routers RT5 and RT7 are AS boundary
        routers; their externally derived information also appears on
        the graph in Figure 8 as stubs.


It should say:

        The area border routers RT3, RT4, RT7, RT10 and RT11 condense
        the routing information of their attached non-backbone areas for
        distribution via the backbone; these are the dashed stubs that
        appear in Figure 6.  Remember that the third area has been
        configured to condense Networks N9-N11 and Host H1 into a single
        route.  This yields a single dashed line for networks N9-N11 and
        Host H1 in Figure 8.  Routers RT5 and RT7 are AS boundary
        routers; their externally derived information also appears on
        the graph in Figure 8 as stubs.


Notes:

Incorrect figure number (8 instead 6).

Errata ID: 7112
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Renato Westphal
Date Reported: 2022-09-01
Verifier Name: John Scudder
Date Verified: 2022-09-01

Section 10.2 says:

        NegotiationDone
            The Master/Slave relationship has been negotiated, and DD
            sequence numbers have been exchanged.  This signals the
            start of the sending/receiving of Database Description
            packets.  For more information on the generation of this
            event, consult Section 10.8.

It should say:

        NegotiationDone
            The Master/Slave relationship has been negotiated, and DD
            sequence numbers have been exchanged.  This signals the
            start of the sending/receiving of Database Description
            packets.  For more information on the generation of this
            event, consult Section 10.6.

Notes:

The generation of the NegotiationDone event is specified in Section 10.6 (not Section 10.8).

(Also discussed at https://mailarchive.ietf.org/arch/msg/lsr/NZMWapi62sJuExnBZFBBMdW169k/)

Errata ID: 7756
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Lokesh Venkata Kumar Chakka
Date Reported: 2024-01-11
Verifier Name: John Scudder
Date Verified: 2024-01-11

Section A.4.5 says:

    AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
    AS boundary routers, and describe destinations external to the AS.
    For details concerning the construction of AS-external-LSAs, see
    Section 12.4.3.

It should say:

    AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
    AS boundary routers, and describe destinations external to the AS.
    For details concerning the construction of AS-external-LSAs, see
    Section 12.4.4.

Notes:

Incorrect references. Construction of AS-external-LSAs explained in Section 12.4.4. Not in 12.4.

(See also https://mailarchive.ietf.org/arch/msg/lsr/OiOvEPM2W-Mwd_QgbmJASg8bDOI/)

Status: Reported (2)

RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 7850
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Lindem
Date Reported: 2024-03-15

Section 10.7/A.3.5 says:

Section 10.7

        Each LSA specified in the Link State Request packet should be
        located in the router's database, and copied into Link State
        Update packets for transmission to the neighbor.  These LSAs
        should NOT be placed on the Link state retransmission list for
        the neighbor.  If an LSA cannot be found in the database,
        something has gone wrong with the Database Exchange process, and
        neighbor event BadLSReq should be generated.
 
Section A.3.5 

    Link State Update packets are multicast on those physical networks
    that support multicast/broadcast.  In order to make the flooding
    procedure reliable, flooded LSAs are acknowledged in Link State
    Acknowledgment packets.  If retransmission of certain LSAs is
    necessary, the retransmitted LSAs are always sent directly to the
    neighbor.  For more information on the reliable flooding of LSAs,
    consult Section 13.

It should say:

Section 10.7
        
        Each LSA specified in the Link State Request packet should be
        located in the router's database, and copied into Link State
        Update packets for transmission directly to the neighbor, 
        i.e., unicast on all interface types except point-to-point
        interfaces where all OSPF packets are sent to the address
        AllSPFRouters.  These LSAs should NOT be placed on the Link
        state retransmission list for the neighbor.  If an LSA cannot
        be found in the database, something has gone wrong with the
        Database Exchange process, and neighbor event BadLSReq should
        be generated.

Section A.3.5 
    
    Link State Update packets are multicast on those physical networks
    that support multicast/broadcast.  In order to make the flooding
    procedure reliable, flooded LSAs are acknowledged in Link State
    Acknowledgment packets.  If retransmission of certain LSAs is
    necessary, the retransmitted LSAs are always sent directly to the
    neighbor.  For more information on the reliable flooding of LSAs,
    consult Section 13. Link State Update packets are also sent
    directly to the neighbor in response to Link State Request
    packets as specified in Section 10.7.
   

Notes:

Clarify that OSPF Link State Updates sent in response to OSPF Link Requests should be unicast.

Errata ID: 7851
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Acee Lindem
Date Reported: 2024-03-15

Section 8.1 says:


        Retransmissions of Link State Update packets are ALWAYS sent
        directly to the neighbor. On multi-access networks, this means
        that retransmissions should be sent to the neighbor's IP
        address.

       

It should say:


        Retransmissions of Link State Update packets and Link State
        Update packets sent in response to Link State Request packets
        are ALWAYS sent directly to the neighbor. On multi-access
        networks, this means that retransmissions should be sent to
        the neighbor's IP address.

       

Notes:

One more place requiring clarification with respect to the Link State Update packets sent in response to Link State Request packets.

Status: Held for Document Update (5)

RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Source of RFC: ospf (rtg)

Errata ID: 3645
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Preet D'Souza
Date Reported: 2013-06-07
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-19

Section 2.1.2 says:

Figure 2: A sample Autonomous System

                                **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |

It should say:

Figure 2: A sample Autonomous System

                                **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |
               Ia|  |  |  |  |  |  |  |  |  |5 |  |  |  |  |  |  |
               Ib|  |  |  |  |  |7 |  |  |  |  |  |  |  |  |  |  |

Notes:

Notes:

section 2.1.2

Page 20, Figure 2 : A sample Autonomous System.
Two additions have been made to the orginal text which are reflected in the Corrected text.
The last two rows for interfaces Ia and Ib have been added.
The reason for the same is as explained below.

By definition of point-to-point links under OSPF, for serial interfaces defined by IP addresses, router RT6 should advertise a stub network to Ib whereas router RT10 should advertise a stub network to Ia .

Verifier's note: RFC 2328 is not wrong without the stubs links.
However, it does no harm to include them.

This table should be looked at in any future revision of this
RFC.

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

Reported By: Andrea Ceschia
Date Reported: 2010-07-29
Held for Document Update by: Stewart Bryant
Date Held: 2012-10-26

Section 3.4. says:

Table 5: Backbone distances calculated by Routers RT3 and RT4

                              dist  from   dist  from
                              RT3          RT4

                   to  Ia     20           27
                   to  Ib     15           22

It should say:

Table 5: Backbone distances calculated by Routers RT3 and RT4.

                              dist  from   dist  from
                              RT3          RT4

                   to  Ia     15           22
		   to  Ib     20           27

Notes:

From RT3 and RT4 perspective the Ia is the nearest interface while Ib is at the remote side of the link connecting RT6 to RT10.

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

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

Section 11.3 says:

The routing table entries changes that
would be caused by the addition of this virtual link are shown
in Table 14.


It should say:

N/A

Notes:

But Table 14 is exiled in another section, section 12, where it has nothing to do. I assume some processor tried to avoid splitting the table and displaced it too far.

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

Reported By: Dande Rajasekhar
Date Reported: 2009-08-19
Held for Document Update by: Stewart Bryant

Section 2.1.1 says:

Figure 1b illustrates the link-state database representation
	    of a Point-to-MultiPoint network. On the left side of the
	    figure, a Point-to-MultiPoint network is pictured. It is
	    assumed that all routers can communicate directly, except
	    for	routers	RT4 and	RT5. I3	though I6 indicate the routers'

It should say:

Figure 1b illustrates the link-state database representation
	    of a Point-to-MultiPoint network. On the left side of the
	    figure, a Point-to-MultiPoint network is pictured. It is
	    assumed that all routers can communicate directly, except
	    for	routers	RT4 and	RT5. I3	through I6 indicate the routers'

Notes:

Should be I3 *through* I6

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

Reported By: Eugene M. Kim
Date Reported: 2015-02-04
Held for Document Update by: Alia Atlas
Date Held: 2015-03-03

Section 2.1.1 says:

In NBMA mode, OSPF emulates operation over a broadcast
network: a Designated Router is elected for the NBMA
network, and the Designated Router originates an LSA for the
network. The graph representation for broadcast networks and
NBMA networks is identical. This representation is pictured
in the middle of Figure 1a.

It should say:

In NBMA mode, OSPF emulates operation over a broadcast
network: a Designated Router is elected for the NBMA
network, and the Designated Router originates an LSA for the
network. The graph representation for broadcast networks and
NBMA networks is identical. This representation is pictured
in the bottom of Figure 1a.

Notes:

The bottom, not middle, of Figure 1a depicts the identical graph representation of broadcast and NBMA networks.

Status: Rejected (11)

RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Source of RFC: ospf (rtg)

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

Reported By: Wenhu Lu
Date Reported: 2009-03-27
Rejected by: Stewart Bryant
Date Rejected: 2012-10-26

Section Appendix E says:

In the paragraph that starts with: "The above algorithm assumes that all"

                                 The algorithm also assumes that no
    network exists having an address equal to another network's
    broadcast address.

It should say:

                                 The algorithm also assumes that if
    one of the conflicting networks is of IP host mask, its LSA
    origination is suppressed. The choice of the suppressing algorithm
    again is a local decision. However, the suppressed LSA MUST be
    originated if the conflicting network becomes withdrawn.

Notes:

The current algorithm will derive an unchanged ID
if one of the conflicting networks is of IP host mask.
This will cause problems that the algorithm try to solve.

On the other hand, the perfect algorithm for
LSID collision resolution does not exist in
that a flat address space cannot accommodate
all of the overlaid supernet/subnet IDs.
For example,
route1 - 10.0.0.0/32
route2 - 10.0.0.1/32
route3 - 10.0.0.0/31
There is no way to originate 3 LSAs with distinct LSIDs.

Thus though in majority cases, LSID collision even
with host route is resolvable, the suppressing
mechanism is still inevitable.
--VERIFIER NOTES--
This text is a change that should be taken through the working group process, as it seems to modify functionality.

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

Reported By: Joel Gannett
Date Reported: 2011-08-31
Rejected by: Stewart Bryant
Date Rejected: 2011-09-02

Section 3.4 says:

                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         20         27
                   N6            16         15
                   N7            20         19
                   N8            18         18
                   N9-N11,H1     29         36
                   _________________________________
                   RT5           14         8
                   RT7           20         14

              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.

It should say:

                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         20         27
                   N6            16         15
                   N7            20         19
                   N8            18         18
                   N9-N11,H1     29         29
                   _________________________________
                   RT5           14         8
                   RT7           20         14

              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.

Notes:

The distance from RT4 to N9-N11,H1 should be changed from 36 to 29 to be consistent with the row above that, which shows the distance from RT3 to N8 and RT4 to N8 as the same value, 18. The length 18 path from RT3 to N8 is RT3-RT6-RT10-N8, while the length 18 path from RT4 to N8 is RT4-RT5-RT7-RT10-N8. The summarized N9-N11,H1 network is a distance 11 beyond that, or 29 in both cases. The length 29 path from RT3 to N9-N11,H1 is RT3-RT6-RT10-RT11-(N9-N11,H1), and the length 29 path from RT4 to N9-N11,H1 is RT4-RT5-RT7-RT10-RT11-(N9-N11,H1).
--VERIFIER NOTES--
Joel made an error in posting this erratum. He posted a corrected erratum (2953) to which the reader is referred.

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

Reported By: Preet D'Souza
Date Reported: 2013-06-07
Rejected by: Stewart Bryant
Date Rejected: 2013-09-19

Section 2.1.2 says:

                                       **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |
               

It should say:

                                    **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |
               Ia|  |  |  |  |  |  |  |  |  |5 |  |  |  |  |  |  |
               Ib|  |  |  |  |  |7 |  |  |  |  |  |  |  |  |  |  |

Notes:

section 2.1.2

Page 20, Figure 2 : A sample Autonomous System.

The interfaces Ia and Ib have not been added to the directed graph.
By definition of point-to-point links under OSPF, for serial interfaces defined by IP addresses,
router RT6 should advertise a stub network to Ib whereas router RT6 should advertise a stub network to Ia .
--VERIFIER NOTES--
The reported made an error in this submission which was
corrected in Erratum 3645

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

Reported By: Anil Chaitanya Mandru
Date Reported: 2019-01-22
Rejected by: Alvaro Retana
Date Rejected: 2019-01-28

Section 16.1 (4) says:

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.

It should say:

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.

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

Reported By: Marcelo Bustani
Date Reported: 2020-01-08
Rejected by: Alvaro Retana
Date Rejected: 2020-03-18

Section 12.4.1 says:

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.

It should say:

"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.
--VERIFIER NOTES--
A discussion on the WG list (lsr) resulted a consensus of no change needed.
https://mailarchive.ietf.org/arch/msg/lsr/FFiqi15XPunSwOV5BO1pl4o5xYY/

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

Reported By: Lokesh Venkata Kumar Chakka
Date Reported: 2024-01-11
Rejected by: John Scudder
Date Rejected: 2024-01-11

Section A.4.5 says:

Forwarding address
Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded instead to the LSA's originator (i.e., the responsible AS boundary router).

It should say:

Forwarding address
Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to a Router ID address value other than 0.0.0.0, data traffic will be forwarded to that Router instead to the LSA's originator (i.e., the responsible AS boundary router).

Notes:

Data traffic destined to the network indicated by Link State ID will be routed to that Router ID mentioned in forwarding address. If forwarding address is set to 0.0.0.0, it will be forwarded to LSA Originator itself.
--VERIFIER NOTES--
See https://mailarchive.ietf.org/arch/msg/lsr/_Xa4tym_roMmxFioFbrF3WRkKcM/

Errata ID: 2632
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Dave Cowley
Date Reported: 2010-11-13
Rejected by: Stewart Bryant
Date Rejected: 2013-01-07

Section 11. says:

    Cost
        The link state cost of the path to the destination.  For all
        paths except type 2 external paths this describes the entire
        path's cost.  For Type 2 external paths, this field describes
        the cost of the portion of the path internal to the AS. 

It should say:

    Cost
        The link state cost of the path to the destination.  For all
        paths except type 2 external paths this describes the entire
        path's cost.  For Type 1 external paths, this field describes
        the cost of the portion of the path both internal and external
        to the AS.  

Notes:

'Type 2 cost' is listed in the subsequent 'field' description for section 11 (The Routing Table Structure).
--VERIFIER NOTES--
The text is correct as written in the RFC.

Errata ID: 2952
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Joel Gannett
Date Reported: 2011-08-31
Rejected by: Stewart Bryant
Date Rejected: 2013-01-07

Section 14.1 says:

Premature aging is also be used when unexpectedly receiving self-originated
LSAs during the flooding procedure (see Section 13.4).

It should say:

Premature aging might also be used when unexpectedly receiving self-originated
LSAs during the flooding procedure (see Section 13.4).

Notes:

Change "is also be used" to "might also be used."
--VERIFIER NOTES--
The text in section 13.4 that is referenced is a case where premature aging is used.

Errata ID: 3452
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: David Jet
Date Reported: 2013-01-12
Rejected by: Stewart Bryant
Date Rejected: 2013-01-28

Section 11 says:

Multiple LSAs may
reference the destination, however a tie-breaking scheme always
reduces the choice to a single LSA.

It should say:

Multiple LSAs may
reference the same destination, however a tie-breaking scheme always
reduces the choice to a single LSA. 

Notes:

I think should add the "same" to describe it more clearly.
--VERIFIER NOTES--
Section 11 is written in terms of "the destination", and this is clearly a single destination, thus there should be no confusion with the original text.

Errata ID: 5269
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Angelos Vassiliou
Date Reported: 2018-03-01
Rejected by: Alia Atlas
Date Rejected: 2018-03-01

Section 9.1 says:

The interface is to a broadcast or NBMA network on
 which another router has been selected to be the 
Designated Router.

It should say:

The interface is connected to a broadcast or NBMA 
network on which another router has been selected 
to be the Designated Router.

Notes:


--VERIFIER NOTES--
An interface is the connection point. This minor editorial suggestion does not add significant clarity.

Errata ID: 5684
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: jonathan natale
Date Reported: 2019-04-04
Rejected by: Alvaro Retana
Date Rejected: 2019-06-28

Section 9.4 says:

These two alternatives (~=">=1 BDRs" vs. ~="no BDRs") seem (to me at
least, maybe I missed the point) to have the same outcome (~="highest
becomes BDR")--please clarify it:
If one or more of these
            routers have declared themselves Backup Designated
Router[alternative1]
            (i.e., they are currently listing themselves as Backup
            Designated Router, but not as Designated Router, in their
            Hello Packets) the one having highest Router Priority is
            declared to be Backup Designated Router.  In case of a tie,
            the one having the highest Router ID is chosen.  If no
            routers have declared themselves Backup Designated
Router[alternative2],



Moy                         Standards Track                    [Page 75]
 
RFC 2328                     OSPF Version 2                   April 1998


            choose the router having highest Router Priority, (again
            excluding those routers who have declared themselves
            Designated Router), and again use the Router ID to break
            ties.

It should say:

TBD

Notes:

It is unclear to me if a BDR should get preempted (I know the BDR should not).
--VERIFIER NOTES--
The confusion was cleared on the WG list.

Report New Errata



Advanced Search