[要約] RFC 8670は、大規模データセンターにおけるBGPプレフィックスセグメントの使用方法に関するガイドラインです。このRFCの目的は、データセンターネットワークのスケーラビリティと柔軟性を向上させるために、BGPプレフィックスセグメントの利点と実装方法を提供することです。
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8670 S. Previdi
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 G. Dawra
LinkedIn
E. Aries
Arrcus, Inc.
P. Lapukhov
Facebook
December 2019
BGP Prefix Segment in Large-Scale Data Centers
大規模データセンターのBGPプレフィックスセグメント
Abstract
概要
This document describes the motivation for, and benefits of, applying Segment Routing (SR) in BGP-based large-scale data centers. It describes the design to deploy SR in those data centers for both the MPLS and IPv6 data planes.
このドキュメントでは、BGPベースの大規模データセンターにセグメントルーティング（SR）を適用する動機と利点について説明します。 MPLSとIPv6の両方のデータプレーンのSRをこれらのデータセンターに展開する設計について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8670.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8670で入手できます。
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
2. Large-Scale Data-Center Network Design Summary
2.1. Reference Design
3. Some Open Problems in Large Data-Center Networks
4. Applying Segment Routing in the DC with MPLS Data Plane
4.1. BGP Prefix Segment (BGP Prefix-SID)
4.2. EBGP Labeled Unicast (RFC 8277)
4.2.1. Control Plane
4.2.2. Data Plane
4.2.3. Network Design Variation
4.2.4. Global BGP Prefix Segment through the Fabric
4.2.5. Incremental Deployments
4.3. IBGP Labeled Unicast (RFC 8277)
5. Applying Segment Routing in the DC with IPv6 Data Plane
6. Communicating Path Information to the Host
7. Additional Benefits
7.1. MPLS Data Plane with Operational Simplicity
7.2. Minimizing the FIB Table
7.3. Egress Peer Engineering
7.4. Anycast
8. Preferred SRGB Allocation
9. IANA Considerations
10. Manageability Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Segment Routing (SR), as described in [RFC8402], leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. A segment can have a local semantic to an SR node or a global semantic within an SR domain. SR allows the enforcement of a flow through any topological path while maintaining per-flow state only from the ingress node to the SR domain. SR can be applied to the MPLS and IPv6 data planes.
[RFC8402]で説明されているセグメントルーティング（SR）は、ソースルーティングパラダイムを利用しています。ノードは、「セグメント」と呼ばれる命令の順序付きリストを介してパケットを操作します。セグメントは、トポロジーまたはサービスベースの任意の命令を表すことができます。セグメントは、SRノードに対するローカルセマンティックまたはSRドメイン内のグローバルセマンティックを持つことができます。 SRを使用すると、入力ノードからSRドメインへのフローごとの状態のみを維持しながら、トポロジパスを通過するフローを適用できます。 SRは、MPLSおよびIPv6データプレーンに適用できます。
The use cases described in this document should be considered in the context of the BGP-based large-scale data-center (DC) design described in [RFC7938]. This document extends it by applying SR both with IPv6 and MPLS data planes.
このドキュメントで説明されている使用例は、[RFC7938]で説明されているBGPベースの大規模データセンター（DC）設計のコンテキストで検討する必要があります。このドキュメントでは、IPv6とMPLSの両方のデータプレーンでSRを適用することにより、このドキュメントを拡張しています。
This section provides a brief summary of the Informational RFC [RFC7938], which outlines a practical network design suitable for data centers of various scales:
このセクションでは、さまざまな規模のデータセンターに適した実用的なネットワーク設計の概要を説明する情報RFC [RFC7938]の概要を示します。
* Data-center networks have highly symmetric topologies with multiple parallel paths between two server-attachment points. The well-known Clos topology is most popular among the operators (as described in [RFC7938]). In a Clos topology, the minimum number of parallel paths between two elements is determined by the "width" of the "Tier-1" stage. See Figure 1 for an illustration of the concept.
* データセンターネットワークは、2つのサーバー接続ポイント間に複数の並列パスを持つ、非常に対称的なトポロジを備えています。よく知られているClosトポロジーは、（[RFC7938]で説明されているように）オペレーターの間で最も人気があります。 Closトポロジでは、2つの要素間の並列パスの最小数は、「Tier-1」ステージの「幅」によって決まります。概念図については、図1を参照してください。
* Large-scale data centers commonly use a routing protocol, such as BGP-4 [RFC4271], in order to provide endpoint connectivity. Therefore, recovery after a network failure is driven either by local knowledge of directly available backup paths or by distributed signaling between the network devices.
* 大規模なデータセンターは、エンドポイント接続を提供するために、BGP-4 [RFC4271]などのルーティングプロトコルを一般的に使用します。したがって、ネットワーク障害後の回復は、直接利用可能なバックアップパスに関するローカルな知識、またはネットワークデバイス間の分散型シグナリングによって行われます。
* Within data-center networks, traffic is load shared using the Equal Cost Multipath (ECMP) mechanism. With ECMP, every network device implements a pseudorandom decision, mapping packets to one of the parallel paths by means of a hash function calculated over certain parts of the packet, typically a combination of various packet header fields.
* データセンターネットワーク内では、トラフィックはEqual Cost Multipath（ECMP）メカニズムを使用して負荷分散されます。 ECMPでは、すべてのネットワークデバイスが疑似ランダム決定を実装し、パケットの特定の部分、通常はさまざまなパケットヘッダーフィールドの組み合わせで計算されたハッシュ関数を使用して、パケットを並列パスの1つにマッピングします。
The following is a schematic of a five-stage Clos topology with four devices in the "Tier-1" stage. Notice that the number of paths between Node1 and Node12 equals four; the paths have to cross all of the Tier-1 devices. At the same time, the number of paths between Node1 and Node2 equals two, and the paths only cross Tier-2 devices. Other topologies are possible, but for simplicity, only the topologies that have a single path from Tier-1 to Tier-3 are considered below. The rest could be treated similarly, with a few modifications to the logic.
以下は、「Tier-1」ステージに4つのデバイスがある5ステージのClosトポロジの概略図です。 Node1とNode12の間のパスの数は4であることに注意してください。パスはすべてのTier-1デバイスを横断する必要があります。同時に、Node1とNode2間のパスの数は2であり、パスはTier-2デバイスのみを通過します。他のトポロジーも可能ですが、簡単にするために、Tier-1からTier-3への単一パスを持つトポロジーのみを以下で考慮します。残りの部分も、ロジックを少し変更するだけで同様に処理できます。
Tier-1
+-----+
|NODE |
+->| 5 |--+
| +-----+ |
Tier-2 | | Tier-2
+-----+ | +-----+ | +-----+
+------------>|NODE |--+->|NODE |--+--|NODE |-------------+
| +-----| 3 |--+ | 6 | +--| 9 |-----+ |
| | +-----+ +-----+ +-----+ | |
| | | |
| | +-----+ +-----+ +-----+ | |
| +-----+---->|NODE |--+ |NODE | +--|NODE |-----+-----+ |
| | | +---| 4 |--+->| 7 |--+--| 10 |---+ | | |
| | | | +-----+ | +-----+ | +-----+ | | | |
| | | | | | | | | |
+-----+ +-----+ | +-----+ | +-----+ +-----+
|NODE | |NODE | Tier-3 +->|NODE |--+ Tier-3 |NODE | |NODE |
| 1 | | 2 | | 8 | | 11 | | 12 |
+-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | |
A O B O <- Servers -> Z O O O
Figure 1: 5-Stage Clos Topology
図1：5段階のClosトポロジ
In the reference topology illustrated in Figure 1, it is assumed:
図1に示されている参照トポロジでは、次のことが想定されています。
* Each node is its own autonomous system (AS) (Node X has AS X). 4-byte AS numbers are recommended ([RFC6793]).
* 各ノードは独自の自律システム（AS）です（ノードXにはAS Xがあります）。 4バイトのAS番号をお勧めします（[RFC6793]）。
- For simple and efficient route propagation filtering, Node5, Node6, Node7, and Node8 use the same AS; Node3 and Node4 use the same AS; and Node9 and Node10 use the same AS.
- 単純で効率的なルート伝搬フィルタリングのために、ノード、ノード6、ノード、およびノード8は同じASを使用します。 Node3とNode4は同じASを使用します。 Node9とNode10は同じASを使用します。
- In the case in which 2-byte autonomous system numbers are used for efficient usage of the scarce 2-byte Private Use AS pool, different Tier-3 nodes might use the same AS.
- 希少な2バイトのPrivate Use ASプールを効率的に使用するために2バイトの自律システム番号が使用される場合、異なるTier 3ノードが同じASを使用する可能性があります。
- Without loss of generality, these details will be simplified in this document. It is to be assumed that each node has its own AS.
- 一般性を失うことなく、これらの詳細はこのドキュメントで簡略化されます。各ノードには独自のASがあると想定されます。
* Each node peers with its neighbors with a BGP session. If not specified, external BGP (EBGP) is assumed. In a specific use case, internal BGP (IBGP) will be used, but this will be called out explicitly in that case.
* 各ノードは、BGPセッションでネイバーとピアリングします。指定しない場合、外部BGP（EBGP）が想定されます。特定の使用例では、内部BGP（IBGP）が使用されますが、その場合は明示的に呼び出されます。
* Each node originates the IPv4 address of its loopback interface into BGP and announces it to its neighbors.
* 各ノードは、ループバックインターフェイスのIPv4アドレスをBGPに発信し、ネイバーに通知します。
- The loopback of Node X is 192.0.2.x/32.
- ノードXのループバックは192.0.2.x / 32です。
In this document, the Tier-1, Tier-2, and Tier-3 nodes are referred to as "Spine", "Leaf", and "ToR" (top of rack) nodes, respectively. When a ToR node acts as a gateway to the "outside world", it is referred to as a "border node".
このドキュメントでは、Tier-1、Tier-2、およびTier-3ノードは、それぞれ「スパイン」、「リーフ」、および「ToR」（ラックの上部）ノードと呼ばれます。 ToRノードが「外界」へのゲートウェイとして機能する場合、それは「境界ノード」と呼ばれます。
The data-center-network design summarized above provides means for moving traffic between hosts with reasonable efficiency. There are few open performance and reliability problems that arise in such a design:
上記のデータセンターネットワーク設計は、ホスト間でトラフィックを妥当な効率で移動する手段を提供します。そのような設計で発生するオープンなパフォーマンスと信頼性の問題はほとんどありません。
* ECMP routing is most commonly realized per flow. This means that large, long-lived "elephant" flows may affect performance of smaller, short-lived "mouse" flows and may reduce efficiency of per-flow load sharing. In other words, per-flow ECMP does not perform efficiently when flow-lifetime distribution is heavy tailed. Furthermore, due to hash-function inefficiencies, it is possible to have frequent flow collisions where more flows get placed on one path over the others.
* ECMPルーティングは、フローごとに最も一般的に実現されます。つまり、大規模で長期間有効な「象」フローは、小規模で短期間有効な「マウス」フローのパフォーマンスに影響を与え、フローごとの負荷分散の効率を低下させる可能性があります。つまり、フローの存続期間の分布が重い場合、フローごとのECMPは効率的に実行されません。さらに、ハッシュ関数の非効率性により、フローの衝突が頻繁に発生し、1つのパスに他のフローよりも多くのフローが配置される可能性があります。
* Shortest-path routing with ECMP implements an oblivious routing model that is not aware of the network imbalances. If the network symmetry is broken, for example, due to link failures, utilization hotspots may appear. For example, if a link fails between Tier-1 and Tier-2 devices (e.g., Node5 and Node9), Tier-3 devices Node1 and Node2 will not be aware of that since there are other paths available from the perspective of Node3. They will continue sending roughly equal traffic to Node3 and Node4 as if the failure didn't exist, which may cause a traffic hotspot.
* ECMPを使用した最短経路ルーティングは、ネットワークの不均衡を認識しない忘却型ルーティングモデルを実装します。リンク障害などが原因でネットワークの対称性が失われると、使用率のホットスポットが表示される場合があります。たとえば、Tier-1とTier-2デバイス（Node5とNode9など）間のリンクに障害が発生した場合、Node3の観点から利用可能な他のパスがあるため、Tier-3デバイスNode1とNode2はそれを認識しません。障害が発生していないかのように、Node3とNode4にほぼ等しいトラフィックを送信し続けるため、トラフィックのホットスポットが発生する可能性があります。
* Isolating faults in the network with multiple parallel paths and ECMP-based routing is nontrivial due to lack of determinism. Specifically, the connections from HostA to HostB may take a different path every time a new connection is formed, thus making consistent reproduction of a failure much more difficult. This complexity scales linearly with the number of parallel paths in the network and stems from the random nature of path selection by the network devices.
* 複数の並列パスとECMPベースのルーティングを備えたネットワーク内の障害を分離することは、決定論の欠如のために重要です。具体的には、HostAからHostBへの接続は、新しい接続が形成されるたびに異なるパスを使用する可能性があるため、障害の一貫した再現がはるかに困難になります。この複雑さは、ネットワーク内の並列パスの数に比例し、ネットワークデバイスによるパス選択のランダムな性質から生じます。
A BGP Prefix Segment is a segment associated with a BGP prefix. A BGP Prefix Segment is a network-wide instruction to forward the packet along the ECMP-aware best path to the related prefix.
BGPプレフィックスセグメントは、BGPプレフィックスに関連付けられたセグメントです。 BGPプレフィックスセグメントは、関連するプレフィックスへのECMP対応の最適パスに沿ってパケットを転送するためのネットワーク全体の命令です。
The BGP Prefix Segment is defined as the BGP Prefix-SID Attribute in [RFC8669], which contains an index. Throughout this document, the BGP Prefix Segment Attribute is referred to as the "BGP Prefix-SID" and the encoded index as the label index.
BGPプレフィックスセグメントは、[RFC8669]でBGPプレフィックスSID属性として定義されており、インデックスが含まれています。このドキュメントでは、BGPプレフィックスセグメント属性を「BGPプレフィックスSID」と呼び、エンコードされたインデックスをラベルインデックスと呼びます。
In this document, the network design decision has been made to assume that all the nodes are allocated the same SRGB (Segment Routing Global Block), e.g., [16000, 23999]. This provides operational simplification as explained in Section 8, but this is not a requirement.
このドキュメントでは、ネットワーク設計の決定は、すべてのノードに同じSRGB（セグメントルーティンググローバルブロック）が割り当てられていると想定して行われています（例：[16000、23999]）。これにより、セクション8で説明するように操作が簡素化されますが、これは必須ではありません。
For illustration purposes, when considering an MPLS data plane, it is assumed that the label index allocated to prefix 192.0.2.x/32 is X. As a result, a local label (16000+x) is allocated for prefix 192.0.2.x/32 by each node throughout the DC fabric.
説明のために、MPLSデータプレーンを検討する場合、プレフィックス192.0.2.x / 32に割り当てられたラベルインデックスはXであると想定されます。その結果、ローカルラベル（16000 + x）がプレフィックス192.0.2に割り当てられます。 DCファブリック全体の各ノードによる.x / 32。
When the IPv6 data plane is considered, it is assumed that Node X is allocated IPv6 address (segment) 2001:DB8::X.
IPv6データプレーンを検討する場合、ノードXにはIPv6アドレス（セグメント）2001：DB8 :: Xが割り当てられていると想定されます。
Referring to Figure 1 and [RFC7938], the following design modifications are introduced:
図1と[RFC7938]を参照すると、次の設計変更が導入されています。
* Each node peers with its neighbors via an EBGP session with extensions defined in [RFC8277] (named "EBGP8277" throughout this document) and with the BGP Prefix-SID attribute extension as defined in [RFC8669].
* 各ノードは、[RFC8277]で定義された拡張（このドキュメントでは「EBGP8277」という名前）と[RFC8669]で定義されたBGP Prefix-SID属性拡張で、EBGPセッションを介して隣接ノードとピアリングします。
* The forwarding plane at Tier-2 and Tier-1 is MPLS.
* Tier-2およびTier-1の転送プレーンはMPLSです。
* The forwarding plane at Tier-3 is either IP2MPLS (if the host sends IP traffic) or MPLS2MPLS (if the host sends MPLS-encapsulated traffic).
* Tier-3の転送プレーンは、IP2MPLS（ホストがIPトラフィックを送信する場合）またはMPLS2MPLS（ホストがMPLSカプセル化トラフィックを送信する場合）のいずれかです。
Figure 2 zooms into a path from ServerA to ServerZ within the topology of Figure 1.
図2は、図1のトポロジ内のServerAからServerZへのパスを拡大しています。
+-----+ +-----+ +-----+
+---------->|NODE | |NODE | |NODE |
| | 4 |--+->| 7 |--+--| 10 |---+
| +-----+ +-----+ +-----+ |
| |
+-----+ +-----+
|NODE | |NODE |
| 1 | | 11 |
+-----+ +-----+
| |
A <- Servers -> Z
Figure 2: Path from A to Z via Nodes 1, 4, 7, 10, and 11
図2：ノード1、4、7、10、および11を介したAからZへのパス
Referring to Figures 1 and 2, and assuming the IP address with the AS and label-index allocation previously described, the following sections detail the control-plane operation and the data-plane states for the prefix 192.0.2.11/32 (loopback of Node11).
図1と2を参照し、前述のASとラベルインデックスの割り当てがあるIPアドレスを想定して、次のセクションでは、プレフィックス192.0.2.11/32のコントロールプレーンの動作とデータプレーンの状態について詳しく説明します（Node11のループバック）。 ）。
Node11 originates 192.0.2.11/32 in BGP and allocates to it a BGP Prefix-SID with label-index: index11 [RFC8669].
Node11はBGPで192.0.2.11/32を発信し、それにlabel-index：index11 [RFC8669]のBGP Prefix-SIDを割り当てます。
Node11 sends the following EBGP8277 update to Node10:
Node11は次のEBGP8277更新をNode10に送信します。
IP Prefix: 192.0.2.11/32
IPプレフィックス：192.0.2.11/32
Label: Implicit NULL
レーベル：Implicit NULL
Next hop: Node11's interface address on the link to Node10
ネクストホップ：Node10へのリンク上のNode11のインターフェースアドレス
AS Path: {11}
BGP Prefix-SID: Label-Index 11
BGPプレフィックスSID：ラベルインデックス11
Node10 receives the above update. As it is SR capable, Node10 is able to interpret the BGP Prefix-SID; therefore, it understands that it should allocate the label from its own SRGB block, offset by the label index received in the BGP Prefix-SID (16000+11, hence, 16011) to the Network Layer Reachability Information (NLRI) instead of allocating a nondeterministic label out of a dynamically allocated portion of the local label space. The implicit NULL label in the NLRI tells Node10 that it is the penultimate hop and that it must pop the top label on the stack before forwarding traffic for this prefix to Node11.
Node10は上記の更新を受信します。 SRに対応しているため、Node10はBGP Prefix-SIDを解釈できます。したがって、独自のSRGBブロックからラベルを割り当て、BGPプレフィックスSIDで受信したラベルインデックス（16000 + 11、つまり16011）をオフセットする代わりに、ネットワークレイヤー到達可能性情報（NLRI）に割り当てる必要があることを理解します。ローカルラベルスペースの動的に割り当てられた部分からの非決定的なラベル。 NLRIの暗黙のNULLラベルは、Node10にそれが最後から2番目のホップであること、およびこのプレフィックスのトラフィックをNode11に転送する前にスタックのトップラベルをポップする必要があることを伝えます。
Then, Node10 sends the following EBGP8277 update to Node7:
次に、Node10は次のEBGP8277アップデートをNode7に送信します。
IP Prefix: 192.0.2.11/32
IPプレフィックス：192.0.2.11/32
Label: 16011
レーベル：16011
Next hop: Node10's interface address on the link to Node7
ネクストホップ：Node7へのリンク上のNode10のインターフェースアドレス
AS Path: {10, 11}
BGP Prefix-SID: Label-Index 11
BGPプレフィックスSID：ラベルインデックス11
Node7 receives the above update. As it is SR capable, Node7 is able to interpret the BGP Prefix-SID; therefore, it allocates the local (incoming) label 16011 (16000 + 11) to the NLRI (instead of allocating a "dynamic" local label from its label manager). Node7 uses the label in the received EBGP8277 NLRI as the outgoing label (the index is only used to derive the local/incoming label).
Node7は上記の更新を受信します。 SRに対応しているため、Node7はBGP Prefix-SIDを解釈できます。したがって、ローカル（受信）ラベル16011（16000 + 11）をNLRIに割り当てます（ラベルマネージャーから「動的」ローカルラベルを割り当てるのではなく）。 Node7は、受信したEBGP8277 NLRIのラベルを発信ラベルとして使用します（インデックスはローカル/着信ラベルを取得するためにのみ使用されます）。
Node7 sends the following EBGP8277 update to Node4:
Node7は次のEBGP8277アップデートをNode4に送信します。
IP Prefix: 192.0.2.11/32
IPプレフィックス：192.0.2.11/32
Label: 16011
レーベル：16011
Next hop: Node7's interface address on the link to Node4
ネクストホップ：Node4へのリンク上のNode7のインターフェースアドレス
AS Path: {7, 10, 11}
BGP Prefix-SID: Label-Index 11
BGPプレフィックスSID：ラベルインデックス11
Node4 receives the above update. As it is SR capable, Node4 is able to interpret the BGP Prefix-SID; therefore, it allocates the local (incoming) label 16011 to the NLRI (instead of allocating a "dynamic" local label from its label manager). Node4 uses the label in the received EBGP8277 NLRI as an outgoing label (the index is only used to derive the local/incoming label).
Node4は上記の更新を受信します。 SR対応であるため、Node4はBGP Prefix-SIDを解釈できます。したがって、ローカル（着信）ラベル16011をNLRIに割り当てます（ラベルマネージャから「動的」ローカルラベルを割り当てるのではなく）。 Node4は、受信したEBGP8277 NLRIのラベルを発信ラベルとして使用します（インデックスは、ローカル/着信ラベルの導出にのみ使用されます）。
Node4 sends the following EBGP8277 update to Node1:
Node4は次のEBGP8277アップデートをNode1に送信します。
IP Prefix: 192.0.2.11/32
IPプレフィックス：192.0.2.11/32
Label: 16011
レーベル：16011
Next hop: Node4's interface address on the link to Node1
ネクストホップ：Node1へのリンク上のNode4のインターフェースアドレス
AS Path: {4, 7, 10, 11}
BGP Prefix-SID: Label-Index 11
BGPプレフィックスSID：ラベルインデックス11
Node1 receives the above update. As it is SR capable, Node1 is able to interpret the BGP Prefix-SID; therefore, it allocates the local (incoming) label 16011 to the NLRI (instead of allocating a "dynamic" local label from its label manager). Node1 uses the label in the received EBGP8277 NLRI as an outgoing label (the index is only used to derive the local/incoming label).
Node1は上記の更新を受信します。 SR対応であるため、Node1はBGPプレフィックスSIDを解釈できます。したがって、ローカル（着信）ラベル16011をNLRIに割り当てます（ラベルマネージャから「動的」ローカルラベルを割り当てるのではなく）。 Node1は、受信したEBGP8277 NLRIのラベルを発信ラベルとして使用します（インデックスは、ローカル/着信ラベルを取得するためにのみ使用されます）。
Referring to Figure 1, and assuming all nodes apply the same advertisement rules described above and all nodes have the same SRGB (16000-23999), here are the IP/MPLS forwarding tables for prefix 192.0.2.11/32 at Node1, Node4, Node7, and Node10.
図1を参照し、すべてのノードが上記の同じアドバタイズルールを適用し、すべてのノードが同じSRGB（16000-23999）を持っていると仮定すると、Node1、Node4、Node7にプレフィックス192.0.2.11/32のIP / MPLS転送テーブルがあります、Node10。
+----------------------------------+----------------+------------+
| Incoming Label or IP Destination | Outgoing Label | Outgoing |
| | | Interface |
+----------------------------------+----------------+------------+
| 16011 | 16011 | ECMP{3, 4} |
+----------------------------------+----------------+------------+
| 192.0.2.11/32 | 16011 | ECMP{3, 4} |
+----------------------------------+----------------+------------+
Table 1: Node1 Forwarding Table
表1：Node1転送テーブル
+----------------------------------+----------------+------------+
| Incoming Label or IP Destination | Outgoing Label | Outgoing |
| | | Interface |
+----------------------------------+----------------+------------+
| 16011 | 16011 | ECMP{7, 8} |
+----------------------------------+----------------+------------+
| 192.0.2.11/32 | 16011 | ECMP{7, 8} |
+----------------------------------+----------------+------------+
Table 2: Node4 Forwarding Table
表2：Node4転送テーブル
+----------------------------------+----------------+-----------+
| Incoming Label or IP Destination | Outgoing Label | Outgoing |
| | | Interface |
+----------------------------------+----------------+-----------+
| 16011 | 16011 | 10 |
+----------------------------------+----------------+-----------+
| 192.0.2.11/32 | 16011 | 10 |
+----------------------------------+----------------+-----------+
Table 3: Node7 Forwarding Table
表3：Node7転送テーブル
+----------------------------------+----------------+-----------+
| Incoming Label or IP Destination | Outgoing Label | Outgoing |
| | | Interface |
+----------------------------------+----------------+-----------+
| 16011 | POP | 11 |
+----------------------------------+----------------+-----------+
| 192.0.2.11/32 | N/A | 11 |
+----------------------------------+----------------+-----------+
Table 4: Node10 Forwarding Table
表4：Node10転送テーブル
A network design choice could consist of switching all the traffic through Tier-1 and Tier-2 as MPLS traffic. In this case, one could filter away the IP entries at Node4, Node7, and Node10. This might be beneficial in order to optimize the forwarding table size.
ネットワーク設計の選択は、Tier-1およびTier-2を介してすべてのトラフィックをMPLSトラフィックとしてスイッチングすることで構成できます。この場合、Node4、Node7、およびNode10のIPエントリをフィルターで除外できます。これは、転送テーブルのサイズを最適化するために役立ちます。
A network design choice could consist of allowing the hosts to send MPLS-encapsulated traffic based on the Egress Peer Engineering (EPE) use case as defined in [SR-CENTRAL-EPE]. For example, applications at HostA would send their Z-destined traffic to Node1 with an MPLS label stack where the top label is 16011 and the next label is an EPE peer segment ([SR-CENTRAL-EPE]) at Node11 directing the traffic to Z.
ネットワーク設計の選択は、[SR-CENTRAL-EPE]で定義されているEgress Peer Engineering（EPE）ユースケースに基づいて、ホストがMPLSカプセル化トラフィックを送信できるようにすることで構成できます。たとえば、HostAのアプリケーションは、Z宛てのトラフィックをMPLSラベルスタックでNode1に送信します。この場合、トップラベルは16011で、次のラベルはNode11のEPEピアセグメント（[SR-CENTRAL-EPE]）であり、トラフィックを送信します。 Z
When the previous design is deployed, the operator enjoys global BGP Prefix-SID and label allocation throughout the DC fabric.
以前の設計が展開されると、オペレーターはDCファブリック全体でグローバルなBGPプレフィックスSIDとラベル割り当てを利用できます。
A few examples follow:
次にいくつかの例を示します。
* Normal forwarding to Node11: A packet with top label 16011 received by any node in the fabric will be forwarded along the ECMP-aware BGP best path towards Node11, and the label 16011 is penultimate popped at Node10 (or at Node 9).
* Node11への通常の転送：ファブリック内の任意のノードによって受信されたトップラベル16011のパケットは、ECMP認識のBGPベストパスに沿ってNode11に転送され、ラベル16011はNode10（またはNode 9）で最後から2番目にポップされます。
* Traffic-engineered path to Node11: An application on a host behind Node1 might want to restrict its traffic to paths via the Spine node Node5. The application achieves this by sending its packets with a label stack of {16005, 16011}. BGP Prefix-SID 16005 directs the packet up to Node5 along the path (Node1, Node3, Node5). BGP Prefix-SID 16011 then directs the packet down to Node11 along the path (Node5, Node9, Node11).
* Node11へのトラフィックエンジニアリングされたパス：Node1の背後にあるホスト上のアプリケーションは、SpineノードNode5を経由するパスへのトラフィックを制限したい場合があります。アプリケーションは、ラベルスタックが{16005、16011}のパケットを送信することでこれを実現します。 BGP Prefix-SID 16005は、パケットをパス（Node1、Node3、Node5）に沿ってNode5まで転送します。次に、BGP Prefix-SID 16011は、パケットをパス（Node5、Node9、Node11）に沿ってNode11に転送します。
The design previously described can be deployed incrementally. Let us assume that Node7 does not support the BGP Prefix-SID, and let us show how the fabric connectivity is preserved.
前述の設計は段階的に展開できます。 Node7がBGP Prefix-SIDをサポートしていないと想定し、ファブリック接続がどのように維持されるかを示します。
From a signaling viewpoint, nothing would change; even though Node7 does not support the BGP Prefix-SID, it does propagate the attribute unmodified to its neighbors.
シグナリングの観点からは、何も変化しません。 Node7はBGP Prefix-SIDをサポートしていませんが、属性を変更せずにネイバーに伝播します。
From a label-allocation viewpoint, the only difference is that Node7 would allocate a dynamic (random) label to the prefix 192.0.2.11/32 (e.g., 123456) instead of the "hinted" label as instructed by the BGP Prefix-SID. The neighbors of Node7 adapt automatically as they always use the label in the BGP8277 NLRI as an outgoing label.
ラベル割り当ての観点からの唯一の違いは、Node7が、BGPプレフィックスSIDによって指示された「ヒント」ラベルではなく、プレフィックス192.0.2.11/32（123456など）に動的（ランダム）ラベルを割り当てることです。 Node7のネイバーは常にBGP8277 NLRIのラベルを発信ラベルとして使用するため、自動的に適応します。
Node4 does understand the BGP Prefix-SID; therefore, it allocates the indexed label in the SRGB (16011) for 192.0.2.11/32.
Node4はBGP Prefix-SIDを理解しています。したがって、192.0.2.11 / 32のSRGB（16011）にインデックス付きラベルを割り当てます。
As a result, all the data-plane entries across the network would be unchanged except the entries at Node7 and its neighbor Node4 as shown in the figures below.
その結果、下の図に示すように、ノード7とその隣接ノード4のエントリを除いて、ネットワーク全体のすべてのデータプレーンエントリは変更されません。
The key point is that the end-to-end Label Switched Path (LSP) is preserved because the outgoing label is always derived from the received label within the BGP8277 NLRI. The index in the BGP Prefix-SID is only used as a hint on how to allocate the local label (the incoming label) but never for the outgoing label.
重要な点は、発信ラベルは常にBGP8277 NLRI内の受信ラベルから派生するため、エンドツーエンドのラベルスイッチドパス（LSP）が保持されることです。 BGP Prefix-SIDのインデックスは、ローカルラベル（着信ラベル）を割り当てる方法のヒントとしてのみ使用され、発信ラベルには使用されません。
+----------------------------------+----------------+-----------+
| Incoming Label or IP Destination | Outgoing Label | Outgoing |
| | | Interface |
+----------------------------------+----------------+-----------+
| 12345 | 16011 | 10 |
+----------------------------------+----------------+-----------+
Table 5: Node7 Forwarding Table
表5：Node7転送テーブル
+----------------------------------+----------------+-----------+
| Incoming Label or IP Destination | Outgoing Label | Outgoing |
| | | Interface |
+----------------------------------+----------------+-----------+
| 16011 | 12345 | 7 |
+----------------------------------+----------------+-----------+
Table 6: Node4 Forwarding Table
表6：Node4転送テーブル
The BGP Prefix-SID can thus be deployed incrementally, i.e., one node at a time.
したがって、BGPプレフィックスSIDは、段階的に展開できます。つまり、一度に1つのノードです。
When deployed together with a homogeneous SRGB (the same SRGB across the fabric), the operator incrementally enjoys the global prefix segment benefits as the deployment progresses through the fabric.
同種のSRGB（ファブリック全体で同じSRGB）と一緒に展開すると、展開がファブリック全体で進行するにつれて、オペレーターはグローバルプレフィックスセグメントのメリットを徐々に享受できます。
The same exact design as EBGP8277 is used with the following modifications:
EBGP8277とまったく同じ設計で、次の変更が加えられています。
* All nodes use the same AS number.
* すべてのノードが同じAS番号を使用します。
* Each node peers with its neighbors via an internal BGP session (IBGP) with extensions defined in [RFC8277] (named "IBGP8277" throughout this document).
* 各ノードは、[RFC8277]で定義された拡張機能を備えた内部BGPセッション（IBGP）を介して隣接ノードとピアリングします（このドキュメント全体で「IBGP8277」という名前）。
* Each node acts as a route reflector for each of its neighbors and with the next-hop-self option. Next-hop-self is a well-known operational feature that consists of rewriting the next hop of a BGP update prior to sending it to the neighbor. Usually, it's a common practice to apply next-hop-self behavior towards IBGP peers for EBGP-learned routes. In the case outlined in this section, it is proposed to use the next-hop-self mechanism also to IBGP-learned routes.
* 各ノードは、その各ネイバーのルートリフレクタとして機能し、next-hop-selfオプションを備えています。 Next-hop-selfは、BGPアップデートのネクストホップをネイバーに送信する前に書き換えることで構成される、よく知られた操作機能です。通常、EBGP学習ルートのIBGPピアにネクストホップセルフ動作を適用することは一般的な方法です。このセクションで概説されているケースでは、IBGPで学習されたルートに対しても、next-hop-selfメカニズムを使用することが提案されています。
Cluster-1
+-----------+
| Tier-1 |
| +-----+ |
| |NODE | |
| | 5 | |
Cluster-2 | +-----+ | Cluster-3
+---------+ | | +---------+
| Tier-2 | | | | Tier-2 |
| +-----+ | | +-----+ | | +-----+ |
| |NODE | | | |NODE | | | |NODE | |
| | 3 | | | | 6 | | | | 9 | |
| +-----+ | | +-----+ | | +-----+ |
| | | | | |
| | | | | |
| +-----+ | | +-----+ | | +-----+ |
| |NODE | | | |NODE | | | |NODE | |
| | 4 | | | | 7 | | | | 10 | |
| +-----+ | | +-----+ | | +-----+ |
+---------+ | | +---------+
| |
| +-----+ |
| |NODE | |
Tier-3 | | 8 | | Tier-3
+-----+ +-----+ | +-----+ | +-----+ +-----+
|NODE | |NODE | +-----------+ |NODE | |NODE |
| 1 | | 2 | | 11 | | 12 |
+-----+ +-----+ +-----+ +-----+
Figure 3: IBGP Sessions with Reflection and Next-Hop-Self
図3：リフレクションとネクストホップセルフを含むIBGPセッション
* For simple and efficient route propagation filtering and as illustrated in Figure 3:
* 図3に示すように、単純で効率的なルート伝搬フィルタリングの場合：
- Node5, Node6, Node7, and Node8 use the same Cluster ID (Cluster-1).
- ノード、ノード6、ノード、およびノード8は同じクラスターID（クラスター1）を使用します。
- Node3 and Node4 use the same Cluster ID (Cluster-2).
- Node3とNode4は同じクラスターID（Cluster-2）を使用します。
- Node9 and Node10 use the same Cluster ID (Cluster-3).
- Node9とNode10は同じクラスターID（Cluster-3）を使用します。
* The control-plane behavior is mostly the same as described in the previous section; the only difference is that the EBGP8277 path propagation is simply replaced by an IBGP8277 path reflection with next hop changed to self.
* コントロールプレーンの動作は、前のセクションで説明したものとほとんど同じです。唯一の違いは、EBGP8277パスの伝搬が、ネクストホップが自己に変更されたIBGP8277パスリフレクションに置き換えられるだけです。
* The data-plane tables are exactly the same.
* データプレーンテーブルはまったく同じです。
The design described in [RFC7938] is reused with one single modification. It is highlighted using the example of the reachability to Node11 via Spine node Node5.
[RFC7938]で説明されている設計は、1つの変更を加えて再利用されます。スパインノードNode5を介したNode11への到達可能性の例を使用して強調表示されています。
Node5 originates 2001:DB8::5/128 with the attached BGP Prefix-SID for IPv6 packets destined to segment 2001:DB8::5 ([RFC8402]).
Node5は、2001：DB8 :: 5（[RFC8402]）宛てのIPv6パケット用のBGPプレフィックスSIDが付加された2001：DB8 :: 5/128を発信します。
Node11 originates 2001:DB8::11/128 with the attached BGP Prefix-SID advertising the support of the Segment Routing Header (SRH) for IPv6 packets destined to segment 2001:DB8::11.
Node11は、2001：DB8 :: 11を宛先とするIPv6パケットのセグメントルーティングヘッダー（SRH）のサポートをアドバタイズするBGPプレフィックスSIDが付加された2001：DB8 :: 11/128から発信されます。
The control-plane and data-plane processing of all the other nodes in the fabric is unchanged. Specifically, the routes to 2001:DB8::5 and 2001:DB8::11 are installed in the FIB along the EBGP best path to Node5 (Spine node) and Node11 (ToR node) respectively.
ファブリック内の他のすべてのノードのコントロールプレーンおよびデータプレーンの処理は変更されていません。具体的には、2001：DB8 :: 5および2001：DB8 :: 11へのルートは、それぞれNode5（スパインノード）およびNode11（ToRノード）へのEBGPベストパスに沿ってFIBにインストールされます。
An application on HostA that needs to send traffic to HostZ via only Node5 (Spine node) can do so by sending IPv6 packets with a Segment Routing Header (SRH, [IPv6-SRH]). The destination address and active segment is set to 2001:DB8::5. The next and last segment is set to 2001:DB8::11.
Node5（Spineノード）のみを介してHostZにトラフィックを送信する必要があるHostA上のアプリケーションは、セグメントルーティングヘッダー（SRH、[IPv6-SRH]）を使用してIPv6パケットを送信することで送信できます。宛先アドレスとアクティブセグメントは2001：DB8 :: 5に設定されます。次と最後のセグメントは2001：DB8 :: 11に設定されます。
The application must only use IPv6 addresses that have been advertised as capable for SRv6 segment processing (e.g., for which the BGP Prefix Segment capability has been advertised). How applications learn this (e.g., centralized controller and orchestration) is outside the scope of this document.
アプリケーションは、SRv6セグメント処理が可能であるとアドバタイズされている（たとえば、BGPプレフィックスセグメント機能がアドバタイズされている）IPv6アドレスのみを使用する必要があります。アプリケーションがこれをどのように学習するか（たとえば、集中型コントローラーとオーケストレーション）は、このドキュメントの範囲外です。
There are two general methods for communicating path information to the end-hosts: "proactive" and "reactive", aka "push" and "pull" models. There are multiple ways to implement either of these methods. Here, it is noted that one way could be using a centralized controller: the controller either tells the hosts of the prefix-to-path mappings beforehand and updates them as needed (network event driven push) or responds to the hosts making requests for a path to a specific destination (host event driven pull). It is also possible to use a hybrid model, i.e., pushing some state from the controller in response to particular network events, while the host pulls other state on demand.
エンドホストへのパス情報の通信には、「プロアクティブ」と「リアクティブ」の2つの一般的な方法があり、「プッシュ」モデルと「プル」モデルとも呼ばれます。これらの方法のいずれかを実装するには、複数の方法があります。ここでは、1つの方法が集中型コントローラーを使用している可能性があることに注意してください。コントローラーは、プレフィックスとパスのマッピングをホストに事前に通知し、必要に応じてそれらを更新するか（ネットワークイベントドリブンプッシュ）、ホストにリクエストを送信して応答します。特定の宛先へのパス（ホストイベント駆動型プル）。ハイブリッドモデルを使用することもできます。つまり、特定のネットワークイベントに応じてコントローラーからいくつかの状態をプッシュし、ホストが要求に応じて他の状態をプルします。
Note also that when disseminating network-related data to the end-hosts, a trade-off is made to balance the amount of information vs. the level of visibility in the network state. This applies to both push and pull models. In the extreme case, the host would request path information on every flow and keep no local state at all. On the other end of the spectrum, information for every prefix in the network along with available paths could be pushed and continuously updated on all hosts.
また、ネットワーク関連のデータをエンドホストに配布する場合、情報量とネットワーク状態の可視性のレベルのバランスを取るためにトレードオフが行われることにも注意してください。これは、プッシュモデルとプルモデルの両方に適用されます。極端な場合、ホストはすべてのフローのパス情報を要求し、ローカル状態をまったく保持しません。スペクトルの反対側では、ネットワーク内のすべてのプレフィックスの情報と使用可能なパスがプッシュされ、すべてのホストで継続的に更新されます。
As required by [RFC7938], no new signaling protocol is introduced. The BGP Prefix-SID is a lightweight extension to BGP Labeled Unicast [RFC8277]. It applies either to EBGP- or IBGP-based designs.
[RFC7938]で要求されているように、新しいシグナリングプロトコルは導入されていません。 BGPプレフィックスSIDは、BGPラベル付きユニキャスト[RFC8277]の軽量拡張です。 EBGPベースまたはIBGPベースのデザインに適用されます。
Specifically, LDP and RSVP-TE are not used. These protocols would drastically impact the operational complexity of the data center and would not scale. This is in line with the requirements expressed in [RFC7938].
具体的には、LDPおよびRSVP-TEは使用されません。これらのプロトコルは、データセンターの運用上の複雑さに大きな影響を与え、拡張できません。これは、[RFC7938]で表現されている要件と一致しています。
Provided the same SRGB is configured on all nodes, all nodes use the same MPLS label for a given IP prefix. This is simpler from an operation standpoint, as discussed in Section 8.
すべてのノードで同じSRGBが構成されている場合、すべてのノードは特定のIPプレフィックスに同じMPLSラベルを使用します。これは、セクション8で説明されているように、操作の観点からは単純です。
The designer may decide to switch all the traffic at Tier-1 and Tier-2 based on MPLS, thereby drastically decreasing the IP table size at these nodes.
設計者は、MPLSに基づいてTier-1とTier-2ですべてのトラフィックを切り替えることを決定できます。これにより、これらのノードでのIPテーブルサイズが大幅に減少します。
This is easily accomplished by encapsulating the traffic either directly at the host or at the source ToR node. The encapsulation is done by pushing the BGP Prefix-SID of the destination ToR for intra-DC traffic, or by pushing the BGP Prefix-SID for the border node for inter-DC or DC-to-outside-world traffic.
これは、ホストまたは送信元のToRノードで直接トラフィックをカプセル化することで簡単に実現できます。カプセル化は、DC内トラフィックの場合は宛先ToRのBGPプレフィックスSIDをプッシュするか、DC間またはDCから外部へのトラフィックの場合は境界ノードのBGPプレフィックスSIDをプッシュすることによって行われます。
It is straightforward to combine the design illustrated in this document with the Egress Peer Engineering (EPE) use case described in [SR-CENTRAL-EPE].
このドキュメントに示されている設計を、[SR-CENTRAL-EPE]で説明されているEgress Peer Engineering（EPE）のユースケースと組み合わせるのは簡単です。
In such a case, the operator is able to engineer its outbound traffic on a per-host-flow basis, without incurring any additional state at intermediate points in the DC fabric.
このような場合、オペレーターは、DCファブリックの中間点で追加の状態を発生させることなく、ホストフローごとに送信トラフィックを設計できます。
For example, the controller only needs to inject a per-flow state on the HostA to force it to send its traffic destined to a specific Internet destination D via a selected border node (say Node12 in Figure 1 instead of another border node, Node11) and a specific egress peer of Node12 (say peer AS 9999 of local PeerNode segment 9999 at Node12 instead of any other peer that provides a path to the destination D). Any packet matching this state at HostA would be encapsulated with SR segment list (label stack) {16012, 9999}. 16012 would steer the flow through the DC fabric, leveraging any ECMP, along the best path to border node Node12. Once the flow gets to border node Node12, the active segment is 9999 (because of Penultimate Hop Popping (PHP) on the upstream neighbor of Node12). This EPE PeerNode segment forces border node Node12 to forward the packet to peer AS 9999 without any IP lookup at the border node. There is no per-flow state for this engineered flow in the DC fabric. A benefit of SR is that the per-flow state is only required at the source.
たとえば、コントローラーはHostAにフローごとの状態を挿入するだけで、選択した境界ノード（別の境界ノードNode11ではなく、図1のNode12など）を介して、特定のインターネット宛先D宛てのトラフィックを送信します。およびNode12の特定の出力ピア（たとえば、宛先Dへのパスを提供する他のピアではなく、Node12のローカルPeerNodeセグメント9999のピアAS 9999）。 HostAでこの状態に一致するパケットは、SRセグメントリスト（ラベルスタック）{16012、9999}でカプセル化されます。 16012は、境界ノードNode12への最適なパスに沿って、ECMPを活用して、DCファブリックを通過するフローを誘導します。フローが境界ノードNode12に到達すると、アクティブセグメントは9999になります（Node12の上流ネイバーでのPenultimate Hop Popping（PHP）のため）。このEPE PeerNodeセグメントは、境界ノードでのIPルックアップなしで、境界ノードNode12にパケットをピアAS 9999に転送させます。 DCファブリックでは、この設計されたフローのフローごとの状態はありません。 SRの利点は、フローごとの状態がソースでのみ必要であることです。
As well as allowing full traffic-engineering control, such a design also offers FIB table-minimization benefits as the Internet-scale FIB at border node Node12 is not required if all FIB lookups are avoided there by using EPE.
EPEを使用してすべてのFIBルックアップを回避する場合、境界ノードNode12でのインターネットスケールFIBは必要ないため、このような設計は完全なトラフィックエンジニアリング制御を可能にするだけでなく、FIBテーブルの最小化の利点も提供します。
The design presented in this document preserves the availability and load-balancing properties of the base design presented in [RFC8402].
このドキュメントに示されている設計は、[RFC8402]に示されている基本設計の可用性とロードバランシングプロパティを保持しています。
For example, one could assign an anycast loopback 192.0.2.20/32 and associate segment index 20 to it on the border nodes Node11 and Node12 (in addition to their node-specific loopbacks). Doing so, the EPE controller could express a default "go-to-the-Internet via any border node" policy as segment list {16020}. Indeed, from any host in the DC fabric or from any ToR node, 16020 steers the packet towards the border nodes Node11 or Node12 leveraging ECMP where available along the best paths to these nodes.
たとえば、エニーキャストループバック192.0.2.20/32を割り当て、境界ノードNode11およびNode12のセグメントインデックス20を（ノード固有のループバックに加えて）関連付けることができます。そうすることで、EPEコントローラーは、デフォルトの「任意の境界ノードを介したインターネットへの移動」ポリシーをセグメントリスト{16020}として表現できます。実際、DCファブリック内の任意のホストまたは任意のToRノードから、16020は、これらのノードへの最適なパスに沿ってECMPを利用して、境界ノードNode11またはNode12に向けてパケットを誘導します。
In the MPLS case, it is recommended to use the same SRGBs at each node.
MPLSの場合、各ノードで同じSRGBを使用することをお勧めします。
Different SRGBs in each node likely increase the complexity of the solution both from an operational viewpoint and from a controller viewpoint.
各ノードのSRGBが異なると、運用上の観点とコントローラーの観点の両方からソリューションの複雑さが増す可能性があります。
From an operational viewpoint, it is much simpler to have the same global label at every node for the same destination (the MPLS troubleshooting is then similar to the IPv6 troubleshooting where this global property is a given).
運用上の観点から、同じ宛先のすべてのノードで同じグローバルラベルを使用する方がはるかに簡単です（MPLSのトラブルシューティングは、このグローバルプロパティが指定されているIPv6のトラブルシューティングに似ています）。
From a controller viewpoint, this allows us to construct simple policies applicable across the fabric.
これにより、コントローラーの観点から、ファブリック全体に適用可能な単純なポリシーを構築できます。
Let us consider two applications, A and B, respectively connected to Node1 and Node2 (ToR nodes). Application A has two flows, FA1 and FA2, destined to Z. B has two flows, FB1 and FB2, destined to Z. The controller wants FA1 and FB1 to be load shared across the fabric while FA2 and FB2 must be respectively steered via Node5 and Node8.
Node1とNode2（ToRノード）にそれぞれ接続された2つのアプリケーションAとBを考えてみましょう。アプリケーションAには、Z宛てのFA1とFA2の2つのフローがあります。Bには、Z宛てのFB1とFB2の2つのフローがあります。コントローラーは、FA1とFB1がファブリック全体でロードシェアリングされることを望みますが、FA2とFB2はそれぞれNode5経由でステアリングされる必要があります。およびNode8。
Assuming a consistent unique SRGB across the fabric as described in this document, the controller can simply do it by instructing A and B to use {16011} respectively for FA1 and FB1 and by instructing A and B to use {16005 16011} and {16008 16011} respectively for FA2 and FB2.
このドキュメントで説明されているように、ファブリック全体で一貫した一意のSRGBを想定すると、コントローラーは、FA1とFB1に対してそれぞれAとBに{16011}を使用するように指示し、AとBに{16005 16011}と{16008を使用するように指示することによって、簡単に実行できます。 16011} FA2およびFB2のそれぞれ。
Let us assume a design where the SRGB is different at every node and where the SRGB of each node is advertised using the Originator SRGB TLV of the BGP Prefix-SID as defined in [RFC8669]: SRGB of Node K starts at value K*1000, and the SRGB length is 1000 (e.g., Node1's SRGB is [1000, 1999], Node2's SRGB is [2000, 2999], ...).
[RFC8669]で定義されているように、BGP Prefix-SIDのOriginator SRGB TLVを使用して各ノードのSRGBがアドバタイズされるデザインを想定します。ノードKのSRGBは値K * 1000から始まります。 、およびSRGBの長さは1000です（たとえば、Node1のSRGBは[1000、1999]、Node2のSRGBは[2000、2999]など）。
In this case, the controller would need to collect and store all of these different SRGBs (e.g., through the Originator SRGB TLV of the BGP Prefix-SID); furthermore, it would also need to adapt the policy for each host. Indeed, the controller would instruct A to use {1011} for FA1 while it would have to instruct B to use {2011} for FB1 (while with the same SRGB, both policies are the same {16011}).
この場合、コントローラーはこれらの異なるSRGBをすべて収集して保存する必要があります（たとえば、BGPプレフィックスSIDの発信元SRGB TLVを介して）。さらに、各ホストのポリシーを適合させる必要もあります。実際、コントローラーはAにFA1に{1011}を使用するように指示する一方で、BにFB1に{2011}を使用するように指示する必要があります（同じSRGBの場合、両方のポリシーは同じ{16011}）。
Even worse, the controller would instruct A to use {1005, 5011} for FA1 while it would instruct B to use {2011, 8011} for FB1 (while with the same SRGB, the second segment is the same across both policies: 16011). When combining segments to create a policy, one needs to carefully update the label of each segment. This is obviously more error prone, more complex, and more difficult to troubleshoot.
さらに悪いことに、コントローラーはAにFA1に{1005、5011}を使用するように指示し、BにFB1に{2011、8011}を使用するように指示します（同じSRGBの場合、2番目のセグメントは両方のポリシーで同じです：16011） 。セグメントを組み合わせてポリシーを作成する場合、各セグメントのラベルを慎重に更新する必要があります。これは明らかにエラーが発生しやすく、複雑で、トラブルシューティングがより困難です。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The design and deployment guidelines described in this document are based on the network design described in [RFC7938].
このドキュメントで説明されている設計と展開のガイドラインは、[RFC7938]で説明されているネットワーク設計に基づいています。
The deployment model assumed in this document is based on a single domain where the interconnected DCs are part of the same administrative domain (which, of course, is split into different autonomous systems). The operator has full control of the whole domain, and the usual operational and management mechanisms and procedures are used in order to prevent any information related to internal prefixes and topology to be leaked outside the domain.
このドキュメントで想定されている展開モデルは、相互接続されたDCが同じ管理ドメイン（もちろん、異なる自律システムに分割されている）の一部である単一ドメインに基づいています。オペレーターはドメイン全体を完全に制御し、通常の運用および管理メカニズムと手順を使用して、内部プレフィックスとトポロジに関連する情報がドメイン外に漏洩するのを防ぎます。
As recommended in [RFC8402], the same SRGB should be allocated in all nodes in order to facilitate the design, deployment, and operations of the domain.
[RFC8402]で推奨されているように、ドメインの設計、展開、および操作を容易にするために、同じSRGBをすべてのノードに割り当てる必要があります。
When EPE ([SR-CENTRAL-EPE]) is used (as explained in Section 7.3), the same operational model is assumed. EPE information is originated and propagated throughout the domain towards an internal server, and unless explicitly configured by the operator, no EPE information is leaked outside the domain boundaries.
EPE（[SR-CENTRAL-EPE]）を使用する場合（第7.3項で説明）、同じ運用モデルが想定されます。 EPE情報は、ドメイン全体で生成され、内部サーバーに向けて伝達されます。オペレーターによって明示的に構成されていない限り、EPE情報はドメイン境界の外に漏洩しません。
This document proposes to apply SR to a well-known scalability requirement expressed in [RFC7938] using the BGP Prefix-SID as defined in [RFC8669].
このドキュメントは、[RFC8669]で定義されているBGP Prefix-SIDを使用して、[RFC7938]で表現されている既知のスケーラビリティ要件にSRを適用することを提案しています。
It has to be noted, as described in Section 10, that the design illustrated in [RFC7938] and in this document refer to a deployment model where all nodes are under the same administration. In this context, it is assumed that the operator doesn't want to leak outside of the domain any information related to internal prefixes and topology. The internal information includes Prefix-SID and EPE information. In order to prevent such leaking, the standard BGP mechanisms (filters) are applied on the boundary of the domain.
セクション10で説明されているように、[RFC7938]およびこのドキュメントで示されている設計は、すべてのノードが同じ管理下にある配備モデルを指すことに注意する必要があります。このコンテキストでは、オペレーターが内部のプレフィックスとトポロジに関連する情報をドメインの外に漏らしたくないと想定されています。内部情報には、Prefix-SIDおよびEPE情報が含まれます。このような漏洩を防ぐために、標準のBGPメカニズム（フィルター）がドメインの境界に適用されます。
Therefore, the solution proposed in this document does not introduce any additional security concerns from what is expressed in [RFC7938] and [RFC8669]. It is assumed that the security and confidentiality of the prefix and topology information is preserved by outbound filters at each peering point of the domain as described in Section 10.
したがって、このドキュメントで提案されているソリューションは、[RFC7938]および[RFC8669]で表現されているものからの追加のセキュリティ上の懸念をもたらしません。プレフィックスとトポロジ情報のセキュリティと機密性は、セクション10で説明されているように、ドメインの各ピアリングポイントで発信フィルターによって保持されると想定されています。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, <https://www.rfc-editor.org/info/rfc7938>.
[RFC7938] Lapukhov、P.、Premji、A。、およびJ. Mitchell、編、「大規模データセンターでのルーティングのためのBGPの使用」、RFC 7938、DOI 10.17487 / RFC7938、2016年8月、<https：/ /www.rfc-editor.org/info/rfc7938>。
[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>。
[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>。
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10.17487/RFC8669, December 2019, <https://www.rfc-editor.org/info/rfc8669>.
[RFC8669] Previdi、S.、Filsfils、C.、Lindem、A.、Ed。、Sreekantiah、A.、and H. Gredler、 "Segment Routing Prefix Segment Identifier Extensions for BGP"、RFC 8669、DOI 10.17487 / RFC8669、 2019年12月、<https://www.rfc-editor.org/info/rfc8669>。
[IPv6-SRH] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", Work in Progress, Internet-Draft, draft-ietf-6man-segment-routing-header-26, 22 October 2019, <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26>.
[IPv6-SRH] Filsfils、C.、Dukes、D.、Previdi、S.、Leddy、J.、Matsushima、S。、およびD. Voyer、「IPv6 Segment Routing Header（SRH）」、Work in Progress、インターネット-Draft、draft-ietf-6man-segment-routing-header-26、2019年10月22日、<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26>。
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>.
[RFC6793] Vohra、Q.、E。Chen、「BGP Support for Four-Octet Autonomous System（AS）Number Space」、RFC 6793、DOI 10.17487 / RFC6793、2012年12月、<https：//www.rfc-editor。 org / info / rfc6793>。
[SR-CENTRAL-EPE] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-central-epe-10, 21 December 2017, <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10>.
[SR-CENTRAL-EPE] Filsfils、C.、Previdi、S.、Dawra、G.、Aries、E。、およびD. Afanasiev、「Segment Routing Centralized BGP Egress Peer Engineering」、Work in Progress、Internet-Draft、 draft-ietf-spring-segment-routing-central-epe-10、2017年12月21日、<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10>。
Acknowledgements
謝辞
The authors would like to thank Benjamin Black, Arjun Sreekantiah, Keyur Patel, Acee Lindem, and Anoop Ghanwani for their comments and review of this document.
このドキュメントのコメントとレビューを提供してくれたベンジャミンブラック、アルジュンスリカンティア、キールパテル、アシーリンデム、アヌープガンワニに感謝します。
Contributors
貢献者
Gaya Nagarajan Facebook United States of America
ガヤナガラジャンFacebookアメリカ合衆国
Email: gaya@fb.com
Gaurav Dawra Cisco Systems United States of America
Gaurav Dawra Cisco Systemsアメリカ合衆国
Email: gdawra.ietf@gmail.com
Dmitry Afanasiev Yandex Russian Federation
Dmitry Afanasiev Yandexロシア連邦
Email: fl0w@yandex-team.ru
Tim Laberge Cisco United States of America
Tim Laberge Ciscoアメリカ合衆国
Email: tlaberge@cisco.com
Edet Nkposong Salesforce.com Inc. United States of America
Edet Nkposong Salesforce.com Inc.アメリカ合衆国
Email: enkposong@salesforce.com
Mohan Nanduri Microsoft United States of America
Mohan Nanduriマイクロソフトアメリカ合衆国
Email: mohan.nanduri@oracle.com
James Uttaro ATT United States of America
James Uttaro ATTアメリカ合衆国
Email: ju1738@att.com
Saikat Ray Unaffiliated United States of America
サイカットレイ非関連アメリカ合衆国
Email: raysaikat@gmail.com
Jon Mitchell Unaffiliated United States of America
ジョンミッチェル系列外のアメリカ合衆国
Email: jrmitche@puck.nether.net
Authors' Addresses
著者のアドレス
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（editor）Cisco Systems、Inc. Brussels Belgium
Email: cfilsfil@cisco.com
Stefano Previdi Cisco Systems, Inc. Italy
Stefano Previdi Cisco Systems、Inc.イタリア
Email: stefano@previdi.net
Gaurav Dawra LinkedIn United States of America
Gaurav Dawra LinkedInアメリカ合衆国
Email: gdawra.ietf@gmail.com
Ebben Aries Arrcus, Inc. 2077 Gateway Place, Suite #400 San Jose, CA 95119 United States of America
Ebben Aries Arrcus、Inc. 2077 Gateway Place、Suite＃400 San Jose、CA 95119アメリカ合衆国
Email: exa@arrcus.com
Petr Lapukhov Facebook United States of America
ペトル・ラプホフFacebookアメリカ合衆国
Email: petr@fb.com