RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (2)

RFC 3107, "Carrying Label Information in BGP-4", May 2001

Note: This RFC has been obsoleted by RFC 8277

Note: This RFC has been updated by RFC 6790

Source of RFC: mpls (rtg)

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

Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Verifier Name: Deborah Brungard
Date Verified: 2015-12-30

Section 2 says:

Label distribution can be piggybacked in the BGP Update message by
   using the BGP-4 Multiprotocol Extensions attribute [RFC 2283].

It should say:

Label distribution can be piggybacked in the BGP Update message by
   using the BGP-4 Multiprotocol Extensions attribute
defined in RFC 2858 [BGP-MP].

Notes:

No reference [RFC 2283] in Reference section of RFC 3107. The reference is called [BGP-MP].

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

Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Verifier Name: Deborah Brungard
Date Verified: 2016-02-11

Section 3 says:

   The label(s) specified for a particular route (and associated with
   its address prefix) must be assigned by the LSR which is identified
   by the value of the Next Hop attribute of the route.

   When a BGP speaker redistributes a route, the label(s) assigned to
   that route must not be changed (except by omission), unless the
   speaker changes the value of the Next Hop attribute of the route.

It should say:

   The label(s) specified for a particular route (and associated with
   its address prefix) must be assigned by the LSR which is identified
   by the value of the Network Address of Next Hop field of
   MP_REACH_NLRI attribute of the route.

   When a BGP speaker redistributes a route, the label(s) assigned to
   that route must not be changed (except by omission), unless the
   speaker changes the value of the Network Address of Next Hop field of
   MP_REACH_NLRI attribute of the route.

Notes:

Next Hop address for labeled routes is conveyed within MP_REACH_NLRI attribute.

Status: Held for Document Update (1)

RFC 3107, "Carrying Label Information in BGP-4", May 2001

Note: This RFC has been obsoleted by RFC 8277

Note: This RFC has been updated by RFC 6790

Source of RFC: mpls (rtg)

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

Reported By: David Lamparter
Date Reported: 2016-01-06
Held for Document Update by: Deborah Brungard
Date Held: 2016-02-11

Throughout the document, when it says:

[... section 3: ...]
   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

4. Advertising Multiple Routes to a Destination

   A BGP speaker may maintain (and advertise to its peers) more than one
   route to a given destination, as long as each such route has its own
   label(s).

   The encoding described above allows a single BGP Update message to
   carry multiple routes, each with its own label(s).

   In the case where a BGP speaker advertises multiple routes to a
   destination, if a route is withdrawn, and a label(s) is specified at
   the time of withdrawal, only the corresponding route with the
   corresponding label is withdrawn.  If a route is withdrawn, and no
   label is specified at the time of withdrawal, then only the
   corresponding unlabeled route is withdrawn; the labeled routes are
   left in place.
[...]

It should say:

-- ALTERNATE 1: require label value --

   A BGP speaker can withdraw a previously advertised route by either
   (a) advertising a new route with the same NLRI (including label) as
   the previously advertised route, or (b) listing the NLRI of the
   previously advertised route in the Withdrawn Routes field of an
   Update message.  The label information carried (as part of NLRI) in
   the Withdrawn Routes field MUST be set to the value previously
   announced.  (Of course, terminating the BGP session also withdraws
   all the previously advertised routes.)

   The binding between route and label cannot be updated to change the
   label without withdrawing the old label and sending an update with
   the new label.

[keep section 4 unchanged]

-- ALTERNATE 2: drop multiple label support --

   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same prefix as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

[remove section 4, remove capability "4" in section 5]

-- ALTERNATE 3: clarify implications of capability "4" --

[optionally, change section 3:]
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field SHOULD be set to the value previously announced.

[insert section 5.1:]
5.1. Implications of Multiple Routes Capability

   Implementing the "multiple routes" capability introduced above
   slightly changes the processing of update and withdraw messages to
   requiring an exact match on the label, i.e. including it in NLRI
   comparisons.

   To ensure interoperability, an implementation that has this
   capability SHOULD NOT send updates with different label values on a
   session whose peer does not advertise the capability.  The peer would
   in this case only hold the latest update, possibly introducing label
   oscillations.  Further, the implementation MUST process incoming
   updates and withdraws on such sessions as if their labels were
   wildcards, removing any previous routes with the same prefix.  It
   MUST NOT hold the same prefix with any but the last seen label value
   on these sessions.

Notes:

This issue was previously discussed in
https://osdir.com/ml/ietf.idr/2004-06/msg00010.html
https://osdir.com/ml/ietf.idr/2004-06/msg00018.html

Sections 3 and 4 are inherently conflicting. The conflict is:

Section 3 states a withdraw "should" be sent with a null label/BoS=1. This means it's not possible to withdraw a specific labeled route, instead all routes with the given prefix would need to be withdrawn. However, section 4 specifies exact-match behavior for processing updates and withdraws.

Also, the Section 3 text is semantically/editorially wrong in itself, saying (shortened) "withdraw [...] binding [... by] new route (and a label) with the same NLRI". However, the label is part of the NLRI; an update with the same NLRI could thus not withdraw the binding, only possibly cause it to not be selected as best path anymore by updating attributes.

I have not checked what other implementations do; Quagga (which only implements this as route reflector):
- does not implement SAFI 4, but applies the behavior on SAFI 128 (VPN)
- does not advertise capability 4
- excludes the label value from all comparisons
- will only keep the last label value received
- will set the label on withdraws to all zeroes (ignoring the recommended value)

Note that, as with Quagga, this also affects BGP-VPN implementations since these essentially inherit the behavior. Also note that the "Multiple Routes Capability" is global over all AFI/SAFI pairs.


P.S.: Out of curiosity / for IDR mailing list: for anyone implementing 3107 or 4364: does your implementation include/advertise the "multiple routes" capability?

Status: Rejected (3)

RFC 3107, "Carrying Label Information in BGP-4", May 2001

Note: This RFC has been obsoleted by RFC 8277

Note: This RFC has been updated by RFC 6790

Source of RFC: mpls (rtg)

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

Reported By: Bruno Decraene
Date Reported: 2010-07-07
Rejected by: Adrian Farrel
Date Rejected: 2010-08-20

Section 5 says:

"A BGP speaker should not advertise this capability to another BGP speaker unless there is a Label Switched Path (LSP) between the two speakers."

It should say:

"An eBGP speaker should not advertise this capability to another eBGP speaker unless there is a Label Switched Path (LSP) or layer two interface between the two speakers."

Or just remove completely that sentence.

Notes:

1) :s/BGP/eBGP
An iBGP router should be able to set up an internal BGP session for AFI 1 / SAFI 4 toward a Route Reflector even if the Route Reflector is not capabble of forwarding MPLS packets (This case is even described in the section 2 of the RFC)

2) + layer two interface
If both router are connected by a direct (sub)interface, they should be able to exchange MPLS packets even if there is no LSP between them.

3) Remove the sentence
AFAIK, the point is now better addressed by draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt
--VERIFIER NOTES--
After discussions with the document author on the MPLS mailing list:

- The EBGP/IBGP distinction is not relevant here, as this does not properly
capture the notion of whether a BGP speaker is in the data path.

- The ability to send an MPLS packet from one router to another does not
necessarily depend on there being either a sequence of MPLS routers
between them or on there being an L2 connection between them. There might
be an L3 tunnel, for example.

Furthermore, we feel that no confusion has arisen as the result of the current text so that there is no harm in leaving it as it stands.

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

Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Rejected by: Deborah Brungard
Date Rejected: 2016-02-11

Section 3 says:

   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

It should say:

   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of
   an MR_UNREACH_NLRI attribute of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x000001.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

Notes:

1. Labeled routes are withdrawn by virtue of MR_UNREACH_NLRI attribute.
2. Label value should be set to 0x00000 with BoS=1. Value 0x800000 was carried from draft, where BoS was high-order bit.
--VERIFIER NOTES--
Rejected as potential to cause interoperability issues.

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

Reported By: Alexander Okonnikov
Date Reported: 2015-10-13
Rejected by: Deborah Brungard
Date Rejected: 2016-02-11

Section 5 says:

   A BGP speaker that is capable of handling multiple routes to a
   destination (as described above) should use the Capabilities Optional
   Parameter, as defined in [BGP-CAP], to inform its peers about this
   capability.  The value of this capability is 4.

It should say:

   A BGP speaker that is capable of handling multiple routes to a
   destination (as described above) should use the Capabilities Optional
   Parameter, as defined in [BGP-CAP], to inform its peers about this
   capability.  This capability is advertised using the Capability Code
   4 and Capability Length 0.

Notes:

To remove confusion what word value means - Capability Value or value of Capability Code.
Also, format of multiple routes capability is not described, so length = 0 is assumed.
--VERIFIER NOTES--

Report New Errata



Advanced Search