RFC 8277 - Using BGP to Bind MPLS Labels to Address Prefixes 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8277
タイトル : RFC 8277 - BGPを使用してMPLSラベルをアドレスプレフィックスにバインドする
翻訳編集 : 自動生成

[要約] RFC 8277は、BGPを使用してMPLSラベルをアドレスプレフィックスにバインドするための仕様です。このRFCの目的は、MPLSネットワークでの経路選択とトラフィックエンジニアリングを向上させることです。

Internet Engineering Task Force (IETF)                          E. Rosen
Request for Comments: 8277                        Juniper Networks, Inc.
Obsoletes: 3107                                             October 2017
Category: Standards Track
ISSN: 2070-1721

Using BGP to Bind MPLS Labels to Address Prefixes

BGPを使用してMPLSラベルをアドレスプレフィックスにバインドする

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.

このドキュメントでは、BGPを使用して、指定されたルーターが指定されたMPLSラベル（またはラベルスタックの隣接部分として編成された指定されたMPLSラベルのシーケンス）を指定されたアドレスプレフィックスにバインドしたことをアドバタイズするための一連の手順を指定します。これは、ネットワークレイヤー到達可能性情報フィールドにプレフィックスとMPLSラベルの両方が含まれ、次のホップフィールドが、そのプレフィックスがラベルにバインドされているノードを識別するBGP UPDATEメッセージを送信することで実行できます。このドキュメントはRFC 3107を廃止します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これは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.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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で入手できます。

著作権表示

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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

1. はじめに

[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]は、BGPを使用して特定のルーターが単一のMPLSラベルまたは一連のMPLSラベルを特定のアドレスプレフィックスにバインドしたことを示すためのエンコーディングと手順を指定しています。（一連のラベルは、[RFC3031]および[RFC3032]で指定されているように、MPLSラベルスタックの連続した部分として編成されます。）これは、ネットワークレイヤー到達可能性情報フィールドにプレフィックスとプレフィックスの両方が含まれるBGP UPDATEメッセージを送信することで行われます。 MPLSラベルおよびそのNext Hopフィールドは、前記プレフィックスが前記ラベルにバインドされているノードを識別します。このような各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]には多くの実装と展開がありますが、過去には相互運用性を妨げ、将来的には相互運用性を妨げる可能性のある多くの問題があります。

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

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

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

o [RFC3107]の多くの実装は、1つのラベルのみがプレフィックスにバインドされることを想定しており、ラベルのシーケンスをプレフィックスにバインドするBGP UPDATEメッセージを適切に処理できません。したがって、この機能を提供しようとする実装では、他の実装との相互運用で問題が発生する可能性があります。

o The procedures in [RFC3107] for withdrawing the binding of a label or sequence of labels to a prefix are not specified clearly and correctly.

o 接頭辞へのラベルまたはラベルのシーケンスのバインディングを撤回するための[RFC3107]の手順は、明確かつ正確に指定されていません。

o [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 that this feature was intended to provide can and has been implemented in a different way using the procedures of [RFC7911], which were not available at the time that [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.

o [RFC3107]は、「宛先への複数のルートのアドバタイズ」と呼ばれるオプションの機能を指定しています。これは、作成者の知る限りでは、仕様どおりに実装されたことはありません。この機能を提供することを意図していた機能は、[RFC7911]の手順を使用して別の方法で実装でき、[RFC3107]が書かれた時点では利用できませんでした。 [RFC3107]では、この機能は実装されたことのないBGP機能コードによって制御され、現在は非推奨です。セクション6を参照してください。

o It is 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 the issue of how the presence of two such UPDATEs impacts the BGP decision process and does not 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.

o BGPスピーカーが、同じアドレスプレフィックスにパスをアドバタイズする2つのBGP UPDATEを受信する可能性があります。一方のUPDATEはラベル（または一連のラベル）をプレフィックスにバインドし、もう一方はバインドしません。 [RFC3107]は、そのような2つのUPDATEの存在がBGP決定プロセスにどのように影響するかについては触れておらず、これらのUPDATEのどちらか一方または両方を伝播する必要があるかどうかを明示していません。これにより、さまざまな実装がこの状況をさまざまな方法で処理するようになりました。

o Much of [RFC3107] applies to the VPN-IPv4 ([RFC4364]) and VPN-IPv6 ([RFC4659]) address families, but those address families are not mentioned in it.

o [RFC3107]の多くは、VPN-IPv4（[RFC4364]）およびVPN-IPv6（[RFC4659]）アドレスファミリーに適用されますが、それらのアドレスファミリーについては言及されていません。

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

このドキュメントは置き換えられ、廃止されます[RFC3107]。ラベルのシーケンスをプレフィックスにバインドするときに使用される新しいBGP機能を定義します。この機能を使用することにより、上記の相互運用性の問題を回避できます。このドキュメントは、実装されていないものも削除します

"Advertising Multiple Routes to a Destination" feature (see Section 4 of [RFC3107]), while specifying how to use [RFC7911] to provide the same functionality. This document also addresses the issue of the how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but do not bind labels to it. However, for backwards compatibility, it declares most of these interactions to be matters of local policy.

「宛先への複数のルートのアドバタイズ」機能（[RFC3107]のセクション4を参照）、[RFC7911]を使用して同じ機能を提供する方法を指定このドキュメントは、ラベルを特定のプレフィックスにバインドするUPDATEが、そのプレフィックスへのパスをアドバタイズするがラベルをプレフィックスにバインドしないUPDATEとどのように相互作用するかという問題にも対処します。ただし、下位互換性のため、これらの相互作用のほとんどはローカルポリシーの問題であると宣言されています。

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

この仕様が[RFC3107]と異なるところは本文中に示されています。現在のドキュメントに準拠する実装は、[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.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

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

2. BGPを使用してアドレスプレフィックスを1つ以上のMPLSラベルにバインドする

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. 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を使用して、特定のノード（Nと呼びます）が特定のMPLSラベル、または特定のMPLSラベルのシーケンス（MPLSラベルスタックの連続した部分として編成）を特定のアドレスプレフィックスにバインドしたことを通知できます。これは、マルチプロトコルBGP UPDATEメッセージ、つまり[RFC4760]で指定されているMP_REACH_NLRI属性を持つUPDATEメッセージを送信することで行われます。その属性の次ホップのネットワークアドレスフィールドには、ノードNのIPアドレスが含まれます。ラベルとプレフィックスは、MP_REACH_NLRIのネットワーク層到達可能性情報（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.

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

プレフィックスがIPv4アドレスプレフィックスまたはIPv6アドレスプレフィックスである場合、Subsequent Address Family Identifier（SAFI）フィールドは4に設定されます。プレフィックスがVPN-IPv4アドレスプレフィックスまたはVPN-IPv6アドレスプレフィックスである場合、SAFIが設定されます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.

AFIが1または2以外の場合のSAFI 4またはSAFI 128の使用は、このドキュメントの範囲外です。

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

このドキュメントでは、MP_REACH_NLRI属性の[ネクストホップのネットワークアドレス]フィールドの形式を指定していません。ネクストホップフィールドの形式は、いくつかの要因に依存し、他の多くのRFCで説明されています。[RFC4364]、[RFC4659]、[RFC4798]、および[RFC5549]を参照してください。

There are a variety of applications that make use of 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. Discussion of which method to use for which application is outside the scope of the current document.

BGPを使用してMPLSラベルバインディングをアドバタイズする代替方法を利用するさまざまなアプリケーションがあります。たとえば、[RFC7432]、[RFC6514]、または[TUNNEL-ENCAPS]を参照してください。現在のドキュメントで説明されている方法は、BGPを使用してMPLSラベルバインディングをアドバタイズする唯一の方法であるとは主張されていません。どのアプリケーションにどのメソッドを使用するかは、現在のドキュメントの範囲外です。

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メッセージを指します。

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

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

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

o この機能が特定のBGPセッションでそのセッションの両方のBGPスピーカーによって送信されない限り、どちらかのスピーカーからそのセッションで送信されたSAFI-4またはSAFI-128 UPDATEメッセージは、プレフィックスを単一のラベルのみにバインドし、セクション2.2。

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

o この機能が特定のセッションで両方のBGPスピーカーによって送信される場合、そのセッションのUPDATEメッセージは、いずれかのスピーカーから、セクション2.3のエンコーディングを使用する必要があり、プレフィックスを複数のラベルのシーケンスにバインドすることができます（MAY）。

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

複数ラベル機能のエンコーディングは、セクション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.

ラベルバインディングを明示的に撤回する手順については、2.4節を参照してください。特定のノードによって特定のプレフィックスにバインドされたラベルを変更する手順については、2.5節を参照してください。

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

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

BGPスピーカーがSAFI-4またはSAFI-128 UPDATEをインストールして伝達するとき、および次ホップフィールドのネットワークアドレスの値を変更する場合、そのデータプレーンを適切にプログラムする必要があります。これについては、セクション4で説明します。

2.1. Multiple Labels Capability

2.1. 複数のラベル機能

[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]は、「機能オプションパラメータ」を定義します。 BGPスピーカーは、BGP OPENメッセージに機能オプションパラメータを含めることができます。 Capabilitiesオプションパラメータは、1オクテットの機能コード、1オクテットの機能長、および可変長の機能値を含むトリプルです。

This document defines a Capability Code known as the Multiple Labels Capability code. IANA has assigned value 8 to this Capability Code. (This Capability Code is new to this document and does not appear in [RFC3107].)

このドキュメントでは、Multiple Labels Capabilityコードと呼ばれる機能コードを定義します。 IANAは、この機能コードに値8を割り当てました。（この機能コードはこのドキュメントの新機能であり、[RFC3107]には表示されません。）

If a BGP speaker has not sent the Multiple Labels Capability in its BGP OPEN message on a particular BGP session, or if it has not received the Multiple Labels Capability in the BGP OPEN message from its peer on that BGP session, that BGP speaker MUST NOT send on that session any UPDATE message that binds more than one MPLS label to any given prefix. Further, when advertising the binding of a single label to a prefix, the BGP speaker MUST use the encoding specified in Section 2.2.

BGPスピーカーが特定のBGPセッションのBGP OPENメッセージで複数ラベル機能を送信していない場合、またはそのBGPセッションのピアからBGP OPENメッセージで複数ラベル機能を受信していない場合、そのBGPスピーカーはそのセッションで、任意のプレフィックスに複数のMPLSラベルをバインドするUPDATEメッセージを送信します。さらに、単一のラベルのプレフィックスへのバインディングをアドバタイズする場合、BGPスピーカーはセクション2.2で指定されたエンコーディングを使用する必要があります。

The value field of the Multiple Labels Capability (shown in Figure 1) consists of one or more triples, where each triple consists of four octets. The first two octets of a triple specify an AFI value, the third octet specifies a SAFI value, and the fourth specifies a Count. If one of the triples is <AFI, SAFI, Count>, the Count is the maximum number of labels that the BGP speaker sending the Capability can process in a received UPDATE of the specified AFI/SAFI. If the Count is 255, then no limit has been placed on the number of labels that can be processed in a received UPDATE of the specified AFI/SAFI.

Multiple Labels Capability（図1に示す）の値フィールドは、1つ以上のトリプルで構成され、各トリプルは4つのオクテットで構成されます。トリプルの最初の2つのオクテットはAFI値を指定し、3番目のオクテットはSAFI値を指定し、4番目のオクテットはカウントを指定します。トリプルの1つが<AFI、SAFI、カウント>の場合、カウントは、機能を送信するBGPスピーカーが、指定されたAFI / SAFIの受信したUPDATEで処理できるラベルの最大数です。カウントが255の場合、指定されたAFI / SAFIの受信したUPDATEで処理できるラベルの数に制限はありません。

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 in which a larger number of labels is needed.

複数ラベル機能を送信する実装は、NLRIで少なくとも2つのラベルをサポートできなければなりません（MUST）。ただし、より多くのラベルが必要になる展開シナリオもあるかもしれません。

      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

図1：複数のラベル機能の値フィールド

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

機能に特定のAFI / SAFIを持つ複数のトリプルが含まれる場合、最初のものを除くすべてを無視する必要があります。

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

<AFI = x、SAFI = y、Count = 0>または<AFI = x、SAFI = y、Count = 1>形式のトリプルは送信してはなりません（MUST NOT）。そのようなトリプルが受信された場合、それは無視されなければなりません（MUST）。

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

長さが4の倍数ではないマルチラベル機能は、不正な形式と見なされる必要があります。

"Graceful Restart Mechanism for BGP" [RFC4724] describes a procedure that allows routes learned over a given BGP session to be maintained when the session fails and then restarts. This procedure requires the entire RIB to be transmitted when the session restarts. If the Multiple Labels Capability for a given AFI/SAFI was exchanged on the failed session but has not been exchanged on the restarted session, then any prefixes advertised in that AFI/SAFI with multiple labels MUST be explicitly withdrawn. Similarly, if the maximum label count (specified in the Capability for a given AFI/SAFI) is reduced, any prefixes advertised with more labels than are valid for the current session MUST be explicitly withdrawn.

「BGPのグレースフルリスタートメカニズム」[RFC4724]では、特定のBGPセッションで学習したルートを、セッションが失敗して再起動したときに維持できるようにする手順について説明しています。この手順では、セッションの再開時にRIB全体を送信する必要があります。特定のAFI / SAFIの複数ラベル機能が失敗したセッションで交換されたが、再起動されたセッションでは交換されなかった場合、複数のラベルを持つそのAFI / SAFIでアドバタイズされたプレフィックスは明示的に撤回する必要があります。同様に、最大ラベルカウント（特定のAFI / SAFIの機能で指定）が削減された場合、現在のセッションで有効な数より多くのラベルを使用してアドバタイズされたプレフィックスは明示的に撤回する必要があります。

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

「BGPグレースフルリスタートの高速ルーティングコンバージェンス」[Enhanced-GR]では、特定のBGPセッションで学習されたルートを、セッションが失敗して再起動したときに維持できるようにする別の手順について説明します。以下の条件のいずれかに該当する場合、これらの手順を適用してはなりません：

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

o 特定のAFI / SAFIの複数ラベル機能は、再起動前に交換されていましたが、再起動されたセッションでは交換されていません。

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

o 特定のAFI / SAFIのマルチラベル機能は、再起動前に特定のカウントで交換されていましたが、再起動されたセッションではより少ないカウントで交換されました。

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

これらの条件のいずれかが成立する場合、指定されたAFI / SAFIのルートの完全なセットを交換する必要があります。

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

BGP OPENメッセージに複数ラベル機能の複数のコピーが含まれている場合、重要なのは最初のコピーのみです。後続のコピーは無視する必要があります。

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メッセージで複数ラベル機能を送信した場合、（b）そのセッションのピアのBGP OPENメッセージで複数ラベル機能を受信した、および（c）両方の機能AFI / SAFI x / yを指定してから、AFI xとSAFI yのUPDATEを使用して、ラベルまたはラベルシーケンスの特定のプレフィックスへのバインディングをアドバタイズする場合、BGPスピーカーはセクション2.3のエンコーディングを使用する必要があります。このエンコーディングは、1つのラベルのみが特定のプレフィックスにバインドされている場合でも使用する必要があります。

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

特定のBGPセッションの両方のBGPスピーカーが複数ラベル機能を送信したが、AFI / SAFI x / yが両方の機能で指定されていない場合、そのセッションでのAFI / SAFI x / yの更新では、セクション2.2のエンコーディングを使用する必要があります。、およびそのようなUPDATEは、1つのラベルのみを接頭辞にバインドできます。

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. If a BGP speaker receives an UPDATE that binds more labels to a given prefix than the number of labels the BGP speaker is prepared to receive (as announced in its Multiple Labels Capability), the BGP speaker MUST apply the "treat-as-withdraw" strategy of [RFC7606] to that UPDATE.

BGPスピーカーは、ピアが送信できるマルチラベル機能で指定されているように、ピアが受信できるよりも多くのラベルを特定のプレフィックスにバインドするUPDATEを送信してはなりません（SHOULD NOT）。 BGPスピーカーが受信する準備ができているラベルの数よりも多くのラベルを特定のプレフィックスにバインドするUPDATEをBGPスピーカーが受信する場合（マルチラベル機能で発表されているとおり）、BGPスピーカーは「with-as-withdraw」を適用する必要があります。そのアップデートへの[RFC7606]の戦略。

Notwithstanding the number of labels that a BGP speaker has claimed to be able to 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 that there is only a limited amount of space in the NLRI field for labels:

BGPスピーカーが受信できると主張しているラベルの数にかかわらず、そのピアは、MP_REACH_NLRI属性のNLRIフィールドで適切にエンコードできる数より多くのラベルを送信しようとしてはなりません。ラベルのNLRIフィールドには限られたスペースしかないことに注意してください。

o per [RFC4760], the size of this field is limited to 255 bits (not 255 octets), including the number of bits in the prefix;

o [RFC4760]ごとに、このフィールドのサイズは、プレフィックスのビット数を含め、255ビット（255オクテットではない）に制限されています。

o 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).

o SAFI-128 UPDATEでは、プレフィックスは少なくとも64ビット長であり、192ビットと同じ長さになる場合があります（例：VPN-IPv6ホストルート）。

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

2.2. 複数のラベル機能が使用されていない場合のNLRIエンコーディング

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:

複数のラベル機能が特定のBGPセッションで送受信されていない場合、そのセッションのBGP UPDATEで、MP_REACH_NLRI属性にセクション2で指定されたAFI / SAFIの組み合わせの1つが含まれている場合、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

図2：ラベルが1つのNLRI

- Length:

- 長さ：

The Length field consists of a single octet. It specifies the length in bits of the remainder of the NLRI field.

長さフィールドは単一のオクテットで構成されます。 NLRIフィールドの残りの部分の長さをビットで指定します。

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.

長さは常に20（Labelフィールドのビット数）、3（Rsrvフィールドのビット数）、1（Sフィールドのビット数）、およびプレフィックスのビット数の長さの合計になることに注意してください。。

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.

AFI / SAFIが1/4であるMP_REACH_NLRI属性では、プレフィックス長は32ビット以下になります。 AFI / SAFIが2/4のMP_REACH_NLRI属性では、プレフィックス長は128ビット以下になります。 SAFIが128のMP_REACH_NLRI属性では、AFIが1の場合、プレフィックスは96ビット以下になり、AFIが2の場合、プレフィックスは192ビット以下になります。

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.

[RFC4760]で指定されているように、NLRIフィールドの実際の長さは、長さフィールドで指定されたビット数であり、最も近いオクテットの整数に切り上げられます。

- Label:

- ラベル：

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

ラベルフィールドは、MPLSラベル値を含む20ビットのフィールドです（[RFC3032]を参照）。

- Rsrv:

- Rsrv：

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

この3ビットフィールドは送信時にゼロに設定する必要があり（SHOULD）、受信時には無視する必要があります。

- S:

- S：

This 1-bit field MUST be set to one on transmission and MUST be ignored on reception.

この1ビットフィールドは、送信時に1に設定する必要があり、受信時には無視する必要があります。

Note that the UPDATE message not only advertises 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.

UPDATEメッセージは、プレフィックスとラベル間のバインディングをアドバタイズするだけでなく、MP_REACH_NLRI属性の[ネクストホップのネットワークアドレス]フィールドで識別されるノードを介してプレフィックスへのパスもアドバタイズすることに注意してください。

[RFC3107] requires that if only a single label is bound to a prefix, the S bit must be set. If the S bit is not set, [RFC3107] specifies that additional labels will appear in the NLRI. However, some implementations assume that the NLRI will contain only a single label and thus do not check the setting of the S bit. The procedures specified in the current document will interwork with such implementations. As long as the Multiple Labels Capability is not 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.

[RFC3107]では、1つのラベルのみがプレフィックスにバインドされている場合、Sビットを設定する必要があります。 Sビットが設定されていない場合、[RFC3107]は、NLRIに追加のラベルが表示されることを指定します。ただし、一部の実装では、NLRIに含まれるラベルは1つだけであるため、Sビットの設定はチェックされません。現在のドキュメントで指定されている手順は、そのような実装と相互に作用します。複数のラベル機能が特定のBGPセッションで両方のBGPスピーカーによって送受信されない限り、このドキュメントでは、NLRIでラベルを1つだけ指定し、Sビットを送信時に設定し、それを無視することを要求しています。受信。

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.

[RFC7911]の手順が使用されている場合、4オクテットの「パス識別子」（[RFC7911]のセクション3で定義）はNLRIの一部であり、長さフィールドの前にあります。

2.3. NLRI Encoding When the Multiple Labels Capability Is Used

2.3. 複数のラベル機能が使用されている場合のNLRIエンコーディング

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:

複数のラベル機能が特定のBGPセッションで送受信された場合、そのセッションのBGP UPDATEで、MP_REACH_NLRI属性がセクション2で指定されたAFI / SAFIの組み合わせの1つを含む場合、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                               ~
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: NLRI with Multiple Labels

図3：複数のラベルを持つNLRI

- Length:

- 長さ：

The Length field consists of a single octet. It specifies the length in bits of the remainder of the NLRI field.

長さフィールドは単一のオクテットで構成されます。 NLRIフィールドの残りの部分の長さをビットで指定します。

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

ラベルごとに、長さが24ビット（Labelフィールドの20ビット、Rsrvフィールドの3ビット、1 Sビット）ずつ増加することに注意してください。

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.

[RFC4760]で指定されているように、NLRIフィールドの実際の長さは、オクテットの最も近い整数に切り上げられた長さフィールドで指定されたビット数になります。

- Label:

- ラベル：

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

ラベルフィールドは、MPLSラベル値を含む20ビットのフィールドです（[RFC3032]を参照）。

- Rsrv:

- Rsrv：

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

この3ビットフィールドは送信時にゼロに設定する必要があり（SHOULD）、受信時には無視する必要があります。

- S:

- S：

In all labels except the last (i.e., in all labels except the one immediately preceding the prefix), the S bit MUST be 0. In the last label, the S bit MUST be 1.

最後を除くすべてのラベル（つまり、プレフィックスの直前のラベルを除くすべてのラベル）では、Sビットは0でなければなりません。最後のラベルでは、Sビットは1でなければなりません。

Note that failure to set the S bit in the last label will make it impossible to parse the NLRI correctly. See Section 3, paragraph j of [RFC7606] for a discussion of error handling when the NLRI cannot be parsed.

最後のラベルでSビットを設定しないと、NLRIを正しく解析できなくなることに注意してください。 NLRIを解析できない場合のエラー処理については、[RFC7606]のセクション3のパラグラフjを参照してください。

Note that the UPDATE message not only advertises the binding between the prefix and the labels, it also advertises a path to the prefix via the node identified in the Next Hop field of the MP_REACH_NLRI attribute.

UPDATEメッセージは、プレフィックスとラベルの間のバインディングをアドバタイズするだけでなく、MP_REACH_NLRI属性のNext Hopフィールドで識別されるノードを介してプレフィックスへのパスもアドバタイズすることに注意してください。

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.4. How to Explicitly Withdraw the Binding of a Label to a Prefix

2.4. プレフィックスへのラベルのバインディングを明示的に撤回する方法

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

図4：引き出しのNLRI

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

送信時に、互換性フィールドは0x800000に設定する必要があります。受信時には、互換性フィールドの値を無視する必要があります。

This encoding is used for explicitly withdrawing the binding (on a given BGP session) between the specified prefix and whatever label or sequence of labels had previously been bound by the procedures of this document to that prefix on the given session. This encoding is used whether or not the Multiple Labels Capability has been sent or received on the session. Note that label/prefix bindings that were not advertised on the given session cannot be withdrawn by this method. (However, 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 the previous session, then this withdrawal method may be used.)

このエンコーディングは、指定されたプレフィックスと、このドキュメントの手順によって以前に特定のセッションでそのプレフィックスにバインドされていたラベルまたはラベルのシーケンスとの間の（特定のBGPセッションで）バインディングを明示的に撤回するために使用されます。このエンコーディングは、マルチラベル機能がセッションで送信または受信されたかどうかに関係なく使用されます。特定のセッションでアドバタイズされなかったラベル/プレフィックスバインディングは、このメソッドでは撤回できないことに注意してください。（ただし、バインディングが同じピアを持つ前のセッションでアドバタイズされ、現在のセッションが前のセッションの「グレースフルリスタート」（[RFC4724]）の結果である場合、この撤回方法を使用できます。）

When using 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 respective prefixes must match, and the respective AFI/SAFIs must match. If the procedures of [RFC7911] are being used, the respective values of the "path identifier" fields must match as well. Note that the prefix length is not the same as the NLRI length; to determine the prefix length of a prefix in an MP_UNREACH_NLRI, the length of the Compatibility field must be subtracted from the length of the NLRI.

MP_UNREACH_NLRI属性を使用して、以前にMP_REACH_NLRI属性でNLRIが指定されたルートを撤回する場合、それぞれのプレフィックスの長さと値が一致し、それぞれのAFI / SAFIが一致する必要があります。 [RFC7911]の手順を使用している場合、「パス識別子」フィールドのそれぞれの値も一致する必要があります。プレフィックス長はNLRI長と同じではないことに注意してください。 MP_UNREACH_NLRI内のプレフィックスのプレフィックス長を決定するには、NLRIの長さから互換性フィールドの長さを差し引く必要があります。

An explicit withdrawal in a SAFI-x UPDATE on a given BGP session not only withdraws 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.

特定のBGPセッションのSAFI-x UPDATEでの明示的な撤回は、プレフィックスとラベル間のバインディングを撤回するだけでなく、そのセッションのSAFI-x UPDATEで以前にアドバタイズされたそのプレフィックスへのパスも撤回します。

[RFC3107] made it possible to specify a particular label value in the Compatibility field. However, the functionality that required the presence of a particular label value (or sequence of label values) was never implemented, and that functionality is not present in the current document. Hence, 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]は、互換性フィールドで特定のラベル値を指定することを可能にしました。ただし、特定のラベル値（または一連のラベル値）の存在を必要とする機能は実装されておらず、その機能は現在のドキュメントには存在しません。したがって、このフィールドの値は重要ではありません。このフィールドにラベル値またはラベル値のシーケンスが含まれる理由はありません。

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

[RFC3107]は、互換性フィールドを0x800000に設定することにより、ラベルを明示的に指定せずにバインディングを撤回することも可能にしました。ただし、一部の実装では0x000000に設定されています。下位互換性を確保するために、このドキュメントでは、互換性フィールドを0x800000に設定することをお勧めしますが、受信時には無視する必要があります。

2.5. Changing the Label That Is Bound to a Prefix

2.5. 接頭辞にバインドされているラベルの変更

Suppose 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 specified above, this indicates that label (or sequence of labels) L1 is bound to prefix P at node N1. Suppose that S1 now 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.

BGPスピーカーS1が、特定のBGPセッションで、ラベル（または一連のラベル）L1、プレフィックスP、およびネクストホップN1を指定するSAFI-4またはSAFI-128 UPDATE U1を受信したとします。上記のように、これは、ラベル（またはラベルのシーケンス）L1がノードN1でプレフィックスPにバインドされていることを示します。 S1が同じセッションで、ラベル（またはラベルのシーケンス）L2、プレフィックスP、および同じネクストホップN1を指定する同じAFI / SAFIのUPDATE U2を受信するとします。

o 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. That is, the UPDATE U1 is implicitly withdrawn and is replaced by UPDATE U2.

o [RFC7911]が使用されていない場合、UPDATE U2は、L2がN1でPにバインドされ、L1がN1でPにバインドされなくなったことを意味すると解釈する必要があります。つまり、UPDATE U1は暗黙的に撤回され、UPDATE U2に置き換えられます。

o Suppose that [RFC7911] is being used, that UPDATE U1 has Path Identifier I1, and that UPDATE U2 has Path Identifier I2.

o [RFC7911]が使用されていて、UPDATE U1にパスID I1があり、UPDATE U2にパスID 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.

* I1がI2と同じである場合、UPDATE U2は、L2がN1でPにバインドされ、L1がN1でPにバインドされなくなったことを意味すると解釈する必要があります。 UPDATE U1は暗黙的に撤回されます。

* 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 (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.)

* I1がI2と同じでない場合、U2は、L2がN1でPにバインドされていることを意味すると解釈しなければなりませんが、U2は、L1がN1でPにバインドされていないことを意味してはなりません。特定の条件下（仕様はこのドキュメントの範囲外です）では、S1はU1で表されるパスとU2で表されるパスの間でトラフィックの負荷分散を選択できます。 U1で表されるパスでトラフィックを送信するために、S1はU1でアドバタイズされたラベルを使用します。 U2で表されるパスでトラフィックを送信するために、S1はU2でアドバタイズされたラベルを使用します。（これらの2つのパスのネクストホップは同じですが、さらに下流に分岐すると想定する必要があります。）

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. Suppose that S1 now 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 an indication that N1 has at least two paths to P, and S1 MAY use this fact to do load-balancing of any traffic that it has to send to P.

BGPスピーカーS1が、所定のBGPセッションで、ラベルL1、プレフィックスP、およびネクストホップN1を指定するSAFI-4またはSAFI-128 UPDATEを受信したとします。 S1が、別のBGPセッションで、ラベルL2、プレフィックスP、および同じネクストホップN1を指定する同じAFI / SAFIのUPDATEを受信するとします。 BGPスピーカーS1は、これをN1がPへの少なくとも2つのパスを持っていることを示すものとして扱う必要があり、S1はこの事実を使用して、Pに送信する必要のあるトラフィックの負荷分散を行うことができます。

Note that this section discusses only 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].

このセクションでは、2つのUPDATEのネクストホップが同じである場合についてのみ説明します。 2つのUPDATEのネクストホップが異なる場合の手順は、[RFC4271]で適切に説明されています。

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

3. SAFI-4またはSAFI-128ルートのインストールまたは伝播、あるいはその両方

3.1. Comparability of Routes

3.1. ルートの比較可能性

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

BGPスピーカーが、同じプレフィックスと次のいずれかを指定する2つのSAFI-4 UPDATEを受信したとします。

o the two UPDATEs are received on different BGP sessions; or

o 2つのUPDATEが異なるBGPセッションで受信されます。または

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

o 2つのUPDATEは同じセッションで受信され、add-pathsはそのセッションで使用され、2つのUPDATEのNLRIは異なるパス識別子を持っています。

These two routes MUST be considered to be comparable, even if they specify different labels. Thus, 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.

これらの2つのルートは、異なるラベルを指定している場合でも、比較可能であると見なす必要があります。したがって、BGPの最適パス選択手順（[RFC4271]のセクション9.1を参照）を適用して、そのうちの1つをより適切なパスとして選択します。 [RFC7911]の手順が特定のBGPセッションで使用されていない場合、最適なパスのみがそのセッションで伝搬されます。 [RFC7911]の手順が特定のBGPセッションで使用されている場合、パスIDは異なりますが、両方のパスがそのセッションで伝播される可能性があります。

The same applies to SAFI-128 routes.

SAFI-128ルートにも同じことが当てはまります。

3.2. Modification of Label(s) Field When Propagating

3.2. 伝播時のラベルフィールドの変更

3.2.1. When the Next Hop Field Is Unchanged

3.2.1. ネクストホップフィールドが変更されていない場合

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.

SAFI-4またはSAFI-128ルートが伝播されるとき、ネクストホップのネットワークアドレスフィールドが変更されないままである場合、ラベルフィールドも変更されないままにする必要があります。

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

ルートのNLRIに複数のラベルがあるが、マルチラベル機能がピアとネゴシエートされていない場合、特定のルートを特定のピアに伝播してはならないことに注意してください。同様に、ルートのNLRIに、ピアが処理できることを（マルチラベル機能を介して）アナウンスしたよりも多くのラベルがある場合、そのルートを特定のピアに伝播してはなりません（MUST NOT）。どちらの場合も、同じAFI、SAFI、およびプレフィックスを持つ（ただしラベルが少ない）以前のルートがすでにピアに伝達されている場合は、2.4で指定された手順を使用して、そのルートからそのルートを撤回する必要があります。

3.2.2. When the Next Hop Field Is Changed

3.2.2. ネクストホップフィールドが変更されたとき

If the Network Address of Next Hop field is changed before a SAFI-4 or SAFI-128 route is 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.

SAFI-4またはSAFI-128ルートが伝達される前に次ホップのネットワークアドレスフィールドが変更された場合、伝達されたルートのラベルフィールドには、プレフィックスにバインドされているラベルが含まれている必要があります。新しいネクストホップ。

Suppose BGP speaker S1 has received an UPDATE that binds a particular sequence of one or more labels to a particular prefix. If S1 chooses to propagate this route after changing its next hop, S1 may change the label in any of the following ways, depending upon local policy:

BGPスピーカーS1が、1つ以上のラベルの特定のシーケンスを特定のプレフィックスにバインドするUPDATEを受信したとします。 S1が次のホップを変更した後でこのルートを伝播することを選択した場合、S1はローカルポリシーに応じて、次のいずれかの方法でラベルを変更できます。

o A single label may be replaced by a single label of the same or different value.

o 単一のラベルは、同じ値または異なる値の単一のラベルで置き換えることができます。

o A sequence of multiple labels may be replaced by a single label.

o 複数のラベルのシーケンスは、単一のラベルで置き換えることができます。

o A single label may be replaced by a sequence of multiple labels.

o 単一のラベルは、複数のラベルのシーケンスで置き換えることができます。

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

o 複数のラベルのシーケンスは、複数のラベルのシーケンスで置き換えることができます。ラベルの数は同じままにするか、変更することができます。

Of course, when deciding whether to propagate, to a given BGP peer, an UPDATE binding a sequence of more than one label, a BGP speaker must attend to the information provided by the Multiple Labels Capability (see Section 2.1). A BGP speaker MUST NOT send multiple labels to a peer with which it has not exchanged the Multiple Labels Capability and MUST NOT send more labels to a given peer than the peer has announced (via the Multiple Labels Capability) than it can handle.

もちろん、複数のラベルのシーケンスをバインドするUPDATEを特定のBGPピアに伝播するかどうかを決定する場合、BGPスピーカーはマルチラベル機能によって提供される情報に注意する必要があります（セクション2.1を参照）。 BGPスピーカーは、複数のラベル機能を交換していないピアに複数のラベルを送信してはならず、ピアが（複数のラベル機能を介して）処理できる以上にラベルを特定のピアに送信してはなりません（MUST NOT）。

It is possible that a BGP speaker's local policy will tell it to encode N labels in a given route's NLRI before propagating the route, but that one of the BGP speaker's peers cannot handle N labels in the NLRI. In this case, the BGP speaker has two choices:

BGPスピーカーのローカルポリシーは、ルートを伝播する前に、特定のルートのNLRIでNラベルをエンコードするように指示する可能性がありますが、BGPスピーカーのピアの1つがNLRIでNラベルを処理できない可能性があります。この場合、BGPスピーカーには2つの選択肢があります。

o It can propagate the route to the given peer with fewer than N labels; however, whether this makes sense, and if so, how to choose the labels, is also a matter of local policy.

o N未満のラベルを持つ特定のピアにルートを伝播できます。ただし、これが理にかなっているかどうか、もしそうであれば、ラベルを選択する方法も、ローカルポリシーの問題です。

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

o ルートを特定のピアに伝播しないことを決定できます。その場合、同じAFI、SAFI、およびプレフィックスを持つ（ただしラベルは少ない）以前のルートがすでにそのピアに伝達されている場合、そのルートはセクション2.4の手順を使用してそのピアから撤回する必要があります。

4. Data Plane

4. データプレーン

In the following, we will use the phrase "node S tunnels packet P to node N", where packet P is an MPLS packet. By this phrase, we mean 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.

以下では、「ノードSがパケットPをノードNにトンネルする」というフレーズを使用します。ここで、パケットPはMPLSパケットです。このフレーズは、ノードSがパケットPをカプセル化し、カプセル化前のPのラベルスタックがNによって変更されずに見えるがノード（存在する場合）からは見えないように、パケットPをノードNに配信することを意味しますSと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 upon the particular deployment scenario.

トンネルがラベルスイッチドパス（LSP）の場合、パケットのカプセル化は、別のMPLSラベルをプッシュするのと同じくらい簡単です。ノードNがノードSのレイヤ2隣接である場合、必要なのはレイヤ2カプセル化だけです。特定の展開シナリオに応じて、他の種類のトンネル（IPトンネル、GREトンネル、UDPトンネルなど）も使用できます。

Suppose 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 suppose S1 installs this route as its (or one of its) best path(s) towards P. And suppose S1 propagates this route after changing the next hop to itself and changing the label to L2. Suppose further that S1 receives an MPLS data packet and, in the process of forwarding that MPLS data packet, S1 sees label L2 rise to the top of the packet's label stack. Then, to forward the packet further, S1 must replace L2 with L1 as the top entry in the packet's label stack, and S1 must then tunnel the packet to N1.

BGPスピーカーS1が、ラベルL1、プレフィックスP、およびネクストホップN1を指定するMP_REACH_NLRIを使用してSAFI-4またはSAFI-128 BGP UPDATEを受信し、S1がこのルート（またはその1つ）への最適なパスとしてこのルートをインストールするとしますP.そして、ネクストホップをそれ自体に変更し、ラベルをL2に変更した後、S1がこのルートを伝播するとします。さらに、S1がMPLSデータパケットを受信し、そのMPLSデータパケットを転送するプロセスで、S1がラベルL2がパケットのラベルスタックの最上位に上昇しているのを確認するとします。次に、パケットをさらに転送するために、S1はL2をパケットのラベルスタックの最上位エントリとしてL1に置き換え、S1はパケットをN1にトンネリングする必要があります。

Suppose that the route received by S1 specified not 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. And suppose again that S1 propagates this route after changing the next hop to itself and changing the Label field to the single label L2. Suppose further that S1 receives an MPLS data packet, and in the process of forwarding that MPLS data packet, S1 sees label L2 rise to the top of the packet's label stack. In this case, 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 such that L11 is now at the top of the label stack. 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 above paragraph 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 specified in the NLRI of that route with a single label. However, it is 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.

S1によって受信されたルートが単一のラベルではなく、一連のk個のラベル<L11、L12、...、L1k>を指定したとします。ここで、L11はNLRIに現れる最初のラベルで、L1kは最後です。また、ネクストホップをそれ自体に変更し、Labelフィールドを単一のラベルL2に変更した後、S1がこのルートを伝播するとします。さらに、S1がMPLSデータパケットを受信し、そのMPLSデータパケットを転送する過程で、S1はラベルL2がパケットのラベルスタックの最上位に上昇していることを確認します。この場合、L2をL1に置き換えるのではなく、S1はL2をラベルスタックの最上部から削除し、ラベルL1kからL11をラベルスタックにプッシュして、L11がラベルスタックの最上部になるようにします。次に、S1はパケットをN1にトンネリングする必要があります。（L1kはパケットのラベルスタックの最下部にないため、L2が以前にパケットのラベルスタックの最下部になかった場合を除き、「スタックの最下部」ビットが設定されないことに注意してください。）上記の段落では、S1ネクストホップをそれ自体に設定した後、SAFI-4またはSAFI-128ルートを伝播し、そのルートのNLRIで指定された1つまたは複数のラベルを単一のラベルに置き換えます。ただし、ローカルポリシーで決定されているように、BGPスピーカーがネクストホップを自分自身に設定した後でSAFI-4またはSAFI-128ルートを伝播するときに複数のラベルを指定することもできます。

Suppose, for example, that 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>.

たとえば、S1がコンテキストラベル（[RFC5331]）をサポートしているとします。 L21をS1がサポートするコンテキストラベルとし、L22をL21によって（S1で）識別されたラベル空間にあるラベルとします。 S1が、プレフィックスがP、ラベルフィールドが<L11、L12、...、L1k>で次のホップがN1であるSAFI-4またはSAFI-128 UPDATEを受信するとします。 UPDATEを伝達する前に、S1は（N1をS1で置き換えることにより）ネクストホップをそれ自体に設定し、ラベルスタック<L11、L12、...、L1k>をラベルのペア<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 do not know how S1 will interpret L21 (or L22).

この場合、S1がトップラベルがL21、2番目のラベルがL22のMPLSデータパケットを受信すると、S1はL21とL22の両方をラベルスタックから削除し、<L11、L12、...、L1k>に置き換えます。 L21がコンテキストラベルであることはS1だけが知っていることに注意してください。他のBGPスピーカーは、S1がL21（またはL22）を解釈する方法を知りません。

The ability to replace one or more labels by one or more labels can provide great flexibility, but it must 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. And suppose that 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 that 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.

1つまたは複数のラベルを1つまたは複数のラベルに置き換える機能により、柔軟性が大幅に向上しますが、慎重に行う必要があります。 S1が、プレフィックスP、ラベルスタック<L11、L12、...、L1k>、およびネクストホップN1を指定するUPDATEを受信したと再び仮定します。また、ネクストホップセルフを設定した後、Labelフィールドを<L21、L22、...、L2k>で置き換えた後、S1がこのUPDATEをBGPスピーカーS2に伝播するとします。最後に、S1がデータプレーンをプログラムして、トップラベルがL21である受信MPLSパケットを処理するときに、L21を<L11、L12、...、L1k>に置き換え、パケットをN1にトンネリングするとします。

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 provide unintended results in other scenarios.

この場合、BGPスピーカーS2は、プレフィックスP、ラベルフィールド<L21、L22、...、L2k>、およびネクストホップS1を持つルートを受信します。 S2がこのルートに従ってIPパケットを転送することを決定した場合、<L21、L22、...、L2k>をパケットのラベルスタックにプッシュし、パケットをS1にトンネリングします。 S1はL21を<L11、L12、...、L1k>に置き換え、パケットをN1にトンネリングします。 N1は、<L11、L12、...、L1k、L22、...、L2k>のラベルスタックを持つパケットを受信します。これは特定のシナリオで役立つ場合がありますが、他のシナリオでは意図しない結果になる可能性があります。

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 does not specify any set of rules for setting these fields; that is a matter of local policy.

パケットのラベルスタックにラベルをプッシュする場合、各ラベルスタックエントリの存続可能時間（TTL）フィールド（[RFC3032]、[RFC3443]）およびトラフィッククラス（TC）フィールド（[RFC3032]、[RFC5462]）もちろん、設定する必要があります。このドキュメントでは、これらのフィールドを設定するための一連の規則を指定していません。それは地方政策の問題です。

This document does not specify any new rules for processing the label stack of an incoming data packet.

このドキュメントでは、着信データパケットのラベルスタックを処理するための新しいルールを指定していません。

It is a matter of local policy 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. 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. And 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.

SAFI-4ルートをIPパケットの転送の基礎として使用できるかどうか、またはSAFI-4ルートをMPLSパケットの転送のみに使用できるかどうかは、ローカルポリシーの問題です。 BGPスピーカーS1がSAFI-4ルートに従ってIPパケットを転送している場合、宛先アドレスがDのIPパケットを検討してください。Pは、IPパケットの転送に使用されているルートの中から、Dの「最長プレフィックス一致」です。また、パケットが、プレフィックスがP、ネクストホップがN1、ラベルのシーケンスがL1であるSAFI-4ルートに従って転送されているとします。このルートに従ってパケットを転送するには、S1がパケットのラベルスタックを作成し、一連のラベルL1をプッシュしてから、パケットをN1にトンネリングする必要があります。

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

5. SAFI-4ルートとSAFI-1ルートの関係

It is 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 treat this situation in different ways.

BGPスピーカーがプレフィックスPのSAFI-1ルートとプレフィックスPのSAFI-4ルートの両方を受信する可能性があります。実装が異なると、この状況は異なる方法で処理されます。

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.

たとえば、実装によっては、SAFI-1ルートとSAFI-4ルートを完全に独立していると見なして、「夜の船」のように扱う場合があります。この場合、2つのSAFIの最適パス選択は独立しており、Pへの最適なSAFI-1ルートとPへの最適なSAFI-4ルートがあります。どのSAFIのルートに従って転送されるパケットその場合、ローカルポリシーの問題です。

Other implementations may treat the SAFI-1 and SAFI-4 routes for a given prefix as comparable, such 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.

他の実装では、プレフィックスPへの最適なルートがSAFI-1ルートまたはSAFI-4ルートのいずれかであるが両方ではないように、特定のプレフィックスのSAFI-1およびSAFI-4ルートを同等として扱う場合があります。そのような実装では、負荷分散が等コストルートのセット間で行われる場合、等コストルートの一部はSAFI-1ルートであり、一部はSAFI-4ルートである可能性があります。これが許可されるかどうかは、やはりローカルポリシーの問題です。

Some implementations may allow a single BGP session to carry UPDATEs of both SAFI-1 and SAFI-4; 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.

一部の実装では、単一のBGPセッションでSAFI-1とSAFI-4の両方のUPDATEを伝送できる場合があります。他の実装ではこれを許可しない場合があります。同じセッションで両方のSAFIを許可する一部の実装では、特定のセッションでのプレフィックスPのSAFI-1ルートの受信を、そのセッションのプレフィックスPの以前のSAFI-4ルートの暗黙的な撤回として扱い、逆の場合も同様です。他の実装では動作が異なる場合があります。

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.

BGPスピーカーは、特定のBGPセッションを介してSAFI-4ルートを受信できますが、SAFI-4が有効になっていない他のBGPセッションがある場合があります。この場合、BGPスピーカーはSAFI-4ルートをSAFI-1ルートに変換してから、SAFI-4が有効になっていないセッションを介して結果を伝播する場合があります。これが行われるかどうかは、ローカルポリシーの問題です。

These differences in the behavior of different 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

6. IANAに関する考慮事項

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

IANAは、このドキュメントを参照として、BGP「機能コード」レジストリで複数のラベル機能に値8を割り当てています。

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は、このドキュメントを参照として、値4（「宛先機能への複数のルート」）を非推奨としてマークするようにBGP「機能コード」レジストリを変更しました。

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

IANAは、「後続のアドレスファミリ識別子（SAFI）パラメータ」レジストリにあるSAFI 4の参照をこのドキュメントに変更しました。

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

また、IANAはこのドキュメントをSAFI 128の参照として同じレジストリに追加しました。

7. Security Considerations

7. セキュリティに関する考慮事項

The security considerations of BGP (as specified in [RFC4271]) apply.

BGPのセキュリティに関する考慮事項（[RFC4271]で指定）が適用されます。

If a BGP implementation that is not conformant with the current document encodes multiple labels in the NLRI but has not sent and received the Multiple Labels Capability, a BGP implementation that does conform with the current document will likely reset the BGP session.

現在のドキュメントに準拠していないBGP実装がNLRIで複数のラベルをエンコードしているが、マルチラベル機能を送受信していない場合、現在のドキュメントに準拠しているBGP実装はBGPセッションをリセットする可能性があります。

This document specifies that certain data packets be "tunneled" from one BGP speaker to another. This requires that the packets be encapsulated while in flight. This document does not specify the encapsulation to be used. However, if a particular encapsulation is used, the security considerations of that encapsulation are applicable.

このドキュメントでは、特定のデータパケットが1つのBGPスピーカーから別のスピーカーに「トンネリング」されることを指定しています。これには、飛行中にパケットをカプセル化する必要があります。このドキュメントでは、使用するカプセル化を指定していません。ただし、特定のカプセル化が使用されている場合、そのカプセル化のセキュリティに関する考慮事項が適用されます。

If a particular tunnel encapsulation does not provide integrity and authentication, it is possible that a data packet's label stack can be modified, through error or malfeasance, while the packet is in flight. This can result in misdelivery of the packet. It should be noted that the tunnel encapsulation (MPLS) most commonly used in deployments of this specification does not provide integrity or authentication; neither do the other tunnel encapsulations mentioned in Section 4.

特定のトンネルカプセル化によって整合性と認証が提供されない場合、パケットの処理中に、エラーまたは不正行為によってデータパケットのラベルスタックが変更される可能性があります。これにより、パケットが誤って配信される可能性があります。この仕様の展開で最も一般的に使用されるトンネルカプセル化（MPLS）は整合性または認証を提供しないことに注意してください。セクション4で説明した他のトンネルカプセル化も行いません。

There are various techniques one can use to constrain the distribution of BGP UPDATE messages. If a BGP UPDATE advertises the binding of a particular label or set of labels to a particular address prefix, such techniques can be used to control the set of BGP speakers that are intended to learn of that binding. However, if BGP sessions do not provide privacy, other routers may learn of that binding.

BGP UPDATEメッセージの配信を制限するために使用できるさまざまな手法があります。 BGP UPDATEが特定のラベルまたはラベルのセットのバインディングを特定のアドレスプレフィックスにアドバタイズする場合、そのような手法を使用して、そのバインディングを学習することを目的としたBGPスピーカーのセットを制御できます。ただし、BGPセッションがプライバシーを提供しない場合、他のルーターがそのバインディングを学習する可能性があります。

When a BGP speaker processes a received MPLS data packet whose top label it advertised, there is no guarantee that the label in question was put on the packet by a router that was intended to know about that label binding. If a BGP speaker is using the procedures of this document, it may be useful for that speaker to distinguish its "internal" interfaces from its "external" interfaces and to avoid advertising the same labels to BGP speakers reached on internal interfaces as to BGP speakers reached on external interfaces. Then, a data packet can be discarded if its top label was not advertised over the type of interface from which the packet was received. This reduces the likelihood of forwarding packets whose labels have been "spoofed" by untrusted sources.

BGPスピーカーが、トップラベルがアドバタイズした受信MPLSデータパケットを処理する場合、問題のラベルが、そのラベルバインディングについて知ることを目的としたルーターによってパケットに付けられたという保証はありません。 BGPスピーカーがこのドキュメントの手順を使用している場合、そのスピーカーがその「内部」インターフェースをその「外部」インターフェースから区別し、BGPスピーカーに関して内部インターフェースで到達したBGPスピーカーに同じラベルをアドバタイズしないようにすることが役立つ場合があります。外部インターフェイスで到達。次に、データパケットは、そのトップラベルがパケットの受信元のインターフェイスのタイプでアドバタイズされなかった場合に廃棄できます。これにより、信頼できないソースによってラベルが「スプーフィング」されたパケットを転送する可能性が低くなります。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.

[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<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>.

[RFC3032]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、DOI 10.17487 / RFC3032、2001年1月、<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>.

[RFC3107] Rekhter、Y.、E。Rosen、「Carrying Label Information in BGP-4」、RFC 3107、DOI 10.17487 / RFC3107、2001年5月、<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>.

[RFC3443] Agarwal、P。およびB. Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワークでの存続時間（TTL）処理」、RFC 3443、DOI 10.17487 / RFC3443、2003年1月、<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>.

[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<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>.

[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<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>.

[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP Virtual Private Network（VPN）Extension for IPv6 VPN」、RFC 4659、DOI 10.17487 / RFC4659、 2006年9月、<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>.

[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<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>.

[RFC4798] De Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用したIPv4 MPLSを介したIPv6アイランドの接続」、RFC 4798、DOI 10.17487 / RFC4798、 2007年2月、<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>.

[RFC5462] Andersson、L。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP」Field Renamed to" Traffic Class "Field」、RFC 5462、DOI 10.17487 / RFC5462、2009年2月、<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>.

[RFC5492] Scudder、J。およびR. Chandra、「BGP-4を使用した機能の宣伝」、RFC 5492、DOI 10.17487 / RFC5492、2009年2月、<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>.

[RFC5549] Le Faucheur、F。およびE. Rosen、「Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop」、RFC 5549、DOI 10.17487 / RFC5549、2009年5月、<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>.

[RFC7606] Chen、E。、編、Scudder、J。、編、Mohapatra、P。、およびK. Patel、「BGP UPDATEメッセージのエラー処理の改訂版」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、 <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>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

8.2. Informative References

8.2. 参考引用

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

[Enhanced-GR] Patel、K.、Chen、E.、Fernando、R。、およびJ. Scudder、「BGPグレースフルリスタートの加速ルーティングコンバージェンス」、作業中、draft-ietf-idr-enhanced-gr-06 、2016年6月。

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

[RFC4724] Sangli、S.、Chen、E.、Fernando、R.、Scudder、J。、およびY. Rekhter、「BGPのグレースフルリスタートメカニズム」、RFC 4724、DOI 10.17487 / RFC4724、2007年1月、<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>.

[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<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>.

[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、< 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>.

[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、2015年2月、<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>.

[RFC7911] Walton、D.、Retana、A.、Chen、E.、J。Scudder、「Advertisement of Multiple Paths in BGP」、RFC 7911、DOI 10.17487 / RFC7911、2016年7月、<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.

[TUNNEL-ENCAPS]ローゼン、E。、パテル、K。、およびG.ベルデ、「BGPトンネルカプセル化属性」、作業中、draft-ietf-idr-tunnel-encaps-07、2017年7月。

Acknowledgements

謝辞

This document obsoletes RFC 3107. We wish to thank Yakov Rekhter, co-author of RFC 3107, for his work on that document. We also wish to thank Ravi Chandra, Enke Chen, Srihari R. Sangli, Eric Gray, and Liam Casey for their review of and comments on that document.

このドキュメントはRFC 3107を廃止します。RFC3107の共同執筆者であるYakov Rekhter氏がこのドキュメントを執筆してくれたことに感謝します。また、Ravi Chandra、Enke Chen、Srihari R. Sangli、Eric Gray、Liam Caseyのレビューとコメントに感謝します。

We thank Alexander Okonnikov and David Lamparter for pointing out a number of the errors in RFC 3107.

RFC 3107の多くのエラーを指摘してくれたAlexander OkonnikovとDavid Lamparterに感謝します。

We wish to thank Lili Wang and Kaliraj Vairavakkalai for their help and advice during the preparation of this document.

このドキュメントの作成中のLili Wang氏とKaliraj Vairavakkalai氏の支援とアドバイスに感謝します。

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 their review of and comments on this document.

また、このドキュメントのレビューとコメントを提供してくれたMach Chen、Bruno Decraene、Jie Dong、Adrian Farrel、Jeff Haas、Jonathan Hardwick、Jakob Heitz、Alexander Okonnikov、Keyur Patel、Kevin Wang、Lucy Yongにも感謝します。

Author's Address

著者のアドレス

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

エリックC.ローゼンジュニパーネットワークス社10テクノロジーパークドライブマサチューセッツ州ウェストフォード01886アメリカ合衆国

   Email: erosen@juniper.net