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

• ステータス: Proposed Standard
• 発行日: October 2017
• ストリーム: IETF
• 廃止: RFC3107
• エラッタ: エラッタなし

---

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.

このドキュメントでは、指定されたルーターが指定されたMPLSラベル（またはラベルスタックの連続した部分として構成された指定されたMPLSラベルのシーケンス）を指定されたアドレスプレフィックスにバインドしたことをアドバタイズするためにBGPを使用する一連の手順を指定します。これは、ネットワーク層到達可能性情報フィールドにプレフィックスとMPLSラベルの両方が含まれ、Next Hopフィールドがそのプレフィックスがそのラベルにバインドされているノードを識別するBGP UPDATEメッセージを送信することによって実行できます。このドキュメントは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.

このドキュメントは、Internet Engineering Task Force（IETF）の成果物です。これはIETFコミュニティのコンセンサスを表しています。公開レビューを受け、Internet Engineering Steering Group（IESG）によって公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2を参照してください。

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.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8277 で入手できます。

Copyright Notice

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

Copyright (c) 2017 IETF Trustおよびドキュメントの著者として特定された人物。全著作権所有。

Table of Contents

1. Introduction
2. Using BGP to Bind an Address Prefix to One or More MPLS Labels
   • 2.1. Multiple Labels Capability
   • 2.2. NLRI Encoding When the Multiple Labels Capability Is Not Used
   • 2.3. NLRI Encoding When the Multiple Labels Capability Is Used
   • 2.4. How to Explicitly Withdraw the Binding of a Label to a Prefix
   • 2.5. Changing the Label That Is Bound to a Prefix
3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes
   • 3.1. Comparability of Routes
   • 3.2. Modification of Label(s) Field When Propagating
4. Data Plane
5. Relationship between SAFI-4 and SAFI-1 Routes
6. IANA Considerations
7. Security Considerations
8. References
   • 8.1. Normative References
   • 8.2. Informative References

• Acknowledgements
• Author's Address

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]は、特定のルーターが単一のMPLSラベルまたは一連のMPLSラベルを特定のアドレスプレフィックスにバインドしたことを示すためにBGPを使用するためのエンコーディングと手順を指定します。（ラベルのシーケンスは、[RFC3031]および[RFC3032]で指定されているMPLSラベルスタックの連続した部分として構成されます。）これは、ネットワーク層到達可能性情報フィールドにプレフィックスとMPLSラベルの両方が含まれ、Next Hopフィールドがそのプレフィックスがそのラベルにバインドされているノードを識別するBGP UPDATEメッセージを送信することによって行われます。このような各UPDATEは、指定されたネクストホップを介して指定されたプレフィックスへのパスもアドバタイズします。

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:

[RFC3107]の実装と展開は多数ありますが、過去に相互運用性を妨げており、将来的にも相互運用性を妨げる可能性のあるいくつかの問題があります。

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

• [RFC3107]は、一連のMPLSラベル（単一のラベルだけでなく）をプレフィックスにバインドできるようにするエンコーディングを指定していますが、一連のラベルをプレフィックスにバインドするセマンティクスは指定していません。

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

• [RFC3107]の多くの実装は、一連のラベルのプレフィックスへのバインドをサポートしていません。

• [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]は、BGP UPDATEメッセージが一連のラベルをプレフィックスにバインドする場合、BGPスピーカーはそのOPENメッセージにBGP Capability [RFC5492]を含め、そのようなUPDATEメッセージを処理できることを示す必要があると規定しています。ただし、[RFC3107]はこの目的のためのCapability Codeを定義していません。

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.

このドキュメントは[RFC3107]を置き換え、廃止します。これは、一連のラベルをプレフィックスにバインドするときに使用される新しいBGP Capabilityを定義します。このCapabilityを使用することで、上記で言及した相互運用性の問題を回避できます。このドキュメントでは、実装されていない「宛先への複数のルートのアドバタイズ」機能（[RFC3107]のセクション4を参照）も削除し、[RFC7911]を使用して同じ機能を提供する方法を指定しています。

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.

これは、マルチプロトコルBGP UPDATEメッセージ、つまり[RFC4760]で指定されているMP_REACH_NLRI属性を持つUPDATEメッセージを送信することによって行われます。その属性のNetwork Address of Next Hopフィールドには、ノードNのIPアドレスが含まれています。ラベルとプレフィックスは、MP_REACH_NLRIのNetwork Layer Reachability Information（NLRI）フィールドにエンコードされます。NLRIフィールドのエンコーディングは、セクション2.2および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.

プレフィックスがIPv4アドレスプレフィックスまたはVPN-IPv4（[RFC4364]）アドレスプレフィックスの場合、MP_REACH_NLRI属性のアドレスファミリ識別子（AFI）は1に設定されます。プレフィックスがIPv6アドレスプレフィックスまたはVPN-IPv6プレフィックス（[RFC4659]）の場合、AFIは2に設定されます。プレフィックスがIPv4アドレスプレフィックスまたはIPv6アドレスプレフィックスの場合、後続アドレスファミリ識別子（SAFI）フィールドは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.

このドキュメントの残りの部分では、「SAFI-x UPDATE」という用語を使用して、SAFIフィールドに値xを含むMP_REACH_NLRI属性またはMP_UNREACH_NLRI属性（[RFC4760]）を含むBGP UPDATEメッセージを参照します。

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]は「Capabilities Optional Parameter」を定義しています。BGPスピーカーは、BGP OPENメッセージにCapabilities Optional Parameterを含めることができます。Capabilities Optional Parameterは、1オクテットのCapability Code、1オクテットのCapability length、および可変長のCapability Valueを含むトリプルです。

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

このドキュメントでは、Multiple Labels Capabilityと呼ばれるBGP Optional Capabilitiesパラメーター（[RFC5492]）を定義しています。

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

• このCapabilityが、そのセッションの両方のBGPスピーカーによって特定のBGPセッションで送信されない限り、どちらかのスピーカーからそのセッションで送信されるSAFI-4またはSAFI-128 UPDATEメッセージは、プレフィックスを単一のラベルのみにバインドしなければならず（MUST）、セクション2.2のエンコーディングを使用しなければなりません（MUST）。

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:

Multiple Labels Capabilityが特定のBGPセッションで送受信されていない場合、セクション2で指定されたAFI/SAFIの組み合わせのいずれかを含むMP_REACH_NLRI属性を持つそのセッションのBGP UPDATEでは、NLRIフィールドは図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: Lengthフィールドは単一のオクテットで構成されます。

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.

(a) BGPスピーカーが特定のBGPセッションのBGP OPENメッセージでMultiple Labels Capabilityを送信し、(b) そのセッションのピアのBGP OPENメッセージでMultiple Labels Capabilityを受信し、(c) 両方のCapabilitiesがAFI/SAFI x/yを指定している場合、AFI xおよびSAFI yのUPDATEを使用してラベルまたはラベルのシーケンスの特定のプレフィックスへのバインドをアドバタイズするとき、BGPスピーカーはセクション2.3のエンコーディングを使用しなければなりません（MUST）。このエンコーディングは、単一のラベルのみが特定のプレフィックスにバインドされている場合でも使用しなければなりません（MUST）。

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:

Multiple Labels Capabilityが特定のBGPセッションで送受信されている場合、セクション2で指定されたAFI/SAFIの組み合わせのいずれかを含むMP_REACH_NLRI属性を持つそのセッションのBGP UPDATEでは、NLRIフィールドは図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:

あるBGPスピーカーが、特定のBGPセッションで、特定のラベルまたはラベルのシーケンスの特定のプレフィックスへのバインドをアナウンスしたとします。ここで、そのバインドを撤回したいとします。これを行うには、MP_UNREACH_NLRI属性を持つBGP UPDATEメッセージを送信できます。この属性のNLRIフィールドは次のようにエンコードされます。

    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.

送信時、Compatibilityフィールドは0x800000に設定する必要があります（SHOULD）。

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.

特定のノードによって特定のプレフィックスにバインドされているラベルを変更する手順は、セクション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.

SAFI-4およびSAFI-128 UPDATEを伝播する手順については、セクション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.

BGPスピーカーがSAFI-4またはSAFI-128 UPDATEをインストールして伝播し、Next HopフィールドのNetwork Addressの値を変更する場合、データプレーンを適切にプログラムする必要があります。これについては、セクション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.

このドキュメントでは、VPN-IPv6アドレスファミリの新しいSAFI値（128）を定義しています。

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]