Skip to main content

RFC 8277 - Using BGP to Bind MPLS Labels to Address Prefixes

Document Information​

  • RFC Number: 8277
  • Title: Using BGP to Bind MPLS Labels to Address Prefixes
  • Author: E. Rosen
  • Date: October 2017
  • Category: Standards Track
  • ISSN: 2070-1721
  • Obsoletes: RFC 3107

Abstract​

This document specifies 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. This can be 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 at which said prefix is bound to said label(s). This document obsoletes RFC 3107.

Status of This Memo​

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained 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, as 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 are provided without warranty as described in the Simplified BSD License.

Table of Contents​

  1. Introduction
  2. Using BGP to Bind an Address Prefix to One or More MPLS Labels
  3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes
  4. Data Plane
  5. Relationship between SAFI-4 and SAFI-1 Routes
  6. IANA Considerations
  7. Security Considerations
  8. References

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 at which said prefix is bound to said label(s). Each such UPDATE also advertises a path to the specified prefix via the specified next hop.

Although there are many implementations and deployments of [RFC3107], there are a number 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] do not support the binding of a sequence of labels to a prefix.

  • [RFC3107] specifies that if a BGP UPDATE message binds a sequence of labels to a prefix, the BGP speaker MUST include a BGP Capability [RFC5492] in its OPEN message indicating that it can process such UPDATE messages. However, [RFC3107] does not define a Capability Code for this purpose.

This document replaces and obsoletes [RFC3107]. It defines a new BGP Capability to be used when binding a sequence of labels to a prefix; by using this Capability, the interoperability problems alluded to 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.

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

This is done by sending a Multiprotocol BGP UPDATE message, i.e., 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.

In the remainder of this document, we will 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.

2.1. Multiple Labels Capability​

[RFC5492] defines the "Capabilities Optional Parameter". A BGP speaker can include a Capabilities Optional Parameter in a BGP OPEN message. The Capabilities Optional Parameter is a triple that includes a one-octet Capability Code, a one-octet Capability length, and a variable-length Capability Value.

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.

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

If the Multiple Labels Capability has not 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
  • Length: The Length field consists of a single octet.

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

If (a) a BGP speaker has sent the Multiple Labels Capability in its BGP OPEN message for a particular BGP 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 using an UPDATE of AFI x and SAFI y to advertise the binding of a label or sequence of labels to a given prefix, the BGP speaker MUST use the encoding of Section 2.3. This encoding MUST be used even if only one label is being bound to a given prefix.

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 specified in Section 2, the NLRI field is encoded as shown in Figure 3:

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

2.4. How to Explicitly Withdraw the Binding of a Label to a Prefix​

Suppose a BGP speaker has announced, on a given BGP session, the binding of a given label or sequence of labels to a given prefix. Suppose it now wishes to withdraw that binding. To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute. The NLRI field of this attribute is encoded as follows:

    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.

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

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

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

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

3.1. Comparability of Routes​

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

3.2.1. When the Next Hop Field Is Unchanged​

3.2.2. When the Next Hop Field Is Changed​

4. Data Plane​

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.

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

6. IANA Considerations​

This document defines a new SAFI value (128) for the VPN-IPv6 address family.

7. Security Considerations​

8. References​

8.1. Normative References​

  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
  • [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
  • [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
  • [RFC4659] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
  • [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
  • [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009.
  • [RFC7841] Halpern, J., Ed., Resnick, P., Ed., and A. Farrel, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, May 2016.
  • [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, July 2016.

8.2. Informative References​

  • [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.

Acknowledgements​

Author's Address​

E. Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States of America

Email: [email protected]

Last updated on