RFC Errata
Found 5 records.
Status: Verified (1)
RFC 4760, "Multiprotocol Extensions for BGP-4", January 2007
Note: This RFC has been updated by RFC 7606
Source of RFC: idr (rtg)
Errata ID: 1573
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: yakov rekhter
Date Reported: 2008-10-13
Verifier Name: Stewart Bryant
Date Verified: 2012-02-20
Section 4 says:
Address Family Identifier (AFI):
This field in combination with the Subsequent Address Family
Identifier field identifies the set of Network Layer protocols
to which the address carried in the Next Hop field must belong,
the way in which the address of the next hop is encoded, and
the semantics of the Network Layer Reachability Information
that follows. If the Next Hop is allowed to be from more than
one Network Layer protocol, the encoding of the Next Hop MUST
provide a way to determine its Network Layer protocol.
Presently defined values for the Address Family Identifier
field are specified in the IANA's Address Family Numbers
registry [IANA-AF].
Subsequent Address Family Identifier (SAFI):
This field in combination with the Address Family Identifier
field identifies the set of Network Layer protocols to which
the address carried in the Next Hop must belong, the way in
which the address of the next hop is encoded, and the semantics
of the Network Layer Reachability Information that follows. If
the Next Hop is allowed to be from more than one Network Layer
protocol, the encoding of the Next Hop MUST provide a way to
determine its Network Layer protocol.
It should say:
Address Family Identifier (AFI):
This field in combination with the Subsequent Address Family
Identifier field identifies the semantics of Withdrawn Routes
Network Layer Reachability Information carried in the attribute.
Presently defined values for the Address Family Identifier
field are specified in the IANA's Address Family Numbers
registry [IANA-AF].
Subsequent Address Family Identifier (SAFI):
This field in combination with the Address Family Identifier
field identifies the semantics of Withdrawn Routes Network
Layer Reachability Information carried in the attribute.
Notes:
This original text refers to the field (Next Hop) that is not present in
the attribute MP_UNREACH_NLRI. Therefore the original text is not applicable.
Status: Held for Document Update (4)
RFC 4760, "Multiprotocol Extensions for BGP-4", January 2007
Note: This RFC has been updated by RFC 7606
Source of RFC: idr (rtg)
Errata ID: 1778
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-05-05
Held for Document Update by: Stewart Bryant
Section 3 says:
An UPDATE message SHOULD NOT include the same address prefix (of the same <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The processing of an UPDATE message in this form is undefined.
It should say:
An UPDATE message SHOULD NOT include the same address prefix (of the same <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES field, Network Layer Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The processing of an UPDATE message in this form is undefined.
Errata ID: 3849
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-12-25
Held for Document Update by: Stewart Bryant
Date Held: 2014-03-02
Section 3 says:
The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the router that SHOULD be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message.
It should say:
The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the router that SHOULD be used as the next hop to the destinations listed in the NLRI field of the MP_REACH_NLRI attribute in the UPDATE message.
Notes:
There is no attribute named "MP_NLRI".
Whilst this should be looked at in any update of the text, the correct term is clear from the context.
Errata ID: 3848
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-12-23
Held for Document Update by: Stewart Bryant
Date Held: 2014-03-02
Section 3 says:
(b) to permit a router to advertise the Network Layer address of the
router that should be used as the next hop to the destinations
listed in the Network Layer Reachability Information field of the
MP_NLRI attribute.
It should say:
(b) to permit a router to advertise the Network Layer address of the
router that should be used as the next hop to the destinations
listed in the Network Layer Reachability Information field of the
MP_REACH_NLRI attribute.
Notes:
There is no attribute named "MP_NLRI".
Whilst this should be corrected in any revision of the text, the correct term is clear from the context.
Errata ID: 5120
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dale Worley
Date Reported: 2017-09-23
Held for Document Update by: Alvaro Retana
Date Held: 2017-11-06
Section global says:
section 3: ... each NLRI ... [2 occurrences] section 5: The Network Layer Reachability information is encoded as ...
It should say:
... each NLRI item ... When the Subsequent Address Family Identifier field is set to one of the values defined in this document (1 or 2), the NLRI field is encoded as ...
Notes:
The text in section 3 makes it clear that the NLRI encoding in section 5 is only
specified for SAFI 1 and 2, but the text in section 5 does not state this. This tends
to cause readers to believe that section 5 applies to any SAFI. (See, e.g.,
draft-ietf-mpls-rfc3107bis.) (However, other RFCs do specify similar encoding structures
for some other SAFIs; see, e.g., RFC 3107.)
The wording "each NLRI" is incorrect, as NLRI is a field and there is only one of them in an UPDATE message.