Subject: [mpls] [Technical Errata Reported] RFC3107 (4582)

From: RFC Errata System <[email-masked]>
Date: Wed, 6 Jan 2016 03:05:54 -0800 (PST)

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: David Lamparter <[email-masked]>

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?

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
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

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 6 Jan 2016 17:52:55 -0500

A proposed 3107bis draft will be available shortly.  The draft will deal 
with the issues you've raised, as well as other issues with RFC3107.

Meanwhile ...

As far as I know, no one has ever implemented Capability 4, and I 
believe 3107bis should propose to deprecate it.

Section 4 of RFC3107 is intended to apply only when Capability 4 has 
been used.  So you can just ignore that section.

However, I think it is perfectly valid to use add-paths to advertise two 
routes whose respective NLRIs have different labels but the same prefix. 
This is like having two different paths to the same prefix, and each 
path may have a different label.

Bestpath selection should choose the best path to a given prefix, 
without considering the labels.

Section 3 is,  as you observe,  very sloppy in its use of the terms 
"NLRI" and "Prefix".
> I have not checked what other implementations do;
You're very brave ;-)
> Quagga (which only implements this as route reflector):
I can't comment on whether your implementation needs SAFI-4 support, but 
the 3107bis draft will make it clear that most of the draft applies to 
SAFI-128 as well.
> - does not advertise capability 4
Good.
> - excludes the label value from all comparisons
Right.
> - will only keep the last label value received
I assume you mean this to be in the context of a given prefix, as 
advertised on a given BGP session.  But remember that if add-paths is 
being used to advertise two paths to a given prefix, each path may have 
a different label.
> - will set the label on withdraws to all zeroes (ignoring the recommended value)
When you receive a withdraw, the best strategy might be to ignore the 
value of the label field.  When sending a withdraw, setting the label 
field to all zeroes is risking an interoperability problem. It might be 
safer to set the value to 0x800000, as RFC3107 says.