Aller au contenu principal

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

  • Statut: Proposed Standard
  • Publié: October 2017
  • Stream: IETF
  • Remplace: RFC3107
  • Errata: Pas d'errata

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.

Ce document spécifie un ensemble de procédures pour utiliser BGP afin d'annoncer qu'un routeur spécifié a lié une étiquette MPLS spécifiée (ou une séquence spécifiée d'étiquettes MPLS organisée comme une partie contiguë d'une pile d'étiquettes) à un préfixe d'adresse spécifié. Cela peut être fait en envoyant un message BGP UPDATE dont le champ Network Layer Reachability Information contient à la fois le préfixe et la ou les étiquettes MPLS et dont le champ Next Hop identifie le nœud auquel ledit préfixe est lié à ladite ou auxdites étiquettes. Ce document rend obsolète la RFC 3107.

Status of This Memo​

This is an Internet Standards Track document.

Ceci est un document de la voie des normes Internet.

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.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). De plus amples informations sur les normes Internet sont disponibles dans la section 2 de la 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.

Des informations sur l'état actuel de ce document, les éventuels errata et la manière de fournir des commentaires à son sujet peuvent être obtenues sur https://www.rfc-editor.org/info/rfc8277.

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

Copyright (c) 2017 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

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.

[RFC3107] spécifie les encodages et les procédures pour utiliser BGP afin d'indiquer qu'un routeur particulier a lié soit une étiquette MPLS unique, soit une séquence d'étiquettes MPLS à un préfixe d'adresse particulier. (Une séquence d'étiquettes serait organisée comme une partie contiguë d'une pile d'étiquettes MPLS telle que spécifiée dans [RFC3031] et [RFC3032].) Cela se fait en envoyant un message BGP UPDATE dont le champ Network Layer Reachability Information contient à la fois le préfixe et la ou les étiquettes MPLS et dont le champ Next Hop identifie le nœud auquel ledit préfixe est lié à ladite ou auxdites étiquettes. Chaque UPDATE annonce également un chemin vers le préfixe spécifié via le prochain saut spécifié.

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:

Bien qu'il existe de nombreuses implémentations et déploiements de la [RFC3107], elle présente un certain nombre de problèmes qui ont entravé l'interopérabilité dans le passé et pourraient potentiellement entraver l'interopérabilité à l'avenir :

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

  • Bien que la [RFC3107] spécifie un encodage qui permet de lier une séquence d'étiquettes MPLS (plutôt qu'une simple étiquette) à un préfixe, elle ne spécifie pas la sémantique de la liaison d'une séquence d'étiquettes à un préfixe.

  • Many implementations of [RFC3107] do not support the binding of a sequence of labels to a prefix.

  • De nombreuses implémentations de la [RFC3107] ne prennent pas en charge la liaison d'une séquence d'étiquettes à un préfixe.

  • [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.

  • La [RFC3107] spécifie que si un message BGP UPDATE lie une séquence d'étiquettes à un préfixe, le locuteur BGP DOIT inclure une capacité BGP [RFC5492] dans son message OPEN indiquant qu'il peut traiter de tels messages UPDATE. Cependant, la [RFC3107] ne définit pas de code de capacité à cet effet.

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.

Ce document remplace et rend obsolète la [RFC3107]. Il définit une nouvelle capacité BGP à utiliser lors de la liaison d'une séquence d'étiquettes à un préfixe ; en utilisant cette capacité, les problèmes d'interopérabilité évoqués ci-dessus peuvent être évités. Ce document supprime également la fonctionnalité non implémentée « Annonce de plusieurs routes vers une destination » (voir la section 4 de la [RFC3107]), tout en spécifiant comment utiliser la [RFC7911] pour fournir la même fonctionnalité.

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.

Cela se fait en envoyant un message BGP UPDATE multiprotocole, c'est-à-dire un message UPDATE avec un attribut MP_REACH_NLRI tel que spécifié dans la [RFC4760]. Le champ Network Address of Next Hop de cet attribut contient une adresse IP du nœud N. La ou les étiquettes et le préfixe sont encodés dans le champ Network Layer Reachability Information (NLRI) du MP_REACH_NLRI. L'encodage du champ NLRI est spécifié dans les sections 2.2 et 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.

Si le préfixe est un préfixe d'adresse IPv4 ou un préfixe d'adresse VPN-IPv4 ([RFC4364]), l'identifiant de famille d'adresses (AFI) de l'attribut MP_REACH_NLRI est défini sur 1. Si le préfixe est un préfixe d'adresse IPv6 ou un préfixe VPN-IPv6 ([RFC4659]), l'AFI est défini sur 2. Si le préfixe est un préfixe d'adresse IPv4 ou un préfixe d'adresse IPv6, le champ Identifiant de famille d'adresses ultérieure (SAFI) est défini sur 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.

Dans la suite de ce document, nous utiliserons le terme « MISE À JOUR SAFI-x » pour désigner un message BGP UPDATE contenant un attribut MP_REACH_NLRI ou un attribut MP_UNREACH_NLRI ([RFC4760]) dont le champ SAFI contient la valeur 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.

La [RFC5492] définit le « paramètre facultatif de capacités ». Un locuteur BGP peut inclure un paramètre facultatif de capacités dans un message BGP OPEN. Le paramètre facultatif de capacités est un triplet qui comprend un code de capacité d'un octet, une longueur de capacité d'un octet et une valeur de capacité de longueur variable.

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

Ce document définit un paramètre de capacités facultatives BGP ([RFC5492]) appelé capacité d'étiquettes multiples.

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

  • À moins que cette capacité ne soit envoyée sur une session BGP donnée par les deux locuteurs BGP de cette session, un message UPDATE SAFI-4 ou SAFI-128 envoyé sur cette session par l'un ou l'autre locuteur DOIT lier un préfixe à une seule étiquette et DOIT utiliser l'encodage de la 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:

Si la capacité d'étiquettes multiples n'a pas été à la fois envoyée et reçue sur une session BGP donnée, alors dans une MISE À JOUR BGP sur cette session dont l'attribut MP_REACH_NLRI contient l'une des combinaisons AFI/SAFI spécifiées dans la section 2, le champ NLRI est encodé comme indiqué dans la 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.

  • Longueur : Le champ Longueur est constitué d'un seul 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.

Si (a) un locuteur BGP a envoyé la capacité d'étiquettes multiples dans son message BGP OPEN pour une session BGP particulière, (b) il a reçu la capacité d'étiquettes multiples dans le message BGP OPEN de son pair pour cette session, et (c) les deux capacités spécifient AFI/SAFI x/y, alors lors de l'utilisation d'une MISE À JOUR d'AFI x et SAFI y pour annoncer la liaison d'une étiquette ou d'une séquence d'étiquettes à un préfixe donné, le locuteur BGP DOIT utiliser l'encodage de la section 2.3. Cet encodage DOIT être utilisé même si une seule étiquette est liée à un préfixe donné.

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:

Si la capacité d'étiquettes multiples a été à la fois envoyée et reçue sur une session BGP donnée, alors dans une MISE À JOUR BGP sur cette session dont l'attribut MP_REACH_NLRI contient l'une des combinaisons AFI/SAFI spécifiées dans la section 2, le champ NLRI est encodé comme indiqué dans la 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:

Supposons qu'un locuteur BGP ait annoncé, sur une session BGP donnée, la liaison d'une étiquette ou d'une séquence d'étiquettes donnée à un préfixe donné. Supposons qu'il souhaite maintenant retirer cette liaison. Pour ce faire, il peut envoyer un message BGP UPDATE avec un attribut MP_UNREACH_NLRI. Le champ NLRI de cet attribut est encodé comme suit :

    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.

Lors de la transmission, le champ Compatibilité DEVRAIT être défini sur 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.

Les procédures pour changer la ou les étiquettes liées à un préfixe donné par un nœud donné sont indiquées dans la 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.

Les procédures de propagation des MISES À JOUR SAFI-4 et SAFI-128 sont discutées dans la 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.

Lorsqu'un locuteur BGP installe et propage une MISE À JOUR SAFI-4 ou SAFI-128, et s'il modifie la valeur du champ Adresse réseau du saut suivant, il doit programmer son plan de données de manière appropriée. Ceci est discuté dans la 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.

Ce document définit une nouvelle valeur SAFI (128) pour la famille d'adresses VPN-IPv6.

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]

Dernière mise à jour le