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