[要約] RFC 8402は、セグメントルーティングアーキテクチャに関する標準化ドキュメントであり、セグメントルーティングの目的は、ネットワークトラフィックを効率的に制御し、柔軟性とスケーラビリティを向上させることです。
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8402 S. Previdi, Ed.
Category: Standards Track L. Ginsberg
ISSN: 2070-1721 Cisco Systems, Inc.
B. Decraene
S. Litkowski
Orange
R. Shakir
Google, Inc.
July 2018
Segment Routing Architecture
セグメントルーティングアーキテクチャ
Abstract
概要
Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.
セグメントルーティング（SR）は、ソースルーティングパラダイムを活用します。ノードは、「セグメント」と呼ばれる命令の順序付きリストを介してパケットを操作します。セグメントは、トポロジーまたはサービスベースの任意の命令を表すことができます。セグメントは、SRノード内のセマンティックローカルまたはSRドメイン内のグローバルを持つことができます。 SRは、SRドメインへの入口ノードでのみフローごとの状態を維持しながら、フローを特定のトポロジパスに制限できるメカニズムを提供します。
SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
SRは、転送プレーンに変更を加えることなく、MPLSアーキテクチャに直接適用できます。セグメントはMPLSラベルとしてエンコードされます。セグメントの順序付きリストは、ラベルのスタックとしてエンコードされます。処理するセグメントはスタックの一番上にあります。セグメントが完了すると、関連するラベルがスタックからポップされます。
SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.
SRは、新しいタイプのルーティングヘッダーを使用して、IPv6アーキテクチャに適用できます。セグメントはIPv6アドレスとしてエンコードされます。セグメントの順序付きリストは、ルーティングヘッダーのIPv6アドレスの順序付きリストとしてエンコードされます。アクティブセグメントは、パケットの宛先アドレス（DA）で示されます。次のアクティブなセグメントは、新しいルーティングヘッダーのポインターによって示されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8402.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8402で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 9
3.1. IGP-Prefix Segment (Prefix-SID) . . . . . . . . . . . . . 9
3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 9
3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. IGP-Node Segment (Node-SID) . . . . . . . . . . . . . . . 13
3.3. IGP-Anycast Segment (Anycast-SID) . . . . . . . . . . . . 13
3.3.1. Anycast-SID in SR-MPLS . . . . . . . . . . . . . . . 13
3.4. IGP-Adjacency Segment (Adj-SID) . . . . . . . . . . . . . 15
3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 17
3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 18
3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 18
4. BGP Segments . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. BGP-Prefix Segment . . . . . . . . . . . . . . . . . . . 19
4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 20
5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 21
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3. Congestion Control . . . . . . . . . . . . . . . . . . . 25
9. Manageability Considerations . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an SR Policy instantiated as an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR supports per-flow explicit routing while maintaining per-flow state only at the ingress nodes to the SR domain.
セグメントルーティング（SR）は、ソースルーティングパラダイムを活用します。ノードは、「セグメント」と呼ばれる命令の順序付きリストとしてインスタンス化されたSRポリシーを通じてパケットを操作します。セグメントは、トポロジーまたはサービスベースの任意の命令を表すことができます。セグメントは、SRノード内のセマンティックローカルまたはSRドメイン内のグローバルを持つことができます。 SRは、SRドメインへの入口ノードでのみフローごとの状態を維持しながら、フローごとの明示的なルーティングをサポートします。
A segment is often referred to by its Segment Identifier (SID).
多くの場合、セグメントはそのセグメント識別子（SID）によって参照されます。
A segment may be associated with a topological instruction. A topological local segment may instruct a node to forward the packet via a specific outgoing interface. A topological global segment may instruct an SR domain to forward the packet via a specific path to a destination. Different segments may exist for the same destination, each with different path objectives (e.g., which metric is minimized, what constraints are specified).
セグメントは、トポロジー命令に関連付けられている場合があります。トポロジーのローカルセグメントは、特定の発信インターフェイスを介してパケットを転送するようにノードに指示できます。トポロジグローバルセグメントは、SRドメインに、特定のパスを介してパケットを宛先に転送するように指示できます。同じ目的地に異なるセグメントが存在し、それぞれが異なるパス目標を持っている場合があります（たとえば、最小化されているメトリック、指定されている制約）。
A segment may be associated with a service instruction (e.g., the packet should be processed by a container or Virtual Machine (VM) associated with the segment). A segment may be associated with a QoS treatment (e.g., shape the packets received with this segment at x Mbps).
セグメントは、サービス命令に関連付けることができます（たとえば、パケットは、セグメントに関連付けられたコンテナまたは仮想マシン（VM）で処理する必要があります）。セグメントは、QoS処理に関連付けることができます（たとえば、このセグメントでx Mbpsで受信されたパケットを整形します）。
The SR architecture supports any type of instruction associated with a segment.
SRアーキテクチャは、セグメントに関連付けられたあらゆるタイプの命令をサポートします。
The SR architecture supports any type of control plane: distributed, centralized, or hybrid.
SRアーキテクチャは、分散型、集中型、ハイブリッド型など、あらゆるタイプのコントロールプレーンをサポートします。
In a distributed scenario, the segments are allocated and signaled by IS-IS or OSPF or BGP. A node individually decides to steer packets on an SR Policy (e.g., pre-computed local protection [RFC8355]). A node individually computes the SR Policy.
分散シナリオでは、セグメントが割り当てられ、IS-ISまたはOSPFまたはBGPによって通知されます。ノードは個別にSRポリシーでパケットをステアリングすることを決定します（たとえば、事前計算されたローカル保護[RFC8355]）。ノードは個別にSRポリシーを計算します。
In a centralized scenario, the segments are allocated and instantiated by an SR controller. The SR controller decides which nodes need to steer which packets on which source-routed policies. The SR controller computes the source-routed policies. The SR architecture does not restrict how the controller programs the network. Likely options are Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), and BGP. The SR architecture does not restrict the number of SR controllers. Specifically, multiple SR controllers may program the same SR domain. The SR architecture allows these SR controllers to discover which SIDs are instantiated at which nodes and which sets of local (SRLB) and global (SRGB) labels are available at which node.
一元化されたシナリオでは、セグメントはSRコントローラーによって割り当てられ、インスタンス化されます。 SRコントローラは、どのノードがどのソースルートポリシーでどのパケットを操作する必要があるかを決定します。 SRコントローラはソースルートポリシーを計算します。 SRアーキテクチャは、コントローラがネットワークをプログラムする方法を制限しません。ありそうなオプションは、ネットワーク構成プロトコル（NETCONF）、パス計算要素通信プロトコル（PCEP）、およびBGPです。 SRアーキテクチャは、SRコントローラーの数を制限しません。具体的には、複数のSRコントローラが同じSRドメインをプログラムする場合があります。 SRアーキテクチャにより、これらのSRコントローラーは、どのSIDがどのノードでインスタンス化され、どのセットのローカル（SRLB）およびグローバル（SRGB）ラベルのセットがどのノードで使用できるかを検出できます。
A hybrid scenario complements a base distributed control plane with a centralized controller. For example, when the destination is outside the IGP domain, the SR controller may compute an SR Policy on behalf of an IGP node. The SR architecture does not restrict how the nodes that are part of the distributed control plane interact with the SR controller. Likely options are PCEP and BGP.
ハイブリッドシナリオは、集中型コントローラーで基本分散制御プレーンを補完します。たとえば、宛先がIGPドメインの外部にある場合、SRコントローラはIGPノードに代わってSRポリシーを計算できます。 SRアーキテクチャは、分散コントロールプレーンの一部であるノードがSRコントローラーと対話する方法を制限しません。ありそうなオプションはPCEPとBGPです。
Hosts MAY be part of an SR domain. A centralized controller can inform hosts about policies either by pushing these policies to hosts or by responding to requests from hosts.
ホストはSRドメインの一部である場合があります。集中型コントローラーは、これらのポリシーをホストにプッシュするか、ホストからの要求に応答することにより、ポリシーについてホストに通知できます。
The SR architecture can be instantiated on various data planes. This document introduces two data-plane instantiations of SR: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6).
SRアーキテクチャは、さまざまなデータプレーンでインスタンス化できます。このドキュメントでは、SRの2つのデータプレーンのインスタンス化について紹介します。SRover MPLS（SR-MPLS）とSR over IPv6（SRv6）です。
SR can be directly applied to the MPLS architecture with no change to the forwarding plane [SR-MPLS]. A segment is encoded as an MPLS label. An SR Policy is instantiated as a stack of labels. The segment to process (the active segment) is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
SRは、転送プレーンに変更を加えることなく、MPLSアーキテクチャに直接適用できます[SR-MPLS]。セグメントはMPLSラベルとしてエンコードされます。 SRポリシーは、ラベルのスタックとしてインスタンス化されます。処理するセグメント（アクティブセグメント）はスタックの一番上にあります。セグメントが完了すると、関連するラベルがスタックからポップされます。
SR can be applied to the IPv6 architecture with a new type of routing header called the SR Header (SRH) [IPv6-SRH]. An instruction is associated with a segment and encoded as an IPv6 address. An SRv6 segment is also called an SRv6 SID. An SR Policy is instantiated as an ordered list of SRv6 SIDs in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by the SegmentsLeft (SL) pointer in the SRH. When an SRv6 SID is completed, the SL is decremented and the next segment is copied to the DA. When a packet is steered on an SR Policy, the related SRH is added to the packet.
SRは、SRヘッダー（SRH）[IPv6-SRH]と呼ばれる新しいタイプのルーティングヘッダーを使用してIPv6アーキテクチャに適用できます。命令はセグメントに関連付けられ、IPv6アドレスとしてエンコードされます。 SRv6セグメントはSRv6 SIDとも呼ばれます。 SRポリシーは、ルーティングヘッダー内のSRv6 SIDの順序付きリストとしてインスタンス化されます。アクティブセグメントは、パケットの宛先アドレス（DA）で示されます。次のアクティブなセグメントは、SRHのSegmentsLeft（SL）ポインターによって示されます。 SRv6 SIDが完了すると、SLが減分され、次のセグメントがDAにコピーされます。パケットがSRポリシーで操作されると、関連するSRHがパケットに追加されます。
In the context of an IGP-based distributed control plane, two topological segments are defined: the IGP-Adjacency segment and the IGP-Prefix segment.
IGPベースの分散コントロールプレーンのコンテキストでは、IGP隣接セグメントとIGPプレフィックスセグメントの2つのトポロジセグメントが定義されています。
In the context of a BGP-based distributed control plane, two topological segments are defined: the BGP peering segment and the BGP-Prefix segment.
BGPベースの分散コントロールプレーンのコンテキストでは、BGPピアリングセグメントとBGPプレフィックスセグメントの2つのトポロジセグメントが定義されています。
The headend of an SR Policy binds a SID (called a Binding segment or BSID) to its policy. When the headend receives a packet with active segment matching the BSID of a local SR Policy, the headend steers the packet into the associated SR Policy.
SRポリシーのヘッドエンドは、SID（バインディングセグメントまたはBSIDと呼ばれる）をそのポリシーにバインドします。ヘッドエンドがローカルSRポリシーのBSIDと一致するアクティブセグメントを持つパケットを受信すると、ヘッドエンドはパケットを関連するSRポリシーに誘導します。
This document defines the IGP, BGP, and Binding segments for the SR-MPLS and SRv6 data planes.
このドキュメントでは、SR-MPLSおよびSRv6データプレーンのIGP、BGP、およびバインディングセグメントを定義します。
Note: This document defines the architecture for Segment Routing, including definitions of basic objects and functions and a description of the overall design. It does NOT define the means of implementing the architecture -- that is contained in numerous referenced documents, some of which are mentioned in this document as a convenience to the reader.
注：このドキュメントでは、セグメントルーティングのアーキテクチャを定義します。これには、基本的なオブジェクトと機能の定義、および全体的な設計の説明が含まれます。アーキテクチャの実装方法は定義されていません。これは、多数の参照ドキュメントに含まれています。そのうちのいくつかは、読者の便宜のためにこのドキュメントで言及されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
SR-MPLS: the instantiation of SR on the MPLS data plane.
SR-MPLS：MPLSデータプレーン上のSRのインスタンス化。
SRv6: the instantiation of SR on the IPv6 data plane.
SRv6：IPv6データプレーン上のSRのインスタンス化。
Segment: an instruction a node executes on the incoming packet (e.g., forward packet according to shortest path to destination, or, forward packet through a specific interface, or, deliver the packet to a given application/service instance).
セグメント：着信パケットに対してノードが実行する命令（例：宛先への最短パスに従ってパケットを転送する、特定のインターフェースを介してパケットを転送する、または特定のアプリケーション/サービスインスタンスにパケットを配信する）。
SID: a segment identifier. Note that the term SID is commonly used in place of the term "Segment", though this is technically imprecise as it overlooks any necessary translation.
SID：セグメント識別子。 「セグメント」という用語の代わりにSIDという用語が一般的に使用されていることに注意してください。ただし、必要な翻訳を見落としているため、技術的には不正確です。
SR-MPLS SID: an MPLS label or an index value into an MPLS label space explicitly associated with the segment.
SR-MPLS SID：セグメントに明示的に関連付けられたMPLSラベルまたはMPLSラベルスペースへのインデックス値。
SRv6 SID: an IPv6 address explicitly associated with the segment.
SRv6 SID：セグメントに明示的に関連付けられているIPv6アドレス。
Segment Routing domain (SR domain): the set of nodes participating in the source-based routing model. These nodes may be connected to the same physical infrastructure (e.g., a Service Provider's network). They may as well be remotely connected to each other (e.g., an enterprise VPN or an overlay). If multiple protocol instances are deployed, the SR domain most commonly includes all of the protocol instances in a network. However, some deployments may wish to subdivide the network into multiple SR domains, each of which includes one or more protocol instances. It is expected that all nodes in an SR domain are managed by the same administrative entity.
セグメントルーティングドメイン（SRドメイン）：ソースベースのルーティングモデルに参加しているノードのセット。これらのノードは、同じ物理インフラストラクチャ（サービスプロバイダーのネットワークなど）に接続できます。また、リモートで相互に接続することもできます（エンタープライズVPNやオーバーレイなど）。複数のプロトコルインスタンスが展開されている場合、SRドメインには通常、ネットワーク内のすべてのプロトコルインスタンスが含まれます。ただし、展開によっては、ネットワークを複数のSRドメインに分割したい場合があり、それぞれに1つ以上のプロトコルインスタンスが含まれています。 SRドメイン内のすべてのノードが同じ管理エンティティによって管理されることが期待されています。
Active Segment: the segment that is used by the receiving router to process the packet. In the MPLS data plane, it is the top label. In the IPv6 data plane, it is the destination address [IPv6-SRH].
アクティブセグメント：受信ルーターがパケットを処理するために使用するセグメント。 MPLSデータプレーンでは、これはトップラベルです。 IPv6データプレーンでは、これは宛先アドレス[IPv6-SRH]です。
PUSH: the operation consisting of the insertion of a segment at the top of the segment list. In SR-MPLS, the top of the segment list is the topmost (outer) label of the label stack. In SRv6, the top of the segment list is represented by the first segment in the Segment Routing Header as defined in [IPv6-SRH].
PUSH：セグメントリストの最上部にセグメントを挿入する操作。 SR-MPLSでは、セグメントリストの最上部がラベルスタックの最上位（外部）ラベルです。 SRv6では、セグメントリストの最上部は、[IPv6-SRH]で定義されているセグメントルーティングヘッダーの最初のセグメントで表されます。
NEXT: when the active segment is completed, NEXT is the operation consisting of the inspection of the next segment. The next segment becomes active. In SR-MPLS, NEXT is implemented as a POP of the top label. In SRv6, NEXT is implemented as the copy of the next segment from the SRH to the destination address of the IPv6 header.
NEXT：アクティブなセグメントが完了すると、NEXTは次のセグメントの検査からなる操作です。次のセグメントがアクティブになります。 SR-MPLSでは、NEXTはトップラベルのPOPとして実装されます。 SRv6では、NEXTは、SRHからIPv6ヘッダーの宛先アドレスへの次のセグメントのコピーとして実装されます。
CONTINUE: the active segment is not completed; hence, it remains active. In SR-MPLS, the CONTINUE operation is implemented as a SWAP of the top label [RFC3031]. In SRv6, this is the plain IPv6 forwarding action of a regular IPv6 packet according to its destination address.
CONTINUE：アクティブなセグメントは完了していません。したがって、アクティブなままです。 SR-MPLSでは、CONTINUE操作はトップラベルの[SWAP]として実装されています[RFC3031]。 SRv6では、これは宛先アドレスに応じた通常のIPv6パケットの単純なIPv6転送アクションです。
SR Global Block (SRGB): the set of global segments in the SR domain. If a node participates in multiple SR domains, there is one SRGB for each SR domain. In SR-MPLS, SRGB is a local property of a node and identifies the set of local labels reserved for global segments. In SR-MPLS, using identical SRGBs on all nodes within the SR domain is strongly recommended. Doing so eases operations and troubleshooting as the same label represents the same global segment at each node. In SRv6, the SRGB is the set of global SRv6 SIDs in the SR domain.
SRグローバルブロック（SRGB）：SRドメインのグローバルセグメントのセット。ノードが複数のSRドメインに参加している場合、SRドメインごとに1つのSRGBがあります。 SR-MPLSでは、SRGBはノードのローカルプロパティであり、グローバルセグメント用に予約されたローカルラベルのセットを識別します。 SR-MPLSでは、SRドメイン内のすべてのノードで同一のSRGBを使用することを強くお勧めします。これにより、同じラベルが各ノードで同じグローバルセグメントを表すため、操作とトラブルシューティングが容易になります。 SRv6では、SRGBはSRドメイン内のグローバルSRv6 SIDのセットです。
SR Local Block (SRLB): local property of an SR node. If a node participates in multiple SR domains, there is one SRLB for each SR domain. In SR-MPLS, SRLB is a set of local labels reserved for local segments. In SRv6, SRLB is a set of local IPv6 addresses reserved for local SRv6 SIDs. In a controller-driven network, some controllers or applications may use the control plane to discover the available set of local segments.
SRローカルブロック（SRLB）：SRノードのローカルプロパティ。ノードが複数のSRドメインに参加している場合、SRドメインごとに1つのSRLBがあります。 SR-MPLSでは、SRLBはローカルセグメント用に予約されたローカルラベルのセットです。 SRv6では、SRLBはローカルSRv6 SID用に予約されたローカルIPv6アドレスのセットです。コントローラ駆動型ネットワークでは、一部のコントローラまたはアプリケーションがコントロールプレーンを使用して、使用可能なローカルセグメントのセットを検出する場合があります。
Global Segment: a segment that is part of the SRGB of the domain. The instruction associated with the segment is defined at the SR domain level. A topological shortest-path segment to a given destination within an SR domain is a typical example of a global segment.
グローバルセグメント：ドメインのSRGBの一部であるセグメント。セグメントに関連付けられた命令は、SRドメインレベルで定義されます。 SRドメイン内の特定の宛先へのトポロジー的な最短パスセグメントは、グローバルセグメントの典型的な例です。
Local Segment: In SR-MPLS, this is a local label outside the SRGB. It may be part of the explicitly advertised SRLB. In SRv6, this can be any IPv6 address, i.e., the address may be part of the SRGB, but used such that it has local significance. The instruction associated with the segment is defined at the node level.
ローカルセグメント：SR-MPLSでは、これはSRGB外のローカルラベルです。明示的にアドバタイズされたSRLBの一部である可能性があります。 SRv6では、これは任意のIPv6アドレスにすることができます。つまり、アドレスはSRGBの一部である可能性がありますが、ローカルな意味を持つように使用されます。セグメントに関連付けられた命令は、ノードレベルで定義されます。
IGP Segment: the generic name for a segment attached to a piece of information advertised by a link-state IGP, e.g., an IGP prefix or an IGP adjacency.
IGPセグメント：リンク状態IGPによってアドバタイズされた情報に添付されたセグメントの一般的な名前（IGPプレフィックスやIGP隣接など）。
IGP-Prefix Segment: an IGP-Prefix segment is an IGP segment representing an IGP prefix. When an IGP-Prefix segment is global within the SR IGP instance/topology, it identifies an instruction to forward the packet along the path computed using the routing algorithm specified in the algorithm field, in the topology, and in the IGP instance where it is advertised. Also referred to as "prefix segment".
IGPプレフィックスセグメント：IGPプレフィックスセグメントは、IGPプレフィックスを表すIGPセグメントです。 IGPプレフィックスセグメントがSR IGPインスタンス/トポロジ内でグローバルである場合、アルゴリズムフィールド、トポロジ、およびそれが存在するIGPインスタンスで指定されたルーティングアルゴリズムを使用して計算されたパスに沿ってパケットを転送する命令を識別します宣伝。 「プレフィックスセグメント」とも呼ばれます。
Prefix-SID: the SID of the IGP-Prefix segment.
Prefix-SID：IGP-PrefixセグメントのSID。
IGP-Anycast Segment: an IGP-Anycast segment is an IGP-Prefix segment that identifies an anycast prefix advertised by a set of routers.
IGP-Anycastセグメント：IGP-Anycastセグメントは、一連のルーターによってアドバタイズされるエニーキャストプレフィックスを識別するIGP-Prefixセグメントです。
Anycast-SID: the SID of the IGP-Anycast segment.
Anycast-SID：IGP-AnycastセグメントのSID。
IGP-Adjacency Segment: an IGP-Adjacency segment is an IGP segment attached to a unidirectional adjacency or a set of unidirectional adjacencies. By default, an IGP-Adjacency segment is local (unless explicitly advertised otherwise) to the node that advertises it. Also referred to as "Adj-SID".
IGP隣接セグメント：IGP隣接セグメントは、単方向隣接または一連の単方向隣接に接続されたIGPセグメントです。デフォルトでは、IGP-Adjacencyセグメントは、それをアドバタイズするノードに対してローカルです（明示的にアドバタイズされない限り）。 「Adj-SID」とも呼ばれます。
Adj-SID: the SID of the IGP-Adjacency segment.
Adj-SID：IGP隣接セグメントのSID。
IGP-Node Segment: an IGP-Node segment is an IGP-Prefix segment that identifies a specific router (e.g., a loopback). Also referred to as "Node Segment".
IGP-Nodeセグメント：IGP-Nodeセグメントは、特定のルーター（ループバックなど）を識別するIGP-Prefixセグメントです。 「ノードセグメント」とも呼ばれます。
Node-SID: the SID of the IGP-Node segment.
Node-SID：IGP-NodeセグメントのSID。
SR Policy: an ordered list of segments. The headend of an SR Policy steers packets onto the SR Policy. The list of segments can be specified explicitly in SR-MPLS as a stack of labels and in SRv6 as an ordered list of SRv6 SIDs. Alternatively, the list of segments is computed based on a destination and a set of optimization objective and constraints (e.g., latency, affinity, SRLG, etc.). The computation can be local or delegated to a PCE server. An SR Policy can be configured by the operator, provisioned via NETCONF [RFC6241] or provisioned via PCEP [RFC5440]. An SR Policy can be used for Traffic Engineering (TE), Operations, Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons.
SRポリシー：セグメントの順序付きリスト。 SRポリシーのヘッドエンドは、パケットをSRポリシーに誘導します。セグメントのリストは、SR-MPLSではラベルのスタックとして、SRv6ではSRv6 SIDの順序付きリストとして明示的に指定できます。あるいは、セグメントのリストは、宛先と、最適化の目的と制約のセット（例えば、待ち時間、類似性、SRLGなど）に基づいて計算されます。計算はローカルで行うことも、PCEサーバーに委任することもできます。 SRポリシーは、オペレーターによって構成され、NETCONF [RFC6241]を介してプロビジョニングされるか、PCEP [RFC5440]を介してプロビジョニングされます。 SRポリシーは、トラフィックエンジニアリング（TE）、運用、管理、保守（OAM）、または高速リルート（FRR）の理由で使用できます。
Segment List Depth: the number of segments of an SR Policy. The entity instantiating an SR Policy at a node N should be able to discover the depth-insertion capability of the node N. For example, the PCEP SR capability advertisement described in [PCEP-SR-EXT] is one means of discovering this capability.
セグメントリストの深さ：SRポリシーのセグメントの数。ノードNでSRポリシーをインスタンス化するエンティティは、ノードNの深度挿入機能を検出できる必要があります。たとえば、[PCEP-SR-EXT]で説明されているPCEP SR機能アドバタイズは、この機能を検出する1つの手段です。
Forwarding Information Base (FIB): the forwarding table of a node
転送情報ベース（FIB）：ノードの転送テーブル
Within an SR domain, an SR-capable IGP node advertises segments for its attached prefixes and adjacencies. These segments are called "IGP segments" or "IGP SIDs". They play a key role in Segment Routing and use cases as they enable the expression of any path throughout the SR domain. Such a path is either expressed as a single IGP segment or a list of multiple IGP segments.
SRドメイン内で、SR対応のIGPノードは、接続されているプレフィックスと隣接のセグメントをアドバタイズします。これらのセグメントは、「IGPセグメント」または「IGP SID」と呼ばれます。これらは、SRドメイン全体の任意のパスの表現を可能にするため、セグメントルーティングおよびユースケースで重要な役割を果たします。このようなパスは、単一のIGPセグメントまたは複数のIGPセグメントのリストとして表されます。
Advertisement of IGP segments requires extensions in link-state IGP protocols. These extensions are defined in [ISIS-SR-EXT], [OSPF-SR-EXT], and [OSPFv3-SR-EXT].
IGPセグメントのアドバタイズには、リンクステートIGPプロトコルの拡張が必要です。これらの拡張機能は、[ISIS-SR-EXT]、[OSPF-SR-EXT]、および[OSPFv3-SR-EXT]で定義されています。
An IGP-Prefix segment is an IGP segment attached to an IGP prefix. An IGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR domain. The context for an IGP-Prefix segment includes the prefix, topology, and algorithm. Multiple SIDs MAY be allocated to the same prefix so long as the tuple <prefix, topology, algorithm> is unique.
IGPプレフィックスセグメントは、IGPプレフィックスに付加されたIGPセグメントです。 IGPプレフィックスセグメントは、SRドメイン内で（明示的にアドバタイズされない限り）グローバルです。 IGP-Prefixセグメントのコンテキストには、プレフィックス、トポロジ、およびアルゴリズムが含まれます。タプル<prefix、topology、algorithm>が一意である限り、複数のSIDを同じプレフィックスに割り当てることができます。
Multiple instances and topologies are defined in IS-IS and OSPF in: [RFC5120], [RFC8202], [RFC6549], and [RFC4915].
IS-ISおよびOSPFでは、[RFC5120]、[RFC8202]、[RFC6549]、および[RFC4915]で複数のインスタンスとトポロジが定義されています。
Segment Routing supports the use of multiple routing algorithms, i.e, different constraint-based shortest-path calculations can be supported. An algorithm identifier is included as part of a Prefix-SID advertisement. Specification of how an algorithm-specific path calculation is done is required in the document defining the algorithm.
セグメントルーティングは、複数のルーティングアルゴリズムの使用をサポートします。つまり、さまざまな制約ベースの最短パス計算をサポートできます。アルゴリズム識別子は、Prefix-SIDアドバタイズメントの一部として含まれています。アルゴリズムを定義するドキュメントでは、アルゴリズム固有のパス計算の方法を指定する必要があります。
This document defines two algorithms:
このドキュメントでは、2つのアルゴリズムを定義しています。
o Shortest Path First: this algorithm is the default behavior. The packet is forwarded along the well known ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs. However, it is explicitly allowed for a midpoint to implement another forwarding based on local policy. The Shortest Path First algorithm is, in fact, the default and current behavior of most of the networks where local policies may override the SPF decision.
o 最短経路優先：このアルゴリズムはデフォルトの動作です。パケットは、IGPで採用されているよく知られたECMP対応のShortest Path First（SPF）アルゴリズムに沿って転送されます。ただし、中間点がローカルポリシーに基づいて別の転送を実装することは明示的に許可されています。最短経路優先アルゴリズムは、実際には、ローカルポリシーがSPFの決定をオーバーライドする可能性があるほとんどのネットワークのデフォルトおよび現在の動作です。
o Strict Shortest Path First (Strict-SPF): This algorithm mandates that the packet be forwarded according to the ECMP-aware SPF algorithm and instructs any router in the path to ignore any possible local policy overriding the SPF decision. The SID advertised with the Strict-SPF algorithm ensures that the path the packet is going to take is the expected, and not altered, SPF path. Note that Fast Reroute (FRR) [RFC5714] mechanisms are still compliant with the Strict Shortest Path First algorithm. In other words, a packet received with a Strict-SPF SID may be rerouted through an FRR mechanism. Strict-SPF uses the same topology used by the Shortest Path First algorithm. Obviously, nodes that do not support Strict-SPF will not install forwarding entries for this algorithm. Restricting the topology only to those nodes that support this algorithm will not produce the desired forwarding paths since the desired behavior is to follow the path calculated by the Shortest Path First algorithm. Therefore, a source SR node MUST NOT use an SR Policy containing a strict SPF segment if the path crosses a node not supporting the Strict-SPF algorithm.
o Strict Shortest Path First（Strict-SPF）：このアルゴリズムは、ECMP対応のSPFアルゴリズムに従ってパケットを転送することを要求し、パス内のすべてのルーターに、SPF決定を無効にする可能性のあるローカルポリシーを無視するように指示します。 Strict-SPFアルゴリズムでアドバタイズされるSIDは、パケットがたどるパスが予想どおりであり、変更されていないSPFパスであることを保証します。 Fast Reroute（FRR）[RFC5714]メカニズムは、依然としてStrict Shortest Path Firstアルゴリズムに準拠しています。言い換えると、Strict-SPF SIDで受信されたパケットは、FRRメカニズムを介して再ルーティングされます。 Strict-SPFは、Shortest Path Firstアルゴリズムで使用されるのと同じトポロジを使用します。明らかに、Strict-SPFをサポートしないノードは、このアルゴリズムの転送エントリをインストールしません。トポロジをこのアルゴリズムをサポートするノードのみに制限しても、望ましい動作はShortest Path Firstアルゴリズムによって計算されたパスをたどることになるため、望ましい転送パスは生成されません。したがって、パスがStrict-SPFアルゴリズムをサポートしていないノードと交差する場合、ソースSRノードは厳密なSPFセグメントを含むSRポリシーを使用してはなりません（MUST NOT）。
An IGP-Prefix segment identifies the path, to the related prefix, computed as per the associated algorithm. A packet injected anywhere within the SR domain with an active Prefix-SID is expected to be forwarded along a path computed using the specified algorithm. For this to be possible, a fully connected topology of routers supporting the specified algorithm is required.
IGP-Prefixセグメントは、関連するアルゴリズムに従って計算された、関連するプレフィックスへのパスを識別します。 SRドメイン内の任意の場所に挿入されたアクティブなPrefix-SIDを持つパケットは、指定されたアルゴリズムを使用して計算されたパスに沿って転送されることが期待されています。これを可能にするには、指定されたアルゴリズムをサポートするルーターの完全に接続されたトポロジが必要です。
When SR is used over the MPLS data plane, SIDs are an MPLS label or an index into an MPLS label space (either SRGB or SRLB).
SRがMPLSデータプレーンで使用される場合、SIDはMPLSラベルまたはMPLSラベルスペース（SRGBまたはSRLB）へのインデックスです。
Where possible, it is recommended that identical SRGBs be configured on all nodes in an SR domain. This simplifies troubleshooting as the same label will be associated with the same prefix on all nodes. In addition, it simplifies support for anycast as detailed in Section 3.3.
可能な場合は、SRドメインのすべてのノードで同一のSRGBを構成することをお勧めします。これにより、すべてのノードで同じラベルが同じプレフィックスに関連付けられるため、トラブルシューティングが簡単になります。さらに、セクション3.3で詳述するように、エニーキャストのサポートを簡素化します。
The following behaviors are associated with SR operating over the MPLS data plane:
次の動作は、MPLSデータプレーン上で動作するSRに関連しています。
o The IGP signaling extension for IGP-Prefix segment includes a flag to indicate whether directly connected neighbors of the node on which the prefix is attached should perform the NEXT operation or the CONTINUE operation when processing the SID. This behavior is equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop Popping (CONTINUE) in MPLS.
o IGP-PrefixセグメントのIGPシグナリング拡張には、SIDを処理するときに、プレフィックスが接続されているノードの直接接続されたネイバーがNEXT操作またはCONTINUE操作を実行する必要があるかどうかを示すフラグが含まれています。この動作は、MPLSの最後から2番目のホップポップ（NEXT）または最後のホップポップ（CONTINUE）と同等です。
o A Prefix-SID is allocated in the form of an MPLS label (or an index in the SRGB) according to a process similar to IP address allocation. Typically, the Prefix-SID is allocated by policy by the operator (or Network Management System (NMS)), and the SID very rarely changes.
o Prefix-SIDは、IPアドレス割り当てと同様のプロセスに従って、MPLSラベル（またはSRGBのインデックス）の形式で割り当てられます。通常、Prefix-SIDは、オペレーター（またはネットワーク管理システム（NMS））によってポリシーによって割り当てられ、SIDはほとんど変更されません。
o While SR allows a local segment to be attached to an IGP prefix, where the terminology "IGP-Prefix segment" or "Prefix-SID" is used, the segment is assumed to be global (i.e., the SID is defined from the advertised SRGB). This is consistent with all the described use cases that require global segments attached to IGP prefixes.
o SRではローカルセグメントをIGPプレフィックスに接続できますが、「IGP-Prefixセグメント」または「Prefix-SID」という用語が使用されますが、セグメントはグローバルであると想定されます（つまり、SIDはアドバタイズされたSRGBから定義されます） ）。これは、IGPプレフィックスに接続されたグローバルセグメントを必要とする、説明されているすべてのユースケースと一致しています。
o The allocation process MUST NOT allocate the same Prefix-SID to different prefixes.
o 割り当てプロセスは、同じPrefix-SIDを異なるプレフィックスに割り当ててはなりません（MUST NOT）。
o If a node learns of a Prefix-SID that has a value that falls outside the locally configured SRGB range, then the node MUST NOT use the Prefix-SID and SHOULD issue an error log reporting a misconfiguration.
o ローカルに設定されたSRGB範囲外の値を持つPrefix-SIDをノードが学習した場合、ノードはPrefix-SIDを使用してはならず（MUST NOT）、設定ミスを報告するエラーログを発行する必要があります（SHOULD）。
o If a node N advertises Prefix-SID SID-R for a prefix R that is attached to N and specifies CONTINUE as the operation to be performed by directly connected neighbors, then N MUST maintain the following FIB entry:
o ノードNがNに接続されている接頭辞RのPrefix-SID SID-Rをアドバタイズし、直接接続されたネイバーによって実行される操作としてCONTINUEを指定する場合、Nは次のFIBエントリを維持する必要があります。
Incoming Active Segment: SID-R Ingress Operation: NEXT Egress interface: NULL
着信アクティブセグメント：SID-R入力操作：NEXT出力インターフェイス：NULL
o A remote node M MUST maintain the following FIB entry for any learned Prefix-SID SID-R attached to prefix R:
o リモートノードMは、プレフィックスRに接続された学習済みのプレフィックスSID SID-Rの次のFIBエントリを維持する必要があります。
Incoming Active Segment: SID-R Ingress Operation: If the next-hop of R is the originator of R and M has been instructed to remove the active segment: NEXT Else: CONTINUE Egress interface: the interface(s) towards the next-hop along the path computed using the algorithm advertised with the SID toward prefix R.
着信アクティブセグメント：SID-R入力操作：RのネクストホップがRのオリジネーターであり、Mがアクティブセグメントを削除するように指示されている場合：NEXT Else：CONTINUE出力インターフェイス：次のホップに向かうインターフェイスSIDでアドバタイズされたアルゴリズムを使用して計算されたパスに沿って、プレフィックスRに向けて。
As Prefix-SIDs are specific to a given algorithm, if traffic associated with an algorithm arrives at a node that does not support that algorithm, the traffic will be dropped as there will be no forwarding entry matching the incoming label.
Prefix-SIDは特定のアルゴリズムに固有であるため、アルゴリズムに関連付けられたトラフィックがそのアルゴリズムをサポートしないノードに到着した場合、着信ラベルに一致する転送エントリがないため、トラフィックはドロップされます。
When SR is used over the IPv6 data plane:
SRがIPv6データプレーンで使用される場合：
o A Prefix-SID is an IPv6 address.
o Prefix-SIDはIPv6アドレスです。
o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node addresses are not SRv6 SIDs by default.
o オペレーターはSRv6 SIDを明示的にインスタンス化する必要があります。 IPv6ノードアドレスは、デフォルトではSRv6 SIDではありません。
A node N advertising an IPv6 address R usable as a segment identifier MUST maintain the following FIB entry:
セグメント識別子として使用可能なIPv6アドレスRをアドバタイズするノードNは、次のFIBエントリを維持する必要があります。
Incoming Active Segment: R Ingress Operation: NEXT Egress interface: NULL
着信アクティブセグメント：R入力操作：NEXT出力インターフェイス：NULL
Note that forwarding to R does not require an entry in the FIBs of all other routers for R. Forwarding can be, and most often will be, achieved by a shorter mask prefix that covers R.
Rへの転送は、Rの他のすべてのルーターのFIBにエントリを必要としないことに注意してください。転送は、Rをカバーする短いマスクプレフィックスによって実現できます。
Independent of SR support, any remote IPv6 node will maintain a plain IPv6 FIB entry for any prefix, no matter if the prefix represents a segment or not. This allows forwarding of packets to the node that owns the SID even by nodes that do not support SR.
SRサポートとは関係なく、リモートIPv6ノードは、プレフィックスがセグメントを表すかどうかに関係なく、プレフィックスのプレーンIPv6 FIBエントリを維持します。これにより、SRをサポートしていないノードでも、SIDを所有するノードにパケットを転送できます。
Support of multiple algorithms applies to SRv6. Since algorithm-specific SIDs are simply IPv6 addresses, algorithm-specific forwarding entries can be achieved by assigning algorithm-specific subnets to the (set of) algorithm specific SIDs that a node allocates.
複数のアルゴリズムのサポートがSRv6に適用されます。アルゴリズム固有のSIDは単にIPv6アドレスであるため、ノードが割り当てるアルゴリズム固有のSID（のセット）にアルゴリズム固有のサブネットを割り当てることにより、アルゴリズム固有の転送エントリを実現できます。
Nodes that do not support a given algorithm may still have a FIB entry covering an algorithm-specific address even though an algorithm-specific path has not been calculated by that node. This is mitigated by the fact that nodes that do not support a given algorithm will not be included in the topology associated with that algorithm-specific SPF; therefore, traffic using the algorithm-specific destination will normally not flow via the excluded node. If such traffic were to arrive and be forwarded by such a node, it will still progress towards the destination node. The next-hop will be either a node that supports the algorithm -- in which case, the packet will be forwarded along algorithm-specific paths (or be dropped if none are available) -- or a node that does NOT support the algorithm -- in which case, the packet will continue to be forwarded along Algorithm 0 paths towards the destination node.
特定のアルゴリズムをサポートしないノードは、アルゴリズム固有のパスがそのノードによって計算されていなくても、アルゴリズム固有のアドレスをカバーするFIBエントリを持っている場合があります。これは、特定のアルゴリズムをサポートしないノードがそのアルゴリズム固有のSPFに関連付けられたトポロジに含まれないという事実によって緩和されます。したがって、アルゴリズム固有の宛先を使用するトラフィックは、通常、除外されたノードを経由しません。このようなトラフィックが到着し、そのようなノードによって転送される場合でも、宛先ノードに向かって進みます。ネクストホップは、アルゴリズムをサポートするノード（この場合、パケットはアルゴリズム固有のパスに沿って転送されます（または、利用できない場合はドロップされます））またはアルゴリズムをサポートしないノードのいずれかになります- -この場合、パケットはアルゴリズム0のパスに沿って宛先ノードに転送され続けます。
An IGP Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain.
IGP Node-SIDは、同じルーティングドメイン内の複数のルーターが所有するプレフィックスに関連付けてはなりません（MUST NOT）。
An Anycast segment or Anycast-SID enforces the ECMP-aware shortest-path forwarding towards the closest node of the anycast set. This is useful to express macro-engineering policies or protection mechanisms.
エニーキャストセグメントまたはエニーキャストSIDは、エニーキャストセットの最も近いノードに向けてECMP対応の最短パス転送を実施します。これは、マクロエンジニアリングポリシーまたは保護メカニズムを表現するのに役立ちます。
An IGP-Anycast segment MUST NOT reference a particular node.
IGP-Anycastセグメントは特定のノードを参照してはなりません（MUST NOT）。
Within an anycast group, all routers in an SR domain MUST advertise the same prefix with the same SID value.
エニーキャストグループ内では、SRドメイン内のすべてのルーターは、同じSID値を持つ同じプレフィックスをアドバタイズする必要があります。
+--------------+
| Group A |
|192.0.2.10/32 |
| SID:100 |
| |
+-----------A1---A3----------+
| | | \ / | | |
SID:10 | | | / | | | SID:30
203.0.113.1/32 | | | / \ | | | 203.0.113.3/32
PE1------R1----------A2---A4---------R3------PE3
\ /| | | |\ /
\ / | +--------------+ | \ /
\ / | | \ /
/ | | /
/ \ | | / \
/ \ | +--------------+ | / \
/ \| | | |/ \
PE2------R2----------B1---B3---------R4------PE4
203.0.113.2/32 | | | \ / | | | 203.0.113.4/32
SID:20 | | | / | | | SID:40
| | | / \ | | |
+-----------B2---B4----------+
| |
| Group B |
| 192.0.2.1/32 |
| SID:200 |
+--------------+
Figure 1: Transit Device Groups
図1：トランジットデバイスグループ
The Figure 1 illustrates a network example with two groups of transit devices. Group A consists of devices {A1, A2, A3, and A4}. They are all provisioned with the anycast address 192.0.2.10/32 and the Anycast-SID 100.
図1は、2つの中継デバイスグループを持つネットワークの例を示しています。グループAは、デバイス{A1、A2、A3、およびA4}で構成されています。それらはすべてエニーキャストアドレス192.0.2.10/32とエニーキャストSID 100でプロビジョニングされます。
Similarly, Group B consists of devices {B1, B2, B3, and B4}, and they are all provisioned with the anycast address 192.0.2.1/32 and the Anycast-SID 200. In the above network topology, each Provide Edge (PE) device has a path to each of the groups: A and B.
同様に、グループBはデバイス{B1、B2、B3、およびB4}で構成され、それらはすべてエニーキャストアドレス192.0.2.1/32およびエニーキャストSID 200でプロビジョニングされます。上記のネットワークトポロジでは、各提供エッジ（PE ）デバイスには、AとBの各グループへのパスがあります。
PE1 can choose a particular transit device group when sending traffic to PE3 or PE4. This will be done by pushing the Anycast-SID of the group in the stack.
PE1は、トラフィックをPE3またはPE4に送信するときに、特定の中継デバイスグループを選択できます。これは、グループのAnycast-SIDをスタックにプッシュすることによって行われます。
Processing the anycast, and subsequent segments, requires special care.
エニーキャストとそれに続くセグメントの処理には、特別な注意が必要です。
+-------------------------+
| Group A |
| 192.0.2.10/32 |
| SID:100 |
|-------------------------|
| |
| SRGB: SRGB: |
SID:10 |(1000-2000) (3000-4000)| SID:30
PE1---+ +-------A1-------------A3-------+ +---PE3
\ / | | \ / | | \ /
\ / | | +-----+ / | | \ /
SRGB: \ / | | \ / | | \ / SRGB:
(7000-8000) R1 | | \ | | R3 (6000-7000)
/ \ | | / \ | | / \
/ \ | | +-----+ \ | | / \
/ \ | | / \ | | / \
PE2---+ +-------A2-------------A4-------+ +---PE4
SID:20 | SRGB: SRGB: | SID:40
|(2000-3000) (4000-5000)|
| |
+-------------------------+
Figure 2: Transit Paths via Anycast Group A
図2：エニーキャストグループA経由のトランジットパス
Considering an MPLS deployment, in the above topology, if device PE1 (or PE2) requires the sending of a packet to the device PE3 (or PE4), it needs to encapsulate the packet in an MPLS payload with the following stack of labels.
上記のトポロジでMPLSの導入を考慮すると、デバイスPE1（またはPE2）がデバイスPE3（またはPE4）にパケットを送信する必要がある場合、次のラベルのスタックを使用してMPLSペイロードにパケットをカプセル化する必要があります。
o Label allocated by R1 for Anycast-SID 100 (outer label).
o Anycast-SID 100のR1によって割り当てられたラベル（外部ラベル）。
o Label allocated by the nearest router in Group A for SID 30 (for destination PE3).
o SID 30のグループAの最も近いルーターによって割り当てられたラベル（宛先PE3用）。
In this case, the first label is easy to compute. However, because there is more than one device that is topologically nearest (A1 and A2), determining the second label is impossible unless A1 and A2 allocated the same label value to the same prefix. Devices A1 and A2 may be devices from different hardware vendors. If both don't allocate the same label value for SID 30, it is impossible to use the anycast Group A as a transit anycast group towards PE3. Hence, PE1 (or PE2) cannot compute an appropriate label stack to steer the packet exclusively through the Group A devices. Same holds true for devices PE3 and PE4 when trying to send a packet to PE1 or PE2.
この場合、最初のラベルは簡単に計算できます。ただし、トポロジ的に最も近いデバイス（A1とA2）が複数あるため、A1とA2が同じプレフィックスに同じラベル値を割り当てない限り、2番目のラベルを特定することはできません。デバイスA1およびA2は、異なるハードウェアベンダーのデバイスである場合があります。どちらもSID 30に同じラベル値を割り当てない場合、エニーキャストグループAをPE3への中継エニーキャストグループとして使用することはできません。したがって、PE1（またはPE2）は適切なラベルスタックを計算して、グループAデバイスのみを介してパケットを誘導することはできません。 PE1またはPE2にパケットを送信しようとする場合、デバイスPE3およびPE4にも同じことが当てはまります。
To ease the use of an anycast segment, it is recommended to configure identical SRGBs on all nodes of a particular anycast group. Using this method, as mentioned above, computation of the label following the anycast segment is straightforward.
エニーキャストセグメントの使用を容易にするために、特定のエニーキャストグループのすべてのノードで同一のSRGBを構成することをお勧めします。上記のように、この方法を使用すると、エニーキャストセグメントに続くラベルの計算は簡単です。
Using an anycast segment without configuring identical SRGBs on all nodes belonging to the same anycast group may lead to misrouting (in an MPLS VPN deployment, some traffic may leak between VPNs).
同じエニーキャストグループに属するすべてのノードで同一のSRGBを構成せずにエニーキャストセグメントを使用すると、誤ルーティングが発生する可能性があります（MPLS VPN展開では、VPN間で一部のトラフィックがリークする可能性があります）。
The adjacency is formed by the local node (i.e., the node advertising the adjacency in the IGP) and the remote node (i.e., the other end of the adjacency). The local node MUST be an IGP node. The remote node may be an adjacent IGP neighbor or a non-adjacent neighbor (e.g., a forwarding adjacency, [RFC4206]).
隣接関係は、ローカルノード（IGPで隣接関係をアドバタイズするノード）とリモートノード（隣接関係のもう一方の端）によって形成されます。ローカルノードはIGPノードである必要があります。リモートノードは、隣接するIGPネイバーまたは非隣接ネイバー（たとえば、転送隣接[RFC4206]）である場合があります。
A packet injected anywhere within the SR domain with a segment list {SN, SNL} where SN is the Node-SID of node N and SNL is an Adj-SID attached by node N to its adjacency over link L will be forwarded along the shortest path to N and then be switched by N, without any IP shortest-path consideration, towards link L. If the Adj-SID identifies a set of adjacencies, then the node N load-balances the traffic among the various members of the set.
セグメントリスト{SN、SNL}でSRドメイン内のどこかに挿入されたパケット。SNはノードNのノードSIDであり、SNLはノードNによってリンクLを介して隣接に接続されたAdj-SIDであり、最短で転送されます。 Nへのパス。次に、IP最短パスを考慮せずに、リンクLに向けてNによって切り替えられます。Adj-SIDが隣接のセットを識別する場合、ノードNは、セットのさまざまなメンバー間でトラフィックの負荷を分散します。
Similarly, when using a global Adj-SID, a packet injected anywhere within the SR domain with a segment list {SNL}, where SNL is a global Adj-SID attached by node N to its adjacency over link L, will be forwarded along the shortest path to N and then be switched by N, without any IP shortest-path consideration, towards link L. If the Adj-SID identifies a set of adjacencies, then the node N does load-balance the traffic among the various members of the set. The use of global Adj-SID allows to reduce the size of the segment list when expressing a path at the cost of additional state (i.e., the global Adj-SID will be inserted by all routers within the area in their forwarding table).
同様に、グローバルAdj-SIDを使用する場合、SRドメイン内のどこかにセグメントリスト{SNL}で挿入されたパケットは、SNLがノードNによってリンクLを介してその隣接に接続されたグローバルAdj-SIDであり、 Nへの最短パス。その後、IP最短パスを考慮せずに、リンクLに向けてNによって切り替えられます。Adj-SIDが隣接のセットを識別する場合、ノードNは、トラフィックのさまざまなメンバー間でトラフィックの負荷を分散します。セットする。グローバルAdj-SIDを使用すると、追加の状態を犠牲にしてパスを表現するときにセグメントリストのサイズを削減できます（つまり、グローバルAdj-SIDは、転送テーブル内のエリア内のすべてのルーターによって挿入されます）。
An "IGP-Adjacency segment" or "Adj-SID" enforces the switching of the packet from a node towards a defined interface or set of interfaces. This is key to theoretically prove that any path can be expressed as a list of segments.
「IGP隣接セグメント」または「Adj-SID」は、ノードから定義されたインターフェースまたはインターフェースのセットへのパケットのスイッチングを強制します。これは、すべてのパスがセグメントのリストとして表現できることを理論的に証明するための鍵です。
The encodings of the Adj-SID include a set of flags supporting the following functionalities:
Adj-SIDのエンコーディングには、次の機能をサポートするフラグのセットが含まれています。
o Eligible for Protection (e.g., using IPFRR or MPLS-FRR). Protection allows that in the event the interface(s) associated with the Adj-SID are down, that the packet can still be forwarded via an alternate path. The use of protection is clearly a policy-based decision; that is, for a given policy protection may or may not be desirable.
o 保護対象（IPFRRまたはMPLS-FRRを使用するなど）。保護により、Adj-SIDに関連付けられたインターフェースがダウンした場合でも、パケットを代替パス経由で転送することができます。保護の使用は明らかにポリシーベースの決定です。つまり、特定のポリシーでは、保護が望ましい場合と望ましくない場合があります。
o Indication whether the Adj-SID has local or global scope. Default scope SHOULD be local.
o Adj-SIDがローカルスコープかグローバルスコープかを示します。デフォルトのスコープはローカルである必要があります。
o Indication whether the Adj-SID is persistent across control plane restarts. Persistence is a key attribute in ensuring that an SR Policy does not temporarily result in misforwarding due to reassignment of an Adj-SID.
o コントロールプレーンの再起動後もAdj-SIDが永続的かどうかを示します。持続性は、Adj-SIDの再割り当てが原因でSRポリシーが一時的に転送ミスを引き起こさないようにするための重要な属性です。
A weight (as described below) is also associated with the Adj-SID advertisement.
重み（以下で説明）もAdj-SIDアドバタイズメントに関連付けられています。
A node SHOULD allocate one Adj-SID for each of its adjacencies.
ノードは隣接のそれぞれに1つのAdj-SIDを割り当てる必要があります（SHOULD）。
A node MAY allocate multiple Adj-SIDs for the same adjacency. An example is to support an Adj-SID that is eligible for protection and an Adj-SID that is NOT eligible for protection.
ノードは同じ隣接に複数のAdj-SIDを割り当てることができます（MAY）。例としては、保護の対象となるAdj-SIDと保護の対象とならないAdj-SIDのサポートがあります。
A node MAY associate the same Adj-SID to multiple adjacencies.
ノードは、同じAdj-SIDを複数の隣接に関連付けることができます。
In order to be able to advertise in the IGP all the Adj-SIDs representing the IGP adjacencies between two nodes, parallel adjacency suppression MUST NOT be performed by the IGP.
2つのノード間のIGP隣接関係を表すすべてのAdj-SIDをIGPでアドバタイズできるようにするには、IGPで並列隣接関係抑制を実行してはなりません（MUST NOT）。
When a node binds an Adj-SID V to a local data-link L, the node MUST install the following FIB entry:
ノードがAdj-SID VをローカルデータリンクLにバインドする場合、ノードは次のFIBエントリをインストールする必要があります。
Incoming Active Segment: V Ingress Operation: NEXT Egress Interface: L
着信アクティブセグメント：V入力操作：NEXT出力インターフェイス：L
The Adj-SID implies, from the router advertising it, the forwarding of the packet through the adjacency or adjacencies identified by the Adj-SID, regardless of its IGP/SPF cost. In other words, the use of adjacency segments overrides the routing decision made by the SPF algorithm.
Adj-SIDは、それをアドバタイズするルーターから、IGP / SPFコストに関係なく、Adj-SIDによって識別される1つまたは複数の隣接を介したパケットの転送を意味します。つまり、隣接セグメントを使用すると、SPFアルゴリズムによるルーティングの決定が上書きされます。
Adj-SIDs can be used in order to represent a set of parallel interfaces between two adjacent routers.
Adj-SIDは、2つの隣接するルーター間の一連の並列インターフェイスを表すために使用できます。
A node MUST install a FIB entry for any locally originated Adj-SID of value W attached to a set of links B with:
ノードは、リンクBのセットに接続された値Wのローカルで生成されたAdj-SIDのFIBエントリをインストールする必要があります。
Incoming Active Segment: W Ingress Operation: NEXT Egress interfaces: load-balance between any data-link within set B
着信アクティブセグメント：W入力操作：NEXT出力インターフェイス：セットB内のデータリンク間の負荷分散
When parallel adjacencies are used and associated with the same Adj-SID, and, in order to optimize the load-balancing function, a "weight" factor can be associated with the Adj-SID advertised with each adjacency. The weight tells the ingress (or an SDN/ orchestration system) about the load-balancing factor over the parallel adjacencies. As shown in Figure 3, A and B are connected through two parallel adjacencies
並列隣接が使用され、同じAdj-SIDに関連付けられている場合、負荷分散機能を最適化するために、各隣接でアドバタイズされるAdj-SIDに「重み」係数を関連付けることができます。重みは、並列隣接の負荷分散係数について、イングレス（またはSDN /オーケストレーションシステム）に通知します。図3に示すように、AとBは2つの並列隣接を介して接続されています
Link-1
+--------+
| |
S---A B---C
| |
+--------+
Link-2
Figure 3: Parallel Links and Adj-SIDs
図3：並列リンクとAdj-SID
Node A advertises following Adj-SIDs and weights:
ノードAは、次のAdj-SIDと重みをアドバタイズします。
o Link-1: Adj-SID 1000, weight: 1
o リンク1：Adj-SID 1000、重量：1
o Link-2: Adj-SID 1000, weight: 2
o リンク2：Adj-SID 1000、重量：2
Node S receives the advertisements of the parallel adjacencies and understands that by using Adj-SID 1000 node A will load-balance the traffic across the parallel links (Link-1 and Link-2) according to a 1:2 ratio i.e., twice as many packets will flow over Link-2 as compared to Link-1.
ノードSは、並列隣接のアドバタイズを受信し、Adj-SID 1000を使用することにより、ノードAが1：2の比率、つまり2倍の比率に従って、並列リンク（Link-1およびLink-2）全体でトラフィックの負荷を分散することを理解します。 Link-1と比較して、多くのパケットがLink-2を介して流れます。
In LAN subnetworks, link-state protocols define the concept of Designated Router (DR, in OSPF) or Designated Intermediate System (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and that describe the LAN topology in a special routing update (OSPF Type2 LSA or IS-IS Pseudonode LSP).
LANサブネットワークでは、リンクステートプロトコルは、ブロードキャストサブネットワークでフラッディングを実行し、特別なルーティングアップデートでLANトポロジを記述する指定ルーター（OSPFではDR）または指定中間システム（IS-ISではDIS）の概念を定義します（ OSPF Type2 LSAまたはIS-IS Pseudonode LSP）。
The difficulty with LANs is that each router only advertises its connectivity to the DR/DIS and not to each of the individual nodes in the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) are necessary in order for each router in the LAN to advertise an Adj-SID associated with each neighbor in the LAN.
LANの問題は、各ルーターがDR / DISへの接続のみをアドバタイズし、LAN内の個々のノードへのアドバタイズを行わないことです。したがって、LAN内の各ルーターがLAN内の各ネイバーに関連付けられたAdj-SIDを通知するためには、追加のプロトコルメカニズム（IS-ISおよびOSPF）が必要です。
In the following example diagram, it is assumed that the all areas are part of a single SR domain.
次の図の例では、すべてのエリアが単一のSRドメインの一部であると想定しています。
The Figure 4 assumes the IPv6 control plane with the MPLS data plane.
図4では、MPLSデータプレーンを備えたIPv6コントロールプレーンを想定しています。
! !
! !
B------C-----F----G-----K
/ | | |
S---A/ | | |
\ | | |
\D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150)
! !
Area 1 ! Backbone ! Area 2
! area !
Figure 4: Inter-Area Topology Example
図4：エリア間トポロジの例
In Area 2, node Z allocates Node-SID 150 to his local IPv6 prefix 2001:DB8::2:1/128.
エリア2で、ノードZはNode-SID 150を彼のローカルIPv6プレフィックス2001：DB8 :: 2：1/128に割り当てます。
Area Border Routers (ABRs) G and J will propagate the prefix and its SIDs into the backbone area by creating a new instance of the prefix according to normal inter-area/level IGP propagation rules.
エリアボーダールーター（ABR）GおよびJは、通常のエリア間/レベルIGP伝搬ルールに従ってプレフィックスの新しいインスタンスを作成することにより、プレフィックスとそのSIDをバックボーンエリアに伝搬します。
Nodes C and I will apply the same behavior when leaking prefixes from the backbone area down to area 1. Therefore, node S will see prefix 2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and I.
ノードCとIは、バックボーンエリアからエリア1にプレフィックスをリークするときに同じ動作を適用します。したがって、ノードSには、プレフィックスSID 150のプレフィックス2001：DB8 :: 2：1/128が表示され、ノードCとノードIによってアドバタイズされます。 。
Therefore, the result is that a Prefix-SID remains attached to its related IGP prefix through the inter-area process, which is the expected behavior in a single SR domain.
したがって、結果として、プレフィックスSIDは、エリア間プロセスを通じて関連するIGPプレフィックスにアタッチされたままになります。これは、単一のSRドメインで予想される動作です。
When node S sends traffic to 2001:DB8::2:1/128, it pushes Node-SID(150) as an active segment and forwards it to A.
ノードSが2001：DB8 :: 2：1/128にトラフィックを送信すると、Node-SID（150）をアクティブセグメントとしてプッシュし、それをAに転送します。
When a packet arrives at ABR I (or C), the ABR forwards the packet according to the active segment (Node-SID(150)). Forwarding continues across area borders, using the same Node-SID(150) until the packet reaches its destination.
パケットがABR I（またはC）に到着すると、ABRはアクティブセグメント（Node-SID（150））に従ってパケットを転送します。パケットが宛先に到達するまで、同じNode-SID（150）を使用してエリア境界を越えて転送が続行されます。
BGP segments may be allocated and distributed by BGP.
BGPセグメントは、BGPによって割り当てられ、配布されます。
A BGP-Prefix segment is a BGP segment attached to a BGP prefix.
BGPプレフィックスセグメントは、BGPプレフィックスに付加されたBGPセグメントです。
A BGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR domain.
BGPプレフィックスセグメントは、SRドメイン内で（明示的にアドバタイズされない限り）グローバルです。
The BGP-Prefix segment is the BGP equivalent to the IGP-Prefix segment.
BGP-Prefixセグメントは、IGP-Prefixセグメントと同等のBGPです。
A likely use case for the BGP-Prefix segment is an IGP-free hyper-scale spine-leaf topology where connectivity is learned solely via BGP [RFC7938]
BGPプレフィックスセグメントのおそらく使用例は、接続がBGPのみを介して学習されるIGPフリーハイパースケールスパインリーフトポロジです[RFC7938]
In the context of BGP Egress Peer Engineering (EPE), as described in [SR-CENTRAL-EPE], an EPE-enabled egress node MAY advertise segments corresponding to its attached peers. These segments are called BGP peering segments or BGP peering SIDs. They enable the expression of source-routed inter-domain paths.
[SR-CENTRAL-EPE]で説明されているように、BGP出力ピアエンジニアリング（EPE）のコンテキストでは、EPE対応の出力ノードは、接続されているピアに対応するセグメントを通知できます（MAY）。これらのセグメントは、BGPピアリングセグメントまたはBGPピアリングSIDと呼ばれます。それらはソースルートされたドメイン間パスの表現を可能にします。
An ingress border router of an Autonomous System (AS) may compose a list of segments to steer a flow along a selected path within the AS towards a selected egress border router C of the AS and through a specific peer. At a minimum, a BGP peering engineering policy applied at an ingress node involves two segments: the Node-SID of the chosen egress node and the BGP peering segment for the chosen egress node peer or peering interface.
自律システム（AS）の入力ボーダールーターは、AS内の選択されたパスに沿って、ASの選択された出力ボーダールーターCに向けて、特定のピアを介してフローを導くためのセグメントのリストを作成します。少なくとも、入力ノードに適用されるBGPピアリングエンジニアリングポリシーには、2つのセグメントが含まれます。選択された出力ノードのNode-SIDと、選択された出力ノードピアまたはピアリングインターフェイスのBGPピアリングセグメントです。
Three types of BGP peering segments/SIDs are defined: PeerNode SID, PeerAdj SID, and PeerSet SID.
3つのタイプのBGPピアリングセグメント/ SIDが定義されています：PeerNode SID、PeerAdj SID、およびPeerSet SID。
o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At the BGP node advertising it, its semantics are:
o PeerNode SID：BGP PeerNodeセグメント/ SIDはローカルセグメントです。それをアドバタイズするBGPノードでは、そのセマンティクスは次のとおりです。
* SR operation: NEXT.
* SRオペレーション：NEXT。
* Next-Hop: the connected peering node to which the segment is related.
* ネクストホップ：セグメントが関連付けられている、接続されているピアリングノード。
o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the BGP node advertising it, the semantics are:
o PeerAdj SID：BGP PeerAdjセグメント/ SIDはローカルセグメントです。それをアドバタイズするBGPノードでは、セマンティクスは次のとおりです。
* SR operation: NEXT.
* SRオペレーション：NEXT。
* Next-Hop: the peer connected through the interface to which the segment is related.
* ネクストホップ：セグメントが関連付けられているインターフェースを介して接続されたピア。
o PeerSet SID: a BGP PeerSet segment/SID is a local segment. At the BGP node advertising it, the semantics are:
o PeerSet SID：BGP PeerSetセグメント/ SIDはローカルセグメントです。それをアドバタイズするBGPノードでは、セマンティクスは次のとおりです。
* SR operation: NEXT.
* SRオペレーション：NEXT。
* Next-Hop: load-balance across any connected interface to any peer in the related group.
* ネクストホップ：関連グループ内の任意のピアに接続されたすべてのインターフェース間で負荷を分散します。
A peer set could be all the connected peers from the same AS or a subset of these. A group could also span across AS. The group definition is a policy set by the operator.
ピアセットは、同じASから接続されているすべてのピア、またはこれらのサブセットです。グループはASにまたがることもできます。グループ定義は、オペレーターが設定するポリシーです。
The BGP extensions necessary in order to signal these BGP peering segments are defined in [BGPLS-SR-EPE].
これらのBGPピアリングセグメントをシグナリングするために必要なBGP拡張は、[BGPLS-SR-EPE]で定義されています。
In order to provide greater scalability, network opacity, and service independence, SR utilizes a Binding SID (BSID). The BSID is bound to an SR Policy, instantiation of which may involve a list of SIDs. Any packets received with an active segment equal to BSID are steered onto the bound SR Policy.
優れたスケーラビリティ、ネットワークの不透明性、およびサービスの独立性を提供するために、SRはバインディングSID（BSID）を利用します。 BSIDはSRポリシーにバインドされており、そのインスタンス化にはSIDのリストが含まれる場合があります。 BSIDと等しいアクティブセグメントで受信されたパケットはすべて、バインドされたSRポリシーに誘導されます。
A BSID may be either a local or a global SID. If local, a BSID SHOULD be allocated from the SRLB. If global, a BSID MUST be allocated from the SRGB.
BSIDはローカルまたはグローバルSIDのいずれかです。ローカルの場合、BSIDはSRLBから割り当てられる必要があります（SHOULD）。グローバルの場合、SSIDからBSIDを割り当てる必要があります。
Use of a BSID allows the instantiation of the policy (the SID list) to be stored only on the node or nodes that need to impose the policy. Direction of traffic to a node supporting the policy then only requires imposition of the BSID. If the policy changes, this also means that only the nodes imposing the policy need to be updated. Users of the policy are not impacted.
BSIDを使用すると、ポリシー（SIDリスト）のインスタンス化を、ポリシーを適用する必要がある1つまたは複数のノードにのみ保存できます。ポリシーをサポートするノードへのトラフィックの方向は、BSIDのインポジションのみが必要です。ポリシーが変更された場合、これは、ポリシーを課しているノードのみを更新する必要があることも意味します。ポリシーのユーザーは影響を受けません。
One use case for a Binding segment is to provide support for an IGP node to advertise its ability to process traffic originally destined to another IGP node, called the "mirrored node" and identified by an IP address or a Node-SID, provided that a Mirroring Context segment is inserted in the segment list prior to any service segment local to the mirrored node.
バインディングセグメントの使用例の1つは、IGPノードが「ミラーリングノード」と呼ばれ、IPアドレスまたはノードSIDで識別される、もともと別のIGPノード宛てのトラフィックを処理する機能をアドバタイズするサポートを提供することです。ミラーリングコンテキストセグメントは、ミラーリングされたノードに対してローカルなサービスセグメントの前のセグメントリストに挿入されます。
When a given node B wants to provide egress node A protection, it advertises a segment identifying node's A context. Such a segment is called "Mirroring Context segment" and is identified by the Mirror SID.
特定のノードBが出力ノードAの保護を提供したい場合、ノードBのコンテキストを識別するセグメントを通知します。このようなセグメントは「ミラーリングコンテキストセグメント」と呼ばれ、ミラーSIDによって識別されます。
The Mirror SID is advertised using the Binding segment defined in SR IGP protocol extensions [ISIS-SR-EXT].
ミラーSIDは、SR IGPプロトコル拡張[ISIS-SR-EXT]で定義されたバインディングセグメントを使用してアドバタイズされます。
In the event of a failure, a Point of Local Repair (PLR) diverting traffic from A to B does a PUSH of the Mirror SID on the protected traffic. When receiving the traffic with the Mirror SID as the active segment, B uses that segment and processes underlying segments in the context of A.
障害が発生した場合、トラフィックをAからBに迂回させるPoint of Local Repair（PLR）は、保護されたトラフィックでミラーSIDのPUSHを実行します。ミラーSIDをアクティブセグメントとしてトラフィックを受信すると、Bはそのセグメントを使用し、Aのコンテキストで基礎となるセグメントを処理します。
Segment Routing is defined for unicast. The application of the source-route concept to Multicast is not in the scope of this document.
セグメントルーティングはユニキャスト用に定義されています。ソースルートの概念をマルチキャストに適用することは、このドキュメントの範囲外です。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
Segment Routing is applicable to both MPLS and IPv6 data planes.
セグメントルーティングは、MPLSおよびIPv6データプレーンの両方に適用できます。
SR adds some metadata (instructions) to the packet, with the list of forwarding path elements (e.g., nodes, links, services, etc.) that the packet must traverse. It has to be noted that the complete source-routed path may be represented by a single segment. This is the case of the Binding SID.
SRは、パケットが通過する必要がある転送パス要素（ノード、リンク、サービスなど）のリストとともに、いくつかのメタデータ（指示）をパケットに追加します。完全なソースルートパスは、単一のセグメントによって表される場合があることに注意する必要があります。これはバインディングSIDの場合です。
By default, SR operates within a trusted domain. Traffic MUST be filtered at the domain boundaries.
デフォルトでは、SRは信頼されたドメイン内で動作します。トラフィックはドメイン境界でフィルタリングする必要があります。
The use of best practices to reduce the risk of tampering within the trusted domain is important. Such practices are discussed in [RFC4381] and are applicable to both SR-MPLS and SRv6.
信頼できるドメイン内での改ざんのリスクを減らすためのベストプラクティスの使用は重要です。このようなプラクティスは[RFC4381]で説明されており、SR-MPLSとSRv6の両方に適用できます。
When applied to the MPLS data plane, SR does not introduce any new behavior or any change in the way the MPLS data plane works. Therefore, from a security standpoint, this document does not define any additional mechanism in the MPLS data plane.
SRは、MPLSデータプレーンに適用されると、MPLSデータプレーンの動作に新しい動作や変更を導入しません。したがって、セキュリティの観点から、このドキュメントではMPLSデータプレーンに追加のメカニズムを定義していません。
SR allows the expression of a source-routed path using a single segment (the Binding SID). Compared to RSVP-TE, which also provides explicit routing capability, there are no fundamental differences in terms of information provided. Both RSVP-TE and Segment Routing may express a source-routed path using a single segment.
SRでは、単一のセグメント（バインディングSID）を使用してソースルートパスを表現できます。明示的なルーティング機能も提供するRSVP-TEと比較すると、提供される情報に関して基本的な違いはありません。 RSVP-TEとセグメントルーティングの両方で、単一のセグメントを使用してソースルートパスを表現できます。
When a path is expressed using a single label, the syntax of the metadata is equivalent between RSVP-TE [RFC3209] and SR.
パスが単一のラベルを使用して表現される場合、メタデータの構文はRSVP-TE [RFC3209]とSRの間で同等です。
When a source-routed path is expressed with a list of segments, additional metadata is added to the packet consisting of the source-routed path the packet must follow expressed as a segment list.
ソースルートパスがセグメントのリストで表現されると、パケットがセグメントリストとして表現されるソースルートパスで構成されるパケットに追加のメタデータが追加されます。
When a path is expressed using a label stack, if one has access to the meaning (i.e., the Forwarding Equivalence Class) of the labels, one has the knowledge of the explicit path. For the MPLS data plane, as no data-plane modification is required, there is no fundamental change of capability. Yet, the occurrence of label stacking will increase.
パスがラベルスタックを使用して表現されている場合、ラベルの意味（つまり、転送等価クラス）にアクセスできれば、明示的なパスを知っていることになります。 MPLSデータプレーンの場合、データプレーンの変更は必要ないため、機能の基本的な変更はありません。しかし、ラベルスタッキングの発生は増加します。
SR domain boundary routers MUST filter any external traffic destined to a label associated with a segment within the trusted domain. This includes labels within the SRGB of the trusted domain, labels within the SRLB of the specific boundary router, and labels outside either of these blocks. External traffic is any traffic received from an interface connected to a node outside the domain of trust.
SRドメイン境界ルーターは、信頼されたドメイン内のセグメントに関連付けられたラベルを宛先とするすべての外部トラフィックをフィルタリングする必要があります。これには、信頼されたドメインのSRGB内のラベル、特定の境界ルーターのSRLB内のラベル、およびこれらのブロックの外側のラベルが含まれます。外部トラフィックとは、信頼ドメイン外のノードに接続されたインターフェースから受信したトラフィックです。
From a network protection standpoint, there is an assumed trust model such that any node imposing a label stack on a packet is assumed to be allowed to do so. This is a significant change compared to plain IP offering shortest path routing, but it is not fundamentally different compared to existing techniques providing explicit routing capability such as RSVP-TE. By default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain. Segment Routing extensions that have been defined in various protocols, leverage the security mechanisms of these protocols such as encryption, authentication, filtering, etc.
ネットワーク保護の観点から、パケットにラベルスタックを課すすべてのノードが許可されていると想定されるような、信頼モデルが想定されています。これは、最短パスルーティングを提供するプレーンIPと比較して大幅な変更ですが、RSVP-TEなどの明示的なルーティング機能を提供する既存の技術とは根本的には変わりません。デフォルトでは、明示的なルーティング情報が管理対象ドメインの境界を越えて漏洩してはなりません（MUST NOT）。さまざまなプロトコルで定義されているセグメントルーティング拡張機能は、暗号化、認証、フィルタリングなど、これらのプロトコルのセキュリティメカニズムを活用します。
In the general case, a segment-routing-capable router accepts and installs labels only if the labels have been previously advertised by a trusted source. The received information is validated using existing control-plane protocols providing authentication and security mechanisms. Segment Routing does not define any additional security mechanism in existing control-plane protocols.
一般的なケースでは、セグメントルーティング対応ルーターは、ラベルが信頼できるソースから以前にアドバタイズされている場合にのみ、ラベルを受け入れてインストールします。受信した情報は、認証およびセキュリティメカニズムを提供する既存のコントロールプレーンプロトコルを使用して検証されます。セグメントルーティングは、既存のコントロールプレーンプロトコルに追加のセキュリティメカニズムを定義しません。
SR does not introduce signaling between the source and the midpoints of a source-routed path. With SR, the source-routed path is computed using SIDs previously advertised in the IP control plane. Therefore, in addition to filtering and controlled advertisement of SIDs at the boundaries of the SR domain, filtering in the data plane is also required. Filtering MUST be performed on the forwarding plane at the boundaries of the SR domain and may require looking at multiple labels/instructions.
SRは、ソースとソースルートパスの中間点との間にシグナリングを導入しません。 SRでは、ソースルートパスは、IPコントロールプレーンで以前にアドバタイズされたSIDを使用して計算されます。したがって、SRドメインの境界でのSIDのフィルタリングと制御されたアドバタイズに加えて、データプレーンでのフィルタリングも必要です。フィルタリングは、SRドメインの境界の転送プレーンで実行する必要があり、複数のラベル/命令を確認する必要がある場合があります。
For the MPLS data plane, there are no new requirements as the existing MPLS architecture already allows such source routing by stacking multiple labels. And, for security protection, [RFC4381] and [RFC5920] already call for the filtering of MPLS packets on trust boundaries.
MPLSデータプレーンの場合、既存のMPLSアーキテクチャではすでに複数のラベルをスタックすることでこのようなソースルーティングが可能であるため、新しい要件はありません。そして、セキュリティ保護のために、[RFC4381]と[RFC5920]はすでに信頼境界でMPLSパケットのフィルタリングを要求しています。
When applied to the IPv6 data plane, Segment Routing does introduce the Segment Routing Header (SRH, [IPv6-SRH]) which is a type of Routing Extension header as defined in [RFC8200].
IPv6データプレーンに適用した場合、セグメントルーティングは、[RFC8200]で定義されているルーティング拡張ヘッダーの一種であるセグメントルーティングヘッダー（SRH、[IPv6-SRH]）を導入します。
The SRH adds some metadata to the IPv6 packet, with the list of forwarding path elements (e.g., nodes, links, services, etc.) that the packet must traverse and that are represented by IPv6 addresses. A complete source-routed path may be encoded in the packet using a single segment (single IPv6 address).
SRHは、パケットが通過する必要があり、IPv6アドレスで表される転送パス要素（ノード、リンク、サービスなど）のリストとともに、一部のメタデータをIPv6パケットに追加します。完全なソースルートパスは、単一のセグメント（単一のIPv6アドレス）を使用してパケットにエンコードできます。
SR domain boundary routers MUST filter any external traffic destined to an address within the SRGB of the trusted domain or the SRLB of the specific boundary router. External traffic is any traffic received from an interface connected to a node outside the domain of trust.
SRドメイン境界ルーターは、信頼されたドメインのSRGBまたは特定の境界ルーターのSRLB内のアドレスを宛先とする外部トラフィックをフィルタリングする必要があります。外部トラフィックとは、信頼ドメイン外のノードに接続されたインターフェースから受信したトラフィックです。
From a network-protection standpoint, there is an assumed trust model such that any node adding an SRH to the packet is assumed to be allowed to do so. Therefore, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain. Segment Routing extensions that have been defined in various protocols, leverage the security mechanisms of these protocols such as encryption, authentication, filtering, etc.
ネットワーク保護の観点からは、SRHをパケットに追加するノードは許可されていると想定されるという、信頼モデルが想定されています。したがって、デフォルトでは、明示的なルーティング情報が管理対象ドメインの境界を介して漏洩してはなりません（MUST NOT）。さまざまなプロトコルで定義されているセグメントルーティング拡張機能は、暗号化、認証、フィルタリングなど、これらのプロトコルのセキュリティメカニズムを活用します。
In the general case, an SRv6 router accepts and install segments identifiers (in the form of IPv6 addresses), only if these SIDs are advertised by a trusted source. The received information is validated using existing control-plane protocols providing authentication and security mechanisms. Segment Routing does not define any additional security mechanism in existing control-plane protocols.
一般的な場合、SRv6ルーターは、これらのSIDが信頼できるソースによってアドバタイズされた場合にのみ、セグメント識別子（IPv6アドレスの形式）を受け入れてインストールします。受信した情報は、認証およびセキュリティメカニズムを提供する既存のコントロールプレーンプロトコルを使用して検証されます。セグメントルーティングは、既存のコントロールプレーンプロトコルに追加のセキュリティメカニズムを定義しません。
Problems that may arise when the above behaviors are not implemented or when the assumed trust model is violated (e.g., through a security breach) include:
上記の動作が実装されていない場合、または想定される信頼モデルに違反した場合（セキュリティ違反など）に発生する可能性のある問題には、次のようなものがあります。
o Malicious looping
o 悪意のあるループ
o Evasion of access controls
o アクセス制御の回避
o Hiding the source of DoS attacks
o DoS攻撃のソースを隠す
Security concerns with SR at the IPv6 data plane are more completely discussed in [RFC5095]. The new IPv6-based Segment Routing Header is defined in [IPv6-SRH]. This document also discusses the above security concerns.
IPv6データプレーンでのSRに関するセキュリティの問題は、[RFC5095]でより完全に説明されています。新しいIPv6ベースのセグメントルーティングヘッダーは、[IPv6-SRH]で定義されています。このドキュメントでは、上記のセキュリティ上の問題についても説明しています。
SR does not introduce new requirements for congestion control. By default, traffic delivery is assumed to be best effort. Congestion control may be implemented at endpoints. Where SR policies are in use, bandwidth allocation may be managed by monitoring incoming traffic associated with the binding SID identifying the SR Policy. Other solutions such as presented in [RFC8084] may be applicable.
SRでは、輻輳制御の新しい要件は導入されていません。デフォルトでは、トラフィック配信はベストエフォートであると想定されています。輻輳制御はエンドポイントで実装できます。 SRポリシーが使用されている場合、SRポリシーを識別するバインディングSIDに関連付けられた着信トラフィックを監視することにより、帯域幅の割り当てを管理できます。 [RFC8084]に示されているような他のソリューションが適用できる場合があります。
In SR-enabled networks, the path the packet takes is encoded in the header. As the path is not signaled through a protocol, OAM mechanisms are necessary in order for the network operator to validate the effectiveness of a path as well as to check and monitor its liveness and performance. However, it has to be noted that SR allows to reduce substantially the number of states in transit nodes; hence, the number of elements that a transit node has to manage is smaller.
SR対応のネットワークでは、パケットがたどるパスはヘッダーにエンコードされます。パスはプロトコルを介して通知されないため、ネットワークオペレーターがパスの有効性を検証し、その生存性とパフォーマンスを確認および監視するには、OAMメカニズムが必要です。ただし、SRを使用すると、通過ノードの状態の数を大幅に減らすことができることに注意してください。したがって、トランジットノードが管理する必要がある要素の数は少なくなります。
SR OAM use cases for the MPLS data plane are defined in [RFC8403]. SR OAM procedures for the MPLS data plane are defined in [RFC8287].
MPLSデータプレーンのSR OAMの使用例は、[RFC8403]で定義されています。 MPLSデータプレーンのSR OAM手順は、[RFC8287]で定義されています。
SR routers receive advertisements of SIDs (index, label, or IPv6 address) from the different routing protocols being extended for SR. Each of these protocols have monitoring and troubleshooting mechanisms to provide operation and management functions for IP addresses that must be extended in order to include troubleshooting and monitoring functions of the SID.
SRルーターは、SR用に拡張されているさまざまなルーティングプロトコルからSID（インデックス、ラベル、またはIPv6アドレス）の通知を受け取ります。これらの各プロトコルには、SIDのトラブルシューティングおよび監視機能を含めるために拡張する必要があるIPアドレスの操作および管理機能を提供するための監視およびトラブルシューティングメカニズムがあります。
SR architecture introduces the usage of global segments. Each global segment MUST be bound to a unique index or address within an SR domain. The management of the allocation of such an index or address by the operator is critical for the network behavior to avoid situations like misrouting. In addition to the allocation policy/ tooling that the operator will have in place, an implementation SHOULD protect the network in case of conflict detection by providing a deterministic resolution approach.
SRアーキテクチャでは、グローバルセグメントの使用法が導入されています。各グローバルセグメントは、SRドメイン内の一意のインデックスまたはアドレスにバインドする必要があります。オペレーターによるこのようなインデックスまたはアドレスの割り当ての管理は、ルーティングミスなどの状況を回避するためのネットワークの動作にとって重要です。オペレーターが配置する割り当てポリシー/ツールに加えて、実装は、決定論的解決アプローチを提供することにより、競合検出の場合にネットワークを保護する必要があります（SHOULD）。
When a path is expressed using a label stack, the occurrence of label stacking will increase. A node may want to signal, in the control plane, its ability in terms of size of the label stack it can support.
ラベルスタックを使用してパスを表現すると、ラベルスタックの発生が増加します。ノードは、サポートできるラベルスタックのサイズの観点から、コントロールプレーンでその能力を通知する場合があります。
A YANG data model [RFC6020] for SR configuration and operations has been defined in [SR-YANG].
SRの構成と操作のためのYANGデータモデル[RFC6020]は、[SR-YANG]で定義されています。
When SR is applied to the IPv6 data plane, segments are identified through IPv6 addresses. The allocation, management, and troubleshooting of segment identifiers is no different than the existing mechanisms applied to the allocation and management of IPv6 addresses.
SRがIPv6データプレーンに適用されると、セグメントはIPv6アドレスを通じて識別されます。セグメント識別子の割り当て、管理、トラブルシューティングは、IPv6アドレスの割り当てと管理に適用される既存のメカニズムと同じです。
The DA of the packet gives the active segment address. The segment list in the SRH gives the entire path of the packet. The validation of the source-routed path is done through inspection of DA and SRH present in the packet header matched to the equivalent routing table entries.
パケットのDAは、アクティブセグメントアドレスを示します。 SRHのセグメントリストは、パケットのパス全体を示します。ソースルートパスの検証は、同等のルーティングテーブルエントリに一致するパケットヘッダーに存在するDAおよびSRHの検査を通じて行われます。
In the context of the SRv6 data plane, the source-routed path is encoded in the SRH as described in [IPv6-SRH]. The SRv6 source-routed path is instantiated into the SRH as a list of IPv6 addresses where the active segment is in the DA field of the IPv6 packet header. Typically, by inspecting, in any node, the packet header, it is possible to derive the source-routed path to which it belongs. Similar to the context of the SR-MPLS data plane, an implementation may originate path control and monitoring packets where the source-routed path is inserted in the SRH and where each segment of the path inserts in the packet the relevant data in order to measure the end-to-end path and performance.
SRv6データプレーンのコンテキストでは、[IPv6-SRH]で説明されているように、ソースルートパスはSRHでエンコードされます。 SRv6ソースルートパスは、アクティブセグメントがIPv6パケットヘッダーのDAフィールドにあるIPv6アドレスのリストとしてSRHにインスタンス化されます。通常、任意のノードでパケットヘッダーを検査することにより、パケットヘッダーが属するソースルートパスを導出できます。 SR-MPLSデータプレーンのコンテキストと同様に、実装では、ソース制御パスがSRHに挿入され、パスの各セグメントが関連データをパケットに挿入して測定するために、パス制御パケットと監視パケットを発信できます。エンドツーエンドのパスとパフォーマンス。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[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>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[BGPLS-SR-EPE] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", Work in Progress, draft-ietf-idr-bgpls-segment-routing-epe-15, March 2018.
[BGPLS-SR-EPE] Previdi、S.、Filsfils、C.、Patel、K.、Ray、S。、およびJ. Dong、「BGP-LS extensions for Segment Routing BGP Egress Peer Engineering」、Work in Progress、 draft-ietf-idr-bgpls-segment-routing-epe-15、2018年3月。
[IPv6-SRH] Filsfils, C., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, Ed., "IPv6 Segment Routing Header (SRH)", Work in Progress, draft-ietf-6man-segment-routing-header-14, June 2018.
[IPv6-SRH] Filsfils、C.、Ed。、Previdi、S.、Leddy、J.、Matsushima、S.、and D. Voyer、Ed。、 "IPv6 Segment Routing Header（SRH）"、Work in Progress、 draft-ietf-6man-segment-routing-header-14、2018年6月。
[ISIS-SR-EXT] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", Work in Progress, draft-ietf-isis-segment-routing-extensions-19, July 2018.
[ISIS-SR-EXT] Previdi、S.、Ed。、Ginsberg、L.、Ed。、Filsfils、C.、Bashandy、A.、Gredler、H.、Litkowski、S.、Decraene、B.、J 。Tantsura、「IS-IS Extensions for Segment Routing」、Work in Progress、draft-ietf-isis-segment-routing-extensions-19、2018年7月。
[OSPF-SR-EXT] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-segment-routing-extensions-25, April 2018.
[OSPF-SR-EXT] Psenak、P.、Previdi、S.、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W。、およびJ. Tantsura、「OSPF Extensions for Segment Routing」、 Work in Progress、draft-ietf-ospf-segment-routing-extensions-25、2018年4月。
[OSPFv3-SR-EXT] Psenak, P., Ed., Filsfils, C., Previdi, S., Ed., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-ospfv3-segment-routing-extensions-13, May 2018.
[OSPFv3-SR-EXT] Psenak、P。、編、Filsfils、C.、Previdi、S。、編、Gredler、H.、Shakir、R.、Henderickx、W.、J。Tantsura、「OSPFv3 Extensions for Segment Routing」、Work in Progress、draft-ietf-ospf-ospfv3-segment-routing-extensions-13、2018年5月。
[PCEP-SR-EXT] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", Work in Progress, draft-ietf-pce-segment-routing-12, June 2018.
[PCEP-SR-EXT] Sivabalan、S.、Filsfils、C.、Tantsura、J.、Henderickx、W.、J. Hardwick、 "PCEP Extensions for Segment Routing"、Work in Progress、draft-ietf-pce- segment-routing-12、2018年6月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.
[RFC4206] Kompella、K。およびY. Rekhter、「Label Switched Paths（LSP）Hierarchy with Generalized Multi-Protocol Label Switching（GMPLS）Traffic Engineering（TE）」、RFC 4206、DOI 10.17487 / RFC4206、2005年10月、<https ：//www.rfc-editor.org/info/rfc4206>。
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006, <https://www.rfc-editor.org/info/rfc4381>.
[RFC4381] Behringer、M。、「Analysis of the Security of BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4381、DOI 10.17487 / RFC4381、2006年2月、<https://www.rfc-editor.org/ info / rfc4381>。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.
[RFC4915] Psenak、P.、Mirtorabi、S.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「OSPFでのマルチトポロジ（MT）ルーティング」、RFC 4915、DOI 10.17487 / RFC4915、 2007年6月、<https://www.rfc-editor.org/info/rfc4915>。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.
[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、DOI 10.17487 / RFC5095、2007年12月、<https：//www.rfc -editor.org/info/rfc5095>。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、DOI 10.17487 / RFC5120、 2008年2月、<https://www.rfc-editor.org/info/rfc5120>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.
[RFC5714] Shand、M。およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、DOI 10.17487 / RFC5714、2010年1月、<https://www.rfc-editor.org/info/rfc5714>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-editor。 org / info / rfc6020>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, <https://www.rfc-editor.org/info/rfc6549>.
[RFC6549] Lindem、A.、Roy、A。、およびS. Mirtorabi、「OSPFv2 Multi-Instance Extensions」、RFC 6549、DOI 10.17487 / RFC6549、2012年3月、<https://www.rfc-editor.org/ info / rfc6549>。
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, <https://www.rfc-editor.org/info/rfc7938>.
[RFC7938] Lapukhov、P.、Premji、A。、およびJ. Mitchell、編、「大規模データセンターでのルーティングのためのBGPの使用」、RFC 7938、DOI 10.17487 / RFC7938、2016年8月、<https：/ /www.rfc-editor.org/info/rfc7938>。
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.
[RFC8084] Fairhurst、G。、「Network Transport Circuit Breakers」、BCP 208、RFC 8084、DOI 10.17487 / RFC8084、2017年3月、<https://www.rfc-editor.org/info/rfc8084>。
[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017, <https://www.rfc-editor.org/info/rfc8202>.
[RFC8202] Ginsberg、L.、Previdi、S。、およびW. Henderickx、「IS-IS Multi-Instance」、RFC 8202、DOI 10.17487 / RFC8202、2017年6月、<https://www.rfc-editor.org / info / rfc8202>。
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, <https://www.rfc-editor.org/info/rfc8287>.
[RFC8287] Kumar、N.、Ed。、Pignataro、C.、Ed。、Swallow、G.、Akiya、N.、Kini、S.、and M. Chen、 "Label Switched Path（LSP）Ping / Traceroute for Segment Routing（SR）IGP-Prefix and IGP-Adjacency Segment Identifiers（SIDs with MPLS Data Planes）」、RFC 8287、DOI 10.17487 / RFC8287、2017年12月、<https://www.rfc-editor.org/info/rfc8287 >。
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, <https://www.rfc-editor.org/info/rfc8355>.
[RFC8355] Filsfils、C.、Ed。、Previdi、S.、Ed。、Decraene、B.、and R. Shakir、 "Resiliency Use Cases in Source Packet Routing in Networking（SPRING）Networks"、RFC 8355、DOI 10.17487 / RFC8355、2018年3月、<https://www.rfc-editor.org/info/rfc8355>。
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 2018, <http://www.rfc-editor.org/info/rfc8403>.
[RFC8403] Geib、R.、Ed。、Filsfils、C.、Pignataro、C.、Ed。、and N. Kumar、 "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System"、RFC 8403、DOI 10.17487 / RFC8403、2018年7月、<http://www.rfc-editor.org/info/rfc8403>。
[SR-CENTRAL-EPE] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", Work in Progress, draft-ietf-spring-segment-routing-central-epe-10, December 2017.
[SR-CENTRAL-EPE] Filsfils、C.、Previdi、S.、Dawra、G.、Aries、E。、およびD. Afanasiev、「Segment Routing Centralized BGP Egress Peer Engineering」、Work in Progress、draft-ietf- spring-segment-routing-central-epe-10、2017年12月。
[SR-MPLS] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-14, June 2018.
[SR-MPLS] Bashandy、A。、編、Filsfils、C。、編、Previdi、S.、Decraene、B.、Litkowski、S。、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、 Work in Progress、draft-ietf-spring-segment-routing-mpls-14、2018年6月。
[SR-YANG] Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", Work in Progress, draft-ietf-spring-sr-yang-09, June 2018.
[SR-YANG] Litkowski、S.、Qu、Y.、Sarkar、P。、およびJ. Tantsura、「セグメントルーティングのYANGデータモデル」、Work in Progress、draft-ietf-spring-sr-yang-09、 2018年6月。
Acknowledgements
謝辞
We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart Bryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, Hannes Gredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers, and Alvaro Retana for their comments and review of this document.
このドキュメントのコメントとレビューについて、Dave Ward、Peter Psenak、Dan Frost、Stewart Bryant、Pierre Francois、Thomas Telkamp、Ruediger Geib、Hannes Gredler、Pushpasis Sarkar、Eric Rosen、およびAlvaro Retanaに感謝します。
Contributors
貢献者
The following people have substantially contributed to the definition of the Segment Routing architecture and to the editing of this document:
以下の人々は、セグメントルーティングアーキテクチャの定義とこのドキュメントの編集に大きく貢献しています。
Ahmed Bashandy Cisco Systems, Inc. Email: bashandy@cisco.com
Ahmed Bashandy Cisco Systems、Inc.メール：bashandy@cisco.com
Martin Horneffer Deutsche Telekom Email: Martin.Horneffer@telekom.de
Martin Horneffer Deutsche Telekomメール：Martin.Horneffer@telekom.de
Wim Henderickx Nokia Email: wim.henderickx@nokia.com
Wim Henderickx Nokiaメール：wim.henderickx@nokia.com
Jeff Tantsura Email: jefftant@gmail.com
Jeff Tantsuraメール：jefftant@gmail.com
Edward Crabbe Email: edward.crabbe@gmail.com
Edward Crabbeメール：edward.crabbe@gmail.com
Igor Milojevic Email: milojevicigor@gmail.com
Igor Milojevic Eメール：milojevicigor@gmail.com
Saku Ytti TDC Email: saku@ytti.fi
Saku Ytti TDCメール：saku@ytti.fi
Authors' Addresses
著者のアドレス
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（editor）Cisco Systems、Inc. Brussels Belgium
Email: cfilsfil@cisco.com
Stefano Previdi (editor) Cisco Systems, Inc. Italy
Stefano Previdi（編集者）Cisco Systems、Inc.イタリア
Email: stefano@previdi.net
Les Ginsberg Cisco Systems, Inc.
Les Ginsberg Cisco Systems、Inc.
Email: ginsberg@cisco.com
Bruno Decraene Orange FR
ブルーノデクレイネオレンジFR
Email: bruno.decraene@orange.com
Stephane Litkowski Orange France
ステファンリトコウスキーオレンジフランス
Email: stephane.litkowski@orange.com
Rob Shakir Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Rob Shakir Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: robjs@google.com