[要約] RFC 8664は、セグメントルーティングのためのパス計算要素通信プロトコル（PCEP）の拡張に関するものであり、セグメントルーティングをサポートするための新しい機能と手順を提供します。目的は、ネットワークのパス計算と制御を改善し、セグメントルーティングの導入を促進することです。
Internet Engineering Task Force (IETF) S. Sivabalan
Request for Comments: 8664 C. Filsfils
Updates: 8408 Cisco Systems, Inc.
Category: Standards Track J. Tantsura
ISSN: 2070-1721 Apstra, Inc.
W. Henderickx
Nokia
J. Hardwick
Metaswitch Networks
December 2019
Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing
セグメントルーティング用のパス計算要素通信プロトコル（PCEP）拡張
Abstract
概要
Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.
セグメントルーティング（SR）を使用すると、ホップバイホップシグナリング手法（LDPやRSVP-TEなど）に依存することなく、任意のヘッドエンドノードが任意のパスを選択できます。リンク状態の内部ゲートウェイプロトコル（IGP）によって通知される「セグメント」のみに依存します。 SRパスは、IGP最短パスツリー（SPT）、明示的な構成、パス計算要素（PCE）など、さまざまなメカニズムから派生できます。このドキュメントでは、ステートフルPCEがトラフィックエンジニアリング（TE）パスを計算して開始できるようにするPath Computation Element Communication Protocol（PCEP）の拡張と、特定の制約およびSRネットワークの最適化基準。
This document updates RFC 8408.
このドキュメントはRFC 8408を更新します。
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/rfc8664.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8664で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 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. Terminology
2.1. Requirements Language
3. Overview of PCEP Operation in SR Networks
4. Object Formats
4.1. The OPEN Object
4.1.1. The Path Setup Type Capability TLV
4.1.2. The SR PCE Capability Sub-TLV
4.2. The RP/SRP Object
4.3. ERO
4.3.1. SR-ERO Subobject
4.3.2. NAI Associated with SID
4.4. RRO
4.5. METRIC Object
5. Procedures
5.1. Exchanging the SR PCE Capability
5.2. ERO Processing
5.2.1. SR-ERO Validation
5.2.2. Interpreting the SR-ERO
5.3. RRO Processing
6. Management Considerations
6.1. Controlling the Path Setup Type
6.2. Migrating a Network to Use PCEP Segment-Routed Paths
6.3. Verification of Network Operation
6.4. Relationship to Existing Management Models
7. Security Considerations
8. IANA Considerations
8.1. PCEP ERO and RRO Subobjects
8.2. New NAI Type Registry
8.3. New SR-ERO Flag Registry
8.4. PCEP-Error Object
8.5. PCEP TLV Type Indicators
8.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
8.7. New Path Setup Type
8.8. New Metric Type
8.9. SR PCE Capability Flags
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Compatibility with Early Implementations
Acknowledgements
Contributors
Authors' Addresses
Segment Routing (SR) leverages the source-routing paradigm. Using SR, a source node steers a packet through a path without relying on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is specified as an ordered list of instructions called "segments". Each segment is an instruction to route the packet to a specific place in the network or to perform a function on the packet. A database of segments can be distributed through the network using a routing protocol (such as IS-IS or OSPF) or by any other means. Several types of segments are defined. A node segment uniquely identifies a specific node in the SR domain. Each router in the SR domain associates a node segment with an ECMP-aware shortest path to the node that it identifies. An adjacency segment represents a unidirectional adjacency. An adjacency segment is local to the node that advertises it. Both node segments and adjacency segments can be used for SR.
セグメントルーティング（SR）は、ソースルーティングパラダイムを活用します。ソースノードはSRを使用して、LDPやRSVP-TEなどのホップバイホップシグナリングプロトコルに依存することなく、パスを介してパケットを誘導します。各パスは、「セグメント」と呼ばれる命令の順序付きリストとして指定されます。各セグメントは、パケットをネットワーク内の特定の場所にルーティングするか、パケットに対して機能を実行するための命令です。セグメントのデータベースは、ルーティングプロトコル（IS-ISやOSPFなど）を使用してネットワークを介して、またはその他の方法で配布できます。いくつかのタイプのセグメントが定義されています。ノードセグメントは、SRドメイン内の特定のノードを一意に識別します。 SRドメイン内の各ルーターは、ノードセグメントを、それが識別するノードへのECMP対応の最短パスに関連付けます。隣接セグメントは、単方向隣接を表します。隣接セグメントは、それをアドバタイズするノードに対してローカルです。 SRには、ノードセグメントと隣接セグメントの両方を使用できます。
[RFC8402] describes the SR architecture. The corresponding IS-IS and OSPF extensions are specified in [RFC8667] and [RFC8665], respectively.
[RFC8402]はSRアーキテクチャについて説明しています。対応するIS-ISおよびOSPF拡張は、それぞれ[RFC8667]および[RFC8665]で指定されています。
The SR architecture can be implemented using either an MPLS forwarding plane [RFC8660] or an IPv6 forwarding plane [IPv6-SRH]. The MPLS forwarding plane can be applied to SR without any change; in which case, an SR path corresponds to an MPLS Label Switching Path (LSP). This document is relevant to the MPLS forwarding plane only. In this document, "Node-SID" and "Adj-SID" denote the Node Segment Identifier and Adjacency Segment Identifier, respectively.
SRアーキテクチャは、MPLSフォワーディングプレーン[RFC8660]またはIPv6フォワーディングプレーン[IPv6-SRH]を使用して実装できます。 MPLSフォワーディングプレーンは、変更せずにSRに適用できます。その場合、SRパスはMPLSラベルスイッチングパス（LSP）に対応します。このドキュメントは、MPLSフォワーディングプレーンにのみ関連しています。このドキュメントでは、「Node-SID」と「Adj-SID」はそれぞれノードセグメント識別子と隣接セグメント識別子を示します。
An SR path can be derived from an IGP Shortest Path Tree (SPT). Segment Routing Traffic-Engineering (SR-TE) paths may not follow an IGP SPT. Such paths may be chosen by a suitable network planning tool and provisioned on the ingress node of the SR-TE path.
SRパスは、IGP最短パスツリー（SPT）から派生できます。セグメントルーティングトラフィックエンジニアリング（SR-TE）パスは、IGP SPTに従わない場合があります。このようなパスは、適切なネットワーク計画ツールによって選択され、SR-TEパスの入力ノードにプロビジョニングされます。
[RFC5440] describes the Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE) or between a pair of PCEs. A PCE computes paths for MPLS Traffic-Engineering (MPLS-TE) LSPs based on various constraints and optimization criteria. [RFC8231] specifies extensions to PCEP that allow a stateful PCE to compute and recommend network paths in compliance with [RFC4657]. It also defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide synchronization of LSP state between a PCC and a PCE or between a pair of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PCE, and control of the setup and path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions are intended for an operational model in which LSPs are configured on the PCC, and control over them is delegated to the PCE.
[RFC5440]は、パス計算クライアント（PCC）とパス計算要素（PCE）の間、またはPCEのペア間で通信するためのパス計算要素通信プロトコル（PCEP）について説明しています。 PCEは、さまざまな制約と最適化基準に基づいて、MPLSトラフィックエンジニアリング（MPLS-TE）LSPのパスを計算します。 [RFC8231]は、ステートフルPCEが[RFC4657]に準拠してネットワークパスを計算および推奨できるようにするPCEPの拡張を指定します。また、MPLS-TE LSPのオブジェクトとTLVを定義します。ステートフルPCEP拡張機能は、PCCとPCE間またはPCEのペア間のLSP状態の同期、LSP制御の委任、PCCからPCEへのLSP状態のレポート、およびLSPのセットアップとパスルーティングの制御を提供します。 PCEからPCCへ。ステートフルPCEP拡張は、LSCがPCCで構成され、それらに対する制御がPCEに委任される運用モデルを対象としています。
A mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE is specified in [RFC8281]. This mechanism is useful in Software-Defined Networking (SDN) applications, such as on-demand engineering or bandwidth calendaring [RFC8413].
ステートフルPCEまたはステートフルPCEを使用するコントローラーからの要求に基づいてPCCでLSPを動的に開始するメカニズムは、[RFC8281]で指定されています。このメカニズムは、オンデマンドエンジニアリングや帯域幅のカレンダー[RFC8413]などのソフトウェア定義ネットワーキング（SDN）アプリケーションで役立ちます。
It is possible to use a stateful PCE for computing one or more SR-TE paths, taking into account various constraints and objective functions. Once a path is chosen, the stateful PCE can initiate an SR-TE path on a PCC using the PCEP extensions specified in [RFC8281] and the SR-specific PCEP extensions specified in this document. Additionally, using procedures described in this document, a PCC can request an SR path from either a stateful or a stateless PCE.
さまざまな制約と目的関数を考慮して、1つ以上のSR-TEパスの計算にステートフルPCEを使用することが可能です。パスが選択されると、ステートフルPCEは、[RFC8281]で指定されたPCEP拡張機能と、このドキュメントで指定されたSR固有のPCEP拡張機能を使用して、PCCでSR-TEパスを開始できます。さらに、このドキュメントで説明されている手順を使用して、PCCはステートフルまたはステートレスPCEからSRパスを要求できます。
This specification relies on the procedures specified in [RFC8408] to exchange the Segment Routing capability and to specify that the path setup type of an LSP is Segment Routing. This specification also updates [RFC8408] to clarify the use of sub-TLVs in the PATH-SETUP-TYPE-CAPABILITY TLV. See Section 4.1.1 for details.
この仕様は、[RFC8408]で指定された手順に基づいて、セグメントルーティング機能を交換し、LSPのパス設定タイプがセグメントルーティングであることを指定します。この仕様は、[RFC8408]も更新して、PATH-SETUP-TYPE-CAPABILITY TLVでのサブTLVの使用を明確にします。詳細については、セクション4.1.1を参照してください。
This specification provides a mechanism for a network controller (acting as a PCE) to instantiate 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 [SR-POLICY].
この仕様は、ネットワークコントローラ（PCEとして機能）が、PCEPを使用してSRポリシーの候補パスをヘッドエンドノード（PCCとして機能）にインスタンス化するメカニズムを提供します。 SRポリシーアーキテクチャの詳細については、[SR-POLICY]を参照してください。
The following terminology is used in this document:
このドキュメントでは、次の用語が使用されています。
ERO: Explicit Route Object
ERO：明示的なルートオブジェクト
IGP: Interior Gateway Protocol
IGP：Interior Gateway Protocol
IS-IS: Intermediate System to Intermediate System
IS-IS：中間システムから中間システム
LSR: Label Switching Router
LSR：ラベルスイッチングルーター
MSD: Base MPLS Imposition Maximum SID Depth, as defined in [RFC8491]
MSD：[RFC8491]で定義されている、ベースMPLSインポジションの最大SID深さ
NAI: Node or Adjacency Identifier
NAI：ノードまたは隣接識別子
OSPF: Open Shortest Path First
OSPF：Open Shortest Path First
PCC: Path Computation Client
PCC：パス計算クライアント
PCE: Path Computation Element
PCE：パス計算要素
PCEP: Path Computation Element Communication Protocol
PCEP：パス計算要素通信プロトコル
RRO: Record Route Object
RRO：ルートオブジェクトの記録
SID: Segment Identifier
SID：セグメント識別子
SR: Segment Routing
SR：セグメントルーティング
SR-DB: Segment Routing Database: the collection of SRGBs, SRLBs, and SIDs and the objects they map to, advertised by a link-state IGP
SR-DB：セグメントルーティングデータベース：SRGB、SRLB、SIDのコレクション、およびそれらがマップするオブジェクトで、リンクステートIGPによってアドバタイズされます。
SR-TE: Segment Routing Traffic Engineering
SR-TE：セグメントルーティングトラフィックエンジニアリング
SRGB: Segment Routing Global Block
SRGB：セグメントルーティンググローバルブロック
SRLB: Segment Routing Local Block
SRLB：セグメントルーティングローカルブロック
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]で説明されているように解釈されます。
In an SR network, the ingress node of an SR path prepends an SR header to all outgoing packets. The SR header consists of a list of SIDs (or MPLS labels in the context of this document). The header has all necessary information so that, in combination with the information distributed by the IGP, the packets can be guided from the ingress node to the egress node of the path; hence, there is no need for any signaling protocol.
SRネットワークでは、SRパスの入力ノードがすべての発信パケットの先頭にSRヘッダーを付加します。 SRヘッダーは、SID（またはこのドキュメントのコンテキストではMPLSラベル）のリストで構成されます。ヘッダーにはすべての必要な情報が含まれているため、IGPによって配信された情報と組み合わせて、パケットをパスの入口ノードから出口ノードに導くことができます。したがって、シグナリングプロトコルは必要ありません。
In PCEP messages, LSP route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects. SR-TE paths computed by a PCE can be represented in an ERO in one of the following forms:
PCEPメッセージでは、LSPルート情報は、一連のサブオブジェクトで構成される明示的ルートオブジェクト（ERO）で伝達されます。 PCEによって計算されたSR-TEパスは、EROで次のいずれかの形式で表すことができます。
* An ordered set of IP addresses representing network nodes/links.
* ネットワークノード/リンクを表す、順序付けられたIPアドレスのセット。
* An ordered set of SIDs, with or without the corresponding IP addresses.
* SIDの順序付けされたセット。対応するIPアドレスあり、またはなし。
* An ordered set of MPLS labels, with or without corresponding IP addresses.
* 対応するIPアドレスの有無にかかわらず、順序付けられたMPLSラベルのセット。
The PCC converts these into an MPLS label stack and next hop, as described in Section 5.2.2.
セクション5.2.2で説明するように、PCCはこれらをMPLSラベルスタックとネクストホップに変換します。
This document defines a new ERO subobject denoted by "SR-ERO subobject" that is capable of carrying a SID as well as the identity of the node/adjacency represented by the SID. SR-capable PCEP speakers should be able to generate and/or process such an ERO subobject. An ERO containing SR-ERO subobjects can be included in the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], the Path Computation LSP Initiate Request (PCInitiate) message defined in [RFC8281], and the Path Computation Update Request (PCUpd) and Path Computation State Report (PCRpt) messages for LSPs defined in [RFC8231].
このドキュメントでは、「SR-EROサブオブジェクト」で示される新しいEROサブオブジェクトを定義します。これは、SIDと、SIDで表されるノード/隣接のIDを運ぶことができます。 SR対応のPCEPスピーカーは、そのようなEROサブオブジェクトを生成または処理できる必要があります。 SR-EROサブオブジェクトを含むEROは、[RFC5440]で定義されたPCEPパス計算応答（PCRep）メッセージ、[RFC8281]で定義されたパス計算LSP開始要求（PCInitiate）メッセージ、およびパス計算更新要求（PCUpd ）および[RFC8231]で定義されているLSPのパス計算状態レポート（PCRpt）メッセージ。
When a PCEP session between a PCC and a PCE is established, both PCEP speakers exchange their capabilities to indicate their ability to support SR-specific functionality.
PCCとPCE間のPCEPセッションが確立されると、両方のPCEPスピーカーが機能を交換して、SR固有の機能をサポートする機能を示します。
A PCE can update an LSP that is initially established via RSVP-TE signaling to use an SR-TE path by sending a PCUpd to the PCC that delegated the LSP to it [RFC8231]. A PCC can update an undelegated LSP that is initially established via RSVP-TE signaling to use an SR-TE path as follows. First, it requests an SR-TE path from a PCE by sending a Path Computation Request (PCReq) message. If it receives a suitable path, it establishes the path in the data plane and then tears down the original RSVP-TE path. If the PCE is stateful, then the PCC sends PCRpt messages indicating that the new path is set up and the old path is torn down, per [RFC8231].
PCEは、LSVPを委任したPCCにPCUpdを送信することで、RSVP-TEシグナリングを介して最初に確立されたLSPを更新してSR-TEパスを使用できます[RFC8231]。 PCCは、RSVP-TEシグナリングを介して最初に確立された委任されていないLSPを更新して、次のようにSR-TEパスを使用できます。最初に、Path Computation Request（PCReq）メッセージを送信して、PCEにSR-TEパスを要求します。適切なパスを受信すると、データプレーンにパスを確立してから、元のRSVP-TEパスを破棄します。 PCEがステートフルの場合、PCCは[RFC8231]に従って、新しいパスがセットアップされ、古いパスが破棄されることを示すPCRptメッセージを送信します。
Similarly, a PCE or PCC can update an LSP initially created with an SR-TE path to use RSVP-TE signaling, if necessary. This capability is useful for rolling back a change when a network is migrated from RSVP-TE to SR-TE technology.
同様に、PCEまたはPCCは、必要に応じて、最初にSR-TEパスで作成されたLSPを更新して、RSVP-TEシグナリングを使用できます。この機能は、ネットワークがRSVP-TEからSR-TEテクノロジーに移行されるときに変更をロールバックするのに役立ちます。
A PCC MAY include a Record Route Object (RRO) containing the recorded LSP in PCReq and PCRpt messages as specified in [RFC5440] and [RFC8231], respectively. This document defines a new RRO subobject for SR networks. The methods used by a PCC to record the SR-TE LSP are outside the scope of this document.
PCCは、[RFC5440]と[RFC8231]でそれぞれ指定されているように、PCReqおよびPCRptメッセージに記録されたLSPを含むレコードルートオブジェクト（RRO）を含めることができます（MAY）。このドキュメントでは、SRネットワークの新しいRROサブオブジェクトを定義します。 PCCがSR-TE LSPを記録するために使用する方法は、このドキュメントの範囲外です。
In summary, this document:
要約すると、このドキュメント：
* Defines a new ERO subobject, a new RRO subobject, and new PCEP error codes.
* 新しいEROサブオブジェクト、新しいRROサブオブジェクト、および新しいPCEPエラーコードを定義します。
* Specifies how two PCEP speakers can establish a PCEP session that can carry information about SR-TE paths.
* SR-TEパスに関する情報を伝送できるPCEPセッションを2つのPCEPスピーカーがどのように確立できるかを指定します。
* Specifies processing rules for the ERO subobject.
* EROサブオブジェクトの処理ルールを指定します。
* Defines a new path setup type to be used in the PATH-SETUP-TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs [RFC8408].
* PATH-SETUP-TYPEおよびPATH-SETUP-TYPE-CAPABILITY TLV [RFC8408]で使用される新しいパスセットアップタイプを定義します。
* Defines a new sub-TLV for the PATH-SETUP-TYPE-CAPABILITY TLV.
* PATH-SETUP-TYPE-CAPABILITY TLVの新しいサブTLVを定義します。
The extensions specified in this document complement the existing PCEP specifications to support SR-TE paths. As such, the PCEP messages (e.g., PCReq, PCRep, PCRpt, PCUpd, PCInitiate, etc.) are formatted according to [RFC5440], [RFC8231], [RFC8281], and any other applicable PCEP specifications.
このドキュメントで指定されている拡張機能は、SR-TEパスをサポートするために既存のPCEP仕様を補完します。そのため、PCEPメッセージ（PCReq、PCRep、PCRpt、PCUpd、PCInitiateなど）は、[RFC5440]、[RFC8231]、[RFC8281]、およびその他の該当するPCEP仕様に従ってフォーマットされます。
[RFC8408] defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional list of sub-TLVs, which are intended to convey parameters that are associated with the path setup types supported by a PCEP speaker.
[RFC8408]は、OPENオブジェクトで使用するPATH-SETUP-TYPE-CAPABILITY TLVを定義します。 PATH-SETUP-TYPE-CAPABILITY TLVには、オプションのサブTLVのリストが含まれています。これは、PCEPスピーカーでサポートされるパスセットアップタイプに関連付けられているパラメーターを伝達するためのものです。
This specification updates [RFC8408] as follows. It creates a new registry that defines the valid type indicators of the sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV (see Section 8.6). A PCEP speaker MUST NOT include a sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV unless it appears in this registry. If a PCEP speaker receives a sub-TLV whose type indicator does not match one of those from the registry or is not recognized by the speaker, then the speaker MUST ignore the sub-TLV.
この仕様は、[RFC8408]を次のように更新します。 PATH-SETUP-TYPE-CAPABILITY TLVのサブTLVの有効なタイプインジケーターを定義する新しいレジストリを作成します（セクション8.6を参照）。 PCEPスピーカーは、このレジストリに表示されない限り、PATH-SETUP-TYPE-CAPABILITY TLVにサブTLVを含めてはなりません（MUST NOT）。 PCEPスピーカーが、タイプインジケーターがレジストリからのものと一致しないか、スピーカーによって認識されないサブTLVを受信した場合、スピーカーはサブTLVを無視する必要があります。
This document defines a new Path Setup Type (PST) for SR, as follows:
このドキュメントでは、SRの新しいパスセットアップタイプ（PST）を次のように定義しています。
PST = 1: Traffic-engineering path is set up using Segment Routing.
PST = 1：トラフィックエンジニアリングパスは、セグメントルーティングを使用して設定されます。
A PCEP speaker SHOULD indicate its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST included in the PST list.
PCEPスピーカーは、この新しいPSTがPSTリストに含まれているOPENオブジェクトでPATH-SETUP-TYPE-CAPABILITY TLVを送信することにより、このドキュメントで説明されている機能のサポートを示す必要があります（SHOULD）。
This document also defines the SR-PCE-CAPABILITY sub-TLV. PCEP speakers use this sub-TLV to exchange information about their SR capability. If a PCEP speaker includes PST=1 in the PST list of the PATH-SETUP-TYPE-CAPABILITY TLV, then it MUST also include the SR-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV.
このドキュメントでは、SR-PCE-CAPABILITYサブTLVも定義しています。 PCEPスピーカーは、このサブTLVを使用してSR機能に関する情報を交換します。 PCEPスピーカーのPATH-SETUP-TYPE-CAPABILITY TLVのPSTリストにPST = 1が含まれている場合は、PATH-SETUP-TYPE-CAPABILITY TLV内にSR-PCE-CAPABILITYサブTLVも含める必要があります。
The format of the SR-PCE-CAPABILITY sub-TLV is shown in the following figure:
SR-PCE-CAPABILITYサブTLVのフォーマットを次の図に示します。
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=26 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |N|X| MSD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SR-PCE-CAPABILITY Sub-TLV Format
図1：SR-PCE-CAPABILITYサブTLV形式
The codepoint for the TLV type is 26. The TLV length is 4 octets.
TLVタイプのコードポイントは26です。TLVの長さは4オクテットです。
The 32-bit value is formatted as follows.
32ビット値の形式は次のとおりです。
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
予約済み：送信者はゼロに設定する必要があり、受信者は無視する必要があります。
Flags: This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver.
フラグ：このドキュメントでは、次のフラグビットを定義します。他のビットは送信者によってゼロに設定されなければならず、受信者によって無視されなければなりません。
N: A PCC sets this flag bit to 1 to indicate that it is capable of resolving a Node or Adjacency Identifier (NAI) to a SID.
N：PCCはこのフラグビットを1に設定して、ノードまたは隣接識別子（NAI）をSIDに解決できることを示します。
X: A PCC sets this flag bit to 1 to indicate that it does not impose any limit on the MSD.
X：PCCはこのフラグビットを1に設定して、MSDに制限を課さないことを示します。
Maximum SID Depth (MSD): specifies the maximum number of SIDs (MPLS label stack depth in the context of this document) that a PCC is capable of imposing on a packet. Section 5.1 explains the relationship between this field and the X-Flag.
最大SID深度（MSD）：PCCがパケットに課すことができるSID（このドキュメントのコンテキストではMPLSラベルスタック深度）の最大数を指定します。セクション5.1では、このフィールドとXフラグの関係について説明します。
To set up an SR-TE LSP using SR, the Request Parameter (RP) or Stateful PCE Request Parameter (SRP) object MUST include the PATH-SETUP-TYPE TLV, specified in [RFC8408], with the PST set to 1 (and path setup using SR-TE).
SRを使用してSR-TE LSPを設定するには、リクエストパラメータ（RP）またはステートフルPCEリクエストパラメータ（SRP）オブジェクトに、[RFC8408]で指定されているPATH-SETUP-TYPE TLVを含め、PSTを1に設定する必要があります（およびSR-TEを使用したパス設定）。
The LSP-IDENTIFIERS TLV MAY be present for the above PST type.
上記のPSTタイプには、LSP-IDENTIFIERS TLVが存在する場合があります。
An SR-TE path consists of one or more SIDs where each SID MAY be associated with the identifier that represents the node or adjacency corresponding to the SID. This identifier is referred to as the NAI. As described later, an NAI can be represented in various formats (e.g., IPv4 address, IPv6 address, etc). Furthermore, an NAI is used for troubleshooting purposes and, if necessary, to derive a SID value as described below.
SR-TEパスは1つ以上のSIDで構成され、各SIDは、SIDに対応するノードまたは隣接を表す識別子に関連付けられている場合があります。この識別子はNAIと呼ばれます。後述するように、NAIはさまざまな形式（IPv4アドレス、IPv6アドレスなど）で表すことができます。さらに、NAIはトラブルシューティングの目的で使用され、必要に応じて、次に説明するようにSID値を取得します。
The ERO specified in [RFC5440] is used to carry SR-TE path information. In order to carry a SID and/or NAI, this document defines a new ERO subobject referred to as the "SR-ERO subobject", whose format is specified in the following section. An ERO carrying an SR-TE path consists of one or more ERO subobjects, and it MUST carry only SR-ERO subobjects. Note that an SR-ERO subobject does not need to have both the SID and NAI. However, at least one of them MUST be present.
[RFC5440]で指定されているEROは、SR-TEパス情報の伝達に使用されます。 SIDまたはNAI、あるいはその両方を伝送するために、このドキュメントでは、「SR-EROサブオブジェクト」と呼ばれる新しいEROサブオブジェクトを定義しています。その形式は次のセクションで指定されています。 SR-TEパスを伝送するEROは1つ以上のEROサブオブジェクトで構成され、SR-EROサブオブジェクトのみを伝送する必要があります。 SR-EROサブオブジェクトは、SIDとNAIの両方を持つ必要がないことに注意してください。ただし、少なくとも1つは存在する必要があります。
When building the MPLS label stack from ERO, a PCC MUST assume that SR-ERO subobjects are organized as a last-in-first-out stack. The first subobject relative to the beginning of ERO contains the information about the topmost label. The last subobject contains information about the bottommost label.
EROからMPLSラベルスタックを構築する場合、PCCはSR-EROサブオブジェクトが後入れ先出しスタックとして編成されていると想定する必要があります。 EROの先頭に関連する最初のサブオブジェクトには、最上位のラベルに関する情報が含まれています。最後のサブオブジェクトには、一番下のラベルに関する情報が含まれています。
An SR-ERO subobject is formatted as shown in the following diagram.
SR-EROサブオブジェクトは、次の図に示すようにフォーマットされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT | Flags |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SR-ERO Subobject Format
図2：SR-EROサブオブジェクトの形式
The fields in the SR-ERO subobject are as follows:
SR-EROサブオブジェクトのフィールドは次のとおりです。
The L-Flag: Indicates whether the subobject represents a loose hop in the LSP [RFC3209]. If this flag is set to zero, a PCC MUST NOT overwrite the SID value present in the SR-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID values in the received SR-ERO based on its local policy.
Lフラグ：サブオブジェクトがLSP [RFC3209]のルーズホップを表すかどうかを示します。このフラグがゼロに設定されている場合、PCCはSR-EROサブオブジェクトに存在するSID値を上書きしてはなりません（MUST NOT）。それ以外の場合、PCCは、ローカルポリシーに基づいて、受信したSR-EROの1つ以上のSID値を拡張または置換できます（MAY）。
Type: Set to 36.
タイプ：36に設定します。
Length: Contains the total length of the subobject in octets. The Length MUST be at least 8 and MUST be a multiple of 4. An SR-ERO subobject MUST contain at least one SID or NAI. The flags described below indicate whether the SID or NAI fields are absent.
長さ：サブオブジェクトの全長がオクテットで含まれます。長さは少なくとも8でなければならず、4の倍数でなければなりません。SR-EROサブオブジェクトには、少なくとも1つのSIDまたはNAIが含まれている必要があります。以下で説明するフラグは、SIDフィールドまたはNAIフィールドが存在しないかどうかを示します。
NAI Type (NT): Indicates the type and format of the NAI contained in the object body, if any is present. If the F bit is set to zero (see below), then the NT field has no meaning and MUST be ignored by the receiver. This document describes the following NT values:
NAIタイプ（NT）：オブジェクト本体に含まれるNAIのタイプと形式（存在する場合）を示します。 Fビットがゼロに設定されている場合（以下を参照）、NTフィールドは意味を持たないため、受信者は無視する必要があります。このドキュメントでは、次のNT値について説明します。
NT=0 The NAI is absent.
NT = 0 NAIはありません。
NT=1 The NAI is an IPv4 node ID.
NT = 1 NAIはIPv4ノードIDです。
NT=2 The NAI is an IPv6 node ID.
NT = 2 NAIはIPv6ノードIDです。
NT=3 The NAI is an IPv4 adjacency.
NT = 3 NAIはIPv4隣接です。
NT=4 The NAI is an IPv6 adjacency with global IPv6 addresses.
NT = 4 NAIは、グローバルIPv6アドレスを持つIPv6隣接です。
NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs.
NT = 5 NAIは、IPv4ノードIDを持つ番号なしの隣接です。
NT=6 The NAI is an IPv6 adjacency with link-local IPv6 addresses.
NT = 6 NAIは、リンクローカルIPv6アドレスを持つIPv6隣接です。
Flags: Used to carry additional information pertaining to the SID. This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver.
フラグ：SIDに関する追加情報を伝えるために使用されます。このドキュメントでは、次のフラグビットを定義しています。他のビットは送信者によってゼロに設定されなければならず、受信者によって無視されなければなりません。
M: If this bit is set to 1, the SID value represents an MPLS label stack entry as specified in [RFC3032]. Otherwise, the SID value is an administratively configured value that represents an index into an MPLS label space (either SRGB or SRLB) per [RFC8402].
M：このビットが1に設定されている場合、SID値は[RFC3032]で指定されているMPLSラベルスタックエントリを表します。それ以外の場合、SID値は、[RFC8402]ごとにMPLSラベルスペース（SRGBまたはSRLB）へのインデックスを表す、管理上構成された値です。
C: If the M bit and the C bit are both set to 1, then the TC, S, and TTL fields in the MPLS label stack entry are specified by the PCE. However, a PCC MAY choose to override these values according to its local policy and MPLS forwarding rules. If the M bit is set to 1 but the C bit is set to zero, then the TC, S, and TTL fields MUST be ignored by the PCC. The PCC MUST set these fields according to its local policy and MPLS forwarding rules. If the M bit is set to zero, then the C bit MUST be set to zero.
C：MビットとCビットの両方が1に設定されている場合、MPLSラベルスタックエントリのTC、S、およびTTLフィールドはPCEによって指定されます。ただし、PCCは、ローカルポリシーとMPLS転送ルールに従ってこれらの値を上書きすることを選択できます（MAY）。 Mビットが1に設定され、Cビットがゼロに設定されている場合、PCCはTC、S、およびTTLフィールドを無視する必要があります。 PCCは、ローカルポリシーとMPLS転送ルールに従ってこれらのフィールドを設定する必要があります。 Mビットがゼロに設定されている場合、Cビットはゼロに設定する必要があります。
S: When this bit is set to 1, the SID value in the subobject body is absent. In this case, the PCC is responsible for choosing the SID value, e.g., by looking it up in the SR-DB using the NAI that, in this case, MUST be present in the subobject. If the S bit is set to 1, then the M and C bits MUST be set to zero.
S：このビットが1に設定されている場合、サブオブジェクト本体のSID値は存在しません。この場合、PCCは、たとえばNAIを使用してSR-DBでSID値を検索することによってSID値を選択する責任があります。この場合、この値はサブオブジェクトに存在する必要があります。 Sビットが1に設定されている場合、MおよびCビットはゼロに設定する必要があります。
F: When this bit is set to 1, the NAI value in the subobject body is absent. The F bit MUST be set to 1 if NT=0; otherwise, it MUST be set to zero. The S and F bits MUST NOT both be set to 1.
F：このビットが1に設定されている場合、サブオブジェクト本体のNAI値はありません。 NT = 0の場合、Fビットは1に設定する必要があります。それ以外の場合は、ゼロに設定する必要があります。 SビットとFビットの両方を1に設定してはなりません（MUST NOT）。
SID: The Segment Identifier. Depending on the M bit, it contains either:
SID：セグメント識別子。 Mビットに応じて、次のいずれかが含まれます。
* A 4-octet index defining the offset into an MPLS label space per [RFC8402] or
* [RFC8402]ごとにMPLSラベルスペースへのオフセットを定義する4オクテットインデックスまたは
* A 4-octet MPLS label stack entry, where the 20 most significant bits encode the label value per [RFC3032].
* 4オクテットのMPLSラベルスタックエントリ。上位20ビットが[RFC3032]に従ってラベル値をエンコードします。
NAI: The NAI associated with the SID. The NAI's format depends on the value in the NT field and is described in the following section.
NAI：SIDに関連付けられたNAI。 NAIの形式はNTフィールドの値に依存し、次のセクションで説明します。
At least one SID and NAI MUST be included in the SR-ERO subobject, and both MAY be included.
少なくとも1つのSIDとNAIがSR-EROサブオブジェクトに含まれている必要があり、両方が含まれている場合があります。
This document defines the following NAIs:
このドキュメントでは、次のNAIを定義しています。
IPv4 Node ID: Specified as an IPv4 address. In this case, the NT value is 1, and the NAI field length is 4 octets.
IPv4ノードID：IPv4アドレスとして指定されます。この場合、NT値は1で、NAIフィールド長は4オクテットです。
IPv6 Node ID: Specified as an IPv6 address. In this case, the NT value is 2, and the NAI field length is 16 octets.
IPv6ノードID：IPv6アドレスとして指定されます。この場合、NT値は2で、NAIフィールド長は16オクテットです。
IPv4 Adjacency: Specified as a pair of IPv4 addresses. In this case, the NT value is 3, and the NAI field length is 8 octets. The format of the NAI is shown in the following figure:
IPv4隣接：IPv4アドレスのペアとして指定されます。この場合、NT値は3で、NAIフィールド長は8オクテットです。 NAIのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NAI for IPv4 Adjacency
図3：NAI for IPv4隣接
IPv6 Global Adjacency: Specified as a pair of global IPv6 addresses. It is used to describe an IPv6 adjacency for a link that uses global IPv6 addresses. Each global IPv6 address is configured on a specific router interface, so together they identify an adjacency between a pair of routers. In this case, the NT value is 4, and the NAI field length is 32 octets. The format of the NAI is shown in the following figure:
IPv6グローバル隣接：グローバルIPv6アドレスのペアとして指定されます。グローバルIPv6アドレスを使用するリンクのIPv6隣接を記述するために使用されます。各グローバルIPv6アドレスは特定のルーターインターフェイスに構成されているので、これらは一緒にルーターのペア間の隣接関係を識別します。この場合、NT値は4で、NAIフィールド長は32オクテットです。 NAIのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NAI for IPv6 Global Adjacency
図4：IPv6グローバル隣接のNAI
Unnumbered Adjacency with IPv4 NodeIDs: Specified as a pair of (node ID, interface ID) tuples. In this case, the NT value is 5, and the NAI field length is 16 octets. The format of the NAI is shown in the following figure:
IPv4 NodeIDを持つ番号なし隣接：（ノードID、インターフェースID）タプルのペアとして指定されます。この場合、NT値は5で、NAIフィールド長は16オクテットです。 NAIのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NAI for Unnumbered Adjacency with IPv4 Node IDs
図5：IPv4ノードIDを使用した番号なし隣接のNAI
IPv6 Link-Local Adjacency: Specified as a pair of (global IPv6 address, interface ID) tuples. It is used to describe an IPv6 adjacency for a link that uses only link-local IPv6 addresses. Each global IPv6 address is configured on a specific router, so together they identify a pair of adjacent routers. The interface IDs identify the link that the adjacency is formed over. In this case, the NT value is 6, and the NAI field length is 40 octets. The format of the NAI is shown in the following figure:
IPv6リンクローカル隣接：（グローバルIPv6アドレス、インターフェースID）タプルのペアとして指定されます。リンクローカルIPv6アドレスのみを使用するリンクのIPv6隣接を記述するために使用されます。各グローバルIPv6アドレスは特定のルーターに構成されているため、隣接するルーターのペアを識別します。インターフェイスIDは、隣接関係が形成されているリンクを識別します。この場合、NT値は6で、NAIフィールド長は40オクテットです。 NAIのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NAI for IPv6 Link-Local Adjacency
図6：IPv6リンクローカル隣接のNAI
A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per [RFC8231]. The RRO on this message represents the SID list that was applied by the PCC, that is, the actual path taken by the LSP. The procedures of [RFC8231] with respect to the RRO apply equally to this specification without change.
PCCは、[RFC8231]に従って、PCRptメッセージを送信することにより、SR-TE LSPをPCEに報告します。このメッセージのRROは、PCCによって適用されたSIDリスト、つまりLSPがたどる実際のパスを表します。 RROに関する[RFC8231]の手順は、変更なしでこの仕様に等しく適用されます。
An RRO contains one or more subobjects called "SR-RRO subobjects", whose format is shown below:
RROには、「SR-RROサブオブジェクト」と呼ばれる1つ以上のサブオブジェクトが含まれています。そのフォーマットは次のとおりです。
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=36 | Length | NT | Flags |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SR-RRO Subobject Format
図7：SR-RROサブオブジェクトの形式
The format of the SR-RRO subobject is the same as that of the SR-ERO subobject, but without the L-Flag.
SR-RROサブオブジェクトのフォーマットは、SR-EROサブオブジェクトのフォーマットと同じですが、Lフラグがありません。
A PCC MUST order the SR-RRO subobjects such that the first subobject relative to the beginning of the RRO identifies the first segment visited by the SR-TE LSP, and the last subobject identifies the final segment of the SR-TE LSP, that is, its endpoint.
PCCはSR-RROサブオブジェクトを順序付けして、RROの先頭に対する最初のサブオブジェクトがSR-TE LSPが最初にアクセスするセグメントを識別し、最後のサブオブジェクトがSR-TE LSPの最終セグメントを識別するようにする必要があります。 、そのエンドポイント。
A PCC MAY request that PCE optimizes an individual path computation request to minimize the SID depth of the computed path by using the METRIC object defined in [RFC5440]. This document defines a new type for the METRIC object to be used for this purpose, as follows:
[RFC5440]で定義されているMETRICオブジェクトを使用して、PCEが個々のパス計算リクエストを最適化して、計算されたパスのSIDの深さを最小化するようにPCCが要求する場合があります。このドキュメントでは、この目的で使用するMETRICオブジェクトの新しいタイプを次のように定義しています。
T = 11: Maximum SID Depth of the requested path.
T = 11：要求されたパスの最大SID深度。
If the PCC includes a METRIC object of this type on a path computation request, then the PCE minimizes the SID depth of the computed path. If the B (bound) bit is set to 1 in the METRIC object, then the PCE MUST NOT return a path whose SID depth exceeds the given metric value. If the PCC did not set the X-Flag in its SR-PCE-CAPABILITY TLV, then it MUST set the B bit to 1. If the PCC set the X-Flag in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to 1 or zero.
PCCがパス計算リクエストにこのタイプのMETRICオブジェクトを含める場合、PCEは計算されたパスのSID深度を最小化します。 B（バインド）ビットがMETRICオブジェクトで1に設定されている場合、PCEは、SID深度が指定されたメトリック値を超えるパスを返してはなりません（MUST NOT）。 PCCがそのSR-PCE-CAPABILITY TLVでXフラグを設定しなかった場合、Bビットを1に設定する必要があります。PCCがそのSR-PCE-CAPABILITY TLVでXフラグを設定した場合、設定できます。 Bビットを1またはゼロに。
If a PCEP session is established with a non-zero default MSD value, then the PCC MUST NOT send an MSD METRIC object with an MSD greater than the session's default MSD. If the PCE receives a path computation request with an MSD METRIC object on such a session that is greater than the session's default MSD, then it MUST consider the request invalid and send a PCEP Error (PCErr) with Error-Type = 10 ("Reception of an invalid object") and Error-value = 9 ("MSD exceeds the default for the PCEP session").
PCEPセッションがゼロ以外のデフォルトのMSD値で確立されている場合、PCCは、セッションのデフォルトのMSDより大きいMSDを持つMSD METRICオブジェクトを送信してはなりません（MUST NOT）。 PCEが、セッションのデフォルトのMSDよりも大きい、そのようなセッションでMSD METRICオブジェクトを使用したパス計算要求を受信した場合、その要求を無効と見なし、Error-Type = 10（ "Reception無効なオブジェクトの「」およびエラー値= 9（「MSDがPCEPセッションのデフォルトを超えています」）。
A PCC indicates that it is capable of supporting the head-end functions for SR-TE LSP by including the SR-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCE. A PCE indicates that it is capable of computing SR-TE paths by including the SR-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCC.
PCCは、PCEに送信するOpenメッセージにSR-PCE-CAPABILITYサブTLVを含めることにより、SR-TE LSPのヘッドエンド機能をサポートできることを示します。 PCEは、PCCに送信するOpenメッセージにSR-PCE-CAPABILITYサブTLVを含めることにより、SR-TEパスを計算できることを示します。
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=1, and supports that path setup type, then it checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that sub-TLV is absent, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 12 ("Missing PCE-SR-CAPABILITY sub-TLV") and MUST then close the PCEP session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a SR-PCE-CAPABILITY sub-TLV, but the PST list does not contain PST=1, then the PCEP speaker MUST ignore the SR-PCE-CAPABILITY sub-TLV.
PCEPスピーカーがPST = 1を含むPSTリストを含むPATH-SETUP-TYPE-CAPABILITY TLVを受信し、そのパスセットアップタイプをサポートしている場合は、SR-PCE-CAPABILITYサブTLVの存在を確認します。そのサブTLVが存在しない場合、PCEPスピーカーは、Error-Type = 10（「無効なオブジェクトの受信」）およびError-value = 12（「Missing PCE-SR-CAPABILITY sub-TLV」を含むPCErrメッセージを送信する必要があります。 ）そしてPCEPセッションを閉じる必要があります。 PCEPスピーカーがSR-PCE-CAPABILITYサブTLVを含むPATH-SETUP-TYPE-CAPABILITY TLVを受信したが、PSTリストにPST = 1が含まれていない場合、PCEPスピーカーはSR-PCE-CAPABILITYサブを無視する必要があります。 TLV。
If a PCC sets the N-Flag to 1, then the PCE MAY send an SR-ERO subobject containing an NAI and no SID (see Section 5.2). Otherwise, the PCE MUST NOT send an SR-ERO subobject containing an NAI and no SID.
PCCがNフラグを1に設定すると、PCEはNAIを含みSIDを含まないSR-EROサブオブジェクトを送信できます（セクション5.2を参照）。それ以外の場合、PCEは、NAIを含みSIDを含まないSR-EROサブオブジェクトを送信してはなりません（MUST NOT）。
The number of SIDs that can be imposed on a packet depends on the PCC's data-plane capability. If a PCC sets the X-Flag to 1, then the MSD is not used and MUST be set to zero. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the X-Flag set to 1, then it MUST ignore the MSD field and assume that the sender can impose a SID stack of any depth. If a PCC sets the X-Flag to zero, then it sets the MSD field to the maximum number of SIDs that it can impose on a packet. In this case, the PCC MUST set the MSD to a number greater than zero. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the X-Flag and MSD both set to zero, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 21 ("Maximum SID depth must be non-zero") and MUST then close the PCEP session.
パケットに適用できるSIDの数は、PCCのデータプレーン機能によって異なります。 PCCがXフラグを1に設定する場合、MSDは使用されず、ゼロに設定する必要があります。 PCEがX-Flagを1に設定してSR-PCE-CAPABILITYサブTLVを受信した場合、PCEはMSDフィールドを無視し、送信者が任意の深さのSIDスタックを課すことができると想定する必要があります。 PCCがX-Flagをゼロに設定すると、MSDフィールドはパケットに課すことができるSIDの最大数に設定されます。この場合、PCCはMSDをゼロより大きい数に設定する必要があります。 PCEがX-FlagとMSDの両方がゼロに設定されたSR-PCE-CAPABILITYサブTLVを受信した場合、Error-Type = 10（「無効なオブジェクトの受信」）およびError-のPCErrメッセージを送信する必要があります。値= 21（「SIDの最大の深さはゼロ以外でなければなりません」）そしてPCEPセッションを閉じなければなりません（MUST）。
Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV indicates the SID/label imposition limit for the PCC node. It is anticipated that, in many deployments, the PCCs will have network interfaces that are homogeneous with respect to MSD (that is, each interface has the same MSD). In such cases, having a per-node MSD on the PCEP session is sufficient; the PCE SHOULD interpret this to mean that all network interfaces on the PCC have the given MSD. However, the PCE MAY also learn a per-node MSD and a per-interface MSD from the routing protocols, as specified in [RFC8491], [RFC8476], and [MSD-BGP]. If the PCE learns the per-node MSD of a PCC from a routing protocol, then it MUST ignore the per-node MSD value in the SR-PCE-CAPABILITY sub-TLV and use the per-node MSD learned from the routing protocol instead. If the PCE learns the MSD of a network interface on a PCC from a routing protocol, then it MUST use the per-interface MSD instead of the MSD value in the SR-PCE-CAPABILITY sub-TLV when it computes a path that uses that interface.
SR-PCE-CAPABILITYサブTLVを介して交換されるMSD値は、PCCノードのSID /ラベルインポジション制限を示すことに注意してください。多くの展開では、PCCはMSDに関して同種のネットワークインターフェイスを持つことが予想されます（つまり、各インターフェイスは同じMSDを持っています）。このような場合、PCEPセッションにノードごとのMSDがあれば十分です。 PCEはこれを解釈して、PCC上のすべてのネットワークインターフェイスに特定のMSDがあることを意味する必要があります。ただし、PCEは、[RFC8491]、[RFC8476]、および[MSD-BGP]で指定されているように、ルーティングプロトコルからノードごとのMSDとインターフェイスごとのMSDも学習できます（MAY）。 PCEがルーティングプロトコルからPCCのノードごとのMSDを学習する場合、SR-PCE-CAPABILITYサブTLVのノードごとのMSD値を無視し、代わりにルーティングプロトコルから学習したノードごとのMSDを使用する必要があります。 。 PCEがルーティングプロトコルからPCC上のネットワークインターフェイスのMSDを学習する場合、それを使用するパスを計算するときに、SRE-PCE-CAPABILITYサブTLVのMSD値の代わりにインターフェイスごとのMSDを使用する必要があります。インターフェース。
Once an SR-capable PCEP session is established with a non-zero MSD value, the corresponding PCE MUST NOT send SR-TE paths with a number of SIDs exceeding that MSD value. If a PCC needs to modify the MSD value, it MUST close the PCEP session and re-establish it with the new MSD value. If a PCEP session is established with a non-zero MSD value, and the PCC receives an SR-TE path containing more SIDs than specified in the MSD value, the PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 3 ("Unsupported number of SR-ERO subobjects"). If a PCEP session is established with an MSD value of zero, then the PCC MAY specify an MSD for each path computation request that it sends to the PCE, by including a "maximum SID depth" METRIC object on the request, as defined in Section 4.5.
ゼロ以外のMSD値でSR対応のPCEPセッションが確立されると、対応するPCEは、そのMSD値を超えるSIDの数を持つSR-TEパスを送信してはなりません（MUST NOT）。 PCCがMSD値を変更する必要がある場合、PCEPセッションを閉じて、新しいMSD値で再確立する必要があります。 PCEPセッションがゼロ以外のMSD値で確立され、PCCがMSD値で指定されたよりも多くのSIDを含むSR-TEパスを受信する場合、PCCはError-Type = 10（ "Reception of無効なオブジェクト "）およびエラー値= 3（"サポートされていない数のSR-EROサブオブジェクト "）。 PCEPセッションがゼロのMSD値で確立されている場合、PCCは、セクションに定義されているように、リクエストに「最大SID深度」METRICオブジェクトを含めることにより、PCEに送信する各パス計算リクエストのMSDを指定できます（MAY）。 4.5。
The N-Flag, X-Flag, and MSD value inside the SR-PCE-CAPABILITY sub-TLV are meaningful only in the Open message sent from a PCC to a PCE. As such, a PCE MUST set the N-Flag to zero, X-Flag to 1, and MSD value to zero in an outbound message to a PCC. Similarly, a PCC MUST ignore any MSD value received from a PCE. If a PCE receives multiple SR-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-TLV received.
SR-PCE-CAPABILITYサブTLV内のNフラグ、Xフラグ、およびMSD値は、PCCからPCEに送信されるOpenメッセージでのみ意味があります。そのため、PCCへの送信メッセージでは、PCEはNフラグをゼロに、Xフラグを1に、MSD値をゼロに設定する必要があります。同様に、PCCはPCEから受信したすべてのMSD値を無視する必要があります。 PCEがOpenメッセージで複数のSR-PCE-CAPABILITYサブTLVを受信した場合、PCEは受信した最初のサブTLVのみを処理します。
If a PCC does not support the SR PCE Capability and thus cannot recognize the SR-ERO or SR-RRO subobjects, it will respond according to the rules for a malformed object per [RFC5440].
PCCがSR PCE機能をサポートせず、したがってSR-EROまたはSR-RROサブオブジェクトを認識できない場合、[RFC5440]の不正なオブジェクトのルールに従って応答します。
On receiving an SR-ERO, a PCC MUST validate that the Length field, S bit, F bit, and NT field are consistent, as follows.
PCCはSR-EROを受信すると、次のように、長さフィールド、Sビット、Fビット、およびNTフィールドが一貫していることを検証する必要があります。
* If NT=0, the F bit MUST be 1, the S bit MUST be zero, and the Length MUST be 8.
* NT = 0の場合、Fビットは1でなければならず、Sビットはゼロでなければならず、長さは8でなければなりません。
* If NT=1, the F bit MUST be zero. If the S bit is 1, the Length MUST be 8; otherwise, the Length MUST be 12.
* NT = 1の場合、Fビットはゼロでなければなりません。 Sビットが1の場合、長さは8でなければなりません。それ以外の場合、長さは12でなければなりません。
* If NT=2, the F bit MUST be zero. If the S bit is 1, the Length MUST be 20; otherwise, the Length MUST be 24.
* NT = 2の場合、Fビットはゼロでなければなりません。 Sビットが1の場合、長さは20でなければなりません。それ以外の場合、長さは24でなければなりません。
* If NT=3, the F bit MUST be zero. If the S bit is 1, the Length MUST be 12; otherwise, the Length MUST be 16.
* NT = 3の場合、Fビットはゼロでなければなりません。 Sビットが1の場合、長さは12でなければなりません。それ以外の場合、長さは16でなければなりません。
* If NT=4, the F bit MUST be zero. If the S bit is 1, the Length MUST be 36; otherwise, the Length MUST be 40.
* NT = 4の場合、Fビットはゼロでなければなりません。 Sビットが1の場合、長さは36でなければなりません。それ以外の場合、長さは40でなければなりません。
* If NT=5, the F bit MUST be zero. If the S bit is 1, the Length MUST be 20; otherwise, the Length MUST be 24.
* NT = 5の場合、Fビットはゼロでなければなりません。 Sビットが1の場合、長さは20でなければなりません。それ以外の場合、長さは24でなければなりません。
* If NT=6, the F bit MUST be zero. If the S bit is 1, the Length MUST be 44; otherwise, the Length MUST be 48.
* NT = 6の場合、Fビットはゼロでなければなりません。 Sビットが1の場合、長さは44でなければなりません。それ以外の場合、長さは48でなければなりません。
If a PCC finds that the NT field, Length field, S bit, and F bit are not consistent, it MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object").
PCCは、NTフィールド、Lengthフィールド、Sビット、およびFビットに一貫性がないことを検出した場合、ERO全体を無効と見なし、Error-Type = 10（ "Reception of an invalid object"）のPCErrメッセージを送信する必要があります。エラー値= 11（「不正なオブジェクト」）。
If a PCC does not recognize or support the value in the NT field, it MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 13 ("Unsupported NAI Type in the SR-ERO/SR-RRO subobject").
PCCがNTフィールドの値を認識またはサポートしない場合、それはERO全体を無効と見なし、Error-Type = 10（ "Reception of a invalid object"）およびError-value = 13（ 「SR-ERO / SR-RROサブオブジェクトでサポートされていないNAIタイプ」）。
If a PCC receives an SR-ERO subobject in which the S and F bits are both set to 1 (that is, both the SID and NAI are absent), it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 6 ("Both SID and NAI are absent in the SR-ERO subobject").
PCCが、SビットとFビットの両方が1に設定されている（つまり、SIDとNAIの両方が存在しない）SR-EROサブオブジェクトを受信した場合、ERO全体が無効であると見なし、エラータイプのPCErrメッセージを送信する必要があります。 = 10（「無効なオブジェクトの受信」）およびエラー値= 6（「SR-EROサブオブジェクトにSIDとNAIの両方が存在しない」）。
If a PCC receives an SR-ERO subobject in which the S bit is set to 1 and the F bit is set to zero (that is, the SID is absent and the NAI is present), but the PCC does not support NAI resolution, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported parameter").
PCCが、Sビットが1に設定され、Fビットが0に設定された（つまり、SIDがなく、NAIが存在する）SR-EROサブオブジェクトを受信したが、PCCがNAI解決をサポートしていない場合ERO全体を無効と見なし、Error-Type = 4（「サポートされていないオブジェクト」）およびError-value = 4（「サポートされていないパラメーター」）のPCErrメッセージを送信する必要があります。
If a PCC receives an SR-ERO subobject in which the S bit is set to 1 and either (or both) the M bit or the C bit is set to 1, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object").
PCCが、Sビットが1に設定され、MビットまたはCビットのいずれか（または両方）が1に設定されているSR-EROサブオブジェクトを受信した場合、ERO全体が無効であると見なし、エラーのあるPCErrメッセージを送信する必要があります。 -Type = 10（「無効なオブジェクトの受信」）およびError-value = 11（「不正なオブジェクト」）。
If a PCC receives an SR-ERO subobject in which the S bit is set to zero and the M bit is set to 1, then the subobject contains an MPLS label. The PCC MAY choose not to accept a label provided by the PCE, based on its local policy. The PCC MUST NOT accept MPLS label value 3 (Implicit NULL), but it MAY accept other special-purpose MPLS label values. If the PCC decides not to accept an MPLS label value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 2 ("Bad label value").
PCCが、Sビットがゼロに設定され、Mビットが1に設定されているSR-EROサブオブジェクトを受信した場合、サブオブジェクトにはMPLSラベルが含まれます。 PCCは、そのローカルポリシーに基づいて、PCEによって提供されるラベルを受け入れないことを選択できます。 PCCはMPLSラベル値3（暗黙のNULL）を受け入れてはならない（MUST NOT）が、他の特別な目的のMPLSラベル値を受け入れてもよい（MAY）。 PCCがMPLSラベル値を受け入れないことを決定した場合は、Error-Type = 10（「無効なオブジェクトの受信」）およびError-value = 2（「不良ラベル値」）のPCErrメッセージを送信する必要があります。
If both the M and C bits of an SR-ERO subobject are set to 1, and if a PCC finds an erroneous setting in one or more of the TC, S, and TTL fields, it MAY overwrite those fields with values chosen according to its own policy. If the PCC does not overwrite them, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 4 ("Bad label format").
SR-EROサブオブジェクトのMビットとCビットの両方が1に設定されており、PCCが1つ以上のTC、S、およびTTLフィールドで誤った設定を検出した場合、これらのフィールドを、独自のポリシー。 PCCがそれらを上書きしない場合は、Error-Type = 10（ "Reception of an invalid object"）およびError-value = 4（ "Bad label format"）のPCErrメッセージを送信する必要があります。
If the M bit of an SR-ERO subobject is set to zero but the C bit is set to 1, then the PCC MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object").
SR-EROサブオブジェクトのMビットがゼロに設定されていて、Cビットが1に設定されている場合、PCCはERO全体を無効と見なし、Error-Type = 10（ "Reception of an invalid object "）およびError-value = 11（" Malformed object "）。
If a PCC receives an SR-ERO subobject in which the S bit is set to zero and the M bit is set to zero, then the subobject contains a SID index value. If the SID is an Adj-SID, then the L-Flag MUST NOT be set. If the L-Flag is set for an Adj-SID, then the PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object").
PCCが、Sビットがゼロに設定され、Mビットがゼロに設定されているSR-EROサブオブジェクトを受信した場合、サブオブジェクトにはSIDインデックス値が含まれます。 SIDがAdj-SIDの場合、Lフラグを設定してはなりません（MUST NOT）。 L-FlagがAdj-SIDに設定されている場合、PCCは、Error-Type = 10（「無効なオブジェクトの受信」）およびError-value = 11（「不正なオブジェクト」）のPCErrメッセージを送信する必要があります。
If a PCC detects that the subobjects of an ERO are a mixture of SR-ERO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 5 ("ERO mixes SR-ERO subobjects with other subobject types").
PCCがEROのサブオブジェクトがSR-EROサブオブジェクトと他のタイプのサブオブジェクトの混合であることを検出した場合、Error-Type = 10（ "Reception of an invalid object"）とError-valueを含むPCErrメッセージを送信する必要があります。 = 5（「EROはSR-EROサブオブジェクトを他のサブオブジェクトタイプと混合します」）。
The SR-ERO subobjects can be classified according to whether they contain a SID representing an MPLS label value or an index value, or no SID. If a PCC detects that the SR-ERO subobjects are a mixture of more than one of these types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 20 ("Inconsistent SIDs in SR-ERO/SR-RRO subobjects").
SR-EROサブオブジェクトは、MPLSラベル値またはインデックス値を表すSIDが含まれているか、SIDが含まれていないかによって分類できます。 PCCがSR-EROサブオブジェクトがこれらのタイプの2つ以上の混合であることを検出した場合、PCCはError-Type = 10（ "Reception of an invalid object"）およびError-value = 20（ 「SR-ERO / SR-RROサブオブジェクトのSIDが矛盾しています」）。
If an ERO specifies a new SR-TE path for an existing LSP and the PCC determines that the ERO contains SR-ERO subobjects that are not valid, then the PCC MUST NOT update the LSP.
EROが既存のLSPの新しいSR-TEパスを指定し、PCCがEROに無効なSR-EROサブオブジェクトが含まれていると判断した場合、PCCはLSPを更新してはなりません（MUST NOT）。
The SR-ERO contains a sequence of subobjects. Each SR-ERO subobject in the sequence identifies a segment that the traffic will be directed to, in the order given. That is, the first subobject identifies the first segment the traffic will be directed to, the second subobject represents the second segment, and so on.
SR-EROには一連のサブオブジェクトが含まれています。シーケンス内の各SR-EROサブオブジェクトは、トラフィックが送信されるセグメントを、指定された順序で識別します。つまり、最初のサブオブジェクトはトラフィックの宛先となる最初のセグメントを識別し、2番目のサブオブジェクトは2番目のセグメントを表し、以下同様に続きます。
The PCC interprets the SR-ERO by converting it to an MPLS label stack plus a next hop. The PCC sends packets along the segment-routed path by prepending the MPLS label stack onto the packets and sending the resulting, modified packet to the next hop.
PCCはSR-EROをMPLSラベルスタックとネクストホップに変換することで解釈します。 PCCは、MPLSラベルスタックをパケットの先頭に追加し、結果の変更されたパケットを次のホップに送信することにより、セグメントルーティングされたパスに沿ってパケットを送信します。
The PCC uses a different procedure to do this conversion, depending on the information that the PCE has provided in the subobjects.
PCCは、PCEがサブオブジェクトで提供した情報に応じて、この変換を行うために別の手順を使用します。
* If the subobjects contain SID index values, then the PCC converts them into the corresponding MPLS labels by following the procedure defined in [RFC8660].
* サブオブジェクトにSIDインデックス値が含まれている場合、PCCは、[RFC8660]で定義されている手順に従って、それらを対応するMPLSラベルに変換します。
* If the subobjects contain NAIs only, the PCC first converts each NAI into a SID index value and then proceeds as above. To convert an NAI to a SID index, the PCC looks for a fully specified prefix or adjacency matching the fields in the NAI. If the PCC finds a matching prefix/adjacency, and the matching prefix/adjacency has a SID associated with it, then the PCC uses that SID. If the PCC cannot find a matching prefix/adjacency, or if the matching prefix/adjacency has no SID associated with it, the PCC behaves as specified in Section 5.2.2.1.
* サブオブジェクトにNAIのみが含まれる場合、PCCは最初に各NAIをSIDインデックス値に変換してから、上記のように続行します。 NAIをSIDインデックスに変換するために、PCCは、NAIのフィールドと一致する完全に指定されたプレフィックスまたは隣接を探します。 PCCが一致するプレフィックス/隣接を検出し、一致するプレフィックス/隣接にSIDが関連付けられている場合、PCCはそのSIDを使用します。 PCCが一致するプレフィックス/隣接を見つけられない場合、または一致するプレフィックス/隣接にSIDが関連付けられていない場合、PCCはセクション5.2.2.1で指定されたとおりに動作します。
* If the subobjects contain MPLS labels, then the PCC looks up the offset of the first subobject's label in its SRGB or SRLB. This gives the first SID. The PCC pushes the labels in any remaining subobjects onto the packet (with the final subobject specifying the bottom-of-stack label).
* サブオブジェクトにMPLSラベルが含まれている場合、PCCはSRGBまたはSRLBで最初のサブオブジェクトのラベルのオフセットを検索します。これにより、最初のSIDが得られます。 PCCは残りのサブオブジェクトのラベルをパケットにプッシュします（最後のサブオブジェクトはスタックの最下部のラベルを指定します）。
For all cases above, after the PCC has imposed the label stack on the packet, it sends the packet to the segment identified by the first SID.
上記のすべてのケースで、PCCはパケットにラベルスタックを課した後、最初のSIDで識別されるセグメントにパケットを送信します。
There are several errors that can occur during the process of converting an SR-ERO sequence to an MPLS label stack and a next hop. The PCC deals with them as follows.
SR-EROシーケンスをMPLSラベルスタックおよびネクストホップに変換するプロセス中に発生する可能性のあるエラーがいくつかあります。 PCCはそれらを次のように扱います。
* If the PCC cannot find a SID index in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 14 ("Unknown SID").
* PCCがSR-DBでSIDインデックスを見つけることができない場合、PCErrメッセージをError-Type = 10（ "Reception of an invalid object"）およびError-value = 14（ "Unknown SID"）で送信する必要があります。
* If the PCC cannot find an NAI in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 15 ("NAI cannot be resolved to a SID").
* PCCがSR-DBでNAIを見つけられない場合、PCErrメッセージをError-Type = 10（「無効なオブジェクトの受信」）およびError-value = 15（「NAIをSIDに解決できない」 ）。
* If the PCC needs to convert a SID into an MPLS label value but cannot find the corresponding router's SRGB in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 16 ("Could not find SRGB").
* PCCがSIDをMPLSラベル値に変換する必要があるが、対応するルーターのSRGBがSR-DBで見つからない場合は、Error-Type = 10（「無効なオブジェクトの受信」）およびError-のPCErrメッセージを送信する必要があります。値= 16（「SRGBが見つかりませんでした」）。
* If the PCC finds that a router's SRGB is not large enough for a SID index value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 17 ("SID index exceeds SRGB size").
* PCCがルーターのSRGBがSIDインデックス値に対して十分な大きさでないことを検出した場合、PCCは、Error-Type = 10（ "Reception of an invalid object"）およびError-value = 17（ "SIDインデックスがSRGBサイズ」）。
* If the PCC needs to convert a SID into an MPLS label value but cannot find the corresponding router's SRLB in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 18 ("Could not find SRLB").
* PCCがSIDをMPLSラベル値に変換する必要があるが、対応するルーターのSRLBがSR-DBで見つからない場合、PCCはエラータイプ= 10（「無効なオブジェクトの受信」）およびエラー値= 18（「SRLBが見つかりませんでした」）。
* If the PCC finds that a router's SRLB is not large enough for a SID index value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 19 ("SID index exceeds SRLB size").
* PCCがルーターのSRLBがSIDインデックス値に対して十分な大きさでないことを検出した場合、PCCは、Error-Type = 10（ "Reception of an invalid object"）およびError-value = 19（ "SIDインデックスがSRLBサイズ」）。
* If the number of labels in the computed label stack exceeds the maximum number of SIDs that the PCC can impose on the packet, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 3 ("Unsupported number of SR-ERO subobjects").
* 計算されたラベルスタック内のラベルの数が、PCCがパケットに課すことができるSIDの最大数を超える場合、Error-Type = 10（「無効なオブジェクトの受信」）およびエラー値を含むPCErrメッセージを送信する必要があります= 3（「サポートされていない数のSR-EROサブオブジェクト」）。
If an ERO specifies a new SR-TE path for an existing LSP and the PCC encounters an error while processing the ERO, then the PCC MUST NOT update the LSP.
EROが既存のLSPの新しいSR-TEパスを指定し、PCCがEROの処理中にエラーを検出した場合、PCCはLSPを更新してはなりません（MUST NOT）。
The syntax-checking rules that apply to the SR-RRO subobject are identical to those of the SR-ERO subobject, except as noted below.
SR-RROサブオブジェクトに適用される構文チェック規則は、以下に記載されている場合を除いて、SR-EROサブオブジェクトのものと同じです。
If a PCEP speaker receives an SR-RRO subobject in which both SID and NAI are absent, it MUST consider the entire RRO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 7 ("Both SID and NAI are absent in the SR-RRO subobject").
PCEPスピーカーがSIDとNAIの両方が存在しないSR-RROサブオブジェクトを受信した場合、RRO全体を無効と見なし、Error-Type = 10（ "Reception of an invalid object"）およびError-valueを含むPCErrメッセージを送信する必要があります。 = 7（「SIDとNAIの両方がSR-RROサブオブジェクトに存在しない」）。
If a PCE detects that the subobjects of an RRO are a mixture of SR-RRO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 10 ("RRO mixes SR-RRO subobjects with other subobject types").
PCEがRROのサブオブジェクトがSR-RROサブオブジェクトと他のタイプのサブオブジェクトの混合であることを検出した場合、PCErrメッセージはError-Type = 10（ "Reception of an invalid object"）およびError-valueで送信する必要があります= 10（「RROはSR-RROサブオブジェクトを他のサブオブジェクトタイプと混合します」）。
The SR-RRO subobjects can be classified according to whether they contain a SID representing an MPLS label value or an index value, or no SID. If a PCE detects that the SR-RRO subobjects are a mixture of more than one of these types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 20 ("Inconsistent SIDs in SR-ERO / SR-RRO subobjects").
SR-RROサブオブジェクトは、MPLSラベル値またはインデックス値を表すSIDを含むか、SIDを含まないかによって分類できます。 PCEがSR-RROサブオブジェクトがこれらのタイプの2つ以上の混合であることを検出した場合、PCErrメッセージをError-Type = 10（ "Reception of an invalid object"）およびError-value = 20（ 「SR-ERO / SR-RROサブオブジェクトのSIDが矛盾しています」）。
This document adds a new path setup type to PCEP to allow LSPs to be set up using Segment Routing techniques. This path setup type may be used with PCEP alongside other path setup types, such as RSVP-TE, or it may be used exclusively.
このドキュメントでは、PCEPに新しいパスセットアップタイプを追加して、セグメントルーティングテクニックを使用してLSPをセットアップできるようにします。このパス設定タイプは、RSVP-TEなどの他のパス設定タイプと一緒にPCEPで使用するか、または排他的に使用できます。
The following factors control which path setup type is used for a given LSP.
次の要素は、特定のLSPに使用されるパス設定タイプを制御します。
* The available path setup types are constrained to those that are supported by, or enabled on, the PCEP speakers. The PATH-SETUP-TYPE-CAPABILITY TLV indicates which path setup types a PCEP speaker supports. To use Segment Routing as a path setup type, it is a prerequisite that the PCC and PCE both include PST=1 in the list of supported path setup types in this TLV and also include the SR-PCE-CAPABILITY sub-TLV.
* 使用可能なパス設定タイプは、PCEPスピーカーでサポートされているか、PCEPスピーカーで有効になっているタイプに制限されています。 PATH-SETUP-TYPE-CAPABILITY TLVは、PCEPスピーカーがサポートするパスセットアップタイプを示します。セグメントルーティングをパスセットアップタイプとして使用するには、PCCとPCEの両方が、このTLVでサポートされているパスセットアップタイプのリストにPST = 1を含み、SR-PCE-CAPABILITYサブTLVも含まれていることが前提条件です。
* When a PCE initiates an LSP, it proposes which path setup type to use by including it in the PATH-SETUP-TYPE TLV in the SRP object of the PCInitiate message. The PCE chooses the path setup type based on the capabilities of the network nodes on the path and on its local policy. The PCC MAY choose to accept the proposed path setup type or to reject the PCInitiate request, based on its local policy.
* PCEがLSPを開始すると、PCInitiateメッセージのSRPオブジェクトのPATH-SETUP-TYPE TLVにそれを含めることで、使用するパスセットアップタイプを提案します。 PCEは、パス上のネットワークノードの機能とローカルポリシーに基づいて、パスセットアップタイプを選択します。 PCCは、そのローカルポリシーに基づいて、提案されたパスセットアップタイプを受け入れるか、PCInitiate要求を拒否するかを選択できます（MAY）。
* When a PCC requests a path for an LSP, it can nominate a preferred path setup type by including it in the PATH-SETUP-TYPE TLV in the RP object of the PCReq message. The PCE MAY choose to reply with a path of the requested type, reply with a path of a different type, or reject the request, based on the capabilities of the network nodes on the path and on its local policy.
* PCCがLSPのパスを要求すると、PCReqメッセージのRPオブジェクトのPATH-SETUP-TYPE TLVにそれを含めることにより、優先パスセットアップタイプを指定できます。 PCEは、パス上のネットワークノードの機能とローカルポリシーに基づいて、要求されたタイプのパスで応答するか、別のタイプのパスで応答するか、要求を拒否するかを選択できます（MAY）。
The operator can influence the path setup type as follows.
オペレーターは、次のようにパス設定タイプに影響を与えることができます。
* Implementations MUST allow the operator to enable and disable the Segment Routing path setup type on a PCEP-speaking device. Implementations MAY also allow the operator to enable and disable the RSVP-TE path setup type.
* 実装では、オペレーターがPCEPスピーキングデバイスでセグメントルーティングパスセットアップタイプを有効および無効にできるようにする必要があります。実装により、オペレーターはRSVP-TEパス設定タイプを有効または無効にすることもできます。
* PCE implementations MUST allow the operator to specify that an LSP should be instantiated using Segment Routing or RSVP-TE as the proposed path setup type.
* PCEの実装では、提案されたパス設定タイプとしてセグメントルーティングまたはRSVP-TEを使用してLSPをインスタンス化する必要があることをオペレーターが指定できるようにする必要があります。
* PCE implementations MAY allow the operator to configure a preference for the PCE to propose paths using Segment Routing or RSVP-TE in the absence of a specified path setup type.
* PCEの実装により、オペレーターは、指定されたパス設定タイプがない場合にセグメントルーティングまたはRSVP-TEを使用してパスを提案するようにPCEの設定を構成できます。
* PCC implementations MUST allow the operator to specify that a path requested for an LSP nominates Segment Routing or RSVP-TE as the path setup type.
* PCC実装では、LSPに要求されたパスがセグメントルーティングまたはRSVP-TEをパスセットアップタイプとして指定することをオペレーターが指定できるようにする必要があります。
* PCC implementations MAY allow the operator to configure a preference for the PCC to nominate Segment Routing or RSVP-TE as the path setup type if none is specified for an LSP.
* PCC実装では、LSCに何も指定されていない場合、オペレーターがPCCの設定を構成して、セグメントルーティングまたはRSVP-TEをパスセットアップタイプとして指定できます。
* PCC implementations SHOULD allow the operator to configure a PCC to refuse to set up an LSP using an undesired path setup type.
* PCC実装は、オペレーターがPCCを構成して、望ましくないパス設定タイプを使用したLSPの設定を拒否できるようにする必要があります（SHOULD）。
This section discusses the steps that the operator takes when migrating a network to enable PCEP to set up paths using Segment Routing as the path setup type.
このセクションでは、ネットワークを移行してPCEPがパスセットアップタイプとしてセグメントルーティングを使用してパスをセットアップできるようにするときに、オペレーターが実行する手順について説明します。
* The operator enables the Segment Routing PST on the PCE servers.
* オペレーターは、PCEサーバーでセグメントルーティングPSTを有効にします。
* The operator enables the Segment Routing PST on the PCCs.
* オペレーターは、PCCでセグメントルーティングPSTを有効にします。
* The operator resets each PCEP session. The PCEP sessions come back up with Segment Routing enabled.
* オペレーターは各PCEPセッションをリセットします。 PCEPセッションは、セグメントルーティングを有効にして戻ってきます。
* If the operator detects a problem, they can roll the network back to its initial state by disabling the Segment Routing PST on the PCEP speakers and resetting the PCEP sessions.
* オペレーターが問題を検出した場合、PCEPスピーカーのセグメントルーティングPSTを無効にし、PCEPセッションをリセットすることにより、ネットワークを初期状態に戻すことができます。
Note that the data plane is unaffected if a PCEP session is reset. Any LSPs that were set up before the session reset will remain in place and will still be present after the session comes back up.
PCEPセッションがリセットされても、データプレーンは影響を受けないことに注意してください。セッションがリセットされる前にセットアップされたLSPはそのまま残り、セッションが復旧した後も存在します。
An implementation SHOULD allow the operator to manually trigger a PCEP session to be reset.
実装では、オペレーターがPCEPセッションを手動でトリガーしてリセットできるようにする必要があります（SHOULD）。
An implementation MAY automatically reset a PCEP session when an operator reconfigures the PCEP speaker's capabilities. However, note that if the capabilities at both ends of the PCEP session are not reconfigured simultaneously, then the session could be reset twice, which could lead to unnecessary network traffic. Therefore, such implementations SHOULD allow the operator to override this behavior and wait instead for a manual reset.
実装は、オペレーターがPCEPスピーカーの機能を再構成するときに、PCEPセッションを自動的にリセットする場合があります。ただし、PCEPセッションの両端の機能が同時に再構成されない場合、セッションが2回リセットされ、不要なネットワークトラフィックが発生する可能性があることに注意してください。したがって、そのような実装は、オペレーターがこの動作をオーバーライドして、代わりに手動リセットを待つことを許可する必要があります（SHOULD）。
Once Segment Routing is enabled on a PCEP session, it can be used as the path setup type for future LSPs.
PCEPセッションでセグメントルーティングを有効にすると、将来のLSPのパスセットアップタイプとして使用できます。
User traffic is not automatically migrated from existing LSPs onto segment-routed LSPs just by enabling the Segment Routing PST in PCEP. The migration of user traffic from existing LSPs onto Segment Routing LSPs is beyond the scope of this document.
PCEPでセグメントルーティングPSTを有効にするだけでは、ユーザートラフィックは既存のLSPからセグメントルーティングLSPに自動的に移行されません。既存のLSPからセグメントルーティングLSPへのユーザートラフィックの移行は、このドキュメントの範囲外です。
The operator needs the following information to verify that PCEP is operating correctly with respect to the Segment Routing path setup type.
オペレーターは、セグメントルーティングパスのセットアップタイプに関してPCEPが正しく動作していることを確認するために、次の情報が必要です。
* An implementation SHOULD allow the operator to view whether the PCEP speaker sent the Segment Routing PST capability to its peer. If the PCEP speaker is a PCC, then the implementation SHOULD also allow the operator to view the values of the L-Flag and N-Flag that were sent and the value of the MSD field that was sent.
* 実装は、オペレーターがPCEPスピーカーがセグメントルーティングPST機能をピアに送信したかどうかを確認できるようにする必要があります（SHOULD）。 PCEPスピーカーがPCCの場合、実装では、送信されたLフラグとNフラグの値と送信されたMSDフィールドの値をオペレーターが表示できるようにする必要があります（SHOULD）。
* An implementation SHOULD allow the operator to view whether the peer sent the Segment Routing PST capability. If the peer is a PCC, then the implementation SHOULD also allow the operator to view the values of the L-Flag and N-Flag and MSD fields that the peer sent.
* 実装は、ピアがセグメントルーティングPST機能を送信したかどうかをオペレーターが確認できるようにする必要があります（SHOULD）。ピアがPCCの場合、実装では、ピアが送信したLフラグとNフラグ、およびMSDフィールドの値をオペレーターが表示できるようにする必要があります（SHOULD）。
* An implementation SHOULD allow the operator to view whether the Segment Routing PST is enabled on the PCEP session.
* 実装は、オペレーターがPCEPセッションでセグメントルーティングPSTが有効になっているかどうかを確認できるようにする必要があります（SHOULD）。
* If one PCEP speaker advertises the Segment Routing PST capability, but the other does not, then the implementation SHOULD create a log to inform the operator of the capability mismatch.
* 1つのPCEPスピーカーがセグメントルーティングPST機能をアドバタイズし、他のPCEPスピーカーがアドバタイズしない場合、実装は機能の不一致をオペレーターに通知するためにログを作成する必要があります（SHOULD）。
* An implementation SHOULD allow the operator to view the PST that was proposed, or requested, for an LSP and the PST that was actually used.
* 実装は、LSPに対して提案または要求されたPSTと実際に使用されたPSTをオペレーターが表示できるようにする必要があります（SHOULD）。
* If a PCEP speaker decides to use a different PST to the one that was proposed, or requested, for an LSP, then the implementation SHOULD create a log to inform the operator that the expected PST has not been used. The log SHOULD give the reason for this choice (local policy, equipment capability, etc.).
* PCEPスピーカーが、LSPに対して提案または要求されたものとは異なるPSTを使用することを決定した場合、実装は、期待されるPSTが使用されなかったことをオペレーターに通知するためにログを作成する必要があります。ログは、この選択の理由（ローカルポリシー、機器の機能など）を示す必要があります（SHOULD）。
* If a PCEP speaker rejects a Segment Routing path, then it SHOULD create a log to inform the operator, giving the reason for the decision (local policy, MSD exceeded, etc.).
* PCEPスピーカーがセグメントルーティングパスを拒否する場合は、ログを作成してオペレーターに通知し、決定の理由（ローカルポリシー、MSD超過など）を通知する必要があります（SHOULD）。
The PCEP YANG module is defined in [PCE-PCEP-YANG]. In the future, this YANG module should be extended or augmented to provide the following additional information relating to Segment Routing:
PCEP YANGモジュールは[PCE-PCEP-YANG]で定義されています。将来的には、このYANGモジュールを拡張または拡張して、セグメントルーティングに関する次の追加情報を提供する必要があります。
* The advertised PST capabilities and MSD per PCEP session.
* アドバタイズされたPST機能とPCEPセッションごとのMSD。
* The PST configured for, and used by, each LSP.
* 各LSPに対して構成され、使用されるPST。
The PCEP MIB [RFC7420] could also be updated to include this information.
PCEP MIB [RFC7420]もこの情報を含むように更新できます。
The security considerations described in [RFC5440], [RFC8231], [RFC8281], and [RFC8408] are applicable to this specification. No additional security measures are required.
[RFC5440]、[RFC8231]、[RFC8281]、および[RFC8408]で説明されているセキュリティの考慮事項は、この仕様に適用されます。追加のセキュリティ対策は必要ありません。
Note that this specification enables a network controller to instantiate a path in the network without the use of a hop-by-hop signaling protocol (such as RSVP-TE). This creates an additional vulnerability if the security mechanisms of [RFC5440], [RFC8231], and [RFC8281] are not used. If there is no integrity protection on the session, then an attacker could create a path that is not subjected to the further verification checks that would be performed by the signaling protocol.
この仕様により、ネットワークコントローラーはホップバイホップシグナリングプロトコル（RSVP-TEなど）を使用せずにネットワーク内のパスをインスタンス化できるようになります。 [RFC5440]、[RFC8231]、および[RFC8281]のセキュリティメカニズムが使用されていない場合、これは追加の脆弱性を作成します。セッションに整合性保護がない場合、攻撃者は、シグナリングプロトコルによって実行される追加の検証チェックを受けないパスを作成する可能性があります。
Note that this specification adds the MSD field to the Open message (see Section 4.1.2), which discloses how many MPLS labels the sender can push onto packets that it forwards into the network. If the security mechanisms of [RFC8231] and [RFC8281] are not used with strong encryption, then an attacker could use this new field to gain intelligence about the capabilities of the edge devices in the network.
この仕様は、MSDフィールドをOpenメッセージに追加することに注意してください（セクション4.1.2を参照）。これは、送信者がネットワークに転送するパケットにプッシュできるMPLSラベルの数を開示します。 [RFC8231]と[RFC8281]のセキュリティメカニズムが強力な暗号化で使用されていない場合、攻撃者はこの新しいフィールドを使用して、ネットワーク内のエッジデバイスの機能に関するインテリジェンスを取得できます。
This document defines a new subobject type for the PCEP ERO and a new subobject type for the PCEP RRO. The codepoints for subobject types of these objects are maintained in the "Resource Reservation Protocol (RSVP) Parameters" registry, under the EXPLICIT_ROUTE and ROUTE_RECORD objects, respectively.
このドキュメントでは、PCEP EROの新しいサブオブジェクトタイプとPCEP RROの新しいサブオブジェクトタイプを定義します。これらのオブジェクトのサブオブジェクトタイプのコードポイントは、それぞれEXPLICIT_ROUTEオブジェクトとROUTE_RECORDオブジェクトの下の「リソース予約プロトコル（RSVP）パラメータ」レジストリで維持されます。
+----------------+------------------------+----------------+
| Object | Subobject | Subobject Type |
+================+========================+================+
| EXPLICIT_ROUTE | SR-ERO (PCEP specific) | 36 |
+----------------+------------------------+----------------+
| ROUTE_RECORD | SR-RRO (PCEP specific) | 36 |
+----------------+------------------------+----------------+
Table 1
表1
IANA has created a new sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP SR-ERO NAI Types". The allocation policy for this new registry is by IETF Review [RFC8126]. The new registry contains the following values:
IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリ内に「PCEP SR-ERO NAI Types」と呼ばれる新しいサブレジストリを作成しました。この新しいレジストリの割り当てポリシーは、IETFレビュー[RFC8126]によるものです。新しいレジストリには、次の値が含まれています。
+-------+-------------------------------+---------------+
| Value | Description | Reference |
+=======+===============================+===============+
| 0 | NAI is absent. | This document |
+-------+-------------------------------+---------------+
| 1 | NAI is an IPv4 node ID. | This document |
+-------+-------------------------------+---------------+
| 2 | NAI is an IPv6 node ID. | This document |
+-------+-------------------------------+---------------+
| 3 | NAI is an IPv4 adjacency. | This document |
+-------+-------------------------------+---------------+
| 4 | NAI is an IPv6 adjacency with | This document |
| | global IPv6 addresses. | |
+-------+-------------------------------+---------------+
| 5 | NAI is an unnumbered | This document |
| | adjacency with IPv4 node IDs. | |
+-------+-------------------------------+---------------+
| 6 | NAI is an IPv6 adjacency with | This document |
| | link-local IPv6 addresses. | |
+-------+-------------------------------+---------------+
| 7-15 | Unassigned | |
+-------+-------------------------------+---------------+
Table 2
表2
IANA has created a new sub-registry, named "SR-ERO Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the SR-ERO subobject. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
IANAは、SR-EROサブオブジェクトのフラグフィールドを管理するために、「パス計算要素プロトコル（PCEP）番号」レジストリ内に「SR-EROフラグフィールド」という名前の新しいサブレジストリを作成しました。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとして数えます）
* Capability description
* 機能の説明
* Defining RFC
* RFCの定義
The following values are defined in this document:
このドキュメントでは、次の値が定義されています。
+-----+---------------------------------+---------------+
| Bit | Description | Reference |
+=====+=================================+===============+
| 0-7 | Unassigned | |
+-----+---------------------------------+---------------+
| 8 | NAI is absent (F) | This document |
+-----+---------------------------------+---------------+
| 9 | SID is absent (S) | This document |
+-----+---------------------------------+---------------+
| 10 | SID specifies TC, S, and TTL in | This document |
| | addition to an MPLS label (C) | |
+-----+---------------------------------+---------------+
| 11 | SID specifies an MPLS label (M) | This document |
+-----+---------------------------------+---------------+
Table 3
表3
IANA has allocated the following codepoints in the "PCEP-ERROR Object Error Types and Values" registry for the following new Error-values:
IANAは、次の新しいエラー値に対して、「PCEP-ERRORオブジェクトのエラータイプと値」レジストリに次のコードポイントを割り当てました。
+------------+-----------------+---------------------------------+
| Error-Type | Meaning | Error-value |
+============+=================+=================================+
| 10 | Reception of an | |
| | invalid object | |
+------------+-----------------+---------------------------------+
| | | 2: Bad label value |
+------------+-----------------+---------------------------------+
| | | 3: Unsupported number of SR-ERO |
| | | subobjects |
+------------+-----------------+---------------------------------+
| | | 4: Bad label format |
+------------+-----------------+---------------------------------+
| | | 5: ERO mixes SR-ERO subobjects |
| | | with other subobject types |
+------------+-----------------+---------------------------------+
| | | 6: Both SID and NAI are absent |
| | | in the SR-ERO subobject |
+------------+-----------------+---------------------------------+
| | | 7: Both SID and NAI are absent |
| | | in the SR-RRO subobject |
+------------+-----------------+---------------------------------+
| | | 9: MSD exceeds the default for |
| | | the PCEP session |
+------------+-----------------+---------------------------------+
| | | 10: RRO mixes SR-RRO subobjects |
| | | with other subobject types |
+------------+-----------------+---------------------------------+
| | | 12: Missing PCE-SR-CAPABILITY |
| | | sub-TLV |
+------------+-----------------+---------------------------------+
| | | 13: Unsupported NAI Type in the |
| | | SR-ERO/SR-RRO subobject |
+------------+-----------------+---------------------------------+
| | | 14: Unknown SID |
+------------+-----------------+---------------------------------+
| | | 15: NAI cannot be resolved to a |
| | | SID |
+------------+-----------------+---------------------------------+
| | | 16: Could not find SRGB |
+------------+-----------------+---------------------------------+
| | | 17: SID index exceeds SRGB size |
+------------+-----------------+---------------------------------+
| | | 18: Could not find SRLB |
+------------+-----------------+---------------------------------+
| | | 19: SID index exceeds SRLB size |
+------------+-----------------+---------------------------------+
| | | 20: Inconsistent SIDs in SR-ERO |
| | | / SR-RRO subobjects |
+------------+-----------------+---------------------------------+
| | | 21: MSD must be non-zero |
+------------+-----------------+---------------------------------+
Table 4
表4
IANA has allocated the following codepoint in the "PCEP TLV Type Indicators" registry. Note that this TLV type indicator is deprecated but retained in the registry to ensure compatibility with early implementations of this specification. See Appendix A for details.
IANAは、「PCEP TLV Type Indicators」レジストリに次のコードポイントを割り当てました。このTLVタイプインジケーターは非推奨ですが、この仕様の初期の実装との互換性を確保するためにレジストリに保持されています。詳細については、付録Aを参照してください。
+-------+--------------------------------+---------------+
| Value | Meaning | Reference |
+=======+================================+===============+
| 26 | SR-PCE-CAPABILITY (deprecated) | This document |
+-------+--------------------------------+---------------+
Table 5
表5
IANA has created a new sub-registry, named "PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. New values are to be assigned by Standards Action [RFC8126]. The valid range of values in the registry is 0-65535. IANA has initialized the registry with the following values. All other values in the registry should be marked as "Unassigned".
IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリ内に「PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators」という名前の新しいサブレジストリを作成し、サブパスのサブTLVのタイプインジケータスペースを管理しますPATH-SETUP-TYPE-CAPABILITY TLV。新しい値は、標準アクション[RFC8126]によって割り当てられます。レジストリ内の値の有効範囲は0〜65535です。 IANAはレジストリを次の値で初期化しました。レジストリ内の他のすべての値は、「未割り当て」としてマークする必要があります。
+-------+-------------------+---------------+
| Value | Meaning | Reference |
+=======+===================+===============+
| 0 | Reserved | This document |
+-------+-------------------+---------------+
| 26 | SR-PCE-CAPABILITY | This document |
+-------+-------------------+---------------+
Table 6
表6
A sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types" was created in [RFC8408]. IANA has allocated a new codepoint within this registry, as follows:
「PCEPパス設定タイプ」と呼ばれる「パス計算要素プロトコル（PCEP）番号」レジストリ内のサブレジストリは、[RFC8408]で作成されました。 IANAは、次のように、このレジストリ内に新しいコードポイントを割り当てました。
+-------+-------------------------------+-----------+
| Value | Description | Reference |
+=======+===============================+===========+
| 1 | Traffic-engineering path is | This |
| | set up using Segment Routing. | document |
+-------+-------------------------------+-----------+
Table 7
表7
IANA has allocated the following codepoint in the PCEP "METRIC Object T Field" registry:
IANAは、PCEP "METRIC Object T Field"レジストリに次のコードポイントを割り当てました。
+-------+-------------------------+---------------+
| Value | Description | Reference |
+=======+=========================+===============+
| 11 | Segment-ID (SID) Depth. | This document |
+-------+-------------------------+---------------+
Table 8
表8
IANA has created a new sub-registry, named "SR Capability Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the SR-PCE-CAPABILITY TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
IANAは、SR-PCE-CAPABILITY TLVのフラグフィールドを管理するために、「パス計算要素プロトコル（PCEP）番号」レジストリ内に「SR機能フラグフィールド」という名前の新しいサブレジストリを作成しました。新しい値は、標準アクション[RFC8126]によって割り当てられます。各ビットは、次の品質で追跡する必要があります。
* Bit number (counting from bit 0 as the most significant bit)
* ビット番号（ビット0を最上位ビットとして数えます）
* Capability description
* 機能の説明
* Defining RFC
* RFCの定義
The following values are defined in this document:
このドキュメントでは、次の値が定義されています。
+-----+------------------------------+-----------+
| Bit | Description | Reference |
+=====+==============================+===========+
| 0-5 | Unassigned | |
+-----+------------------------------+-----------+
| 6 | Node or Adjacency Identifier | This |
| | (NAI) is supported (N) | document |
+-----+------------------------------+-----------+
| 7 | Unlimited Maximum SID Depth | This |
| | (X) | document |
+-----+------------------------------+-----------+
Table 9
表9
[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>。
[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>。
[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>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[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>。
[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>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< https://www.rfc-editor.org/info/rfc8231>。
[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>.
[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのパス計算要素通信プロトコル（PCEP）拡張」、RFC 8281、DOI 10.17487 / RFC8281、2017年12月、<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>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. Hardwick, "Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8408] Sivabalan、S.、Tantsura、J.、Minei、I.、Varga、R.、and J. Hardwick、 "Conveying Path Setup Type in PCE Communication Protocol（PCEP）Messages"、RFC 8408、DOI 10.17487 / RFC8408 、2018年7月、<https://www.rfc-editor.org/info/rfc8408>。
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, <https://www.rfc-editor.org/info/rfc8491>.
[RFC8491] Tantsura、J.、Chunduri、U.、Aldrin、S。、およびL. Ginsberg、「IS-ISを使用したシグナリングの最大SID深度（MSD）」、RFC 8491、DOI 10.17487 / RFC8491、2018年11月、<https ：//www.rfc-editor.org/info/rfc8491>。
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.
[RFC8660] Bashandy、A。、編、Filsfils、C。、編、Previdi、S.、Decraene、B.、Litkowski、S。、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、RFC 8660、DOI 10.17487 / RFC8660、2019年12月、<https://www.rfc-editor.org/info/rfc8660>。
[IPv6-SRH] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", Work in Progress, Internet-Draft, draft-ietf-6man-segment-routing-header-26, 22 October 2019, <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26>.
[IPv6-SRH] Filsfils、C.、Dukes、D.、Previdi、S.、Leddy、J.、Matsushima、S。、およびD. Voyer、「IPv6 Segment Routing Header（SRH）」、Work in Progress、インターネット-Draft、draft-ietf-6man-segment-routing-header-26、2019年10月22日、<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26>。
[MSD-BGP] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., and N. Triantafillis, "Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-ls-segment-routing-msd-09, 15 October 2019, <https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-09>.
[MSD-BGP] Tantsura、J.、Chunduri、U.、Talaulikar、K.、Mirsky、G。、およびN. Triantafillis、「ボーダーゲートウェイプロトコルリンクステートを使用したMSD（最大SID深度）のシグナリング」、作業中、Internet-Draft、draft-ietf-idr-bgp-ls-segment-routing-msd-09、2019年10月15日、<https://tools.ietf.org/html/draft-ietf-idr-bgp-ls- segment-routing-msd-09>。
[PCE-PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October 2019, <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.
[PCE-PCEP-YANG] Dhody、D.、Hardwick、J.、Beeram、V。、およびJ. Tantsura、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、インターネットドラフト、draft-ietf-pce-pcep-yang-13、2019年10月31日、<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC4657] Ash、J.、Ed。およびJ.L. Le Roux、Ed。、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、DOI 10.17487 / RFC4657、2006年9月、<https://www.rfc-editor.org/info/rfc4657>。
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、RFC 7420、DOI 10.17487 / RFC7420、2014年12月、<https://www.rfc-editor.org/info/rfc7420>。
[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>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework for Scheduled Use of Resources", RFC 8413, DOI 10.17487/RFC8413, July 2018, <https://www.rfc-editor.org/info/rfc8413>.
[RFC8413] Zhuang、Y.、Wu、Q.、Chen、H。、およびA. Farrel、「スケジュールされたリソースの使用のためのフレームワーク」、RFC 8413、DOI 10.17487 / RFC8413、2018年7月、<https：// www。 rfc-editor.org/info/rfc8413>。
[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, <https://www.rfc-editor.org/info/rfc8476>.
[RFC8476] Tantsura、J.、Chunduri、U.、Aldrin、S。、およびP. Psenak、「OSPFを使用したシグナリングの最大SID深度（MSD）」、RFC 8476、DOI 10.17487 / RFC8476、2018年12月、<https：/ /www.rfc-editor.org/info/rfc8476>。
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.
[RFC8665] Psenak、P。、編、Previdi、S。、編、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W。、およびJ. Tantsura、「セグメントルーティングのOSPF拡張"、RFC 8665、DOI 10.17487 / RFC8665、2019年12月、<https://www.rfc-editor.org/info/rfc8665>。
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.
[RFC8667] Previdi、S.、Ed。、Ginsberg、L.、Ed。、Filsfils、C.、Bashandy、A.、Gredler、H.、and B. Decraene、 "IS-IS Extensions for Segment Routing"、RFC 8667、DOI 10.17487 / RFC8667、2019年12月、<https://www.rfc-editor.org/info/rfc8667>。
[SR-POLICY] Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-05, 17 November 2019, <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-05>.
[SR-POLICY] Filsfils、C.、Sivabalan、S.、Voyer、D.、Bogdanov、A。、およびP. Mattes、「Segment Routing Policy Architecture」、Work in Progress、Internet-Draft、draft-ietf-spring -segment-routing-policy-05、2019年11月17日、<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-05>。
An early implementation of this specification will send the SR-CAPABILITY-TLV as a top-level TLV in the OPEN object instead of sending the PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object. Implementations that wish to interoperate with such early implementations should also send the SR-CAPABILITY-TLV as a top-level TLV in their OPEN object and should interpret receiving this top-level TLV as though the sender had sent a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP-TE and SR-TE PSTs are supported) with the SR-CAPABILITY-TLV as a sub-TLV. If a PCEP speaker receives an OPEN object in which both the SR-CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level TLVs, then it should ignore the top-level SR-CAPABILITY-TLV and process only the PATH-SETUP-TYPE-CAPABILITY TLV.
この仕様の初期の実装では、OPENオブジェクトでPATH-SETUP-TYPE-CAPABILITY TLVを送信する代わりに、OPENオブジェクトでトップレベルのTLVとしてSR-CAPABILITY-TLVを送信します。そのような初期の実装と相互運用したい実装は、SR-CAPABILITY-TLVをOPENオブジェクトのトップレベルTLVとして送信し、送信者がPATH-SETUP-TYPE-を送信したかのように、このトップレベルTLVの受信を解釈する必要があります。 PSTリストが（0、1）のCAPABILITY TLV（つまり、RSVP-TE PSRとSR-TE PSTの両方がサポートされます）は、SR-CAPABILITY-TLVをサブTLVとして使用します。 PCEPスピーカーが、SR-CAPABILITY-TLVとPATH-SETUP-TYPE-CAPABILITY TLVの両方がトップレベルのTLVとして表示されるOPENオブジェクトを受信した場合、トップレベルのSR-CAPABILITY-TLVを無視して、 PATH-SETUP-TYPE-CAPABILITY TLV。
Acknowledgements
謝辞
We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing-Wher Chen, and Tomas Janciga for the valuable comments.
貴重なコメントをいただいたイナミネイ、ジョージスワロー、マレクザボドスキー、ドゥルーフドーディ、イングワーチェン、トーマスジャンシガに感謝します。
Contributors
貢献者
The following people contributed to this document:
以下の人々がこの文書に貢献しました：
* Lakshmi Sharma * Jan Medved * Edward Crabbe * Robert Raszuk * Victor Lopez
* ラクシュミシャルマ* Jan Medved * Edward Crabbe * Robert Raszuk * Victor Lopez
Authors' Addresses
著者のアドレス
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata Ontario K2K 3E8 Canada
Siva Sivabalan Cisco Systems、Ins。 To00 Innovation Drive Canata Ontario A2C3A ৮カナダ
Email: msiva@cisco.com
Clarence Filsfils Cisco Systems, Inc. Pegasus Parc Brabant 1831 De kleetlaan 6a Belgium
Clarence Filsfils Cisco Systems、Inc. Pegasus Parc Brabant 1831 De kleetlaan 6aベルギー
Email: cfilsfil@cisco.com
Jeff Tantsura Apstra, Inc. 333 Middlefield Rd #200 Menlo Park, CA 94025 United States of America
Jeff Tantsura Apstra、Inc. 333 Middlefield Rd＃200 Menlo Park、CA 94025アメリカ合衆国
Email: jefftant.ietf@gmail.com
Wim Henderickx Nokia Copernicuslaan 50 95134 Antwerp 2018 Belgium
Wim Henderickx Nokia Copernicuslaan 50 95134アントワープ2018ベルギー
Email: wim.henderickx@nokia.com
Jon Hardwick Metaswitch Networks 100 Church Street Enfield United Kingdom
Jon Hardwick Metaswitch Networks 100 Church Street Enfieldイギリス
Email: jonathan.hardwick@metaswitch.com