[要約] RFC 9256は、Segment Routing Policy Architectureを定義し、パケットフローを任意の経路に誘導することを可能にする。SRポリシーは、ソースルーティングを利用した指示の順序付きリストであり、ヘッドエンドノードでインスタンス化される。
Internet Engineering Task Force (IETF) C. Filsfils
Request for Comments: 9256 K. Talaulikar, Ed.
Updates: 8402 Cisco Systems, Inc.
Category: Standards Track D. Voyer
ISSN: 2070-1721 Bell Canada
A. Bogdanov
British Telecom
P. Mattes
Microsoft
July 2022
Segment Routing Policy Architecture
セグメントルーティングポリシーアーキテクチャ
Abstract
概要
Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
セグメントルーティング（SR）により、ノードは任意のパスに沿ってパケットフローを操作できます。ソースルーティングのおかげで、パスごとの中間状態は排除されます。SRポリシーは、ソースルーティングされたポリシーを表すセグメント（すなわち、指示）の順序付けられたリストです。パケットフローは、ヘッドエンドノードと呼ばれるインスタンス化されるノード上のSRポリシーに操縦されます。SRポリシーに操縦されたパケットには、そのSRポリシーに関連するセグメントの順序付けられたリストがあります。
This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.
このドキュメントは、SRポリシーの概念とSRポリシーへの操縦の概念を詳述するため、RFC 8402を更新します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9256.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9256で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. SR Policy
2.1. Identification of an SR Policy
2.2. Candidate Path and Segment List
2.3. Protocol-Origin of a Candidate Path
2.4. Originator of a Candidate Path
2.5. Discriminator of a Candidate Path
2.6. Identification of a Candidate Path
2.7. Preference of a Candidate Path
2.8. Validity of a Candidate Path
2.9. Active Candidate Path
2.10. Validity of an SR Policy
2.11. Instantiation of an SR Policy in the Forwarding Plane
2.12. Priority of an SR Policy
2.13. Summary
3. Segment Routing Database
4. Segment Types
4.1. Explicit Null
5. Validity of a Candidate Path
5.1. Explicit Candidate Path
5.2. Dynamic Candidate Path
5.3. Composite Candidate Path
6. Binding SID
6.1. BSID of a Candidate Path
6.2. BSID of an SR Policy
6.3. Forwarding Plane
6.4. Non-SR Usage of Binding SID
7. SR Policy State
8. Steering into an SR Policy
8.1. Validity of an SR Policy
8.2. Drop-upon-Invalid SR Policy
8.3. Incoming Active SID is a BSID
8.4. Per-Destination Steering
8.5. Recursion on an On-Demand Dynamic BSID
8.6. Per-Flow Steering
8.7. Policy-Based Routing
8.8. Optional Steering Modes for BGP Destinations
9. Recovering from Network Failures
9.1. Leveraging TI-LFA Local Protection of the Constituent IGP
Segments
9.2. Using an SR Policy to Locally Protect a Link
9.3. Using a Candidate Path for Path Protection
10. Security Considerations
11. Manageability Considerations
12. IANA Considerations
12.1. Guidance for Designated Experts
13. References
13.1. Normative References
13.2. Informative References
Acknowledgement
Contributors
Authors' Addresses
Segment Routing (SR) [RFC8402] allows a node to steer a packet flow along any path. The headend is a node where the instructions for source routing (i.e., segments) are written into the packet. It hence becomes the starting node for a specific segment routing path. Intermediate per-path states are eliminated thanks to source routing.
セグメントルーティング（SR）[RFC8402]により、ノードは任意のパスに沿ってパケットフローを操作できます。ヘッドエンドは、ソースルーティングの指示（つまり、セグメント）がパケットに書き込まれるノードです。したがって、特定のセグメントルーティングパスの開始ノードになります。ソースルーティングのおかげで、パスごとの中間状態は排除されます。
A Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of segments (i.e., instructions) that represent a source-routed policy. The headend node is said to steer a flow into an SR Policy. The packets steered into an SR Policy have an ordered list of segments associated with that SR Policy written into them. [RFC8660] describes the representation and processing of this ordered list of segments as an MPLS label stack for SR-MPLS, while [RFC8754] and [RFC8986] describe the same for Segment Routing over IPv6 (SRv6) with the use of the Segment Routing Header (SRH).
セグメントルーティングポリシー（SRポリシー）[RFC8402]は、ソースルーティングされたポリシーを表すセグメント（つまり、指示）の順序付けられたリストです。ヘッドエンドノードは、流れをSRポリシーに導くと言われています。SRポリシーに進むパケットには、そのSRポリシーに関連付けられたセグメントの順序付けられたリストがあります。[RFC8660]は、この順序付けられたセグメントリストのSR-MPLSのMPLSラベルスタックとしての表現と処理を説明し、[RFC8754]および[RFC8986]は、セグメントルーティングのセグメントルーティングとセグメントルーティングの使用と同じことを説明しています。ヘッダー（SRH）。
[RFC8402] introduces the SR Policy construct and provides an overview of how it is leveraged for Segment Routing use cases. This document updates [RFC8402] to specify detailed concepts of SR Policy and steering packets into an SR Policy. It applies equally to the SR-MPLS and SRv6 instantiations of segment routing.
[RFC8402]は、SRポリシーコンストラクトを導入し、セグメントルーティングユースケースにレバレッジされている方法の概要を提供します。このドキュメントは[RFC8402]を更新して、SRポリシーとステアリングパケットの詳細な概念をSRポリシーに指定します。セグメントルーティングのSR-MPLSおよびSRV6インスタンス化に等しく適用されます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The general concept of SR Policy provides a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy for the steering of traffic for a specific purpose (e.g., for a specific Service Level Agreement (SLA)) from that node.
SRポリシーの一般的な概念は、特定の目的のためのトラフィックのステアリングのためのソースルーティングポリシーを実装するためのノード上の順序付けられたセグメントのリストのインスタンス化を可能にするフレームワークを提供します（例：特定のサービスレベル契約（SLA））そのノードから。
The Segment Routing architecture [RFC8402] specifies that any instruction can be bound to a segment. Thus, an SR Policy can be built using any type of Segment Identifier (SID) including those associated with topological or service instructions.
セグメントルーティングアーキテクチャ[RFC8402]は、任意の命令がセグメントにバインドできることを指定しています。したがって、SRポリシーは、トポロジーまたはサービスの指示に関連するものを含む、あらゆるタイプのセグメント識別子（SID）を使用して構築できます。
This section defines the key aspects and constituents of an SR Policy.
このセクションでは、SRポリシーの重要な側面と構成要素を定義します。
An SR Policy MUST be identified through the tuple <Headend, Color, Endpoint>. In the context of a specific headend, an SR Policy MUST be identified by the <Color, Endpoint> tuple.
SRポリシーは、tuple <headend、color、endpoint>を介して特定する必要があります。特定のヘッドエンドのコンテキストでは、SRポリシーは<Color、Endpoint> Tupleによって特定する必要があります。
The headend is the node where the policy is instantiated/implemented. The headend is specified as an IPv4 or IPv6 address and MUST resolve to a unique node in the SR domain [RFC8402].
ヘッドエンドは、ポリシーがインスタンス化/実装されているノードです。ヘッドエンドはIPv4またはIPv6アドレスとして指定されており、SRドメイン[RFC8402]の一意のノードに解決する必要があります。
The endpoint indicates the destination of the policy. The endpoint is specified as an IPv4 or IPv6 address and SHOULD resolve to a unique node in the domain. In a specific case (refer to Section 8.8.1), the endpoint can be the unspecified address (0.0.0.0 for IPv4, :: for IPv6) and in this case, the destination of the policy is indicated by the last segment in the segment list(s).
エンドポイントは、ポリシーの宛先を示します。エンドポイントはIPv4またはIPv6アドレスとして指定されており、ドメイン内の一意のノードに解決する必要があります。特定のケース（セクション8.8.1を参照）では、エンドポイントは不特定のアドレス（IPv4の0.0.0.0、IPv6の場合は0.0.0.0）になります。セグメントリスト。
The color is an unsigned non-zero 32-bit integer value that associates the SR Policy with an intent or objective (e.g., low latency).
色は、SRポリシーを意図または目的（たとえば低遅延）に関連付けるゼロ32ビット整数値のない署名されていない32ビット整数値です。
The endpoint and the color are used to automate the steering of service or transport routes on SR Policies (refer to Section 8).
エンドポイントと色は、SRポリシーのサービスまたは輸送ルートのステアリングを自動化するために使用されます（セクション8を参照）。
An implementation MAY allow the assignment of a symbolic name comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy to serve as a user-friendly attribute for debugging and troubleshooting purposes. Such symbolic names may identify an SR Policy when the naming scheme ensures uniqueness. The SR Policy name MAY also be signaled along with a candidate path of the SR Policy (refer to Section 2.2). An SR Policy MAY have multiple names associated with it in the scenario where the headend receives different SR Policy names along with different candidate paths for the same SR Policy via the same or different sources.
実装により、印刷可能なASCII [RFC0020]文字（つまり、0x20〜0x7e）を含むシンボリック名をSRポリシーに割り当てることができ、デバッグおよびトラブルシューティングの目的のためのユーザーフレンドリーな属性として機能します。このような象徴的な名前は、命名スキームが一意性を保証する場合、SRポリシーを特定する場合があります。SRポリシー名は、SRポリシーの候補パスとともに合図することもできます（セクション2.2を参照）。SRポリシーには、同じソースまたは異なるソースを介して同じSRポリシーの異なる候補パスとともに、ヘッドエンドが異なるSRポリシー名を受信するシナリオでは、複数の名前が関連付けられている場合があります。
An SR Policy is associated with one or more candidate paths. A candidate path is the unit for signaling of an SR Policy to a headend via protocol extensions like the Path Computation Element Communication Protocol (PCEP) [RFC8664] [PCEP-SR-POLICY-CP] or BGP SR Policy [BGP-SR-POLICY].
SRポリシーは、1つ以上の候補パスに関連付けられています。候補パスは、パス計算要素通信プロトコル（PCEP）[RFC8664] [PCEP-SR-Policy-CP]またはBGP SRポリシー[BGP-SR-Policyyなどのプロトコル拡張を介してヘッドエンドへのSRポリシーのシグナリングのユニットです。]。
A segment list represents a specific source-routed path to send traffic from the headend to the endpoint of the corresponding SR Policy.
セグメントリストは、ヘッドエンドから対応するSRポリシーのエンドポイントにトラフィックを送信する特定のソースルーティングパスを表します。
A candidate path is either dynamic, explicit, or composite.
候補パスは、動的、明示的、または複合です。
An explicit candidate path is expressed as a segment list or a set of segment lists.
明示的な候補パスは、セグメントリストまたはセグメントリストのセットとして表されます。
A dynamic candidate path expresses an optimization objective and a set of constraints for a specific data plane (i.e., SR-MPLS or SRv6). The headend (potentially with the help of a PCE) computes a solution segment list (or set of segment lists) that solves the optimization problem.
動的候補パスは、特定のデータプレーン（つまり、SR-MPLSまたはSRV6）の最適化目標と一連の制約を表します。ヘッドエンド（潜在的にPCEの助けを借りて）は、最適化問題を解決するソリューションセグメントリスト（またはセグメントリストのセット）を計算します。
If a candidate path is associated with a set of segment lists, each segment list is associated with weight for weighted load balancing (refer to Section 2.11 for details). The default weight is 1.
候補パスがセグメントリストのセットに関連付けられている場合、各セグメントリストは加重負荷分散の重みに関連付けられています（詳細についてはセクション2.11を参照）。デフォルトの重みは1です。
A composite candidate path acts as a container for grouping SR Policies. The composite candidate path construct enables the combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for load-balanced steering of packet flows over its constituent SR Policies. The following criteria apply for inclusion of constituent SR Policies using a composite candidate path under a parent SR Policy:
複合候補パスは、SRポリシーをグループ化するためのコンテナとして機能します。複合候補パス構築により、SRポリシーの組み合わせが可能になります。それぞれが、潜在的に異なる最適化目標と制約を備えた明示的な候補パスおよび/または動的候補パスを備えており、その構成要素SRポリシーを積極的に流すためのパケットのバランスの取れたステアリングを行います。次の基準では、親SRポリシーの下で複合候補パスを使用して、構成要素SRポリシーを含めることを適用します。
* The endpoints of the constituent SR Policies and the parent SR Policy MUST be identical.
* 構成要素SRポリシーのエンドポイントと親SRポリシーは同一でなければなりません。
* The colors of each of the constituent SR Policies and the parent SR Policy MUST be different.
* 構成要素SRポリシーのそれぞれの色と親SRポリシーは異なる必要があります。
* The constituent SR Policies MUST NOT use composite candidate paths.
* 構成要素SRポリシーは、複合候補パスを使用してはなりません。
Each constituent SR Policy of a composite candidate path is associated with weight for load-balancing purposes (refer to Section 2.11 for details). The default weight is 1.
複合候補パスの各構成SRポリシーは、負荷分散の目的で重量に関連付けられています（詳細については、セクション2.11を参照）。デフォルトの重みは1です。
Section 2.13 illustrates an information model for hierarchical relationships between the SR Policy constructs described in this section.
セクション2.13は、このセクションで説明するSRポリシーコンストラクト間の階層的な関係の情報モデルを示しています。
A headend may be informed about a candidate path for an SR Policy <Color, Endpoint> by various means including: via configuration, PCEP [RFC8664] [PCEP-SR-POLICY-CP], or BGP [BGP-SR-POLICY].
ヘッドエンドは、SRポリシー<色、エンドポイント>の候補パスについて通知される場合があります。
Protocol-Origin of a candidate path is an 8-bit value associated with the mechanism or protocol used for signaling/provisioning the SR Policy. It helps identify the protocol/mechanism that provides or signals the candidate path and indicates its preference relative to other protocols/mechanisms.
候補パスのプロトコルオリジンは、SRポリシーのシグナリング/プロビジョニングに使用されるメカニズムまたはプロトコルに関連付けられた8ビット値です。候補パスを提供またはシグナルにするプロトコル/メカニズムを特定し、他のプロトコル/メカニズムに比べてその好みを示すのに役立ちます。
The headend assigns different Protocol-Origin values to each source of SR Policy information. The Protocol-Origin value is used as a tiebreaker between candidate paths of equal Preference, as described in Section 2.9. The table below specifies the RECOMMENDED default values of Protocol-Origin:
HeadEndは、SRポリシー情報の各ソースに異なるプロトコルオリジン値を割り当てます。プロトコルオリジン値は、セクション2.9で説明されているように、同等の好みの候補パス間のタイブレーカーとして使用されます。以下の表は、プロトコルオリジンの推奨デフォルト値を指定します。
+=================+===================+
| Protocol-Origin | Description |
+=================+===================+
| 10 | PCEP |
+-----------------+-------------------+
| 20 | BGP SR Policy |
+-----------------+-------------------+
| 30 | Via Configuration |
+-----------------+-------------------+
Table 1: Protocol-Origin Default Values
表1：プロトコルオリジンのデフォルト値
Note that the above order is to satisfy the need for having a clear ordering, and implementations MAY allow modifications of these default values assigned to protocols on the headend along similar lines as a routing administrative distance. Its application in the candidate path selection is described in Section 2.9.
上記の順序は明確な順序を持つ必要性を満たすことであり、実装により、ルーティング管理距離と同様の回線に沿ってヘッドエンドのプロトコルに割り当てられたこれらのデフォルト値の変更が可能になる場合があります。候補パス選択におけるそのアプリケーションは、セクション2.9で説明されています。
The Originator identifies the node that provisioned or signaled the candidate path on the headend. The Originator is expressed in the form of a 160-bit numerical value formed by the concatenation of the fields of the tuple <Autonomous System Number (ASN), node-address> as below:
オリジネーターは、ヘッドエンドの候補パスをプロビジョニングまたは信号したノードを識別します。オリジネーターは、Tuple <自律システム番号（ASN）、Node-Address>以下のように、Tuple <Autonomous Systems ofのフィールドの連結によって形成される160ビットの数値値の形で表されます。
Autonomous System Number (ASN): represented as a 4-byte number. If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and the high-order bits MUST be set to 0.
自律システム番号（ASN）：4バイト数として表されます。2バイトのASNが使用されている場合、低次の16ビットを使用する必要があり、高次ビットを0に設定する必要があります。
Node Address: represented as a 128-bit value. IPv4 addresses MUST be encoded in the lowest 32 bits, and the high-order bits MUST be set to 0.
ノードアドレス：128ビット値として表されます。IPv4アドレスは、最低32ビットでエンコードする必要があり、高次ビットを0に設定する必要があります。
Its application in the candidate path selection is described in Section 2.9.
候補パス選択におけるそのアプリケーションは、セクション2.9で説明されています。
When provisioning is via configuration, the ASN and node address MAY be set to either the headend or the provisioning controller/node ASN and address. The default value is 0 for both AS and node address.
プロビジョニングが構成を介して行われる場合、ASNおよびノードアドレスをヘッドエンドまたはプロビジョニングコントローラー/ノードASNおよびアドレスのいずれかに設定できます。デフォルト値は、ASとノードアドレスの両方で0です。
When signaling is via PCEP, it is the IPv4 or IPv6 address of the PCE, and the AS number is expected to be set to 0 by default when not available or known.
シグナリングがPCEPを介して行われる場合、それはPCEのIPv4またはIPv6アドレスであり、AS数は、使用できない場合または既知の場合、デフォルトで0に設定されると予想されます。
When signaling is via BGP SR Policy, the ASN and node address are provided by BGP (refer to [BGP-SR-POLICY]) on the headend.
シグナリングがBGP SRポリシーを介して行われる場合、ASNおよびノードアドレスは、ヘッドエンドでBGP（[BGP-SR-Policy]を参照）によって提供されます。
The Discriminator is a 32-bit value associated with a candidate path that uniquely identifies it within the context of an SR Policy from a specific Protocol-Origin as specified below:
判別器は、以下に指定された特定のプロトコルオリジンからSRポリシーのコンテキスト内でそれを一意に識別する候補パスに関連付けられた32ビット値です。
* When provisioning is via configuration, this is a unique identifier for a candidate path; it is specific to the implementation's configuration model. The default value is 0.
* プロビジョニングが構成を介して行われる場合、これは候補パスの一意の識別子です。実装の構成モデルに固有です。デフォルト値は0です。
* When signaling is via PCEP, the method to uniquely signal an individual candidate path along with its Discriminator is described in [PCEP-SR-POLICY-CP]. The default value is 0.
* シグナリングがPCEPを介して行われる場合、その識別器とともに個々の候補パスを一意に信号する方法は、[PCEP-SR-Policy-CP]で説明されています。デフォルト値は0です。
* When signaling is via BGP SR Policy, the BGP process receiving the route provides the distinguisher (refer to [BGP-SR-POLICY]) as the Discriminator. Note that the BGP best path selection is applied before the route is supplied as a candidate path, so only a single candidate path for a given SR Policy will be seen for a given Discriminator.
* シグナリングがBGP SRポリシーを介して行われる場合、ルートを受信するBGPプロセスは、識別子としてdistimutiuser（[BGP-SR-Policy]を参照）を提供します。ルートが候補パスとして供給される前にBGPベストパス選択が適用されるため、特定の判別器には特定のSRポリシーの単一の候補パスのみが見られます。
Its application in the candidate path selection is described in Section 2.9.
候補パス選択におけるそのアプリケーションは、セクション2.9で説明されています。
A candidate path is identified in the context of a single SR Policy.
候補パスは、単一のSRポリシーのコンテキストで特定されます。
A candidate path is not shared across SR Policies.
候補パスは、SRポリシー全体で共有されていません。
A candidate path is not identified by its segment list(s).
候補パスは、そのセグメントリストでは識別されません。
If CP1 is a candidate path of SR Policy Pol1 and CP2 is a candidate path of SR Policy Pol2, then these two candidate paths are independent, even if they happen to have the same segment list. The segment list does not identify a candidate path. The segment list is an attribute of a candidate path.
CP1がSRポリシーPOL1の候補パスであり、CP2がSRポリシーPOL2の候補パスである場合、これら2つの候補パスは、たとえたとえ同じセグメントリストを持っていても独立しています。セグメントリストは、候補パスを識別しません。セグメントリストは、候補パスの属性です。
The identity of a candidate path MUST be uniquely established in the context of an SR Policy <Headend, Color, Endpoint> to handle add, delete, or modify operations on them in an unambiguous manner regardless of their source(s).
候補パスのIDは、SRポリシー<headend、color、endpoint>のコンテキストで一意に確立する必要があります。これは、ソースに関係なく、それらの操作を追加、削除、または変更します。
The tuple <Protocol-Origin, Originator, Discriminator> uniquely identifies a candidate path.
Tuple <Protocol-Origin、Originator、Disfrinator>は、候補パスを一意に識別します。
Candidate paths MAY also be assigned or signaled with a symbolic name comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to serve as a user-friendly attribute for debugging and troubleshooting purposes. Such symbolic names MUST NOT be considered as identifiers for a candidate path. The signaling of the candidate path name via BGP and PCEP is described in [BGP-SR-POLICY] and [PCEP-SR-POLICY-CP], respectively.
候補パスは、印刷可能なASCII [RFC0020]文字（つまり、0x20〜0x7e）で構成されるシンボリック名で割り当てられたり、デバッグおよびトラブルシューティングの目的のためのユーザーフレンドリーな属性として機能したりすることもできます。このような象徴的な名前は、候補パスの識別子と見なされてはなりません。BGPおよびPCEPを介した候補パス名のシグナル伝達は、それぞれ[BGP-Sr-Policy]と[PCEP-SR-Policy-CP]で説明されています。
The Preference of the candidate path is used to select the best candidate path for an SR Policy. It is a 32-bit value where a higher value indicates higher preference and the default Preference value is 100.
候補パスの選好は、SRポリシーに最適な候補パスを選択するために使用されます。これは32ビット値であり、高い値が優先度が高いことを示し、デフォルトの設定値は100です。
It is RECOMMENDED that each candidate path of a given SR Policy has a different Preference.
特定のSRポリシーの各候補パスには異なる好みがあることをお勧めします。
The signaling of the candidate path Preference via BGP and PCEP is described in [BGP-SR-POLICY] and [PCEP-SR-POLICY-CP], respectively.
BGPおよびPCEPを介した候補パス選好のシグナル伝達は、それぞれ[BGP-Sr-Policy]および[PCEP-SR-Policy-CP]で説明されています。
A candidate path is usable when it is valid. The RECOMMENDED candidate path validity criterion is the validity of at least one of its constituent segment lists. The validation rules are specified in Section 5.
候補パスが有効な場合に使用可能です。推奨される候補パスの妥当性基準は、その構成要素セグメントリストの少なくとも1つの有効性です。検証ルールは、セクション5で指定されています。
A candidate path is selected when it is valid and it is determined to be the best path of the SR Policy. The selected path is referred to as the "active path" of the SR Policy in this document.
候補パスが有効であるときに選択され、SRポリシーの最良のパスであると判断されます。選択されたパスは、このドキュメントのSRポリシーの「アクティブパス」と呼ばれます。
Whenever a new path is learned or an active path is deleted, the validity of an existing path changes, or an existing path is changed, the selection process MUST be re-executed.
新しいパスが学習されたり、アクティブパスが削除されたりする場合はいつでも、既存のパスの有効性が変更されるか、既存のパスが変更されます。選択プロセスを再実行する必要があります。
The candidate path selection process operates primarily on the candidate path Preference. A candidate path is selected when it is valid and it has the highest Preference value among all the valid candidate paths of the SR Policy.
候補パス選択プロセスは、主に候補パス選好で動作します。候補パスが有効であるときに選択され、SRポリシーのすべての有効な候補パスの中で最高の優先値があります。
In the case of multiple valid candidate paths of the same Preference, the tie-breaking rules are evaluated on the identification tuple in the following order until only one valid best path is selected:
同じ好みの複数の有効な候補パスの場合、タイブレイクルールは、1つの有効な最良のパスのみが選択されるまで、次の順序で識別タプルで評価されます。
1. The higher value of Protocol-Origin is selected.
1. プロトコルオリジンのより高い値が選択されます。
2. If specified by configuration, prefer the existing installed path.
2. 構成で指定されている場合、既存のインストールされたパスを優先します。
3. The lower value of the Originator is selected.
3. オリジネーターの低い値が選択されます。
4. Finally, the higher value of the Discriminator is selected.
4. 最後に、識別器のより高い値が選択されます。
The rules are framed with multiple protocols and sources in mind and hence may not follow the logic of a single protocol (e.g., BGP best path selection). The motivation behind these rules are as follows:
ルールは、複数のプロトコルとソースを念頭に置いて囲まれているため、単一のプロトコルのロジック（たとえば、BGPベストパス選択）に従うことはできません。これらのルールの背後にある動機は次のとおりです。
* The Preference, being the primary criterion, allows an operator to influence selection across paths thus allowing provisioning of multiple path options, e.g., CP1 is preferred as its Preference value is the highest, and if it becomes invalid, then CP2 with the next highest Preference value is selected, and so on. Since Preference works across protocol sources, it also enables (where necessary) selective override of the default Protocol-Origin preference, e.g., to prefer a path signaled via BGP SR Policy over what is configured.
* 優先度は主要な基準であるため、オペレーターはパス全体の選択に影響を与えることができます。これにより、複数のパスオプションのプロビジョニングが可能になります。値が選択されます。選好はプロトコルソース間で機能するため、（必要に応じて）デフォルトのプロトコルオリジン選好の選択的オーバーライドを可能にします。
* The Protocol-Origin allows an operator to set up a default selection mechanism across protocol sources, e.g., to prefer configured paths over paths signaled via BGP SR Policy or PCEP.
* プロトコルオリジンにより、オペレーターは、プロトコルソース全体でデフォルトの選択メカニズムを設定できます。たとえば、たとえば、BGP SRポリシーまたはPCEPを介して合図されたパスよりも構成されたパスを好むことができます。
* The Originator allows an operator to have multiple redundant controllers and still maintain a deterministic behavior over which of them are preferred even if they are providing the same candidate paths for the same SR policies to the headend.
* オリジネーターは、オペレーターが複数の冗長コントローラーを持つことを許可し、ヘッドエンドに同じSRポリシーの同じ候補パスを提供している場合でも、それらのどちらが優先されるかについての決定論的な動作を維持できます。
* The Discriminator performs the final tie-breaking step to ensure a deterministic outcome of selection regardless of the order in which candidate paths are signaled across multiple transport channels or sessions.
* 判別器は、最終的なタイブレークステップを実行して、複数の輸送チャネルまたはセッションで候補パスが通知される順序に関係なく、選択の決定論的結果を確保します。
[SR-POLICY-CONSID] provides a set of examples to illustrate the active candidate path selection rules.
[SR-Policy-Consid]は、アクティブな候補パス選択ルールを示す一連の例を提供します。
An SR Policy is valid when it has at least one valid candidate path.
SRポリシーは、少なくとも1つの有効な候補パスがある場合に有効です。
Generally, only valid SR policies are instantiated in the forwarding plane.
一般に、有効なSRポリシーのみが転送面にインスタンス化されます。
Only the active candidate path MUST be used for forwarding traffic that is being steered onto that policy except for certain scenarios such as fast reroute where a backup candidate path may be used as described in Section 9.3.
セクション9.3で説明されているように、バックアップ候補パスを使用できる高速再ルートなどの特定のシナリオを除いて、そのポリシーに操縦されているトラフィックを転送するためにアクティブな候補パスのみを使用する必要があります。
If a set of segment lists is associated with the active path of the policy, then the steering is per flow and weighted-ECMP (W-ECMP) based according to the relative weight of each segment list.
セグメントリストのセットがポリシーのアクティブパスに関連付けられている場合、ステアリングは各セグメントリストの相対重量に従ってフローごとに、加重ECMP（W-ECMP）です。
The fraction of the flows associated with a given segment list is w/Sw, where w is the weight of the segment list and Sw is the sum of the weights of the segment lists of the selected path of the SR Policy.
特定のセグメントリストに関連付けられているフローの割合はW/SWであり、Wはセグメントリストの重みであり、SWはSRポリシーの選択されたパスのセグメントリストの重みの合計です。
When a composite candidate path is active, the fraction of flows steered into each constituent SR Policy is equal to the relative weight of each constituent SR Policy. Further load-balancing of flows steered into a constituent SR Policy is performed based on the weights of the segment list of the active candidate path of that constituent SR Policy.
複合候補のパスがアクティブな場合、各構成SRポリシーに操縦されたフローの割合は、各構成SRポリシーの相対重量に等しくなります。構成要素SRポリシーに操縦されたフローのさらなる負荷分散は、その構成要素SRポリシーのアクティブ候補パスのセグメントリストの重みに基づいて実行されます。
The accuracy of the weighted load-balancing depends on the platform implementation.
加重負荷分散の精度は、プラットフォームの実装に依存します。
Upon topological change, many policies could be re-computed or revalidated. An implementation MAY provide a per-policy priority configuration. The operator may set this field to indicate the order in which the policies should be re-computed. Such a priority is represented by an integer in the range (0, 255) where the lowest value is the highest priority. The default value of priority is 128.
トポロジカルな変化により、多くのポリシーが再計算または再確認される可能性があります。実装は、ポリティごとの優先度構成を提供する場合があります。オペレーターは、このフィールドを設定して、ポリシーを再計算する順序を示す場合があります。このような優先順位は、最低値が最も優先度が高い範囲（0、255）の整数によって表されます。優先度のデフォルト値は128です。
An SR Policy may comprise multiple candidate paths received from the same or different sources. A candidate path MAY be signaled with a priority value. When an SR Policy has multiple candidate paths with distinct signaled non-default priority values and the SR Policy itself does not have a priority value configured, the SR Policy as a whole takes the lowest value (i.e., the highest priority) amongst these signaled priority values.
SRポリシーは、同じソースまたは異なるソースから受信した複数の候補パスで構成される場合があります。候補パスは、優先順位の値で信号を受けることができます。SRポリシーに明確なシグナル非デフォルト優先値を持つ複数の候補パスがあり、SRポリシー自体に優先値が構成されていない場合、SRポリシー全体がこれらのシグナル優先度の中で最低値（つまり、最高の優先度）を取得します。値。
In summary, the information model is the following:
要約すると、情報モデルは次のとおりです。
SR Policy POL1 <Headend = H1, Color = 1, Endpoint = E1>
Candidate Path CP1 <Protocol-Origin = 20, Originator =
64511:192.0.2.1, Discriminator = 1>
Preference 200
Priority 10
Segment List 1 <SID11...SID1i>, Weight W1
Segment List 2 <SID21...SID2j>, Weight W2
Candidate Path CP2 <Protocol-Origin = 20, Originator =
64511:192.0.2.2, Discriminator = 2>
Preference 100
Priority 10
Segment List 3 <SID31...SID3i>, Weight W3
Segment List 4 <SID41...SID4j>, Weight W4
The SR Policy POL1 is identified by the tuple <Headend, Color, Endpoint>. It has two candidate paths: CP1 and CP2. Each is identified by a tuple <Protocol-Origin, Originator, Discriminator> within the scope of POL1. CP1 is the active candidate path (it is valid and has the highest Preference). The two segment lists of CP1 are installed as the forwarding instantiation of SR Policy POL1. Traffic steered on POL1 is flow-based hashed on segment list <SID11...SID1i> with a ratio W1/(W1+W2).
SRポリシーPOL1は、tuple <headend、color、endpoint>によって識別されます。CP1とCP2の2つの候補パスがあります。それぞれは、POL1の範囲内で、Tuple <Protocol-Origin、Originator、Disfrinator>によって識別されます。CP1はアクティブな候補パスです（有効であり、最も優先されます）。CP1の2つのセグメントリストは、SRポリシーPOL1の転送インスタンス化としてインストールされます。POL1に操縦されたトラフィックは、F1/（W1 W2）の比率で、セグメントリスト<SID11 ... SID1I>にフローベースのハッシュされています。
The information model of SR Policy POL100 having a composite candidate path is the following:
複合候補パスを持つSRポリシーPOL100の情報モデルは次のとおりです。
SR Policy POL100 <Headend = H1, Color = 100, Endpoint = E1>
Candidate Path CP1 <Protocol-Origin = 20, Originator =
64511:192.0.2.1, Discriminator = 1>
Preference 200
SR Policy <Color = 1>, Weight W1
SR Policy <Color = 2>, Weight W2
The constituent SR Policies POL1 and POL2 have an information model as described at the start of this section. They are referenced only by color in the composite candidate path since their headend and endpoint are identical to the POL100. The valid segment lists of the active candidate path of POL1 and POL2 are installed in the forwarding. Traffic steered on POL100 is hashed on a per-flow basis on POL1 with a proportion W1/(W1+W2). Within the POL1, the flow-based hashing over its segment lists are performed as described earlier in this section.
構成要素SRポリシーPOL1およびPOL2には、このセクションの開始時に説明されているように情報モデルがあります。ヘッドエンドとエンドポイントはPOL100と同一であるため、複合候補パスの色によってのみ参照されます。POL1とPOL2のアクティブな候補パスの有効なセグメントリストは、転送にインストールされています。POL100で操縦されたトラフィックは、W1/（W1 W2）の割合でPOL1の流量ごとにハッシュされます。POL1内で、このセクションで前述のように、そのセグメントリストのフローベースのハッシュは実行されます。
An SR Policy computation node (e.g., headend or controller) maintains the Segment Routing Database (SR-DB). The SR-DB is a conceptual database to illustrate the various pieces of information and their sources that may help in SR Policy computation and validation. There is no specific requirement for an implementation to create a new database as such.
SRポリシー計算ノード（HeadEndやコントローラーなど）は、セグメントルーティングデータベース（SR-DB）を維持します。SR-DBは、SRポリシーの計算と検証に役立つ可能性のあるさまざまな情報とそのソースを説明するための概念データベースです。実装が新しいデータベースを作成するための特定の要件はありません。
An SR headend leverages the SR-DB to validate explicit candidate paths and compute dynamic candidate paths.
SRヘッドエンドはSR-DBを活用して、明示的な候補パスを検証し、動的候補パスを計算します。
The information in the SR-DB may include:
SR-DBの情報には次のものが含まれます。
* IGP information (topology, IGP metrics based on IS-IS [RFC1195] and OSPF [RFC2328] [RFC5340]) * Segment Routing information (such as Segment Routing Global Block, Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP Peering SID, SRv6 SIDs) [RFC8402] [RFC8986] * TE Link Attributes (such as TE metric, Shared Risk Link Groups, attribute-flag, extended admin group) [RFC5305] [RFC3630] [RFC5329] * Extended TE Link attributes (such as latency, loss) [RFC8570] [RFC7471] * Inter-AS Topology information [RFC9086]
* IGP情報（トポロジー、IS-IS [RFC1195]およびOSPF [RFC2328] [RFC5340]） *セグメントルーティング情報（セグメントルーティンググローバルブロック、セグメントローカルブロック、プレフィックスSID、adj-SIDS、bgpピーリングSID、SRV6 SIDS）[RFC8402] [RFC8986] * TEリンク属性（TEメトリック、共有リスクリンクグループ、属性フラグ、拡張管理グループなど）[RFC5305] [RFC3630] [RFC5329] *拡張リンク属性（レイテンシ、損失など）[RFC8570] [RFC7471] *トポロジー情報間[RFC9086]
The attached domain topology may be learned via protocol/mechanisms such as IGP, Border Gateway Protocol - Link State (BGP-LS), or NETCONF.
接続されたドメイントポロジは、IGP、Border Gateway Protocol -Link State（BGP -LS）、またはNetConfなどのプロトコル/メカニズムを介して学習できます。
A non-attached (remote) domain topology may be learned via protocol/ mechanisms such as BGP-LS or NETCONF.
非合計（リモート）ドメイントポロジは、BGP-LやNetConfなどのプロトコル/メカニズムを介して学習できます。
In some use cases, the SR-DB may only contain the attached domain topology while in others, the SR-DB may contain the topology of multiple domains and in this case, it is multi-domain capable.
一部のユースケースでは、SR-DBには接続されたドメイントポロジのみが含まれている場合がありますが、SR-DBには複数のドメインのトポロジーが含まれている場合があり、この場合、マルチドメイン能力があります。
The SR-DB may also contain the SR Policies instantiated in the network. This can be collected via BGP-LS [BGP-LS-TE-POLICY] or PCEP [RFC8231] (along with [PCEP-SR-POLICY-CP] and [PCEP-BSID-LABEL]). This information allows to build an end-to-end policy on the basis of intermediate SR policies (see Section 6 for further details).
SR-DBには、ネットワークにインスタンス化されたSRポリシーも含まれている場合があります。これは、BGP-LS [BGP-LS-TE-Policy]またはPCEP [RFC8231]（[PCEP-SR-Policy-CP]および[PCEP-BSID-Label]とともに）を介して収集できます。この情報により、中間SRポリシーに基づいてエンドツーエンドポリシーを構築できます（詳細については、セクション6を参照）。
The SR-DB may also contain the Maximum SID Depth (MSD) capability of nodes in the topology. This can be collected via IS-IS [RFC8491], OSPF [RFC8476], BGP-LS [RFC8814], or PCEP [RFC8664].
SR-DBには、トポロジ内のノードの最大SID深度（MSD）機能も含まれている場合があります。これは、IS-IS [RFC8491]、OSPF [RFC8476]、BGP-LS [RFC8814]、またはPCEP [RFC8664]を介して収集できます。
The use of the SR-DB for path computation and for the validation of optimization objective and constraints of paths is outside the scope of this document. Some implementation aspects related to path computation are covered in [SR-POLICY-CONSID].
パス計算および最適化の目的とパスの制約の検証にSR-DBを使用することは、このドキュメントの範囲外です。パス計算に関連するいくつかの実装の側面は、[sr-policy-sonsid]でカバーされています。
A segment list is an ordered set of segments represented as <S1, S2, ... Sn> where S1 is the first segment.
セグメントリストは、<s1、s2、... sn>として表されるセグメントの順序付きセットです。ここで、S1は最初のセグメントです。
Based on the desired data plane, either the MPLS label stack or the SRv6 Segment Routing Header [RFC8754] is built from the segment list. However, the segment list itself can be specified using different segment-descriptor types and the following are currently defined:
目的のデータプレーンに基づいて、MPLSラベルスタックまたはSRV6セグメントルーティングヘッダー[RFC8754]がセグメントリストから構築されています。ただし、セグメントリスト自体は、さまざまなセグメント記述型タイプを使用して指定でき、以下は現在定義されています。
Type A: SR-MPLS Label:
An MPLS label corresponding to any of the segment types defined
for SR-MPLS (as defined in [RFC8402] or other SR-MPLS
specifications) can be used. Additionally, special purpose
labels like explicit-null or in general any MPLS label MAY also
be used. For example, this type can be used to specify a label
representation that maps to an optical transport path on a
packet transport node.
Type B: SRv6 SID:
An IPv6 address corresponding to any of the SID behaviors for
SRv6 (as defined in [RFC8986] or other SRv6 specifications) can
be used. Optionally, the SRv6 SID behavior (as defined in
[RFC8986] or other SRv6 specifications) and structure (as
defined in [RFC8986]) MAY also be provided for the headend to
perform validation of the SID when using it for building the
segment list.
Type C: IPv4 Prefix with optional SR Algorithm:
In this case, the headend is required to resolve the specified
IPv4 Prefix Address to the SR-MPLS label corresponding to its
Prefix SID segment (as defined in [RFC8402]). The SR algorithm
(refer to Section 3.1.1 of [RFC8402]) to be used MAY also be
provided.
Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS:
In this case, the headend is required to resolve the specified
IPv6 Global Prefix Address to the SR-MPLS label corresponding
to its Prefix SID segment (as defined in [RFC8402]). The SR
Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY
also be provided.
Type E: IPv4 Prefix with Local Interface ID:
This type allows for identification of an Adjacency SID or BGP
Peer Adjacency SID (as defined in [RFC8402]) SR-MPLS label for
point-to-point links including IP unnumbered links. The
headend is required to resolve the specified IPv4 Prefix
Address to the node originating it and then use the Local
Interface ID to identify the point-to-point link whose
adjacency is being referred to. The Local Interface ID link
descriptor follows semantics as specified in [RFC5307]. This
type can also be used to indicate indirection into a layer 2
interface (i.e., without IP address) like a representation of
an optical transport path or a layer 2 Ethernet port or circuit
at the specified node.
Type F: IPv4 Addresses for link endpoints as Local, Remote pair:
This type allows for identification of an Adjacency SID or BGP
Peer Adjacency SID (as defined in [RFC8402]) SR-MPLS label for
links. The headend is required to resolve the specified IPv4
Local Address to the node originating it and then use the IPv4
Remote Address to identify the link adjacency being referred
to. The Local and Remote Address pair link descriptors follow
semantics as specified in [RFC7752].
Type G: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SR-MPLS:
This type allows for identification of an Adjacency SID or BGP
Peer Adjacency SID (as defined in [RFC8402]) label for links
including those with only Link-Local IPv6 addresses. The
headend is required to resolve the specified IPv6 Prefix
Address to the node originating it and then use the Local
Interface ID to identify the point-to-point link whose
adjacency is being referred to. For other than point-to-point
links, additionally the specific adjacency over the link needs
to be resolved using the Remote Prefix and Interface ID. The
Local and Remote pair of Prefix and Interface ID link
descriptor follows semantics as specified in [RFC7752]. This
type can also be used to indicate indirection into a layer 2
interface (i.e., without IP address) like a representation of
an optical transport path or a layer 2 Ethernet port or circuit
at the specified node.
Type H: IPv6 Addresses for link endpoints as Local, Remote pair
for SR-MPLS:
This type allows for identification of an Adjacency SID or BGP
Peer Adjacency SID (as defined in [RFC8402]) label for links
with Global IPv6 addresses. The headend is required to resolve
the specified Local IPv6 Address to the node originating it and
then use the Remote IPv6 Address to identify the link adjacency
being referred to. The Local and Remote Address pair link
descriptors follow semantics as specified in [RFC7752].
Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6:
The headend is required to resolve the specified IPv6 Global
Prefix Address to an SRv6 SID corresponding to a Prefix SID
segment (as defined in [RFC8402]), such as a SID associated
with the End behavior (as defined in [RFC8986]) of the node
that is originating the prefix. The SR Algorithm (refer to
Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as defined
in [RFC8986] or other SRv6 specifications), and structure (as
defined in [RFC8986]) MAY also be provided.
Type J: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SRv6:
This type allows for identification of an SRv6 SID
corresponding to an Adjacency SID or BGP Peer Adjacency SID (as
defined in [RFC8402]), such as a SID associated with the End.X
behavior (as defined in [RFC8986]) associated with link or
adjacency with only Link-Local IPv6 addresses. The headend is
required to resolve the specified IPv6 Prefix Address to the
node originating it and then use the Local Interface ID to
identify the point-to-point link whose adjacency is being
referred to. For other than point-to-point links, additionally
the specific adjacency needs to be resolved using the Remote
Prefix and Interface ID. The Local and Remote pair of Prefix
and Interface ID link descriptor follows semantics as specified
in [RFC7752]. The SR Algorithm (refer to Section 3.1.1 of
[RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or
other SRv6 specifications), and structure (as defined in
[RFC8986]) MAY also be provided.
Type K: IPv6 Addresses for link endpoints as Local, Remote pair
for SRv6:
This type allows for identification of an SRv6 SID
corresponding to an Adjacency SID or BGP Peer Adjacency SID (as
defined in [RFC8402]), such as a SID associated with the End.X
behavior (as defined in [RFC8986]) associated with link or
adjacency with Global IPv6 addresses. The headend is required
to resolve the specified Local IPv6 Address to the node
originating it and then use the Remote IPv6 Address to identify
the link adjacency being referred to. The Local and Remote
Address pair link descriptors follow semantics as specified in
[RFC7752]. The SR Algorithm (refer to Section 3.1.1 of
[RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or
other SRv6 specifications), and structure (as defined in
[RFC8986]) MAY also be provided.
When the algorithm is not specified for the SID types above which optionally allow for it, the headend SHOULD use the Strict Shortest Path algorithm if available and otherwise, it SHOULD use the default Shortest Path algorithm. The specification of the algorithm enables the use of SIDs specific to the IGP Flex Algorithm [IGP-FLEX-ALGO] in SR Policy.
上記のSIDタイプにアルゴリズムが指定されていない場合、ヘッドエンドは、利用可能な場合は厳密なパスアルゴリズムを使用する必要があります。アルゴリズムの仕様により、SRポリシーでIGP Flexアルゴリズム[IGP-Flex-Algo]に固有のSIDを使用できます。
For SID types C through K, a SID value MAY also be optionally provided to the headend for verification purposes. Section 5.1 describes the resolution and verification of the SIDs and segment lists on the headend.
SIDタイプCからKの場合、検証目的でSID値をヘッドエンドにオプションで提供することもできます。セクション5.1では、ヘッドエンドのSIDSおよびセグメントリストの解像度と検証について説明します。
When building the MPLS label stack or the SRv6 SID list from the segment list, the node instantiating the policy MUST interpret the set of Segments as follows:
セグメントリストからMPLSラベルスタックまたはSRV6 SIDリストを構築する場合、ポリシーをインスタンス化するノードは、セグメントのセットを次のように解釈する必要があります。
* The first Segment represents the topmost MPLS label or the first SRv6 SID. It identifies the active segment the traffic will be directed toward along the explicit SR path. * The last segment represents the bottommost MPLS label or the last SRv6 SID the traffic will be directed toward along the explicit SR path.
* 最初のセグメントは、最上位のMPLSラベルまたは最初のSRV6 SIDを表します。それは、トラフィックが明示的なSRパスに沿って向けられるアクティブセグメントを識別します。*最後のセグメントは、Bottommost MPLSラベルまたは最後のSRV6 SIDを表します。トラフィックは、明示的なSRパスに沿って向けられます。
A Type A SID MAY be any MPLS label, including special purpose labels.
タイプA SIDは、特別な目的ラベルを含む任意のMPLSラベルである場合があります。
For example, assuming that the desired traffic-engineered path from a headend 1 to an endpoint 4 can be expressed by the segment list <16002, 16003, 16004> where 16002, 16003, and 16004, respectively, refer to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6 traffic can be traffic-engineered from nodes 1 to 4 via the previously described path using an SR Policy with segment list <16002, 16003, 16004, 2> where the MPLS label value of 2 represents the "IPv6 Explicit NULL Label".
たとえば、ヘッドエンド1からエンドポイント4への目的のトラフィックエンジニアリングパスは、それぞれ16002、16003、16003、および16004でセグメントリストで表現できます。ノード2、3、および4に、IPv6トラフィックは、セグメントリスト<16002、16003、16004、2>を使用してSRポリシーを使用して、以前に記載されたパスを介してノード1から4からトラフィックエンジニアリングできます。MPLSラベル値は2です。「IPv6明示的なヌルラベル」を表します。
The penultimate node before node 4 will pop 16004 and will forward the frame on its directly connected interface to node 4.
ノード4の前の最後から2番目のノードが16004をポップし、直接接続されたインターフェイスでフレームをノード4に転送します。
The endpoint receives the traffic with the top label "2", which indicates that the payload is an IPv6 packet.
エンドポイントは、トップラベル「2」でトラフィックを受け取ります。これは、ペイロードがIPv6パケットであることを示しています。
When steering unlabeled IPv6 BGP destination traffic using an SR Policy composed of segment list(s) based on IPv4 SIDs, the Explicit Null Label Policy is processed as specified in [BGP-SR-POLICY]. When an "IPv6 Explicit NULL label" is not present as the bottom label, the headend SHOULD automatically impose one. Refer to Section 8 for more details.
IPv4 SIDSに基づいてセグメントリストで構成されるSRポリシーを使用して、無効なIPv6 BGP宛先トラフィックをステアリングすると、明示的なヌルラベルポリシーは[BGP-SR-Policy]で指定されているように処理されます。「IPv6明示的なヌルラベル」がボトムラベルとして存在しない場合、ヘッドエンドは自動的に課す必要があります。詳細については、セクション8を参照してください。
An explicit candidate path is associated with a segment list or a set of segment lists.
明示的な候補パスは、セグメントリストまたはセグメントリストのセットに関連付けられています。
An explicit candidate path is provisioned by the operator directly or via a controller.
明示的な候補パスは、オペレーターによって直接またはコントローラーを介してプロビジョニングされます。
The computation/logic that leads to the choice of the segment list is external to the SR Policy headend. The SR Policy headend does not compute the segment list. The SR Policy headend only confirms its validity.
セグメントリストの選択につながる計算/ロジックは、SRポリシーヘッドエンドの外部です。SRポリシーヘッドエンドはセグメントリストを計算しません。SRポリシーヘッドエンドは、その有効性のみを確認します。
An explicit candidate path MAY consist of a single explicit segment list containing only an implicit-null label to indicate pop-and-forward behavior. The Binding SID (BSID) is popped and the traffic is forwarded based on the inner label or an IP lookup in the case of unlabeled IP packets. Such an explicit path can serve as a fallback or path of last resort for traffic being steered into an SR Policy using its BSID (refer to Section 8.3).
明示的な候補パスは、ポップアンドフォワードの動作を示すための暗黙のヌルラベルのみを含む単一の明示的なセグメントリストで構成されている場合があります。バインディングSID（BSID）がポップされ、トラフィックが内側のラベルまたはIPルックアップに基づいて転送されます。このような明示的なパスは、BSIDを使用してSRポリシーに操縦されるトラフィックのための最後の手段のフォールバックまたはパスとして機能します（セクション8.3を参照）。
A segment list of an explicit candidate path MUST be declared invalid when any of the following is true:
明示的な候補パスのセグメントリストは、以下のいずれかが真である場合、無効と宣言する必要があります。
* It is empty. * Its weight is 0. * It comprises a mix of SR-MPLS and SRv6 segment types. * The headend is unable to perform path resolution for the first SID into one or more outgoing interface(s) and next-hop(s). * The headend is unable to perform SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6 SID. * The headend verification fails for any SID for which verification has been explicitly requested.
* それは空です。*その重量は0です。 * SR-MPLとSRV6セグメントタイプの混合物で構成されています。*ヘッドエンドは、最初のSIDのパス解像度を1つ以上の発信インターフェイスと次のホップに実行できません。*ヘッドエンドは、Kを介してタイプCの非ファーストSIDのSID解像度をMPLSラベルまたはSRV6 SIDに実行することができません。*検証が明示的に要求されたSIDのヘッドエンド検証は失敗します。
"Unable to perform path resolution" means that the headend has no path to the SID in its SR database.
「パス解像度を実行できない」とは、ヘッドエンドにSRデータベースにSIDへのパスがないことを意味します。
SID verification is performed when the headend is explicitly requested to verify SID(s) by the controller via the signaling protocol used. Implementations MAY provide a local configuration option to enable verification on a global or per-policy or per-candidate path basis.
SID検証は、使用されたシグナリングプロトコルを介してコントローラーによってSIDを検証するようヘッドエンドが明示的に要求されたときに実行されます。実装では、グローバルまたはポリティまたはパスごとのパスベースで検証を有効にするためのローカル構成オプションを提供する場合があります。
"Verification fails" for a SID means any of the following:
SIDの「検証が失敗する」は、次のいずれかを意味します。
* The headend is unable to find the SID in its SR-DB * The headend detects a mismatch between the SID value provided and the SID value resolved by context provided for SIDs of type C through K in its SR-DB. * The headend is unable to perform SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6 SID.
* HeadEndは、SR-DB *でSIDを見つけることができません。ヘッドエンドは、提供されたSID値と、SR-DBのタイプCからKのSIDに提供されるコンテキストによって解決されるSID値との間の不一致を検出します。*ヘッドエンドは、Kを介してタイプCの非ファーストSIDのSID解像度をMPLSラベルまたはSRV6 SIDに実行することができません。
In multi-domain deployments, it is expected that the headend may be unable to verify the reachability of the SIDs in remote domains. Types A or B MUST be used for the SIDs for which the reachability cannot be verified. Note that the first SID MUST always be reachable regardless of its type.
マルチドメインの展開では、ヘッドエンドがリモートドメイン内のSIDの到達可能性を検証できない場合があると予想されます。タイプAまたはBは、到達可能性を検証できないSIDに使用する必要があります。最初のSIDは、そのタイプに関係なく常に到達可能でなければならないことに注意してください。
Additionally, a segment list MAY be declared invalid when both of the conditions below are met :
さらに、以下の両方の条件が満たされている場合、セグメントリストは無効であると宣言される場合があります。
* Its last segment is not a Prefix SID (including BGP Peer Node-SID) advertised by the node specified as the endpoint of the corresponding SR Policy. * Its last segment is not an Adjacency SID (including BGP Peer Adjacency SID) of any of the links present on neighbor nodes and that terminate on the node specified as the endpoint of the corresponding SR Policy.
* その最後のセグメントは、対応するSRポリシーのエンドポイントとして指定されたノードによって宣伝されているプレフィックスSID（BGPピアノードSIDを含む）ではありません。*その最後のセグメントは、隣接ノードに存在するリンクのいずれかの隣接SID（BGPピア隣接SIDを含む）ではなく、対応するSRポリシーのエンドポイントとして指定されたノードで終了します。
An explicit candidate path is invalid as soon as it has no valid segment list.
明示的な候補パスは、有効なセグメントリストがないとすぐに無効です。
Additionally, an explicit candidate path MAY be declared invalid when its constituent segment lists (valid or invalid) are using segment types of different SR data planes.
さらに、構成要素セグメントリスト（有効または無効）が異なるSRデータプレーンのセグメントタイプを使用している場合、明示的な候補パスは無効であると宣言される場合があります。
A dynamic candidate path is specified as an optimization objective and a set of constraints.
動的候補パスは、最適化目標と一連の制約として指定されています。
The headend of the policy leverages its SR database to compute a segment list ("solution segment list") that solves this optimization problem for either the SR-MPLS or the SRv6 data plane as specified.
ポリシーのヘッドエンドは、SRデータベース（「ソリューションセグメントリスト」）を計算するためにSRデータベースを活用して、SR-MPLSまたは指定されたSRV6データプレーンのいずれかのこの最適化問題を解決します。
The headend re-computes the solution segment list any time the inputs to the problem change (e.g., topology changes).
HeadEndは、問題の変更への入力がいつでもソリューションセグメントリストを再計算します（トポロジの変更など）。
When the local computation is not possible (e.g., a policy's tail end is outside the topology known to the headend) or not desired, the headend may rely on an external entity. For example, a path computation request may be sent to a PCE supporting PCEP extensions specified in [RFC8664].
ローカル計算が不可能である場合（たとえば、ポリシーのテールエンドがヘッドエンドで知られているトポロジの外側）または望ましくない場合、ヘッドエンドは外部エンティティに依存する場合があります。たとえば、[RFC8664]で指定されたPCEP拡張をサポートするPCEにパス計算要求を送信することができます。
If no solution is found to the optimization objective and constraints, then the dynamic candidate path MUST be declared invalid.
最適化の目的と制約に対する解決策が見つからない場合、動的候補パスは無効であると宣言する必要があります。
[SR-POLICY-CONSID] discusses some of the optimization objectives and constraints that may be considered by a dynamic candidate path. It illustrates some of the desirable properties of the computation of the solution segment list.
[SR-Policy-Consid]動的候補パスによって考慮される可能性のある最適化の目的と制約のいくつかについて説明します。ソリューションセグメントリストの計算の望ましい特性の一部を示しています。
A composite candidate path is specified as a group of its constituent SR Policies.
複合候補パスは、その構成SRポリシーのグループとして指定されています。
A composite candidate path is valid when it has at least one valid constituent SR Policy.
複合候補パスは、少なくとも1つの有効な構成要素SRポリシーがある場合に有効です。
The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. It provides scaling, network opacity, and service independence. [SR-POLICY-CONSID] illustrates some of these benefits. This section describes the association of BSID with an SR Policy.
結合SID（BSID）は、セグメントルーティング[RFC8402]の基本です。スケーリング、ネットワークの不透明度、およびサービスの独立性を提供します。[SR-Policy-Consid]は、これらの利点のいくつかを示しています。このセクションでは、BSIDとSRポリシーとの関連について説明します。
Each candidate path MAY be defined with a BSID.
各候補パスは、BSIDで定義できます。
Candidate paths of the same SR Policy SHOULD have the same BSID.
同じSRポリシーの候補パスには同じBSIDが必要です。
Candidate paths of different SR Policies MUST NOT have the same BSID.
さまざまなSRポリシーの候補パスは、同じbSIDを持たないはずです。
The BSID of an SR Policy is the BSID of its active candidate path.
SRポリシーのBSIDは、アクティブな候補パスのBSIDです。
When the active candidate path has a specified BSID, the SR Policy uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is available. A BSID is available when its value is not associated with any other usage, e.g., a label used by some other MPLS forwarding entry or an SRv6 SID used in some other context (such as to another segment, to another SR Policy, or that it is outside the range of SRv6 Locators).
アクティブな候補パスに指定されたBSIDがある場合、SRポリシーは、この値（MPLSのラベル、SRV6のIPv6アドレス）が利用可能な場合、BSIDを使用します。BSIDは、その値が他の使用法に関連付けられていない場合に利用可能です。たとえば、他のMPLS転送エントリまたは他のコンテキストで使用されるSRV6 SID（別のセグメントなど、別のSRポリシー、またはSRV6ロケーターの範囲外です）。
In the case of SR-MPLS, SRv6 BSIDs (e.g., with the behavior End.BM [RFC8986]) MAY be associated with the SR Policy in addition to the MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g., with different behaviors like End.B6.Encaps and End.B6.Encaps.Red [RFC8986]) MAY be associated with the SR Policy.
SR-MPLSの場合、SRV6 BSID（たとえば、動作が終了します。BM[RFC8986]）は、MPLS BSIDに加えてSRポリシーに関連付けられている可能性があります。SRV6の場合、複数のSRV6 BSID（例：End.B6.EncapsやEnd.B6.Encaps.Red [RFC8986]などの異なる動作がある）がSRポリシーに関連付けられている可能性があります。
Optionally, instead of only checking that the BSID of the active path is available, a headend MAY check that it is available within the given SID range i.e., Segment Routing Local Block (SRLB) as specified in [RFC8402].
オプションでは、アクティブパスのBSIDが利用可能であることのみを確認する代わりに、ヘッドエンドは、[RFC8402]で指定されているように、特定のSID範囲、つまりセグメントローカルブロック（SRLB）内で使用できることを確認できます。
When the specified BSID is not available (optionally is not in the SRLB), an alert message MUST be generated via mechanisms like syslog.
指定されたBSIDが利用できない場合（オプションではSRLBにはありません）、Syslogなどのメカニズムを介してアラートメッセージを生成する必要があります。
In the cases (as described above) where SR Policy does not have a BSID available, the SR Policy MAY dynamically bind a BSID to itself. Dynamically bound BSIDs SHOULD use an available SID outside the SRLB.
SRポリシーにBSIDが利用可能になっていない場合（上記のように）、SRポリシーはBSIDをそれ自体に動的に結合する場合があります。動的に結合したBSIDは、SRLBの外側で利用可能なSIDを使用する必要があります。
Assuming that at time t the BSID of the SR Policy is B1, if at time t+dt a different candidate path becomes active and this new active path does not have a specified BSID or its BSID is specified but is not available (e.g., it is in use by something else), then the SR Policy MAY keep the previous BSID B1.
時点でSRポリシーのBSIDがB1であると仮定すると、時間に別の候補パスがアクティブになり、この新しいアクティブパスには指定されたBSIDがないか、そのBSIDが指定されていませんが、利用できません（例えば、他の何かによって使用されている）、SRポリシーは以前のBSID B1を維持する場合があります。
The association of an SR Policy with a BSID thus MAY change over the life of the SR Policy (e.g., upon active path change). Hence, the BSID SHOULD NOT be used as an identification of an SR Policy.
したがって、SRポリシーとBSIDとの関連は、SRポリシーの存続期間中に変化する可能性があります（たとえば、アクティブパスの変更時）。したがって、BSIDはSRポリシーの識別として使用しないでください。
All the candidate paths of the same SR Policy can have an unspecified BSID.
同じSRポリシーのすべての候補パスには、不特定のBSIDを持つことができます。
In such a case, a BSID MAY be dynamically bound to the SR Policy as soon as the first valid candidate path is received. That BSID is kept through the life of the SR Policy and across changes of the active candidate path.
そのような場合、最初の有効な候補パスが受信されるとすぐに、BSIDがSRポリシーに動的に結合される場合があります。そのBSIDは、SRポリシーの存続期間を通じて、アクティブな候補パスの変更を通じて保持されています。
All the paths of the SR Policy can have the same specified BSID.
SRポリシーのすべてのパスには、同じ指定されたBSIDを持つことができます。
An implementation MAY support the configuration of the Specified-BSID-only restrictive behavior on the headend for all SR Policies or individual SR Policies. Further, this restrictive behavior MAY also be signaled on a per-SR-Policy basis to the headend.
実装は、すべてのSRポリシーまたは個々のSRポリシーのヘッドエンドで指定されたBSIDのみの制限動作の構成をサポートする場合があります。さらに、この制限的な動作は、ヘッドエンドに合わせてSRSRポリティごとに通知される場合があります。
When this restrictive behavior is enabled, if the candidate path has an unspecified BSID or if the specified BSID is not available when the candidate path becomes active, then no BSID is bound to it and the candidate path is considered invalid. An alert MUST be triggered for this error via mechanisms like syslog. Other candidate paths MUST then be evaluated for becoming the active candidate path.
この制限的な動作が有効になっている場合、候補パスに不特定のBSIDがある場合、または候補パスがアクティブになったときに指定されたBSIDが利用できない場合、BSIDはそれに拘束されず、候補パスは無効と見なされます。Syslogのようなメカニズムを介して、このエラーに対してアラートをトリガーする必要があります。その後、アクティブな候補パスになるために他の候補パスを評価する必要があります。
A valid SR Policy results in the installation of a BSID-keyed entry in the forwarding plane with the action of steering the packets matching this entry to the selected path of the SR Policy.
有効なSRポリシーにより、このエントリをSRポリシーの選択したパスに一致させるパケットをステアリングするアクションにより、転送面にBSIDキーのエントリが設置されます。
If the Specified-BSID-only restrictive behavior is enabled and the BSID of the active path is not available (optionally not in the SRLB), then the SR Policy does not install any entry indexed by a BSID in the forwarding plane.
指定されたBSIDのみの制限動作が有効になり、アクティブパスのBSIDが使用できない場合（オプションではSRLBではありません）、SRポリシーは転送面のBSIDによってインデックス付けされたエントリをインストールしません。
An implementation MAY choose to associate a Binding SID with any type of interface (e.g., a layer 3 termination of an Optical Circuit) or a tunnel (e.g., IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE tunnel, etc). This enables the use of other non-SR-enabled interfaces and tunnels as segments in an SR Policy segment list without the need of forming routing protocol adjacencies over them.
実装は、バインディングSIDをあらゆるタイプのインターフェイス（光学回路のレイヤー3終端など）またはトンネル（IPトンネル、GREトンネル、IP/UDPトンネル、MPLS RSVP-TEトンネルなどに関連付けることを選択できます。）。これにより、SRポリシーセグメントリストのセグメントとして、他の非SR対応インターフェイスとトンネルを、ルーティングプロトコルの隣接を形成する必要なく、セグメントとして使用することができます。
The details of this kind of usage are beyond the scope of this document. A specific packet-optical integration use case is described in [POI-SR].
この種の使用の詳細は、このドキュメントの範囲を超えています。特定のパケット光学統合ユースケースは、[POI-SR]で説明されています。
The SR Policy state is maintained on the headend to represent the state of the policy and its candidate paths. This is to provide an accurate representation of whether the SR Policy is being instantiated in the forwarding plane and which of its candidate paths and segment list(s) are active. The SR Policy state MUST also reflect the reason when a policy and/or its candidate path is not active due to validation errors or not being preferred. The operational state information reported for SR Policies are specified in [SR-POLICY-YANG].
SRポリシーの状態は、ポリシーの状態とその候補パスを表すために、ヘッドエンドで維持されています。これは、SRポリシーが転送面にインスタンス化されているかどうか、およびその候補パスとセグメントリストのどれがアクティブであるかを正確に表現するためです。SRポリシーの状態は、検証エラーのためにポリシーおよび/またはその候補パスがアクティブでない場合、または優先されない理由を反映する必要があります。SRポリシーについて報告されている運用状態情報は、[SR-Policy-Yang]で指定されています。
The SR Policy state can be reported by the headend node via BGP-LS [BGP-LS-TE-POLICY] or PCEP [RFC8231] [PCEP-BSID-LABEL].
SRポリシー状態は、BGP-LS [BGP-LS-TE-Policy]またはPCEP [RFC8231] [PCEP-BSID-Label]を介してヘッドエンドノードによって報告できます。
SR Policy state on the headend also includes traffic accounting information for the flows being steered via the policies. The details of the SR Policy accounting are beyond the scope of this document. The aspects related to the SR traffic counters and their usage in the broader context of traffic accounting in an SR network are covered in [SR-TRAFFIC-COUNTERS] and [SR-TRAFFIC-ACCOUNTING], respectively.
ヘッドエンドのSRポリシー状態には、ポリシーを介して操縦されるフローの交通会計情報も含まれています。SRポリシーアカウンティングの詳細は、このドキュメントの範囲を超えています。SRトラフィックカウンターに関連する側面と、SRネットワークでのトラフィック会計のより広範なコンテキストでのその使用法は、それぞれ[SRトラフィックカウンター]と[SRトラフィックカウンティング]でカバーされています。
Implementations MAY support an administrative state to control locally provisioned policies via mechanisms like command-line interface (CLI) or NETCONF.
実装は、コマンドラインインターフェイス（CLI）やNetConfなどのメカニズムを介してローカルでプロビジョニングされたポリシーを制御するための管理状態をサポートする場合があります。
A headend can steer a packet flow into a valid SR Policy in various ways:
ヘッドエンドは、さまざまな方法でパケットフローを有効なSRポリシーに導くことができます。
* Incoming packets have an active SID matching a local BSID at the headend. * Per-Destination Steering: incoming packets match a BGP/Service route, which recurses on an SR Policy. * Per-Flow Steering: incoming packets match or recurse on a forwarding array of which some of the entries are SR Policies. * Policy-Based Steering: incoming packets match a routing policy that directs them on an SR Policy.
* 着信パケットには、ヘッドエンドのローカルBSIDと一致するアクティブなSIDがあります。*設定ごとのステアリング：着信パケットは、SRポリシーで再発するBGP/サービスルートと一致します。*流量あたりのステアリング：着信パケットは、一部のエントリがSRポリシーである転送配列に一致するか再発します。*ポリシーベースのステアリング：着信パケットは、SRポリシーに指示するルーティングポリシーと一致します。
An SR Policy is invalid when all its candidate paths are invalid as described in Sections 2.10 and 5.
セクション2.10および5で説明されているように、すべての候補パスが無効である場合、SRポリシーは無効です。
By default, upon transitioning to the invalid state,
デフォルトでは、無効な状態に移行すると、
* an SR Policy and its BSID are removed from the forwarding plane. * any steering of a service (Pseudowire (PW)), destination (BGP-VPN), flow or packet on the related SR Policy is disabled and the related service, destination, flow, or packet is routed per the classic forwarding table (e.g., longest match to the destination or the recursing next-hop).
* SRポリシーとそのBSIDは、転送面から削除されます。*サービス（PSEUDOWIRE（PW））、宛先（BGP-VPN）、フローまたはパケットのステアリングは、関連するSRポリシーのフローまたはパケットが無効になり、関連サービス、宛先、フロー、またはパケットは、古典的な転送テーブルごとにルーティングされます（例えば、目的地に最も長い一致または再発のネクストホップ）。
An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior. This would entail the following:
SRポリシーは、ドロップアップインバリッドの動作に対して有効になる場合があります。これには、次のことが含まれます。
* an invalid SR Policy and its BSID is kept in the forwarding plane with an action to drop. * any steering of a service (PW), destination (BGP-VPN), flow, or packet on the related SR Policy is maintained with the action to drop all of this traffic.
* 無効なSRポリシーとそのBSIDは、ドロップするアクションで転送面に保持されます。*サービス（PW）、宛先（BGP-VPN）、フロー、または関連するSRポリシーのパケットのステアリングは、このトラフィックをすべてドロップするアクションで維持されます。
The Drop-Upon-Invalid behavior has been deployed in use cases where the operator wants some PW to only be transported on a path with specific constraints. When these constraints are no longer met, the operator wants the PW traffic to be dropped. Specifically, the operator does not want the PW to be routed according to the IGP shortest path to the PW endpoint.
ドロップアップインバリッドの動作は、オペレーターが特定の制約のあるパスでのみPWを輸送することを望んでいるユースケースで展開されています。これらの制約が満たされなくなった場合、オペレーターはPWのトラフィックを削除することを望んでいます。具体的には、オペレーターは、PWエンドポイントへのIGP最短パスに従ってPWをルーティングしたくありません。
Let us assume that headend H has a valid SR Policy P of segment list <S1, S2, S3> and BSID B.
HeadEnd Hには、セグメントリストの有効なSRポリシーPがあると仮定します<S1、S2、S3>およびBSID B
In the case of SR-MPLS, when H receives a packet K with label stack <B, L2, L3>, H pops B and pushes <S1, S2, S3> and forwards the resulting packet according to SID S1.
SR-MPLSの場合、Hがラベルスタック<B、L2、L3>、H POPS Bを使用してパケットKを受信し、<S1、S2、S3>を押し、SID S1に従って結果のパケットを転送します。
"Forwards the resulting packet according to SID S1" means: If S1 is an Adj-SID or a PHP-enabled prefix SID advertised by a neighbor, H sends the resulting packet with label stack <S2, S3, L2, L3> on the outgoing interface associated with S1; Else, H sends the resulting packet with label stack <S1, S2, S3, L2, L3> along the path of S1.
「SID S1によると結果のパケットを転送する」は次のとおりです。S1がADJ-SIDまたは隣人によって宣伝されたPHP対応のプレフィックスSIDである場合、Hは結果のパケットをラベルスタック<S2、S3、L2、L3>で送信します。S1に関連付けられた発信インターフェイス。それ以外の場合、hは、s1の経路に沿って、ラベルスタック<s1、s2、s3、l2、l3>で得られたパケットを送信します。
In the case of SRv6, the processing is similar and follows the SR Policy headend behaviors as specified in Section 5 of [RFC8986].
SRV6の場合、処理は類似しており、[RFC8986]のセクション5で指定されているSRポリシーヘッドエンドの動作に従います。
H has steered the packet into the SR Policy P.
HはパケットをSRポリシーPに導きました。
H did not have to classify the packet. The classification was done by a node upstream of H (e.g., the source of the packet or an intermediate ingress edge node of the SR domain) and the result of this classification was efficiently encoded in the packet header as a BSID.
Hはパケットを分類する必要はありませんでした。分類は、Hの上流のノード（たとえば、パケットのソースまたはSRドメインの中間侵入エッジノード）によって行われ、この分類の結果は、BSIDとしてパケットヘッダーに効率的にエンコードされました。
This is another key benefit of the segment routing in general and the binding SID in particular: the ability to encode a classification and the resulting steering in the packet header to better scale and simplify intermediate aggregation nodes.
これは、一般的なセグメントルーティングのもう1つの重要な利点と、特に結合SID：分類をエンコードする能力と、パケットヘッダーでのステアリングをエンコードする能力と、中間集約ノードをより適切に拡張および簡素化する能力です。
When Drop-Upon-Invalid (refer to Section 8.2) is not in use, for an invalid SR Policy P, its BSID B is not in the forwarding plane and hence, the packet K is dropped by H.
ドロップインバリッド（セクション8.2を参照）が使用されていない場合、無効なSRポリシーPの場合、そのBSID Bは転送面になく、したがってパケットKはHによってドロップされます。
This section describes how a headend applies steering of flows corresponding to BGP routes over SR Policy using the Color Extended community [RFC9012].
このセクションでは、ヘッドエンドがColor Extended Community [RFC9012]を使用してSRポリシーを介したBGPルートに対応するフローのステアリングを適用する方法について説明します。
In the case of SR-MPLS, let us assume that headend H:
SR-MPLSの場合、HeadEnd H：
* learns a BGP route R/r via next-hop N, Color Extended community C, and VPN label V. * has a valid SR Policy P to (color = C, endpoint = N) of segment list <S1, S2, S3> and BSID B. * has a BGP policy that matches on the Color Extended community C and allows its usage as SLA steering information.
* Next-Hop N、Color Extended Community C、およびVPNラベルVを介してBGPルートR/Rを学習します。BSID B. *には、Color Extended Community Cに一致するBGPポリシーがあり、SLAステアリング情報としての使用を可能にします。
If all these conditions are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of BSID B instead of via N.
これらすべての条件が満たされている場合、hはnではなくbsid bの次のhop = srポリシーpを使用してrib/fibにr/rをインストールします。
Indeed, H's local BGP policy and the received BGP route indicate that the headend should associate R/r with an SR Policy path to endpoint N with the SLA associated with color C. The headend, therefore, installs the BGP route on that policy.
実際、HのローカルBGPポリシーと受信したBGPルートは、ヘッドエンドがR/RをSRポリシーパスに関連付けてColor Cに関連付けたSLAに関連付ける必要があることを示しています。したがって、ヘッドエンドはそのポリシーにBGPルートをインストールします。
This can be implemented by using the BSID as a generalized next-hop and installing the BGP route on that generalized next-hop.
これは、BSIDを一般化されたネクストホップとして使用し、その一般化されたネクストホップにBGPルートをインストールすることで実装できます。
When H receives a packet K with a destination matching R/r, H pushes the label stack <S1, S2, S3, V> and sends the resulting packet along the path to S1.
HがR/Rを一致させる宛先を持つパケットKを受信すると、Hはラベルスタック<S1、S2、S3、V>を押し、結果のパケットをS1へのパスに沿って送信します。
Note that any SID associated with the BGP route is inserted after the segment list of the SR Policy (i.e., <S1, S2, S3, V>).
BGPルートに関連付けられたSIDは、SRポリシーのセグメントリスト（つまり、<S1、S2、S3、V>）の後に挿入されることに注意してください。
In the case of SRv6, the processing is similar and follows the SR Policy headend behaviors as specified in Section 5 of [RFC8986].
SRV6の場合、処理は類似しており、[RFC8986]のセクション5で指定されているSRポリシーヘッドエンドの動作に従います。
The same behavior applies to any type of service route: any AFI/SAFI of BGP [RFC4760] or the Locator/ID Separation Protocol (LISP) [RFC6830] for both IPv4/IPv6.
同じ動作は、BGP [RFC4760]のAFI/SAFIまたはIPv4/IPv6の両方のロケーター/ID分離プロトコル（LISP）[RFC6830]のAFI/SAFIのあらゆる種類のサービスルートに適用されます。
In a BGP multi-path scenario, the BGP route MAY be resolved over a mix of paths that include those that are steered over SR Policies and others resolved via the normal BGP next-hop resolution. Implementations MAY provide options to prefer one type over the other or other forms of local policy to determine the paths that are selected.
BGPマルチパスシナリオでは、BGPルートは、SRポリシーや通常のBGP Next-HOP解像度を介して解決されたPATHを含むパスを含むパスの組み合わせで解決できます。実装は、選択されたパスを決定するために、他の形式または他の形式のローカルポリシーよりも1つのタイプを好むオプションを提供する場合があります。
When a BGP route has multiple Color Extended communities each with a valid SR Policy, the BGP process installs the route on the SR Policy giving preference to the Color Extended community with the highest numerical value.
BGPルートにそれぞれが有効なSRポリシーを持つ複数の色の拡張コミュニティがある場合、BGPプロセスはSRポリシーにルートをインストールし、最も高い数値で色拡張コミュニティを優先します。
Let us assume that headend H:
HeadEnd H：
* learns a BGP route R/r via next-hop N, Color Extended communities C1 and C2. * has a valid SR Policy P1 to (color = C1, endpoint = N) of segment list <S1, S2, S3> and BSID B1. * has a valid SR Policy P2 to (color = C2, endpoint = N) of segment list <S4, S5, S6> and BSID B2. * has a BGP policy that matches the Color Extended communities C1 and C2 and allows their usage as SLA steering information
* Next-Hop N、Color Extended Communities C1およびC2を介してBGPルートR/Rを学習します。*セグメントリスト<S1、S2、S3>、およびBSID B1の有効なSRポリシーP1（Color = C1、Endpoint = N）があります。*セグメントリスト<S4、S5、S6>、およびBSID B2の有効なSRポリシーP2から（Color = C2、Endpoint = N）があります。* Color Extended Communities C1とC2に一致するBGPポリシーがあり、SLAステアリング情報としての使用を許可します
If all these conditions are met, H installs R/r in RIB/FIB with next-hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1.
これらすべての条件が満たされている場合、hはr/rをrib/fibにインストールしますrib/fibは、c2> c1であるため、bsid = b2（nの代わりに）のbsid = b2のsrポリシーp2を使用します。
When the SR Policy with a specific color is not instantiated or in the down/inactive state, the SR Policy with the next highest numerical value of color is considered.
特定の色のSRポリシーがインスタンス化されていない場合、またはダウン/非アクティブ状態にない場合、色の次の最高数値を持つSRポリシーが考慮されます。
In the previous section, it was assumed that H had a pre-established "explicit" SR Policy (color C, endpoint N).
前のセクションでは、Hが事前に確立された「明示的な」SRポリシー（Color C、Endpoint N）があると想定されていました。
In this section, independent of the a priori existence of any explicit candidate path of the SR Policy (C, N), it is to be noted that the BGP process at headend node H triggers the instantiation of a dynamic candidate path for the SR Policy (C, N) as soon as:
このセクションでは、SRポリシー（C、N）の明示的な候補パスの先験的存在とは無関係に、HeadEndノードHのBGPプロセスは、SRポリシーの動的候補パスのインスタンス化をトリガーすることに注意してください。（c、n）すぐに：
* the BGP process learns of a route R/r via N and with Color Extended community C. * a local policy at node H authorizes the on-demand SR Policy path instantiation and maps the color to a dynamic SR Policy path optimization template.
* BGPプロセスは、Nを介したルートR/Rと色の拡張コミュニティCを学習します。 * Node Hのローカルポリシーは、オンデマンドSRポリシーパスのインスタンス化を許可し、色を動的SRポリシーパス最適化テンプレートにマッピングします。
When a BGP route R/r via N has multiple Color Extended communities Ci (with i=1 ... n), an individual on-demand SR Policy dynamic path request (color Ci, endpoint N) is triggered for each color Ci. The SR Policy that is used for steering is then determined as described in Section 8.4.1.
N経由のBGPルートR/Rに複数の色の拡張コミュニティCI（i = 1 ... nで）がある場合、個々のオンデマンドSRポリシーダイナミックパス要求（色CI、エンドポイントN）が各色CIに対してトリガーされます。ステアリングに使用されるSRポリシーは、セクション8.4.1で説明されているように決定されます。
This section provides an example of how a headend might apply per-flow steering in practice.
このセクションでは、ヘッドエンドが実際にフローごとのステアリングを適用する方法の例を示します。
Let us assume that headend H:
HeadEnd H：
* has a valid SR Policy P1 to (color = C1, endpoint = N) of segment list <S1, S2, S3> and BSID B1. * has a valid SR Policy P2 to (color = C2, endpoint = N) of segment list <S4, S5, S6> and BSID B2. * is configured to instantiate an array of paths to N where the entry 0 is the IGP path to N, color C1 is the first entry, and color C2 is the second entry. The index into the array is called a Forwarding Class (FC). The index can have values 0 to 7, especially when derived from the MPLS TC bits [RFC5462]. * is configured to match flows in its ingress interfaces (upon any field such as Ethernet destination/source/VLAN/TOS or IP destination/source/Differentiated Services Code Point (DSCP), or transport ports etc.), and color them with an internal per-packet forwarding-class variable (0, 1, or 2 in this example).
* セグメントリスト<S1、S2、S3>、およびBSID B1の有効なSRポリシーP1（Color = C1、Endpoint = N）があります。*セグメントリスト<S4、S5、S6>、およびBSID B2の有効なSRポリシーP2から（Color = C2、Endpoint = N）があります。* nへのパスの配列をインスタンス化するように構成されています。ここで、エントリ0はnへのIGPパス、色C1は最初のエントリ、カラーC2は2番目のエントリです。配列へのインデックスは、転送クラス（FC）と呼ばれます。特にMPLS TCビット[RFC5462]から導出された場合、インデックスは値0〜7を持つことができます。*インターフェイスのフローを一致させるように構成されています（イーサネットの宛先/VLAN/TOSまたはIP宛先/ソース/差別化されたサービスコードポイント（DSCP）、または輸送ポートなどのフィールドに）、それらを色で色付けします。パケットごとの転送クラス変数（この例では0、1、または2）。
If all these conditions are met, H installs in RIB/FIB:
これらすべての条件が満たされている場合、hはrib/fibにインストールします。
* N via recursion on an array A (instead of the immediate outgoing link associated with the IGP shortest path to N). * Entry A(0) set to the immediate outgoing link of the IGP shortest path to N. * Entry A(1) set to SR Policy P1 of BSID=B1. * Entry A(2) set to SR Policy P2 of BSID=B2.
* nアレイa（nへの最短パスに関連付けられた即時発信リンクの代わりに）アレイAの再帰を介して。* Entry A（0）は、IGPの最短パスへの即時発信リンクに設定されています。*エントリA（2）BSID = B2のSRポリシーP2に設定。
H receives three packets K, K1, and K2 on its incoming interface. These three packets either longest match on N or more likely on a BGP/service route that recurses on N. H colors these 3 packets respectively with forwarding-class 0, 1, and 2.
Hは、その着信インターフェイスで3つのパケットK、K1、およびK2を受け取ります。これらの3つのパケットは、NでNで最も長い一致するか、N.Hで再発するBGP/サービスルートでの可能性が高くなります。
As a result, for SR-MPLS:
その結果、sr-mplsの場合：
* H forwards K along the shortest path to N (i.e., pushes the Prefix-SID of N). * H pushes <S1, S2, S3> on packet K1 and forwards the resulting frame along the shortest path to S1. * H pushes <S4, S5, S6> on packet K2 and forwards the resulting frame along the shortest path to S4.
* hは、nへの最短経路に沿ってkを前方に進めます（つまり、nのプレフィックスシドを押します）。* hパケットK1で<S1、S2、S3>を押し、結果のフレームをS1への最短経路に沿って転送します。* hパケットK2で<S4、S5、S6>を押し、結果のフレームをS4への最短経路に沿って転送します。
For SRv6, the processing is similar and the segment lists of the individual SR Policies P1 and P2 are enforced for packets K1 and K2 using the SR Policy headend behaviors as specified in Section 5 of [RFC8986].
SRV6の場合、処理は類似しており、個々のSRポリシーP1およびP2のセグメントリストは、[RFC8986]のセクション5で指定されているSRポリシーヘッドエンドの動作を使用して、パケットK1およびK2に施行されます。
If the local configuration does not specify any explicit forwarding information for an entry of the array, then this entry is filled with the same information as entry 0 (i.e., the IGP shortest path).
ローカル構成が配列のエントリの明示的な転送情報を指定していない場合、このエントリはエントリ0（つまり、IGP最短パス）と同じ情報で満たされます。
If the SR Policy mapped to an entry of the array becomes invalid, then this entry is filled with the same information as entry 0. When all the array entries have the same information as entry 0, the forwarding entry for N is updated to bypass the array and point directly to its outgoing interface and next-hop.
配列のエントリにマッピングされたSRポリシーが無効になった場合、このエントリはエントリ0と同じ情報で満たされています。すべての配列エントリがエントリ0と同じ情報を持っている場合、nの転送エントリが更新され、配列とポイントは、その発信インターフェイスと次のホップを直接指します。
The array index values (e.g., 0, 1, and 2) and the notion of forwarding class are implementation specific and only meant to describe the desired behavior. The same can be realized by other mechanisms.
配列インデックス値（0、1、および2など）と転送クラスの概念は、実装固有であり、望ましい動作を記述することのみを意図しています。同じことが他のメカニズムによって実現できます。
This realizes per-flow steering: different flows bound to the same BGP endpoint are steered on different IGP or SR Policy paths.
これにより、流量あたりのステアリングが実現します。同じBGPエンドポイントにバインドされた異なるフローは、異なるIGPまたはSRポリシーパスに操縦されます。
A headend MAY support options to apply per-flow steering only for traffic matching specific prefixes (e.g., specific IGP or BGP prefixes).
ヘッドエンドは、特定のプレフィックス（特定のIGPまたはBGPプレフィックスなど）に一致するトラフィックにのみフローごとのステアリングを適用するオプションをサポートできます。
Finally, headend H MAY be configured with a local routing policy that overrides any BGP/IGP path and steers a specified packet on an SR Policy. This includes the use of mechanisms like IGP Shortcut for automatic routing of IGP prefixes over SR Policies intended for such purpose.
最後に、HeadEnd Hは、BGP/IGPパスをオーバーライドし、SRポリシーに指定されたパケットを操縦するローカルルーティングポリシーで構成される場合があります。これには、そのような目的のために意図されたSRポリシーを介したIGPプレフィックスの自動ルーティングのためのIGPショートカットなどのメカニズムの使用が含まれます。
In the previous section, it is seen that the steering on an SR Policy is governed by the matching of the BGP route's next-hop N and the authorized Color Extended community C with an SR Policy defined by the tuple (N, C).
前のセクションでは、SRポリシーのステアリングは、BGPルートのNext-Hop Nと、Tuple（N、C）によって定義されたSRポリシーを備えた承認されたカラー拡張コミュニティCのマッチングによって支配されていることがわかります。
This is the most likely form of BGP destination steering and the one recommended for most use cases.
これは、BGP宛先ステアリングの最も可能性の高い形式であり、ほとんどのユースケースに推奨されるものです。
This section defines an alternative steering mechanism based only on the Color Extended community.
このセクションでは、色の拡張コミュニティのみに基づいた代替ステアリングメカニズムを定義します。
Three types of steering modes are defined.
3種類のステアリングモードが定義されています。
For the default, Type 0, the BGP destination is steered as follows:
デフォルトのタイプ0の場合、BGP宛先は次のように操縦されます。
IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6
endpoint address and C is a color;
Steer into SR Policy (N, C);
ELSE;
Steer on the IGP path to the next-hop N.
This is the classic case described in this document previously and what is recommended in most scenarios.
これは、以前にこのドキュメントで説明されている古典的なケースであり、ほとんどのシナリオで推奨されているものです。
For Type 1, the BGP destination is steered as follows:
タイプ1の場合、BGP宛先は次のように操縦されます。
IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6
endpoint address and C is a color;
Steer into SR Policy (N, C);
ELSE IF there is a valid SR Policy (null endpoint, C) of the
same address-family of N;
Steer into SR Policy (null endpoint, C);
ELSE IF there is any valid SR Policy
(any address-family null endpoint, C);
Steer into SR Policy (any null endpoint, C);
ELSE;
Steer on the IGP path to the next-hop N.
For Type 2, the BGP destination is steered as follows:
タイプ2の場合、BGPの宛先は次のように操縦されます。
IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6
endpoint address and C is a color;
Steer into SR Policy (N, C);
ELSE IF there is a valid SR Policy (null endpoint, C)
of the same address-family of N;
Steer into SR Policy (null endpoint, C);
ELSE IF there is any valid SR Policy
(any address-family null endpoint, C);
Steer into SR Policy (any null endpoint, C);
ELSE IF there is any valid SR Policy (any endpoint, C)
of the same address-family of N;
Steer into SR Policy (any endpoint, C);
ELSE IF there is any valid SR Policy
(any address-family endpoint, C);
Steer into SR Policy (any address-family endpoint, C);
ELSE;
Steer on the IGP path to the next-hop N.
The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set to the 0 value).
nullエンドポイントは、IPv4の場合は0.0.0.0および:: IPv6の場合（すべてのビットが0値に設定されています）。
Please refer to [BGP-SR-POLICY] for the updates to the BGP Color Extended community for the implementation of these mechanisms.
これらのメカニズムの実装については、BGPカラー拡張コミュニティの更新については、[BGP-SR-Policy]を参照してください。
The steering preference is first based on the highest Color Extended community value and then Color-Only steering type for the color. Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1>C2. The steering preference order is:
ステアリングの好みは、最初に最も高い色の拡張コミュニティの価値に基づいており、次に色の色のみのステアリングタイプに基づいています。（nh、c1（co = 01）、c2（co = 01））via（nh、c1（co = 01））を想定しています。C1> C2。ステアリングの好みの順序は次のとおりです。
* SR Policy (NH, C1). * SR Policy (null, C1). * SR Policy (NH, C2). * SR Policy (null, C2). * IGP to NH.
* SRポリシー（NH、C1）。* SRポリシー（NULL、C1）。* SRポリシー（NH、C2）。* SRポリシー（NULL、C2）。* NHへのIGP。
This document defined earlier that when all the following conditions are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of BSID B instead of via N.
このドキュメントは、次のすべての条件が満たされた場合、hがnではなくbsid bのbsid bのrib/fib = srポリシーpを使用してr/rをリブ/fibにインストールすることを先に定義しました。
* H learns a BGP route R/r via next-hop N, Color Extended community C. * H has a valid SR Policy P to (color = C, endpoint = N) of segment list <S1, S2, S3> and BSID B. * H has a BGP policy that matches the Color Extended community C and allows its usage as SLA steering information.
* hは、ネクストホップn、色拡張コミュニティCを介してBGPルートR/Rを学習します。。 * Hには、Color Extended Community Cに一致するBGPポリシーがあり、SLAステアリング情報としての使用を可能にします。
This behavior is extended by noting that the BGP Policy may require the BGP steering to always stay on the SR Policy whatever its validity.
この動作は、BGPポリシーでは、BGPステアリングがその有効性に関係なく常にSRポリシーにとどまることを要求する場合があることに留意することにより拡張されます。
This is the "drop-upon-invalid" option described in Section 8.2 applied to BGP-based steering.
これは、BGPベースのステアリングに適用されるセクション8.2で説明されている「ドロップアップインバリッド」オプションです。
In any topology, Topology-Independent Loop-Free Alternate (TI-LFA) [SR-TI-LFA] provides a 50 msec local protection technique for IGP SIDs. The backup path is computed on a per-IGP-SID basis along the post-convergence path.
どのトポロジーでも、トポロジに依存しないループフリーの代替（TI-LFA）[SR-TI-LFA]は、IGP SIDSに50ミリ秒のローカル保護技術を提供します。バックアップパスは、コンバージェンス後のパスに沿ってIGPごとのSIDベースで計算されます。
In a network that has deployed TI-LFA, an SR Policy built on the basis of TI-LFA protected IGP segments leverages the local protection of the constituent segments. Since TI-LFA protection is based on IGP computation, there are cases where the path used during the fast-reroute time window may not meet the exact constraints of the SR Policy.
TI-LFAを展開したネットワークでは、TI-LFA保護されたIGPセグメントに基づいて構築されたSRポリシーが、構成要素セグメントの局所保護を活用します。TI-LFA保護はIGP計算に基づいているため、高速リアウトタイムウィンドウで使用されるパスがSRポリシーの正確な制約を満たしていない場合があります。
In a network that has deployed TI-LFA, an SR Policy instantiated only with non-protected Adj SIDs does not benefit from any local protection.
TI-LFAを展開したネットワークでは、保護されていないadj SIDSのみでのみインスタンス化されたSRポリシーは、現地の保護の恩恵を受けません。
1----2-----6----7
| | | |
4----3-----9----8
Figure 1: Local Protection Using SR Policy
図1：SRポリシーを使用したローカル保護
An SR Policy can be instantiated at node 2 to protect link 2-to-6. A typical explicit segment list would be <3, 9, 6>.
SRポリシーは、リンク2から6を保護するために、ノード2でインスタンス化できます。典型的な明示的なセグメントリストは<3、9、6>です。
A typical use case occurs for links outside an IGP domain: e.g., 1, 2, 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are part of IGP/SR sub-domain 2. In such a case, links 2-to-6 and 3to9 cannot benefit from TI-LFA automated local protection. The SR Policy with segment list <3, 9, 6> on node 2 can be locally configured to be a fast-reroute backup path for the link 2-to-6.
IGPドメイン外のリンクに対して典型的なユースケースが発生します。たとえば、1、2、3、および4はIGP/SRサブドメイン1の一部であり、6、7、8、および9はIGP/SRサブドメインの一部です2.そのような場合、リンク2対6および3to9は、TI-LFA自動局所保護の恩恵を受けることはできません。ノード2のセグメントリスト<3、9、6>を備えたSRポリシーは、リンク2〜6の高速リアウトバックアップパスとしてローカルに構成できます。
An SR Policy allows for multiple candidate paths, of which at any point in time there is a single active candidate path that is provisioned in the forwarding plane and used for traffic steering. However, another (lower preference) candidate path MAY be designated as the backup for a specific or all (active) candidate path(s). The following options are possible:
SRポリシーでは、複数の候補パスが可能になります。このパスは、任意の時点で、転送面にプロビジョニングされ、トラフィックステアリングに使用される単一のアクティブな候補パスがあります。ただし、別の（より低い優先度）候補パスは、特定またはすべての（アクティブな）候補パスのバックアップとして指定される場合があります。次のオプションが可能です。
* A pair of disjoint candidate paths are provisioned with one of them as primary and the other identified as its backup. * A specific candidate path is provisioned as the backup for any (active) candidate path. * The headend picks the next (lower) preference valid candidate path as the backup for the active candidate path.
* 一対のばらばらの候補パスは、そのうちの1つがプライマリとしてプロビジョニングされ、もう1つはバックアップとして識別されます。*特定の候補パスは、（アクティブな）候補パスのバックアップとしてプロビジョニングされます。*ヘッドエンドは、アクティブな候補パスのバックアップとして、次の（低い）優先候補の有効な候補パスを選択します。
The headend MAY compute a priori and validate such backup candidate paths as well as provision them into the forwarding plane as a backup for the active path. The backup candidate path may be dynamically computed or explicitly provisioned in such a way that they provide the most appropriate alternative for the active candidate path. A fast-reroute mechanism MAY then be used to trigger sub-50 msec switchover from the active to the backup candidate path in the forwarding plane. Mechanisms like Bidirectional Forwarding Detection (BFD) MAY be used for fast detection of such failures.
ヘッドエンドは、アプリオリを計算し、そのようなバックアップ候補パスを検証し、アクティブパスのバックアップとして転送面にプロビジョニングする場合があります。バックアップ候補パスは、アクティブな候補パスに最も適切な代替品を提供するように、動的に計算または明示的にプロビジョニングされる場合があります。その後、高速レルートメカニズムを使用して、下向き面のアクティブな候補パスからバックアップ候補のパスへのサブ50ミリ秒のスイッチオーバーをトリガーできます。双方向転送検出（BFD）などのメカニズムは、そのような障害の迅速な検出に使用される場合があります。
This document specifies in detail the SR Policy construct introduced in [RFC8402] and its instantiation on a router supporting SR along with descriptions of mechanisms for the steering of traffic flows over it. Therefore, the security considerations of [RFC8402] apply. The security consideration related to SR-MPLS [RFC8660] and SRv6 [RFC8754] [RFC8986] also apply.
このドキュメントは、[RFC8402]で導入されたSRポリシーコンストラクトと、SRをサポートするルーターでのインスタンス化と、それを越えてトラフィックの操縦のメカニズムの説明を詳細に指定しています。したがって、[RFC8402]のセキュリティ上の考慮事項が適用されます。SR-MPLS [RFC8660]およびSRV6 [RFC8754] [RFC8986]に関連するセキュリティの考慮事項も適用されます。
The endpoint of the SR Policy, other than in the case of a null endpoint, uniquely identifies the tail-end node of the segment routed path. If an address that is used as an endpoint for an SR Policy is advertised by more than one node due to a misconfiguration or spoofing and the same is advertised via an IGP, the traffic steered over the SR Policy may end up getting diverted to an undesired node resulting in misrouting. Mechanisms for detection of duplicate prefix advertisement can be used to identify and correct such scenarios. The details of these mechanisms are outside the scope of this document.
NULLエンドポイントの場合を除き、SRポリシーのエンドポイントは、セグメントルーティングパスのテールエンドノードを一意に識別します。SRポリシーのエンドポイントとして使用されるアドレスが、誤解またはスプーフィングのために複数のノードによって宣伝され、IGPを介して同じものが宣伝されている場合、SRポリシーを介して操縦されたトラフィックが最終的に迂回される可能性があります誤ったルーティングをもたらすノード。重複するプレフィックス広告を検出するためのメカニズムを使用して、そのようなシナリオを識別して修正できます。これらのメカニズムの詳細は、このドキュメントの範囲外です。
Section 8 specifies mechanisms for the steering of traffic flows corresponding to BGP routes over SR Policies matching the color value signaled via the BGP Color Extended Community attached with the BGP routes. Misconfiguration or error in setting of the Color Extended Community with the BGP routes can result in the forwarding of packets for those routes along undesired paths.
セクション8では、BGPルートに付属しているBGPカラー拡張コミュニティを介してシグナル化された色の値に一致するSRポリシーに対応するBGPルートに対応するトラフィックフローのステアリングのメカニズムを指定します。BGPルートを使用した色の拡張コミュニティの設定における誤解またはエラーは、望ましくないパスに沿ってそれらのルートのパケットを転送する可能性があります。
In Sections 2.1 and 2.6, the document mentions that a symbolic name MAY be signaled along with a candidate path for the SR Policy and for the SR Policy Candidate Path, respectively. While the value of symbolic names for display clarity is indisputable, as with any unrestricted free-form text received from external parties, there can be no absolute assurance that the information the text purports to show is accurate or even truthful. For this reason, users of implementations that display such information would be well advised not to rely on it without question and to use the specific identifiers of the SR Policy and SR Policy Candidate Path for validation. Furthermore, implementations that display such information might wish to display it in such a fashion as to differentiate it from known-good information. (Such display conventions are inherently implementation specific; one example might be use of a distinguished text color or style for information that should be treated with caution.)
セクション2.1および2.6では、文書は、SRポリシーおよびSRポリシー候補パスの候補パスとともに、象徴的な名前がそれぞれ合図される可能性があることを述べています。ディスプレイの明確さのための象徴的な名前の価値は議論の余地がありませんが、外部の当事者から受け取った無制限のフリーフォームテキストと同様に、テキストが表示する情報が正確または真実でさえあるという絶対的な保証はありません。このため、そのような情報を表示する実装のユーザーは、疑いもなく頼らず、検証のためにSRポリシーとSRポリシー候補のパスの特定の識別子を使用することをお勧めします。さらに、そのような情報を表示する実装は、既知の情報と区別するような方法で表示したい場合があります。 （このようなディスプレイの規則は本質的に実装固有です。一例として、慎重に扱うべき情報のために著名なテキストの色またはスタイルを使用することです。）
This document does not define any new protocol extensions and does not introduce any further security considerations.
このドキュメントは、新しいプロトコル拡張機能を定義せず、さらなるセキュリティ上の考慮事項を導入しません。
This document specifies in detail the SR Policy construct introduced in [RFC8402] and its instantiation on a router supporting SR along with descriptions of mechanisms for the steering of traffic flows over it. Therefore, the manageability considerations of [RFC8402] apply.
このドキュメントは、[RFC8402]で導入されたSRポリシーコンストラクトと、SRをサポートするルーターでのインスタンス化と、それを越えてトラフィックの操縦のメカニズムの説明を詳細に指定しています。したがって、[RFC8402]の管理可能性の考慮事項が適用されます。
A YANG model for the configuration and operation of SR Policy has been defined in [SR-POLICY-YANG].
SRポリシーの構成と動作のためのYangモデルは、[SR-Policy-Yang]で定義されています。
IANA has created a new subregistry called "Segment Types" under the "Segment Routing" registry that was created by [RFC8986]. This subregistry maintains the alphabetic identifiers for the segment types (as specified in Section 4) that may be used within a segment list of an SR Policy. The alphabetical identifiers run from A to Z and may be extended on exhaustion with the identifiers AA to AZ, BA to BZ, and so on, through ZZ. This subregistry follows the Specification Required allocation policy as specified in [RFC8126].
IANAは、[RFC8986]によって作成された「セグメントルーティング」レジストリの下に「セグメントタイプ」と呼ばれる新しいサブレジストリを作成しました。このサブレジストリは、SRポリシーのセグメントリスト内で使用できるセグメントタイプ（セクション4で指定）のアルファベット識別子を維持しています。アルファベット識別子はAからZまで実行され、ZZを介して識別子AAからAZ、BAからBZなど、識別子AAからBAなどを使用して疲労して拡張できます。このサブレジストリは、[RFC8126]で指定されているように、必要な割り当てポリシーの仕様に従います。
The initial registrations for this subregistry are as follows:
このサブレジストリの最初の登録は次のとおりです。
+=======+=============================================+===========+
| Value | Description | Reference |
+=======+=============================================+===========+
| A | SR-MPLS Label | RFC 9256 |
+-------+---------------------------------------------+-----------+
| B | SRv6 SID | RFC 9256 |
+-------+---------------------------------------------+-----------+
| C | IPv4 Prefix with optional SR Algorithm | RFC 9256 |
+-------+---------------------------------------------+-----------+
| D | IPv6 Global Prefix with optional SR | RFC 9256 |
| | Algorithm for SR-MPLS | |
+-------+---------------------------------------------+-----------+
| E | IPv4 Prefix with Local Interface ID | RFC 9256 |
+-------+---------------------------------------------+-----------+
| F | IPv4 Addresses for link endpoints as Local, | RFC 9256 |
| | Remote pair | |
+-------+---------------------------------------------+-----------+
| G | IPv6 Prefix and Interface ID for link | RFC 9256 |
| | endpoints as Local, Remote pair for SR-MPLS | |
+-------+---------------------------------------------+-----------+
| H | IPv6 Addresses for link endpoints as Local, | RFC 9256 |
| | Remote pair for SR-MPLS | |
+-------+---------------------------------------------+-----------+
| I | IPv6 Global Prefix with optional SR | RFC 9256 |
| | Algorithm for SRv6 | |
+-------+---------------------------------------------+-----------+
| J | IPv6 Prefix and Interface ID for link | RFC 9256 |
| | endpoints as Local, Remote pair for SRv6 | |
+-------+---------------------------------------------+-----------+
| K | IPv6 Addresses for link endpoints as Local, | RFC 9256 |
| | Remote pair for SRv6 | |
+-------+---------------------------------------------+-----------+
Table 2: Segment Types
表2：セグメントタイプ
The Designated Expert (DE) is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and to verify that the document is permanently and publicly available. The DE is also expected to check the clarity of purpose and use of the requested assignment. Additionally, the DE must verify that any request for one of these assignments has been made available for review and comment within the IETF: the DE will post the request to the SPRING Working Group mailing list (or a successor mailing list designated by the IESG). If the request comes from within the IETF, it should be documented in an Internet-Draft. Lastly, the DE must ensure that any other request for a code point does not conflict with work that is active or already published within the IETF.
指定された専門家（DE）は、[RFC8126]に記載されている適切なドキュメント（仕様）の存在を確認し、ドキュメントが永続的かつ公開されていることを確認することが期待されます。DEは、要求された割り当ての目的と使用の明確さを確認することも期待されています。さらに、DEは、これらの割り当てのいずれかのリクエストがIETF内でレビューとコメントのために利用可能になったことを確認する必要があります。DEは、スプリングワーキンググループメーリングリスト（またはIESGによって指定された後継メーリングリスト）にリクエストを投稿します。。リクエストがIETF内から来る場合、インターネットドラフトで文書化する必要があります。最後に、DEは、コードポイントの他の要求が、IETF内でアクティブまたはすでに公開されている作業と競合しないことを確認する必要があります。
[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>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A。、およびS. Ray、「BGPを使用したリンク状態および交通工学の北行き分布（TE）情報」、RFC 7752、DOI 10.17487/RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
[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] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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.、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[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.、Ed。、Filsfils、C.、Ed。、Previdi、S.、Decraene、B.、Litkowski、S.、およびR. Shakir、「MPLSデータプレーンとのセグメントルーティング」、RFC8660、doi 10.17487/rfc8660、2019年12月、<https://www.rfc-editor.org/info/rfc8660>。
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.
[RFC8754] Filsfils、C.、Ed。、Dukes、D.、Ed。、Previdi、S.、Leddy、J.、Matsushima、S.、およびD. Voyer、「IPv6セグメントルーティングヘッダー（SRH）」、RFC8754、doi 10.17487/rfc8754、2020年3月、<https://www.rfc-editor.org/info/rfc8754>。
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.
[RFC8986] Filsfils、C.、Ed。、Camarillo、P.、Ed。、Leddy、J.、Voyer、D.、Matsushima、S.、およびZ. Li、「IPv6（SRV6）ネットワークプログラミングを介したセグメントルーティング」、RFC 8986、DOI 10.17487/RFC8986、2021年2月、<https://www.rfc-editor.org/info/rfc8986>。
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, <https://www.rfc-editor.org/info/rfc9012>.
[RFC9012] Patel、K.、Van de Velde、G.、Sangli、S。、およびJ. Scudder、「BGPトンネルカプセル化属性」、RFC 9012、DOI 10.17487/RFC9012、2021年4月、<https：//.rfc-editor.org/info/rfc9012>。
[BGP-LS-TE-POLICY] Previdi, S., Talaulikar, K., Ed., Dong, J., Ed., Chen, M., Gredler, H., and J. Tantsura, "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS", Work in Progress, Internet-Draft, draft-ietf-idr-te-lsp-distribution-17, April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-17>.
[BGP-LS-TE-Policy] Previdi、S.、Talaulikar、K.、Ed。、Dong、J.、Ed。、Chen、M.、Gredler、H。、およびJ. Tantsura、「Traffic Engineeringの分布（TE）BGP-LSを使用したポリシーと状態、「進行中の作業、インターネットドラフト、Draft-ITR-TE-LSP-Distribution-17、2022年4月、<https://datatracker.ietf.org/doc/HTML/DRORET-IITF-IDR-TE-LSP-DISTRIBUTION-17>。
[BGP-SR-POLICY] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, P., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-segment-routing-te-policy-18, June 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-18>.
[BGP-Sr-Policy] Previdi、S.、Filsfils、C.、Talaulikar、K.、Ed。、Mattes、P.、Jain、D。、およびS. Lin、「広告セグメントルーティングポリシー」、作業進行中、インターネットドラフト、ドラフト-ITEF-IDR-SEMING-ROUTING-TE-POLICY-18、2022年6月、<https://datatracker.ietf.org/doc/html/draft-idr-segment-routing-te-policy-18>。
[IGP-FLEX-ALGO] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-20, May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20>.
[Igp-flex-algo] Psenak、P.、Ed。、Hegde、S.、Filsfils、C.、Talaulikar、K。、およびA. Gulko、「IGP Flexible Algorithm」、進行中の作業、インターネットドラフト、ドラフト-ietf-lsr-flex-algo-20、2022年5月、<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20>。
[PCEP-BSID-LABEL] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. Li, Ed., "Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.", Work in Progress, Internet-Draft, draft-ietf-pce-binding-label-sid-15, March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-15>.
[PCEP-BSID-Label] Sivabalan、S.、Filsfils、C.、Tantsura、J.、Previdi、S.、およびC. Li、ed。、「PCEベースのネットワークのバインディングラベル/セグメント識別子（SID）の運搬。」、進行中の作業、インターネットドラフト、ドラフト-ITF-PCEバインディングラベル-SID-15、2022年3月、<https://datatracker.ietf.org/doc/html/draft-ietf-pceバインディング-label-sid-15>。
[PCEP-SR-POLICY-CP] Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Bidgoli, "PCEP extension to support Segment Routing Policy Candidate Paths", Work in Progress, Internet-Draft, draft-ietf-pce-segment-routing-policy-cp-07, 21 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-07>.
[PCEP-SR-Policy-CP] Koldychev、M.、Sivabalan、S.、Barth、C.、Peng、S.、およびH. Bidgoli、「PCEP拡張機能ルーティングポリシー候補パスをサポートする」、進行中の作業、インターネットドラフト、ドラフト-ITESF-PCE-SEMING-Routing-Policy-CP-07、2022年4月21日、<https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-CP-07>。
[POI-SR] Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical Integration in Segment Routing", Work in Progress, Internet-Draft, draft-anand-spring-poi-sr-08, 29 July 2019, <https://datatracker.ietf.org/doc/html/draft-anand-spring-poi-sr-08>.
[Poi-Sr] Anand、M.、Bardhan、S.、Subrahmaniam、R.、Tantsura、J.、Mukhopadhyaya、U。、およびC. filsfils、「セグメントルーティングにおけるパケット統合」、進行中の作業、インターネット-draft、draft-anand-spring-poi-sr-08、2019年7月29日、<https://datatracker.ietf.org/doc/html/draft-anand-spring-poi-sr-08>
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC0020] Cerf、V。、「ネットワークインターチェンジ用ASCII形式」、STD 80、RFC 20、DOI 10.17487/RFC0020、1969年10月、<https://www.rfc-editor.org/info/rfc20>。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS ISの使用」、RFC 1195、DOI 10.17487/RFC1195、1990年12月、<https://www.rfc-editor.org/情報/rfc1195>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487/RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）拡張機能ズオブスフバージョン2」、RFC 3630、DOI 10.17487/RFC3630、2003年9月、<https：//www.rfc-editor.org/info/rfc3630>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、DOI 10.17487/RFC4760、2007年1月、<https：// www。rfc-editor.org/info/rfc4760>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Traffic Engineering for Traffic Engineering」、RFC 5305、DOI 10.17487/RFC5305、2008年10月、<https://www.rfc-editor.org/info/rfc5305>。
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.
[RFC5307] Kompella、K.、ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、DOI 10.17487/RFC5307、2008年10月、<https://www.rfc-editor.org/info/rfc5307>。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A。、およびA. Lindem、ed。、「OSPFバージョン3へのトラフィックエンジニアリング拡張」、RFC 5329、DOI 10.17487/RFC5329、2008年9月、<HTTPS：//www.rfc-editor.org/info/rfc5329>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487/RFC5340、2008年7月、<https：//www.rfc-editor.org/info/rfc5340>。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5462] Andersson、L。and R. Asati、「マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ：「Exp」フィールドは「トラフィッククラス」フィールドに改名されました。//www.rfc-editor.org/info/rfc5462>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「ロケーター/ID分離プロトコル（LISP）」、RFC 6830、DOI 10.17487/RFC6830、2013年1月、<https：/<https：//www.rfc-editor.org/info/rfc6830>。
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC7471] Giacalone、S.、Ward、D.、Drake、J.、Atlas、A。、およびS. Previdi、「OSPF Traffic Engineering（TE）Metric Extensions」、RFC 7471、DOI 10.17487/RFC7471、2015年3月、<https://www.rfc-editor.org/info/rfc7471>。
[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.、Misei、I.、Medved、J。、およびR. Varga、「Path Computation Element Communication Protocol（PCEP）ステートフルPCEの拡張」、RFC 8231、DOI 10.17487/RFC8231、2017年9月、<<https://www.rfc-editor.org/info/rfc8231>。
[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>。
[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月、<：//www.rfc-editor.org/info/rfc8491>。
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8570] Ginsberg、L.、Ed。、Previdi、S.、Ed。、Giacalone、S.、Ward、D.、Drake、J。、およびQ. Wu、「IS-IS Traffic Engineering（TE）Metric Extensions"、RFC 8570、doi 10.17487/rfc8570、2019年3月、<https://www.rfc-editor.org/info/rfc8570>。
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>.
[RFC8664] Sivabalan、S.、Filsfils、C.、Tantsura、J.、Henderickx、W。、およびJ. Hardwick、「パス計算要素通信プロトコル（PCEP）セグメントルーティング用拡張」、RFC 8664、DOI 10.17487/RFC86644487/、2019年12月、<https://www.rfc-editor.org/info/rfc8664>。
[RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., and N. Triantafillis, "Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State", RFC 8814, DOI 10.17487/RFC8814, August 2020, <https://www.rfc-editor.org/info/rfc8814>.
[RFC8814] Tantsura、J.、Chunduri、U.、Talaulikar、K.、Mirsky、G。、およびN. Triantafillis、「Border Gateway Protocol -link Stateを使用した最大SID深度（MSD）のシグナリング」、RFC 8814、doi10.17487/rfc8814、2020年8月、<https://www.rfc-editor.org/info/rfc8814>。
[RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Ray, S., and J. Dong, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 2021, <https://www.rfc-editor.org/info/rfc9086>.
[RFC9086] Previdi、S.、Talaulikar、K.、Ed。、Filsfils、C.、Patel、K.、Ray、S。、およびJ. Dong、 "Border Gateway Protocol -link State（BGP -LS）拡張機能セグメントルーティングBGP出力ピアエンジニアリング」、RFC 9086、DOI 10.17487/RFC9086、2021年8月、<https://www.rfc-editor.org/info/rfc9086>
[SR-POLICY-CONSID] Filsfils, C., Talaulikar, K., Ed., Krol, P., Horneffer, M., and P. Mattes, "SR Policy Implementation and Deployment Considerations", Work in Progress, Internet-Draft, draft-filsfils-spring-sr-policy-considerations-09, 24 April 2022, <https://datatracker.ietf.org/doc/html/ draft-filsfils-spring-sr-policy-considerations-09>.
[Sr-Policy-Consid] Filsfils、C.、Talaulikar、K.、ed。、Krol、P.、Horneffer、M.、およびP. Mattes、「SRポリシーの実施と展開の考慮事項」、進行中の作業、インターネット - ドラフト、ドラフト、ドラフト-filsfils-spring-sr-policy-consididerations-09、2022年4月24日、<https://datatracker.ietf.org/doc/html/ draft-filsfils-spring-srapolicy-considerations-09>。
[SR-POLICY-YANG] Raza, K., Ed., Sawaya, S., Shunwan, Z., Voyer, D., Durrani, M., Matsushima, S., and V. Beeram, "YANG Data Model for Segment Routing Policy", Work in Progress, Internet-Draft, draft-ietf-spring-sr-policy-yang-01, April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-policy-yang-01>.
[Sr-Policy-Yang] Raza、K.、Ed。、Sawaya、S.、Shunwan、Z.、Voyer、D.、Durrani、M.、Matsushima、S.、およびV. Beeram、 "Yang Data Model forセグメントルーティングポリシー」、作業中の作業、インターネットドラフト、Draft-Iitf-Spring-Sr-Policy-Yang-01、2021年4月、<https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-policy-yang-01>。
[SR-TI-LFA] Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-08, 21 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-08>.
[Sr-Ti-Lfa] Litkowski、S.、Bashandy、A.、Filsfils、C.、Francois、P.、Decraene、B。、およびD. Voyer、「Topology Independent Fast Rerouteセグメントルーティングを使用」、Internet-Draft、Draft-ITETF-RTGWG-SEMING-ROUTING-TI-LFA-08、2022年1月21日、<https://datatracker.ietf.org/doc/html/draft-iitf-rtgwg-segment--sage--routing-ti-lfa-08>。
[SR-TRAFFIC-ACCOUNTING] Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D., Morton, R., and G. Dawra, "Traffic Accounting in Segment Routing Networks", Work in Progress, Internet-Draft, draft-ali-spring-sr-traffic-accounting-07, May 2022, <https://datatracker.ietf.org/doc/html/draft-ali-spring-sr-traffic-accounting-07>.
[Sr-Traffic-Accounting] Ali、Z.、Filsfils、C.、Talaulikar、K.、Sivabalan、S.、Horneffer、M.、Raszuk、R.、Litkowski、S.、Voyer、D.、Morton、R R R。、およびG. Dawra、「セグメントルーティングネットワークの交通会計」、作業中の作業、インターネットドラフト、ドラフト-Ali-spring-spring-raffic-accounting-07、2022年5月<https：//datatracker.ietf。org/doc/html/draft-ali-spring-sr-traffic-accounting-07>。
[SR-TRAFFIC-COUNTERS] Filsfils, C., Ali, Z., Ed., Horneffer, M., Voyer, D., Durrani, M., and R. Raszuk, "Segment Routing Traffic Accounting Counters", Work in Progress, Internet-Draft, draft-filsfils-spring-sr-traffic-counters-02, October 2021, <https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-traffic-counters-02>.
[Sr-Traffic-Counters] Filsfils、C.、Ali、Z.、ed。、Horneffer、M.、Voyer、D.、Durrani、M.、およびR. Raszuk、「セグメントルーティングトラフィックカウンティングカウンター」、進行状況、インターネットドラフト、ドラフトフィルスフィルスプリング-Sr-トラフィックカウンターズ-02、2021年10月、<https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-traffic-counter--02>。
Acknowledgement
謝辞
The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha, Jim Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi, Matthew Bocci, Cullen Jennings, and Carlos J. Bernardos for their review, comments, and suggestions.
著者は、タレク・サード、ダネンドラ・ジャイン、ルーデガー・ガイブ、ロブ・シャキール、チェン・リー、ドルフ・ドディ、ギャン・ミシュラ、ナンダン・サハ、ジム・ギチャード、マーティン・ヴィゴール、ベンジャミン・シュワルツ、デイビッド・シナジ、マシュー・ボッシ、カル・ジャニング、カルロスに感謝したいと思います。J. Bernardosのレビュー、コメント、提案について。
Contributors
貢献者
The following people have contributed to this document:
次の人々がこの文書に貢献しています。
Siva Sivabalan Cisco Systems Email: msiva@cisco.com
Siva Sivabalan Cisco Systems Email：msiva@cisco.com
Zafar Ali Cisco Systems Email: zali@cisco.com
Zafar Ali Cisco Systems Email：zali@cisco.com
Jose Liste Cisco Systems Email: jliste@cisco.com
Jose Liste Cisco Systems Email：jliste@cisco.com
Francois Clad Cisco Systems Email: fclad@cisco.com
Francois Clad Cisco Systems Email：fclad@cisco.com
Kamran Raza Cisco Systems Email: skraza@cisco.com
Kamran Raza Cisco Systems Email：skraza@cisco.com
Mike Koldychev Cisco Systems Email: mkoldych@cisco.com
Mike Koldychev Cisco Systems Email：mkoldych@cisco.com
Shraddha Hegde Juniper Networks Email: shraddha@juniper.net
Shraddha Hegde Juniper Networks Email：shraddha@juniper.net
Steven Lin Google, Inc. Email: stevenlin@google.com
Steven Lin Google、Inc。電子メール：stevenlin@google.com
Przemyslaw Krol Google, Inc. Email: pkrol@google.com
Przemyslaw Krol Google、Inc。電子メール：pkrol@google.com
Martin Horneffer Deutsche Telekom Email: martin.horneffer@telekom.de
Martin Horneffer Deutsche Telekomメール：Martin.horneffer@telekom.de
Dirk Steinberg Steinberg Consulting Email: dws@steinbergnet.net
Dirk Steinberg Steinbergコンサルティングメール：dws@steinbergnet.net
Bruno Decraene Orange Business Services Email: bruno.decraene@orange.com
Bruno Decraene Orange Business Services Email：bruno.decraene@orange.com
Stephane Litkowski Orange Business Services Email: stephane.litkowski@orange.com
Stephane Litkowski Orange Business Services Email：Stephane.litkowski@orange.com
Luay Jalil Verizon Email: luay.jalil@verizon.com
Luay Jalil Verizonメール：luay.jalil@verizon.com
Authors' Addresses
著者のアドレス
Clarence Filsfils Cisco Systems, Inc. Pegasus Parc De kleetlaan 6a 1831 Diegem Belgium Email: cfilsfil@cisco.com
Clarence Filsfils Cisco Systems、Inc。Pegasus Parc de Kleetlaan 6a 1831 Diegem Belgiumメール：cfilsfil@cisco.com
Ketan Talaulikar (editor) Cisco Systems, Inc. India Email: ketant.ietf@gmail.com
Ketan Talaulikar（編集者）Cisco Systems、Inc。India Email：ketant.ietf@gmail.com
Daniel Voyer Bell Canada 671 de la gauchetiere W Montreal Quebec H3B 2M8 Canada Email: daniel.voyer@bell.ca
ダニエル・ボイヤー・ベル・カナダ671デ・ラ・ガウチェティエールwモントリオール・ケベックH3b 2m8カナダメール：daniel.voyer@bell.ca
Alex Bogdanov British Telecom Email: alex.bogdanov@bt.com
Alex Bogdanov British Telecom Email：alex.bogdanov@bt.com
Paul Mattes Microsoft One Microsoft Way Redmond, WA 98052-6399 United States of America Email: pamattes@microsoft.com
Paul Mattes Microsoft One Microsoft Way Redmond、WA 98052-6399 United States of America Email：pamattes@microsoft.com