Passa al contenuto principale

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

  • Stato: Proposed Standard
  • Pubblicato: October 2017
  • Stream: IETF
  • Sostituisce: RFC3107
  • Errata: Nessun 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.

Questo documento specifica una serie di procedure per l'utilizzo di BGP per annunciare che un router specificato ha associato un'etichetta MPLS specificata (o una sequenza specificata di etichette MPLS organizzata come parte contigua di uno stack di etichette) a un prefisso di indirizzo specificato. Ciò può essere fatto inviando un messaggio BGP UPDATE il cui campo Network Layer Reachability Information contiene sia il prefisso che la/le etichetta/e MPLS e il cui campo Next Hop identifica il nodo in cui detto prefisso è associato a detta/e etichetta/e. Questo documento rende obsoleto l'RFC 3107.

Status of This Memo​

This is an Internet Standards Track document.

Questo è un documento Internet Standards Track.

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.

Questo documento è un prodotto della Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto una revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli standard Internet sono disponibili nella Sezione 2 della 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.

Informazioni sullo stato attuale di questo documento, eventuali errata e come fornire feedback su di esso possono essere ottenute all'indirizzo 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 e le persone identificate come autori del documento. Tutti i diritti riservati.

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] specifica le codifiche e le procedure per l'utilizzo di BGP per indicare che un particolare router ha associato una singola etichetta MPLS o una sequenza di etichette MPLS a un particolare prefisso di indirizzo. (Una sequenza di etichette sarebbe organizzata come parte contigua di uno stack di etichette MPLS come specificato in [RFC3031] e [RFC3032].) Ciò viene fatto inviando un messaggio BGP UPDATE il cui campo Network Layer Reachability Information contiene sia il prefisso che la/le etichetta/e MPLS e il cui campo Next Hop identifica il nodo in cui detto prefisso è associato a detta/e etichetta/e. Ogni UPDATE di questo tipo annuncia anche un percorso verso il prefisso specificato tramite il next hop specificato.

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:

Sebbene esistano molte implementazioni e distribuzioni di [RFC3107], vi sono una serie di problemi che hanno ostacolato l'interoperabilità in passato e potrebbero potenzialmente ostacolare l'interoperabilità in futuro:

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

  • Sebbene [RFC3107] specifichi una codifica che consente di associare una sequenza di etichette MPLS (piuttosto che una singola etichetta) a un prefisso, non specifica la semantica dell'associazione di una sequenza di etichette a un prefisso.

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

  • Molte implementazioni di [RFC3107] non supportano l'associazione di una sequenza di etichette a un prefisso.

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

  • [RFC3107] specifica che se un messaggio BGP UPDATE associa una sequenza di etichette a un prefisso, il BGP speaker DEVE includere una BGP Capability [RFC5492] nel suo messaggio OPEN indicando che può elaborare tali messaggi UPDATE. Tuttavia, [RFC3107] non definisce un Capability Code per questo scopo.

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.

Questo documento sostituisce e rende obsoleto [RFC3107]. Definisce una nuova BGP Capability da utilizzare quando si associa una sequenza di etichette a un prefisso; utilizzando questa Capability, è possibile evitare i problemi di interoperabilità menzionati sopra. Questo documento rimuove anche la funzionalità non implementata "Advertising Multiple Routes to a Destination" (vedere la Sezione 4 di [RFC3107]), specificando al contempo come utilizzare [RFC7911] per fornire la stessa funzionalità.

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.

Ciò viene fatto inviando un messaggio Multiprotocol BGP UPDATE, ovvero un messaggio UPDATE con un attributo MP_REACH_NLRI come specificato in [RFC4760]. Il campo Network Address of Next Hop di tale attributo contiene un indirizzo IP del nodo N. La/le etichetta/e e il prefisso sono codificati nel campo Network Layer Reachability Information (NLRI) dell'MP_REACH_NLRI. La codifica del campo NLRI è specificata nelle Sezioni 2.2 e 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.

Se il prefisso è un prefisso di indirizzo IPv4 o un prefisso di indirizzo VPN-IPv4 ([RFC4364]), l'Address Family Identifier (AFI) dell'attributo MP_REACH_NLRI è impostato su 1. Se il prefisso è un prefisso di indirizzo IPv6 o un prefisso VPN-IPv6 ([RFC4659]), l'AFI è impostato su 2. Se il prefisso è un prefisso di indirizzo IPv4 o un prefisso di indirizzo IPv6, il campo Subsequent Address Family Identifier (SAFI) è impostato su 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.

Nel resto di questo documento, utilizzeremo il termine "SAFI-x UPDATE" per riferirci a un messaggio BGP UPDATE contenente un attributo MP_REACH_NLRI o un attributo MP_UNREACH_NLRI ([RFC4760]) il cui campo SAFI contiene il valore 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.

[RFC5492] definisce il "Capabilities Optional Parameter". Un BGP speaker può includere un Capabilities Optional Parameter in un messaggio BGP OPEN. Il Capabilities Optional Parameter è una tripla che include un Capability Code di un ottetto, una Capability length di un ottetto e un Capability Value di lunghezza variabile.

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

Questo documento definisce un parametro BGP Optional Capabilities ([RFC5492]) noto come 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.

  • A meno che questa Capability non venga inviata su una determinata sessione BGP da entrambi i BGP speaker di quella sessione, un messaggio SAFI-4 o SAFI-128 UPDATE inviato su quella sessione da uno dei due speaker DEVE associare un prefisso a una sola etichetta e DEVE utilizzare la codifica della Sezione 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:

Se la Multiple Labels Capability non è stata inviata e ricevuta su una determinata sessione BGP, allora in un BGP UPDATE su quella sessione il cui attributo MP_REACH_NLRI contiene una delle combinazioni AFI/SAFI specificate nella Sezione 2, il campo NLRI è codificato come mostrato nella Figura 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.

  • Length: Il campo Length è costituito da un singolo ottetto.

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.

Se (a) un BGP speaker ha inviato la Multiple Labels Capability nel suo messaggio BGP OPEN per una particolare sessione BGP, (b) ha ricevuto la Multiple Labels Capability nel messaggio BGP OPEN del suo peer per quella sessione, e (c) entrambe le Capability specificano AFI/SAFI x/y, allora quando si utilizza un UPDATE di AFI x e SAFI y per annunciare l'associazione di un'etichetta o di una sequenza di etichette a un dato prefisso, il BGP speaker DEVE utilizzare la codifica della Sezione 2.3. Questa codifica DEVE essere utilizzata anche se solo un'etichetta viene associata a un dato prefisso.

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:

Se la Multiple Labels Capability è stata inviata e ricevuta su una determinata sessione BGP, allora in un BGP UPDATE su quella sessione il cui attributo MP_REACH_NLRI contiene una delle combinazioni AFI/SAFI specificate nella Sezione 2, il campo NLRI è codificato come mostrato nella Figura 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:

Supponiamo che un BGP speaker abbia annunciato, su una determinata sessione BGP, l'associazione di una data etichetta o sequenza di etichette a un dato prefisso. Supponiamo che ora desideri ritirare tale associazione. Per farlo, può inviare un messaggio BGP UPDATE con un attributo MP_UNREACH_NLRI. Il campo NLRI di questo attributo è codificato come segue:

    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.

Alla trasmissione, il campo Compatibility DOVREBBE essere impostato su 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.

Le procedure per modificare la/le etichetta/e associate a un dato prefisso da un dato nodo sono fornite nella Sezione 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.

Le procedure per la propagazione degli UPDATE SAFI-4 e SAFI-128 sono discusse nella Sezione 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.

Quando un BGP speaker installa e propaga un UPDATE SAFI-4 o SAFI-128, e se modifica il valore del campo Network Address of Next Hop, deve programmare il suo data plane in modo appropriato. Questo è discusso nella Sezione 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.

Questo documento definisce un nuovo valore SAFI (128) per la famiglia di indirizzi 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]

Ultimo aggiornamento il