[要約] RFC 8661は、Segment Routing MPLSとLDPの相互運用性に関する規格であり、MPLSネットワークでのセグメントルーティングの実装をサポートします。このRFCの目的は、LDPとSegment Routing MPLSの統合を可能にし、ネットワークの柔軟性とスケーラビリティを向上させることです。
Internet Engineering Task Force (IETF) A. Bashandy, Ed.
Request for Comments: 8661 Individual
Category: Standards Track C. Filsfils, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
S. Previdi
Huawei Technologies
B. Decraene
S. Litkowski
Orange
December 2019
Segment Routing MPLS Interworking with LDP
LDPとのセグメントルーティングMPLSインターワーキング
Abstract
概要
A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows enforcing a flow through any topological path while maintaining per-flow state only at the ingress node to the SR domain.
セグメントルーティング（SR）ノードは、SRヘッダーをパケットの先頭に付加することにより、セグメントと呼ばれる制御された命令セットを通じてパケットを誘導します。セグメントは、トポロジーまたはサービスベースの任意の命令を表すことができます。 SRを使用すると、SRドメインへの入力ノードでのみフローごとの状態を維持しながら、トポロジパスを介してフローを適用できます。
The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing MPLS operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist.
セグメントルーティングアーキテクチャは、転送プレーンに変更を加えることなく、MPLSデータプレーンに直接適用できます。このドキュメントでは、LDPが展開されているネットワーク、およびSR対応ノードと非SR対応ノードが共存しているネットワークでのセグメントルーティングMPLSの動作について説明します。
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/rfc8661.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8661で入手できます。
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. SR-LDP Ships-in-the-Night Coexistence
2.1. MPLS2MPLS, MPLS2IP, and IP2MPLS Coexistence
3. SR and LDP Interworking
3.1. LDP to SR
3.1.1. LDP to SR Behavior
3.2. SR to LDP
3.2.1. Segment Routing Mapping Server (SRMS)
3.2.2. SR to LDP Behavior
3.2.3. Interoperability of Multiple SRMSes and Prefix-SID
Advertisements
4. SR-LDP Interworking Use Cases
4.1. SR Protection of LDP-Based Traffic
4.2. Eliminating Targeted LDP Sessions
4.3. Guaranteed FRR Coverage
4.4. Inter-AS Option C, Carrier's Carrier
5. IANA Considerations
6. Manageability Considerations
6.1. SR and LDP Coexistence
6.2. Data-Plane Verification
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Migration from LDP to SR
Acknowledgements
Contributors
Authors' Addresses
Segment Routing, as described in [RFC8402], can be used on top of the MPLS data plane without any modification as described in [RFC8660].
[RFC8402]で説明されているセグメントルーティングは、[RFC8660]で説明されているように、変更することなくMPLSデータプレーンの上で使用できます。
Segment Routing control plane can coexist with current label distribution protocols such as LDP [RFC5036].
セグメントルーティングコントロールプレーンは、LDP [RFC5036]などの現在のラベル配布プロトコルと共存できます。
This document outlines the mechanisms through which SR interworks with LDP in cases where a mix of SR-capable and non-SR-capable routers coexist within the same network and more precisely in the same routing domain.
このドキュメントでは、SR対応および非SR対応のルータが同じネットワーク内で、より正確には同じルーティングドメイン内で共存している場合に、SRがLDPと相互作用するメカニズムについて説明します。
Section 2 describes the coexistence of SR with other MPLS control-plane protocols. Section 3 documents the interworking between SR and LDP in the case of nonhomogeneous deployment. Section 4 describes how a partial SR deployment can be used to provide SR benefits to LDP-based traffic including a possible application of SR in the context of interdomain MPLS use cases. Appendix A documents a method to migrate from LDP to SR-based MPLS tunneling.
セクション2では、SRと他のMPLSコントロールプレーンプロトコルの共存について説明します。セクション3は、不均一な展開の場合のSRとLDP間の相互作用について説明します。セクション4では、部分的なSR展開を使用してLDPベースのトラフィックにSRの利点を提供する方法について説明します。これには、ドメイン間MPLSの使用例のコンテキストでSRの可能なアプリケーションが含まれます。付録Aでは、LDPからSRベースのMPLSトンネリングに移行する方法を説明しています。
Typically, an implementation will allow an operator to select (through configuration) which of the described modes of SR and LDP coexistence to use.
通常、実装では、SRとLDPの共存について説明されているモードのどれを使用するかを（構成を介して）オペレーターが選択できます。
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 Control-Plane Client (MCC)" refers to any control-plane protocol installing forwarding entries in the MPLS data plane. SR, LDP [RFC5036], RSVP-TE [RFC3209], BGP [RFC8277], etc., are examples of MCCs.
「MPLSコントロールプレーンクライアント（MCC）」とは、MPLSデータプレーンに転送エントリをインストールする任意のコントロールプレーンプロトコルを指します。 SR、LDP [RFC5036]、RSVP-TE [RFC3209]、BGP [RFC8277]などがMCCの例です。
An MCC, operating at Node N, must ensure that the incoming label it installs in the MPLS data plane of Node N has been uniquely allocated to itself.
ノードNで動作するMCCは、ノードNのMPLSデータプレーンにインストールする着信ラベルがそれ自体に一意に割り当てられていることを確認する必要があります。
Segment Routing makes use of the Segment Routing Global Block (SRGB, as defined in [RFC8402]) for the label allocation. The use of the SRGB allows SR to coexist with any other MCC.
セグメントルーティングは、セグメント割り当てグローバルブロック（[RFC8402]で定義されているSRGB）を使用してラベルを割り当てます。 SRGBを使用すると、SRを他のMCCと共存させることができます。
This is clearly the case for the adjacency segment: it is a local label allocated by the label manager, as is the case for any MCC.
これは明らかに隣接セグメントの場合です。これは、他のMCCの場合と同様に、ラベルマネージャーによって割り当てられたローカルラベルです。
This is clearly the case for the prefix segment: the label manager allocates the SRGB set of labels to the SR MCC client, and the operator ensures the unique allocation of each global prefix segment or label within the allocated SRGB set.
これは明らかにプレフィックスセグメントの場合です。ラベルマネージャーはSRGBセットのラベルをSR MCCクライアントに割り当て、オペレーターは割り当てられたSRGBセット内の各グローバルプレフィックスセグメントまたはラベルの一意の割り当てを保証します。
Note that this static label-allocation capability of the label manager has existed for many years across several vendors and is therefore not new. Furthermore, note that the label manager's ability to statically allocate a range of labels to a specific application is not new either. This is required for MPLS-TP operation. In this case, the range is reserved by the label manager, and it is the MPLS-TP [RFC5960] Network Management System (acting as an MCC) that ensures the unique allocation of any label within the allocated range and the creation of the related MPLS forwarding entry.
ラベルマネージャーのこの静的なラベル割り当て機能は、何年にもわたっていくつかのベンダーに存在しており、新しいものではないことに注意してください。さらに、特定のアプリケーションにラベルの範囲を静的に割り当てるラベルマネージャの機能も新しいものではないことに注意してください。これはMPLS-TP動作に必要です。この場合、範囲はラベルマネージャによって予約されており、割り当てられた範囲内のラベルの一意の割り当てと関連する作成を保証するのは、MPLS-TP [RFC5960]ネットワーク管理システム（MCCとして機能）です。 MPLS転送エントリ。
Let us illustrate an example of ship-in-the-night (SIN) coexistence.
Ship-in-the-night（SIN）共存の例を示します。
PE2 PE4
\ /
PE1----A----B---C---PE3
Figure 1: SIN Coexistence
図1：SINの共存
The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN service is supported by PE1 and PE3. The operator wants to tunnel the ODD service via LDP and the EVEN service via SR.
EVEN VPNサービスはPE2およびPE4でサポートされ、ODD VPNサービスはPE1およびPE3でサポートされます。オペレーターは、LDP経由のODDサービスとSR経由のEVENサービスをトンネリングしたいと考えています。
This can be achieved in the following manner:
これは、次の方法で実現できます。
* The operator configures PE1, PE2, PE3, and PE4 with respective loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, and 192.0.2.204/32. These PEs advertised their VPN routes with next hop set on their respective loopback address.
* オペレーターは、PE1、PE2、PE3、およびPE4をそれぞれループバック192.0.2.201/32、192.0.2.202/32、192.0.2.203/32、および192.0.2.204/32で構成します。これらのPEは、それぞれのループバックアドレスにネクストホップが設定されたVPNルートをアドバタイズしました。
* The operator configures A, B, C with respective loopbacks 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32.
* オペレーターはA、B、Cをそれぞれのループバック192.0.2.1/32、192.0.2.2/32、192.0.2.3/32で構成します。
* The operator configures PE2, A, B, C, and PE4 with SRGB [100, 300].
* オペレーターは、PE2、A、B、C、およびPE4をSRGB [100、300]で構成します。
* The operator attaches the respective Node Segment Identifiers (Node SIDs, as defined in [RFC8402]), 202, 101, 102, 103, and 204, to the loopbacks of nodes PE2, A, B, C, and PE4. The Node SIDs are configured to request Penultimate Hop Popping.
* オペレーターは、それぞれのノードセグメント識別子（[RFC8402]で定義されているノードSID）202、101、102、103、204をノードPE2、A、B、C、およびPE4のループバックに接続します。ノードSIDは、最後から2番目のホップポップを要求するように構成されています。
* PE1, A, B, C, and PE3 are LDP capable.
* PE1、A、B、C、およびPE3はLDP対応です。
* PE1 and PE3 are not SR capable.
* PE1とPE3はSR対応ではありません。
PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN label 10001.
PE3は、ネクストホップ192.0.2.203およびVPNラベル10001を使用して、ODD VPNルートをPE1に送信します。
From an LDP viewpoint, PE1 received an LDP label binding (1037) for a Forwarding Equivalence Class (FEC) 192.0.2.203/32 from its next-hop A; A received an LDP label binding (2048) for that FEC from its next-hop B; B received an LDP label binding (3059) for that FEC from its next-hop C; and C received implicit NULL LDP binding from its next-hop PE3.
LDPの観点から、PE1は、ネクストホップAからForwarding Equivalence Class（FEC）192.0.2.203/32のLDPラベルバインディング（1037）を受信しました。 Aは、ネクストホップBからそのFECのLDPラベルバインディング（2048）を受信しました。 Bは、ネクストホップCからそのFECのLDPラベルバインディング（3059）を受信しました。 Cは、ネクストホップPE3から暗黙のNULL LDPバインディングを受信しました。
As a result, PE1 sends its traffic to the ODD service route advertised by PE3 to next-hop A with two labels: the top label is 1037 and the bottom label is 10001. Node A swaps 1037 with 2048 and forwards to B; B swaps 2048 with 3059 and forwards to C; C pops 3059 and forwards to PE3.
その結果、PE1はそのトラフィックを、PE3によってアドバタイズされたODDサービスルートに、2つのラベルを持つ次のホップAに送信します。上部ラベルは1037で、下部ラベルは10001です。ノードAは1037を2048と交換し、Bに転送します。 Bは2048を3059と交換し、Cに転送します。 Cは3059をポップし、PE3に転送します。
PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN label 10002.
PE4は、ネクストホップ192.0.2.204およびVPNラベル10002のPE2にEVEN VPNルートを送信します。
From an SR viewpoint, PE2 maps the IGP route 192.0.2.204/32 onto Node SID 204; Node A swaps 204 with 204 and forwards to B; B swaps 204 with 204 and forwards to C; and C pops 204 and forwards to PE4.
SRの観点から、PE2はIGPルート192.0.2.204/32をノードSID 204にマッピングします。ノードAは204を204と交換し、Bに転送します。 Bは204を204と交換し、Cに転送します。 Ｃは２０４をポップし、ＰＥ４に転送する。
As a result, PE2 sends its traffic to the VPN service route advertised by PE4 to next-hop A with two labels: the top label is 204 and the bottom label is 10002. Node A swaps 204 with 204 and forwards to B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards to PE4.
その結果、PE2は、PE4によってアドバタイズされたVPNサービスルートにトラフィックを送信し、次の2つのラベルを付けて次のホップAに送信します。 204は204でCに転送されます。Cは204をポップし、PE4に転送します。
The two modes of MPLS tunneling coexist.
MPLSトンネリングの2つのモードが共存します。
* The ODD service is tunneled from PE1 to PE3 through a continuous LDP LSP traversing A, B, and C.
* ODDサービスは、A、B、Cを通過する継続的なLDP LSPを介してPE1からPE3にトンネリングされます。
* The EVEN service is tunneled from PE2 to PE4 through a continuous SR node segment traversing A, B, and C.
* EVENサービスは、A、B、Cを通過する継続的なSRノードセグメントを介してPE2からPE4にトンネリングされます。
MPLS2MPLS refers to the forwarding behavior where a router receives a labeled packet and switches it out as a labeled packet. Several MPLS2MPLS entries may be installed in the data plane for the same prefix.
MPLS2MPLSは、ルーターがラベル付きパケットを受信し、ラベル付きパケットとしてスイッチアウトする転送動作を指します。同じプレフィックスのデータプレーンに複数のMPLS2MPLSエントリをインストールできます。
Let us examine A's MPLS forwarding table as an example:
例として、AのMPLS転送テーブルを調べてみましょう。
Incoming label: 1037
受信ラベル：1037
- Outgoing label: 2048
- 送信ラベル：2048
- Outgoing next hop: B
- 発信ネクストホップ：B
Note: This entry is programmed by LDP for 192.0.2.203/32.
注：このエントリは、192.0.2.203 / 32のLDPによってプログラムされています。
Incoming label: 203
受信ラベル：203
- Outgoing label: 203
- 送信ラベル：203
- Outgoing next hop: B
- 発信ネクストホップ：B
Note: This entry is programmed by SR for 192.0.2.203/32.
注：このエントリは、SRによって192.0.2.203/32用にプログラムされています。
These two entries can coexist because their incoming label is unique. The uniqueness is guaranteed by the label manager allocation rules.
これら2つのエントリは、着信ラベルが一意であるため、共存できます。一意性は、ラベルマネージャの割り当てルールによって保証されます。
The same applies for the MPLS2IP forwarding entries. MPLS2IP is the forwarding behavior where a router receives a labeled IPv4/IPv6 packet with one label only, pops the label, and switches the packet out as IPv4/IPv6. For IP2MPLS coexistence, refer to Section 6.1.
同じことがMPLS2IP転送エントリにも適用されます。 MPLS2IPは、ルーターが1つのラベルのみのラベル付きIPv4 / IPv6パケットを受信し、ラベルをポップして、パケットをIPv4 / IPv6として切り替える転送動作です。 IP2MPLSの共存については、セクション6.1を参照してください。
This section analyzes the case where SR is available in one part of the network and LDP is available in another part. It describes how a continuous MPLS tunnel can be built throughout the network.
このセクションでは、ネットワークの一部でSRが利用可能で、別の部分でLDPが利用可能であるケースを分析します。ネットワーク全体で継続的なMPLSトンネルを構築する方法について説明します。
PE2 PE4
\ /
PE1----P5--P6--P7--P8---PE3
<-----SR---->
<------LDP------>
Figure 2: SR and LDP Interworking
図2：SRとLDPのインターワーキング
Let us analyze the following example:
次の例を分析してみましょう。
* P6, P7, P8, PE4, and PE3 are LDP capable.
* P6、P7、P8、PE4、およびPE3はLDP対応です。
* PE1, PE2, P5, and P6 are SR capable. PE1, PE2, P5, and P6 are configured with SRGB (100, 200) and with node segments 101, 102, 105, and 106, respectively.
* PE1、PE2、P5、およびP6はSR対応です。 PE1、PE2、P5、およびP6は、それぞれSRGB（100、200）およびノードセグメント101、102、105、106で構成されています。
* A service flow must be tunneled from PE1 to PE3 over a continuous MPLS tunnel encapsulation; therefore, SR and LDP need to interwork.
* サービスフローは、継続的なMPLSトンネルカプセル化を介してPE1からPE3にトンネリングする必要があります。したがって、SRとLDPは連携する必要があります。
In this section, a right-to-left traffic flow is analyzed.
このセクションでは、右から左へのトラフィックフローを分析します。
PE3 has learned a service route whose next hop is PE1. PE3 has an LDP label binding from the next-hop P8 for the FEC "PE1". Therefore, PE3 sends its service packet to P8 as per classic LDP behavior.
PE3は、ネクストホップがPE1であるサービスルートを学習しました。 PE3には、FEC "PE1"のネクストホップP8からのLDPラベルバインディングがあります。したがって、PE3は、従来のLDP動作に従って、サービスパケットをP8に送信します。
P8 has an LDP label binding from its next-hop P7 for the FEC "PE1" and therefore, P8 forwards to P7 as per classic LDP behavior.
P8には、FEC "PE1"のネクストホップP7からのLDPラベルバインディングがあるため、従来のLDP動作に従ってP8がP7に転送されます。
P7 has an LDP label binding from its next-hop P6 for the FEC "PE1" and therefore, P7 forwards to P6 as per classic LDP behavior.
P7には、FEC "PE1"のネクストホップP6からのLDPラベルバインディングがあるため、P7は従来のLDP動作に従ってP6に転送します。
P6 does not have an LDP binding from its next-hop P5 for the FEC "PE1". However, P6 has an SR node segment to the IGP route "PE1". Hence, P6 forwards the packet to P5 and swaps its local LDP label for FEC "PE1" by the equivalent node segment (i.e., 101).
P6には、FEC "PE1"のネクストホップP5からのLDPバインディングがありません。ただし、P6には、IGPルート「PE1」へのSRノードセグメントがあります。したがって、P6はパケットをP5に転送し、FEC "PE1"のローカルLDPラベルを同等のノードセグメント（つまり、101）でスワップします。
P5 pops 101 (assuming PE1 advertised its node segment 101 with the penultimate-pop flag set) and forwards to PE1.
P5は101をポップし（PE1が最後から2番目のポップフラグが設定されたノードセグメント101をアドバタイズした場合）、PE1に転送します。
PE1 receives the tunneled packet and processes the service label.
PE1はトンネルされたパケットを受信し、サービスラベルを処理します。
The end-to-end MPLS tunnel is built by stitching an LDP LSP from PE3 to P6 and the related node segment from P6 to PE1.
エンドツーエンドのMPLSトンネルは、LDP LSPをPE3からP6に、関連するノードセグメントをP6からPE1にステッチすることによって構築されます。
It has to be noted that no additional signaling or state is required in order to provide interworking in the direction LDP to SR.
LDPからSRへの方向にインターワーキングを提供するために、追加のシグナリングや状態は必要ないことに注意してください。
An SR node having LDP neighbors MUST create LDP bindings for each Prefix-SID learned in the SR domain by treating SR-learned labels as if they were learned through an LDP neighbor. In addition, for each FEC, the SR node stitches the incoming LDP label to the outgoing SR label. This has to be done in both LDP-independent and ordered label distribution control modes as defined in [RFC5036].
LDPネイバーを持つSRノードは、SR学習ラベルをLDPネイバーを通じて学習されたかのように扱うことにより、SRドメインで学習された各Prefix-SIDのLDPバインディングを作成する必要があります。さらに、各FECについて、SRノードは着信LDPラベルを発信SRラベルにステッチします。これは、[RFC5036]で定義されているLDPに依存しないモードと順序付きラベル配布制御モードの両方で実行する必要があります。
In this section, the left-to-right traffic flow is analyzed.
このセクションでは、左から右へのトラフィックフローが分析されます。
This section defines the Segment Routing Mapping Server (SRMS). The SRMS is an IGP node advertising mapping between Segment Identifiers (SID) and prefixes advertised by other IGP nodes. The SRMS uses a dedicated IGP extension (IS-IS, OSPFv2, and OSPFv3), which is protocol specific and defined in [RFC8665], [RFC8666], and [RFC8667].
このセクションでは、セグメントルーティングマッピングサーバー（SRMS）を定義します。 SRMSは、セグメント識別子（SID）と他のIGPノードによってアドバタイズされるプレフィックス間のマッピングをアドバタイズするIGPノードです。 SRMSは専用のIGP拡張機能（IS-IS、OSPFv2、およびOSPFv3）を使用します。これはプロトコル固有であり、[RFC8665]、[RFC8666]、および[RFC8667]で定義されています。
The SRMS function of an SR-capable router allows distribution of mappings for prefixes not locally attached to the advertising router and therefore allows advertisement of mappings on behalf of non-SR-capable routers.
SR対応ルーターのSRMS機能により、アドバタイズルーターにローカルに接続されていないプレフィックスのマッピングを配布できるため、SR非対応ルーターに代わってマッピングのアドバタイズが可能になります。
The SRMS is a control-plane-only function that may be located anywhere in the IGP flooding scope. At least one SRMS server MUST exist in a routing domain to advertise Prefix-SIDs on behalf of non-SR nodes, thereby allowing non-LDP routers to send and receive labeled traffic from LDP-only routers. Multiple SRMSes may be present in the same network (for redundancy). This implies that there are multiple ways a prefix-to-SID mapping can be advertised. Conflicts resulting from inconsistent advertisements are addressed by [RFC8660].
SRMSは、コントロールプレーンのみの機能であり、IGPフラッディングスコープの任意の場所に配置できます。非SRノードに代わってPrefix-SIDをアドバタイズするには、ルーティングドメインに少なくとも1つのSRMSサーバーが存在する必要があります。これにより、非LDPルーターがLDP専用ルーターからラベル付きトラフィックを送受信できるようになります。複数のSRMSが同じネットワークに存在する場合があります（冗長性のため）。これは、プレフィックスからSIDへのマッピングを通知する方法が複数あることを意味します。一貫性のない広告による競合は[RFC8660]で対処されます。
The example depicted in Figure 2 assumes that the operator configures P5 to act as a Segment Routing Mapping Server and advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103), and (PE4, 104).
図2に示す例では、オペレーターがセグメントルーティングマッピングサーバーとして機能するようにP5を構成し、（P7、107）、（P8、108）、（PE3、103）、および（PE4、104）のマッピングをアドバタイズすると想定しています。 。
The mappings advertised by one or more SRMSes result from local policy information configured by the operator.
1つ以上のSRMSによってアドバタイズされるマッピングは、オペレーターによって構成されたローカルポリシー情報から生じます。
If PE3 had been SR capable, the operator would have configured PE3 with node segment 103. Instead, as PE3 is not SR capable, the operator configures that policy at the SRMS and it is the latter that advertises the mapping.
PE3がSR対応であった場合、オペレーターはノードセグメント103でPE3を構成します。代わりに、PE3はSR対応ではないため、オペレーターはSRMSでそのポリシーを構成し、マッピングをアドバタイズするのは後者です。
The Mapping Server Advertisements are only understood by SR-capable routers. The SR-capable routers install the related node segments in the MPLS data plane exactly like the node segments had been advertised by the nodes themselves.
マッピングサーバーアドバタイズメントは、SR対応ルーターによってのみ認識されます。 SR対応ルーターは、ノードセグメントがノード自体によってアドバタイズされたのとまったく同じように、関連するノードセグメントをMPLSデータプレーンにインストールします。
For example, PE1 installs the node segment 103 with next-hop P5 exactly as if PE3 had advertised node segment 103.
たとえば、PE1は、PE3がノードセグメント103をアドバタイズした場合とまったく同じように、ノードセグメント103にネクストホップP5をインストールします。
PE1 has a service route whose next hop is PE3. PE1 has a node segment for that IGP route: 103 with next-hop P5. Hence, PE1 sends its service packet to P5 with two labels: the bottom label is the service label and the top label is 103.
PE1には、ネクストホップがPE3であるサービスルートがあります。 PE1には、そのIGPルートのノードセグメントがあり、103がネクストホップP5です。したがって、PE1は2つのラベルを持つサービスパケットをP5に送信します。下部のラベルはサービスラベルで、上部のラベルは103です。
P5 swaps 103 for 103 and forwards to P6.
P5は103を103に交換し、P6に転送します。
P6's next hop for the IGP route "PE3" is not SR capable (P7 does not advertise the SR capability). However, P6 has an LDP label binding from that next hop for the same FEC (e.g., LDP label 1037). Hence, P6 swaps 103 for 1037 and forwards to P7.
IGPルート「PE3」のP6のネクストホップはSR対応ではありません（P7はSR機能をアドバタイズしません）。ただし、P6には、同じFECの次のホップからのLDPラベルバインディングがあります（LDPラベル1037など）。したがって、P6は103を1037にスワップし、P7に転送します。
P7 swaps this label with the LDP label received from P8 and forwards to P8.
P7はこのラベルをP8から受信したLDPラベルと交換し、P8に転送します。
P8 pops the LDP label and forwards to PE3.
P8はLDPラベルをポップし、PE3に転送します。
PE3 receives the tunneled packet and processes the service label.
PE3はトンネルされたパケットを受信し、サービスラベルを処理します。
The end-to-end MPLS tunnel is built by stitching an SR node segment from PE1 to P6 and an LDP LSP from P6 to PE3.
エンドツーエンドのMPLSトンネルは、SR1ノードセグメントをPE1からP6に、LDP LSPをP6からPE3にステッチすることによって構築されます。
SR-mapping advertisement for a given prefix provides no information about Penultimate Hop Popping. Other mechanisms, such as IGP-specific mechanisms ([RFC8665], [RFC8666], and [RFC8667]), MAY be used to determine the Penultimate Hop Popping in such case.
特定のプレフィックスのSRマッピングアドバタイズには、最後から2番目のホップポッピングに関する情報はありません。 IGP固有のメカニズム（[RFC8665]、[RFC8666]、および[RFC8667]）などの他のメカニズムを使用して、そのような場合の最後から2番目のホップポッピングを決定できます。
| Note: In the previous example, Penultimate Hop Popping is not
| performed at the SR-LDP border for segment 103 (PE3), because
| none of the routers in the SR domain are Penultimate Hop for
| segment 103. In this case, P6 requires the presence of the
| segment 103 such as to map it to the LDP label 1037.
This section specifies the concept and externally visible functionality of a Segment Routing Mapping Server (SRMS).
このセクションでは、セグメントルーティングマッピングサーバー（SRMS）の概念と外部から見える機能について説明します。
The purpose of SRMS functionality is to support the advertisement of Prefix-SIDs to a prefix without the need to explicitly advertise such assignment within a prefix reachability advertisement. Examples of explicit Prefix-SID Advertisement are the Prefix-SID sub-TLVs defined in [RFC8665], [RFC8666], and [RFC8667].
SRMS機能の目的は、プレフィックス到達可能性アドバタイズメント内でそのような割り当てを明示的にアドバタイズする必要なく、プレフィックスへのプレフィックスSIDのアドバタイズをサポートすることです。明示的なPrefix-SIDアドバタイズメントの例は、[RFC8665]、[RFC8666]、および[RFC8667]で定義されているPrefix-SIDサブTLVです。
The SRMS functionality allows assigning of Prefix-SIDs to prefixes owned by non-SR-capable routers as well as to prefixes owned by SR-capable nodes. It is the former capability that is essential to the SR-LDP interworking described later in this section.
SRMS機能により、SR非対応ルーターが所有するプレフィックスとSR対応ノードが所有するプレフィックスにPrefix-SIDを割り当てることができます。これは、このセクションで後述するSR-LDPインターワーキングに不可欠な前者の機能です。
The SRMS functionality consists of two functional blocks: the Mapping Server (MS) and Mapping Client (MC).
SRMS機能は、マッピングサーバー（MS）とマッピングクライアント（MC）の2つの機能ブロックで構成されています。
An MS is a node that advertises an SR mappings. Advertisements sent by an MS define the assignment of a Prefix-SID to a prefix independent of the advertisement of reachability to the prefix itself. An MS MAY advertise SR mappings for any prefix whether or not it advertises reachability for the prefix and irrespective of whether that prefix is advertised by or even reachable through any router in the network.
MSは、SRマッピングをアドバタイズするノードです。 MSによって送信されるアドバタイズメントは、プレフィックス自体への到達可能性のアドバタイズメントとは無関係に、プレフィックスへのPrefix-SIDの割り当てを定義します。 MSは、プレフィックスの到達可能性をアドバタイズするかどうかに関係なく、そのプレフィックスがネットワーク内のルーターによってアドバタイズされるか、または到達可能かどうかに関係なく、プレフィックスのSRマッピングをアドバタイズできます（MAY）。
An MC is a node that receives and uses the MS mapping advertisements. Note that a node may be both an MS and an MC. An MC interprets the SR-mapping advertisement as an assignment of a Prefix-SID to a prefix. For a given prefix, if an MC receives an SR-mapping advertisement from a Mapping Server and also has received a Prefix-SID Advertisement for that same prefix in a prefix reachability advertisement, then the MC MUST prefer the SID advertised in the prefix reachability advertisement over the Mapping Server Advertisement, i.e., the Mapping Server Advertisement MUST be ignored for that prefix. Hence, assigning a Prefix-SID to a prefix using the SRMS functionality does not preclude assigning the same or different Prefix-SID(s) to the same prefix using explicit Prefix-SID Advertisement such as the aforementioned Prefix-SID sub-TLVs.
MCは、MSマッピングアドバタイズを受信して使用するノードです。ノードはMSとMCの両方になる場合があることに注意してください。 MCは、SRマッピングアドバタイズをプレフィックスへのプレフィックスSIDの割り当てとして解釈します。特定のプレフィックスについて、MCがマッピングサーバーからSRマッピングアドバタイズを受信し、プレフィックス到達可能性アドバタイズメントで同じプレフィックスのPrefix-SIDアドバタイズメントも受信した場合、MCはプレフィックス到達可能性アドバタイズメントでアドバタイズされるSIDを優先する必要があります。つまり、マッピングサーバーアドバタイズメントを介して、つまりマッピングサーバーアドバタイズメントは、そのプレフィックスでは無視する必要があります。したがって、SRMS機能を使用してPrefix-SIDをプレフィックスに割り当てることは、前述のPrefix-SIDサブTLVなどの明示的なPrefix-SIDアドバタイズメントを使用して同じプレフィックスに同じまたは異なるPrefix-SIDを割り当てることを排除しません。
For example, consider an IPv4 prefix advertisement received by an IS-IS router in the Extended IP reachability TLV (TLV 135). Suppose TLV 135 contained the Prefix-SID sub-TLV. If the router that receives TLV 135 with the Prefix-SID sub-TLV also received an SR-mapping advertisement for the same prefix through the SID/Label Binding TLV, then the receiving router must prefer the Prefix-SID sub-TLV over the SID/Label Binding TLV for that prefix. Refer to [RFC8667] for details about the Prefix-SID sub-TLV and SID/Label Binding TLV.
たとえば、拡張IP到達可能性TLV（TLV 135）のIS-ISルーターによって受信されたIPv4プレフィックスアドバタイズメントについて考えてみます。 TLV 135にPrefix-SIDサブTLVが含まれているとします。 Prefix-SIDサブTLVを含むTLV 135を受信するルーターが、SID /ラベルバインディングTLVを介して同じプレフィックスのSRマッピングアドバタイズも受信した場合、受信側ルーターはSIDよりもPrefix-SIDサブTLVを優先する必要があります。そのプレフィックスの/ Label Binding TLV。 Prefix-SID sub-TLVおよびSID / Label Binding TLVの詳細については、[RFC8667]を参照してください。
SR to LDP interworking requires an SRMS as defined above.
SRからLDPへのインターワーキングには、上記で定義したSRMSが必要です。
Each SR-capable router installs in the MPLS data-plane Node SIDs learned from the SRMS exactly as if these SIDs had been advertised by the nodes themselves.
各SR対応ルーターは、SRMSから学習したMPSIDデータプレーンノードSIDに、これらのSIDがノード自体によってアドバタイズされたかのようにインストールされます。
An SR node having LDP-only neighbors MUST stitch the incoming SR label (whose SID is advertised by the SRMS) to the outgoing LDP label.
LDPのみのネイバーを持つSRノードは、（SIDがSRMSによってアドバタイズされる）着信SRラベルを発信LDPラベルにステッチする必要があります。
It has to be noted that the SR to LDP behavior does not propagate the status of the LDP FEC that was signaled by LDP when configured in ordered mode.
SRからLDPへの動作は、順序付きモードで設定された場合にLDPによって通知されたLDP FECのステータスを伝播しないことに注意する必要があります。
It has to be noted that in the case of SR to LDP, the label binding is equivalent to the independent LDP Label Distribution Control Mode [RFC5036] where a label is bound to a FEC independently from the received binding for the same FEC.
SRからLDPの場合、ラベルバインディングは独立したLDPラベル配布制御モード[RFC5036]と同等であり、同じFECについて受信したバインディングとは別に、ラベルがFECにバインドされます。
3.2.3. Interoperability of Multiple SRMSes and Prefix-SID Advertisements
3.2.3. 複数のSRMSとプレフィックスSIDアドバタイズメントの相互運用性
In the case of SR-LDP interoperability through the use of an SRMS, mappings are advertised by one or more SRMSes.
SRMSの使用によるSR-LDP相互運用性の場合、マッピングは1つ以上のSRMSによってアドバタイズされます。
SRMS functionality is implemented in the link-state protocol (such as IS-IS and OSPF). Link-state protocols allow propagation of updates across area boundaries and, therefore, SRMS advertisements are propagated through the usual inter-area advertisement procedures in link-state protocols.
SRMS機能は、リンクステートプロトコル（IS-ISやOSPFなど）に実装されています。リンクステートプロトコルでは、エリア境界を越えて更新を伝達できるため、SRMSアドバタイズはリンクステートプロトコルの通常のエリア間アドバタイズ手順を通じて伝達されます。
Multiple SRMSes can be provisioned in a network for redundancy. Moreover, a preference mechanism may also be used among SRMSes to deploy a primary/secondary SRMS scheme allowing controlled modification or migration of SIDs.
複数のSRMSをネットワークにプロビジョニングして、冗長性を確保できます。さらに、SRMS間で設定メカニズムを使用して、SIDの制御された変更または移行を可能にするプライマリ/セカンダリSRMSスキームを展開することもできます。
The content of SRMS advertisement (i.e., mappings) are a matter of local policy determined by the operator. When multiple SRMSes are active, it is necessary that the information (mappings) advertised by the different SRMSes is aligned and consistent. The following mechanism is applied to determine the preference of SRMS advertisements:
SRMSアドバタイズメントの内容（つまり、マッピング）は、オペレーターが決定するローカルポリシーの問題です。複数のSRMSがアクティブである場合、異なるSRMSによってアドバタイズされる情報（マッピング）が調整され、一貫している必要があります。 SRMSアドバタイズメントの優先順位を決定するために、次のメカニズムが適用されます。
If a node acts as an SRMS, it MAY advertise a preference to be associated with all SRMS SID Advertisements sent by that node. The means of advertising the preference is defined in the protocol-specific documents, e.g., [RFC8665], [RFC8666], and [RFC8667]. The preference value is an unsigned 8-bit integer with the following properties:
ノードがSRMSとして機能する場合、そのノードによって送信されたすべてのSRMS SIDアドバタイズメントに関連付けられるようにプリファレンスをアドバタイズできます（MAY）。プリファレンスをアドバタイズする方法は、プロトコル固有のドキュメントで定義されています（例：[RFC8665]、[RFC8666]、および[RFC8667]）。設定値は、次のプロパティを持つ符号なし8ビット整数です。
+-------+------------------------------------------+
| 0 | Reserved value indicating advertisements |
| | from that node MUST NOT be used |
+-------+------------------------------------------+
| 1-255 | Preference value (255 is most preferred) |
+-------+------------------------------------------+
Table 1
表1
Advertisement of a preference value is optional. Nodes that do not advertise a preference value are assigned a preference value of 128.
プリファレンス値の通知はオプションです。設定値を通知しないノードには、設定値128が割り当てられます。
An MCC on a node receiving one or more SRMS mapping advertisements applies them as follows:
1つ以上のSRMSマッピングアドバタイズメントを受信するノード上のMCCは、次のようにそれらを適用します。
* For any prefix for which it did not receive a Prefix-SID Advertisement, the MCC applies the SRMS mapping advertisements with the highest preference. The mechanism by which a Prefix-SID is advertised for a given prefix is defined in the protocol specifications [RFC8665], [RFC8666], and [RFC8667].
* Prefix-SIDアドバタイズメントを受信しなかったプレフィックスについては、MCCは優先度が最も高いSRMSマッピングアドバタイズメントを適用します。 Prefix-SIDが特定のプレフィックスにアドバタイズされるメカニズムは、プロトコル仕様[RFC8665]、[RFC8666]、および[RFC8667]で定義されています。
* If there is an incoming label collision as specified in [RFC8660], apply the steps specified in [RFC8660] to resolve the collision.
* [RFC8660]で指定されている着信ラベルの衝突がある場合は、[RFC8660]で指定されている手順を適用して、衝突を解決します。
When the SRMS advertises mappings, an implementation should provide a mechanism through which the operator determines which of the IP2MPLS mappings are preferred among the one advertised by the SRMS and the ones advertised by LDP.
SRMSがマッピングをアドバタイズする場合、実装は、SRMSによってアドバタイズされたマッピングとLDPによってアドバタイズされたマッピングのうち、IP2MPLSマッピングのどちらを優先するかをオペレーターが決定するメカニズムを提供する必要があります。
SR can be deployed, for example, to enhance LDP transport. The SR deployment can be limited to the network region where the SR benefits are most desired.
たとえば、LDPトランスポートを強化するためにSRを展開できます。 SRの導入は、SRのメリットが最も望まれるネットワークリージョンに限定できます。
In Figure 3, let us assume:
図3では、次のことを想定しています。
* All link costs are 10 except FG, which is 30.
* FGを除くすべてのリンクコストは10です。FGは30です。
* All routers are LDP capable.
* すべてのルーターはLDP対応です。
* X, Y, and Z are PEs participating in an important service S.
* X、Y、およびZは、重要なサービスSに参加しているPEです。
* The operator requires 50 msec link-based Fast Reroute (FRR) for service S.
* オペレーターは、サービスSに50ミリ秒のリンクベースの高速リルート（FRR）を必要とします。
* A, B, C, D, E, F, and G are SR capable.
* A、B、C、D、E、F、GはSR対応です。
* X, Y, and Z are not SR capable, e.g., as part of a staged migration from LDP to SR, the operator deploys SR first in a subpart of the network and then everywhere.
* X、Y、およびZはSRに対応していません。たとえば、LDPからSRへの段階的な移行の一環として、オペレーターは最初にSRをネットワークのサブパートに展開し、その後どこにでも展開します。
X
|
Y--A---B---E--Z
| | \
D---C--F--G
30
Figure 3: SR-LDP Interworking Example
図3：SR-LDPインターワーキングの例
The operator would like to resolve the following issues:
オペレーターは次の問題を解決したいと考えています。
* To protect the link BA along the shortest-path of the important flow XY, B requires a Remote Loop-Free Alternate (RLFA; see [RFC7490]) repair tunnel to D and, therefore, a targeted LDP session from B to D. Typically, network operators prefer avoiding these dynamically established multi-hop LDP sessions in order to reduce the number of protocols running in the network and, therefore, simplify network operations.
* 重要なフローXYの最短経路に沿ってリンクBAを保護するには、BはDへのリモートループフリー代替（RLFA; [RFC7490]を参照）修復トンネルを必要とし、したがって、BからDへのターゲットLDPセッションを必要とします。 、ネットワークオペレータは、ネットワークで実行されているプロトコルの数を減らし、ネットワークの運用を簡素化するために、これらの動的に確立されたマルチホップLDPセッションを回避することを好みます。
* There is no LFA/RLFA solution to protect the link BE along the shortest path of the important flow XZ. The operator wants a guaranteed link-based FRR solution.
* 重要なフローXZの最短経路に沿ってリンクBEを保護するLFA / RLFAソリューションはありません。オペレーターは、保証されたリンクベースのFRRソリューションを望んでいます。
The operator can meet these objectives by deploying SR only on A, B, C, D, E, F, and G:
オペレーターは、A、B、C、D、E、F、GにのみSRを配置することにより、これらの目標を達成できます。
* The operator configures A, B, C, D, E, F, and G with SRGB [100, 200] and with node segments 101, 102, 103, 104, 105, 106, and 107, respectively.
* オペレーターは、A、B、C、D、E、F、GをそれぞれSRGB [100、200]とノードセグメント101、102、103、104、105、106、107で構成します。
* The operator configures D as an SR Mapping Server with the following policy mapping: (X, 201), (Y, 202), and (Z, 203).
* オペレーターは、DをSRマッピングサーバーとして構成し、（X、201）、（Y、202）、および（Z、203）のポリシーマッピングを使用します。
* Each SR node automatically advertises a local adjacency segment for its IGP adjacencies. Specifically, F advertises adjacency segment 9001 for its adjacency FG.
* 各SRノードは、IGP隣接のローカル隣接セグメントを自動的にアドバタイズします。具体的には、Fはその隣接FGの隣接セグメント9001をアドバタイズします。
A, B, C, D, E, F, and G keep their LDP capability. Therefore, the flows XY and XZ are transported over end-to-end LDP LSPs.
A、B、C、D、E、F、GはLDP機能を維持します。したがって、フローXYおよびXZは、エンドツーエンドのLDP LSPを介して転送されます。
For example, LDP at B installs the following MPLS data-plane entries:
たとえば、BのLDPは次のMPLSデータプレーンエントリをインストールします。
Incoming label: local LDP label bound by B for FEC Y
着信ラベル：FEC YのBによってバインドされたローカルLDPラベル
- Outgoing label: LDP label bound by A for FEC Y
- 発信ラベル：FEC YのAによってバインドされたLDPラベル
- Outgoing next hop: A
- 発信ネクストホップ：A
Incoming label: local LDP label bound by B for FEC Z
着信ラベル：FEC ZのBによってバインドされたローカルLDPラベル
- Outgoing label: LDP label bound by E for FEC Z
- 発信ラベル：FEC ZのEによってバインドされたLDPラベル
- Outgoing next hop: E
- 発信ネクストホップ：E
The novelty comes from how the backup chains are computed for these LDP-based entries. While LDP labels are used for the primary next-hop and outgoing labels, SR information is used for the FRR construction. In steady state, the traffic is transported over LDP LSP. In transient FRR state, the traffic is backup thanks to the SR-enhanced capabilities.
新規性は、これらのLDPベースのエントリに対してバックアップチェーンがどのように計算されるかに由来します。 LDPラベルはプライマリネクストホップおよび発信ラベルに使用されますが、SR情報はFRRの構築に使用されます。定常状態では、トラフィックはLDP LSPを介して転送されます。一時的なFRR状態では、SR拡張機能により、トラフィックはバックアップです。
The RLFA paths are dynamically precomputed as defined in [RFC7490]. Typically, implementations allow to enable an RLFA mechanism through a simple configuration command that triggers both the precomputation and installation of the repair path. The details on how RLFA mechanisms are implemented and configured is outside the scope of this document and not relevant to the aspects of SR-LDP interwork explained in this document.
[RFC7490]で定義されているように、RLFAパスは動的に事前計算されます。通常、実装では、修復パスの事前計算とインストールの両方をトリガーする単純な構成コマンドを介してRLFAメカニズムを有効にすることができます。 RLFAメカニズムの実装および構成方法の詳細は、このドキュメントの範囲外であり、このドキュメントで説明されているSR-LDPインターワークの側面には関係ありません。
This helps meet the requirements of the operator:
これは、オペレーターの要件を満たすのに役立ちます。
* Eliminate targeted LDP sessions.
* ターゲットLDPセッションを排除します。
* Provide guaranteed FRR coverage.
* 保証されたFRRカバレッジを提供します。
* Keep the traffic over LDP LSP in steady state.
* LDP LSP上のトラフィックを定常状態に保ちます。
* Partially deploy SR only where needed.
* SRを必要な場所にのみ部分的に展開します。
B's MPLS entry to Y becomes:
YへのBのMPLSエントリは次のようになります。
Incoming label: local LDP label bound by B for FEC Y
着信ラベル：FEC YのBによってバインドされたローカルLDPラベル
- Outgoing label: LDP label bound by A for FEC Y
- 発信ラベル：FEC YのAによってバインドされたLDPラベル
- Backup outgoing label: SR node segment for Y {202}
- 送信ラベルのバックアップ：YのSRノードセグメント{202}
- Outgoing next hop: A
- 発信ネクストホップ：A
- Backup next hop: repair tunnel: node segment to D {104} with outgoing next hop: C
- バックアップネクストホップ：トンネルを修復：ノードセグメントをD {104}に送信し、発信ネクストホップ：C
It has to be noted that D is selected as a Remote Loop-Free Alternate (RLFA) as defined in [RFC7490].
[RFC7490]で定義されているように、Dはリモートループフリー代替（RLFA）として選択されていることに注意してください。
In steady state, X sends its Y-destined traffic to B with a top label, which is the LDP label bound by B for FEC Y. B swaps that top label for the LDP label bound by A for FEC Y and forwards to A. A pops the LDP label and forwards to Y.
定常状態では、XはY宛てのトラフィックをBにFEC YのBによってバインドされたLDPラベルであるトップラベルを付けてBに送信します。BはそのトップラベルをFEC YのAによってバインドされたLDPラベルに交換し、Aに転送します。 LDPラベルがポップされ、Yに転送されます。
Upon failure of the link BA, B swaps the incoming top label with the node segment for Y (202) and sends the packet onto a repair tunnel to D (node segment 104). Thus, B sends the packet to C with the label stack {104, 202}. C pops the node segment 104 and forwards to D. D swaps 202 for 202 and forwards to A. A's next hop to Y is not SR capable, and therefore, Node A swaps the incoming node segment 202 to the LDP label announced by its next hop (in this case, implicit NULL).
リンクBAに障害が発生すると、Bは着信トップラベルをYのノードセグメント（202）と交換し、パケットをD（ノードセグメント104）への修復トンネルに送信します。したがって、Bはラベルスタック{104、202}を使用してパケットをCに送信します。 Cはノードセグメント104をポップし、Dに転送します。Dは202を202にスワップし、Aに転送します。AのYへの次のホップはSRに対応していないため、ノードAは着信ノードセグメント202を、次のノードが発表したLDPラベルにスワップしますホップ（この場合、暗黙のNULL）。
After IGP convergence, B's MPLS entry to Y will become:
IGPコンバージェンス後、BのYへのMPLSエントリは次のようになります。
Incoming label: local LDP label bound by B for FEC Y
着信ラベル：FEC YのBによってバインドされたローカルLDPラベル
- Outgoing label: LDP label bound by C for FEC Y
- 発信ラベル：FEC YのCによってバインドされたLDPラベル
- Outgoing next hop: C
- 発信ネクストホップ：C
And the traffic XY travels again over the LDP LSP.
そして、トラフィックXYは再びLDP LSPを通過します。
Conclusion: the operator has eliminated the need for targeted LDP sessions (no longer required) and the steady-state traffic is still transported over LDP. The SR deployment is confined to the area where these benefits are required.
結論：オペレーターはターゲットLDPセッション（不要）の必要性を排除し、定常状態のトラフィックは引き続きLDPを介して転送されます。 SRの展開は、これらのメリットが必要な領域に限定されます。
Despite that, in general, an implementation would not require a manual configuration of targeted LDP sessions. However, it is always a gain if the operator is able to reduce the set of protocol sessions running on the network infrastructure.
それにもかかわらず、一般に、実装ではターゲットLDPセッションを手動で構成する必要はありません。ただし、オペレーターがネットワークインフラストラクチャで実行されているプロトコルセッションのセットを減らすことができる場合は、常にメリットがあります。
As mentioned in Section 4.1, in the example topology described in Figure 3, there is no RLFA-based solution for protecting the traffic flow YZ against the failure of link BE because there is no intersection between the extended P-space and Q-space (see [RFC7490] for details). However:
セクション4.1で説明したように、図3で説明されているトポロジの例では、拡張P空間とQ空間（詳細については、[RFC7490]を参照してください）。しかしながら：
* G belongs to the Q space of Z.
* GはZのQ空間に属します。
* G can be reached from B via a "repair SR path" {106, 9001} that is not affected by failure of link BE. (The method by which G and the repair tunnel to it from B are identified are outside the scope of this document.)
* リンクBEの障害の影響を受けない「修復SRパス」{106、9001}を介してBからGに到達できます。 （GおよびBからGへの修復トンネルを特定する方法は、このドキュメントの範囲外です。）
B's MPLS entry to Z becomes:
BのZへのMPLSエントリは次のようになります。
Incoming label: local LDP label bound by B for FEC Z
着信ラベル：FEC ZのBによってバインドされたローカルLDPラベル
- Outgoing label: LDP label bound by E for FEC Z
- 発信ラベル：FEC ZのEによってバインドされたLDPラベル
- Backup outgoing label: SR node segment for Z {203}
- 発信ラベルのバックアップ：ZのSRノードセグメント{203}
- Outgoing next hop: E
- 発信ネクストホップ：E
- Backup next hop: repair tunnel to G: {106, 9001}
- ネクストホップのバックアップ：Gへのトンネルを修復：{106、9001}
G is reachable from B via the combination of a node segment to F {106} and an adjacency segment FG {9001}.
GはBからノードセグメントとF {106}への結合と隣接セグメントFG {9001}を介して到達可能です。
Note that {106, 107} would have equally worked. Indeed, in many cases, P's shortest path to Q is over the link PQ. The adjacency segment from P to Q is required only in very rare topologies where the shortest-path from P to Q is not via the link PQ.
{106、107}も同様に機能することに注意してください。実際、多くの場合、PのQへの最短経路はリンクPQを経由します。 PからQへの隣接セグメントは、PからQへの最短パスがリンクPQを経由しない非常にまれなトポロジでのみ必要です。
In steady state, X sends its Z-destined traffic to B with a top label, which is the LDP label bound by B for FEC Z. B swaps that top label for the LDP label bound by E for FEC Z and forwards to E. E pops the LDP label and forwards to Z.
定常状態では、XはZ宛てのトラフィックをトップラベルを付けてBに送信します。これはFEC ZのBによってバインドされたLDPラベルです。BはFEC ZのEによってバインドされたLDPラベルのトップラベルを交換し、Eに転送します。 EはLDPラベルをポップし、Zに転送します。
Upon failure of the link BE, B swaps the incoming top label with the node segment for Z (203) and sends the packet onto a repair tunnel to G (node segment 106 followed by adjacency segment 9001). Thus, B sends the packet to C with the label stack {106, 9001, 203}. C pops the node segment 106 and forwards to F. F pops the adjacency segment 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's next hop to Z is not SR capable, and thus, E swaps the incoming node segment 203 for the LDP label announced by its next hop (in this case, implicit NULL).
リンクBEに障害が発生すると、Bは着信トップラベルをZのノードセグメント（203）と交換し、パケットをGへの修復トンネル（ノードセグメント106の後に隣接セグメント9001）に送信します。したがって、Bはラベルスタック{106、9001、203}を使用してCにパケットを送信します。 Cはノードセグメント106をポップし、Fに転送します。Fは隣接セグメント9001をポップし、Gに転送します。Gは203を203にスワップし、Eに転送します。EのZへの次のホップはSR対応ではないため、Eは着信ノードをスワップします。ネクストホップ（この場合は暗黙のNULL）によってアナウンスされたLDPラベルのセグメント203。
After IGP convergence, B's MPLS entry to Z will become:
IGPコンバージェンスの後、BのZへのMPLSエントリは次のようになります。
Incoming label: local LDP label bound by B for FEC Z
着信ラベル：FEC ZのBによってバインドされたローカルLDPラベル
- Outgoing label: LDP label bound by C for FEC Z
- 発信ラベル：FEC ZのCによってバインドされたLDPラベル
- Outgoing next hop: C
- 発信ネクストホップ：C
And the traffic XZ travels again over the LDP LSP.
そしてトラフィックXZは再びLDP LSPを通過します。
Conclusions:
結論：
* the operator has eliminated its second problem: guaranteed FRR coverage is provided. The steady-state traffic is still transported over LDP. The SR deployment is confined to the area where these benefits are required.
* オペレーターは2番目の問題を排除しました。FRRカバレッジが保証されます。定常状態のトラフィックは、引き続きLDPを介して転送されます。 SRの展開は、これらのメリットが必要な領域に限定されます。
* FRR coverage has been achieved without any signaling for setting up the repair LSP and without setting up a targeted LDP session between B and G.
* FRRカバレッジは、修復LSPをセットアップするためのシグナリングなしで、およびBとG間のターゲットLDPセッションをセットアップせずに達成されました。
In inter-AS Option C [RFC4364], two interconnected ASes sets up inter-AS MPLS connectivity. SR may be independently deployed in each AS.
AS間オプションC [RFC4364]では、2つの相互接続されたASがAS間MPLS接続をセットアップします。 SRは各ASに独立して展開できます。
PE1---R1---B1---B2---R2---PE2
<-----------> <----------->
AS1 AS2
Figure 4: Inter-AS Option C
図4：Inter-ASオプションC
In Inter-AS Option C, B2 advertises to B1 a labeled BGP route [RFC8277] for PE2, and B1 reflects it to its internal peers, e.g., PE1. PE1 learns from a service route reflector a service route whose next hop is PE2. PE1 resolves that service route on the labeled BGP route to PE2. That labeled BGP route to PE2 is itself resolved on the AS1 IGP route to B1.
Inter-ASオプションCでは、B2はPE2のラベル付きBGPルート[RFC8277]をB1にアドバタイズし、B1はそれを内部ピア（PE1など）に反映します。 PE1は、サービスルートリフレクタから、ネクストホップがPE2であるサービスルートを学習します。 PE1は、ラベル付きBGPルート上のサービスルートをPE2に解決します。 PE2へのそのラベル付けされたBGPルート自体は、B1へのAS1 IGPルートで解決されます。
If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the node segment from PE1 to B1.
AS1がSRを操作する場合、PE1からB1へのトンネルは、PE1からB1へのノードセグメントによって提供されます。
PE1 sends a service packet with three labels: the top one is the node segment to B1, the next one is the label in the labeled BGP route provided by B1 for the route "PE2", and the bottom one is the service label allocated by PE2.
PE1は3つのラベルの付いたサービスパケットを送信します。上の1つはB1へのノードセグメントで、次の1つはルート「PE2」用にB1によって提供されるラベル付きBGPルートのラベルで、下の1つはによって割り当てられたサービスラベルですPE2。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
When both SR and LDP coexist, the following applies:
SRとLDPの両方が共存する場合、以下が適用されます。
* If both SR and LDP propose an IP2MPLS entry for the same IP prefix, then by default the LDP route SHOULD be selected. This is because it is expected that SR is introduced into networks that contain routers that do not support SR. Hence, by having a behavior that prefers LDP over SR, traffic flow is unlikely to be disrupted.
* SRとLDPの両方が同じIPプレフィックスのIP2MPLSエントリを提案する場合、デフォルトでLDPルートを選択する必要があります（SHOULD）。これは、SRをサポートしないルーターを含むネットワークにSRが導入されることが予想されるためです。したがって、SRよりもLDPを優先する動作を持つことで、トラフィックフローが中断される可能性は低くなります。
* A local policy on a router MUST allow to prefer the SR-provided IP2MPLS entry.
* ルーターのローカルポリシーは、SRが提供するIP2MPLSエントリを優先することを許可する必要があります。
* Note that this policy MAY be locally defined. There is no requirement that all routers use the same policy.
* このポリシーはローカルで定義できることに注意してください。すべてのルーターが同じポリシーを使用する必要はありません。
When Label switch paths (LSPs) are defined by stitching LDP LSPs with SR LSPs, it is necessary to have mechanisms allowing the verification of the LSP connectivity as well as validation of the path. These mechanisms are described in [RFC8287].
ラベルスイッチパス（LSP）がLDP LSPとSR LSPをつなぐことによって定義される場合、LSP接続の検証とパスの検証を可能にするメカニズムが必要です。これらのメカニズムは[RFC8287]で説明されています。
This document does not introduce any change to the MPLS data plane [RFC3031] and therefore no additional security of the MPLS data plane is required.
このドキュメントでは、MPLSデータプレーン[RFC3031]への変更を紹介していないため、MPLSデータプレーンの追加のセキュリティは必要ありません。
This document introduces another form of label binding advertisements. The security associated with these advertisements is part of the security applied to routing protocols such as IS-IS [RFC5304] and OSPF [RFC5709], which both optionally make use of cryptographic authentication mechanisms. This form of advertisement is more centralized, on behalf of the node advertising the IP reachability, which presents a different risk profile. This document also specifies a mechanism by which the ill effects of advertising conflicting label bindings can be mitigated. In particular, advertisements from the node advertising the IP reachability is more preferred than the centralized one. This document recognizes that errors in configuration and/or programming may result in false or conflicting label binding advertisements compromising traffic forwarding. Therefore, this document recommends the operator implement strict configuration/programmability control, the monitoring of the advertised SIDs, the preference of an IP reachability SID Advertisement over a centralized SID Advertisement, and the logging of any error message in order to avoid, or at least significantly minimize, the possibility of such risk.
このドキュメントでは、別の形式のラベルバインディング広告を紹介します。これらのアドバタイズに関連するセキュリティは、IS-IS [RFC5304]やOSPF [RFC5709]などのルーティングプロトコルに適用されるセキュリティの一部であり、どちらもオプションで暗号化認証メカニズムを利用します。この形式のアドバタイズメントは、IP到達可能性をアドバタイズするノードに代わって、より集中化され、異なるリスクプロファイルを示します。このドキュメントでは、競合するラベルバインディングのアドバタイジングによる悪影響を軽減できるメカニズムについても説明しています。特に、IP到達可能性をアドバタイズするノードからのアドバタイズは、集中型アドバタイズよりも優先されます。このドキュメントは、設定やプログラミングのエラーが、トラフィック転送を危険にさらす誤ったまたは競合するラベルバインディングアドバタイズメントをもたらす可能性があることを認識しています。したがって、このドキュメントでは、オペレーターが厳密な構成/プログラマビリティ制御、アドバタイズされたSIDの監視、集中型SIDアドバタイズメントよりもIP到達可能性SIDアドバタイズメントを優先すること、および回避するために、または少なくともエラーメッセージをログに記録することを推奨しています。このようなリスクの可能性を大幅に最小化します。
[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>。
[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>。
[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>。
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.
[RFC8660] Bashandy、A。、編、Filsfils、C。、編、Previdi、S.、Decraene、B.、Litkowski、S。、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、RFC 8660 、DOI 10.17487 / RFC8660、2019年12月、<https://www.rfc-editor.org/info/rfc8660>。
[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>。
[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>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https://www.rfc-editor.org/info / rfc4364>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<https://www.rfc-editor.org/info/rfc5304>。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、 DOI 10.17487 / RFC5709、2009年10月、<https://www.rfc-editor.org/info/rfc5709>。
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, DOI 10.17487/RFC5960, August 2010, <https://www.rfc-editor.org/info/rfc5960>.
[RFC5960] Frost、D。、編、Bryant、S。、編、およびM. Bocci、編、「MPLSトランスポートプロファイルデータプレーンアーキテクチャ」、RFC 5960、DOI 10.17487 / RFC5960、2010年8月、<https： //www.rfc-editor.org/info/rfc5960>。
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <https://www.rfc-editor.org/info/rfc7490>.
[RFC7490]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M。、およびN.したがって、「リモートループフリー代替（LFA）高速再ルーティング（FRR）」、RFC 7490、DOI 10.17487 / RFC7490、2015年4月、<https://www.rfc-editor.org/info/rfc7490>。
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.
[RFC8277]ローゼン、E。、「BGPを使用してMPLSラベルをアドレスプレフィックスにバインドする」、RFC 8277、DOI 10.17487 / RFC8277、2017年10月、<https://www.rfc-editor.org/info/rfc8277>。
[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、 "Resililiency 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>。
[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://doi.org/10.17487/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://doi.org/10.17487/RFC8665>。
[RFC8666] Psenak, P., Ed. and S. Previdi, "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, <https://doi.org/10.17487/RFC8666>.
[RFC8666] Psenak、P.、Ed。およびS. Previdi、「セグメントルーティング用のOSPFv3拡張機能」、RFC 8666、DOI 10.17487 / RFC8666、2019年12月、<https://doi.org/10.17487/RFC8666>。
[RFC8667] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://doi.org/10.17487/RFC8667>.
[RFC8667] Previdi、S.、Ginsberg、L.、Filsfils、C.、Bashandy、A.、Gredler、H。、およびB. Decraene、「IS-IS Extensions for Segment Routing」、RFC 8667、DOI 10.17487 / RFC8667 、2019年12月、<https://doi.org/10.17487/RFC8667>。
PE2 PE4
\ /
PE1----P5--P6--P7---PE3
Figure 5: Migration
図5：移行
Several migration techniques are possible. The technique described here is inspired by the commonly used method to migrate from one IGP to another.
いくつかの移行手法が可能です。ここで説明する手法は、あるIGPから別のIGPに移行するために一般的に使用される方法に触発されています。
At time T0, all the routers run LDP. Any service is tunneled from an ingress PE to an egress PE over a continuous LDP LSP.
時間T0では、すべてのルータがLDPを実行しています。すべてのサービスは、継続的なLDP LSPを介して入力PEから出力PEにトンネリングされます。
At time T1, all the routers are upgraded to SR. They are configured with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6, and P7 are respectively configured with the node segments 101, 102, 103, 104, 105, 106, and 107 (attached to their service-recursing loopback).
時間T1に、すべてのルータがSRにアップグレードされます。これらはSRGB範囲[100、300]で構成されます。 PE1、PE2、PE3、PE4、P5、P6、およびP7は、それぞれノードセグメント101、102、103、104、105、106、および107（サービス再帰ループバックに接続）で構成されます。
| Note: At this time, the service traffic is still tunneled over
| LDP LSPs. For example, PE1 has an SR node segment to PE3 and
| an LDP LSP to PE3. As seen earlier, however, the LDP IP2MPLS
| encapsulation is preferred by default. However, it has to be
| noted that the SR infrastructure is usable, e.g., for Fast
| Reroute (FRR) or IGP Loop-Free Convergence to protect existing
| IP and LDP traffic. FRR mechanisms are described in [RFC8355].
At time T2, the operator enables the local policy at PE1 to prefer SR IP2MPLS encapsulation over LDP IP2MPLS.
時間T2で、オペレータはPE1のローカルポリシーがLDP IP2MPLSよりもSR IP2MPLSカプセル化を優先できるようにします。
The service from PE1 to any other PE is now riding over SR. All other service traffic is still transported over LDP LSPs.
PE1から他のPEへのサービスはSRを介して実行されています。他のすべてのサービストラフィックは、引き続きLDP LSPを介して転送されます。
At time T3, gradually, the operator enables the preference for SR IP2MPLS encapsulation across all the edge routers.
時間T3で、オペレータは徐々に、すべてのエッジルータでSR IP2MPLSカプセル化の設定を有効にします。
All the service traffic is now transported over SR. LDP is still operational and services could be reverted to LDP.
これで、すべてのサービストラフィックがSRを介して転送されます。 LDPは引き続き動作しており、サービスをLDPに戻すことができます。
At time T4, LDP is unconfigured from all routers.
時間T4では、LDPはすべてのルーターから構成解除されます。
Acknowledgements
謝辞
The authors would like to thank Pierre Francois, Ruediger Geib, and Alexander Vainshtein for their contributions to the content of this document.
この文書の内容に貢献してくれたPierre Francois、Ruediger Geib、およびAlexander Vainshteinに感謝します。
Contributors
貢献者
Edward Crabbe Individual 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 Itti Tadakメール：Sakui.it.fi
Rob Shakir Google Email: robjs@google.com
Rob Shakir Googleメール：robjs@google.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 Apstra, Inc. Email: jefftant.ietf@gmail.com
Jeff Tantsura Apstra、Inc.メール：jefftant.ietf@gmail.com
Les Ginsberg Cisco Systems Email: ginsberg@cisco.com
Les Ginsberg Cisco Systemsメール：ginsberg@cisco.com
Authors' Addresses
著者のアドレス
Ahmed Bashandy (editor) Individual United States of America
Ahmed Bashandy（editor）個人アメリカ合衆国
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 Huawei Technologies Italy
Stefano Previdi Huawei Technologiesイタリア
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