[mpls] [Errata Held for Document Update] RFC3107 (4582)

[RFC Errata System <[e-mail]>]

The following errata report has been held for document update 
for RFC3107, "Carrying Label Information in BGP-4". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3107&eid=4582

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: David Lamparter <[e-mail]>
Date Reported: 2016-01-06
Held by: Deborah Brungard (IESG)

Section: GLOBAL

Original Text
-------------
[... 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.
[...]

Corrected Text
--------------
-- 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?

--------------------------------------
RFC3107 (draft-ietf-mpls-bgp4-mpls-04)
--------------------------------------
Title               : Carrying Label Information in BGP-4
Publication Date    : May 2001
Author(s)           : Y. Rekhter, E. Rosen
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG