Signaling Alternative Labels for BGP Prefixes

A single MPLS label or a label stack is advertised along with an NLRI belonging to labeled address families such as Labeled Unicast , VPN , etc. In certain topologies, it would be useful to advertise one or more additional, alternative labels associated with the same NLRI. This document proposes a method to encode and send such alternative labels using BGP Next Hop Dependent Characteristic (NHC) attribute .

The BGP Next Hop Dependent Characteristics attribute (NHC attribute) is an optional, transitive BGP path attribute defined in consisting of the Next Hop address and a list of Characteristic TLVs among other things. A new Characteristic TLV Type called the Alternative-Label Characteristic is used to encode alternative labels for an NLRI. It is also referred to as Alt-Label Characteristic in this document. The encoding of the Alt-Label Characteristic TLV is shown below:

Assigned by IANA to be [TBD]. Length of the Characteristic Value - set to 6. 1 octet representing the type of alternative label. This field is assigned values from a new IANA registry called "BGP Alternative-Label Label Types". 2 octets reserved field for future use; MUST be set to 0 when sending and SHOULD be ignored when received. 3 octets encoding one MPLS Label . This document specifies Label Type 1, called "Extra-domain Label", described in later sections. Future documents may specify newer Label Types and allocate them in the IANA registry mentioned above. As depicted above, each Characteristic TLV supports encoding of a single label only i.e., label stack encoding is not supported.

Unless specified otherwise in this document, advertisement and receive processing of the NHC attribute and the Alt-Label Characteristic TLVs follow the general behavior outlined in . This section specifies the general behavior for processing any Label Type. This behavior MAY be overridden for specific Label Types by documents that specify those Types.

A router that originates a route may attach the NHC attribute containing one or more Alt-Label Characteristic TLVs. More than one such TLV may contain the same Label Type but with different label values.

On the receiving router:

any valid label in the received Alt-Label Characteristic TLV may be installed in the corresponding route forwarding entries as the outgoing label.
if more than one valid label is received, it is a matter of local policy to decide which of those labels are installed under what conditions.
if the received route is re-advertised by the router without changing the Next Hop, the received Alt-Label Characteristic TLVs MUST be re-advertised without modification.
if the received route is re-advertised by the router setting itself as the new Nexthop:
- all received Alt-Label Characteristic TLVs SHOULD be removed from the NHC attribute.
- one or more new labels MAY be allocated for the route locally, and MAY be advertised encoded in Alt-Label Characteristic TLVs within the NHC attribute.

This document defines a new label type called "Extra-domain Label" which is assigned a value of Label Type 1. This label type indicates that any traffic destined to that label will be forwarded to one or more next hops that belong to domain(s) that are different from where the traffic ingressed. This behavior holds true whether such next hops are part of a prefix's bestpaths or backup paths or any other alternate paths. What constitutes a "domain" is outside the scope of this document, and is defined based on local policy or configuration. One simple instance of a domain is an Autonomous System, in which case, as an example, an extra-domain label L that receives traffic from ASN-X would switch that traffic towards ASNs other than ASN-X. Other examples of a domain may be an IGP area within a single Autonomous System, or a domain spanning multiple Autonomous Systems, and so on.

A router may allocate one or more extra-domain labels in addition to a "primary" label associated with the same route. The primary label is encoded as part of the NLRI (for example, etc) while the extra-domain labels would be encoded using the Alt-Label Characteristic TLVs.

On the receiving router:

the extra-domain label may be installed in the corresponding route forwarding entry as the outgoing label. Specifically this label can be installed when the route is installed as the backup path or the FRR path of a prefix. This is so that any traffic forwarded towards that label in the event of bestpaths failure will not loop back to this router.
if the received route is re-advertised without changing the Nexthop, the received label(s) MUST be re-advertised without modification.
if the received route is re-advertised by the router after setting itself as the new Nexthop:
- the received label(s) MUST be removed from the NHC Alt-Label Characteristic TLV(s).
- one or more new extra-domain labels MAY be allocated locally and advertised by encoding them in Alt-Label Characteristic TLVs.

This section illustrates an use case where allocating an addtional label for a prefix and advertising it using the Alt-Label Characteristic TLV within the NHC attribute can help break a continuous loop of advertisements.

The diagram depicts two Border Routers (BR1, BR2) peering with each other, as well as two PEs (PE3, PE4). PE3 originates some VPN routes which are advertised to BR1 and BR2, which in turn advertise them to PE4. PE3 originates VPN routes and advertises them to BR1 and BR2. Each Border Router considers its direct path to PE3 as the bestpath and selects the other Border Router as its backup path. Initially, BR1 receives the primary path from PE3 with label L3. Local Label L11 is allocated with context {(PE3, L3)}. This is advertised to BR2 and PE4. Similarly, BR2 receives the primary path from PE3 with label L3. Local Label L21 is allocated with context {(PE3, L3)}. This is advertised to BR1 and PE4. BR1 receives the update from BR2 and selects it to be the backup path. It now allocates a new local label L12 with context {(PE3, L3), (BR2, L21)}. This is advertised to BR2 and PE4. BR2 receives the new update from BR1. It now allocates a new local label L22 with context {(PE3, L3), (BR1, L12)}. This is advertised to BR1 and PE4. BR1 receives the new update from BR2. It now allocates a new local label L13 with context {(PE3, L3), (BR2, L22)}. This is advertised to BR2 and PE4. BR2 receives the new update from BR1. It now allocates a new local label L23 with context {(PE3, L3), (BR1, L13)}. This is advertised to BR2 and PE4. The above operations continue forever resulting in a continuous loop of label allocations and advertisements. The solution to the above problem involves each Border Router allocating an additional label whose context points to only the bestpath without including any backup path information. Accordingly, the modified steps are described below: BR1 receives the update from BR2 and selects it to be the backup path. It now allocates a new local label L12 with context {(PE3, L3), (BR2, L21)}. In the route advertisement to BR2 and PE4, label L12 is encoded as part of the NLRI while label L11 is encoded as an extra-domain label in Alt-Label Characteristic TLV. BR2 receives the update from BR1 and selects it to be the backup path. It now allocates a new local label L22 with context {(PE3, L3), (BR2, L11)}. Note that BR2 uses the extra-domain label L11 received in the Alt-Label Characteristic TLV when allocating its new local label L22. In the route advertisement to BR1 and PE4, label L22 is encoded as part of the NLRI while label L21 is encoded as an extra-domain label in Alt-Label Characteristic TLV. BR1 receives the new update from BR2. It now sees the label L21 in the Alt-Label Characeristic TLV and determines no need for a change in the already allocated label (L12) context which is {(PE3, L3), (BR2, L21)}. Hence there is no new route advertisement.

In case of any errors encountered while processing Alt-Label Characteristic TLV, the error SHOULD be logged for the attention of the operator. Unless otherwise specified, the error handling specified for NHC attribute in should be followed. If the Length of the Alt-Label Characteristic TLV is not 6, then the TLV MUST be parsed according to the encoded length and MUST be ignored. Subsequent TLVs of the NHC attribute SHOULD continue to be parsed normally. It is not an error to receive an unrecognized Label Type value in this Characteristic TLV. Such labels MUST be processed according to . If more than one instance of a TLV with the exact same Label Type and Label value fields are received, then all but the first instance MUST be ignored. It is not an error to receive more than one TLV instance with the same Label Type but different Label values. One or more of those labels MAY be used locally, and all such labels MUST be considered for further propagation subject to the behavior specified in .

When receving the Extra-domain Label Type, if syntactic or semantic errors are encountered while parsing the Label field, then only that TLV MUST be ignored. It is not an error to receive more than one extra-domain label. One or more of those labels MAY be used locally, and all such labels MUST be considered for further propagation subject to the behavior specified in . The exact conditions under which a particular label may be selected for installation in local route forwarding entries is beyond the scope of this document and left to the local application.

This document requests IANA to allocate a new type code in the in the "BGP Next Hop Dependent Characteristic Codes" registry to represent "Alternative-Label Characteristic". This document requests IANA to create a new registry called "BGP Alternative-Label Label Types" with the following initial allocations. The remainder of the values in the registry are to be allocated based on a First Come, First Served policy.

The security considerations of the base NHC attribute described in continues to apply. The labels signaled using the new Alternative-Label Characteristic TLV is tightly associated with the Next Hop signaled in the NHC attribute. If this consistency is not maintained, intentionally or otherwise, it could lead to traffic mis-direction or blackholing. An implementaion MAY provide a local configuration option to disable installation and propagation of such received labels for specific address-families, specific routes, etc.