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
                                                           December 2019

Segment Routing MPLS Interworking with LDP




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.


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


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 ( 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トラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、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
   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
   Authors' Addresses
1. Introduction
1. はじめに

Segment Routing, as described in [RFC8402], can be used on top of the MPLS data plane without any modification as described in [RFC8660].


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.


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.


Typically, an implementation will allow an operator to select (through configuration) which of the described modes of SR and LDP coexistence to use.


1.1. Requirements Language
1.1. 要件言語

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.


2. SR-LDP Ships-in-the-Night Coexistence
2. SR-LDPの夜間共存

"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.


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.


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.


                              PE2          PE4
                                \          /

Figure 1: SIN Coexistence


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,,, and 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.204/32で構成します。これらのPEは、それぞれのループバックアドレスにネクストホップが設定されたVPNルートをアドバタイズしました。

* The operator configures A, B, C with respective loopbacks,,

* オペレーターはA、B、Cをそれぞれのループバック192.0.2.1/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 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) 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)の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 and VPN label 10002.

PE4は、ネクストホップ192.0.2.204およびVPNラベル10002のPE2にEVEN VPNルートを送信します。

From an SR viewpoint, PE2 maps the IGP route 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に転送します。 Cは204をポップし、PE4に転送する。

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.


* 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にトンネリングされます。

2.1. MPLS2MPLS, MPLS2IP, and IP2MPLS Coexistence

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.


Let us examine A's MPLS forwarding table as an example:


Incoming label: 1037


- Outgoing label: 2048

- 送信ラベル:2048

- Outgoing next hop: B

- 発信ネクストホップ:B

Note: This entry is programmed by LDP for

注:このエントリは、 / 32のLDPによってプログラムされています。

Incoming label: 203


- Outgoing label: 203

- 送信ラベル:203

- Outgoing next hop: B

- 発信ネクストホップ:B

Note: This entry is programmed by SR for


These two entries can coexist because their incoming label is unique. The uniqueness is guaranteed by the label manager allocation rules.


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を参照してください。

3. SR and LDP Interworking
3. SRおよびLDPインターワーキング

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.


                             PE2            PE4
                               \            /

Figure 2: SR and LDP Interworking


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は連携する必要があります。

3.1. LDP to SR
3.1. LDPからSR

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.


PE1 receives the tunneled packet and processes the service label.


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にステッチすることによって構築されます。

3.1.1. LDP to SR Behavior
3.1.1. LDPからSRへの動作

It has to be noted that no additional signaling or state is required in order to provide interworking in the direction LDP to 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].


3.2. SR to LDP
3.2. SARからLBP

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.


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].


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.


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.


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 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.


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.


P7 swaps this label with the LDP label received from P8 and forwards to P8.


P8 pops the LDP label and forwards to PE3.


PE3 receives the tunneled packet and processes the service label.


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.
3.2.1. Segment Routing Mapping Server (SRMS)
3.2.1. セグメントルーティングマッピングサーバー(SRMS)

This section specifies the concept and externally visible functionality of a Segment Routing Mapping Server (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].


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.


The SRMS functionality consists of two functional blocks: the Mapping Server (MS) and Mapping Client (MC).


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]を参照してください。

3.2.2. SR to LDP Behavior
3.2.2. SRからLDPへの動作

SR to LDP interworking requires an SRMS as defined above.


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.


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.


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.


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 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.


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.


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


Advertisement of a preference value is optional. Nodes that do not advertise a preference value are assigned a preference value of 128.


An MCC on a node receiving one or more SRMS mapping advertisements applies them as follows:


* 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.


4. SR-LDP Interworking Use Cases
4. SR-LDPインターワーキングの使用例

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のメリットが最も望まれるネットワークリージョンに限定できます。

4.1. SR Protection of LDP-Based Traffic
4.1. LDPベースのトラフィックのSR保護

In Figure 3, let us assume:


* 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をネットワークのサブパートに展開し、その後どこにでも展開します。

                                 |   |    \

Figure 3: SR-LDP Interworking Example


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:


* 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:


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を必要な場所にのみ部分的に展開します。

4.2. Eliminating Targeted LDP Sessions
4.2. ターゲットLDPセッションの排除

B's MPLS entry to Y becomes:


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].


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:


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.


4.3. Guaranteed FRR Coverage
4.3. FRRカバレッジの保証

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:


* 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:


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:


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を通過します。



* 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セッションをセットアップせずに達成されました。

4.4. Inter-AS Option C, Carrier's Carrier
4.4. Inter-ASオプションC、キャリアのキャリア

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に独立して展開できます。

                       <----------->   <----------->
                            AS1            AS2

Figure 4: Inter-AS Option 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.


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.


5. IANA Considerations
5. IANAに関する考慮事項

This document has no IANA actions.


6. Manageability Considerations
6. 管理性に関する考慮事項
6.1. SR and LDP Coexistence
6.1. SRとLDPの共存

When both SR and LDP coexist, the following applies:


* 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.

* このポリシーはローカルで定義できることに注意してください。すべてのルーターが同じポリシーを使用する必要はありません。

6.2. Data-Plane Verification
6.2. データプレーン検証

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]で説明されています。

7. Security Considerations
7. セキュリティに関する考慮事項

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.


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アドバタイズメントを優先すること、および回避するために、または少なくともエラーメッセージをログに記録することを推奨しています。このようなリスクの可能性を大幅に最小化します。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、< rfc2119>。

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <>.

[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<https:// www。>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、< 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, <>.

[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<>。

[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, <>.

[RFC8660] Bashandy、A。、編、Filsfils、C。、編、Previdi、S.、Decraene、B.、Litkowski、S。、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、RFC 8660 、DOI 10.17487 / RFC8660、2019年12月、<>。

8.2. Informative References
8.2. 参考引用

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <>.

[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、< / 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, <>.

[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月、<>。

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <>.

[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク(VPN)」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、< / rfc4364>。

[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <>.

[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<>。

[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, <>.

[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月、<>。

[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, <>.

[RFC5960] Frost、D。、編、Bryant、S。、編、およびM. Bocci、編、「MPLSトランスポートプロファイルデータプレーンアーキテクチャ」、RFC 5960、DOI 10.17487 / RFC5960、2010年8月、<https: //>。

[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, <>.

[RFC7490]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M。、およびN.したがって、「リモートループフリー代替(LFA)高速再ルーティング(FRR)」、RFC 7490、DOI 10.17487 / RFC7490、2015年4月、<>。

[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <>.

[RFC8277]ローゼン、E。、「BGPを使用してMPLSラベルをアドレスプレフィックスにバインドする」、RFC 8277、DOI 10.17487 / RFC8277、2017年10月、<>。

[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, <>.

[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月、< >。

[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, <>.

[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月、<>。

[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, <>.

[RFC8665] Psenak、P。、編、Previdi、S。、編、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W。、およびJ. Tantsura、「セグメントルーティングのOSPF拡張"、RFC 8665、DOI 10.17487 / RFC8665、2019年12月、<>。

[RFC8666] Psenak, P., Ed. and S. Previdi, "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, <>.

[RFC8666] Psenak、P.、Ed。およびS. Previdi、「セグメントルーティング用のOSPFv3拡張機能」、RFC 8666、DOI 10.17487 / RFC8666、2019年12月、<>。

[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, <>.

[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月、<>。

Appendix A. Migration from LDP to SR
付録A. LDPからSRへの移行
                               PE2        PE4
                                 \        /

Figure 5: Migration


Several migration techniques are possible. The technique described here is inspired by the commonly used method to migrate from one IGP to another.


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.




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に感謝します。



Edward Crabbe Individual Email:

Edward Crabbe個別メール

Igor Milojevic Email:

Igor Milojevic Eメール

Saku Ytti TDC Email:

Saku Itti Tadakメール

Rob Shakir Google Email:

Rob Shakir Googleメール

Martin Horneffer Deutsche Telekom Email:

Martin Horneffer Deutsche Telekomメール

Wim Henderickx Nokia Email:

Wim Henderickx Nokiaメール

Jeff Tantsura Apstra, Inc. Email:

Jeff Tantsura Apstra、Inc.メール

Les Ginsberg Cisco Systems Email:

Les Ginsberg Cisco Systemsメール

Authors' Addresses


Ahmed Bashandy (editor) Individual United States of America

Ahmed Bashandy(editor)個人アメリカ合衆国


Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium

Clarence Filsfils(editor)Cisco Systems、Inc. Brussels Belgium


Stefano Previdi Huawei Technologies Italy

Stefano Previdi Huawei Technologiesイタリア


Bruno Decraene Orange France

Bruno Decraene Orange France


Stephane Litkowski Orange France