Internet Engineering Task Force (IETF) S. Sivabalan
Request for Comments: 9604 Ciena Corporation
Category: Standards Track C. Filsfils
ISSN: 2070-1721 Cisco Systems, Inc.
J. Tantsura
Nvidia
S. Previdi
C. Li, Ed.
Huawei Technologies
August 2024
In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (BSID), as described in RFC 8402. It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering (TE) Label Switched Path (LSP) or an SR TE path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the concept of binding value, which can be either an MPLS label or a Segment Identifier (SID). It further specifies an extension to Path Computation Element Communication Protocol (PCEP) for reporting the binding value by a Path Computation Client (PCC) to the Path Computation Element (PCE) to support PCE-based TE policies.
より大きなスケーラビリティ、ネットワークの機密性、およびサービスの独立性を提供するために、RFC 8402に記載されているように、セグメントルーティング（SR）はバインディングセグメント識別子（BSID）を利用します。（TE）ラベルスイッチ付きパス（LSP）またはSR TEパス。BSIDは、SRポリシーを実施するために適切なTEパスにトラフィックを導くために、上流ノードで使用できます。このドキュメントは、MPLSラベルまたはセグメント識別子（SID）のいずれかである可能性のあるバインディング値の概念を指定します。さらに、PATH計算クライアント（PCC）によるバインディング値をPATH計算要素（PCC）によると、PCEベースのTEポリシーをサポートするためのパス計算要素通信プロトコル（PCEP）への拡張を指定します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc9604.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9604で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Motivation and Example
1.2. Summary of the Extension
2. Requirements Language
3. Terminology
4. Path Binding TLV
4.1. SRv6 Endpoint Behavior and SID Structure
5. Operation
6. Binding SID in SR-ERO
7. Binding SID in SRv6-ERO
8. PCE Allocation of Binding Label/SID
9. Security Considerations
10. Manageability Considerations
10.1. Control of Function and Policy
10.2. Information and Data Models
10.3. Liveness Detection and Monitoring
10.4. Verify Correct Operations
10.5. Requirements on Other Protocols
10.6. Impact on Network Operations
11. IANA Considerations
11.1. PCEP TLV Type Indicators
11.1.1. TE-PATH-BINDING TLV
11.2. LSP Object
11.3. PCEP Error Type and Value
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network where those paths are subject to various constraints. Currently, TE paths are set up using either the RSVP-TE signaling protocol or Segment Routing (SR). We refer to such paths as "RSVP-TE paths" and "SR-TE paths", respectively, in this document.
パス計算要素（PCE）は、それらのパスがさまざまな制約の対象となるネットワークを通るトラフィックエンジニアリング（TE）パスを計算できます。現在、TEパスは、RSVP-TEシグナル伝達プロトコルまたはセグメントルーティング（SR）のいずれかを使用してセットアップされています。このドキュメントでは、それぞれ「RSVP-TEパス」や「SR-TEパス」などのパスを参照します。
As per [RFC8402], SR allows a head-end node to steer a packet flow along a given path via an SR Policy. As per [RFC9256], an SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy with a specific intent for traffic steering from that node.
[RFC8402]によると、SRはヘッドエンドノードがSRポリシーを介して特定のパスに沿ってパケットフローを操縦することを許可します。[RFC9256]によると、SRポリシーは、そのノードからのトラフィックステアリングを目的としたソースルーティングポリシーを実装するためのノード上のセグメントの順序付きリストのインスタンス化を可能にするフレームワークです。
As described in [RFC8402], a Binding SID (BSID) is bound to an SR Policy, instantiation of which may involve a list of Segment Identifiers (SIDs). Any packets received with an active segment equal to a BSID are steered onto the bound SR Policy. A BSID may be either a local (SR Local Block (SRLB)) or a global (SR Global Block (SRGB)) SID. As per Section 6.4 of [RFC9256], a BSID can also be associated with any type of interface or tunnel to enable the use of a non-SR interface or tunnel as a segment in a SID list. In this document, the term "binding label/SID" is used to generalize the allocation of a binding value for both SR and non-SR paths.
[RFC8402]で説明されているように、結合SID（BSID）はSRポリシーに結合され、そのインスタンス化にはセグメント識別子のリスト（SIDS）が含まれる場合があります。BSIDに等しいアクティブセグメントで受信されたパケットは、バインドされたSRポリシーに操縦されます。BSIDは、ローカル（SRローカルブロック（SRLB））またはグローバル（SRグローバルブロック（SRGB））SIDのいずれかです。[RFC9256]のセクション6.4によると、BSIDは、SIDリストのセグメントとして非SRインターフェイスまたはトンネルを使用できるようにするために、あらゆるタイプのインターフェイスまたはトンネルにも関連付けられます。このドキュメントでは、「バインディングラベル/SID」という用語を使用して、SRパスと非SRパスの両方のバインディング値の割り当てを一般化します。
[RFC5440] describes the PCEP for communication between a Path Computation Client (PCC) and a PCE or between a pair of PCEs as per [RFC4655]. [RFC8231] specifies extensions to PCEP that allow a PCC to delegate its Label Switched Paths (LSPs) to a stateful PCE. A stateful PCE can then update the state of LSPs delegated to it. [RFC8281] specifies a mechanism allowing a PCE to dynamically instantiate an LSP on a PCC by sending the path and characteristics. This document specifies an extension to PCEP to manage the binding of label/SID that can be applied to SR, RSVP-TE, and other path setup types.
[RFC5440]は、[RFC4655]に従って、パス計算クライアント（PCC）とPCEまたはPCEのペア間の通信のPCEPを説明しています。[RFC8231]は、PCCがラベルスイッチ付きパス（LSP）をステートフルなPCEに委任できるようにするPCEPへの拡張機能を指定します。ステートフルPCEは、委任されたLSPの状態を更新できます。[RFC8281]は、PCEがパスと特性を送信してPCCのLSPを動的にインスタンス化できるメカニズムを指定します。このドキュメントは、SR、RSVP-TE、およびその他のパスセットアップタイプに適用できるラベル/SIDのバインディングを管理するためのPCEPへの拡張機能を指定します。
[RFC8664] provides a mechanism for a PCE (acting as a network controller) to instantiate SR-TE paths (candidate paths) for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For more information on the SR Policy Architecture, see [RFC9256].
[RFC8664]は、PCEPを使用してヘッドエンドノード（PCCとして機能する）にSRポリシーのSR-TEパス（候補パス）をインスタンス化するためのPCE（ネットワークコントローラーとして機能する）のメカニズムを提供します。SRポリシーアーキテクチャの詳細については、[RFC9256]を参照してください。
A binding label/SID has local significance to the ingress node of the corresponding TE path. When a stateful PCE is deployed for setting up TE paths, a binding label/SID reported from the PCC to the stateful PCE is useful for enforcing an end-to-end TE/SR policy. A sample Data Center (DC) and IP/MPLS WAN use case is illustrated in Figure 1 with a multi-domain PCE. In the IP/MPLS WAN, an SR-TE LSP is set up using the PCE. The list of SIDs of the SR-TE LSP is {A, B, C, D}. The gateway Node-1 (which is the PCC) allocates a binding SID X and reports it to the PCE. In the MPLS DC network, an end-to-end SR-TE LSP is established. In order for the access node to steer the traffic towards Node-1 and over the SR-TE path in WAN, the PCE passes the SID stack {Y, X} where Y is the node SID of the gateway Node-1 to the access node and X is the BSID. In the absence of the BSID X, the PCE would need to pass the SID stack {Y, A, B, C, D} to the access node. This example also illustrates the additional benefit of using the binding label/SID to reduce the number of SIDs imposed by the access nodes with a limited forwarding capacity.
バインディングラベル/SIDは、対応するTEパスの侵入ノードに対して局所的な重要性を持っています。TE PATHSのセットアップのためにステートフルPCEが展開されると、PCCからStateful PCEに報告された拘束力のあるラベル/SIDは、エンドツーエンドのTE/SRポリシーを施行するのに役立ちます。サンプルデータセンター（DC）およびIP/MPLS WANユースケースを図1に、マルチドメインPCEを使用して示しています。IP/MPLS WANでは、PCEを使用してSR-TE LSPがセットアップされています。SR-TE LSPのSIDSのリストは{a、b、c、d}です。ゲートウェイノード1（PCC）は、バインディングSID Xを割り当て、PCEに報告します。MPLS DCネットワークでは、エンドツーエンドのSR-TE LSPが確立されています。アクセスノードがノード1に向かってwanのSR-TEパスに向かってトラフィックを導くために、PCEはSIDスタック{y、x}を通過します。ここで、yはアクセスへのゲートウェイノード1のノードSIDです。ノードとXはBSIDです。BSID xがない場合、PCEはSIDスタック{y、a、b、c、d}をアクセスノードに渡す必要があります。この例は、バインディングラベル/SIDを使用して、転送容量が限られているアクセスノードによって課されるSIDの数を減らすことの追加の利点を示しています。
SID stack
{Y, X} +--------------+
| Multi-domain |
_ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE |
| +--------------+
| ^
| | Binding
| .-----. | SID (X) .-----.
| ( ) | ( )
V .--( )--. | .--( )--.
+------+ ( ) +-------+ ( ) +-------+
|Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway|
| Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 |
+------+ ( SR-TE path ) +-------+ ( SR-TE path ) +-------+
'--( )--' Node '--( )--'
( ) SID of ( )
'-----' Node-1 '-----'
is Y SIDs for SR-TE LSP:
{A, B, C, D}
Figure 1: A Sample Use Case of Binding SID
図1：バインディングSIDのサンプルユースケース
Using the extension defined in this document, a PCC could report to the stateful PCE the binding label/SID it allocated via a Path Computation LSP State Report (PCRpt) message. It is also possible for a stateful PCE to request a PCC to allocate a specific binding label/SID by sending a Path Computation LSP Update Request (PCUpd) message. If the PCC can successfully allocate the specified binding value, it reports the binding value to the PCE. Otherwise, the PCC sends an error message to the PCE indicating the cause of the failure. A local policy or configuration at the PCC SHOULD dictate if the binding label/SID needs to be assigned.
このドキュメントで定義されている拡張機能を使用して、PCCはPath Computation LSP状態レポート（PCRPT）メッセージを介して割り当てられたバインディングラベル/SIDをステートフルPCEに報告できます。また、Path Computation LSP Update Request（PCUPD）メッセージを送信することにより、ステートフルPCEがPCCに特定のバインディングラベル/SIDを割り当てるように要求することも可能です。PCCが指定されたバインディング値を正常に割り当てることができる場合、PCEにバインディング値を報告します。それ以外の場合、PCCはPCEにエラーメッセージを送信して、障害の原因を示します。PCCでのローカルポリシーまたは構成は、バインディングラベル/SIDを割り当てる必要があるかどうかを指示する必要があります。
To implement the needed changes to PCEP, this document introduces a new OPTIONAL TLV that allows a PCC to report the binding label/SID associated with a TE LSP or a PCE to request a PCC to allocate any or a specific binding label/SID value. This TLV is intended for TE LSPs established using RSVP-TE, SR-TE, or any other future method. In the case of SR-TE LSPs, the TLV can carry a binding label (for SR-TE paths with the MPLS data plane) or a binding IPv6 SID (e.g., IPv6 address for SR-TE paths with the IPv6 data plane). Throughout this document, the term "binding value" means either an MPLS label or a SID.
必要な変更をPCEPに実装するために、このドキュメントでは、PCCがTE LSPまたはPCEに関連付けられたバインディングラベル/SIDを報告できるようにする新しいオプションTLVを導入し、PCCに特定のバインディングラベル/SID値を割り当てるように要求します。このTLVは、RSVP-TE、SR-TE、またはその他の将来の方法を使用して確立されたTE LSPを対象としています。SR-TE LSPの場合、TLVはバインディングラベル（MPLSデータプレーンを使用したSR-TEパスの場合）またはバインディングIPv6 SID（例えば、IPv6データプレーンを使用したSR-TEパスのIPv6アドレス）を運ぶことができます。このドキュメント全体で、「バインディング値」という用語は、MPLSラベルまたはSIDのいずれかを意味します。
As another way to use the extension specified in this document, to support the PCE-based central controller [RFC8283] operation where the PCE would take responsibility for managing some part of the MPLS label space for each of the routers that it controls, the PCE could directly make the binding label/SID allocation and inform the PCC. See Section 8 for details.
このドキュメントで指定された拡張機能を使用する別の方法として、PCEベースのセントラルコントローラー[RFC8283]操作をサポートします。PCEは、PCEを制御する各ルーターのMPLSラベルスペースの一部を管理する責任を負います。バインディングラベル/SIDの割り当てを直接作成し、PCCに通知することができます。詳細については、セクション8を参照してください。
In addition to specifying a new TLV, this document specifies how and when a PCC and PCE can use this TLV, how they can allocate a binding label/SID, and the associated error handling.
新しいTLVの指定に加えて、このドキュメントは、PCCとPCEがこのTLVを使用する方法と時期、バインディングラベル/SIDの割り当て方法、および関連するエラー処理を指定します。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following terminologies are used in this document:
このドキュメントでは、次の用語が使用されています。
BSID:
bsid：
Binding SID
バインディングシド
binding label/SID:
バインディングラベル/シド：
a generic term used for the binding segment for both SR and non-SR paths
SRパスと非SRパスの両方の結合セグメントに使用される一般的な用語
binding value:
バインディング値：
a generic term used for the binding segment as it can be encoded in various formats (as per the Binding Type (BT))
さまざまな形式でエンコードできるため、バインディングセグメントに使用される一般的な用語（バインディングタイプ（BT）に従って）
LSP:
LSP:
Label Switched Path
ラベルスイッチ付きパス
PCC:
PCC:
Path Computation Client
パス計算クライアント
PCEP:
PCEP：
Path Computation Element Communication Protocol
パス計算要素通信プロトコル
RSVP-TE:
RSVP-TE：
Resource Reservation Protocol - Traffic Engineering
リソース予約プロトコル - トラフィックエンジニアリング
SID:
SID:
Segment Identifier
セグメント識別子
SR:
SR:
Segment Routing
セグメントルーティング
The new optional TLV called "TE-PATH-BINDING TLV" (the format is shown in Figure 2) is defined to carry the binding label/SID for a TE path. This TLV is associated with the LSP object specified in [RFC8231]. This TLV can also be carried in the PCEP-ERROR object [RFC5440] in case of error. Multiple instances of TE-PATH-BINDING TLVs MAY be present in the LSP and PCEP-ERROR object. The type of this TLV is 55. The length is variable.
「TE-PATH結合TLV」と呼ばれる新しいオプションのTLV（形式を図2に示します）は、TEパスのバインディングラベル/SIDを運ぶために定義されています。このTLVは、[RFC8231]で指定されたLSPオブジェクトに関連付けられています。このTLVは、エラーの場合にPCEP-Errorオブジェクト[RFC5440]に携帯することもできます。TE-PATH結合TLVの複数のインスタンスは、LSPおよびPCEP-Errorオブジェクトに存在する場合があります。このTLVのタイプは55です。長さは可変です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 55 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Binding Value (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: TE-PATH-BINDING TLV
図2：TE-PATH結合TLV
The TE-PATH-BINDING TLV is a generic TLV such that it is able to carry binding label/SID (i.e., MPLS label or SRv6 SID). It is formatted according to the rules specified in [RFC5440]. The value portion of the TLV comprises:
TE-PATH結合TLVは、バインディングラベル/SID（つまり、MPLSラベルまたはSRV6 SID）を運ぶことができるようにする一般的なTLVです。[RFC5440]で指定されたルールに従ってフォーマットされています。TLVの値部分は次のとおりです。
* Binding Type (BT): A one-octet field that identifies the type of binding included in the TLV. This document specifies the following BT values:
* バインディングタイプ（BT）：TLVに含まれるバインディングのタイプを識別する1オクテットフィールド。このドキュメントは、次のBT値を指定します。
- BT = 0: The binding value is a 20-bit MPLS label value. The TLV is padded to 4-bytes alignment. The Length MUST be set to 7 (the padding is not included in the length, as per [RFC5440], Section 7.1), and the first 20 bits are used to encode the MPLS label value.
- BT = 0：バインディング値は20ビットMPLSラベル値です。TLVは、4バイトのアライメントにパッドで埋められています。長さは7に設定する必要があります（パディングは[RFC5440]、セクション7.1に従って長さに含まれていません）、最初の20ビットはMPLSラベル値をエンコードするために使用されます。
- BT = 1: The binding value is a 32-bit MPLS Label Stack Entry as per [RFC3032] with Label, Traffic Class (TC) [RFC5462], S, and TTL values encoded. Note that the receiver MAY choose to override TC, S, and TTL values according to its local policy. The Length MUST be set to 8.
- BT = 1：バインディング値は、[RFC3032]に従って、ラベル、トラフィッククラス（TC）[RFC5462]、S、およびTTL値をエンコードした32ビットMPLSラベルスタックエントリです。受信者は、ローカルポリシーに従ってTC、S、およびTTLの値をオーバーライドすることを選択できることに注意してください。長さは8に設定する必要があります。
- BT = 2: The binding value is an SRv6 SID with the format of a 16-octet IPv6 address, representing the binding SID for SRv6. The Length MUST be set to 20.
- BT = 2：バインディング値は、SRV6の16オクテットIPv6アドレスの形式を備えたSRV6 SIDで、SRV6のバインディングSIDを表します。長さは20に設定する必要があります。
- BT = 3: The binding value is a 24-octet field, defined in Section 4.1, that contains the SRv6 SID as well as its Behavior and Structure. The Length MUST be set to 28.
- BT = 3：バインディング値は、SRV6SIDとその動作と構造を含むセクション4.1で定義されている24オクテットフィールドです。長さは28に設定する必要があります。
Section 11.1.1 defines the IANA registry used to maintain these binding types as well as any future ones. Note that multiple TE-PATH-BINDING TLVs with the same or different binding types MAY be present for the same LSP. A PCEP speaker could allocate multiple TE-PATH-BINDING TLVs (of the same BT) and use different binding values in different domains or use cases based on a local policy.
セクション11.1.1は、これらの結合タイプと将来のタイプを維持するために使用されるIANAレジストリを定義します。同じLSPに対して、同じまたは異なる結合タイプを持つ複数のTE-PATH結合TLVが存在する場合があることに注意してください。PCEPスピーカーは、複数のTE-PATH結合TLV（同じBTの）を割り当て、ローカルポリシーに基づいて異なるドメインまたはユースケースで異なるバインディング値を使用できます。
* Flags: 1 octet of flags. The following flag is defined in the new "TE-PATH-BINDING TLV Flag field" registry as described in Section 11.1.1:
* フラグ：1オクテットの旗。次のフラグは、セクション11.1.1で説明されている新しい「TE-PATH結合TLVフラグフィールド」レジストリで定義されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R| |
+-+-+-+-+-+-+-+-+
Figure 3: Flags
図3：フラグ
Where:
ただし：
- R (Removal - 1 bit): When set, the requesting PCEP peer requires the removal of the binding value for the LSP. When unset, the PCEP peer indicates that the binding value is added or retained for the LSP. This flag is used in the PCRpt and PCUpd messages. It is ignored in other PCEP messages.
- R（削除-1ビット）：設定すると、要求するPCEPピアには、LSPのバインディング値の除去が必要です。設定された場合、PCEPピアは、LSPに対して結合値が追加または保持されることを示します。このフラグは、PCRPTおよびPCUPDメッセージで使用されます。他のPCEPメッセージでは無視されます。
- The unassigned flags MUST be set to 0 while sending and ignored on receipt.
- 送信中に、未割り当てのフラグを0に設定し、受領時に無視する必要があります。
* Reserved: MUST be set to 0 while sending and ignored on receipt.
* 予約済み：送信中に0に設定して、受領時に無視する必要があります。
* Binding Value: A variable-length field, padded with trailing zeros to a 4-octet boundary. When the BT is 0, the 20 bits represent the MPLS label. When the BT is 1, the 32 bits represent the MPLS label stack entry as per [RFC3032]. When the BT is 2, the 128 bits represent the SRv6 SID. When the BT is 3, the binding value also contains the SRv6 Endpoint Behavior and SID Structure, defined in Section 4.1. In this document, the TE-PATH-BINDING TLV is considered to be empty if no binding value is present. Note that the length of the TLV would be 4 in such a case.
* バインディング値：4オクテットの境界に後続のゼロでパディングされた可変長さのフィールド。BTが0の場合、20ビットはMPLSラベルを表します。BTが1の場合、32ビットは[RFC3032]に従ってMPLSラベルスタックエントリを表します。BTが2の場合、128ビットはSRV6 SIDを表します。BTが3の場合、結合値には、セクション4.1で定義されているSRV6エンドポイントの動作とSID構造も含まれています。このドキュメントでは、TE-PATH結合TLVは、バインディング値が存在しない場合、空であると見なされます。このような場合、TLVの長さは4になることに注意してください。
This section specifies the format of the binding value in the TE-PATH-BINDING TLV when the BT is set to 3 for the SRv6 Binding SIDs [RFC8986]. The format is shown in Figure 4.
このセクションでは、SRV6結合SIDS [RFC8986]のBTが3に設定されている場合、TE-PATH結合TLVのバインディング値の形式を指定します。形式を図4に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 Binding SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6 Endpoint Behavior and SID Structure
図4：SRV6エンドポイントの動作とSID構造
The Binding Value consists of:
バインディング値は次のとおりです。
* SRv6 Binding SID: 16 octets. The 128-bit IPv6 address, representing the binding SID for SRv6.
* SRV6バインディングSID：16オクテット。SRV6のバインディングSIDを表す128ビットIPv6アドレス。
* Reserved: 2 octets. It MUST be set to 0 on transmit and ignored on receipt.
* 予約済み：2オクテット。送信時に0に設定し、受信時に無視する必要があります。
* Endpoint Behavior: 2 octets. The Endpoint Behavior code point for this SRv6 SID as defined by the "SRv6 Endpoint Behaviors" registry [RFC8986]. When the field is set with the value 0, the Endpoint Behavior is considered unknown.
* エンドポイントの動作：2オクテット。「SRV6エンドポイント動作」レジストリ[RFC8986]で定義されているこのSRV6 SIDのエンドポイント動作コードポイント。値0でフィールドが設定されると、エンドポイントの動作は不明と見なされます。
* [RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). A locator may be represented as B:N, where B is the SRv6 SID locator block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID, called "locator node". The following fields are used to advertise the length of each individual part of the SRv6 SID:
* [RFC8986]は、SRV6 SIDをloc：funct：argで構成されるものとして定義します。ここで、ロケーター（loc）がlの最も重要なビットでエンコードされ、その後、fits of function（funce）とbits of arguments（arg）が続きます。）。aロケーターはb：nとして表される場合があります。ここで、bはsrv6 sidロケーターブロック（オペレーターによってsrv6 sidsに割り当てられたipv6プレフィックス）であり、nは「ロケーターノード」と呼ばれるsidをインスタンス化する親ノードの識別子です。次のフィールドは、SRV6 SIDの個々の部分の長さを宣伝するために使用されます。
- LB Length: 1 octet. SRv6 SID Locator Block length in bits.
- LBの長さ：1オクテット。srv6 sidロケーターブロック長さのブロック長。
- LN Length: 1 octet. SRv6 SID Locator Node length in bits.
- LN長：1オクテット。SRV6 SIDロケーターノード長さのビット。
- Function Length: 1 octet. SRv6 SID Function length in bits.
- 関数の長さ：1オクテット。SRV6 SID関数のビットの長さ。
- Arguments Length: 1 octet. SRv6 SID Arguments length in bits.
- 引数の長さ：1オクテット。srv6 sid bits in bitsの長さ。
The total of the locator block, locator node, function, and arguments lengths MUST be less than or equal to 128 bits. If this condition is not met, the corresponding TE-PATH-BINDING TLV is considered invalid. Also, if the Endpoint Behavior is found to be unknown or inconsistent, it is considered invalid. A PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 37 ("Invalid SRv6 SID Structure") MUST be sent in such cases.
ロケーターブロック、ロケーターノード、機能、および引数の合計は、128ビット以下でなければなりません。この状態が満たされない場合、対応するTE-PATH結合TLVは無効と見なされます。また、エンドポイントの動作が不明または一貫性がないことが判明した場合、それは無効と見なされます。エラータイプ= 10（「無効なオブジェクトの受信」）およびエラー値= 37（ "無効なSRV6 SID構造"）のPCERRメッセージは、そのような場合に送信する必要があります。
The SRv6 SID Structure could be used by the PCE for ease of operations and monitoring. For example, this information could be used for validation of SRv6 SIDs being instantiated in the network and checked for conformance to the SRv6 SID allocation scheme chosen by the operator as described in Section 3.2 of [RFC8986]. In the future, PCE could also be used for verification and for automatically securing the SRv6 domain by provisioning filtering rules at SR domain boundaries as described in Section 5 of [RFC8754]. The details of these potential applications are outside the scope of this document.
SRV6 SID構造は、操作と監視を容易にするためにPCEによって使用できます。たとえば、この情報は、ネットワークにインスタンス化されているSRV6 SIDの検証に使用でき、[RFC8986]のセクション3.2で説明されているように、オペレーターが選択したSRV6 SID割り当てスキームへの適合を確認できます。将来、PCEは、[RFC8754]のセクション5で説明されているように、SRドメイン境界でフィルタリングルールをプロビジョニングすることにより、検証やSRV6ドメインを自動的に保護するためにも使用できます。これらの潜在的なアプリケーションの詳細は、このドキュメントの範囲外です。
The binding value is usually allocated by the PCC and reported to a PCE via a PCRpt message (see Section 8 where PCE performs the allocation). If a PCE does not recognize the TE-PATH-BINDING TLV, it would ignore the TLV in accordance with [RFC5440]. If a PCE recognizes the TLV but does not support the TLV, it MUST send a PCErr with Error-Type = 2 ("Capability not supported").
バインディング値は通常、PCCによって割り当てられ、PCRPTメッセージを介してPCEに報告されます（PCEが割り当てを実行するセクション8を参照）。PCEがTE-PATH結合TLVを認識していない場合、[RFC5440]に従ってTLVを無視します。PCEがTLVを認識しているがTLVをサポートしていない場合、エラータイプ= 2（「サポートされていない」）でPCERRを送信する必要があります。
Multiple TE-PATH-BINDING TLVs are allowed to be present in the same LSP object. This signifies the presence of multiple binding SIDs for the given LSP. In the case of multiple TE-PATH-BINDING TLVs, the existing instances of TE-PATH-BINDING TLVs MAY be included in the LSP object. In case of an error condition, the whole message is rejected, and the resulting PCErr message MAY include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object.
複数のTE-PATH結合TLVは、同じLSPオブジェクトに存在することが許可されています。これは、与えられたLSPの複数の結合SIDの存在を意味します。複数のTE-PATH結合TLVの場合、TE-PATH結合TLVの既存のインスタンスがLSPオブジェクトに含まれる場合があります。エラー状態の場合、メッセージ全体が拒否され、結果のPCERRメッセージには、PCEP-ERRORオブジェクトに問題のあるTE-PATHバインディングTLVが含まれる場合があります。
If a PCE recognizes an invalid binding value (e.g., label value from the reserved MPLS label space), it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 2 ("Bad label value") as specified in [RFC8664].
PCEが無効なバインディング値（予約されたMPLSラベルスペースからのラベル値など）を認識している場合、エラータイプ= 10（「無効なオブジェクトの受信」）およびエラー-Value = 2（ "でPCERRメッセージを送信する必要があります。[RFC8664]で指定されているように、悪いラベル値 "）。
For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV by setting BT to 3. This can enable the sender to have control of the SRv6 Endpoint Behavior and SID Structure. A sender MAY choose to set the BT to 2, in which case the receiving implementation chooses how to interpret the SRv6 Endpoint Behavior and SID Structure according to local policy.
SRV6 BSIDSの場合、BTを3に設定することにより、TE-PATH結合TLVのSRV6エンドポイントの動作とSID構造を常に明示的に指定することをお勧めします。これにより、送信者はSRV6エンドポイントの動作とSID構造を制御できるようになります。送信者は、BTを2に設定することを選択できます。この場合、受信実装は、ローカルポリシーに従ってSRV6エンドポイントの動作とSID構造を解釈する方法を選択します。
If a PCC wishes to withdraw a previously reported binding value, it MUST send a PCRpt message with the specific TE-PATH-BINDING TLV with R flag set to 1. If a PCC wishes to modify a previously reported binding, it MUST withdraw the former binding value (with R flag set in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING TLV containing the new binding value. Note that other instances of TE-PATH-BINDING TLVs that are unchanged MAY also be included. If the unchanged instances are not included, they will remain associated with the LSP.
PCCが以前に報告されたバインディング値を撤回したい場合、特定のTE-PATHバインディングTLVを使用してPCRPTメッセージをRフラグを1に送信する必要があります。バインディング値（前のTE-PATH結合TLVにRフラグが設定されています）および新しいバインディング値を含む新しいTE-PATH結合TLVが含まれています。変更されていないTE-PATH結合TLVの他のインスタンスも含まれる場合があることに注意してください。変更されていないインスタンスが含まれていない場合、それらはLSPに関連付けられたままです。
If a PCE requires a PCC to allocate one (or several) specific binding value(s), it may do so by sending a PCUpd or PCInitiate message containing one or more TE-PATH-BINDING TLVs. If the values can be successfully allocated, the PCC reports the binding values to the PCE. If the PCC considers the binding value specified by the PCE invalid, it MUST send a PCErr message with Error-Type = 32 ("Binding label/SID failure") and Error-value = 1 ("Invalid SID"). If the binding value is valid but the PCC is unable to allocate the binding value, it MUST send a PCErr message with Error-Type = 32 ("Binding label/SID failure") and Error-value = 2 ("Unable to allocate the specified binding value"). Note that, in case of an error, the PCC rejects the PCUpd or PCInitiate message in its entirety and can include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object.
PCCがPCCが1つ（または複数の）特定のバインディング値を割り当てる必要がある場合、1つ以上のTE-PATH結合TLVを含むPCUPDまたはPCINITIATEメッセージを送信することにより、PCCがそうすることができます。値を正常に割り当てることができる場合、PCCは結合値をPCEに報告します。PCCがPCEの無効で指定されたバインディング値を考慮した場合、Error-Type = 32（ "Binding Label/SID障害"）およびError-Value = 1（ "Invalid Sid"）でPCERRメッセージを送信する必要があります。バインディング値が有効であるが、PCCがバインディング値を割り当てることができない場合、エラータイプ= 32（ "バインディングラベル/SID障害"）およびエラー値= 2（ "指定されたバインディング値」）。エラーが発生した場合、PCCはPCUPDまたはPCInitiateメッセージ全体を拒否し、PCEP-Errorオブジェクトに問題のあるTE-PATH結合TLVを含めることができることに注意してください。
If a PCE wishes to request the withdrawal of a previously reported binding value, it MUST send a PCUpd message with the specific TE-PATH-BINDING TLV with R flag set to 1. If a PCE wishes to modify a previously requested binding value, it MUST request the withdrawal of the former binding value (with R flag set in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING TLV containing the new binding value. If a PCC receives a PCUpd message with TE-PATH-BINDING TLV where the R flag is set to 1, but either the binding value is missing (empty TE-PATH-BINDING TLV) or the binding value is incorrect, it MUST send a PCErr message with Error-Type = 32 ("Binding label/SID failure") and Error-value = 4 ("Unable to remove the binding value").
PCEが以前に報告されたバインディング値の引き出しを要求したい場合、Rフラグを1に設定した特定のTE-PATHバインディングTLVを使用してPCUPDメッセージを送信する必要があります。前のバインディング値の撤回（前者のTE-PATH結合TLVにRフラグが設定された）を要求し、新しいバインディング値を含む新しいTE-PATH結合TLVを含める必要があります。PCCは、Rフラグが1に設定されているが、バインディング値が欠落している（空のTE-PATH結合TLV）またはバインディング値が正しくない場合、PCUPDメッセージをTE-PATHバインドTLVで受信します。エラータイプ= 32（ "バインディングラベル/SID障害"）およびエラー値= 4（ "バインディング値を削除できない"）を使用したPCERRメッセージ。
In some cases, a stateful PCE may want to request that the PCC allocate a binding value of the PCC's own choosing. It instructs the PCC by sending a PCUpd message containing an empty TE-PATH-BINDING TLV, i.e., no binding value is specified (bringing the Length field of the TLV to 4). A PCE can also request that a PCC allocate a binding value at the time of initiation by sending a PCInitiate message with an empty TE-PATH-BINDING TLV. Only one such instance of empty TE-PATH-BINDING TLV, per BT, SHOULD be included in the LSP object; others should be ignored on receipt. If the PCC is unable to allocate a new binding value as per the specified BT, it MUST send a PCErr message with Error-Type = 32 ("Binding label/SID failure") and Error-value = 3 ("Unable to allocate a new binding label/SID").
場合によっては、ステートフルPCEは、PCCがPCC自身の選択の拘束力のある値を割り当てるように要求する場合があります。空のTE-PATH結合TLVを含むPCUPDメッセージを送信してPCCに指示します。つまり、バインディング値は指定されていません（TLVの長さフィールドを4にする）。また、PCCは、空のTE-PATH結合TLVを使用してPCINITIATEメッセージを送信することにより、開始時にPCCがバインディング値を割り当てることも要求できます。BTあたりの空のTE-PATH結合TLVのそのようなインスタンスのみをLSPオブジェクトに含める必要があります。他の人は受領時に無視する必要があります。PCCが指定されたBTに従って新しいバインディング値を割り当てることができない場合、エラータイプ= 32（ "バインディングラベル/SID障害"）およびエラー-Value = 3（ "を割り当てることができないPCERRメッセージを送信する必要があります新しいバインディングラベル/sid "）。
As previously noted, if a message contains an invalid TE-PATH-BINDING TLV that leads to an error condition, the whole message is rejected including any other valid instances of TE-PATH-BINDING TLVs, if any. The resulting error message MAY include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object.
前述のように、メッセージにエラー条件につながる無効なTE-PATH結合TLVが含まれている場合、TE-PATH結合TLVの他の有効なインスタンスを含むメッセージ全体が拒否されます。結果のエラーメッセージには、PCEP-ERRORオブジェクトに問題のあるTE-PATH結合TLVが含まれる場合があります。
If a PCC receives a TE-PATH-BINDING TLV in any message other than PCUpd or PCInitiate, it MUST close the corresponding PCEP session with the reason "Reception of a malformed PCEP message" (according to [RFC5440]). Similarly, if a PCE receives a TE-PATH-BINDING TLV in any message other than a PCRpt or if the TE-PATH-BINDING TLV is associated with any object other than an LSP or PCEP-ERROR object, the PCE MUST close the corresponding PCEP session with the reason "Reception of a malformed PCEP message" (according to [RFC5440]).
PCCがPCUPDまたはPCInitiate以外のメッセージでTE-PATH結合TLVを受信した場合、「[RFC5440]に従って）「不正なPCEPメッセージの受信」という理由で、対応するPCEPセッションを閉じる必要があります。同様に、PCEがPCRPT以外のメッセージでTE-PATH結合TLVを受信した場合、またはTE-PATH結合TLVがLSPまたはPCEP-Errorオブジェクト以外のオブジェクトに関連付けられている場合、PCEは対応するものを閉じる必要があります「不正なPCEPメッセージの受信」という理由を使用したPCEPセッション（[RFC5440]による）。
If a TE-PATH-BINDING TLV is absent in the PCRpt message and no binding values were previously reported, the PCE MUST assume that the corresponding LSP does not have any binding. Similarly, if TE-PATH-BINDING TLV is absent in the PCUpd message and no binding values were previously reported, the PCC's local policy dictates how the binding allocations are made for a given LSP.
PCRPTメッセージにTE-PATH結合TLVが存在し、バインディング値が以前に報告されていない場合、PCEは対応するLSPにはバインディングがないと仮定する必要があります。同様に、PCUPDメッセージにTE-PATH結合TLVが存在し、バインディング値が以前に報告されていない場合、PCCのローカルポリシーは、特定のLSPに対してバインディング割り当てがどのように行われるかを決定します。
Note that some binding types have similar information but different binding value formats. For example, BT=(2 or 3) is used for the SRv6 SID, and BT=(0 or 1) is used for the MPLS Label. In case a PCEP speaker receives multiple TE-PATH-BINDING TLVs with the same SRv6 SID or MPLS Label but different BT values, it MUST send a PCErr message with Error-Type = 32 ("Binding label/SID failure") and Error-value = 5 ("Inconsistent binding types").
一部のバインディングタイプには、同様の情報がありますが、バインディング値が異なることに注意してください。たとえば、Bt =（2または3）はSRV6 SIDに使用され、Bt =（0または1）がMPLSラベルに使用されます。PCEPスピーカーが同じSRV6 SIDまたはMPLSラベルを使用して複数のTE-PATH結合TLVを受信した場合、異なるBT値では、エラータイプ= 32（ "バインディングラベル/SID障害"）およびエラー値= 5（ "一貫性のない結合タイプ"）。
In PCEP messages, LSP route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects. [RFC8664] defines the "SR-ERO subobject" capable of carrying a SID as well as the identity of the Node or Adjacency Identifier (NAI) represented by the SID. The NAI Type (NT) field indicates the type and format of the NAI contained in the SR-ERO. In case of binding SID, the NAI MUST NOT be included and NT MUST be set to zero. Section 5.2.1 of [RFC8664] specifies bit settings and error handling in the case when NT=0.
PCEPメッセージでは、LSPルート情報は、サブオブジェクトのシーケンスで構成される明示的なルートオブジェクト（ERO）に携帯されています。[RFC8664]は、SIDを運ぶことができる「SR-EROサブオブジェクト」と、SIDが表すノードまたは隣接識別子（NAI）の識別を定義します。NAIタイプ（NT）フィールドは、SR-EROに含まれるNAIのタイプと形式を示します。拘束力のあるSIDの場合、NAIを含める必要はなく、NTをゼロに設定する必要があります。[RFC8664]のセクション5.2.1は、NT = 0の場合のビット設定とエラー処理を指定します。
[RFC9603] defines the "SRv6-ERO subobject" for an SRv6 SID. Similarly to SR-ERO (Section 6), the NAI MUST NOT be included and the NT MUST be set to zero. Section 5.2.1 of [RFC8664] specifies bit settings and error handling in the case when NT=0.
[RFC9603]は、SRV6 SIDの「SRV6-ERO Subobject」を定義します。SR-ERO（セクション6）と同様に、NAIを含める必要はなく、NTをゼロに設定する必要があります。[RFC8664]のセクション5.2.1は、NT = 0の場合のビット設定とエラー処理を指定します。
Section 5 already includes the scenario where a PCE requires a PCC to allocate a specified binding value by sending a PCUpd or PCInitiate message containing a TE-PATH-BINDING TLV. This section specifies an OPTIONAL feature for the PCE to allocate the binding label/SID of its own accord in the case where the PCE also controls the label space of the PCC and can make the label allocation on its own as described in [RFC8283]. Note that the act of requesting a specific binding value (Section 5) is different from the act of allocating a binding label/ SID as described in this section.
セクション5には、PCCがTE-PATH結合TLVを含むPCUPDまたはPCINITIATEメッセージを送信することにより、指定されたバインディング値を割り当てるためにPCCが必要とするシナリオが既に含まれています。このセクションでは、PCEがPCCのラベル空間を制御し、[RFC8283]に記載されているように独自のラベル割り当てを作成できる場合、PCEのオプション機能を独自の合意に割り当てるためのオプション機能を指定します。特定のバインディング値（セクション5）を要求する行為は、このセクションで説明されているように、バインディングラベル/ SIDを割り当てる行為とは異なることに注意してください。
[RFC8283] introduces the architecture for PCE as a central controller as an extension of the architecture described in [RFC4655] and assumes the continued use of PCEP as the protocol used between PCE and PCC. [RFC9050] specifies the procedures and PCEP extensions for using the PCE as the central controller. It assumes that the exclusive label range to be used by a PCE is known and set on both PCEP peers. A future extension could add the capability to advertise this range via a possible PCEP extension as well (see [PCE-ID-SPACE]).
[RFC8283]は、[RFC4655]に記載されているアーキテクチャの拡張として中央コントローラーとしてPCEのアーキテクチャを導入し、PCCとPCCの間で使用されるプロトコルとしてPCEPの継続的な使用を想定しています。[RFC9050]は、PCEを中央コントローラーとして使用するための手順とPCEP拡張機能を指定します。PCEで使用される排他的なラベル範囲が既知であり、両方のPCEPピアで設定されていると想定しています。将来の拡張機能は、可能なPCEP拡張機能を介してこの範囲を宣伝する機能を追加することもできます（[PCE-ID-Space]を参照）。
When PCE as a Central Controller (PCECC) operations are supported as per [RFC9050], the binding label/SID MAY also be allocated by the PCE itself. Both peers need to exchange the PCECC capability as described in [RFC9050] before the PCE can allocate the binding label/ SID on its own.
[RFC9050]に従って中央コントローラー（PCECC）操作としてのPCEがサポートされる場合、バインディングラベル/SIDはPCE自体によって割り当てられる場合があります。両方のピアは、PCEがバインディングラベル/ SIDを単独で割り当てる前に、[RFC9050]で説明されているようにPCECC機能を交換する必要があります。
A new P flag in the LSP object [RFC8231] is introduced to indicate that the allocation needs to be made by the PCE. Note that the P flag could be used for other types of allocations (such as path segments [PCEP-SR]) in the future.
LSPオブジェクト[RFC8231]の新しいPフラグが導入され、PCEが割り当てを行う必要があることを示すことが導入されています。Pフラグは、将来、他のタイプの割り当て（パスセグメント[PCEP-SR]など）に使用できることに注意してください。
P (PCE-allocation): If the bit is set to 1, it indicates that the PCC requests that the PCE make allocations for this LSP. The TE-PATH-BINDING TLV in the LSP object identifies that the allocation is for a binding label/SID. A PCC MUST set this bit to 1 and include a TE-PATH-BINDING TLV in the LSP object if it wishes to request an allocation for a binding label/SID by the PCE in the PCEP message. A PCE MUST also set this bit to 1 and include a TE-PATH-BINDING TLV to indicate that the binding label/SID is allocated by PCE and encoded in the PCEP message towards the PCC. Further, if the binding label/SID is allocated by the PCC, the PCE MUST set this bit to 0 and follow the procedure described in Section 5.
P（PCE-Allocation）：ビットが1に設定されている場合、PCCがPCEがこのLSPに割り当てを行うことを要求することを示します。LSPオブジェクトのTE-PATH結合TLVは、割り当てがバインディングラベル/SIDのものであることを識別します。PCCは、このビットを1に設定し、PCEPメッセージのPCEによるバインディングラベル/SIDの割り当てを要求する場合は、LSPオブジェクトにTE-PATH結合TLVを含める必要があります。また、PCEはこのビットを1に設定し、TE-PATH結合TLVを含めて、バインディングラベル/SIDがPCEによって割り当てられ、PCCに向かってPCEPメッセージにエンコードされていることを示す必要があります。さらに、バインディングラベル/SIDがPCCによって割り当てられている場合、PCEはこのビットを0に設定し、セクション5で説明した手順に従う必要があります。
Note that:
ご了承ください：
* A PCE could allocate the binding label/SID of its own accord for a PCE-initiated or PCE-delegated LSP and inform the PCC in the PCInitiate message or PCUpd message by setting P=1 and including TE-PATH-BINDING TLV in the LSP object.
* PCEは、PCESITEDまたはPCE解凍LSPに対してバインディングラベル/SIDを独自の合意から割り当て、P = 1を設定し、LSPにTE-PATHバインディングTLVを含めることにより、PCINITIATEメッセージまたはPCUPDメッセージでPCCを通知することができます物体。
* To let the PCC allocate the binding label/SID, a PCE MUST set P=0 and include an empty TE-PATH-BINDING TLV (i.e., no binding value is specified) in the LSP object in the PCInitiate/PCUpd message.
* PCCにバインディングラベル/SIDを割り当てるには、PCEがP = 0を設定し、PCInitiate/PCUPDメッセージのLSPオブジェクトに空のTE-PATHバインディングTLV（つまり、バインディング値は指定されていない）を含める必要があります。
* To request that the PCE allocate the binding label/SID, a PCC MUST set P=1, D=1, and include an empty TE-PATH-BINDING TLV in the PCRpt message. The PCE will attempt to allocate it and respond to the PCC with a PCUpd message that includes the allocated binding label/SID in the TE-PATH-BINDING TLV and P=1 and D=1 in the LSP object. If the PCE is unable to allocate the binding label/SID, it MUST send a PCErr message with Error-Type = 32 ("Binding label/ SID failure") and Error-value = 3 ("Unable to allocate a new binding label/SID").
* PCEがバインディングラベル/SIDを割り当てるように要求するには、PCCはP = 1、d = 1を設定し、PCRPTメッセージに空のTE-PATH結合TLVを含める必要があります。PCEは、TE-PATHバインディングTLVに割り当てられたバインディングラベル/SIDとLSPオブジェクトのD = 1に割り当てられたバインディングラベル/SIDを含むPCUPDメッセージでそれを割り当て、PCCに応答しようとします。PCEがバインディングラベル/ SIDを割り当てることができない場合、Error-Type = 32（ "バインディングラベル/ SID障害"）およびエラー値= 3（ "新しいバインディングラベルを割り当てることができないPCERRメッセージを送信する必要があります/"sid "）。
* If one or both speakers (PCE and PCC) have not indicated support and willingness to use the PCEP extensions for the PCECC as per [RFC9050] and a PCEP peer receives P=1 in the LSP object, they MUST:
* 片方または両方のスピーカー（PCEとPCC）が[RFC9050]に従ってPCECCのPCEP拡張機能を使用するサポートと意欲を示していない場合、PCEPピアはLSPオブジェクトでP = 1を受信する必要があります。
- send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-value = 16 ("Attempted PCECC operations when PCECC capability was not advertised") and
- エラータイプ= 19（ "無効な操作"）およびエラー値= 16（ "PCECC機能が宣伝されていないときにPCECC操作を試みる"）を使用してPCERRメッセージを送信し、
- terminate the PCEP session.
- PCEPセッションを終了します。
* A legacy PCEP speaker that does not recognize the P flag in the LSP object would ignore it in accordance with [RFC8231].
* LSPオブジェクトのPフラグを認識しないレガシーPCEPスピーカーは、[RFC8231]に従ってそれを無視します。
It is assumed that the label range to be used by a PCE is known and set on both PCEP peers. The exact mechanism is out of the scope of [RFC9050] and this document. Note that the specific BSID could be from the PCE-controlled or the PCC-controlled label space. The PCE can directly allocate the label from the PCE-controlled label space using P=1 as described above, whereas the PCE can request the allocation of a specific BSID from the PCC-controlled label space with P=0 as described in Section 5.
PCEで使用されるラベル範囲は、両方のPCEPピアで既知であり、設定されていると想定されています。正確なメカニズムは[RFC9050]とこのドキュメントの範囲外です。特定のBSIDは、PCE制御またはPCC制御ラベル空間からである可能性があることに注意してください。PCEは、上記のようにP = 1を使用してPCE制御ラベル空間からラベルを直接割り当てることができますが、PCEは、セクション5で説明されているように、P = 0のPCC制御ラベル空間から特定のBSIDの割り当てを要求できます。
Note that the P flag in the LSP object SHOULD NOT be set to 1 without the presence of TE-PATH-BINDING TLV or any other future TLV defined for PCE allocation. On receipt of such an LSP object, the P flag is ignored. The presence of TE-PATH-BINDING TLV with P=1 indicates the allocation is for the binding label/SID. In the future, some other TLV (such as one defined in [PCEP-SR]) could also be used alongside P=1 to indicate allocation of a different attribute. A future document should not attempt to assign semantics to P=1 without limiting the scope to one that both PCEP peers can agree on.
LSPオブジェクトのPフラグは、TE-PATH結合TLVまたはPCE割り当てのために定義されたその他の将来のTLVの存在なしに1に設定しないでください。このようなLSPオブジェクトを受け取ると、Pフラグは無視されます。P = 1を使用したTE-PATH結合TLVの存在は、割り当てがバインディングラベル/SID用であることを示しています。将来的には、他のTLV（[PCEP-SR]で定義されているものなど）をP = 1と一緒に使用して、異なる属性の割り当てを示すこともできます。将来のドキュメントは、両方のPCEPピアが同意できるスコープに制限することなく、P = 1にセマンティクスを割り当てようとしないでください。
The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC8664], and [RFC9050] are applicable to this specification. No additional security measure is required.
[RFC5440]、[RFC8231]、[RFC8281]、[RFC8664]、および[RFC9050]で説明されているセキュリティ上の考慮事項は、この仕様に適用されます。追加のセキュリティ測定は必要ありません。
As described in [RFC8402] and [RFC8664], SR intrinsically involves an entity (whether head-end or a central network controller) controlling and instantiating paths in the network without the involvement of (other) nodes along those paths. Binding SIDs are in effect shorthand aliases for longer path representations, and the alias expansion is in principle known only by the node that acts on it. In this document, the expansion of the alias is shared between PCC and PCE, and rogue actions by either PCC or PCE could result in shifting or misdirecting traffic in ways that are hard for other nodes to detect. In particular, when a PCE propagates paths of the form {A, B, BSID} to other entities, the BSID values are opaque, and a rogue PCE can substitute a BSID from a different LSP in such paths to move traffic without the recipient of the path knowing the ultimate destination.
[RFC8402]および[RFC8664]で説明されているように、SRは本質的に、それらのパスに沿った（他の）ノードの関与なしにネットワークのパスを制御およびインスタンス化するエンティティ（ヘッドエンドまたは中央ネットワークコントローラー）を含みます。バインディングSIDは、実際にはより長いパス表現のための速記のエイリアスであり、エイリアスの拡張は原則として、それに作用するノードによってのみ知られています。このドキュメントでは、エイリアスの拡張がPCCとPCCの間で共有され、PCCまたはPCEのいずれかによる不正行為は、他のノードが検出するのが難しい方法でトラフィックをシフトまたは誤った方向付けする可能性があります。特に、PCEがフォーム{a、b、bsid}のパスを他のエンティティに伝播する場合、bsid値は不透明であり、不正なpceはそのようなパスの異なるLSPからBSIDを代用して、レシピエントのレシピエントなしでトラフィックを移動することができます。究極の目的地を知っている道。
The case of BT=3 provides additional opportunities for malfeasance, as it purports to convey information about internal SRv6 SID Structure. There is no mechanism defined to validate this internal structure information, and mischaracterizing the division of bits into locator block, locator node, function, and argument can result in different interpretation of the bits by PCC and PCE. Most notably, shifting bits into or out of the "argument" is a direct vector for affecting processing, but other attacks are also possible.
BT = 3のケースは、内部SRV6 SID構造に関する情報を伝えることを目的としているため、不正行為の追加の機会を提供します。この内部構造情報を検証するために定義されたメカニズムはなく、ロケーターブロック、ロケーターノード、関数、および引数へのビットの分割を誤って特徴付けても、PCCとPCEによるビットの異なる解釈をもたらす可能性があります。最も顕著なのは、「引数」にビットを移動することは、処理に影響を与えるための直接的なベクトルであることですが、他の攻撃も可能です。
Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in RFC 9325 [BCP195] (unless explicitly set aside in [RFC8253]).
したがって、[RFC8231]によると、これらのPCEP拡張は、輸送層のセキュリティ（TLS）[RFC8253]を使用して、同じ行政当局に属するPCESおよびPCCにおける認証および暗号化されたセッションでのみアクティブ化することをお勧めします。RFC 9325 [BCP195]での最良の現在のプラクティス（[RFC8253]で明示的に確保されていない限り）。
All manageability requirements and considerations listed in [RFC5440], [RFC8231], and [RFC8664] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]、[RFC8231]、および[RFC8664]にリストされているすべての管理可能性の要件と考慮事項は、このドキュメントで定義されているPCEPプロトコル拡張に適用されます。さらに、このセクションにリストされている要件と考慮事項が適用されます。
A PCC implementation SHOULD allow the operator to configure the policy the PCC needs to apply when allocating the binding label/SID.
PCCの実装により、オペレーターは、バインディングラベル/SIDを割り当てるときにPCCが適用する必要があるポリシーを構成できるようにする必要があります。
If BT is set to 2, the operator needs to have local policy set to decide the SID structure and the SRv6 Endpoint Behavior of the BSID.
BTが2に設定されている場合、オペレーターは、BSIDのSID構造とSRV6エンドポイントの動作を決定するためにローカルポリシーを設定する必要があります。
The PCEP YANG module [PCEP-YANG] will be extended to include policy configuration for binding label/SID allocation.
PCEP Yangモジュール[PCEP-Yang]は、バインディングラベル/SID割り当てのポリシー構成を含めるように拡張されます。
The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]に既にリストされているものに加えて、新しい活性検出および監視要件を意味するものではありません。
The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8664].
このドキュメントで定義されているメカニズムは、[RFC5440]、[RFC8231]、および[RFC8664]にすでにリストされているものに加えて、新しい操作検証要件を意味するものではありません。
The mechanisms defined in this document do not imply any new requirements on other protocols.
このドキュメントで定義されているメカニズムは、他のプロトコルの新しい要件を意味するものではありません。
The mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply to the PCEP extensions defined in this document.
[RFC5440]、[RFC8231]、および[RFC8664]で定義されているメカニズムは、このドキュメントで定義されているPCEP拡張機能にも適用されます。
IANA has allocated code points for the protocol elements described in this document in the "Path Computation Element Protocol (PCEP) Numbers" registry group.
IANAは、このドキュメントで説明されているプロトコル要素のコードポイントを「PATH計算要素プロトコル（PCEP）番号」レジストリグループで割り当てました。
This document defines a new PCEP TLV. IANA has allocated the following in the "PCEP TLV Type Indicators" registry within the PCEP Numbers registry group:
このドキュメントでは、新しいPCEP TLVを定義します。IANAは、PCEP番号レジストリグループ内の「PCEP TLVタイプインジケーター」レジストリで以下を割り当てました。
+=======+=================+===========+
| Value | Description | Reference |
+=======+=================+===========+
| 55 | TE-PATH-BINDING | RFC 9604 |
+-------+-----------------+-----------+
Table 1
IANA has created the "TE-PATH-BINDING TLV BT Field" registry to manage the values of the binding type field in the TE-PATH-BINDING TLV. Initial values are shown below. New values are assigned by Standards Action [RFC8126].
IANAは、TE-PATH結合TLVのバインディングタイプフィールドの値を管理するために、「TE-PATHバインドTLV BTフィールド」レジストリを作成しました。初期値を以下に示します。新しい値は、標準アクション[RFC8126]によって割り当てられます。
+=======+======================================+===========+
| Value | Description | Reference |
+=======+======================================+===========+
| 0 | MPLS Label | RFC 9604 |
+-------+--------------------------------------+-----------+
| 1 | MPLS Label Stack Entry | RFC 9604 |
+-------+--------------------------------------+-----------+
| 2 | SRv6 SID | RFC 9604 |
+-------+--------------------------------------+-----------+
| 3 | SRv6 SID with Behavior and Structure | RFC 9604 |
+-------+--------------------------------------+-----------+
| 4-255 | Unassigned | |
+-------+--------------------------------------+-----------+
Table 2
IANA has created a new "TE-PATH-BINDING TLV Flag Field" registry to manage the Flag field in the TE-PATH-BINDING TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
IANAは、TE-PATHバインディングTLVのフラグフィールドを管理するために、新しい「TE-PATH結合TLVフラグフィールド」レジストリを作成しました。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
* Bit number (count from 0 as the most significant bit)
* ビット数（最も重要なビットとして0からカウント）
* Description
* 説明
* Reference
* 参照
+=====+=============+===========+
| Bit | Description | Reference |
+=====+=============+===========+
| 0 | R (Removal) | RFC 9604 |
+-----+-------------+-----------+
| 1-7 | Unassigned | |
+-----+-------------+-----------+
Table 3
IANA has allocated a code point in the "LSP Object Flag Field" registry for the new P flag as follows:
IANAは、次のように、新しいPフラグの「LSPオブジェクトフラグフィールド」レジストリにコードポイントを割り当てました。
+=====+================+===========+
| Bit | Description | Reference |
+=====+================+===========+
| 0 | PCE-allocation | RFC 9604 |
+-----+----------------+-----------+
Table 4
This document defines a new Error-Type and associated Error-values for the PCErr message. IANA has allocated a new Error-Type and Error-values within the "PCEP-ERROR Object Error Types and Values" registry of the PCEP Numbers registry group, as follows:
このドキュメントでは、PCERRメッセージの新しいエラータイプと関連するエラー価値を定義します。IANAは、次のように、PCEP番号レジストリグループの「PCEP-Errorオブジェクトエラータイプと値」レジストリ内で、新しいエラータイプとエラー値を割り当てました。
+============+================+===========================+
| Error-Type | Meaning | Error-value |
+============+================+===========================+
| 32 | Binding label/ | 0: Unassigned |
| | SID failure +---------------------------+
| | | 1: Invalid SID |
| | +---------------------------+
| | | 2: Unable to allocate the |
| | | specified binding value |
| | +---------------------------+
| | | 3: Unable to allocate a |
| | | new binding label/SID |
| | +---------------------------+
| | | 4: Unable to remove the |
| | | binding value |
| | +---------------------------+
| | | 5: Inconsistent binding |
| | | types |
+------------+----------------+---------------------------+
Table 5
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[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>.
[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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
and Y. Zhu, "Path Computation Element Communication
Protocol (PCEP) Extensions for IPv6 Segment Routing",
RFC 9603, DOI 10.17487/RFC9603, July 2024,
<https://www.rfc-editor.org/info/rfc9603>.
[PCE-ID-SPACE]
Li, C., Shi, H., Ed., Wang, A., Cheng, W., and C. Zhou,
"Path Computation Element Communication Protocol (PCEP)
extension to advertise the PCE Controlled Identifier
Space", Work in Progress, Internet-Draft, draft-ietf-pce-
controlled-id-space-00, 4 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
controlled-id-space-00>.
[PCEP-SR] Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"Path Computation Element Communication Protocol (PCEP)
Extension for Path Segment in Segment Routing (SR)", Work
in Progress, Internet-Draft, draft-ietf-pce-sr-path-
segment-09, 26 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-
path-segment-09>.
[PCEP-YANG]
Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
"A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-25, 21 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-yang-25>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
We would like to thank Milos Fabian, Mrinmoy Das, Andrew Stone, Tom Petch, Aijun Wang, Olivier Dugeon, and Adrian Farrel for their valuable comments.
ミロス・ファビアン、ミリーモイ・ダス、アンドリュー・ストーン、トム・ペッチ、アイジュン・ワン、オリビエ・ドゲオン、エイドリアン・ファレルの貴重なコメントに感謝します。
Thanks to Julien Meuric for shepherding. Thanks to John Scudder for the AD review.
羊飼いのためのジュリエン・ムリックに感謝します。広告レビューをしてくれたJohn Scudderに感謝します。
Thanks to Theresa Enghardt for the GENART review.
GenartレビューをしてくれたTheresa Enghardtに感謝します。
Thanks to Martin Vigoureux, Benjamin Kaduk, Éric Vyncke, Lars Eggert, Murray Kucherawy, and Erik Kline for the IESG reviews.
IESGのレビューについては、Martin Vigoureux、Benjamin Kaduk、Eric Vyncke、Lars Eggert、Murray Kuherawy、Erik Klineに感謝します。
Jonathan Hardwick
Microsoft
United Kingdom
Email: jonhardwick@microsoft.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066
Karnataka
India
Email: dhruv.ietf@gmail.com
Mahendra Singh Negi
RtBrick India
N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3
Bangalore 560102
Karnataka
India
Email: mahend.ietf@gmail.com
Mike Koldychev
Cisco Systems, Inc.
2000 Innovation Drive
Kanata Ontario K2K 3E8
Canada
Email: mkoldych@cisco.com
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Siva Sivabalan
Ciena Corporation
Email: msiva282@gmail.com
Clarence Filsfils
Cisco Systems, Inc.
Pegasus Parc
De Kleetlaan 6a
1831 Brabant
Belgium
Email: cfilsfil@cisco.com
Jeff Tantsura
Nvidia
Email: jefftant.ietf@gmail.com
Stefano Previdi
Huawei Technologies
Email: stefano@previdi.net
Cheng Li (editor)
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com