[要約] RFC 8604は、セグメントルーティングを使用して数百万のエンドポイントを相互接続するためのガイドラインです。このRFCの目的は、スケーラビリティと柔軟性を向上させ、ネットワークの管理を簡素化することです。
Independent Submission C. Filsfils, Ed.
Request for Comments: 8604 Cisco Systems, Inc.
Category: Informational S. Previdi
ISSN: 2070-1721 Huawei Technologies
G. Dawra, Ed.
LinkedIn
W. Henderickx
Nokia
D. Cooper
CenturyLink
June 2019
Interconnecting Millions of Endpoints with Segment Routing
数百万のエンドポイントをセグメントルーティングで相互接続する
Abstract
概要
This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document.
このドキュメントでは、数十万のネットワークノードと数千万の物理アンダーレイエンドポイントをサポートするようにネットワークを拡張するセグメントルーティングのアプリケーションについて説明します。この使用例は、大規模データセンター（DC）や大規模な集約ネットワークの相互接続に適用できます。中点ノードと葉ノードのテーブルの転送には、数万のエントリしか必要ありません。これは、セグメントルーティングの本質的にスケーラブルな性質と、このドキュメントで提案されている設計によって実現できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8604.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8604で入手できます。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Reference Design ................................................3
4. Control Plane ...................................................5
5. Illustration of the Scale .......................................5
6. Design Options ..................................................6
6.1. Segment Routing Global Block (SRGB) Size ...................6
6.2. Redistribution of Routes for Agg Nodes .....................7
6.3. Sizing and Hierarchy .......................................7
6.4. Local Segments to Hosts/Servers ............................7
6.5. Compressed SRTE Policies ...................................7
7. Deployment Model ................................................8
8. Benefits ........................................................8
8.1. Simplified Operations ......................................8
8.2. Inter-domain SLAs ..........................................8
8.3. Scale ......................................................9
8.4. ECMP .......................................................9
9. IANA Considerations .............................................9
10. Manageability Considerations ...................................9
11. Security Considerations ........................................9
12. Informative References .........................................9
Acknowledgements ..................................................10
Contributors ......................................................10
Authors' Addresses ................................................11
This document describes how Segment Routing (SR) can be used to interconnect millions of endpoints.
このドキュメントでは、セグメントルーティング（SR）を使用して何百万ものエンドポイントを相互接続する方法について説明します。
The following terms and abbreviations are used in this document:
このドキュメントでは、次の用語と略語を使用しています。
Term Definition
-------------------------------------------------------------
Agg Aggregation
BGP Border Gateway Protocol
DC Data Center
DCI Data Center Interconnect
ECMP Equal-Cost Multipath
FIB Forwarding Information Base
LDP Label Distribution Protocol
LFIB Label Forwarding Information Base
MPLS Multiprotocol Label Switching
PCE Path Computation Element
PCEP Path Computation Element Communication Protocol
PW Pseudowire
SLA Service Level Agreement
SR Segment Routing
SRTE Policy Segment Routing Traffic Engineering Policy
TE Traffic Engineering
TI-LFA Topology Independent Loop-Free Alternate
The network diagram below illustrates the reference network topology used in this document:
次のネットワークダイアグラムは、このドキュメントで使用されているリファレンスネットワークトポロジを示しています。
+-------+ +--------+ +--------+ +-------+ +-------+
A DCI1 Agg1 Agg3 DCI3 Z
| DC1 | | M1 | | C | | M2 | | DC2 |
| DCI2 Agg2 Agg4 DCI4 |
+-------+ +--------+ +--------+ +-------+ +-------+
Figure 1: Reference Topology
図1：参照トポロジ
The following apply to the reference topology above:
以下は、上記の参照トポロジに適用されます。
o Independent ISIS-OSPF/SR instance in core (C) region.
o コア（C）領域の独立したISIS-OSPF / SRインスタンス。
o Independent ISIS-OSPF/SR instance in Metro1 (M1) region.
o Metro1（M1）リージョンの独立したISIS-OSPF / SRインスタンス。
o Independent ISIS-OSPF/SR instance in Metro2 (M2) region.
o Metro2（M2）リージョンの独立したISIS-OSPF / SRインスタンス。
o BGP/SR in DC1.
o DC1のBGP / SR。
o BGP/SR in DC2.
o DC2のBGP / SR。
o Agg routes (Agg1, Agg2, Agg3, Agg4) are redistributed from C to M (M1 and M2) and from M to DC domains.
o Aggルート（Agg1、Agg2、Agg3、Agg4）は、CからM（M1およびM2）に、およびMからDCドメインに再配布されます。
o No other route is advertised or redistributed between regions.
o リージョン間で他のルートがアドバタイズまたは再配布されることはありません。
o The same homogeneous Segment Routing Global Block (SRGB) is used throughout the domains (e.g., 16000-23999).
o 同じ同種のセグメントルーティンググローバルブロック（SRGB）がドメイン全体で使用されます（例：16000-23999）。
o Unique SRGB sub-ranges are allocated to each metro (M) and core (C) domain:
o 一意のSRGBサブ範囲は、各メトロ（M）およびコア（C）ドメインに割り当てられます。
* The 16000-16999 range is allocated to the core (C) domain/region.
* 16000〜16999の範囲は、コア（C）ドメイン/リージョンに割り当てられます。
* The 17000-17999 range is allocated to the M1 domain/region.
* 17000-17999の範囲は、M1ドメイン/リージョンに割り当てられます。
* The 18000-18999 range is allocated to the M2 domain/region.
* 18000-18999の範囲は、M2ドメイン/リージョンに割り当てられます。
* Specifically, the Agg1 router has Segment Identifier (SID) 16001 allocated, and the Agg2 router has SID 16002 allocated.
* 具体的には、Agg1ルーターにはセグメント識別子（SID）16001が割り当てられており、Agg2ルーターにはSID 16002が割り当てられています。
* Specifically, the Agg3 router has SID 16003 allocated, and the anycast SID for Agg3 and Agg4 is 16006.
* 具体的には、Agg3ルーターにはSID 16003が割り当てられており、Agg3およびAgg4のエニーキャストSIDは16006です。
* Specifically, the DCI3 router has SID 18003 allocated, and the anycast SID for DCI3 and DCI4 is 18006.
* 具体的には、DCI3ルーターにはSID 18003が割り当てられており、DCI3およびDCI4のエニーキャストSIDは18006です。
* Specifically, at the Agg1 router, the binding SID 4001 leads to DCI pair (DCI3, DCI4) via a specific low-latency path {16002, 16003, 18006}.
* 具体的には、Agg1ルーターでは、バインディングSID 4001は特定の低遅延パス{16002、16003、18006}を介してDCIペア（DCI3、DCI4）につながります。
o The same SRGB sub-range is reused within each DC (DC1 and DC2) region for each DC (e.g., 20000-23999). Specifically, nodes A and Z both have SID 20001 allocated to them.
o 同じSRGBサブ範囲が、各DCの各DC（DC1およびDC2）領域内で再利用されます（例：20000-23999）。具体的には、ノードAとZの両方にSID 20001が割り当てられています。
This section provides a high-level description of how a control plane could be implemented using protocol components already defined in other RFCs.
このセクションでは、他のRFCですでに定義されているプロトコルコンポーネントを使用してコントロールプレーンを実装する方法の概要を説明します。
The mechanism through which SRTE Policies are defined, computed, and programmed in the source nodes is outside the scope of this document.
SRTEポリシーがソースノードで定義、計算、およびプログラミングされるメカニズムは、このドキュメントの範囲外です。
Typically, a controller or a service orchestration system programs node A with a PW to a remote next-hop node Z with a given SLA contract (e.g., low-latency path, disjointness from a specific core plane, disjointness from a different PW service).
通常、コントローラーまたはサービスオーケストレーションシステムは、PWを持つノードAを、特定のSLAコントラクト（たとえば、低遅延パス、特定のコアプレーンからの素性、異なるPWサービスからの素性）でリモートネクストホップノードZにプログラムします。 。
Node A automatically detects that node Z is not reachable. It then automatically sends a PCEP request to an SR PCE for an SRTE policy that provides reachability information for node Z with the requested SLA.
ノードAは、ノードZに到達できないことを自動的に検出します。次に、要求されたSLAでノードZの到達可能性情報を提供するSRTEポリシーのPCEP要求をSR PCEに自動的に送信します。
The SR PCE [RFC4655] is made of two components: a multi-domain topology and a computation engine. The multi-domain topology is continuously refreshed through BGP - Link State (BGP-LS) feeds [RFC7752] from each domain. The computation engine is designed to implement TE algorithms and provide output in SR Path format. Upon receiving the PCEP request [RFC5440], the SR PCE computes the requested path. The path is expressed through a list of segments (e.g., {16003, 18006, 20001}) and provided to node A.
SR PCE [RFC4655]は、マルチドメイントポロジと計算エンジンの2つのコンポーネントで構成されています。マルチドメイントポロジは、各ドメインからのBGP-リンク状態（BGP-LS）フィード[RFC7752]を通じて継続的に更新されます。計算エンジンは、TEアルゴリズムを実装し、SRパス形式で出力を提供するように設計されています。 PCEPリクエスト[RFC5440]を受信すると、SR PCEはリクエストされたパスを計算します。パスはセグメントのリスト（例：{16003、18006、20001}）で表され、ノードAに提供されます。
The SR PCE logs the request as a stateful query and hence is able to recompute the path at each network topology change.
SR PCEはリクエストをステートフルクエリとしてログに記録するため、ネットワークトポロジが変更されるたびにパスを再計算できます。
Node A receives the PCEP reply with the path (expressed as a segment list). Node A installs the received SRTE policy in the data plane. Node A then automatically steers the PW into that SRTE policy.
ノードAは、パス（セグメントリストとして表現）を含むPCEP応答を受信します。ノードAは、受信したSRTEポリシーをデータプレーンにインストールします。次に、ノードAはPWをそのSRTEポリシーに自動的に誘導します。
According to the reference topology shown in Figure 1, the following assumptions are made:
図1に示されている参照トポロジーに従って、次の仮定が行われます。
o There is one core domain, and there are 100 leaf (metro) domains.
o コアドメインが1つあり、リーフ（メトロ）ドメインが100あります。
o The core domain includes 200 nodes.
o コアドメインには200ノードが含まれます。
o Two nodes connect each leaf (metro) domain. Each node connecting a leaf domain has a SID allocated. Each pair of nodes connecting a leaf domain also has a common anycast SID. This yields up to 300 prefix segments in total.
o 2つのノードが各リーフ（メトロ）ドメインを接続します。リーフドメインを接続する各ノードには、SIDが割り当てられています。リーフドメインを接続するノードの各ペアにも、共通のエニーキャストSIDがあります。これにより、合計で最大300のプレフィックスセグメントが生成されます。
o A core node connects only one leaf domain.
o コアノードは1つのリーフドメインのみを接続します。
o Each leaf domain has 6,000 leaf-node segments. Each leaf node has 500 endpoints attached and thus 500 adjacency segments. This yields a total of 3 million endpoints for a leaf domain.
o 各リーフドメインには、6,000のリーフノードセグメントがあります。各リーフノードには500のエンドポイントが接続されているため、500の隣接セグメントがあります。これにより、リーフドメインで合計300万のエンドポイントが生成されます。
Based on the above, the network scaling numbers are as follows:
上記に基づいて、ネットワークのスケーリング数は次のとおりです。
o 6,000 leaf-node segments multiplied by 100 leaf domains: 600,000 nodes.
o 6,000のリーフノードセグメントに100のリーフドメインを掛けたもの：600,000ノード。
o 600,000 nodes multiplied by 500 endpoints: 300 million endpoints.
o 600,000ノードに500エンドポイントを掛けると、3億エンドポイントになります。
The node scaling numbers are as follows:
ノードのスケーリング数は次のとおりです。
o Leaf-node segment scale: 6,000 leaf-node segments + 300 core-node segments + 500 adjacency segments = 6,800 segments.
o リーフノードセグメントスケール：6,000リーフノードセグメント+ 300コアノードセグメント+ 500隣接セグメント= 6,800セグメント。
o Core-node segment scale: 6,000 leaf-domain segments + 300 core-domain segments = 6,300 segments.
o コアノードセグメントスケール：6,000リーフドメインセグメント+ 300コアドメインセグメント= 6,300セグメント。
In the above calculations, the link-adjacency segments are not taken into account. These are local segments and, typically, less than 100 per node.
上記の計算では、リンク隣接セグメントは考慮されていません。これらはローカルセグメントであり、通常、ノードあたり100未満です。
It has to be noted that, depending on leaf-node FIB capabilities, leaf domains could be split into multiple smaller domains. In the above example, the leaf domains could be split into six smaller domains so that each leaf node only needs to learn 1,000 leaf-node segments + 300 core-node segments + 500 adjacency segments, yielding a total of 1,800 segments.
リーフノードのFIB機能によっては、リーフドメインを複数の小さなドメインに分割できることに注意する必要があります。上記の例では、リーフドメインを6つの小さなドメインに分割して、各リーフノードが1,000のリーフノードセグメント+ 300のコアノードセグメント+ 500の隣接セグメントを学習するだけで、合計1,800のセグメントが得られるようになります。
This section describes multiple design options to illustrate scale as described in the previous section.
このセクションでは、前のセクションで説明したスケールを説明するために、複数の設計オプションについて説明します。
In the simplified illustrations in this document, we picked a small homogeneous SRGB range of 16000-23999. In practice, a large-scale design would use a bigger range, such as 16000-80000 or even larger. A larger range provides allocations for various TE applications within a given domain.
このドキュメントの簡略化された図では、16000〜23999の小さな均一なSRGB範囲を選択しました。実際には、大規模な設計では、16000〜80000など、より大きな範囲を使用します。より大きな範囲は、特定のドメイン内のさまざまなTEアプリケーションに割り当てを提供します。
The operator might choose to not redistribute the routes for Agg nodes into the Metro/DC domains. In that case, more segments are required in order to express an inter-domain path.
オペレーターは、AggノードのルートをMetro / DCドメインに再配布しないことを選択する場合があります。その場合、ドメイン間パスを表現するために、より多くのセグメントが必要です。
For example, node A would use an SRTE Policy {DCI1, Agg1, Agg3, DCI3, Z} in order to reach Z instead of {Agg3, DCI3, Z} in the reference design.
たとえば、ノードAは、リファレンスデザインで{Agg3、DCI3、Z}の代わりにZに到達するために、SRTEポリシー{DCI1、Agg1、Agg3、DCI3、Z}を使用します。
The operator is free to choose among a small number of larger leaf domains, a large number of small leaf domains, or a mix of small and large core/leaf domains.
オペレーターは、少数の大きな葉のドメイン、多数の小さな葉のドメイン、または小さなコアと葉のドメインの混合から自由に選択できます。
The operator is free to use a two-tier (Core/Metro) or three-tier (Core/Metro/DC) design.
オペレーターは、2層（コア/メトロ）または3層（コア/メトロ/ DC）の設計を自由に使用できます。
Local segments can be programmed at any leaf node (e.g., node Z) in order to identify locally attached hosts (or Virtual Machines (VMs)). For example, if node Z has bound a local segment 40001 to a local host ZH1, then node A uses the following SRTE Policy in order to reach that host: {16006, 18006, 20001, 40001}. Such a local segment could represent the NID (Network Interface Device) in the context of the service provider access network, or a VM in the context of the DC network.
ローカルセグメントは、ローカルに接続されたホスト（または仮想マシン（VM））を識別するために、任意のリーフノード（ノードZなど）でプログラムできます。たとえば、ノードZがローカルセグメント40001をローカルホストZH1にバインドした場合、ノードAはそのホストに到達するために次のSRTEポリシーを使用します：{16006、18006、20001、40001}。このようなローカルセグメントは、サービスプロバイダーのアクセスネットワークのコンテキストではNID（ネットワークインターフェイスデバイス）を、DCネットワークのコンテキストではVMを表すことができます。
As an example and according to Section 3, we assume that node A can reach node Z (e.g., with a low-latency SLA contract) via the SRTE policy that consists of the path Agg1, Agg2, Agg3, DCI3/4(anycast), Z. The path is represented by the segment list {16001, 16002, 16003, 18006, 20001}.
例として、セクション3に従って、パスAgg1、Agg2、Agg3、DCI3 / 4（anycast）で構成されるSRTEポリシーを介してノードAがノードZに到達できると想定します（たとえば、低レイテンシSLAコントラクトを使用）。 、Z。パスは、セグメントリスト{16001、16002、16003、18006、20001}で表されます。
It is clear that the control-plane solution can install an SRTE Policy {16002, 16003, 18006} at Agg1, collect the binding SID allocated by Agg1 to that policy (e.g., 4001), and hence program node A with the compressed SRTE Policy {16001, 4001, 20001}.
コントロールプレーンソリューションがSRTEポリシー{16002、16003、18006}をAgg1にインストールできることは明らかで、Agg1によってそのポリシー（4001など）に割り当てられたバインディングSIDを収集し、圧縮されたSRTEポリシーでノードAをプログラムします。 {16001、4001、20001}。
From node A, 16001 leads to Agg1. Once at Agg1, 4001 leads to the DCI pair (DCI3, DCI4) via a specific low-latency path {16002, 16003, 18006}. Once at that DCI pair, 20001 leads to Z.
ノードAから、16001はAgg1につながります。 Agg1に入ると、4001は特定の低遅延パス{16002、16003、18006}を介してDCIペア（DCI3、DCI4）につながります。そのDCIペアで、20001はZにつながります。
Binding SIDs allocated to "intermediate" SRTE Policies achieve the compression of end-to-end SRTE Policies.
「中間」SRTEポリシーに割り当てられたバインディングSIDは、エンドツーエンドSRTEポリシーの圧縮を実現します。
The segment list {16001, 4001, 20001} expresses the same path as {16001, 16002, 16003, 18006, 20001} but with two less segments.
セグメントリスト{16001、4001、20001}は、{16001、16002、16003、18006、20001}と同じパスを表しますが、セグメントが2つ少なくなります。
The binding SID also provides for inherent churn protection.
バインディングSIDは、固有のチャーン保護も提供します。
When the core topology changes, the control plane can update the low-latency SRTE Policy from Agg1 to the DCI pair to DC2 without updating the SRTE Policy from A to Z.
コアトポロジが変更されると、コントロールプレーンは、SRTEポリシーをAからZに更新せずに、低遅延SRTEポリシーをAgg1からDCIペアからDC2に更新できます。
It is expected that this design will be used in "green field" deployments as well as interworking ("brown field") deployments with an MPLS design across multiple domains.
この設計は、「グリーンフィールド」配置だけでなく、複数のドメインにまたがるMPLS設計とのインターワーキング（「ブラウンフィールド」）配置でも使用されることが期待されています。
The design options illustrated in this document allow interconnections on a very large scale. Millions of endpoints across different domains can be interconnected.
このドキュメントで説明する設計オプションは、非常に大規模な相互接続を可能にします。異なるドメインにわたる何百万ものエンドポイントを相互接続できます。
Two control-plane protocols not needed in this design are LDP and RSVP-TE. No new protocol has been introduced. The design leverages the core IP protocols ISIS, OSPF, BGP, and PCEP with straightforward SR extensions.
この設計で不要な2つのコントロールプレーンプロトコルは、LDPとRSVP-TEです。新しいプロトコルは導入されていません。この設計は、コアIPプロトコルであるISIS、OSPF、BGP、およびPCEPを単純なSR拡張で活用しています。
Fast reroute and resiliency are provided by TI-LFA with sub-50-ms fast reroute upon failure of a link, node, or Shared Risk Link Group (SRLG). TI-LFA is described in [SR-TI-LFA].
高速リルートと回復力は、リンク、ノード、または共有リスクリンクグループ（SRLG）の障害時にサブ50ミリ秒の高速リルートでTI-LFAによって提供されます。 TI-LFAは[SR-TI-LFA]で説明されています。
The use of anycast SIDs also provides improved availability and resiliency.
エニーキャストSIDを使用すると、可用性と回復力も向上します。
Inter-domain SLAs can be delivered (e.g., latency vs. cost-optimized paths, disjointness from backbone planes, disjointness from other services, disjointness between primary and backup paths).
ドメイン間SLAを提供できます（例：レイテンシvsコスト最適化パス、バックボーンプレーンからの分離、他のサービスからの分離、プライマリパスとバックアップパスの間の分離）。
Existing inter-domain solutions do not provide any support for SLA contracts. They just provide best-effort reachability across domains.
既存のドメイン間ソリューションは、SLA契約をサポートしていません。ドメイン間でベストエフォートの到達可能性を提供するだけです。
In addition to having eliminated the need for LDP and RSVP-TE, per-service midpoint states have also been removed from the network.
LDPおよびRSVP-TEの必要性を排除したことに加えて、サービスごとのミッドポイント状態もネットワークから削除されました。
Each policy (intra-domain or inter-domain, with or without TE) is expressed as a list of segments. Since each segment is optimized for ECMP, the entire policy is optimized for ECMP. The benefit of an anycast prefix segment optimized for ECMP should also be considered (e.g., 16001 load-shares across any gateway from the M1 leaf domain to the Core and 16002 load-shares across any gateway from the Core to the M1 leaf domain).
各ポリシー（TEの有無にかかわらず、ドメイン内またはドメイン間）は、セグメントのリストとして表現されます。各セグメントはECMP用に最適化されているため、ポリシー全体がECMP用に最適化されています。 ECMP用に最適化されたエニーキャストプレフィックスセグメントの利点も考慮する必要があります（たとえば、M1リーフドメインからコアへのゲートウェイ全体の16001ロードシェアと、コアからM1リーフドメインへのゲートウェイ全体の16002ロードシェア）。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document describes an application of SR over the MPLS data plane. SR does not introduce any changes in the MPLS data plane. The manageability considerations described in [RFC8402] apply to the MPLS data plane when used with SR.
このドキュメントでは、MPLSデータプレーンでのSRのアプリケーションについて説明します。 SRは、MPLSデータプレーンに変更を導入しません。 [RFC8402]で説明されている管理性の考慮事項は、SRと共に使用される場合、MPLSデータプレーンに適用されます。
This document does not introduce additional security requirements and mechanisms other than those described in [RFC8402].
このドキュメントでは、[RFC8402]で説明されている以外の追加のセキュリティ要件とメカニズムを紹介していません。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：// www.rfc-editor.org/info/rfc4655>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
[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>。
[SR-TI-LFA] Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Francois, P., Voyer, D., Clad, F., and P. Camarillo, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, draft-ietf-rtgwg-segment-routing-ti-lfa-01, March 2019.
[SR-TI-LFA] Litkowski、S.、Bashandy、A.、Filsfils、C.、Decraene、B.、Francois、P.、Voyer、D.、Clad、F。、およびP. Camarillo、「トポロジーに依存しないセグメントルーティングを使用した高速リルート」、作業中、draft-ietf-rtgwg-segment-routing-ti-lfa-01、2019年3月。
Acknowledgements
謝辞
We would like to thank Giles Heron, Alexander Preusche, Steve Braaten, and Francis Ferguson for their contributions to the content of this document.
このドキュメントの内容に貢献してくれたGiles Heron、Alexander Preusche、Steve Braaten、およびFrancis Fergusonに感謝します。
Contributors
貢献者
The following people substantially contributed to the editing of this document:
以下の人々は、このドキュメントの編集に大きく貢献しました：
Dennis Cai Individual
デニス・カイ個人
Tim Laberge Individual
ティムラバージ個人
Steven Lin Google Inc.
Steven Lin Google Inc.
Bruno Decraene Orange
ブルーノデクレイエンオレンジ
Luay Jalil Verizon
ルアイ・ジャリル・ベライゾン
Jeff Tantsura Individual
ジェフタンチュラ個人
Rob Shakir Google Inc.
Rob Shakir Google Inc.
Authors' Addresses
著者のアドレス
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（editor）Cisco Systems、Inc. Brussels Belgium
Email: cfilsfil@cisco.com
Stefano Previdi Huawei Technologies
Stefano Previdi Huawei Technologies
Email: stefano@previdi.net
Gaurav Dawra (editor) LinkedIn United States of America
Gaurav Dawra（編集者）LinkedIn日本
Email: gdawra.ietf@gmail.com
Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 Belgium
Wim Henderickx Nokia Copernicuslaan 50アントワープ2018ベルギー
Email: wim.henderickx@nokia.com
Dave Cooper CenturyLink
デイブ・クーパー・センチュリーリンク
Email: Dave.Cooper@centurylink.com