[要約] RFC 8660は、MPLSデータプレーンを使用したセグメントルーティングに関する仕様です。このRFCの目的は、セグメントルーティングの機能と特徴を説明し、MPLSネットワークでの実装を促進することです。
Internet Engineering Task Force (IETF) A. Bashandy, Ed.
Request for Comments: 8660 Arrcus
Category: Standards Track C. Filsfils, Ed.
ISSN: 2070-1721 S. Previdi
Cisco Systems, Inc.
B. Decraene
S. Litkowski
Orange
R. Shakir
Google
December 2019
Segment Routing with the MPLS Data Plane
MPLSデータプレーンによるセグメントルーティング
Abstract
概要
Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).
セグメントルーティング（SR）は、ソースルーティングパラダイムを活用します。ノードは、パケットの先頭にSRヘッダーを付加することにより、セグメントと呼ばれる制御された命令セットを通じてパケットを操作します。 MPLSデータプレーンでは、SRヘッダーはラベルスタックを通じてインスタンス化されます。このドキュメントでは、MPLSデータプレーン（SR-MPLS）を介してSRをインスタンス化できる転送動作を指定します。
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/rfc8660.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8660で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. MPLS Instantiation of Segment Routing
2.1. Multiple Forwarding Behaviors for the Same Prefix
2.2. SID Representation in the MPLS Forwarding Plane
2.3. Segment Routing Global Block and Local Block
2.4. Mapping a SID Index to an MPLS Label
2.5. Incoming Label Collision
2.5.1. Tiebreaking Rules
2.5.2. Redistribution between Routing Protocol Instances
2.6. Effect of Incoming Label Collision on Outgoing Label
Programming
2.7. PUSH, CONTINUE, and NEXT
2.7.1. PUSH
2.7.2. CONTINUE
2.7.3. NEXT
2.8. MPLS Label Downloaded to the FIB for Global and Local SIDs
2.9. Active Segment
2.10. Forwarding Behavior for Global SIDs
2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs
2.10.2. Forwarding for the NEXT Operation for Global SIDs
2.11. Forwarding Behavior for Local SIDs
2.11.1. Forwarding for the PUSH Operation on Local SIDs
2.11.2. Forwarding for the CONTINUE Operation for Local SIDs
2.11.3. Outgoing Label for the NEXT Operation for Local SIDs
3. IANA Considerations
4. Manageability Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Examples
A.1. IGP Segment Examples
A.2. Incoming Label Collision Examples
A.2.1. Example 1
A.2.2. Example 2
A.2.3. Example 3
A.2.4. Example 4
A.2.5. Example 5
A.2.6. Example 6
A.2.7. Example 7
A.2.8. Example 8
A.2.9. Example 9
A.2.10. Example 10
A.2.11. Example 11
A.2.12. Example 12
A.2.13. Example 13
A.2.14. Example 14
A.3. Examples for the Effect of Incoming Label Collision on an
Outgoing Label
A.3.1. Example 1
A.3.2. Example 2
Acknowledgements
Contributors
Authors' Addresses
The Segment Routing architecture [RFC8402] can be directly applied to the MPLS architecture with no change in the MPLS forwarding plane. This document specifies forwarding-plane behavior to allow Segment Routing to operate on top of the MPLS data plane (SR-MPLS). This document does not address control-plane behavior. Control-plane behavior is specified in other documents such as [RFC8665], [RFC8666], and [RFC8667].
セグメントルーティングアーキテクチャ[RFC8402]は、MPLSフォワーディングプレーンを変更せずに、MPLSアーキテクチャに直接適用できます。このドキュメントでは、セグメントルーティングがMPLSデータプレーン（SR-MPLS）上で動作できるようにする転送プレーンの動作を指定しています。このドキュメントでは、コントロールプレーンの動作については扱いません。コントロールプレーンの動作は、[RFC8665]、[RFC8666]、[RFC8667]などの他のドキュメントで指定されています。
The Segment Routing problem statement is described in [RFC7855].
セグメントルーティング問題ステートメントは、[RFC7855]で説明されています。
Coexistence of SR over the MPLS forwarding plane with LDP [RFC5036] is specified in [RFC8661].
MPLSフォワーディングプレーン上のSRとLDP [RFC5036]の共存は、[RFC8661]で指定されています。
Policy routing and traffic engineering using Segment Routing can be found in [ROUTING-POLICY].
セグメントルーティングを使用したポリシールーティングとトラフィックエンジニアリングは、[ROUTING-POLICY]にあります。
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]で説明されているように解釈されます。
MPLS instantiation of Segment Routing fits in the MPLS architecture as defined in [RFC3031] from both a control-plane and forwarding-plane perspective:
セグメントルーティングのMPLSインスタンス化は、コントロールプレーンとフォワーディングプレーンの両方の観点から、[RFC3031]で定義されているMPLSアーキテクチャに適合します。
* From a control-plane perspective, [RFC3031] does not mandate a single signaling protocol. Segment Routing makes use of various control-plane protocols such as link-state IGPs [RFC8665] [RFC8666] [RFC8667]. The flooding mechanisms of link-state IGPs fit very well with label stacking on the ingress. A future control-layer protocol and/or policy/configuration can be used to specify the label stack.
* コントロールプレーンの観点から、[RFC3031]は単一のシグナリングプロトコルを義務付けていません。セグメントルーティングは、リンクステートIGP [RFC8665] [RFC8666] [RFC8667]などのさまざまなコントロールプレーンプロトコルを利用します。リンクステートIGPのフラッディングメカニズムは、入力でのラベルスタッキングと非常によく適合します。将来の制御層プロトコルおよび/またはポリシー/構成を使用して、ラベルスタックを指定できます。
* From a forwarding-plane perspective, Segment Routing does not require any change to the forwarding plane because Segment IDs (SIDs) are instantiated as MPLS labels, and the Segment Routing header is instantiated as a stack of MPLS labels.
* フォワーディングプレーンの観点から見ると、セグメントID（SID）はMPLSラベルとしてインスタンス化され、セグメントルーティングヘッダーはMPLSラベルのスタックとしてインスタンス化されるため、セグメントルーティングではフォワーディングプレーンを変更する必要はありません。
We call the "MPLS Control Plane Client (MCC)" any control-plane entity installing forwarding entries in the MPLS data plane. Local configuration and policies applied on a router are examples of MCCs.
「MPLSコントロールプレーンクライアント（MCC）」を、MPLSデータプレーンに転送エントリをインストールするコントロールプレーンエンティティと呼びます。ルータに適用されるローカル設定とポリシーは、MCCの例です。
In order to have a node segment reach the node, a network operator SHOULD configure at least one node segment per routing instance, topology, or algorithm. Otherwise, the node is not reachable within the routing instance, within the topology, or along the routing algorithm, which restricts its ability to be used by an SR Policy and as a Topology Independent Loop-Free Alternate (TI-LFA).
ノードセグメントをノードに到達させるには、ネットワークオペレーターは、ルーティングインスタンス、トポロジ、またはアルゴリズムごとに少なくとも1つのノードセグメントを構成する必要があります（SHOULD）。それ以外の場合、ルーティングインスタンス内、トポロジ内、またはルーティングアルゴリズムに沿ってノードに到達できません。そのため、SRポリシーによる、およびトポロジに依存しないループフリー代替（TI-LFA）としての使用が制限されます。
The SR architecture does not prohibit having more than one SID for the same prefix. In fact, by allowing multiple SIDs for the same prefix, it is possible to have different forwarding behaviors (such as different paths, different ECMP and Unequal-Cost Multipath (UCMP) behaviors, etc.) for the same destination.
SRアーキテクチャでは、同じプレフィックスに対して複数のSIDを持つことを禁止していません。実際、同じプレフィックスに対して複数のSIDを許可することにより、同じ宛先に対して異なる転送動作（異なるパス、異なるECMPおよび不等コストマルチパス（UCMP）動作など）を使用することができます。
Instantiating Segment Routing over the MPLS forwarding plane fits seamlessly with this principle. An operator may assign multiple MPLS labels or indices to the same prefix and assign different forwarding behaviors to each label/SID. The MCC in the network downloads different MPLS labels/SIDs to the FIB for different forwarding behaviors. The MCC at the entry of an SR domain or at any point in the domain can choose to apply a particular forwarding behavior to a particular packet by applying the PUSH action to that packet using the corresponding SID.
MPLSフォワーディングプレーンを介したセグメントルーティングのインスタンス化は、この原則にシームレスに適合します。オペレータは、同じプレフィックスに複数のMPLSラベルまたはインデックスを割り当て、各ラベル/ SIDに異なる転送動作を割り当てることができます。ネットワーク内のMCCは、さまざまな転送動作のために、さまざまなMPLSラベル/ SIDをFIBにダウンロードします。 SRドメインのエントリまたはドメイン内の任意のポイントにあるMCCは、対応するSIDを使用してそのパケットにPUSHアクションを適用することにより、特定の転送動作を特定のパケットに適用することを選択できます。
When instantiating SR over the MPLS forwarding plane, a SID is represented by an MPLS label or an index [RFC8402].
MPLSフォワーディングプレーンを介してSRをインスタンス化する場合、SIDはMPLSラベルまたはインデックス[RFC8402]で表されます。
A global SID is a label, or an index that may be mapped to an MPLS label within the Segment Routing Global Block (SRGB), of the node that installs a global SID in its FIB and receives the labeled packet. Section 2.4 specifies the procedure to map a global segment represented by an index to an MPLS label within the SRGB.
グローバルSIDは、FIBにグローバルSIDをインストールし、ラベル付きパケットを受信するノードのラベル、またはセグメントルーティンググローバルブロック（SRGB）内のMPLSラベルにマップできるインデックスです。セクション2.4では、インデックスで表されるグローバルセグメントをSRGB内のMPLSラベルにマップする手順を指定しています。
The MCC MUST ensure that any label value corresponding to any SID it installs in the forwarding plane follows the rules below:
MCCは、フォワーディングプレーンにインストールするSIDに対応するラベル値が、以下のルールに従っていることを確認する必要があります。
* The label value MUST be unique within the router on which the MCC is running, i.e., the label MUST only be used to represent the SID and MUST NOT be used to represent more than one SID or for any other forwarding purpose on the router.
* ラベル値は、MCCが実行されているルーター内で一意である必要があります。つまり、ラベルは、SIDを表すためにのみ使用しなければならず、複数のSIDを表すため、またはルーター上の他の転送目的のために使用してはなりません。
* The label value MUST NOT come from the range of special-purpose labels [RFC7274].
* ラベル値は、特別な目的のラベルの範囲から来てはなりません[RFC7274]。
Labels allocated in this document are considered per-platform downstream allocated labels [RFC3031].
このドキュメントで割り当てられたラベルは、プラットフォームごとのダウンストリーム割り当てラベル[RFC3031]と見なされます。
The concepts of SRGB and global SID are explained in [RFC8402]. In general, the SRGB need not be a contiguous range of labels.
SRGBとグローバルSIDの概念は[RFC8402]で説明されています。一般に、SRGBはラベルの連続した範囲である必要はありません。
For the rest of this document, the SRGB is specified by the list of MPLS label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] where Ll(i) =< Lh(i).
このドキュメントの残りの部分では、SRGBはMPLSラベル範囲のリスト[Ll（1）、Lh（1）]、[Ll（2）、Lh（2）]、...、[Ll（k ）、Lh（k）]ここで、Ll（i）= <Lh（i）。
The following rules apply to the list of MPLS ranges representing the SRGB:
SRGBを表すMPLS範囲のリストには、次の規則が適用されます。
* The list of ranges comprising the SRGB MUST NOT overlap.
* SRGBを構成する範囲のリストは重複してはなりません。
* Every range in the list of ranges specifying the SRGB MUST NOT cover or overlap with a reserved label value or range [RFC7274], respectively.
* SRGBを指定する範囲のリストのすべての範囲は、それぞれ予約済みのラベル値または範囲[RFC7274]をカバーまたはオーバーラップしてはならない[MUST NOT]。
* If the SRGB of a node does not conform to the structure specified in this section or to the previous two rules, the SRGB MUST be completely ignored by all routers in the routing domain, and the node MUST be treated as if it does not have an SRGB.
* ノードのSRGBがこのセクションで指定された構造または前の2つのルールに準拠していない場合、SRGBはルーティングドメイン内のすべてのルーターによって完全に無視されなければならず（MUST）、ノードはそれがないかのように扱われなければなりません（MUST）。 SRGB。
* The list of label ranges MUST only be used to instantiate global SIDs into the MPLS forwarding plane.
* ラベル範囲のリストは、グローバルSIDをMPLS転送プレーンにインスタンス化するためにのみ使用する必要があります。
A local segment MAY be allocated from the Segment Routing Local Block (SRLB) [RFC8402] or from any unused label as long as it does not use a special-purpose label. The SRLB consists of the range of local labels reserved by the node for certain local segments. In a controller-driven network, some controllers or applications MAY use the control plane to discover the available set of Local SIDs on a particular router [ROUTING-POLICY]. The rules applicable to the SRGB are also applicable to the SRLB, except the SRGB MUST only be used to instantiate global SIDs into the MPLS forwarding plane. The recommended, minimum, or maximum size of the SRGB and/or SRLB is a matter of future study.
ローカルセグメントは、特別な目的のラベルを使用しない限り、Segment Routing Local Block（SRLB）[RFC8402]または未使用のラベルから割り当てることができます。 SRLBは、特定のローカルセグメント用にノードによって予約されたローカルラベルの範囲で構成されます。コントローラー主導のネットワークでは、一部のコントローラーまたはアプリケーションがコントロールプレーンを使用して、特定のルーターで利用可能なローカルSIDのセットを検出する場合があります[ROUTING-POLICY]。 SRGBに適用されるルールはSRLBにも適用されますが、SRGBはグローバルSIDをMPLSフォワーディングプレーンにインスタンス化するためにのみ使用する必要があります。 SRGBまたはSRLB、あるいはその両方の推奨、最小、または最大サイズは、今後の検討事項です。
This subsection specifies how the MPLS label value is calculated given the index of a SID. The value of the index is determined by an MCC such as IS-IS [RFC8667] or OSPF [RFC8665]. This section only specifies how to map the index to an MPLS label. The calculated MPLS label is downloaded to the FIB, sent out with a forwarded packet, or both.
このサブセクションでは、SIDのインデックスが指定された場合のMPLSラベル値の計算方法を指定します。インデックスの値は、IS-IS [RFC8667]やOSPF [RFC8665]などのMCCによって決定されます。このセクションでは、インデックスをMPLSラベルにマップする方法のみを指定します。計算されたMPLSラベルはFIBにダウンロードされるか、転送されたパケットで送信されるか、またはその両方が行われます。
Consider a SID represented by the index "I". Consider an SRGB as specified in Section 2.3. The total size of the SRGB, represented by the variable "Size", is calculated according to the formula:
インデックス「I」で表されるSIDについて考えます。セクション2.3で指定されているSRGBについて考えます。変数「Size」で表されるSRGBの合計サイズは、次の式に従って計算されます。
size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1
The following rules MUST be applied by the MCC when calculating the MPLS label value corresponding to the SID index value "I".
次のルールは、SIDインデックス値「I」に対応するMPLSラベル値を計算するときにMCCによって適用される必要があります。
0 =< I < size. If index "I" does not satisfy the previous inequality, then the label cannot be calculated.
0 = <I <サイズ。インデックス「I」が前の不等式を満たさない場合、ラベルを計算できません。
The label value corresponding to the SID index "I" is calculated as follows:
SIDインデックス「I」に対応するラベル値は、次のように計算されます。
j = 1 , temp = 0
j = 1、temp = 0
While temp + Lh(j)- Ll(j) < I
temp = temp + Lh(j)- Ll(j) + 1
j = j+1
j = j + 1
label = I - temp + Ll(j)
An example for how a router calculates labels and forwards traffic based on the procedure described in this section can be found in Appendix A.1.
このセクションで説明する手順に基づいて、ルーターがラベルを計算してトラフィックを転送する方法の例は、付録A.1にあります。
The MPLS Architecture [RFC3031] defines the term Forwarding Equivalence Class (FEC) as the set of packets with similar and/or identical characteristics that are forwarded the same way and are bound to the same MPLS incoming (local) label. In Segment Routing MPLS, a local label serves as the SID for a given FEC.
MPLSアーキテクチャ[RFC3031]は、同じ方法で転送され、同じMPLS着信（ローカル）ラベルにバインドされる、類似または同一の特性を持つパケットのセットとして転送等価クラス（FEC）という用語を定義します。セグメントルーティングMPLSでは、ローカルラベルが特定のFECのSIDとして機能します。
We define SR FEC [RFC8402] as one of the following:
SR FEC [RFC8402]を次のいずれかとして定義します。
* (Prefix, Routing Instance, Topology, Algorithm) [RFC8402], where a topology identifies a set of links with metrics. For the purpose of incoming label collision resolution, the same Topology numerical value SHOULD be used on all routers to identify the same set of links with metrics. For MCCs where the "Topology" and/or "Algorithm" fields are not defined, the numerical value of zero MUST be used for these two fields. For the purpose of incoming label collision resolution, a routing instance is identified by a single incoming label downloader to the FIB. Two MCCs running on the same router are considered different routing instances if the only way the two instances know about each other's incoming labels is through redistribution. The numerical value used to identify a routing instance MAY be derived from other configuration or MAY be explicitly configured. If it is derived from other configuration, then the same numerical value SHOULD be derived from the same configuration as long as the configuration survives router reload. If the derived numerical value varies for the same configuration, then an implementation SHOULD make the numerical value used to identify a routing instance configurable.
* （プレフィックス、ルーティングインスタンス、トポロジ、アルゴリズム）[RFC8402]。トポロジは、メトリックを持つリンクのセットを識別します。着信ラベルの衝突解決のために、すべてのルーターで同じトポロジー数値を使用して、メトリックを持つ同じリンクのセットを識別する必要があります（SHOULD）。 「トポロジ」または「アルゴリズム」フィールドが定義されていないMCCの場合、これらの2つのフィールドにはゼロの数値を使用する必要があります。着信ラベルの衝突解決のために、ルーティングインスタンスは、FIBへの単一の着信ラベルダウンローダーによって識別されます。同じルーターで実行されている2つのMCCは、2つのインスタンスが互いの着信ラベルを認識する唯一の方法が再配布による場合、異なるルーティングインスタンスと見なされます。ルーティングインスタンスを識別するために使用される数値は、他の構成から導出される場合と、明示的に構成される場合があります。他の構成から派生した場合、構成がルーターのリロードに耐えられる限り、同じ数値が同じ構成から派生する必要があります（SHOULD）。導出された数値が同じ構成で異なる場合、実装は、ルーティングインスタンスの識別に使用される数値を構成可能にする必要があります（SHOULD）。
* (next hop, outgoing interface), where the outgoing interface is physical or virtual.
* （ネクストホップ、発信インターフェイス）、発信インターフェイスは物理または仮想です。
* (number of adjacencies, list of next hops, list of outgoing interfaces IDs in ascending numerical order). This FEC represents parallel adjacencies [RFC8402].
* （隣接の数、ネクストホップのリスト、昇順の発信インターフェースIDのリスト）。このFECは並列隣接を表します[RFC8402]。
* (Endpoint, Color). This FEC represents an SR Policy [RFC8402].
* （エンドポイント、色）。このFECはSRポリシー[RFC8402]を表します。
* (Mirror SID). The Mirror SID (see [RFC8402], Section 5.1) is the IP address advertised by the advertising node to identify the Mirror SID. The IP address is encoded as specified in Section 2.5.1.
* （SIDのミラー）。ミラーSID（[RFC8402]、セクション5.1を参照）は、ミラーSIDを識別するためにアドバタイジングノードによってアドバタイズされるIPアドレスです。 IPアドレスは、セクション2.5.1の指定に従ってエンコードされます。
This section covers the RECOMMENDED procedure for handling the scenario where, because of an error/misconfiguration, more than one SR FEC as defined in this section maps to the same incoming MPLS label. Examples illustrating the behavior specified in this section can be found in Appendix A.2.
このセクションでは、エラー/設定ミスのために、このセクションで定義されている複数のSR FECが同じ着信MPLSラベルにマッピングされるシナリオを処理するための推奨手順について説明します。このセクションで指定された動作を示す例は、付録A.2にあります。
An incoming label collision occurs if the SIDs of the set of FECs {FEC1, FEC2, ..., FECk} map to the same incoming SR MPLS label "L1".
FECのセット{FEC1、FEC2、...、FECk}のSIDが同じ着信SR MPLSラベル「L1」にマッピングされている場合、着信ラベルの衝突が発生します。
Suppose an anycast prefix is advertised with a Prefix-SID by some, but not all, of the nodes that advertise that prefix. If the Prefix-SID sub-TLVs result in mapping that anycast prefix to the same incoming label, then the advertisement of the Prefix-SID by some, but not all, of the advertising nodes MUST NOT be treated as a label collision.
エニーキャストプレフィックスが、そのプレフィックスをアドバタイズするノードのすべてではなく一部によってPrefix-SIDでアドバタイズされているとします。 Prefix-SIDサブTLVがそのエニーキャストプレフィックスを同じ着信ラベルにマッピングする場合、すべてではなく一部のアドバタイズノードによるPrefix-SIDのアドバタイズメントはラベルの衝突として扱われてはなりません（MUST NOT）。
An implementation MUST NOT allow the MCCs belonging to the same router to assign the same incoming label to more than one SR FEC.
実装では、同じルーターに属するMCCが同じ着信ラベルを複数のSR FECに割り当てることを許可してはなりません（MUST NOT）。
The objective of the following steps is to deterministically install in the MPLS Incoming Label Map, also known as label FIB, a single FEC with the incoming label "L1". By "deterministically install", we mean if the set of FECs {FEC1, FEC2,..., FECk} map to the same incoming SR MPLS label "L1", then the steps below assign the same FEC to the label "L1" irrespective of the order by which the mappings of this set of FECs to the label "L1" are received. For example, first-come, first-served tiebreaking is not allowed. The remaining FECs may be installed in the IP FIB without an incoming label.
次の手順の目的は、着信ラベル「L1」を持つ単一のFECであるラベルFIBとしても知られるMPLS着信ラベルマップに確定的にインストールすることです。 「決定的にインストールする」とは、FECのセット{FEC1、FEC2、...、FECk}が同じ着信SR MPLSラベル「L1」にマップする場合、以下の手順で同じFECをラベル「L1」に割り当てることを意味しますこのFECセットのラベル「L1」へのマッピングが受信される順序に関係なく。たとえば、先着順のタイブレークは許可されていません。残りのFECは、着信ラベルなしでIP FIBにインストールできます。
The procedure in this section relies completely on the local FEC and label database within a given router.
このセクションの手順は、特定のルータ内のローカルFECおよびラベルデータベースに完全に依存しています。
The collision resolution procedure is as follows:
衝突解決手順は次のとおりです。
1. Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to the same MPLS label "L1".
1. FECのセットのSIDを指定すると、{FEC1、FEC2、...、FECk}は同じMPLSラベル「L1」にマップされます。
2. Within an MCC, apply tiebreaking rules to select one FEC only, and assign the label to it. The losing FECs are handled as if no labels are attached to them. The losing FECs with algorithms other than the shortest path first [RFC8402] are not installed in the FIB.
2. MCC内で、タイブレークルールを適用して1つのFECのみを選択し、それにラベルを割り当てます。失われたFECは、ラベルが添付されていないかのように処理されます。最初に最短経路[RFC8402]以外のアルゴリズムを使用して失われたFECは、FIBにインストールされません。
a. If the same set of FECs are attached to the same label "L1", then the tiebreaking rules MUST always select the same FEC irrespective of the order in which the FECs and the label "L1" are received. In other words, the tiebreaking rule MUST be deterministic.
a. 同じセットのFECが同じラベル「L1」に添付されている場合、タイブレーキングルールは、FECとラベル「L1」が受信される順序に関係なく、常に同じFECを選択する必要があります。つまり、タイブレークルールは決定論的である必要があります。
3. If there is still collision between the FECs belonging to different MCCs, then reapply the tiebreaking rules to the remaining FECs to select one FEC only, and assign the label to that FEC.
3. 異なるMCCに属するFEC間にまだ衝突がある場合は、タイブレーキングルールを残りのFECに適用して1つのFECのみを選択し、そのFECにラベルを割り当てます。
4. Install the selected FEC into the IP FIB and its incoming label into the label FIB.
4. 選択したFECをIP FIBにインストールし、その着信ラベルをラベルFIBにインストールします。
5. The remaining FECs with the default algorithm (see the Prefix-SID algorithm specification [RFC8402]) may be installed in the FIB natively, such as pure IP entries in case of Prefix FEC, without any incoming labels corresponding to their SIDs. The remaining FECs with algorithms other than the shortest path first [RFC8402] are not installed in the FIB.
5. デフォルトのアルゴリズム（Prefix-SIDアルゴリズム仕様[RFC8402]を参照）を持つ残りのFECは、SIDに対応する着信ラベルなしで、プレフィックスFECの場合の純粋なIPエントリなど、FIBにネイティブにインストールできます。最初に最短パス[RFC8402]以外のアルゴリズムを使用した残りのFECは、FIBにインストールされません。
The default tiebreaking rules are specified as follows:
デフォルトのタイブレーク規則は次のように指定されています。
1. Determine the lowest administrative distance among the competing FECs as defined in the section below. Then filter away all the competing FECs with a higher administrative distance.
1. 以下のセクションで定義されているように、競合するFECの中で最小の管理距離を決定します。次に、アドミニストレーティブディスタンスが高い競合するすべてのFECをフィルタリングします。
2. If more than one competing FEC remains after step 1, select the smallest numerical FEC value. The numerical value of the FEC is determined according to the FEC encoding described later in this section.
2. ステップ1の後に複数の競合するFECが残っている場合は、最小のFEC数値を選択します。 FECの数値は、このセクションで後述するFECエンコーディングに従って決定されます。
These rules deterministically select which FEC to install in the MPLS forwarding plane for the given incoming label.
これらのルールは、特定の着信ラベルのMPLSフォワーディングプレーンにインストールするFECを決定的に選択します。
This document defines the default tiebreaking rules that SHOULD be implemented. An implementation MAY choose to support different tiebreaking rules and MAY use one of these instead of the default tiebreaking rules. To maximize MPLS forwarding consistency in case of a SID configuration error, the network operator MUST deploy, within an IGP flooding area, routers implementing the same tiebreaking rules.
このドキュメントでは、実装する必要があるデフォルトのタイブレークルールを定義します。実装は、異なるタイブレークルールをサポートすることを選択してもよく（MAY）、デフォルトのタイブレークルールの代わりにこれらのいずれかを使用してもよい（MAY）。 SID構成エラーが発生した場合にMPLS転送の整合性を最大化するには、ネットワークオペレーターは、IGPフラッディングエリア内に、同じタイブレイクルールを実装するルーターを展開する必要があります。
Each FEC is assigned an administrative distance. The FEC administrative distance is encoded as an 8-bit value. The lower the value, the better the administrative distance.
各FECにはアドミニストレーティブディスタンスが割り当てられています。 FEC管理距離は、8ビット値としてエンコードされます。値が低いほど、アドミニストレーティブディスタンスは良くなります。
The default FEC administrative distance order starting from the lowest value SHOULD be:
最低値から始まるデフォルトのFEC管理距離の順序は次のようにする必要があります。
* Explicit SID assignment to a FEC that maps to a label outside the SRGB irrespective of the owner MCC. An explicit SID assignment is a static assignment of a label to a FEC such that the assignment survives a router reboot.
* 所有者のMCCに関係なく、SRGB外のラベルにマップするFECへの明示的なSID割り当て。明示的なSIDの割り当ては、FECへのラベルの静的な割り当てであり、ルーターの再起動後も割り当てられます。
- An example of explicit SID allocation is static assignment of a specific label to an Adj-SID.
- 明示的なSID割り当ての例は、Adj-SIDへの特定のラベルの静的割り当てです。
- An implementation of explicit SID assignment MUST guarantee collision freeness on the same router.
- 明示的なSID割り当ての実装は、同じルーターでの衝突のないことを保証しなければなりません（MUST）。
* Dynamic SID assignment:
* 動的SID割り当て：
- All FEC types, except for the SR Policy, are ordered using the default administrative distance defined by the implementation.
- SRポリシーを除くすべてのFECタイプは、実装によって定義されたデフォルトのアドミニストレーティブディスタンスを使用して注文されます。
- The Binding SID [RFC8402] assigned to the SR Policy always has a higher default administrative distance than the default administrative distance of any other FEC type.
- SRポリシーに割り当てられたバインディングSID [RFC8402]のデフォルトの管理距離は、他のFECタイプのデフォルトの管理距離より常に高くなります。
To maximize MPLS forwarding consistency, if the same FEC is advertised in more than one protocol, a user MUST ensure that the administrative distance preference between protocols is the same on all routers of the IGP flooding domain. Note that this is not really new as this already applies to IP forwarding.
MPLS転送の一貫性を最大化するには、同じFECが複数のプロトコルでアドバタイズされる場合、ユーザーは、プロトコル間の管理距離の優先順位がIGPフラッディングドメインのすべてのルーターで同じであることを確認する必要があります。これはすでにIP転送に適用されているため、これは実際には新しいことではないことに注意してください。
The numerical sort across FECs SHOULD be performed as follows:
FEC全体の数値ソートは、次のように実行する必要があります。
* Each FEC is assigned a FEC type encoded in 8 bits. The type codepoints for each SR FEC defined at the beginning of this section are as follows:
* 各FECには、8ビットでエンコードされたFECタイプが割り当てられています。このセクションの冒頭で定義されている各SR FECのタイプコードポイントは次のとおりです。
120: (Prefix, Routing Instance, Topology, Algorithm)
120：（プレフィックス、ルーティングインスタンス、トポロジ、アルゴリズム）
130: (next hop, outgoing interface)
130：（ネクストホップ、発信インターフェース）
140: Parallel Adjacency [RFC8402]
140：並列隣接[RFC8402]
150: SR Policy [RFC8402]
150：SRポリシー[RFC8402]
160: Mirror SID [RFC8402]
160：ミラーSID [RFC8402]
The numerical values above are mentioned to guide implementation. If other numerical values are used, then the numerical values must maintain the same greater-than ordering of the numbers mentioned here.
上記の数値は、実装をガイドするために記載されています。他の数値が使用されている場合、数値は、ここで言及されている数値と同じより大きい順序を維持する必要があります。
* The fields of each FEC are encoded as follows:
* 各FECのフィールドは次のようにエンコードされます。
- All fields in all FECs are encoded in big endian order.
- すべてのFECのすべてのフィールドは、ビッグエンディアン順でエンコードされます。
- The Routing Instance ID is represented by 16 bits. For routing instances that are identified by less than 16 bits, encode the Instance ID in the least significant bits while the most significant bits are set to zero.
- ルーティングインスタンスIDは16ビットで表されます。 16ビット未満で識別されるルーティングインスタンスの場合、インスタンスIDを最下位ビットでエンコードし、最上位ビットはゼロに設定します。
- The address family is represented by 8 bits, where IPv4 is encoded as 100, and IPv6 is encoded as 110. These numerical values are mentioned to guide implementations. If other numerical values are used, then the numerical value of IPv4 MUST be less than the numerical value for IPv6.
- アドレスファミリは8ビットで表され、IPv4は100としてエンコードされ、IPv6は110としてエンコードされます。これらの数値は、実装をガイドするために言及されています。他の数値が使用されている場合、IPv4の数値はIPv6の数値よりも小さい必要があります。
- All addresses are represented in 128 bits as follows:
- すべてのアドレスは、次のように128ビットで表されます。
o The IPv6 address is encoded natively.
o IPv6アドレスはネイティブにエンコードされます。
o The IPv4 address is encoded in the most significant bits, and the remaining bits are set to zero.
o IPv4アドレスは最上位ビットでエンコードされ、残りのビットはゼロに設定されます。
- All prefixes are represented by (8 + 128) bits.
- すべてのプレフィックスは（8 + 128）ビットで表されます。
o A prefix is encoded in the most significant bits, and the remaining bits are set to zero.
o プレフィックスは最上位ビットでエンコードされ、残りのビットはゼロに設定されます。
o The prefix length is encoded before the prefix in an 8-bit field.
o プレフィックス長は、8ビットフィールドのプレフィックスの前にエンコードされます。
- The Topology ID is represented by 16 bits. For routing instances that identify topologies using less than 16 bits, encode the topology ID in the least significant bits while the most significant bits are set to zero.
- トポロジIDは16ビットで表されます。 16ビット未満を使用してトポロジを識別するルーティングインスタンスの場合、最上位ビットがゼロに設定されている間、最下位ビットでトポロジIDをエンコードします。
- The Algorithm is encoded in a 16-bit field.
- アルゴリズムは16ビットフィールドにエンコードされます。
- The Color ID is encoded using 32 bits.
- カラーIDは32ビットを使用してエンコードされます。
* Choose the set of FECs of the smallest FEC type codepoint.
* 最小のFECタイプコードポイントのFECのセットを選択します。
* Out of these FECs, choose the FECs with the smallest address family codepoint.
* これらのFECから、最小のアドレスファミリコードポイントを持つFECを選択します。
* Encode the remaining set of FECs as follows:
* 残りのFECセットを次のようにエンコードします。
- (Prefix, Routing Instance, Topology, Algorithm) is encoded as (Prefix Length, Prefix, routing_instance_id, Topology, SR Algorithm).
- （プレフィックス、ルーティングインスタンス、トポロジ、アルゴリズム）は（プレフィックス長、プレフィックス、routing_instance_id、トポロジ、SRアルゴリズム）としてエンコードされます。
- (next hop, outgoing interface) is encoded as (next hop, outgoing_interface_id).
- （ネクストホップ、発信インターフェース）は（ネクストホップ、発信インターフェースID）としてエンコードされます。
- (number of adjacencies, list of next hops in ascending numerical order, list of outgoing interface IDs in ascending numerical order) is used to encode a parallel adjacency [RFC8402].
- （隣接の数、昇順のネクストホップのリスト、昇順の発信インターフェイスIDのリスト）は、並列隣接をエンコードするために使用されます[RFC8402]。
- (Endpoint, Color) is encoded as (Endpoint_address, Color_id).
- （Endpoint、Color）は（Endpoint_address、Color_id）としてエンコードされます。
- (IP address) is the encoding for a Mirror SID FEC. The IP address is encoded as described above in this section.
- （IPアドレス）は、ミラーSID FECのエンコーディングです。 IPアドレスは、このセクションで前述したようにエンコードされます。
* Select the FEC with the smallest numerical value.
* 数値が最も小さいFECを選択します。
The numerical values mentioned in this section are for guidance only. If other numerical values are used, then the other numerical values MUST maintain the same numerical ordering among different SR FECs.
このセクションに記載されている数値は、参考値です。他の数値が使用される場合、他の数値は異なるSR FEC間で同じ数値の順序を維持する必要があります。
The following rule SHOULD be applied when redistributing SIDs with prefixes between routing protocol instances:
ルーティングプロトコルインスタンス間でプレフィックス付きのSIDを再配布する場合は、次のルールを適用する必要があります（SHOULD）。
* If the SRGB of the receiving instance is the same as the SRGB of the origin instance, then:
* 受信インスタンスのSRGBが起点インスタンスのSRGBと同じ場合、次のようになります。
- the index is redistributed with the route.
- インデックスはルートとともに再配布されます。
* Else,
* そうしないと、
- the index is not redistributed and if the receiving instance decides to advertise an index with the redistributed route, it is the duty of the receiving instance to allocate a fresh index relative to its own SRGB. Note that in this case, the receiving instance MUST compute the local label it assigns to the route according to Section 2.4 and install it in FIB.
- インデックスは再配布されません。受信インスタンスが再配布されたルートでインデックスをアドバタイズすることを決定した場合、独自のSRGBに対して新しいインデックスを割り当てるのは受信インスタンスの義務です。この場合、受信インスタンスは、セクション2.4に従ってルートに割り当てるローカルラベルを計算し、FIBにインストールする必要があることに注意してください。
It is outside the scope of this document to define local node behaviors that would allow the mapping of the original index into a new index in the receiving instance via the addition of an offset or other policy means.
オフセットやその他のポリシー手段を追加して、元のインデックスを受信インスタンスの新しいインデックスにマッピングできるようにするローカルノードの動作を定義することは、このドキュメントの範囲外です。
A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001)
Consider the simple topology above, where:
上記の簡単なトポロジについて考えてみましょう。
* A and B are in the IS-IS domain with SRGB = [16000-17000]
* AおよびBはSRGB = [16000-17000]のIS-ISドメインにあります
* B and C are in the OSPF domain with SRGB = [20000-21000]
* BおよびCは、SRGB = [20000-21000]のOSPFドメインにあります
* B redistributes 192.0.2.1/32 into the IS-IS domain
* Bは192.0.2.1/32をIS-ISドメインに再配布します
In this case, A learns 192.0.2.1/32 as an IP leaf connected to B, which is usual for IP prefix redistribution
この場合、Aは192.0.2.1/32をBに接続されたIPリーフとして学習します。これは通常、IPプレフィックスの再配布に使用されます。
However, according to the redistribution rule above, B decides not to advertise any index with 192.0.2.1/32 into IS-IS because the SRGB is not the same.
ただし、上記の再配布ルールに従って、SRGBが同じではないため、Bは192.0.2.1/32のインデックスをIS-ISにアドバタイズしないことを決定します。
Consider the example in the illustration described in Section 2.5.2.1.
セクション2.5.2.1で説明されている図の例を検討してください。
When router B redistributes the prefix 192.0.2.1/32, router B decides to allocate and advertise the same index 1 with the prefix 192.0.2.1/32.
ルータBがプレフィックス192.0.2.1/32を再配布すると、ルータBは同じインデックス1を割り当て、プレフィックス192.0.2.1/32でアドバタイズすることを決定します。
Within the SRGB of the IS-IS domain, index 1 corresponds to the local label 16001. Hence, according to the redistribution rule above, router B programs the incoming label 16001 in its FIB to match traffic arriving from the IS-IS domain destined to the prefix 192.0.2.1/32.
IS-ISドメインのSRGB内では、インデックス1はローカルラベル16001に対応します。したがって、上記の再配布ルールに従って、ルータBは、FIBの着信ラベル16001をプログラムして、IS-ISドメインから着信するトラフィックを照合します。接頭辞192.0.2.1/32
When determining what outgoing label to use, the ingress node that pushes new segments, and hence a stack of MPLS labels, MUST use, for a given FEC, the label that has been selected by the node receiving the packet with that label exposed as the top label. So in case of incoming label collision on this receiving node, the ingress node MUST resolve this collision by using this same "Incoming Label Collision resolution procedure" and by using the data of the receiving node.
使用する発信ラベルを決定するとき、新しいセグメントをプッシュする入力ノード、つまりMPLSラベルのスタックは、特定のFECに対して、そのラベルがパケットとして公開されているパケットを受信するノードによって選択されたラベルを使用する必要があります。トップラベル。したがって、この受信ノードで着信ラベルの衝突が発生した場合、入力ノードはこの同じ「着信ラベル衝突解決手順」を使用し、受信ノードのデータを使用して、この衝突を解決する必要があります。
In the general case, the ingress node may not have the exact same data as the receiving node, so the result may be different. This is under the responsibility of the network operator. But in a typical case, e.g., where a centralized node or a distributed link-state IGP is used, all nodes would have the same database. However, to minimize the chance of misforwarding, a FEC that loses its incoming label to the tiebreaking rules specified in Section 2.5 MUST NOT be installed in FIB with an outgoing Segment Routing label based on the SID corresponding to the lost incoming label.
一般的なケースでは、入口ノードは受信ノードとまったく同じデータを持たない可能性があるため、結果は異なる場合があります。これはネットワークオペレーターの責任です。しかし、たとえば、集中型ノードまたは分散型リンクステートIGPが使用されるような典型的なケースでは、すべてのノードが同じデータベースを持ちます。ただし、誤った転送の可能性を最小限に抑えるために、セクション2.5で指定されたタイブレーキングルールへの着信ラベルを失うFECは、失われた着信ラベルに対応するSIDに基づく発信セグメントルーティングラベルとともにFIBにインストールしてはなりません。
Examples for the behavior specified in this section can be found in Appendix A.3.
このセクションで指定されている動作の例は、付録A.3にあります。
PUSH, NEXT, and CONTINUE are operations applied by the forwarding plane. The specifications of these operations can be found in [RFC8402]. This subsection specifies how to implement each of these operations in the MPLS forwarding plane.
PUSH、NEXT、CONTINUEは、フォワーディングプレーンによって適用される操作です。これらの操作の仕様は[RFC8402]にあります。このサブセクションでは、MPLSフォワーディングプレーンでこれらの各操作を実装する方法を指定します。
As described in [RFC8402], PUSH corresponds to pushing one or more labels on top of an incoming packet then sending it out of a particular physical interface or virtual interface, such as a UDP tunnel [RFC7510] or the Layer 2 Tunneling Protocol version 3 (L2TPv3) [RFC4817], towards a particular next hop. When pushing labels onto a packet's label stack, the Time-to-Live (TTL) field [RFC3032] [RFC3443] and the Traffic Class (TC) field [RFC3032] [RFC5462] of each label stack entry must, of course, be set. This document does not specify any set of rules for setting these fields; that is a matter of local policy. Sections 2.10 and 2.11 specify additional details about forwarding behavior.
[RFC8402]で説明されているように、PUSHは、着信パケットの上に1つ以上のラベルをプッシュし、UDPトンネル[RFC7510]またはLayer 2 Tunneling Protocolバージョン3などの特定の物理インターフェイスまたは仮想インターフェイスから送信することに対応します。 （L2TPv3）[RFC4817]、特定のネクストホップに向けて。パケットのラベルスタックにラベルをプッシュする場合、各ラベルスタックエントリのTime-to-Live（TTL）フィールド[RFC3032] [RFC3443]とトラフィッククラス（TC）フィールド[RFC3032] [RFC5462]はもちろんセットする。このドキュメントでは、これらのフィールドを設定するための一連の規則を指定していません。それは地方政策の問題です。セクション2.10および2.11は、転送動作に関する追加の詳細を指定します。
As described in [RFC8402], the CONTINUE operation corresponds to swapping the incoming label with an outgoing label. The value of the outgoing label is calculated as specified in Sections 2.10 and 2.11.
[RFC8402]で説明されているように、CONTINUE操作は、着信ラベルを発信ラベルと交換することに対応します。発信ラベルの値は、セクション2.10および2.11の指定に従って計算されます。
As described in [RFC8402], NEXT corresponds to popping the topmost label. The action before and/or after the popping depends on the instruction associated with the active SID on the received packet prior to the popping. For example, suppose the active SID in the received packet was an Adj-SID [RFC8402]; on receiving the packet, the node applies the NEXT operation, which corresponds to popping the topmost label, and then sends the packet out of the physical or virtual interface (e.g., the UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]) towards the next hop corresponding to the Adj-SID.
[RFC8402]で説明されているように、NEXTは最上位のラベルのポップに対応します。ポップの前または後のアクションは、ポップの前に受信したパケットのアクティブSIDに関連付けられた命令によって異なります。たとえば、受信したパケットのアクティブなSIDがAdj-SID [RFC8402]だったとします。パケットを受信すると、ノードは最上位のラベルのポップに対応するNEXT操作を適用し、物理または仮想インターフェイス（たとえば、UDPトンネル[RFC7510]またはL2TPv3トンネル[RFC4817]）からパケットをAdj-SIDに対応するネクストホップ。
If the active SID in the received packet was a Mirror SID (see [RFC8402], Section 5.1) allocated by the receiving router, the receiving router applies the NEXT operation, which corresponds to popping the topmost label, and then performs a lookup using the contents of the packet after popping the outermost label in the mirrored forwarding table. The method by which the lookup is made, and/or the actions applied to the packet after the lookup in the mirror table, depends on the contents of the packet and the mirror table. Note that the packet exposed after popping the topmost label may or may not be an MPLS packet. A Mirror SID can be viewed as a generalization of the context label in [RFC5331] because a Mirror SID does not make any assumptions about the packet underneath the top label.
受信したパケットのアクティブなSIDが受信側ルーターによって割り当てられたミラーSID（[RFC8402]、セクション5.1を参照）である場合、受信側ルーターは最上位のラベルのポップに対応するNEXT操作を適用し、ミラーリングされた転送テーブルで最も外側のラベルをポップした後のパケットの内容。検索が行われる方法、および/またはミラーテーブルでの検索後にパケットに適用されるアクションは、パケットとミラーテーブルの内容によって異なります。最上位のラベルをポップした後に公開されるパケットは、MPLSパケットである場合とそうでない場合があることに注意してください。ミラーSIDは、[RFC5331]のコンテキストラベルの一般化と見なすことができます。これは、ミラーSIDは、トップラベルの下のパケットについて何も想定していないためです。
The label corresponding to the global SID "Si", which is represented by the global index "I" and downloaded to the FIB, is used to match packets whose active segment (and hence topmost label) is "Si". The value of this label is calculated as specified in Section 2.4.
グローバルインデックス「I」で表され、FIBにダウンロードされたグローバルSID「Si」に対応するラベルは、アクティブセグメント（したがって最上位のラベル）が「Si」であるパケットを照合するために使用されます。このラベルの値は、セクション2.4の指定に従って計算されます。
For Local SIDs, the MCC is responsible for downloading the correct label value to the FIB. For example, an IGP with SR extensions [RFC8667] [RFC8665] downloads the MPLS label corresponding to an Adj-SID [RFC8402].
ローカルSIDの場合、MCCは正しいラベル値をFIBにダウンロードする責任があります。たとえば、SR拡張機能を備えたIGP [RFC8667] [RFC8665]は、Adj-SID [RFC8402]に対応するMPLSラベルをダウンロードします。
When instantiated in the MPLS domain, the active segment on a packet corresponds to the topmost label and is calculated according to the procedure specified in Sections 2.10 and 2.11. When arriving at a node, the topmost label corresponding to the active SID matches the MPLS label downloaded to the FIB as specified in Section 2.4.
MPLSドメインでインスタンス化されると、パケットのアクティブセグメントは最上位のラベルに対応し、セクション2.10および2.11で指定された手順に従って計算されます。ノードに到着すると、アクティブSIDに対応する最上位のラベルは、セクション2.4で指定されているように、FIBにダウンロードされたMPLSラベルと一致します。
This section specifies the forwarding behavior, including the calculation of outgoing labels, that corresponds to a global SID when applying the PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane.
このセクションでは、MPLS転送プレーンでPUSH、CONTINUE、およびNEXT操作を適用する場合のグローバルSIDに対応する、送信ラベルの計算を含む転送動作を指定します。
This document covers the calculation of the outgoing label for the top label only. The case where the outgoing label is not the top label and is part of a stack of labels that instantiates a routing policy or a traffic-engineering tunnel is outside the scope of this document and may be covered in other documents such as [ROUTING-POLICY].
このドキュメントでは、トップラベルのみの発信ラベルの計算について説明します。発信ラベルがトップラベルではなく、ルーティングポリシーまたはトラフィックエンジニアリングトンネルをインスタンス化するラベルのスタックの一部であるケースは、このドキュメントの範囲外であり、[ROUTING-POLICY]などの他のドキュメントでカバーされる場合があります。 ]。
Suppose an MCC on router "R0" determines that, before sending the packet towards a neighbor "N", the PUSH or CONTINUE operation is to be applied to an incoming packet related to the global SID "Si". SID "Si" is represented by the global index "I" and owned by the router Ri. Neighbor "N" may be directly connected to "R0" through either a physical or a virtual interface (e.g., UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]).
ルーター「R0」のMCCが、ネイバー「N」に向けてパケットを送信する前に、PUSHまたはCONTINUE操作がグローバルSID「Si」に関連する着信パケットに適用されることを決定するとします。 SID「Si」はグローバルインデックス「I」で表され、ルーターRiが所有しています。ネイバー「N」は、物理インターフェイスまたは仮想インターフェイス（UDPトンネル[RFC7510]またはL2TPv3トンネル[RFC4817]など）を介して「R0」に直接接続できます。
The method by which the MCC on router "R0" determines that the PUSH or CONTINUE operation must be applied using the SID "Si" is beyond the scope of this document. An example of a method to determine the SID "Si" for the PUSH operation is the case where IS-IS [RFC8667] receives the Prefix-SID "Si" sub-TLV advertised with the prefix "P/m" in TLV 135, and the prefix "P/m" is the longest matching network prefix for the incoming IPv4 packet.
ルータ "R0"のMCCがSID "Si"を使用してPUSHまたはCONTINUE操作を適用する必要があると判断する方法は、このドキュメントの範囲外です。 PUSHオペレーションのSID「Si」を決定する方法の例は、IS-IS [RFC8667]がTLV 135でプレフィックス「P / m」でアドバタイズされたPrefix-SID「Si」サブTLVを受信する場合です。プレフィックス「P / m」は、着信IPv4パケットに一致する最長のネットワークプレフィックスです。
For the CONTINUE operation, an example of a method used to determine the SID "Si" is the case where IS-IS [RFC8667] receives the Prefix-SID "Si" sub-TLV advertised with prefix "P" in TLV 135, and the top label of the incoming packet matches the MPLS label in the FIB corresponding to the SID "Si" on router "R0".
CONTINUE操作の場合、SID "Si"を決定するために使用される方法の例は、IS-IS [RFC8667]がTLV 135でプレフィックス "P"でアドバタイズされたPrefix-SID "Si"サブTLVを受信する場合です。着信パケットのトップラベルは、ルーター「R0」のSID「Si」に対応するFIBのMPLSラベルと一致します。
The forwarding behavior for PUSH and CONTINUE corresponding to the SID "Si" is as follows:
SID "Si"に対応するPUSHおよびCONTINUEの転送動作は次のとおりです。
* If neighbor "N" does not support SR or advertises an invalid SRGB or a SRGB that is too small for the SID "Si", then:
* ネイバー「N」がSRをサポートしていないか、無効なSRGBまたはSID「Si」には小さすぎるSRGBをアドバタイズする場合、次のようになります。
- If it is possible to send the packet towards neighbor "N" using standard MPLS forwarding behavior as specified in [RFC3031] and [RFC3032], forward the packet. The method by which a router decides whether it is possible to send the packet to "N" or not is beyond the scope of this document. For example, the router "R0" can use the downstream label determined by another MCC, such as LDP [RFC5036], to send the packet.
- [RFC3031]と[RFC3032]で指定されている標準のMPLS転送動作を使用してネイバー「N」に向けてパケットを送信できる場合は、パケットを転送します。ルーターがパケットを「N」に送信できるかどうかを判断する方法は、このドキュメントの範囲外です。たとえば、ルーター「R0」は、LDP [RFC5036]などの別のMCCによって決定されたダウンストリームラベルを使用して、パケットを送信できます。
- Else, if there are other usable next hops, use them to forward the incoming packet. The method by which the router "R0" decides on the possibility of using other next hops is beyond the scope of this document. For example, the MCC on "R0" may chose the send an IPv4 packet without pushing any label to another next hop.
- または、他に使用可能なネクストホップがある場合は、それらを使用して着信パケットを転送します。ルータ「R0」が他のネクストホップを使用する可能性を決定する方法は、このドキュメントの範囲外です。たとえば、「R0」上のMCCは、別のネクストホップにラベルをプッシュすることなく、IPv4パケットの送信を選択できます。
- Otherwise, drop the packet.
- それ以外の場合は、パケットをドロップします。
* Else,
* そうしないと、
- Calculate the outgoing label as specified in Section 2.4 using the SRGB of neighbor "N".
- 近傍「N」のSRGBを使用して、セクション2.4で指定されているように出力ラベルを計算します。
- Determine the outgoing label stack
- 発信ラベルスタックを決定する
o If the operation is PUSH:
o 操作がPUSHの場合：
+ Push the calculated label according to the MPLS label pushing rules specified in [RFC3032].
+ [RFC3032]で指定されたMPLSラベルプッシュルールに従って、計算されたラベルをプッシュします。
o Else,
o そうしないと、
+ swap the incoming label with the calculated label according to the label-swapping rules in [RFC3031].
+ [RFC3031]のラベル交換ルールに従って、着信ラベルを計算されたラベルと交換します。
o Send the packet towards neighbor "N".
o ネイバー「N」に向けてパケットを送信します。
As specified in Section 2.7.3, the NEXT operation corresponds to popping the topmost label. The forwarding behavior is as follows:
セクション2.7.3で指定されているように、NEXT操作は最上位のラベルのポップに対応します。転送動作は次のとおりです。
* Pop the topmost label
* 一番上のラベルをポップ
* Apply the instruction associated with the incoming label that has been popped
* ポップされた着信ラベルに関連付けられた指示を適用します
The action on the packet after popping the topmost label depends on the instruction associated with the incoming label as well as the contents of the packet right underneath the top label that was popped. Examples of the NEXT operation are described in Appendix A.1
最上位ラベルをポップした後のパケットのアクションは、着信ラベルに関連付けられた命令と、ポップされたトップラベルのすぐ下のパケットの内容によって異なります。 NEXT操作の例は、付録A.1で説明されています。
This section specifies the forwarding behavior for Local SIDs when SR is instantiated over the MPLS forwarding plane.
このセクションでは、SRがMPLS転送プレーンを介してインスタンス化されるときのローカルSIDの転送動作を指定します。
Suppose an MCC on router "R0" determines that the PUSH operation is to be applied to an incoming packet using the Local SID "Si" before sending the packet towards neighbor "N", which is directly connected to R0 through a physical or virtual interface such as a UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817].
ルーター「R0」のMCCがローカルSID「Si」を使用して着信パケットにPUSH操作を適用する前に、物理または仮想インターフェイスを介してR0に直接接続されているネイバー「N」にパケットを送信するとします。 UDPトンネル[RFC7510]やL2TPv3トンネル[RFC4817]など。
An example of such a Local SID is an Adj-SID allocated and advertised by IS-IS [RFC8667]. The method by which the MCC on "R0" determines that the PUSH operation is to be applied to the incoming packet is beyond the scope of this document. An example of such a method is the backup path used to protect against a failure using TI-LFA [FAST-REROUTE].
そのようなローカルSIDの例は、IS-ISによって割り当てられ、アドバタイズされるAdj-SIDです[RFC8667]。 「R0」のMCCがPUSH操作を着信パケットに適用することを決定する方法は、このドキュメントの範囲外です。このような方法の例は、TI-LFA [FAST-REROUTE]を使用して障害から保護するために使用されるバックアップパスです。
As mentioned in [RFC8402], a Local SID is specified by an MPLS label. Hence, the PUSH operation for a Local SID is identical to the label push operation using any MPLS label [RFC3031]. The forwarding action after pushing the MPLS label corresponding to the Local SID is also determined by the MCC. For example, if the PUSH operation was done to forward a packet over a backup path calculated using TI-LFA, then the forwarding action may be sending the packet to a certain neighbor that will in turn continue to forward the packet along the backup path.
[RFC8402]で述べられているように、ローカルSIDはMPLSラベルによって指定されます。したがって、ローカルSIDのPUSH操作は、MPLSラベル[RFC3031]を使用したラベルプッシュ操作と同じです。ローカルSIDに対応するMPLSラベルをプッシュした後の転送アクションも、MCCによって決定されます。たとえば、TI-LFAを使用して計算されたバックアップパスを介してパケットを転送するためにPUSH操作が行われた場合、転送アクションは、パケットを特定のネイバーに送信し、ネイバーは引き続きバックアップパスに沿ってパケットを転送します。
A Local SID on router "R0" corresponds to a local label. In such a scenario, the outgoing label towards next hop "N" is determined by the MCC running on the router "R0", and the forwarding behavior for the CONTINUE operation is identical to the swap operation on an MPLS label [RFC3031].
ルータ「R0」のローカルSIDはローカルラベルに対応します。このようなシナリオでは、ネクストホップ「N」に向かう発信ラベルは、ルーター「R0」で実行されているMCCによって決定され、CONTINUE操作の転送動作は、MPLSラベルのスワップ操作と同じです[RFC3031]。
The NEXT operation for Local SIDs is identical to the NEXT operation for global SIDs as specified in Section 2.10.2.
ローカルSIDのNEXT操作は、2.10.2項で指定されているグローバルSIDのNEXT操作と同じです。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document describes the applicability of Segment Routing over the MPLS data plane. Segment Routing does not introduce any change in the MPLS data plane. Manageability considerations described in [RFC8402] apply to the MPLS data plane when used with Segment Routing. SR Operations, Administration, and Maintenance (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データプレーンでのセグメントルーティングの適用性について説明します。セグメントルーティングは、MPLSデータプレーンに変更をもたらしません。 [RFC8402]で説明されている管理性の考慮事項は、セグメントルーティングで使用される場合、MPLSデータプレーンに適用されます。 MPLSデータプレーンのSR Operations、Administration、and Maintenance（OAM）の使用例は、[RFC8403]で定義されています。 MPLSデータプレーンのSR OAM手順は、[RFC8287]で定義されています。
This document does not introduce additional security requirements and mechanisms other than the ones described in [RFC8402].
このドキュメントでは、[RFC8402]で説明されているもの以外の追加のセキュリティ要件とメカニズムを紹介していません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、DOI 10.17487 / RFC3032、2001年1月、<https://www.rfc-editor.org/info/rfc3032>。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.
[RFC3443] Agarwal、P。およびB. Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワークでの存続時間（TTL）処理」、RFC 3443、DOI 10.17487 / RFC3443、2003年1月、<https：// www。 rfc-editor.org/info/rfc3443>。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5462] Andersson、L。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP" Renamed to "Traffic Class" Field」、RFC 5462、DOI 10.17487 / RFC5462、2009年2月、<https： //www.rfc-editor.org/info/rfc5462>。
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>.
[RFC7274] Kompella、K.、Andersson、L。、およびA. Farrel、「特別な目的のMPLSラベルの割り当てと廃止」、RFC 7274、DOI 10.17487 / RFC7274、2014年6月、<https：//www.rfc-editor .org / info / rfc7274>。
[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。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[FAST-REROUTE] Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Francois, P., Voyer, D., Clad, F., and P. Camarillo, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-01, 5 March 2019, <https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01>.
[FAST-REROUTE] Litkowski、S.、Bashandy、A.、Filsfils、C.、Decraene、B.、Francois、P.、Voyer、D.、Clad、F.、and P. Camarillo、 "Topology Independent Fast Rerouteセグメントルーティングの使用」、進行中の作業、インターネットドラフト、draft-ietf-rtgwg-segment-routing-ti-lfa-01、2019年3月5日、<https://tools.ietf.org/html/draft-ietf- rtgwg-segment-routing-ti-lfa-01>。
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and J. Young, "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 2007, <https://www.rfc-editor.org/info/rfc4817>.
[RFC4817] Townsley、M.、Pignataro、C.、Wainner、S.、Seely、T。、およびJ. Young、「MPLS over Layer 2 Tunneling Protocol Version 3」、RFC 4817、DOI 10.17487 / RFC4817、3月2007、<https://www.rfc-editor.org/info/rfc4817>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<https：// www。 rfc-editor.org/info/rfc5036>。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<https：//www.rfc -editor.org/info/rfc5331>。
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, <https://www.rfc-editor.org/info/rfc7510>.
[RFC7510] Xu、X.、Sheth、N.、Yong、L.、Callon、R。、およびD. Black、「UDPでのMPLSのカプセル化」、RFC 7510、DOI 10.17487 / RFC7510、2015年4月、<https：/ /www.rfc-editor.org/info/rfc7510>。
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC7855] Previdi、S.、Ed。、Filsfils、C.、Ed。、Decraene、B.、Litkowski、S.、Horneffer、M.、and R. Shakir、 "Source Packet Routing in Networking（SPRING）Problem Statementおよび要件」、RFC 7855、DOI 10.17487 / RFC7855、2016年5月、<https://www.rfc-editor.org/info/rfc7855>。
[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 >。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc8403>。
[RFC8661] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing MPLS Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661, December 2019, <https://www.rfc-editor.org/info/rfC8661>.
[RFC8661] Bashandy、A.、Ed。、Filsfils、C.、Ed。、Previdi、S.、Decraene、B.、and S. Litkowski、 "Segment Routing MPLS Interworking with LDP"、RFC 8661、DOI 10.17487 / RFC8661 、2019年12月、<https://www.rfc-editor.org/info/rfC8661>。
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.
[RFC8665] Psenak、P。、編、Previdi、S。、編、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W。、およびJ. Tantsura、「セグメントルーティングのOSPF拡張"、RFC 8665、DOI 10.17487 / RFC8665、2019年12月、<https://www.rfc-editor.org/info/rfc8665>。
[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, <https://www.rfc-editor.org/info/rfc8666>.
[RFC8666] Psenak、P.、Ed。およびS. Previdi編、「OSPFv3 Extensions for Segment Routing」、RFC 8666、DOI 10.17487 / RFC8666、2019年12月、<https://www.rfc-editor.org/info/rfc8666>。
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.
[RFC8667] Previdi、S.、Ed。、Ginsberg、L.、Ed。、Filsfils、C.、Bashandy、A.、Gredler、H.、and B. Decraene、 "IS-IS Extensions for Segment Routing"、RFC 8667、DOI 10.17487 / RFC8667、2019年12月、<https://www.rfc-editor.org/info/rfc8667>。
[ROUTING-POLICY] Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-05, 17 November 2019, <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-05>.
[ルーティングポリシー] Filsfils、C.、Sivabalan、S.、Voyer、D.、Bogdanov、A。、およびP. Mattes、「セグメントルーティングポリシーアーキテクチャ」、作業中、インターネットドラフト、draft-ietf-spring -segment-routing-policy-05、2019年11月17日、<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-05>。
Consider the network diagram of Figure 1 and the IP addresses and IGP segment allocations of Figure 2. Assume that the network is running IS-IS with SR extensions [RFC8667], and all links have the same metric. The following examples can be constructed.
図1のネットワークダイアグラムと、図2のIPアドレスとIGPセグメントの割り当てについて考えてみます。ネットワークがSR拡張[RFC8667]を使用してIS-ISを実行しており、すべてのリンクが同じメトリックを持っているとします。以下の例を構築できます。
+--------+
/ \
R0-----R1-----R2----------R3-----R8
| \ / |
| +--R4--+ |
| |
+-----R5-----+
Figure 1: IGP Segments -- Illustration
図1：IGPセグメント-イラスト
+-----------------------------------------------------------+
| IP addresses allocated by the operator: |
| 192.0.2.1/32 as a loopback of R1 |
| 192.0.2.2/32 as a loopback of R2 |
| 192.0.2.3/32 as a loopback of R3 |
| 192.0.2.4/32 as a loopback of R4 |
| 192.0.2.5/32 as a loopback of R5 |
| 192.0.2.8/32 as a loopback of R8 |
| 198.51.100.9/32 as an anycast loopback of R4 |
| 198.51.100.9/32 as an anycast loopback of R5 |
| |
| SRGB defined by the operator as [1000,5000] |
| |
| Global IGP SID indices allocated by the operator: |
| 1 allocated to 192.0.2.1/32 |
| 2 allocated to 192.0.2.2/32 |
| 3 allocated to 192.0.2.3/32 |
| 4 allocated to 192.0.2.4/32 |
| 8 allocated to 192.0.2.8/32 |
| 1009 allocated to 198.51.100.9/32 |
| |
| Local IGP SID allocated dynamically by R2 |
| for its "north" adjacency to R3: 9001 |
| for its "east" adjacency to R3 : 9002 |
| for its "south" adjacency to R3: 9003 |
| for its only adjacency to R4 : 9004 |
| for its only adjacency to R1 : 9005 |
+-----------------------------------------------------------+
Figure 2: IGP Address and Segment Allocation -- Illustration
図2：IGPアドレスとセグメントの割り当て-イラスト
Suppose R1 wants to send IPv4 packet P1 to R8. In this case, R1 needs to apply the PUSH operation to the IPv4 packet.
R1がIPv4パケットP1をR8に送信したいとします。この場合、R1はPUSH操作をIPv4パケットに適用する必要があります。
Remember that the SID index "8" is a global IGP segment attached to the IP prefix 192.0.2.8/32. Its semantic is global within the IGP domain: any router forwards a packet received with active segment 8 to the next hop along the ECMP-aware shortest path to the related prefix.
SIDインデックス「8」は、IPプレフィックス192.0.2.8/32に付加されたグローバルIGPセグメントであることを忘れないでください。そのセマンティクスはIGPドメイン内でグローバルです。どのルーターも、アクティブセグメント8で受信したパケットを、関連するプレフィックスへのECMP対応の最短パスに沿って次のホップに転送します。
R2 is the next hop along the shortest path towards R8. By applying
the steps in Section 2.8, the outgoing label downloaded to R1's FIB
corresponding to the global SID index "8" is 1008 because the SRGB of
R2 = [1000,5000] as shown in Figure 2.
Because the packet is IPv4, R1 applies the PUSH operation using the label value 1008 as specified in Section 2.10.1. The resulting MPLS header will have the "S" bit [RFC3032] set because it is followed directly by an IPv4 packet.
パケットはIPv4であるため、R1はセクション2.10.1で指定されているラベル値1008を使用してPUSH操作を適用します。結果のMPLSヘッダーにはIPv4パケットが直接続くため、「S」ビット[RFC3032]が設定されます。
The packet arrives at router R2. Because top label 1008 corresponds to the IGP SID index "8", which is the Prefix-SID attached to the prefix 192.0.2.8/32 owned by Node R8, the instruction associated with the SID is "forward the packet using one of the ECMP interfaces or next hops along the shortest path(s) towards R8". Because R2 is not the penultimate hop, R2 applies the CONTINUE operation to the packet and sends it to R3 using one of the two links connected to R3 with top label 1008 as specified in Section 2.10.1.
パケットはルーターR2に到着します。トップラベル1008は、ノードR8が所有するプレフィックス192.0.2.8/32に付加されたプレフィックスSIDであるIGP SIDインデックス「8」に対応するため、SIDに関連付けられた命令は、「ECMPの1つを使用してパケットを転送します。 R8 "への最短パスに沿ったインターフェースまたはネクストホップ。 R2は最後から2番目のホップではないので、R2はパケットにCONTINUE操作を適用し、セクション2.10.1で指定されているようにトップラベル1008でR3に接続された2つのリンクの1つを使用してR3に送信します。
R3 receives the packet with top label 1008. Because top label 1008 corresponds to the IGP SID index "8", which is the Prefix-SID attached to the prefix 192.0.2.8/32 owned by Node R8, the instruction associated with the SID is "send the packet using one of the ECMP interfaces and next hops along the shortest path towards R8". Because R3 is the penultimate hop, we assume that R3 performs penultimate hop popping, which corresponds to the NEXT operation; the packet is then sent to R8. The NEXT operation results in popping the outer label and sending the packet as a pure IPv4 packet to R8.
R3は、トップラベル1008のパケットを受信します。トップラベル1008は、ノードR8が所有するプレフィックス192.0.2.8/32に付加されたプレフィックスSIDであるIGP SIDインデックス「8」に対応するため、SIDに関連付けられた命令は、 「R8への最短パスに沿ったECMPインターフェイスとネクストホップの1つを使用してパケットを送信します。」 R3は最後から2番目のホップであるため、R3は最後から2番目のホップポップを実行すると想定します。これは、NEXT操作に対応しています。その後、パケットはR8に送信されます。 NEXT操作の結果、外部ラベルがポップされ、パケットが純粋なIPv4パケットとしてR8に送信されます。
In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP awareness ensures that the traffic is load-shared between any ECMP path; in this case, it's the two links between R2 and R3.
結論として、P1がたどるパスはR1-R2--R3-R8です。 ECMP認識は、トラフィックがECMPパス間で負荷分散されることを保証します。この場合は、R2とR3の間の2つのリンクです。
This section outlines several examples to illustrate the handling of label collision described in Section 2.5.
このセクションでは、セクション2.5で説明されているラベルの衝突の処理を示すいくつかの例の概要を説明します。
For the examples in this section, we assume that Node A has the following:
このセクションの例では、ノードAに次のものが含まれていると想定しています。
* OSPF default admin distance for implementation=50
* 実装のOSPFデフォルト管理距離= 50
* IS-IS default admin distance for implementation=60
* IS-IS実装のデフォルトの管理距離= 60
The following example illustrates incoming label collision resolution for the same FEC type using MCC administrative distance.
次の例は、MCC管理距離を使用した同じFECタイプの着信ラベル衝突解決を示しています。
FEC1:
FEC1;
Node A receives an OSPF Prefix-SID Advertisement from Node B for 198.51.100.5/32 with index=5. Assuming that OSPF SRGB on Node A = [1000,1999], the incoming label is 1005.
ノードAは、ノードBから198.51.100.5/32のOSPF Prefix-SIDアドバタイズメントをインデックス= 5で受信します。ノードAのOSPF SRGB = [1000,1999]とすると、着信ラベルは1005です。
FEC2:
道楽：
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for 203.0.113.105/32 with index=5. Assuming that IS-IS SRGB on Node A = [1000,1999], the incoming label is 1005.
ノードAのIS-ISは、ノードCから203.0.113.105/32のプレフィックスSIDアドバタイズメントをインデックス= 5で受信します。ノードAのIS-IS SRGB = [1000,1999]とすると、着信ラベルは1005です。
FEC1 and FEC2 both use dynamic SID assignment. Since neither of the FECs are of type 'SR Policy', we use the default admin distances of 50 and 60 to break the tie. So FEC1 wins.
FEC1とFEC2はどちらも動的SID割り当てを使用します。どちらのFECも「SRポリシー」タイプではないため、デフォルトの管理距離である50と60を使用して、同点を破ります。つまり、FEC1が勝つ。
The following example Illustrates incoming label collision resolution for different FEC types using the MCC administrative distance.
次の例は、MCCアドミニストレーティブディスタンスを使用した、さまざまなFECタイプの着信ラベル衝突解決を示しています。
FEC1:
FEC1;
Node A receives an OSPF Prefix-SID Advertisement from Node B for 198.51.100.6/32 with index=6. Assuming that OSPF SRGB on Node A = [1000,1999], the incoming label on Node A corresponding to 198.51.100.6/32 is 1006.
ノードAは、ノードBから198.51.100.6/32のOSPF Prefix-SIDアドバタイズメントをインデックス= 6で受信します。ノードAのOSPF SRGB = [1000,1999]とすると、198.51.100.6 / 32に対応するノードAの着信ラベルは1006です。
FEC2:
道楽：
IS-IS on Node A assigns label 1006 to the globally significant Adj-SID (i.e., when advertised, the L-Flag is clear in the Adj-SID sub-TLV as described in [RFC8667]). Hence, the incoming label corresponding to this Adj-SID is 1006. Assume Node A allocates this Adj-SID dynamically, and it may differ across router reboots.
ノードAのIS-ISは、ラベル1006をグローバルに有効なAdj-SIDに割り当てます（つまり、アドバタイズされると、L-Flagは[RFC8667]で説明されているように、Adj-SIDサブTLVでクリアされます）。したがって、このAdj-SIDに対応する着信ラベルは1006です。ノードAがこのAdj-SIDを動的に割り当てると想定します。これは、ルーターの再起動によって異なる場合があります。
FEC1 and FEC2 both use dynamic SID assignment. Since neither of the FECs are of type 'SR Policy', we use the default admin distances of 50 and 60 to break the tie. So FEC1 wins.
FEC1とFEC2はどちらも動的SID割り当てを使用します。どちらのFECも「SRポリシー」タイプではないため、デフォルトの管理距離である50と60を使用して、同点を破ります。つまり、FEC1が勝つ。
The following example illustrates incoming label collision resolution based on preferring static over dynamic SID assignment.
次の例は、動的SID割り当てよりも静的を優先することに基づく着信ラベル衝突解決を示しています。
FEC1:
FEC1;
OSPF on Node A receives a Prefix-SID Advertisement from Node B for
198.51.100.7/32 with index=7. Assuming that the OSPF SRGB on Node A
= [1000,1999], the incoming label corresponding to 198.51.100.7/32 is
1007.
FEC2:
道楽：
The operator on Node A configures IS-IS on Node A to assign label 1007 to the globally significant Adj-SID (i.e., when advertised, the L-Flag is clear in the Adj-SID sub-TLV as described in [RFC8667]).
ノードAのオペレーターは、ノードAのIS-ISを構成して、ラベル1007をグローバルに重要なAdj-SIDに割り当てます（つまり、アドバタイズされると、[RFC8667]で説明されているように、Adj-SIDサブTLVでLフラグがクリアされます） 。
Node A assigns this Adj-SID explicitly via configuration, so the Adj-SID survives router reboots.
ノードAはこのAdj-SIDを構成を介して明示的に割り当てるため、Adj-SIDはルーターの再起動後も存続します。
FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID assignment. So FEC2 wins.
FEC1は動的SID割り当てを使用し、FEC2は明示的なSID割り当てを使用します。したがって、FEC2が優先されます。
The following example illustrates incoming label collision resolution using FEC type default administrative distance.
次の例は、FECタイプのデフォルトのアドミニストレーティブディスタンスを使用した着信ラベルの衝突解決を示しています。
FEC1:
FEC1;
OSPF on Node A receives a Prefix-SID Advertisement from Node B for 198.51.100.8/32 with index=8. Assuming that OSPF SRGB on Node A = [1000,1999], the incoming label corresponding to 198.51.100.8/32 is 1008.
ノードAのOSPFは、index = 8の198.51.100.8/32のノードBからPrefix-SIDアドバタイズを受信します。ノードAのOSPF SRGB = [1000,1999]とすると、198.51.100.8 / 32に対応する着信ラベルは1008です。
FEC2:
道楽：
Suppose the SR Policy Advertisement from the controller to Node A for the policy identified by (Endpoint = 192.0.2.208, color = 100) that consists of SID-List=<S1, S2> assigns the globally significant Binding-SID label 1008.
SID-List = <S1、S2>で構成される（Endpoint = 192.0.2.208、color = 100）で識別されるポリシーのコントローラーからノードAへのSRポリシーアドバタイズメントが、グローバルに有効なBinding-SIDラベル1008を割り当てるとします。
From the point of view of Node A, FEC1 and FEC2 both use dynamic SID assignment. Based on the default administrative distance outlined in Section 2.5.1, the Binding SID has a higher administrative distance than the Prefix-SID; hence, FEC1 wins.
ノードAの観点からは、FEC1とFEC2の両方が動的SID割り当てを使用します。セクション2.5.1で概説されているデフォルトのアドミニストレーティブディスタンスに基づいて、バインディングSIDはプレフィックスSIDよりもアドミニストレーティブディスタンスが高くなっています。したがって、FEC1が優先されます。
The following example illustrates incoming label collision resolution based on FEC type preference.
次の例は、FECタイプ設定に基づく着信ラベルの衝突解決を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
203.0.113.110/32 with index=10. Assuming that the IS-IS SRGB on Node
A = [1000,1999], the incoming label corresponding to 203.0.113.110/32
is 1010.
FEC2:
道楽：
IS-IS on Node A assigns label 1010 to the globally significant Adj-SID (i.e., when advertised, the L-Flag is clear in the Adj-SID sub-TLV as described in [RFC8667]).
ノードAのIS-ISは、ラベル1010をグローバルに有効なAdj-SIDに割り当てます（つまり、アドバタイズされたとき、L-Flagは[RFC8667]で説明されているように、Adj-SIDサブTLVでクリアされます）。
Node A allocates this Adj-SID dynamically, and it may differ across router reboots. Hence, both FEC1 and FEC2 both use dynamic SID assignment.
ノードAはこのAdj-SIDを動的に割り当て、ルーターの再起動によって異なる場合があります。したがって、FEC1とFEC2はどちらも動的SID割り当てを使用します。
Since both FECs are from the same MCC, they have the same default admin distance. So we compare the FEC type codepoints. FEC1 has FEC type codepoint=120, while FEC2 has FEC type codepoint=130. Therefore, FEC1 wins.
両方のFECは同じMCCからのものであるため、デフォルトの管理距離は同じです。そこで、FECタイプのコードポイントを比較します。 FEC1のFECタイプコードポイントは120ですが、FEC2のFECタイプコードポイントは130です。したがって、FEC1が優先されます。
The following example illustrates incoming label collision resolution based on address family preference.
次の例は、アドレスファミリ設定に基づく着信ラベル衝突解決を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
203.0.113.111/32 with index=11. Assuming that the IS-IS SRGB on Node
A = [1000,1999], the incoming label on Node A for 203.0.113.111/32 is
1011.
FEC2:
道楽：
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
2001:DB8:1000::11/128 with index=11. Assuming that the IS-IS SRGB on
Node A = [1000,1999], the incoming label on Node A for
2001:DB8:1000::11/128 is 1011.
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare the FEC type codepoints. Both FECs have FEC type codepoint=120. So we compare the address family. Since IPv4 is preferred over IPv6, FEC1 wins.
FEC1とFEC2はどちらも動的SID割り当てを使用します。両方のFECは同じMCCからのものであるため、デフォルトの管理距離は同じです。そこで、FECタイプのコードポイントを比較します。両方のFECのFECタイプコードポイントは120です。そこで、アドレスファミリを比較します。 IPv4よりもIPv6が優先されるため、FEC1が優先されます。
The following example illustrates incoming label collision resolution based on prefix length.
次の例は、プレフィックス長に基づく着信ラベル衝突解決を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for 203.0.113.112/32 with index=12. Assuming that IS-IS SRGB on Node A = [1000,1999], the incoming label for 203.0.113.112/32 on Node A is 1012.
ノードAのIS-ISは、ノードBから203.0.113.112/32のプレフィックスSIDアドバタイズメントをインデックス= 12で受信します。ノードAのIS-IS SRGB = [1000,1999]とすると、ノードAの203.0.113.112/32の着信ラベルは1012です。
FEC2:
道楽：
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
203.0.113.128/30 with index=12. Assuming that the IS-IS SRGB on Node
A = [1000,1999], the incoming label for 203.0.113.128/30 on Node A is
1012.
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare the FEC type codepoints. Both FECs have FEC type codepoint=120. So we compare the address family. Both are a part of the IPv4 address family, so we compare the prefix length. FEC1 has prefix length=32, and FEC2 has prefix length=30, so FEC2 wins.
FEC1とFEC2はどちらも動的SID割り当てを使用します。両方のFECは同じMCCからのものであるため、デフォルトの管理距離は同じです。そこで、FECタイプのコードポイントを比較します。両方のFECのFECタイプコードポイントは120です。そこで、アドレスファミリを比較します。どちらもIPv4アドレスファミリの一部なので、プレフィックス長を比較します。 FEC1のプレフィックス長は32で、FEC2のプレフィックス長は30であるため、FEC2が優先されます。
The following example illustrates incoming label collision resolution based on the numerical value of the FECs.
次の例は、FECの数値に基づく着信ラベル衝突解決を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for 203.0.113.113/32 with index=13. Assuming that IS-IS SRGB on Node A = [1000,1999], the incoming label for 203.0.113.113/32 on Node A is 1013.
ノードAのIS-ISは、ノードBから203.0.113.113/32のプレフィックスSIDアドバタイズメントをインデックス= 13で受信します。ノードAのIS-IS SRGB = [1000,1999]とすると、ノードAの203.0.113.113/32の着信ラベルは1013です。
FEC2:
道楽：
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for 203.0.113.213/32 with index=13. Assuming that IS-IS SRGB on Node A = [1000,1999], the incoming label for 203.0.113.213/32 on Node A is 1013.
ノードAのIS-ISは、ノードCから203.0.113.213/32のプレフィックスSIDアドバタイズメントをインデックス= 13で受信します。ノードAのIS-IS SRGB = [1000,1999]とすると、ノードAの203.0.113.213/32の着信ラベルは1013です。
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare the FEC type codepoints. Both FECs have FEC type codepoint=120. So we compare the address family. Both are a part of the IPv4 address family, so we compare the prefix length. Prefix lengths are the same, so we compare the prefix. FEC1 has the lower prefix, so FEC1 wins.
FEC1とFEC2はどちらも動的SID割り当てを使用します。両方のFECは同じMCCからのものであるため、デフォルトの管理距離は同じです。そこで、FECタイプのコードポイントを比較します。両方のFECのFECタイプコードポイントは120です。そこで、アドレスファミリを比較します。どちらもIPv4アドレスファミリの一部なので、プレフィックス長を比較します。プレフィックスの長さが同じなので、プレフィックスを比較します。 FEC1の方がプレフィックスが低いため、FEC1が優先されます。
The following example illustrates incoming label collision resolution based on the Routing Instance ID.
次の例は、ルーティングインスタンスIDに基づく着信ラベル衝突解決を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
203.0.113.114/32 with index=14. Assume that this IS-IS instance on
Node A has Routing Instance ID = 1000 and SRGB = [1000,1999]. Hence,
the incoming label for 203.0.113.114/32 on Node A is 1014.
FEC2:
道楽：
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
203.0.113.114/32 with index=14. Assume that this is another instance
of IS-IS on Node A but Routing Instance ID = 2000 is different and
SRGB = [1000,1999] is the same. Hence, the incoming label for
203.0.113.114/32 on Node A is 1014.
These two FECs match all the way through the prefix length and prefix. So the Routing Instance ID breaks the tie, and FEC1 wins.
これらの2つのFECは、プレフィックス長とプレフィックスを通じて完全に一致します。そのため、ルーティングインスタンスIDが同点となり、FEC1が優先されます。
The following example illustrates incoming label collision resolution based on the topology ID.
次の例は、トポロジIDに基づく着信ラベルの衝突解決を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
203.0.113.115/32 with index=15. Assume that this IS-IS instance on
Node A has Routing Instance ID = 1000. Assume that the prefix
advertisement of 203.0.113.115/32 was received in the IS-IS Multi-
topology advertisement with ID = 50. If the IS-IS SRGB for this
routing instance on Node A = [1000,1999], then the incoming label of
203.0.113.115/32 for topology 50 on Node A is 1015.
FEC2:
道楽：
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
203.0.113.115/32 with index=15. Assume that it has the same Routing
Instance ID = 1000, but 203.0.113.115/32 was advertised with IS-IS
Multi-topology ID = 40, which is different. If the IS-IS SRGB on
Node A = [1000,1999], then the incoming label of 203.0.113.115/32 for
topology 40 on Node A is also 1015.
Since these two FECs match all the way through the prefix length, prefix, and Routing Instance ID, we compare the IS-IS Multi-topology ID, so FEC2 wins.
これらの2つのFECは、プレフィックス長、プレフィックス、ルーティングインスタンスIDを通じて完全に一致するため、IS-ISマルチトポロジIDを比較して、FEC2が優先されます。
The following example illustrates incoming label collision for resolution based on the algorithm ID.
次の例は、アルゴリズムIDに基づく解決のための着信ラベル衝突を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
203.0.113.116/32 with index=16. Assume that IS-IS on Node A has
Routing Instance ID = 1000. Assume that Node B advertised
203.0.113.116/32 with IS-IS Multi-topology ID = 50 and SR algorithm =
0. Assume that the IS-IS SRGB on Node A = [1000,1999]. Hence, the
incoming label corresponding to this advertisement of
203.0.113.116/32 is 1016.
FEC2:
道楽：
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
203.0.113.116/32 with index=16. Assume that it is the same IS-IS
instance on Node A with Routing Instance ID = 1000. Also assume that
Node C advertised 203.0.113.116/32 with IS-IS Multi-topology ID = 50
but with SR algorithm = 22. Since it is the same routing instance,
the SRGB on Node A = [1000,1999]. Hence, the incoming label
corresponding to this advertisement of 203.0.113.116/32 by Node C is
also 1016.
Since these two FECs match all the way through in terms of the prefix length, prefix, Routing Instance ID, and Multi-topology ID, we compare the SR algorithm IDs, so FEC1 wins.
これら2つのFECは、プレフィックス長、プレフィックス、ルーティングインスタンスID、およびマルチトポロジIDの点で完全に一致するため、SRアルゴリズムIDを比較し、FEC1が優先されます。
The following example illustrates incoming label collision resolution based on the FEC numerical value, independent of how the SID is assigned to the colliding FECs.
次の例は、SIDが衝突するFECにどのように割り当てられているかに関係なく、FEC数値に基づく着信ラベル衝突解決を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
203.0.113.117/32 with index=17. Assume that the IS-IS SRGB on Node A
= [1000,1999]; thus, the incoming label is 1017.
FEC2:
道楽：
Suppose there is an IS-IS Mapping Server Advertisement (SID / Label
Binding TLV) from Node D that has range = 100 and prefix =
203.0.113.1/32. Suppose this Mapping Server Advertisement generates
100 mappings, one of which maps 203.0.113.17/32 to index=17.
Assuming that it is the same IS-IS instance, the SRGB = [1000,1999]
and hence the incoming label for 1017.
Even though FEC1 comes from a normal Prefix-SID Advertisement and FEC2 is generated from a Mapping Server Advertisement, it is not used as a tiebreaking parameter. Both FECs use dynamic SID assignment, are from the same MCC, and have the same FEC type codepoint=120. Their prefix lengths are the same as well. FEC2 wins based on its lower numerical prefix value, since 203.0.113.17 is less than 203.0.113.117.
FEC1は通常のプレフィックスSIDアドバタイズメントから取得され、FEC2はマッピングサーバーアドバタイズメントから生成されますが、タイブレーキングパラメーターとしては使用されません。両方のFECは動的SID割り当てを使用し、同じMCCからのものであり、同じFECタイプcodepoint = 120を持っています。接頭辞の長さも同じです。 203.0.113.17は203.0.113.117より小さいため、FEC2は、数値の小さいプレフィックス値に基づいて勝ちます。
The following example illustrates incoming label collision resolution based on address family preference.
次の例は、アドレスファミリ設定に基づく着信ラベル衝突解決を示しています。
FEC1:
FEC1;
SR Policy Advertisement from the controller to Node A. Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>, and the Binding-SID label=1020.
コントローラからノードAへのSRポリシーアドバタイズメント。エンドポイントアドレス= 2001：DB8：3000 :: 100、カラー= 100、SID-List = <S1、S2>、およびBinding-SIDラベル= 1020。
FEC2:
道楽：
SR Policy Advertisement from controller to Node A. Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4>, and the Binding-SID label=1020.
コントローラからノードAへのSRポリシーアドバタイズメント。エンドポイントアドレス= 192.0.2.60、カラー= 100、SID-List = <S3、S4>、およびBinding-SIDラベル= 1020。
The FEC tiebreakers match, and they have the same FEC type codepoint=140. Thus, FEC2 wins based on the IPv4 address family being preferred over IPv6.
FECタイブレーカーが一致し、それらは同じFECタイプcodepoint = 140を持っています。したがって、IPv6よりも優先されるIPv4アドレスファミリに基づいてFEC2が勝ちます。
The following example illustrates incoming label resolution based on the numerical value of the policy endpoint.
次の例は、ポリシーエンドポイントの数値に基づく着信ラベル解決を示しています。
FEC1:
FEC1;
SR Policy Advertisement from the controller to Node A. Endpoint address=192.0.2.70, color=100, SID-List=<S1, S2>, and Binding-SID label=1021.
コントローラからノードAへのSRポリシーアドバタイズメント。エンドポイントアドレス= 192.0.2.70、カラー= 100、SID-List = <S1、S2>、およびBinding-SIDラベル= 1021。
FEC2:
道楽：
SR Policy Advertisement from the controller to Node A. Endpoint address=192.0.2.71, color=100, SID-List=<S3, S4>, and Binding-SID label=1021.
コントローラからノードAへのSRポリシーアドバタイズメント。エンドポイントアドレス= 192.0.2.71、カラー= 100、SID-List = <S3、S4>、およびBinding-SIDラベル= 1021。
The FEC tiebreakers match, and they have the same address family. Thus, FEC1 wins by having the lower numerical endpoint address value.
FECタイブレーカーは一致し、それらは同じアドレスファミリーを持っています。したがって、FEC1は、エンドポイントアドレスの数値が小さい方が優先されます。
A.3. Examples for the Effect of Incoming Label Collision on an Outgoing Label
A.3. 発信ラベルに対する着信ラベルの衝突の影響の例
This section presents examples to illustrate the effect of incoming label collision on the selection of the outgoing label as described in Section 2.6.
このセクションでは、セクション2.6で説明されている、出力ラベルの選択に対する入力ラベルの衝突の影響を示す例を示します。
The following example illustrates the effect of incoming label resolution on the outgoing label.
次の例は、発信ラベルに対する着信ラベル解決の影響を示しています。
FEC1:
FEC1;
IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
203.0.113.122/32 with index=22. Assuming that the IS-IS SRGB on Node
A = [1000,1999], the corresponding incoming label is 1022.
FEC2:
道楽：
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
203.0.113.222/32 with index=22. Assuming that the IS-IS SRGB on Node
A = [1000,1999], the corresponding incoming label is 1022.
FEC1 wins based on the lowest numerical prefix value. This means that Node A installs a transit MPLS forwarding entry to swap incoming label 1022 with outgoing label N and to use outgoing interface I. N is determined by the index associated with FEC1 (index=22) and the SRGB advertised by the next-hop node on the shortest path to reach 203.0.113.122/32.
FEC1は、最小の数値プレフィックス値に基づいて勝ちます。つまり、ノードAは中継MPLS転送エントリをインストールして、着信ラベル1022を発信ラベルNと交換し、発信インターフェイスIを使用します。Nは、FEC1に関連付けられたインデックス（index = 22）とネクストホップによってアドバタイズされるSRGBによって決定されます203.0.113.122/32に到達する最短パス上のノード。
Node A will generally also install an imposition MPLS forwarding entry corresponding to FEC1 for incoming prefix=203.0.113.122/32 pushing outgoing label N, and using outgoing interface I.
ノードAは通常、着信プレフィックス= 203.0.113.122 / 32のFEC1に対応するインポジションMPLS転送エントリもインストールし、発信ラベルNをプッシュし、発信インターフェイスIを使用します。
The rule in Section 2.6 means Node A MUST NOT install an ingress MPLS forwarding entry corresponding to FEC2 (the losing FEC, which would be for prefix 203.0.113.222/32).
セクション2.6のルールは、ノードAがFEC2（失われたFEC、プレフィックス203.0.113.222/32の場合）に対応する入力MPLS転送エントリをインストールしてはならないことを意味します。
The following example illustrates the effect of incoming label collision resolution on outgoing label programming on Node A.
次の例は、ノードAでの発信ラベルプログラミングに対する着信ラベル衝突解決の影響を示しています。
FEC1:
FEC1;
SR Policy Advertisement from the controller to Node A. Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2>, and Binding-SID label=1023.
コントローラからノードAへのSRポリシーアドバタイズメント。エンドポイントアドレス= 192.0.2.80、カラー= 100、SID-List = <S1、S2>、Binding-SIDラベル= 1023。
FEC2:
道楽：
SR Policy Advertisement from controller to Node A. Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4>, and Binding-SID label=1023.
コントローラからノードAへのSRポリシーアドバタイズメント。エンドポイントアドレス= 192.0.2.81、カラー= 100、SID-List = <S3、S4>、およびBinding-SIDラベル= 1023。
FEC1 wins by having the lower numerical endpoint address value. This means that Node A installs a transit MPLS forwarding entry to swap incoming label=1023 with outgoing labels, and the outgoing interface is determined by the SID-List for FEC1.
FEC1は、エンドポイントアドレスの数値が小さい方が優先されます。これは、ノードAが中継MPLS転送エントリをインストールして、着信ラベル= 1023を発信ラベルと交換し、発信インターフェイスがFEC1のSIDリストによって決定されることを意味します。
In this example, we assume that Node A receives two BGP/VPN routes:
この例では、ノードAが2つのBGP / VPNルートを受信すると想定します。
* R1 with VPN label=V1, BGP next hop = 192.0.2.80, and color=100
* VPNラベル= V1、BGPネクストホップ= 192.0.2.80、色= 100のR1
* R2 with VPN label=V2, BGP next hop = 192.0.2.81, and color=100
* VPNラベル= V2、BGPネクストホップ= 192.0.2.81、色= 100のR2
We also assume that Node A has a BGP policy that matches color=100
and allows its usage as Service Level Agreement (SLA) steering
information. In this case, Node A will install a VPN route with
label stack = <S1,S2,V1> (corresponding to FEC1).
The rule described in Section 2.6 means that Node A MUST NOT install
a VPN route with label stack = <S3,S4,V1> (corresponding to FEC2.)
Acknowledgements
謝辞
The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on this document.
このドキュメントに関する貴重なコメントを提供してくれたLes Ginsberg、Chris Bowers、Himanshu Shah、Adrian Farrel、Alexander Vainshtein、Przemyslaw Krol、Darren Dukes、Zafar Ali、Martin Vigoureuxに感謝します。
Contributors
貢献者
The following contributors have substantially helped the definition and editing of the content of this document:
以下の寄稿者は、このドキュメントのコンテンツの定義と編集に大きく貢献しています。
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 Email: saku@ytti.fi
Saku Yttiメール：saku@ytti.fi
Authors' Addresses
著者のアドレス
Ahmed Bashandy (editor) Arrcus
Ahmed Bashand（する必要があります）フォーカス
Email: abashandy.ietf@gmail.com
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（editor）Cisco Systems、Inc. Brussels Belgium
Email: cfilsfil@cisco.com
Stefano Previdi Cisco Systems, Inc. Italy
Stefano Previdi Cisco Systems、Inc.イタリア
Email: stefano@previdi.net
Bruno Decraene Orange France
Bruno Decraene Orange France
Email: bruno.decraene@orange.com
Stephane Litkowski Orange France
ステファンリトコウスキーオレンジフランス
Email: slitkows.ietf@gmail.com
Rob Shakir Google United States of America
Rob Shakir Googleアメリカ合衆国
Email: robjs@google.com