RFC Errata
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.