RFC 8277

Using BGP to Bind MPLS Labels to Address Prefixes

📅 published October 2017, from ietf

Okay bestie, this RFC is titled Using BGP to Bind MPLS Labels to Address Prefixes 🎀 It's RFC 8277, written by E. Rosen from Juniper Networks, Inc. 💅 It's a Standards Track document, dated October 2017, with ISSN 2070-1721. The big tea ☕: it obsoletes RFC 3107 💀, so this one replaces it. The title block doesn't list any Updates.

Abstract ✨

Okay so this doc is all about a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels, organized as a contiguous part of a label stack) to a specified address prefix 🦋 The way you do it is by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s), and whose Next Hop field identifies the node where that prefix is bound to those label(s). And yes, this doc obsoletes RFC 3107 🌸

Status of This Memo 📜

This is an Internet Standards Track document. 🔥

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🫶

Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc8277 🧚

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 🙈

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Using BGP to Bind an Address Prefix to One or More MPLS
    Labels  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.  Multiple Labels Capability  . . . . . . . . . . . . . . .   6
  2.2.  NLRI Encoding When the Multiple Labels Capability Is
        Not Used  . . . . . . . . . . . . . . . . . . . . . . . .   8
  2.3.  NLRI Encoding When the Multiple Labels Capability Is Used  10
  2.4.  How to Explicitly Withdraw the Binding of a Label to a
        Prefix  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  2.5.  Changing the Label That Is Bound to a Prefix  . . . . . .  13
3.  Installing and/or Propagating SAFI-4 or SAFI-128 Routes . . .  14
  3.1.  Comparability of Routes . . . . . . . . . . . . . . . . .  14
  3.2.  Modification of Label(s) Field When Propagating . . . . .  14
    3.2.1.  When the Next Hop Field Is Unchanged  . . . . . . . .  14
    3.2.2.  When the Next Hop Field Is Changed  . . . . . . . . .  15
4.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . . . .  16
5.  Relationship between SAFI-4 and SAFI-1 Routes . . . . . . . .  18
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  22
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1. Introduction ✨

[RFC3107] specifies encodings and procedures for using BGP to indicate that a particular router has bound either a single MPLS label or a sequence of MPLS labels to a particular address prefix. (A sequence of labels would be organized as a contiguous part of an MPLS label stack, as specified in [RFC3031] and [RFC3032].) This is done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s), and whose Next Hop field identifies the node where that prefix is bound to those label(s). Each such UPDATE also advertises a path to the specified prefix via the specified next hop. 🦋

Although there are tons of implementations and deployments of [RFC3107], there are a bunch of issues with it that have impeded interoperability in the past and may potentially impede interoperability in the future 😭

  • Although [RFC3107] specifies an encoding that allows a sequence of MPLS labels (rather than just a single label) to be bound to a prefix, it does not specify the semantics of binding a sequence of labels to a prefix.
  • Many implementations of [RFC3107] assume that only one label will be bound to a prefix, and cannot properly process a BGP UPDATE message that binds a sequence of labels to a prefix. Thus, an implementation attempting to provide this feature is likely to experience problems interoperating with other implementations.
  • The procedures in [RFC3107] for withdrawing the binding of a label or sequence of labels to a prefix are not specified clearly and correctly.
  • [RFC3107] specifies an optional feature, known as "Advertising Multiple Routes to a Destination", that, to the best of the author's knowledge, has never been implemented as specified. The functionality this feature was meant to provide can be, and has been, implemented in a different way using the procedures of [RFC7911], which didn't exist yet when [RFC3107] was written. In [RFC3107], this feature was controlled by a BGP Capability Code that has never been implemented and is now deprecated; see Section 6.
  • It's possible for a BGP speaker to receive two BGP UPDATEs that advertise paths to the same address prefix, where one UPDATE binds a label (or sequence of labels) to the prefix and the other does not. [RFC3107] is silent on how the presence of two such UPDATEs impacts the BGP decision process, and it doesn't say explicitly whether one or the other or both of these UPDATEs should be propagated. This has led different implementations to handle this situation in different ways. 💀
  • Much of [RFC3107] applies to the VPN-IPv4 ([RFC4364]) and VPN-IPv6 ([RFC4659]) address families, but those address families are not mentioned in it.

This document replaces and obsoletes [RFC3107]. It defines a new BGP Capability to be used when binding a sequence of labels to a prefix, and by using this Capability, the interoperability problems mentioned above can be avoided 💖 This document also removes the unimplemented "Advertising Multiple Routes to a Destination" feature (see Section 4 of [RFC3107]), while specifying how to use [RFC7911] to provide the same functionality. It also covers how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but don't bind labels to it. However, for backwards compatibility, it declares most of these interactions to be matters of local policy.

The places where this specification differs from [RFC3107] are marked in the text. It is believed that implementations that conform to the current document will interoperate correctly with existing deployed implementations of [RFC3107]. 🫶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 👑

2. Using BGP to Bind an Address Prefix to One or More MPLS Labels 🦋

BGP may be used to advertise that a particular node (call it N) has bound a particular MPLS label, or a particular sequence of MPLS labels (organized as a contiguous part of an MPLS label stack), to a particular address prefix. You do this by sending a Multiprotocol BGP UPDATE message, meaning an UPDATE message with an MP_REACH_NLRI attribute as specified in [RFC4760]. The Network Address of Next Hop field of that attribute contains an IP address of node N. The label(s) and the prefix are encoded in the Network Layer Reachability Information (NLRI) field of the MP_REACH_NLRI. The encoding of the NLRI field is specified in Sections 2.2 and 2.3. 💅

If the prefix is an IPv4 address prefix or a VPN-IPv4 ([RFC4364]) address prefix, the Address Family Identifier (AFI) of the MP_REACH_NLRI attribute is set to 1. If the prefix is an IPv6 address prefix or a VPN-IPv6 prefix ([RFC4659]), the AFI is set to 2. 🌈

If the prefix is an IPv4 address prefix or an IPv6 address prefix, the Subsequent Address Family Identifier (SAFI) field is set to 4. If the prefix is a VPN-IPv4 address prefix or a VPN-IPv6 address prefix, the SAFI is set to 128. ⭐

The use of SAFI 4 or SAFI 128 when the AFI is other than 1 or 2 is outside the scope of this document. 🙈

This document does not specify the format of the Network Address of Next Hop field of the MP_REACH_NLRI attribute. That format depends on a number of factors and is discussed in several other RFCs: see [RFC4364], [RFC4659], [RFC4798], and [RFC5549]. 🧚

There are a variety of applications that use alternative methods of using BGP to advertise MPLS label bindings: see, e.g., [RFC7432], [RFC6514], or [TUNNEL-ENCAPS]. The method described in the current document is not claimed to be the only way of using BGP to advertise MPLS label bindings. Deciding which method to use for which application is outside the scope of the current document. 🍓

In the rest of this document, we'll use the term "SAFI-x UPDATE" to refer to a BGP UPDATE message containing an MP_REACH_NLRI attribute or an MP_UNREACH_NLRI attribute ([RFC4760]) whose SAFI field contains the value x. ✨

This document defines a BGP Optional Capabilities parameter ([RFC5492]) known as the Multiple Labels Capability. 🎀

  • Unless this Capability is sent on a given BGP session by both of that session's BGP speakers, a SAFI-4 or SAFI-128 UPDATE message sent on that session from either speaker MUST bind a prefix to only a single label and MUST use the encoding of Section 2.2.
  • If this Capability is sent by both BGP speakers on a given session, an UPDATE message on that session, from either speaker, MUST use the encoding of Section 2.3 and MAY bind a prefix to a sequence of more than one label.

The encoding of the Multiple Labels Capability is specified in Section 2.1. 💜

Procedures for explicitly withdrawing a label binding are given in Section 2.4. Procedures for changing the label(s) bound to a given prefix by a given node are given in Section 2.5. 🔥

Procedures for propagating SAFI-4 and SAFI-128 UPDATEs are discussed in Section 3. 🌸

When a BGP speaker installs and propagates a SAFI-4 or SAFI-128 UPDATE, and if it changes the value of the Network Address of Next Hop field, it must program its data plane appropriately. This is discussed in Section 4. 💖

2.1. Multiple Labels Capability ✨

okay bestie, so [RFC5492] is where the "Capabilities Optional Parameter" lives 💅. A BGP speaker can pop one of these into its BGP OPEN message. It's a triple: a one-octet Capability Code, a one-octet Capability length, and a variable-length Capability Value 🎀.

This document makes a Capability Code called the Multiple Labels Capability code, and IANA assigned it value 8 🦋. (This Capability Code is brand new in this document and does not show up in [RFC3107].)

Now the important part 😭. If a BGP speaker hasn't sent the Multiple Labels Capability in its BGP OPEN message on a particular session, OR it hasn't received the Multiple Labels Capability in its peer's OPEN message on that session, then that speaker MUST NOT send any UPDATE on that session that binds more than one MPLS label to any given prefix 🙅‍♀️. And when it advertises a single label bound to a prefix, it MUST use the encoding in Section 2.2 💖.

The value field of the Multiple Labels Capability (shown in Figure 1) is one or more triples, and each triple is four octets 🧚. The first two octets are an AFI value, the third is a SAFI value, and the fourth is a Count. For a triple like <AFI, SAFI, Count>, the Count is the max number of labels the sending speaker can process in a received UPDATE of that AFI/SAFI. If the Count is 255, there's no limit on how many labels can be processed in a received UPDATE of that AFI/SAFI 🌈.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              AFI              |    SAFI       |    Count      ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~              AFI              |    SAFI       |    Count      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 1: Value Field of Multiple Labels Capability

Any implementation that sends a Multiple Labels Capability MUST be able to support at least two labels in the NLRI. However, there may be deployment scenarios where a larger number of labels is needed 🍓.

If the Capability has more than one triple with a given AFI/SAFI, all but the first MUST be ignored 🙈.

A triple of the form <AFI=x, SAFI=y, Count=0> or <AFI=x, SAFI=y, Count=1> MUST NOT be sent. If one is received, it MUST be ignored 💀.

A Multiple Labels Capability whose length is not a multiple of four MUST be considered to be malformed. Not it 🚫.

"Graceful Restart Mechanism for BGP" [RFC4724] describes a procedure that lets routes learned over a BGP session stay put when the session fails and then restarts 🔄. This procedure needs the entire RIB to be transmitted when the session restarts. So if the Multiple Labels Capability for a given AFI/SAFI was exchanged on the failed session but hasn't been exchanged on the restarted one, then any prefixes advertised in that AFI/SAFI with multiple labels MUST be explicitly withdrawn 😤. Same energy for the label count: if the maximum label count (specified in the Capability for a given AFI/SAFI) gets reduced, any prefixes advertised with more labels than are valid for the current session MUST be explicitly withdrawn 🧹.

"Accelerated Routing Convergence for BGP Graceful Restart" [Enhanced-GR] describes another procedure that keeps routes learned over a given BGP session around when the session fails and restarts ⚡. These procedures MUST NOT be applied if either of the following conditions hold:

  • The Multiple Labels Capability for a given AFI/SAFI had been exchanged prior to the restart but has not been exchanged on the restarted session.
  • The Multiple Labels Capability for a given AFI/SAFI had been exchanged with a given Count prior to the restart but have been exchanged with a smaller count on the restarted session.

If either of these conditions hold, the complete set of routes for the given AFI/SAFI MUST be exchanged 🫶.

If a BGP OPEN message contains multiple copies of the Multiple Labels Capability, only the first copy is significant, and subsequent copies MUST be ignored 👑.

Okay, this is the big combo moment 🔥. If (a) a BGP speaker has sent the Multiple Labels Capability in its BGP OPEN message for a particular session, (b) it has received the Multiple Labels Capability in its peer's BGP OPEN message for that session, and (c) both Capabilities specify AFI/SAFI x/y, then when it uses an UPDATE of AFI x and SAFI y to advertise the binding of a label or a sequence of labels to a given prefix, it MUST use the encoding of Section 2.3. That encoding MUST be used even if only one label is being bound to a given prefix ✨.

If both BGP speakers on a session have sent the Multiple Labels Capability, but AFI/SAFI x/y isn't specified in both Capabilities, then UPDATEs of AFI/SAFI x/y on that session MUST use the encoding of Section 2.2, and those UPDATEs can only bind one label to a prefix 🙃.

A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a given prefix than its peer is capable of receiving, as specified in the Multiple Labels Capability sent by that peer 🤏. And if a BGP speaker receives an UPDATE that binds more labels to a given prefix than it's prepared to receive (as announced in its own Multiple Labels Capability), the BGP speaker MUST apply the "treat-as-withdraw" strategy of [RFC7606] to that UPDATE 🫣.

Notwithstanding how many labels a BGP speaker has claimed it can receive, its peer MUST NOT attempt to send more labels than can be properly encoded in the NLRI field of the MP_REACH_NLRI attribute. Please note there's only a limited amount of space in the NLRI field for labels, bestie 📏:

  • per [RFC4760], the size of this field is limited to 255 bits (not 255 octets), including the number of bits in the prefix;
  • in a SAFI-128 UPDATE, the prefix is at least 64 bits long and may be as long as 192 bits (e.g., in a VPN-IPv6 host route).

2.2. NLRI Encoding When the Multiple Labels Capability Is Not Used 🌸

If the Multiple Labels Capability hasn't been both sent and received on a given BGP session, then in a BGP UPDATE on that session whose MP_REACH_NLRI attribute contains one of the AFI/SAFI combinations specified in Section 2, the NLRI field is encoded as shown in Figure 2 🦋:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length     |                 Label                 |Rsrv |S|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Prefix                               ~
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: NLRI with One Label

Here's the breakdown 🧠:

  • Length: The Length field is a single octet, and it specifies the length in bits of the remainder of the NLRI field.

Note that the length will always be the sum of 20 (number of bits in Label field), plus 3 (number of bits in Rsrv field), plus 1 (number of bits in S field), plus the length in bits of the prefix.

In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix length will be 32 bits or less. In an MP_REACH_NLRI attribute whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less. In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will be 96 bits or less if the AFI is 1 and will be 192 bits or less if the AFI is 2.

As specified in [RFC4760], the actual length of the NLRI field will be the number of bits specified in the Length field, rounded up to the nearest integral number of octets.

  • Label: The Label field is a 20-bit field containing an MPLS label value (see [RFC3032]) 🏷️.
  • Rsrv: This 3-bit field SHOULD be set to zero on transmission and MUST be ignored on reception.
  • S: This 1-bit field MUST be set to one on transmission and MUST be ignored on reception.

Note that the UPDATE message doesn't just advertise the binding between the prefix and the label. It also advertises a path to the prefix via the node identified in the Network Address of Next Hop field of the MP_REACH_NLRI attribute 🗺️.

[RFC3107] requires that if only a single label is bound to a prefix, the S bit must be set. If the S bit isn't set, [RFC3107] specifies that additional labels will appear in the NLRI. However, some implementations assume the NLRI will contain only a single label, so they don't check the setting of the S bit 🙄. The procedures in this document will interwork with those implementations. As long as the Multiple Labels Capability isn't sent and received by both BGP speakers on a given BGP session, this document REQUIRES that only one label be specified in the NLRI, that the S bit be set on transmission, and that it be ignored on reception 🫶.

If the procedures of [RFC7911] are being used, a four-octet "path identifier" (as defined in Section 3 of [RFC7911]) is part of the NLRI and precedes the Length field 🆔.

2.3. NLRI Encoding When the Multiple Labels Capability Is Used 💖

Okay, bestie, this is where it gets spicy 🌶️. If the Multiple Labels Capability has been both sent and received on a given BGP session, then in a BGP UPDATE on that session whose MP_REACH_NLRI attribute contains one of the AFI/SAFI combinations from Section 2, the NLRI field is encoded like Figure 3 shows ✨

   0                   1                   2                     3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+
  |    Length     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Label                 |Rsrv |S~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                 Label                 |Rsrv |S|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Prefix                               ~
  ~                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: NLRI with Multiple Labels
  • Length:

The Length field is a single octet 🧁. It tells you the length in bits of the rest of the NLRI field.

Note that for each label, the length goes up by 24 bits (20 bits in the Label field, plus 3 bits in the Rsrv field, plus 1 S bit) 🎀.

In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix length will be 32 bits or less. In one whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less. In one whose SAFI is 128, the prefix will be 96 bits or less if the AFI is 1, and 192 bits or less if the AFI is 2 🌈.

As specified in [RFC4760], the actual length of the NLRI field will be the number of bits in the Length field, rounded up to the nearest whole number of octets 🦋.

  • Label:

The Label field is a 20-bit field holding an MPLS label value (see [RFC3032]) 💜.

  • Rsrv:

This 3-bit field SHOULD be set to zero on transmission and MUST be ignored on reception 🌸.

  • S:

In all labels except the last one (that is, every label except the one right before the prefix), the S bit MUST be 0. In the last label, the S bit MUST be 1 👑.

Note that if you forget to set the S bit in the last label, the NLRI becomes impossible to parse correctly. See Section 3, paragraph j of [RFC7606] for a discussion of error handling when the NLRI cannot be parsed 😭.

Note that the UPDATE message doesn't just advertise the binding between the prefix and the labels. It also advertises a path to the prefix through the node named in the Next Hop field of the MP_REACH_NLRI attribute 🧚.

If the procedures of [RFC7911] are being used, a four-octet "path identifier" (as defined in Section 3 of [RFC7911]) is part of the NLRI and comes before the Length field 🍓.

2.4. How to Explicitly Withdraw the Binding of a Label to a Prefix 🙅‍♀️

Okay, picture this: a BGP speaker has announced, on a given BGP session, the binding of a given label or sequence of labels to a given prefix. Now it wants to take that back. To do that, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute 💅. The NLRI field of that attribute is encoded like this:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Length     |        Compatibility                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Prefix                               ~
  ~                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: NLRI for Withdrawal

Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored 🫶.

This encoding is used to explicitly withdraw the binding (on a given BGP session) between the specified prefix and whatever label or sequence of labels had previously been bound to that prefix on that session by the procedures of this document. It's used whether or not the Multiple Labels Capability has been sent or received on the session 🌷. Note that label/prefix bindings that were never advertised on the given session can't be withdrawn this way. (But if the bindings were advertised on a previous session with the same peer, and the current session is the result of a "graceful restart" ([RFC4724]) of that previous session, then this withdrawal method may be used 🔄.)

When you use an MP_UNREACH_NLRI attribute to withdraw a route whose NLRI was previously specified in an MP_REACH_NLRI attribute, the lengths and values of the prefixes must match, and the AFI/SAFIs must match too. If the procedures of [RFC7911] are being used, the "path identifier" fields must match as well. Heads up: the prefix length is not the same as the NLRI length! To figure out the prefix length of a prefix in an MP_UNREACH_NLRI, you subtract the length of the Compatibility field from the length of the NLRI 🧮.

An explicit withdrawal in a SAFI-x UPDATE on a given BGP session doesn't just withdraw the binding between the prefix and the label(s). It also withdraws the path to that prefix that was previously advertised in a SAFI-x UPDATE on that session 💀.

[RFC3107] made it possible to put a particular label value in the Compatibility field. However, the functionality that needed a particular label value (or sequence of label values) was never implemented, and it isn't present in this document. So the value of this field is of no significance. There is never any reason for this field to contain a label value or a sequence of label values 🙈.

[RFC3107] also made it possible to withdraw a binding without naming the label, by setting the Compatibility field to 0x800000. However, some implementations set it to 0x000000. To keep backwards compatibility, this document says it is RECOMMENDED that the Compatibility field be set to 0x800000, but it is REQUIRED that it be ignored upon reception 🍼.

2.5. Changing the Label That Is Bound to a Prefix 🦄

Let's set the scene. A BGP speaker, S1, has received, on a given BGP session, a SAFI-4 or SAFI-128 UPDATE, U1, that specifies label (or sequence of labels) L1, prefix P, and next hop N1. As mentioned above, this means label (or sequence of labels) L1 is bound to prefix P at node N1. Now S1 receives, on the same session, an UPDATE, U2, of the same AFI/SAFI, that specifies label (or sequence of labels) L2, prefix P, and the same next hop, N1 🤔.

  • If [RFC7911] is not being used, UPDATE U2 MUST be interpreted as meaning that L2 is now bound to P at N1, and that L1 is no longer bound to P at N1. In other words, UPDATE U1 is implicitly withdrawn and replaced by UPDATE U2 ✨.
  • Suppose that [RFC7911] is being used, that UPDATE U1 has Path Identifier I1, and that UPDATE U2 has Path Identifier I2.
    • If I1 is the same as I2, UPDATE U2 MUST be interpreted as meaning that L2 is now bound to P at N1, and that L1 is no longer bound to P at N1. UPDATE U1 is implicitly withdrawn 🙌.
    • If I1 is not the same as I2, U2 MUST be interpreted as meaning that L2 is now bound to P at N1, but U2 MUST NOT be interpreted as meaning that L1 is no longer bound to P at N1. Under certain conditions (the specification of which is outside the scope of this document), S1 may choose to load-balance traffic between the path represented by U1 and the path represented by U2. To send traffic on the path represented by U1, S1 uses the label(s) advertised in U1. To send traffic on the path represented by U2, S1 uses the label(s) advertised in U2. (Although these two paths have the same next hop, one must suppose that they diverge further downstream 🌊.)

Now a different scenario. Suppose a BGP speaker, S1, has received, on a given BGP session, a SAFI-4 or SAFI-128 UPDATE that specifies label L1, prefix P, and next hop N1. Then S1 receives, on a different BGP session, an UPDATE of the same AFI/SAFI that specifies label L2, prefix P, and the same next hop, N1. BGP speaker S1 SHOULD treat this as a sign that N1 has at least two paths to P, and S1 MAY use this fact to load-balance any traffic it has to send to P 🎯.

Note that this section only discusses the case where two UPDATEs have the same next hop. Procedures for the case where two UPDATEs have different next hops are adequately described in [RFC4271] 🗺️.

3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes 🚀

3.1. Comparability of Routes 🪞

Suppose a BGP speaker has received two SAFI-4 UPDATEs that specify the same Prefix, and either:

  • the two UPDATEs are received on different BGP sessions; or
  • the two UPDATEs are received on the same session, add-paths is used on that session, and the NLRIs of the two UPDATEs have different path identifiers.

These two routes MUST be considered comparable, even if they specify different labels. So the BGP best-path selection procedures (see Section 9.1 of [RFC4271]) are applied to select one of them as the better path 🏆. If the procedures of [RFC7911] are not being used on a particular BGP session, only the best path is propagated on that session. If the procedures of [RFC7911] are being used on a particular BGP session, then both paths may be propagated on that session, though with different path identifiers 💞.

The same applies to SAFI-128 routes 💜.

3.2. Modification of Label(s) Field When Propagating 🎀

3.2.1. When the Next Hop Field Is Unchanged 🌸

When a SAFI-4 or SAFI-128 route is propagated, if the Network Address of Next Hop field is left unchanged, the Label field(s) MUST also be left unchanged 🔒.

Note that a given route MUST NOT be propagated to a given peer if the route's NLRI has multiple labels but the Multiple Labels Capability was not negotiated with that peer. Similarly, a given route MUST NOT be propagated to a given peer if the route's NLRI has more labels than the peer has announced (through its Multiple Labels Capability) that it can handle 🚫. In either case, if a previous route with the same AFI, SAFI, and prefix (but with fewer labels) has already been propagated to the peer, that route MUST be withdrawn from that peer using the procedure specified in Section 2.4 🧹.

3.2.2. When the Next Hop Field Is Changed 🦋

okay bestie, so if the Network Address of Next Hop field gets changed before a SAFI-4 or SAFI-128 route gets propagated, the Label field(s) of the propagated route MUST contain the label(s) that is (are) bound to the prefix at the new next hop. 🫶

Let's say BGP speaker S1 got an UPDATE that binds a certain sequence of one or more labels to a certain prefix. If S1 decides to propagate this route after changing its next hop, S1 may change the label in any of these ways, depending on local policy: 💅

  • A single label may be replaced by a single label of the same or different value.
  • A sequence of multiple labels may be replaced by a single label.
  • A single label may be replaced by a sequence of multiple labels.
  • A sequence of multiple labels may be replaced by a sequence of multiple labels; the number of labels may be left the same or may be changed.

Now, when you're deciding whether to propagate, to a given BGP peer, an UPDATE that binds more than one label, a BGP speaker has to check the info from the Multiple Labels Capability (see Section 2.1). A BGP speaker MUST NOT send multiple labels to a peer it hasn't exchanged the Multiple Labels Capability with, and it MUST NOT send more labels to a given peer than the peer has announced (via the Multiple Labels Capability) that it can handle. 🙈

It's possible that a BGP speaker's local policy says to encode N labels in a route's NLRI before propagating it, but one of its peers can't handle N labels in the NLRI. In that case, the BGP speaker has two choices: ✨

  • It can propagate the route to the given peer with fewer than N labels. Whether that makes sense, and if so how to choose the labels, is also a matter of local policy.
  • It can decide not to propagate the route to the given peer. In that case, if a previous route with the same AFI, SAFI, and prefix (but with fewer labels) has already been propagated to that peer, that route MUST be withdrawn from that peer using the procedure of Section 2.4. 😭

4. Data Plane 🌊

In the following, we're going to use the phrase "node S tunnels packet P to node N", where packet P is an MPLS packet. What we mean by this is that node S encapsulates packet P and causes packet P to be delivered to node N, in such a way that P's label stack before encapsulation will be seen unchanged by N but will not be seen by the nodes (if any) between S and N. 🧚

If the tunnel is a Label Switched Path (LSP), encapsulating the packet may be as simple as pushing on another MPLS label. If node N is a Layer 2 adjacency of node S, a Layer 2 encapsulation may be all that is needed. Other sorts of tunnels (e.g., IP tunnels, GRE tunnels, UDP tunnels) may also be used, depending on the particular deployment scenario. 🌸

Okay, so say BGP speaker S1 receives a SAFI-4 or SAFI-128 BGP UPDATE with an MP_REACH_NLRI specifying label L1, prefix P, and next hop N1, and S1 installs this route as its (or one of its) best path(s) towards P. Then S1 propagates this route after changing the next hop to itself and changing the label to L2. Now S1 receives an MPLS data packet, and while forwarding that packet, S1 sees label L2 rise to the top of the packet's label stack. To forward the packet further, S1 must replace L2 with L1 as the top entry in the packet's label stack, and then S1 must tunnel the packet to N1. 💖

Now let's say the route S1 received didn't specify a single label, but a sequence of k labels <L11, L12, ..., L1k>, where L11 is the first label appearing in the NLRI and L1k is the last. Again, S1 propagates this route after changing the next hop to itself and changing the Label field to the single label L2. S1 receives an MPLS data packet, and while forwarding it, S1 sees label L2 rise to the top of the label stack. This time, instead of simply replacing L2 with L1, S1 removes L2 from the top of the label stack and then pushes labels L1k through L11 onto the label stack, so that L11 is now at the top. Then S1 must tunnel the packet to N1. (Note that L1k will not be at the bottom of the packet's label stack and hence will not have the "bottom of stack" bit set unless L2 had previously been at the bottom of the packet's label stack.) 🍓

The paragraph above assumes that when S1 propagates a SAFI-4 or SAFI-128 route after setting the next hop to itself, it replaces the label or labels in the NLRI of that route with a single label. However, it's also possible, as determined by local policy, for a BGP speaker to specify multiple labels when it propagates a SAFI-4 or SAFI-128 route after setting the next hop to itself. 🎀

For example, say S1 supports context labels ([RFC5331]). Let L21 be a context label supported by S1, and let L22 be a label that is in the label space identified (at S1) by L21. Suppose S1 receives a SAFI-4 or SAFI-128 UPDATE whose prefix is P, whose Label field is <L11, L12, ..., L1k>, and whose next hop is N1. Before propagating the UPDATE, S1 may set the next hop to itself (by replacing N1 with S1) and may replace the label stack <L11, L12, ..., L1k> with the pair of labels <L21, L22>. 👑

In this case, if S1 receives an MPLS data packet whose top label is L21 and whose second label is L22, S1 will remove both L21 and L22 from the label stack and replace them with <L11, L12, ..., L1k>. Note that the fact that L21 is a context label is known only to S1. Other BGP speakers don't know how S1 will interpret L21 (or L22). 🔥

Being able to replace one or more labels with one or more labels is super flexible, but it has to be done carefully. Let's suppose again that S1 receives an UPDATE that specifies prefix P, label stack <L11, L12, ..., L1k>, and next hop N1. Say S1 propagates this UPDATE to BGP speaker S2 after setting next hop self and after replacing the Label field with <L21, L22, ..., L2k>. Finally, suppose S1 programs its data plane so that when it processes a received MPLS packet whose top label is L21, it replaces L21 with <L11, L12, ..., L1k> and then tunnels the packet to N1. 💅

This is where it gets a little messy, bestie. 💀

In this case, BGP speaker S2 will have received a route with prefix P, Label field <L21, L22, ..., L2k>, and next hop S1. If S2 decides to forward an IP packet according to this route, it will push <L21, L22, ..., L2k> onto the packet's label stack and tunnel the packet to S1. S1 will replace L21 with <L11, L12, ..., L1k> and will tunnel the packet to N1. N1 will receive the packet with the following label stack: <L11, L12, ..., L1k, L22, ..., L2k>. While this may be useful in certain scenarios, it may give unintended results in other scenarios. 😭

Procedures for choosing, setting up, maintaining, or determining the liveness of a particular tunnel or type of tunnel are outside the scope of this document. 🌈

When pushing labels onto a packet's label stack, the Time-to-Live (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) field ([RFC3032], [RFC5462]) of each label stack entry must, of course, be set. This document doesn't specify any set of rules for setting these fields. That's a matter of local policy. ✨

This document doesn't specify any new rules for processing the label stack of an incoming data packet. 🌸

Whether SAFI-4 routes can be used as the basis for forwarding IP packets, or whether SAFI-4 routes can only be used for forwarding MPLS packets, is a matter of local policy. If BGP speaker S1 is forwarding IP packets according to SAFI-4 routes, then consider an IP packet with destination address D, such that P is the "longest prefix match" for D from among the routes that are being used to forward IP packets. Suppose the packet is being forwarded according to a SAFI-4 route whose prefix is P, whose next hop is N1, and whose sequence of labels is L1. To forward the packet according to this route, S1 must create a label stack for the packet, push on the sequence of labels L1, and then tunnel the packet to N1. 🦋

5. Relationship between SAFI-4 and SAFI-1 Routes 💜

It's possible that a BGP speaker will receive both a SAFI-1 route for prefix P and a SAFI-4 route for prefix P. Different implementations handle this situation in different ways. 🫶

For example, some implementations may regard SAFI-1 routes and SAFI-4 routes as completely independent, and may treat them in a "ships in the night" fashion. In this case, best-path selection for the two SAFIs is independent, and there will be a best SAFI-1 route to P as well as a best SAFI-4 route to P. Which packets get forwarded according to the routes of which SAFI is then a matter of local policy. 🌟

Other implementations may treat the SAFI-1 and SAFI-4 routes for a given prefix as comparable, so that the best route to prefix P is either a SAFI-1 route or a SAFI-4 route, but not both. In such implementations, if load-balancing is done among a set of equal cost routes, some of the equal cost routes may be SAFI-1 routes and some may be SAFI-4 routes. Whether this is allowed is, again, a matter of local policy. 💅

Some implementations may allow a single BGP session to carry UPDATEs of both SAFI-1 and SAFI-4, and other implementations may disallow this. Some implementations that allow both SAFIs on the same session may treat the receipt of a SAFI-1 route for prefix P on a given session as an implicit withdrawal of a previous SAFI-4 route for prefix P on that session, and vice versa. Other implementations may have different behavior. 🙈

A BGP speaker may receive a SAFI-4 route over a given BGP session but may have other BGP sessions for which SAFI-4 is not enabled. In this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1 route and then propagate the result over the session on which SAFI-4 is not enabled. Whether this is done is a matter of local policy. 🧚

These differences in behavior between implementations may result in unexpected behavior or lack of interoperability. In some cases, it may be difficult or impossible to achieve the desired policies with certain implementations or combinations of implementations. 😭🌈

6. IANA Considerations 📋

IANA has assigned value 8 for Multiple Labels Capability in the BGP "Capability Codes" registry, with this document as the reference. 🎀

IANA has modified the BGP "Capability Codes" registry to mark value 4 ("Multiple routes to a destination capability") as deprecated, with this document as the reference. 🍓

IANA has changed the reference for SAFI 4 in the "Subsequent Address Family Identifiers (SAFI) Parameters" registry to this document. ✨

Also, IANA has added this document as a reference for SAFI 128 in that same registry. 💖

7. Security Considerations ✨

okay bestie, security is where things get dramatic 😭🔥. The security considerations of BGP (as specified in [RFC4271]) apply here too, so that's the baseline 💅.

If a BGP implementation that isn't conformant with this document encodes multiple labels in the NLRI, but it hasn't sent and received the Multiple Labels Capability, then a BGP implementation that does conform with this document will likely reset the BGP session. Rude 💀.

This document says certain data packets get "tunneled" from one BGP speaker to another 🦋. That means the packets have to be encapsulated while they're in flight. This document doesn't specify which encapsulation to use, but if you pick a particular one, its security considerations apply too 🧚.

If a tunnel encapsulation doesn't provide integrity and authentication, a data packet's label stack can get modified while it's in flight, whether by accident or by someone up to no good 👀. That can lead to misdelivery of the packet. The tunnel encapsulation (MPLS) that's most commonly used when deploying this specification doesn't provide integrity or authentication, and neither do the other tunnel encapsulations mentioned in Section 4. Just so you know 🫶.

There are a bunch of techniques for constraining how BGP UPDATE messages get distributed 🌸. If a BGP UPDATE advertises the binding of a particular label or set of labels to a particular address prefix, those techniques can control which BGP speakers are meant to learn about that binding. But if BGP sessions don't provide privacy, other routers might learn about the binding anyway 🙈.

When a BGP speaker processes a received MPLS data packet whose top label it advertised, there's no guarantee that whoever put that label on the packet was a router that was supposed to know about the label binding 😬. If a BGP speaker is using the procedures in this document, it may be useful for that speaker to tell apart its "internal" interfaces from its "external" ones, and to avoid advertising the same labels to BGP speakers reached over internal interfaces as to those reached over external interfaces ✨. Then a data packet can be discarded if its top label wasn't advertised over the type of interface it came in on. That lowers the chance of forwarding packets whose labels were "spoofed" by untrusted sources. Main character energy for your network 👑💖.

8. References

8.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
           Label Switching Architecture", RFC 3031,
           DOI 10.17487/RFC3031, January 2001,
           <https://www.rfc-editor.org/info/rfc3031>.

[RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
           Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
           Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
           <https://www.rfc-editor.org/info/rfc3032>.

[RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
           BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
           <https://www.rfc-editor.org/info/rfc3107>.

[RFC3443]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
           in Multi-Protocol Label Switching (MPLS) Networks",
           RFC 3443, DOI 10.17487/RFC3443, January 2003,
           <https://www.rfc-editor.org/info/rfc3443>.

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271,
           DOI 10.17487/RFC4271, January 2006,
           <https://www.rfc-editor.org/info/rfc4271>.

[RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
           Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
           2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
           "BGP-MPLS IP Virtual Private Network (VPN) Extension for
           IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
           <https://www.rfc-editor.org/info/rfc4659>.

[RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
           "Multiprotocol Extensions for BGP-4", RFC 4760,
           DOI 10.17487/RFC4760, January 2007,
           <https://www.rfc-editor.org/info/rfc4760>.

[RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
           "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
           Provider Edge Routers (6PE)", RFC 4798,
           DOI 10.17487/RFC4798, February 2007,
           <https://www.rfc-editor.org/info/rfc4798>.

[RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
           (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
           Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
           2009, <https://www.rfc-editor.org/info/rfc5462>.

[RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
           with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
           2009, <https://www.rfc-editor.org/info/rfc5492>.

[RFC5549]  Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
           Layer Reachability Information with an IPv6 Next Hop",
           RFC 5549, DOI 10.17487/RFC5549, May 2009,
           <https://www.rfc-editor.org/info/rfc5549>.

[RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
           Patel, "Revised Error Handling for BGP UPDATE Messages",
           RFC 7606, DOI 10.17487/RFC7606, August 2015,
           <https://www.rfc-editor.org/info/rfc7606>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[Enhanced-GR]
           Patel, K., Chen, E., Fernando, R., and J. Scudder,
           "Accelerated Routing Convergence for BGP Graceful
           Restart", Work in Progress,
           draft-ietf-idr-enhanced-gr-06, June 2016.

[RFC4724]  Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
           Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
           DOI 10.17487/RFC4724, January 2007,
           <https://www.rfc-editor.org/info/rfc4724>.

[RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
           Label Assignment and Context-Specific Label Space",
           RFC 5331, DOI 10.17487/RFC5331, August 2008,
           <https://www.rfc-editor.org/info/rfc5331>.

[RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
           Encodings and Procedures for Multicast in MPLS/BGP IP
           VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
           <https://www.rfc-editor.org/info/rfc6514>.

[RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
           Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
           Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
           2015, <https://www.rfc-editor.org/info/rfc7432>.

[RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
           "Advertisement of Multiple Paths in BGP", RFC 7911,
           DOI 10.17487/RFC7911, July 2016,
           <https://www.rfc-editor.org/info/rfc7911>.

[TUNNEL-ENCAPS]
           Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
           Encapsulation Attribute", Work in Progress,
           draft-ietf-idr-tunnel-encaps-07, July 2017.

Acknowledgements

this doc obsoletes RFC 3107 🙌. huge thank you to Yakov Rekhter, co-author of RFC 3107, for all his work on it 🫶. we also want to thank Ravi Chandra, Enke Chen, Srihari R. Sangli, Eric Gray, and Liam Casey for reviewing and commenting on that doc 💜.

thanks to Alexander Okonnikov and David Lamparter for catching a bunch of the errors in RFC 3107 🔍✨.

big thanks to Lili Wang and Kaliraj Vairavakkalai for their help and advice while this doc was being prepared 🌸.

we also thank Mach Chen, Bruno Decraene, Jie Dong, Adrian Farrel, Jeff Haas, Jonathan Hardwick, Jakob Heitz, Alexander Okonnikov, Keyur Patel, Kevin Wang, and Lucy Yong for reviewing and commenting on this document 🎀💅.

Author's Address

Eric C. Rosen
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts  01886
United States of America

Email: erosen@juniper.net
📦 where this page comes from