Internet Engineering Task Force (IETF) Y. Wei, Ed.
Request for Comments: 9696 Z. Zhang
Category: Informational ZTE Corporation
ISSN: 2070-1721 D. Afanasiev
Yandex
P. Thubert
Individual
T. Przygienda
Juniper Networks
April 2025
This document discusses the properties, applicability, and operational considerations of Routing in Fat Trees (RIFT) in different network scenarios with the intention of providing a rough guide on how RIFT can be deployed to simplify routing operations in Clos topologies and their variations.
このドキュメントでは、さまざまなネットワークシナリオでの脂肪木（RIFT）でのルーティングのプロパティ、適用性、および運用上の考慮事項について説明します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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）の製品です。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/rfc9696.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9696で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Problem Statement of Routing in Modern IP Fabric Fat Tree
Networks
4. Applicability of RIFT to Clos IP Fabrics
4.1. Overview of RIFT
4.2. Applicable Topologies
4.2.1. Horizontal Links
4.2.2. Vertical Shortcuts
4.2.3. Generalizing to Any Directed Acyclic Graph
4.2.4. Reachability of Internal Nodes in the Fabric
4.3. Use Cases
4.3.1. Data Center Topologies
4.3.2. Metro Networks
4.3.3. Building Cabling
4.3.4. Internal Router Switching Fabrics
4.3.5. CloudCO
5. Operational Considerations
5.1. South Reflection
5.2. Suboptimal Routing on Link Failures
5.3. Black-Holing on Link Failures
5.4. Zero Touch Provisioning (ZTP)
5.5. Miscabling
5.5.1. Miscabling Examples
5.5.2. Miscabling Considerations
5.6. Multicast and Broadcast Implementations
5.7. Positive vs. Negative Disaggregation
5.8. Mobile Edge and Anycast
5.9. IPv4 over IPv6
5.10. In-Band Reachability of Nodes
5.11. Dual-Homing Servers
5.12. Fabric with a Controller
5.12.1. Controller Attached to ToFs
5.12.2. Controller Attached to Leaf
5.13. Internet Connectivity Within Underlay
5.13.1. Internet Default on the Leaf
5.13.2. Internet Default on the ToFs
5.14. Subnet Mismatch and Address Families
5.15. Anycast Considerations
5.16. IoT Applicability
5.17. Key Management
5.18. TTL/Hop Limit of 1 vs. 255 on LIEs/TIEs
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
This document discusses the properties and applicability of "RIFT: Routing in Fat Trees" [RFC9692] in different deployment scenarios and highlights the operational simplicity of the technology compared to classical routing solutions. It also documents special considerations when RIFT is used with or without overlays and/or controllers and how RIFT identifies miscablings and reroutes around node and link failures.
このドキュメントでは、さまざまな展開シナリオにおける「Rift：fat Treesでのルーティング」[RFC9692]のプロパティと適用性について説明し、古典的なルーティングソリューションと比較したテクノロジーの運用シンプルさを強調しています。また、オーバーレイやコントローラーの有無にかかわらずRIFTが使用されている場合、およびRiftがノードおよびリンク障害の周りの混乱と再ルーティングをどのように識別するかを文書化します。
This document uses the terminology defined in [RFC9692]. The most frequently used terms and their definitions from that document are listed here.
このドキュメントでは、[RFC9692]で定義されている用語を使用しています。最も頻繁に使用される用語とそのドキュメントからの定義は、ここにリストされています。
Clos / Fat Tree:
クローズ /ファットツリー：
This document uses the terms "Clos" and "Fat Tree" interchangeably where it always refers to a folded spine-and-leaf topology with possibly multiple Points of Delivery (PoDs) and one or multiple Top of Fabric (ToF) planes. Several modifications such as leaf-2-leaf shortcuts and multiple level shortcuts are possible and described further in the document.
このドキュメントでは、「クローズ」と「脂肪ツリー」という用語を交換可能に使用します。これは、常に折りたたまれた脊椎と葉トポロジを指し、おそらく複数の配信ポイント（ポッド）と1つまたは複数の布地（TOF）飛行機を指します。Leaf-2-Leafショートカットや複数のレベルのショートカットなどのいくつかの変更が可能であり、ドキュメントでさらに説明されています。
Crossbar:
クロスバー：
Physical arrangement of ports in a switching matrix without implying any further scheduling or buffering disciplines.
さらにスケジューリングやバッファリング分野を暗示せずに、スイッチングマトリックス内のポートの物理的配置。
Directed Acyclic Graph (DAG):
指示された非環式グラフ（DAG）：
A finite directed graph with no directed cycles (loops). If links in a Clos are considered as either being all directed towards the top or bottom, each of such two graphs is a DAG.
指示サイクル（ループ）のない有限指向グラフ。クローズのリンクがすべて上部または下部に向けられていると見なされる場合、そのような2つのグラフはそれぞれDAGです。
Disaggregation:
分解：
The process in which a node decides to advertise more specific prefixes southwards, either positively to attract the corresponding traffic or negatively to repel it. Disaggregation is performed to prevent traffic loss and suboptimal routing to the more specific prefixes.
ノードがより具体的な接頭辞を南に宣伝することを決定したプロセスは、対応するトラフィックを引き付けるか、それを撃退するために否定的に積極的に宣伝することを決定します。より具体的なプレフィックスへのトラフィックの損失と最適ではないルーティングを防ぐために、分解が実行されます。
Leaf:
葉：
A node without southbound adjacencies. Level 0 implies a leaf in RIFT, but a leaf does not have to be level 0.
南行きの隣接のないノード。レベル0は裂け目の葉を意味しますが、葉はレベル0である必要はありません。
LIE:
LIE:
This is an acronym for "Link Information Element" exchanged on all the system's links running RIFT to form _ThreeWay_ adjacencies and carry information used to perform RIFT Zero Touch Provisioning (ZTP) of levels.
これは、Riftを実行して_threeway_隣接を形成し、Rift Zero Touch Provisioning（ZTP）レベルの実行に使用される情報を作成するためにRiftを実行しているすべてのシステムのリンクで交換された「Link Information Element」の頭字語です。
South Reflection:
南リフレクション：
Often abbreviated just as "reflection", South Reflection defines a mechanism where South Node TIEs are "reflected" from the level south back up north to allow nodes in the same level without East-West links to be aware of each other's node Topology Information Elements (TIEs).
多くの場合、「反射」と同じように省略されているサウスリフレクションは、南ノードの結びつきが北に戻るレベルから「反射」され、東西リンクなしの同じレベルのノードが互いのノードトポロジ情報要素（TIE）を認識できるようにするメカニズムを定義します。
Spine:
脊椎：
Any nodes north of leaves and south of ToF nodes. Multiple layers of spines in a PoD are possible.
葉の北とTOFノードの南にあるノード。ポッド内の棘の複数の層が可能です。
TIE:
TIE:
This is an acronym for "Topology Information Element". TIEs are exchanged between RIFT nodes to describe parts of a network such as links and address prefixes. A TIE always has a direction and a type. North TIEs (sometimes abbreviated as N-TIEs) are used when dealing with TIEs in the northbound representation, and South-TIEs (sometimes abbreviated as S-TIEs) are used for the southbound equivalent. TIEs have different types, such as node and prefix TIEs.
これは、「トポロジ情報要素」の頭字語です。タイはリフトノード間で交換され、リンクやアドレスのプレフィックスなどのネットワークの一部を説明します。ネクタイには常に方向とタイプがあります。ノースタイ（場合によってはN-Tiesとして略されることもあります）は、北行きの表現の関係を扱うときに使用され、南=タイ（S-Tiesとして略されることもあります）が南行きの同等物に使用されます。ネクタイには、ノードやプレフィックスタイなど、さまざまなタイプがあります。
Clos [CLOS] topologies (commonly called a Fat Tree/network in modern IP fabric considerations as a similar term for the original definition of the term Fat Tree [FATTREE]) have gained prominence in today's networking, primarily as a result of the paradigm shift towards a centralized data-center-based architecture that delivers a majority of computation and storage services.
Clos [clos]トポロジー（一般に、最新のIPファブリックの考慮事項における脂肪ツリー/ネットワークと呼ばれ、脂肪ツリーという用語[Fattree]という用語の元の定義の同様の用語と同様の用語[ファットツリー]と呼ばれています）は、主に、計算およびストレージサービスの大部分を提供する集中データセンターベースのアーキテクチャへのパラダイムシフトの結果として、今日のネットワーキングで顕著になりました。
Current routing protocols were geared towards a network with an irregular topology with isotropic properties and a low degree of connectivity. When applied to Fat Tree topologies:
現在のルーティングプロトコルは、等方性特性と低い接続性を備えた不規則なトポロジを備えたネットワークに向けられていました。脂肪ツリートポロジーに適用される場合：
* They tend to need extensive configuration or provisioning during initialization and adding or removing nodes from the fabric.
* 彼らは、初期化中に広範な構成またはプロビジョニングが必要であり、ファブリックからノードを追加または削除する必要があります。
* For link-state routing protocols, all nodes including spine-and-leaf nodes learn the entire network topology and routing information, which is actually not needed on the leaf nodes during normal operation. They flood significant amounts of duplicate link-state information between spine-and-leaf nodes during topology updates and convergence events, requiring that additional CPU and link bandwidth be consumed. This may impact the stability and scalability of the fabric, make the fabric less reactive to failures, and prevent the use of cheaper hardware at the lower levels (i.e., spine-and-leaf nodes).
* リンク状態のルーティングプロトコルの場合、スパインアンドリーフノードを含むすべてのノードは、ネットワークトポロジとルーティング情報全体を学習します。これは、通常の動作中に葉のノードでは実際には必要ありません。彼らは、トポロジの更新中および収束イベント中に、脊椎と葉のノードの間の重複リンク状態情報のかなりの量を浸水させ、追加のCPUとリンク帯域幅を消費する必要があります。これは、ファブリックの安定性とスケーラビリティに影響を与え、生地の障害に対する反応性を低下させ、より低いレベル（すなわち、背骨と葉のノード）で安価なハードウェアを使用するのを防ぐ可能性があります。
Further content of this document assumes that the reader is familiar with the terms and concepts used in the Open Shortest Path First (OSPF) [RFC2328], OSPF for IPv6 [RFC5340], and Intermediate System to Intermediate System (IS-IS) [ISO10589-Second-Edition] link-state protocols. [RFC9692] outlines the requirements of routing in IP fabrics and RIFT protocol concepts.
このドキュメントのさらなる内容は、読者が最初のオープンパスファースト（OSPF）[RFC2328]、IPv6 [RFC5340]のOSPF、および中間システム（IS-IS）[ISO10589-Second-Edition]リンク状態プロトコルズへの中間システムで使用される用語と概念に精通していることを前提としています。[RFC9692]は、IPファブリックとRIFTプロトコルの概念でのルーティングの要件の概要を示しています。
RIFT is a dynamic routing protocol that is tailored for use in Clos, Fat Tree, and other anisotropic topologies. Therefore, a core property of RIFT is that its operation is sensitive to the structure of the fabric -- it is anisotropic. RIFT acts as a link-state protocol when "pointing north", advertising southward routes to northward peers (parents) through flooding and database synchronization. When "pointing south", RIFT operates hop-by-hop like a distance-vector protocol, typically advertising a fabric default route towards the ToF, aka superspine, to southward peers (children).
Riftは、Clos、Fat Tree、およびその他の異方性トポロジで使用するために調整された動的なルーティングプロトコルです。したがって、Riftの中核特性は、その動作がファブリックの構造に敏感であることです - それは異方性です。Riftは、「北を指す」ときにリンク状態のプロトコルとして機能し、洪水とデータベースの同期を通じて北向きのピア（親）への南向きのルートを宣伝します。「Pointing South」の場合、Riftは距離ベクトルプロトコルのようにホップバイホップを操作します。通常、ファブリックのデフォルトルートをTOF（別名SuperSpine）に向けて南向きのピア（子供）に宣伝します。
The fabric default is typically the default route as described in Section 6.3.8 ("Southbound Default Route Origination") of [RFC9692]. The ToF nodes may alternatively originate more specific prefixes (P') southbound instead of the default route. In such a scenario, all addresses carried within the RIFT domain must be contained within P', and it is possible for a leaf that acts as gateway to the Internet to advertise the default route instead.
ファブリックのデフォルトは、通常、[RFC9692]のセクション6.3.8（「南行きのデフォルトルートオリジネーション」）で説明されているデフォルトルートです。TOFノードは、デフォルトルートの代わりに、より特定の接頭辞（P '）を南に向かって発生する場合があります。このようなシナリオでは、RIFTドメイン内に運ばれるすべてのアドレスをP '内に含める必要があり、インターネットへのゲートウェイとして機能する葉が代わりにデフォルトのルートを宣伝することが可能です。
RIFT floods flat link-state information northbound only so that each level obtains the full topology of the levels that are south of it. That information is never flooded East-West or back south again, so a top tier node has a full set of prefixes from the Shortest Path First (SPF) calculation.
Rift Floods Flat Link-State Informationは北を北に向かっているため、各レベルがその南にあるレベルの完全なトポロジーを取得します。その情報は決して東西または南に戻ることはないので、最上部のパス最初の（SPF）計算からのプレフィックスの完全なセットがあります。
In the southbound direction, the protocol operates like a "fully summarizing, unidirectional" path-vector protocol or, rather, a distance-vector with implicit split horizon. Routing information, normally just the default route, propagates one hop south and is "re-advertised" by nodes at next lower level.
南方向には、プロトコルは「完全に要約された一方向性」パスベクトルプロトコルのように動作します。ルーティング情報は、通常はデフォルトルートであり、1つのホップを南に伝播し、次の下位レベルでノードによって「再承認されます」。
+---------------+ +----------------+
| ToF | | ToF | LEVEL 2
+ ++------+--+--+-+ ++-+--+----+-----+
| | | | | | | | | ^
+ | | | +-------------------------+ |
Distance- | +-------------------+ | | | | |
Vector | | | | | | | | +
South | | | | +--------+ | | | Link-State
+ | | | | | | | | Flooding
| | | +----------------+ | | | North
v | | | | | | | | +
++---+-+ +------+ +-+----+ ++----++ |
|SPINE | |SPINE | | SPINE| | SPINE| | LEVEL 1
+ ++----++ ++---+-+ +-+--+-+ ++----++ |
+ | | | | | | | | | ^ N
Distance- | +-------+ | | +--------+ | | | E
Vector | | | | | | | | | +------>
South | +-------+ | | | +------+ | | | |
+ | | | | | | | | | +
v ++--++ +-+-++ ++--++ ++--++ +
|LEAF| |LEAF| |LEAF| |LEAF| LEVEL 0
+----+ +----+ +----+ +----+
Figure 1: RIFT Overview
図1：リフトの概要
A spine node only has information necessary for its level, which is all destinations south of the node based on SPF calculation, the default route, and potentially disaggregated routes.
スパインノードには、そのレベルに必要な情報のみがあります。これは、SPF計算、デフォルトルート、および潜在的に分解されたルートに基づいて、すべてノードの南にある目的地です。
RIFT combines the advantages of both link-state and distance-vector protocols:
Riftは、リンク状態と距離ベクトルプロトコルの両方の利点を組み合わせています。
* Fastest possible convergence
* 可能な限り速い収束
* Automatic detection of topology
* トポロジの自動検出
* Minimal routes/information on Top-of-Rack (ToR) switches, aka leaf nodes
* ラックの上部（TOR）スイッチに関する最小ルート/情報、別名リーフノード
* High degree of ECMP
* 高度のECMP
* Fast decommissioning of nodes
* ノードの高速廃止措置
* Maximum propagation speed with flexible prefixes in an update
* アップデート内の柔軟なプレフィックスを備えた最大伝播速度
There are two types of link-state databases that are "north representation" North Topology Information Elements (N-TIEs) and "south representation" South Topology Information Elements (S-TIEs). The N-TIEs contain a link-state topology description of lower levels, and the S-TIEs simply carry default and disaggregated routes for the lower levels.
「北代表」の北トポロジ情報要素（n-ties）と「南代表」の南トポロジー情報要素（S-ties）であるリンク状態データベースには2つのタイプがあります。N-Tiesには、低レベルのリンク状態トポロジの説明が含まれており、S-Tiesは単に低レベルのデフォルトおよび分解ルートを運ぶだけです。
RIFT also eliminates major disadvantages of link-state and distance-vector protocols with the following:
また、Riftは、リンク状態と距離ベクトルプロトコルの主要な欠点を次のもので排除します。
* Reduced and balanced flooding
* 洪水の削減とバランスの取れた洪水
* Level-constrained automatic neighbor discovery
* レベルに制約のある自動隣人発見
To achieve this, RIFT builds on the art of IGPs, such as OSPF, IS-IS, Mobile Ad Hoc Network (MANET), and Internet of Things (IoT) to provide unique features:
これを達成するために、Riftは、OSPF、IS-IS、モバイルアドホックネットワーク（MANET）、モノのインターネット（IoT）などのIGPの技術に基づいて構築され、ユニークな機能を提供します。
* Automatic (positive or negative) route disaggregation of northward routes upon fallen leaves
* 倒れた葉の北向きルートの自動（正または負の）ルート分解
* Recursive operation in the case of negative route disaggregation
* 負のルート分解の場合の再帰操作
* Anisotropic routing that extends a principle seen in the Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] to wide superspines
* 低電力および喪失ネットワーク（RPL）[RFC6550]のルーティングプロトコルで見られる原理を広いスーパーパインに拡張する異方性ルーティング
* Optimal flooding reduction that derives from the concept of a "multipoint relay" (MPR) found in Optimized Link State Routing (OLSR) [RFC3626] and balances the flooding load over northbound links and nodes
* 最適化されたリンク状態ルーティング（OLSR）[RFC3626]で見つかった「マルチポイントリレー」（MPR）の概念に由来する最適な洪水削減を行い、北行きのリンクとノードの洪水荷重のバランスをとります。
Additional advantages that are unique to RIFT are listed below. The details of these advantages can be found in RIFT [RFC9692].
Riftに固有の追加の利点を以下に示します。これらの利点の詳細は、Rift [RFC9692]にあります。
* True ZTP
* 真のZTP
* Minimal blast radius on failures
* 障害に対する最小限の爆風半径
* Can utilize all paths through fabric without looping
* ループなしで生地を通してすべてのパスを利用できます
* Simple leaf implementation that can scale down to servers
* サーバーに縮小できるシンプルな葉の実装
* Key-value store
* キー価値ストア
* Horizontal links used for protection only
* 保護のみに使用される水平リンク
Albeit RIFT is specified primarily for "proper" Clos or Fat Tree topologies, the protocol natively supports Points of Delivery (PoD) concepts, which, strictly speaking, are not found in the original Clos concept.
Riftは主に「適切な」クローズまたはファットツリートポロジ向けに指定されていますが、プロトコルは、厳密に言えば、元のクローズコンセプトには見られない、配信ポイント（POD）の概念をネイティブにサポートしています。
Further, the specification explains and supports operations of multi-plane Clos variants where the protocol recommends the use of inter-plane rings at the ToF level to allow the reconciliation of topology view of different planes to make the Negative Disaggregation viable in case of failures within a plane. These observations hold not only in case of RIFT but also in the generic case of dynamic routing on Clos variants with multiple planes and failures in bisectional bandwidth, especially on the leaves.
さらに、この仕様は、プロトコルがTOFレベルで面間リングの使用を推奨して、異なる平面のトポロジービューの調整を、平面内の障害の場合に負の分解を実行可能にすることを可能にするマルチプレーンクローズバリアントの操作を説明およびサポートします。これらの観察結果は、Riftの場合だけでなく、複数の平面と二分詞帯域幅の故障を伴う極端なバリアントの動的ルーティングの一般的なケースでも、特に葉にも当てはまります。
RIFT is not limited to pure Clos divided into PoD and multi-planes but supports horizontal (East-West) links below the ToF level. Those links are used only for last resort northbound forwarding when a spine loses all its northbound links or cannot compute a default route through them.
Riftは、ポッドとマルチプレーンに分割された純粋な純度に限定されませんが、TOFレベル以下の水平（東西）リンクをサポートします。これらのリンクは、背骨がすべての北行きのリンクを失うか、それらを介してデフォルトルートを計算できない場合の最後の手段の北行きの転送にのみ使用されます。
A full-mesh connectivity between nodes on the same level can be deployed, which allows North SPF (N-SPF) to provide for any node losing all its northbound adjacencies (as long as any of the other nodes in the level are northbound connected) and still participate in northbound forwarding.
同じレベルのノード間のフルメッシュ接続を展開することができます。これにより、North SPF（N-SPF）は、ノードがすべての北に隣接するすべての隣接を失うことを可能にします（レベルの他のノードのいずれかが北に接続されている限り）。
Note that a "ring" of horizontal links at any level below ToF does not provide a "ring-based protection" scheme since the SPF computation would have to deal with breaking of "loops", an application for which RIFT is not intended.
TOF以下の任意のレベルでの水平リンクの「リング」は、SPF計算がRiftが意図していないアプリケーションである「ループ」の破壊に対処する必要があるため、「リングベースの保護」スキームを提供しないことに注意してください。
Through relaxations of the specified adjacency forming rules, RIFT implementations can be extended to support vertical "shortcuts". The RIFT specification itself does not provide the exact details since the resulting solution suffers from either a much larger blast radius with increased flooding volumes or bow tie problems in the case of maximum aggregation routing.
指定された隣接形成ルールの緩和を通じて、垂直の「ショートカット」をサポートするためにRIFT実装を拡張できます。Rift仕様自体は、結果として得られるソリューションは、最大集約ルーティングの場合に洪水量が増加するか、洪水量が増加するか、蝶ネクタイの問題を伴うはるかに大きな爆風半径に苦しむため、正確な詳細を提供しません。
RIFT is an anisotropic routing protocol, meaning that it has a sense of direction (northbound, southbound, and East-West) and operates differently depending on the direction.
Riftは異方性ルーティングプロトコルです。つまり、方向感覚（北行き、南行き、東西）があり、方向に応じて異なる動作をします。
Since a DAG provides a sense of north (the direction of the DAG) and south (the reverse), it can be used to apply RIFT -- an edge in the DAG that has only incoming vertices is a ToF node.
DAGは北の感覚（DAGの方向）と南（逆）を提供するため、Riftを適用するために使用できます。DAGのエッジのみがTOFノードです。
There are a number of caveats though:
しかし、多くの警告があります：
* The DAG structure must exist before RIFT starts, so there is a need for a companion protocol to establish the logical DAG structure.
* Riftが始まる前にDAG構造が存在する必要があるため、論理DAG構造を確立するためのコンパニオンプロトコルが必要です。
* A generic DAG does not have a sense of East and West. The operation specified for East-West links and the southbound reflection between nodes are not applicable. Also, ZTP will derive a sense of depth that will eliminate some links. Variations of ZTP could be derived to meet specific objectives, e.g., make it so that most routers have at least two parents to reach the ToF.
* 一般的なDAGには、東と西の感覚がありません。東西リンクに指定された操作とノード間の南行きの反射は適用されません。また、ZTPは、いくつかのリンクを排除する深さの感覚を導き出します。ZTPのバリエーションは、特定の目的を満たすために導き出すことができます。たとえば、ほとんどのルーターに少なくとも2人の親がTOFに到達するようにします。
* RIFT applies to any Destination-Oriented DAG (DODAG) where there's only one ToF node and the problem of disaggregation does not exist. In that case, RIFT operates very much like RPL [RFC6550], but uses link-state information for southbound routes (downwards in RPL's terms). For an arbitrary DAG with multiple destinations (ToFs), the way disaggregation happens has to be considered.
* Riftは、TOFノードが1つしかなく、分解の問題が存在しない任意の目的地指向DAG（DODAG）に適用されます。その場合、RiftはRPL [RFC6550]と非常によく似ていますが、南行きルートにリンク状態情報を使用します（RPLの用語では下向き）。複数の目的地（TOFS）を備えた任意のDAGの場合、分解が起こる方法を考慮する必要があります。
* Positive Disaggregation expects that most of the ToF nodes reach most of the leaves, so disaggregation is the exception as opposed to the rule. When this is no longer true, it makes sense to turn off disaggregation and route between the ToF nodes over a ring, a full mesh, a transit network, or a form of area zero. Then again, this operation is similar to RPL operating as a single DODAG with a virtual root.
* 肯定的な分解は、ほとんどのTOFノードがほとんどの葉に到達することを期待しているため、ルールとは対照的に、分解が例外です。これがもはや真でない場合、リング、フルメッシュ、トランジットネットワーク、またはエリアゼロの形式を越えて、TOFノード間の分解とルーティングをオフにすることは理にかなっています。繰り返しになりますが、この操作は、仮想ルートを備えた単一のドーダグとして動作するRPLに似ています。
* In order to aggregate and disaggregate routes, RIFT requires that all the ToF nodes share the full knowledge of the prefixes in the fabric. This can be achieved with a ring as suggested by RIFT [RFC9692], by some preconfiguration, or by using a synchronization with a common repository where all the active prefixes are registered.
* ルートを集約して分解するために、Riftでは、すべてのTOFノードがファブリックス内の接頭辞の完全な知識を共有する必要があります。これは、Rift [RFC9692]、ある程度の事前設定、またはすべてのアクティブなプレフィックスが登録されている共通リポジトリとの同期を使用して、リングで実現できます。
RIFT does not require that nodes have reachable addresses in the fabric, though it is clearly desirable for operational purposes. Under normal operating conditions, this can be easily achieved by injecting the node's loopback address into Prefix North TIEs and Prefix South TIEs or other implementation-specific mechanisms.
Riftは、ノードがファブリックに到達可能なアドレスを持つことを必要としませんが、運用目的では明らかに望ましいものです。通常の動作条件下では、これはノードのループバックアドレスを接頭辞の北タイと接頭辞の南タイまたはその他の実装固有のメカニズムに注入することで簡単に実現できます。
Special considerations arise when a node loses all northbound adjacencies but is not at the top of the fabric. If a spine node loses all northbound links, the spine node doesn't advertise a default route. But if the level of the spine node is auto-determined by ZTP, it will "fall down" as depicted in Figure 8.
ノードがすべての北行きの隣接を失うが、ファブリックの上部にない場合、特別な考慮事項が生じます。スパインノードがすべてのノースバウンドリンクを失った場合、スパインノードはデフォルトのルートを宣伝しません。しかし、脊椎ノードのレベルがZTPによって自動決定されている場合、図8に示すように「落ちる」。
RIFT is suited for applying underlay routing in data center (DC) IP fabrics, with the vast majority of these IP fabrics being Clos architectures (and will be for the foreseeable future). It significantly simplifies operation and deployment of such fabrics as described in Section 5 for environments compared to extensive proprietary provisioning and operational solutions.
Riftは、データセンター（DC）IPファブリックのアンダーレイルーティングを適用するのに適しており、これらのIPファブリックの大部分はクローズアーキテクチャです（予見可能な将来のためです）。広範なプロビジョニングおよび運用ソリューションと比較して、環境のセクション5で説明されているようなファブリックの操作と展開を大幅に簡素化します。
. +-----+ +-----+
. | | | |
.+-+ S0 | | S1 |
.| ++---++ ++---++
.| | | | |
.| | +------------+ |
.| | | +------------+ |
.| | | | |
.| ++-+--+ +--+-++
.| | | | |
.| | A0 | | A1 |
.| +-+--++ ++---++
.| | | | |
.| | +------------+ |
.| | +-----------+ | |
.| | | | |
.| +-+-+-+ +--+-++
.+-+ | | |
. | L0 | | L1 |
. +-----+ +-----+
Figure 2: Level Shortcut
図2：レベルショートカット
RIFT is not strictly limited to Clos topologies. The protocol only requires a sense of "compass rose directionality" either achieved through configuration or derivation of levels. So conceptually, shortcuts between levels could be included. Figure 2 depicts an example of a shortcut between levels. In this example, suboptimal routing will occur when traffic is sent from L0 to L1 via S0's default route and back down through A0 or A1. In order to avoid that, only default routes from A0 or A1 are used. All leaves would be required to install each other's routes.
Riftは、クローズトポロジーに厳密に限定されていません。プロトコルには、構成またはレベルの導出によって達成される「コンパスローズ方向性」の感覚のみが必要です。したがって、概念的には、レベル間のショートカットを含めることができました。図2は、レベル間のショートカットの例を示しています。この例では、S0のデフォルトルートを介してL0からL1にトラフィックが送信され、A0またはA1を介して戻ると、最適ではないルーティングが発生します。それを回避するために、A0またはA1からのデフォルトルートのみが使用されます。お互いのルートを設置するには、すべての葉が必要です。
While various technical and operational challenges may require the use of such modifications, discussion of those topics is outside the scope of this document.
さまざまな技術的および運用上の課題には、このような変更の使用が必要になる場合がありますが、これらのトピックの議論はこのドキュメントの範囲外です。
The demand for bandwidth is increasing steadily, driven primarily by environments close to content producers (server farms connection via DC fabrics) but in proximity to content consumers as well. Consumers are often clustered in metro areas with their own network architectures that can benefit from simplified, regular Clos structures. Thus, they can also benefit from RIFT.
帯域幅の需要は着実に増加しており、主にコンテンツプロデューサー（DCファブリックを介したサーバーファーム接続）に近い環境によって駆動されますが、コンテンツ消費者にも近接しています。消費者は、多くの場合、単純化された定期的な閉鎖構造から利益を得ることができる独自のネットワークアーキテクチャを備えたメトロエリアでクラスター化されています。したがって、それらはリフトからも恩恵を受けることができます。
Commercial edifices are often cabled in topologies that are either Clos or its isomorphic equivalents. The Clos can grow rather high with many levels. That presents a challenge for classical routing protocols (except BGP [RFC4271] and Private Network-Network Interface (PNNI) [PNNI], which is largely phased-out by now) that do not support an arbitrary number of levels, which RIFT does naturally. Moreover, due to the limited sizes of forwarding tables in network elements of building cabling, the minimum FIB size RIFT maintains under normal conditions is cost-effective in terms of hardware and operational costs.
商業建築物は、多くの場合、近接またはその同型相当のいずれかのトポロジーでケーブルされています。クローズは、多くのレベルでかなり高くなる可能性があります。これは、古典的なルーティングプロトコル（BGP [RFC4271]とプライベートネットワークネットワークインターフェイス（PNNI）[PNNI]を除く課題を提示します。さらに、ビルディングケーブルのネットワーク要素の転送テーブルが限られているため、通常の条件下で最小FIBサイズのリフトが維持されるため、ハードウェアと運用コストの点で費用対効果が高くなります。
It is common in high-speed communications switching and routing devices to use switch fabrics that are interconnection networks inside the devices connecting the input ports to their output ports. For example, a crossbar is one of the switch fabric techniques, even though it is not feasible due to cost, head-of-line blocking, or size trade-offs. Normally, such fabrics are not self-healing or rely on 1:1 or 1+1 protection schemes, but it is conceivable to use RIFT to operate Clos fabrics that can deal effectively with interconnections or subsystem failures in such a module. RIFT is not IP specific and hence any link addressing connecting internal device subnets is conceivable.
高速通信スイッチングおよびルーティングデバイスでは、入力ポートを出力ポートに接続するデバイス内の相互接続ネットワークであるスイッチファブリックを使用することが一般的です。たとえば、クロスバーは、コスト、頭のブロック、またはサイズのトレードオフのために実行不可能ですが、スイッチファブリックのテクニックの1つです。通常、そのような生地は自己修正ではなく、1：1または1+1の保護スキームに依存していませんが、Riftを使用して、そのようなモジュールの相互接続またはサブシステム障害を効果的に扱うことができるクローズファブリックを操作することが考えられます。RiftはIP固有ではないため、接続する内部デバイスサブネットに対処するリンクは考えられます。
The Cloud Central Office (CloudCO) is a new stage of the telecom Central Office. It takes the advantage of Software-Defined Networking (SDN) and Network Function Virtualization (NFV) in conjunction with general purpose hardware to optimize current networks. The following figure illustrates this architecture at a high level. It describes a single instance or macro-node of CloudCO that provides a number of value-added services (VASes), a Broadband Access Abstraction (BAA), and virtualized network services. An Access I/O module faces a CloudCO access node and the Customer Premises Equipment (CPE) behind it. A Network I/O module is facing the core network. The two I/O modules are interconnected by a spine-and-leaf fabric [TR-384].
Cloud Central Office（Cloudco）は、Telecom Central Officeの新しいステージです。ソフトウェア定義のネットワーク（SDN）とネットワーク関数仮想化（NFV）を汎用ハードウェアと組み合わせて、現在のネットワークを最適化します。次の図は、このアーキテクチャを高レベルで示しています。多くの付加価値サービス（Vase）、ブロードバンドアクセス抽象化（BAA）、および仮想化ネットワークサービスを提供するCloudcoの単一のインスタンスまたはマクロノードについて説明します。アクセスI/Oモジュールは、CloudCoアクセスノードとその背後にある顧客前提機器（CPE）に面しています。ネットワークI/Oモジュールがコアネットワークに直面しています。2つのI/Oモジュールは、脊椎と葉の生地によって相互接続されています[TR-384]。
+---------------------+ +----------------------+
| Spine | | Spine |
| Switch | | Switch |
+------+---+------+-+-+ +--+-+-+-+-----+-------+
| | | | | | | | | | | |
| | | | | +-------------------------------+ |
| | | | | | | | | | | |
| | | | +-------------------------+ | | |
| | | | | | | | | | | |
| | +----------------------+ | | | | | | | |
| | | | | | | | | | | |
| +---------------------------------+ | | | | | | |
| | | | | | | | | | | |
| | | +-----------------------------+ | | | | |
| | | | | | | | | | | |
| | | | | +--------------------+ | | | |
| | | | | | | | | | | |
+--+ +-+---+--+ +-+---+--+ +--+----+--+ +-+--+--+ +--+
|L | | Leaf | | Leaf | | Leaf | | Leaf | |L |
|S | | Switch | | Switch | | Switch | | Switch| |S |
++-+ +-+-+-+--+ +-+-+-+--+ +--+-+--+--+ ++-+--+-+ +-++
| | | | | | | | | | | | | |
| +-+-+-+--+ +-+-+-+--+ +--+-+--+--+ ++-+--+-+ |
| |Compute | |Compute | | Compute | |Compute| |
| |Node | |Node | | Node | |Node | |
| +--------+ +--------+ +----------+ +-------+ |
| || VAS5 || || vDHCP|| || vRouter|| ||VAS1 || |
| |--------| |--------| |----------| |-------| |
| |--------| |--------| |----------| |-------| |
| || VAS6 || || VAS3 || || v802.1x|| ||VAS2 || |
| |--------| |--------| |----------| |-------| |
| |--------| |--------| |----------| |-------| |
| || VAS7 || || VAS4 || || vIGMP || ||BAA || |
| |--------| |--------| |----------| |-------| |
| +--------+ +--------+ +----------+ +-------+ |
| |
++-----------+ +---------++
|Network I/O | |Access I/O|
+------------+ +----------+
Figure 3: CloudCO Architecture Example
図3：Cloudcoアーキテクチャの例
The Spine-Leaf architecture deployed inside CloudCO meets the network requirements of being adaptable, agile, scalable, and dynamic.
Cloudco内に展開されている背骨葉アーキテクチャは、適応性があり、アジャイルで、スケーラブルで、動的であるというネットワーク要件を満たしています。
RIFT presents the features for organizations building and operating IP fabrics to simplify the operation and deployments while achieving many desirable properties of a dynamic routing protocol on such a substrate:
Riftは、IPファブリックを構築および運用する組織の機能を提示し、そのような基板上の動的ルーティングプロトコルの多くの望ましいプロパティを実現しながら、操作と展開を簡素化します。
* RIFT only floods routing information to the devices that need it.
* Riftは、それを必要とするデバイスへのルーティング情報のみをフラッシュします。
* RIFT allows for ZTP within the protocol. In its most extreme version, RIFT does not rely on any specific addressing and can operate using IPv6 Neighbor Discovery (ND) [RFC4861] only for IP fabric.
* Riftは、プロトコル内のZTPを許可します。最も極端なバージョンでは、Riftは特定のアドレス指定に依存せず、IPファブリックのみでIPv6 Neighbor Discovery（ND）[RFC4861]を使用して動作できます。
* RIFT has provisions to detect common IP fabric miscabling scenarios.
* Riftには、一般的なIPファブリックの容疑者シナリオを検出する規定があります。
* RIFT automatically negotiates Bidirectional Forwarding Detection (BFD) per link. This allows for IP and micro-BFD [RFC7130] to replace Link Aggregation Groups (LAGs) that hide bandwidth imbalances in case of constituent failures. Further automatic link validation techniques similar to those in [RFC5357] could be supported as well.
* Riftは、リンクごとに双方向転送検出（BFD）を自動的に交渉します。これにより、IPおよびMicro-BFD [RFC7130]が、構成障害の場合に帯域幅の不均衡を隠すリンク集約グループ（LAG）を置き換えることができます。[RFC5357]のものと同様のさらなる自動リンク検証手法もサポートできます。
* RIFT inherently solves many problems associated with the use of classical routing topologies with dense meshes and high degrees of ECMP by including automatic bandwidth balancing, flood reduction, and automatic disaggregation on failures while providing maximum aggregation of prefixes in default scenarios. ECMP in RIFT eliminates the need for more Loop-Free Alternate (LFA) procedures.
* Riftは本質的に、自動帯域幅のバランス、洪水削減、および障害に関する自動分解を含めることにより、密なメッシュと高度のECMPを備えた古典的なルーティングトポロジの使用に関連する多くの問題を本質的に解決し、デフォルトのシナリオでプレフィックスの最大集約を提供します。RIFTのECMPは、よりループフリーの代替（LFA）手順の必要性を排除します。
* RIFT reduces FIB size towards the bottom of the IP fabric where most nodes reside. This allows for cheaper hardware on the edges and introduction of modern IP fabric architectures that encompass server multihoming and other mechanisms.
* Riftは、ほとんどのノードが存在するIPファブリックの底に向かってFIBサイズを減らします。これにより、エッジ上のより安価なハードウェアが可能になり、サーバーのマルチホームやその他のメカニズムを含む最新のIPファブリックアーキテクチャの導入が可能になります。
* RIFT provides valley-free routing that is loop free. A valley-free path allows for reversal of direction at most once from a packet heading northbound to southbound while permitting traversal of horizontal links in the northbound phase. This allows for the use of any such valley-free path in bisectional fabric bandwidth between two destinations irrespective of their metrics that can be used to balance load on the fabric in different ways. Valley-free routing eliminates the need for any specific micro-loop avoidance procedures for RIFT.
* Riftは、ループフリーのバレーフリールーティングを提供します。谷間のないパスは、北に向かって北に向かうパケットから南行きに向かうパケットから最大1回方向の反転を可能にしながら、北行きの位相で水平リンクの横断を許可します。これにより、さまざまな方法で生地の負荷のバランスをとるために使用できるメトリックに関係なく、2つの目的地の間の二等式ファブリック帯域幅にそのような谷間のないパスを使用できます。谷間のないルーティングは、リフトのための特定のマイクロループ回避手順の必要性を排除します。
* RIFT includes a key-value distribution mechanism that allows for future applications such as automatic provisioning of basic overlay services or automatic key rollovers over whole fabrics.
* Riftには、基本的なオーバーレイサービスの自動プロビジョニングや、ファブリック全体にわたる自動キーロールオーバーなどの将来のアプリケーションを可能にするキー価値分布メカニズムが含まれています。
* RIFT is designed for minimum delay in case of prefix mobility on the fabric. In conjunction with [RFC8505], RIFT can differentiate anycast advertisements from mobility events and retain only the most recent advertisement in the latter case.
* Riftは、ファブリックのプレフィックスモビリティの場合、最小の遅延のために設計されています。[RFC8505]と併せて、RiftはAnyCastの広告をモビリティイベントと区別し、後者の場合の最新の広告のみを保持することができます。
* Many further operational and design points collected over many years of routing protocol deployments have been incorporated in RIFT such as fast flooding rates, protection of information lifetimes, and operationally recognizable remote ends of links and node names.
* 長年のルーティングプロトコル展開にわたって収集されたさらに多くの運用および設計ポイントは、高速洪水速度、情報の保護の寿命の保護、リンクとノード名の運用上認識可能なリモートエンドなど、リフトに組み込まれています。
South reflection is a mechanism where South Node TIEs are "reflected" back up north to allow nodes in the same level without East-West links to "see" each other.
サウスリフレクションは、南ノードの結びつきが北に「反射」され、同じレベルのノードが互いを「見る」ことなくノードを許可するメカニズムです。
For example, in Figure 4, Spine111\Spine112\Spine121\Spine122 reflects Node S-TIEs from ToF21 to ToF22 separately. Respectively, Spine111\Spine112\Spine121\Spine122 reflects Node S-TIEs from ToF22 to ToF21 separately, so ToF22 and ToF21 see each other's node information as level 2 nodes.
たとえば、図4では、SPINE111 \ SPINE112 \ SPINE121 \ SPINE122は、TOF21からTOF22へのノードS-TIEを個別に反映しています。それぞれ、Spine111 \ Spine112 \ Spine121 \ Spine122は、TOF22からTOF21へのノードS-TIESを個別に反映しているため、TOF22とTOF21はレベル2ノードとして互いのノード情報を表示します。
In an equivalent fashion, as the result of the south reflection between Spine121-Leaf121-Spine122 and Spine121-Leaf122-Spine122, Spine121 and Spine 122 know each other at level 1.
同等の方法では、脊椎1121-leaf121-spine122と脊椎1122-spine122の間の南反射の結果として、脊椎122と脊椎122はレベル1で互いに知り合っています。
+--------+ +--------+
| ToF21 | | ToF22 | LEVEL 2
++--+-+-++ ++-+--+-++
| | | | | | | +
| | | | | | | linkTS8
+------------+ | +-+linkTS3+-+ | | | +-------------+
| | | | | | + |
| +---------------------------+ | linkTS7 |
| | | | + + + |
| | | +-------+linkTS4+------------+ |
| | | + + | | |
| | | +-------------+--+ | |
| | | | | linkTS6 | |
+-+----+-+ +-+----+-+ ++--------+ +-+----+-+
|Spine111| |Spine112| |Spine121 | |Spine122| LEVEL 1
+-+---+--+ +-+----+-+ +-+---+---+ +-+----+-+
| | | | | | | |
| +-------------+ | + ++XX+linkSL6+---+ +
| | | | linkSL5 | | linkSL8
| +-----------+ | | + +---+linkSL7+-+ | +
| | | | | | | |
+-+---+-+ +--+--+-+ +-+---+-+ +--+--+-+
|Leaf111| |Leaf112| |Leaf121| |Leaf122| LEVEL 0
+-+-----+ +-+-----+ +-----+-+ +-+-----+
+ + + +
Prefix111 Prefix112 Prefix121 Prefix122
Figure 4: Suboptimal Routing Upon Link Failure Use Case
図4：リンク障害ユースケースに対する最適下ルーティング
As shown in Figure 4, as the result of the south reflection, Spine121 and Spine 122 know each other via Leaf121 or Leaf 122 at level 1.
図4に示すように、南反射の結果として、脊椎121と脊椎122は、Leaf121またはLeaf 122をレベル1で互いに知っています。
Without disaggregation mechanisms, the packet from leaf121 to prefix122 will probably go up through linkSL5 to linkTS3 when linkSL6 fails. Then, the packet will go down through linkTS4 to linkSL8 to Leaf122 or go up through linkSL5 to linkTS6, then go down through linkTS8 and linkSL8 to Leaf122 based on the pure default route. This is the case of suboptimal routing or bow tying.
分解メカニズムがなければ、leaf121からprefix122へのパケットは、linksl6が失敗したときにlinksl5を介してlinkts3に上がります。次に、パケットはlinkts4を介してLinksl8にleaf122にダウンするか、linksl5をlinkts6に上がってから、純粋なデフォルトルートに基づいてlinkts8とlinksl8を介してleaf122に下ります。これは、最適ではないルーティングまたは弓を結ぶ場合です。
With disaggregation mechanisms, Spine122 will detect the failure according to the reflected node S-TIE from Spine121 when linkSL6 fails. Based on the disaggregation algorithm provided by RIFT, Spine122 will explicitly advertise prefix122 in Disaggregated Prefix S-TIE PrefixTIEElement(prefix122, cost 1). The packet from leaf121 to prefix122 will only be sent to linkSL7 following a longest-prefix match to prefix 122 directly, then it will go down through linkSL8 to Leaf122.
分解メカニズムを使用すると、SPINE122は、Linksl6が失敗したときにSPINE121の反射ノードS-TIEに従って障害を検出します。Riftによって提供される分解アルゴリズムに基づいて、Spine122は、分解されたプレフィックスS-TYPREIXTIEELEMENT（Prefix122、コスト1）でPrefix122を明示的に宣伝します。leaf121からprefix122へのパケットは、最長のプレフィックス一致に続いてlinksl7にのみ送信されます122は直接プレフィックス122になり、linksl8を介してleaf122にダウンします。
+--------+ +--------+
| ToF 21 | | ToF 22 | LEVEL 2
++-+--+-++ ++-+--+-++
| | | | | | | +
| | | | | | | linkTS8
+--------------+ | +-+linkTS3+X+ | | | +--------------+
linkTS1 | | | | | + |
+ +-----------------------------+ | linkTS7 |
| | + | + + + |
| | linkTS2 +-------+linkTS4+X+----------+ |
| + + + + | | |
| linkTS5 +-+ +------------+--+ | |
| + | | | linkTS6 | |
+-+----+-+ +-+----+-+ ++-------+ +-+-----++
|Spine111| |Spine112| |Spine121| |Spine122| LEVEL 1
+-+---+--+ ++----+--+ +-+---+--+ +-+----+-+
| | | | | | | |
+ +---------------+ | + +---+linkSL6+---+ +
linkSL1 | | | linkSL5 | | linkSL8
+ +--+linkSL3+--+ | | + +---+linkSL7+-+ | +
| | | | | | | |
+-+---+-+ +--+--+-+ +-+---+-+ +--+--+-+
|Leaf111| |Leaf112| |Leaf121| |Leaf122| LEVEL 0
+-+-----+ +-+-----+ +-----+-+ +-----+-+
+ + + +
Prefix111 Prefix112 Prefix121 Prefix122
Figure 5: Black-Holing Upon Link Failure Use Case
図5：リンク障害ユースケースのブラックホーリング
This scenario illustrates a case where double link failure occurs and black-holing can happen.
このシナリオは、二重リンクの故障が発生し、ブラックホーリングが発生する可能性のあるケースを示しています。
Without disaggregation mechanisms, the packet from leaf111 to prefix122 would suffer 50% black-holing based on pure default route when linkTS3 and linkTS4 both fail. The packet is supposed to go up through linkSL1 to linkTS1 and then go down through linkTS3 or linkTS4 will be dropped. The packet is supposed to go up through linkSL3 to linkTS2, then go down through linkTS3 or linkTS4 will be dropped as well. This is the case of black-holing.
分解メカニズムがなければ、leaf111からprefix122へのパケットは、linkts3とlinkts4の両方が故障した場合、純粋なデフォルトルートに基づいて50％のブラックホーリングを受けます。パケットはLinksl1を介してlinkts1に上がってから、linkts3を介して下降するか、linkts4がドロップされることになっています。パケットはlinksl3を介してlinkts2に上がり、linkts3を介して下降するか、linkts4もドロップされます。これはブラックホーリングの場合です。
With disaggregation mechanisms, ToF22 will detect the failure according to the reflected node S-TIE of ToF21 from Spine111\Spine112 when linkTS3 and linkTS4 both fail. Based on the disaggregation algorithm provided by RIFT, ToF22 will explicitly originate an S-TIE with prefix 121 and prefix 122 that is flooded to spines 111, 112, 121, and 122.
分解メカニズムを使用すると、TOF22は、Linkts3とLinkts4の両方が失敗すると、Spine111 \ Spine112のToF21の反射ノードS-Tieに従って障害を検出します。RIFTによって提供される分解アルゴリズムに基づいて、TOF22は、スパイン111、112、121、および122に浸水した接頭辞121および接頭辞122でS-TIEを明示的に発生します。
The packet from leaf111 to prefix122 will not be routed to linkTS1 or linkTS2. The packet from leaf111 to prefix122 will only be routed to linkTS5 or linkTS7 following a longest-prefix match to prefix122.
leaf111からprefix122へのパケットは、linkts1またはlinkts2にルーティングされません。leaf111からprefix122へのパケットは、prefix122に最長のプレフィックスマッチに続いて、linkts5またはlinkts7にのみルーティングされます。
RIFT is designed to require a very minimal configuration to simplify its operation and avoid human errors; based on that minimal information, ZTP auto configures the key operational parameters of all the RIFT nodes, including the System ID of the node that must be unique in the RIFT network and the level of the node in the Fat Tree, which determines which peers are northward "parents" and which are southward "children".
Riftは、操作を簡素化し、ヒューマンエラーを回避するために、非常に最小限の構成を必要とするように設計されています。その最小限の情報に基づいて、ZTP Autoは、リフトネットワークで一意でなければならないノードのシステムIDと、どのピアが北にある「親」であり、南に「子供」であるかを決定する脂肪ツリーのノードのレベルを含む、すべてのリフトノードの主要な動作パラメーターを構成します。
ZTP is always on, but its decisions can be overridden when a network administrator prefers to impose its own configuration. In that case, it is the responsibility of the administrator to ensure that the configured parameters are correct, i.e., ensure that the System ID of each node is unique and that the administratively set levels truly reflect the relative position of the nodes in the fabric. It is recommended to let ZTP configure the network, and when ZTP does not configure the network, it is recommended to configure the level of all the nodes to avoid an undesirable interaction between ZTP and the manual configuration.
ZTPは常にオンになっていますが、ネットワーク管理者が独自の構成を課すことを好む場合、その決定は無効にすることができます。その場合、構成されたパラメーターが正しいことを確認することは、管理者の責任です。つまり、各ノードのシステムIDが一意であり、管理的に設定されたレベルがファブリックのノードの相対的な位置を真に反映していることを確認します。ZTPをネットワークを構成させることをお勧めします。ZTPがネットワークを構成しない場合は、ZTPと手動構成の間の望ましくない相互作用を回避するために、すべてのノードのレベルを構成することをお勧めします。
ZTP requires that the administrator points out the ToF nodes to set the baseline from which the fabric topology is derived. The ToF nodes are configured with the TOP_OF_FABRIC flag, which are initial 'seeds' needed for other ZTP nodes to derive their level in the topology. ZTP computes the level of each node based on the Highest Available Level (HAL) of the potential parent closest to that baseline, which represents the superspine. In a fashion, RIFT can be seen as a distance-vector protocol that computes a set of feasible successors towards the superspine and autoconfigures the rest of the topology.
ZTPは、管理者がTOFノードを指摘して、ファブリックトポロジが導出されるベースラインを設定することを要求します。TOFノードは、TOP_OF_FABRICフラグで構成されており、他のZTPノードがトポロジのレベルを導出するために必要な初期「シード」です。ZTPは、そのベースラインに最も近い潜在的な親の利用可能な最高レベル（HAL）に基づいて各ノードのレベルを計算します。簡単に言えば、Riftは、スーパースパインに向かって実行可能な後継者のセットを計算し、トポロジの残りの部分を自動確認する距離ベクトルプロトコルと見なすことができます。
The autoconfiguration mechanism computes a global maximum of levels by diffusion. The derivation of the level of each node happens then based on LIEs received from its neighbors, whereas each node (with possible exceptions of configured leaves) tries to attach at the highest possible point in the fabric. This guarantees that even if the diffusion front reaches a node from "below" faster than from "above", it will greedily abandon already negotiated levels derived from nodes topologically below it and properly peer with nodes above.
Autoconfigurationメカニズムは、拡散によりグローバルな最大レベルを計算します。各ノードのレベルの導出は、近隣から受け取った嘘に基づいて発生しますが、各ノード（構成された葉を除いて可能な限り）は、ファブリックの可能な限り最高のポイントで取り付けようとします。これにより、拡散フロントが「上から「上から」よりも速く「下」からノードに到達したとしても、その下のノードから派生した既に交渉されたレベルを貪欲に放棄し、上記のノードで適切にピアを貪欲に放棄します。
The achieved equilibrium can be disturbed massively by all nodes with the highest level either leaving or entering the domain (with some finer distinctions not explained further). It is therefore recommended that each node is multihomed towards nodes with respective HAL offerings. Fortunately, this is the natural state of things for the topology variants considered in RIFT.
達成された均衡は、最高レベルがドメインを離れるか入力するすべてのノードによって大きく乱すことができます（さらに説明されていない違いはありません）。したがって、各ノードは、それぞれのHAL製品を使用してノードに向かってマルチホームすることをお勧めします。幸いなことに、これはRiftで考慮されるトポロジーのバリエーションの自然な状態です。
A RIFT node may also be configured to confine it to the leaf role with the LEAF_ONLY flag. A leaf node can also be configured to support leaf-2-leaf procedures with the LEAF_2_LEAF flag. In both cases, the node cannot be TOP_OF_FABRIC and its level cannot be configured. RIFT will fully determine the node's level after it is attached to the topology and ensure that the node is at the "bottom of the hierarchy" (southernmost).
RIFTノードは、LEAF_ONLYフラグに葉の役割に限定するように構成することもできます。リーフノードは、LEAF_2_LEAFフラグを使用してLEAF-2-LEAF手順をサポートするように構成することもできます。どちらの場合も、ノードはtop_of_fabricにすることはできず、そのレベルを構成することはできません。Riftは、トポロジに取り付けられた後、ノードのレベルを完全に決定し、ノードが「階層の下部」（最南端）にあることを確認します。
+----------------+ +-----------------+
| ToF21 | +------+ ToF22 | LEVEL 2
+-------+----+---+ | +----+---+--------+
| | | | | | | | |
| | | +----------------------------+ |
| +---------------------------+ | | | |
| | | | | | | | |
| | | | +-----------------------+ | |
| | +------------------------+ | | |
| | | | | | | | |
+-+---+--+ +-+---+--+ | +--+---+-+ +--+---+-+
|Spine111| |Spine112| | |Spine121| |Spine122| LEVEL 1
+-+---+--+ ++----+--+ | +--+---+-+ +-+----+-+
| | | | | | | | |
| +---------+ | link-M | +---------+ |
| | | | | | | | |
| +-------+ | | | | +-------+ | |
| | | | | | | | |
+-+---+-+ +--+--+-+ | +-+---+-+ +--+--+-+
|Leaf111| |Leaf112+-----+ |Leaf121| |Leaf122| LEVEL 0
+-------+ +-------+ +-------+ +-------+
Figure 6: A Single-Plane Miscabling Example
図6：シングル面の誤りの例
Figure 6 shows a single-plane miscabling example. It's a perfect Fat Tree fabric except for link-M connecting Leaf112 to ToF22.
図6は、単一面の容疑者の例を示しています。Leaf112をTOF22に接続するLink-Mを除いて、これは完璧な脂肪ツリーファブリックです。
The RIFT control protocol can discover the physical links automatically and is able to detect cabling that violates Fat Tree topology constraints. It reacts accordingly to such miscabling attempts, preventing adjacencies between nodes from being formed and traffic from being forwarded on those miscabled links at a minimum. In such scenario, Leaf112 will use link-M to derive its level (unless it is leaf) and can report links to Spine111 and Spine112 as miscabled unless the implementations allow horizontal links.
Rift Controlプロトコルは、物理リンクを自動的に発見し、脂肪ツリートポロジーの制約に違反するケーブルを検出することができます。それはそのような誤った試みにそれに応じて反応し、ノード間の隣接が形成されないようにし、それらの誤ったリンクに少なくとも転送されるのを防ぎます。このようなシナリオでは、leaf112はLink-Mを使用してレベルを導き出し（葉でない限り）、実装が水平リンクを許可しない限り、SPINE111およびSPINE112へのリンクを誤って報告できます。
Figure 7 shows a multi-plane miscabling example. Since Leaf112 and Spine121 belong to two different PoDs, the adjacency between Leaf112 and Spine121 cannot be formed. Link-W would be detected and prevented.
図7は、マルチプレーンの容疑者の例を示しています。Leaf112とSpine121は2つの異なるポッドに属しているため、Leaf112とSpine121の隣接は形成できません。Link-Wが検出され、防止されます。
+-------+ +-------+ +-------+ +-------+
|ToF A1| |ToF A2| |ToF B1| |ToF B2| LEVEL 2
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| | | +-----------------+ | | |
| +--------------------------+ | | | |
| +------+ | | | +------+ |
| | +-----------------+ | | | | |
| | | +--------------------------+ | |
| A | | B | | A | | B |
+-----+--+ +-+---+--+ +--+---+-+ +--+-----+
|Spine111| |Spine112| +---+Spine121| |Spine122| LEVEL 1
+-+---+--+ ++----+--+ | +--+---+-+ +-+----+-+
| | | | | | | | |
| +---------+ | | | +---------+ |
| | | | link-W | | | |
| +-------+ | | | | +-------+ | |
| | | | | | | | |
+-+---+-+ +--+--+-+ | +-+---+-+ +--+--+-+
|Leaf111| |Leaf112+------+ |Leaf121| |Leaf122| LEVEL 0
+-------+ +-------+ +-------+ +-------+
+--------PoD#1----------+ +---------PoD#2---------+
Figure 7: A Multiple Plane Miscabling Example
図7：複数の平面誤った例
RIFT provides an optional level determination procedure in its ZTP mode. Nodes in the fabric without their level configured determine it automatically. However, this can have possible counter-intuitive consequences. One extreme failure scenario is depicted in Figure 8, and it shows that if all northbound links of Spine11 fail at the same time, Spine11 negotiates a lower level than Leaf11 and Leaf12.
Riftは、ZTPモードでオプションのレベル決定手順を提供します。レベルを構成しない生地内のノードは、自動的に決定します。ただし、これは直感に反する結果をもたらす可能性があります。1つの極端な障害シナリオを図8に示し、Spine11のすべての北行きリンクが同時に失敗した場合、Spine11はLeaf11とLeaf12よりも低いレベルと交渉することを示しています。
To prevent such scenario where leaves are expected to act as switches, the LEAF_ONLY flag can be set for Leaf111 and Leaf112. Since level -1 is invalid, Spine11 would not derive a valid level from the topology in Figure 8. It will be isolated from the whole fabric, and it would be up to the leaves to declare the links towards such spine as miscabled.
葉がスイッチとして機能すると予想されるこのようなシナリオを防ぐために、leaf111およびleaf112にleaf_onlyフラグを設定できます。レベル-1は無効であるため、SPINE11は図8のトポロジから有効なレベルを導き出さず、ファブリック全体から分離され、葉まで存在します。
+-------+ +-------+ +-------+ +-------+
|ToF A1| |ToF A2| |ToF A1| |ToF A2|
+-------+ +-------+ +-------+ +-------+
| | | | | |
| +-------+ | | |
+ + | | ====> | |
X X +------+ | +------+ |
+ + | | | |
+----+--+ +-+-----+ +-+-----+
|Spine11| |Spine12| |Spine12|
+-+---+-+ ++----+-+ ++----+-+
| | | | | |
| +---------+ | | |
| +-------+ | | +-------+ |
| | | | | |
+-+---+-+ +--+--+-+ +-----+-+ +-----+-+
|Leaf111| |Leaf112| |Leaf111| |Leaf112|
+-------+ +-------+ +-+-----+ +-+-----+
| |
| +--------+
| |
+-+---+-+
|Spine11|
+-------+
Figure 8: Fallen Spine
図8：倒れた脊椎
There are scenarios where operators may want to leverage ZTP and implement additional cabling constraints that go beyond the previously described topology violations. Enforcing cabling down to specific level, node, and port combinations might make it simpler for onsite staff to perform troubleshooting activities or replace optical transceivers and/or cabling as the physical layout will be consistent across the fabric. This is especially true for densely connected fabrics where it is difficult to physically manipulate those components. It is also easy to imagine other models, such as one where the strict port requirement is relaxed.
オペレーターがZTPを活用し、以前に記載されたトポロジ違反を超えた追加のケーブル制約を実装したいシナリオがあります。ケーブルを特定のレベル、ノード、ポートの組み合わせに施行すると、オンサイトのスタッフがトラブルシューティングアクティビティを実行したり、光学トランシーバーやケーブルを置き換えたり、物理レイアウトがファブリック全体で一貫しているため、より簡単になります。これは、これらのコンポーネントを物理的に操作することが困難な密集したファブリックに特に当てはまります。また、厳格なポート要件が緩和されているモデルなど、他のモデルなどを想像するのも簡単です。
Figure 9 illustrates an example where the first port on Leaf1 must connect to the first port on Spine1, the second port on Leaf1 must connect to the first port on Spine2, and so on. Consider a case where (Leaf1, Port1) and (Leaf1, Port2) were reversed. RIFT would not consider this to be miscabled by default; however, an operator might want to.
図9は、leaf1の最初のポートがSPINE1の最初のポートに接続する必要がある例を示しています。LEAF1の2番目のポートは、SPINE2の最初のポートに接続する必要があります。（leaf1、port1）および（leaf1、port2）が逆転した場合を考えてみましょう。Riftは、これをデフォルトでは不正行為とは見なしません。ただし、オペレーターは望むかもしれません。
+--------+ +--------+ +--------+ +--------+
| Spine1 | | Spine2 | | Spine3 | | Spine4 |
+-1------+ +-1------+ +-1------+ +-1------+
+ + + +
| +----------+ | |
| | | |
| | +---------------------+ |
| | | |
| | | +--------------------------------+
| | | |
| | | |
| | | |
| | | |
+ + + +
+-1--2--3--4--+
| Leaf1 | ......
+-------------+
Figure 9: Additional Cabling Constraint Example
図9：追加のケーブル制約の例
RIFT allows implementations to provide programmable plug-ins that can adjust ZTP operation or capture information during computation. While defining this is outside the scope of this document, such a mechanism could be used to extend the miscabling functionality.
Riftを使用すると、実装がZTP操作を調整したり、計算中に情報をキャプチャできるプログラム可能なプラグインを提供したりできます。これを定義することはこのドキュメントの範囲外でありながら、そのようなメカニズムを使用して、誤った機能を拡張することができます。
For other protocols to achieve this, it would require additional operational overhead. Consider a fabric that is using unnumbered OSPF links; it is still very likely that a miscabled link will form an adjacency. Each attempt to move cables to the correct port may result in the need for additional troubleshooting as other links will become miscabled in the process. Without automation to explicitly tell the operator which ports need to be moved where, the process becomes manually intensive and error-prone very quickly. If the problem goes unnoticed, it will result in suboptimal performance in the fabric.
他のプロトコルがこれを達成するには、追加の動作オーバーヘッドが必要になります。数え切れないほどのOSPFリンクを使用しているファブリックを考えてみましょう。誤ったリンクが隣接を形成する可能性が非常に高いです。ケーブルを正しいポートに移動しようとするたびに、他のリンクがその過程で誤っているため、追加のトラブルシューティングが必要になる場合があります。自動化がなければ、どのポートを移動する必要があるかをオペレーターに明示的に伝え、プロセスが手動で集中的になり、非常に迅速にエラーが発生します。問題が気付かれない場合、ファブリックの最適ではないパフォーマンスが発生します。
RIFT supports both multicast and broadcast implementations. While a multicast implementation is preferred, there might cases where a broadcast implementation is optimal or even required. For example, operating systems on IoT devices and embedded devices may not have the required multicast support. Another example is containers, which do support multicast in some cases but tend to be very CPU-inefficient and difficult to tune.
Riftは、マルチキャストとブロードキャストの両方の実装をサポートしています。マルチキャストの実装が推奨されますが、ブロードキャストの実装が最適であるか、さらには必要な場合があります。たとえば、IoTデバイスおよび組み込みデバイスのオペレーティングシステムには、必要なマルチキャストサポートがない場合があります。もう1つの例はコンテナです。これは、場合によってはマルチキャストをサポートしますが、非常にcpuであり、調整が困難である傾向があります。
Disaggregation is the procedure whereby RIFT [RFC9692] advertises a more specific route southwards as an exception to the aggregated fabric-default north. Disaggregation is useful when a prefix within the aggregation is reachable via some of the parents but not the others at the same level of the fabric. It is mandatory when the level is the ToF since a ToF node that cannot reach a prefix becomes a black hole for that prefix. The hard problem is to know which prefixes are reachable by whom.
分解とは、Rift [RFC9692]が集約されたファブリックデフォルト北の例外として、より具体的なルートを南に宣伝する手順です。分解は、集約内の接頭辞が一部の親の一部を介して到達可能であるが、生地の同じレベルの他の親ではない場合に役立ちます。プレフィックスに到達できないTOFノードがそのプレフィックスのブラックホールになるため、レベルがTOFである場合は必須です。難しい問題は、誰が誰が到達できるかを知ることです。
In the general case, RIFT [RFC9692] solves that problem by interconnecting the ToF nodes so that the ToF nodes can exchange the full list of prefixes that exist in the fabric and figure out when a ToF node lacks reachability to some prefixes. This requires additional ports at the ToF, typically two ports per ToF node to form a ToF-spanning ring. RIFT [RFC9692] also defines the southbound reflection procedure that enables a parent to explore the direct connectivity of its peers, meaning their own parents and children; based on the advertisements received from the shared parents and children, it may enable the parent to infer the prefixes its peers can reach.
一般的なケースでは、RIFT [RFC9692]は、TOFノードを相互接続することにより問題を解決し、TOFノードがファブリックに存在するプレフィックスの完全なリストを交換し、TOFノードにいくつかのプレフィックスに到達可能性がない場合に把握できるようにします。これには、TOF、通常はTOFノードごとに2つのポートに追加のポートが必要です。Rift [RFC9692]は、親が仲間の直接的な接続性を探索できるようにする南行きの反射手順を定義します。共有された親と子供から受け取った広告に基づいて、親がピアが到達できる接頭辞を推測できるようになる場合があります。
When a parent lacks reachability to a prefix, it may disaggregate the prefix negatively, i.e., advertise that this parent can be used to reach any prefix in the aggregation except that one. The Negative Disaggregation signaling is simple and functions transitively from ToF to Top-of-Pod (ToP) and then from ToP to Leaf. However, it is hard for a parent to figure out which prefix it needs to disaggregate because it does not know what it does not know; it results that the use of a spanning ring at the ToF is required to operate the Negative Disaggregation. Also, though it is only an implementation problem, the programming of the FIB is complex compared to normal routes and may incur recursions.
親が接頭辞に到達可能性を欠いている場合、接頭辞を否定的に分解する可能性があります。つまり、この親を使用して集約の任意のプレフィックスに到達できることを宣伝します。否定的な分解シグナル伝達は単純であり、TOFからPod（Top）、そして上から葉までトランザティブに機能します。ただし、親がどのような接頭辞を分解する必要があるかを把握することは困難です。その結果、TOFでのスパニングリングの使用は、否定的な分解を操作するために必要であることになります。また、実装の問題にすぎませんが、FIBのプログラミングは通常のルートと比較して複雑であり、再帰が発生する可能性があります。
The more classical alternative is, for the parents that can reach a prefix that peers at the same level cannot, to advertise a more specific route to that prefix. This leverages the normal longest prefix match in the FIB and does not require a special implementation. As opposed to the Negative Disaggregation, the Positive Disaggregation is difficult and inefficient to operate transitively.
より古典的な代替品は、同じレベルのピアができないプレフィックスに到達できる親にとって、そのプレフィックスへのより具体的なルートを宣伝することです。これは、FIBで通常の最長のプレフィックスマッチを活用し、特別な実装を必要としません。否定的な分解とは対照的に、肯定的な分解は、一時的に動作することは困難で非効率的です。
Transitivity is not needed by a grandchild if all its parents received the Positive Disaggregation, meaning that they shall all avoid the black hole; when that is the case, they collectively build a ceiling that protects the grandchild. Until then, a parent that received the Positive Disaggregation may believe that some peers are lacking the reachability and re-advertise too early or defer and maintain a black hole situation longer than necessary.
両親全員が肯定的な分解を受け取った場合、孫は交差性を必要としません。つまり、彼らはすべてブラックホールを避けることを意味します。その場合、彼らは孫を保護する天井をまとめて構築します。それまでは、肯定的な分解を受けた親は、一部のピアが到達可能性を欠いており、早すぎることを繰り返したり、必要以上にブラックホールの状況を延期したり維持したりすると信じるかもしれません。
In a non-partitioned fabric, all the ToF nodes see one another through the reflection and can figure out if one is missing a child. In that case, it is possible to compute the prefixes that the peer cannot reach and disaggregate positively without a ToF-spanning ring. The ToF nodes can also ascertain that the ToP nodes are each connected to at least a ToF node that can still reach the prefix, meaning that the transitive operation is not required.
非党の生地では、すべてのTOFノードは反射を通して互いに互いに見られ、子供がいないかどうかを把握できます。その場合、ピアが到達できないプレフィックスを計算して、TOFスパンリングなしでは積極的に分解できます。TOFノードは、上部ノードがそれぞれ、プレフィックスに到達できる少なくともTOFノードに接続されていることを確認することもできます。つまり、推移的な動作は必要ありません。
The bottom line is that in a fabric that is partitioned (e.g., using multiple planes) and/or where the ToP nodes are not guaranteed to always form a ceiling for their children, it is mandatory to use Negative Disaggregation. On the other hand, in a highly symmetrical and fully connected fabric (e.g., a canonical Clos Network), the Positive Disaggregation methods save the complexity and cost associated to the ToF-spanning ring.
一番下の行は、分割されている生地（複数の平面を使用するなど）および/または上部ノードが常に子供の天井を形成することを保証されていない場合、否定的な分解を使用することが必須であるということです。一方、高度に対称的で完全に接続されたファブリック（例えば、標準的なクローズネットワーク）で、肯定的な分解方法は、TOFにまたがるリングに関連する複雑さとコストを節約します。
Note that in the case of Positive Disaggregation, the first ToF nodes that announce a more-specific route attract all the traffic for that route and may suffer from a transient incast. A ToP node that defers injecting the longer prefix in the FIB, in order to receive more advertisements and spread the packets better, also keeps on sending a portion of the traffic to the black hole in the meantime. In the case of Negative Disaggregation, the last ToF nodes that inject the route may also incur an incast issue; this problem would occur if a prefix that becomes totally unreachable is disaggregated.
肯定的な分解の場合、より固有のルートを発表する最初のTOFノードは、そのルートのすべてのトラフィックを引き付け、一時的な不定期に苦しむ可能性があることに注意してください。より多くの広告を受け取り、パケットをよりよく広めるために、FIBに長いプレフィックスを注入するdefをdefする上部ノードは、その間にトラフィックの一部をブラックホールに送信し続けます。負の分解の場合、ルートを挿入する最後のTOFノードは、不定期の問題も発生する可能性があります。この問題は、完全に到達不能になるプレフィックスが分解された場合に発生します。
When a physical or a virtual node changes its point of attachment in the fabric from a previous-leaf to a next-leaf, new routes must be installed that supersede the old ones. Since the flooding flows northwards, the nodes (if any) between the previous-leaf and the common parent are not immediately aware that the path via the previous-leaf is obsolete and a stale route may exist for a while. The common parent needs to select the freshest route advertisement in order to install the correct route via the next-leaf. This requires that the fabric determines the sequence of the movements of the mobile node.
物理的または仮想ノードが、以前の葉から次の葉に生地内のアタッチメントのポイントを変更する場合、古いルートに取って代わる新しいルートをインストールする必要があります。洪水は北に向かって流れるため、前葉と一般的な親の間のノード（もしあれば）は、前葉を介した経路が時代遅れであり、しばらくの間古いルートが存在する可能性があることをすぐに認識しません。共通の親は、次の葉を介して正しいルートをインストールするために、新鮮なルート広告を選択する必要があります。これには、ファブリックがモバイルノードの動きのシーケンスを決定する必要があります。
On the one hand, a classical sequence counter provides a total order for a while, but it will eventually wrap. On the other hand, a timestamp provides a permanent order, but it may miss a movement that happens too quickly vs. the granularity of the timing information. It is not envisioned that an average fabric supports the Precision Time Protocol [IEEEstd1588] in the short term nor that the precision available with the Network Time Protocol [RFC5905] (in the order of 100 to 200 ms) may not be necessarily enough to cover, e.g., the fast mobility of a Virtual Machine (VM).
一方では、クラシックシーケンスカウンターはしばらくの間総順序を提供しますが、最終的にはラップされます。一方、タイムスタンプは恒久的な順序を提供しますが、タイミング情報の粒度に対してあまりにも速く起こる動きを見逃す可能性があります。平均的なファブリックは、短期的には精密時間プロトコル[IEEESTD1588]をサポートしたり、ネットワーク時間プロトコル[RFC5905]で利用可能な精度（100〜200ミリ秒）で利用可能な精度は必ずしも十分ではない可能性があるとは考えられていません。
Section 6.8.4 ("Mobility") of [RFC9692] specifies a hybrid method that combines a sequence counter from the mobile node and a timestamp from the network taken at the leaf when the route is injected. If the timestamps of the concurrent advertisements are comparable (i.e., more distant than the precision of the timing protocol), then the timestamp alone is used to determine the relative freshness of the routes. Otherwise, the sequence counter from the mobile node is used if it is available. One caveat is that the sequence counter must not wrap within the precision of the timing protocol. Another is that the mobile node may not even provide a sequence counter; in which case, the mobility itself must be slower than the precision of the timing.
[RFC9692]のセクション6.8.4（「モビリティ」）は、ルートが注入されたときに葉で取られたネットワークからのモバイルノードのシーケンスカウンターとタイムスタンプを組み合わせたハイブリッドメソッドを指定します。同時広告のタイムスタンプが同等である場合（つまり、タイミングプロトコルの精度よりも遠い）、タイムスタンプのみを使用して、ルートの相対的な新鮮さを決定します。それ以外の場合、モバイルノードから使用可能な場合は、モバイルノードからのシーケンスカウンターが使用されます。1つの警告は、シーケンスカウンターがタイミングプロトコルの精度内でラップしてはならないことです。もう1つは、モバイルノードがシーケンスカウンターさえ提供できない可能性があることです。その場合、モビリティ自体はタイミングの精度よりも遅くなければなりません。
Mobility must not be confused with anycast. In both cases, the same address is injected in RIFT at different leaves. In the case of mobility, only the freshest route must be conserved since the mobile node changes its point of attachment for a leaf to the next. In the case of anycast, the node may either be multihomed (attached to multiple leaves in parallel) or reachable beyond the fabric via multiple routes that are redistributed to different leaves. Either way, the multiple routes are equally valid and should be conserved in the case of anycast. Without further information from the redistributed routing protocol, it is impossible to sort out a movement from a redistribution that happens asynchronously on different leaves. RIFT [RFC9692] expects that anycast addresses are advertised within the timing precision, which is typically the case with a low-precision timing and a multihomed node. Beyond that time interval, RIFT interprets the lag as a mobility and only the freshest route is retained.
モビリティをAnycastと混同してはなりません。どちらの場合も、同じアドレスが異なる葉で裂け目で注入されます。モビリティの場合、モバイルノードが葉までのアタッチメントポイントを次のものに変更するため、最新のルートのみを保存する必要があります。Anycastの場合、ノードは、異なる葉に再配布される複数のルートを介して、ファブリックを越えてファブリックを越えて到達可能なマルチホーム（並列の複数の葉に取り付けられています）のいずれかです。いずれにせよ、複数のルートは等しく有効であり、Anycastの場合に保存する必要があります。再配分されたルーティングプロトコルの詳細情報がなければ、異なる葉で非同期に発生する再分配からの動きを整理することは不可能です。Rift [RFC9692]は、Anycastアドレスがタイミングの精度内で宣伝されると予想しています。これは、通常、低精度のタイミングとマルチホームのノードの場合に当てはまります。その時間間隔を超えて、Riftはラグをモビリティとして解釈し、新鮮なルートのみが保持されます。
When using IPv6 [RFC8200], RIFT suggests leveraging 6LoWPAN ND [RFC8505] as the IPv6 ND interaction between the mobile node and the leaf. This not only provides a sequence counter but also a lifetime and a security token that may be used to protect the ownership of an address [RFC8928]. When using 6LoWPAN ND [RFC8505], the parallel registration of an anycast address to multiple leaves is done with the same sequence counter, whereas the sequence counter is incremented when the point of attachment changes. This way, it is possible to differentiate a mobile node from a multihomed node, even when the mobility happens within the timing precision. It is also possible for a mobile node to be multihomed as well, e.g., to change only one of its points of attachment.
IPv6 [RFC8200]を使用する場合、Riftは、モバイルノードと葉の間のIPv6 ND相互作用として6lowpan nd [rfc8505]を活用することを提案します。これは、シーケンスカウンターだけでなく、住所の所有権を保護するために使用できる寿命とセキュリティトークンも提供します[RFC8928]。6lowpan nd [rfc8505]を使用する場合、複数の葉へのanycastアドレスの並列登録は同じシーケンスカウンターで行われますが、アタッチメントポイントが変更されるとシーケンスカウンターが増加します。このようにして、モバイルノードをマルチホームノードと区別することができます。また、モバイルノードもマルチホームにしていることも可能です。たとえば、添付のポイントの1つのみを変更することもできます。
RIFT allows advertising IPv4 prefixes over an IPv6 RIFT network. An IPv6 Address Family (AF) configures via the usual ND mechanisms and then V4 can use V6 next-hops analogous to [RFC8950]. It is expected that the whole fabric supports the same type of forwarding of AFs on all the links. RIFT provides an indication whether a node is capable of V4-forwarding and implementations are possible where different routing tables are computed per AF as long as the computation remains loop-free.
Riftを使用すると、IPv6 Riftネットワークを介してIPv4プレフィックスを広告できます。IPv6アドレスファミリー（AF）は、通常のNDメカニズムを介して構成され、V4は[RFC8950]に類似したV6 Next-HOPSを使用できます。ファブリック全体が、すべてのリンクで同じタイプのAFSの転送をサポートすることが期待されています。Riftは、ノードがV4に適したものであるかどうかを示しており、計算がループフリーのままである限り、AFごとに異なるルーティングテーブルが計算される場合、実装が可能になります。
+-----+ +-----+
+---+---+ | ToF | | ToF |
^ +--+--+ +-----+
| | | | |
| | +-------------+ |
| | +--------+ | |
+ | | | |
V6 +-----+ +-+---+
Forwarding |Spine| |Spine|
+ +--+--+ +-----+
| | | | |
| | +-------------+ |
| | +--------+ | |
| | | | |
v +-----+ +-+---+
+---+---+ |Leaf | | Leaf|
+--+--+ +--+--+
| |
IPv4 prefixes| |IPv4 prefixes
| |
+---+----+ +---+----+
| V4 | | V4 |
| subnet | | subnet |
+--------+ +--------+
Figure 10: IPv4 over IPv6
図10：IPv6オーバーIPv4
RIFT doesn't precondition that nodes of the fabric have reachable addresses, but operational reasons to reach the internal nodes may exist. Figure 11 shows an example that the network management station (NMS) attaches to Leaf1.
Riftは、ファブリックのノードに到達可能なアドレスがあることを前提条件ではありませんが、内部ノードに到達する運用上の理由が存在する可能性があります。図11は、ネットワーク管理ステーション（NMS）がLEAF1に取り付けられている例を示しています。
+-------+ +-------+
| ToF1 | | ToF2 |
++---- ++ ++-----++
| | | |
| +----------+ |
| +--------+ | |
| | | |
++-----++ +--+---++
|Spine1 | |Spine2 |
++-----++ ++-----++
| | | |
| +----------+ |
| +--------+ | |
| | | |
++-----++ +--+---++
| Leaf1 | | Leaf2 |
+---+---+ +-------+
|
|NMS
Figure 11: In-Band Reachability of Nodes
図11：ノードの帯域到達可能性
If the NMS wants to access Leaf2, it simply works because the loopback address of Leaf2 is flooded in its Prefix North TIE.
NMSがleaf2にアクセスしたい場合、leaf2のループバックアドレスがそのプレフィックスノースタイであふれているため、単に機能します。
If the NMS wants to access Spine2, it also works because a spine node always advertises its loopback address in the Prefix North TIE. The NMS may reach Spine2 from Leaf1-Spine2 or Leaf1-Spine1-ToF1/ ToF2-Spine2.
NMSがSPINE2にアクセスしたい場合、スパインノードは常にプレフィックスノースタイでループバックアドレスを宣伝するためにも機能します。NMSは、leaf1-spine2またはleaf1-spine1-tof1/ tof2-spine2からspine2に到達する場合があります。
If the NMS wants to access ToF2, ToF2's loopback address needs to be injected into its Prefix South TIE. This TIE must be seen by all nodes at the level below -- the spine nodes in Figure 11 -- that must form a ceiling for all the traffic coming from below (south). Otherwise, the traffic from the NMS may follow the default route to the wrong ToF Node, e.g., ToF1.
NMSがTOF2にアクセスしたい場合、TOF2のループバックアドレスをそのプレフィックスサウスタイに注入する必要があります。このネクタイは、下のレベル（図11の背骨ノード）のすべてのノードで見なければなりません。これは、下から来るすべてのトラフィックの上限を形成する必要があります（南）。それ以外の場合、NMSからのトラフィックは、デフォルトのルートに従って間違ったTOFノード、たとえばTOF1へのルートに従うことができます。
In the case of failure between ToF2 and spine nodes, ToF2's loopback address must be disaggregated recursively all the way to the leaves. In a partitioned ToF, even with recursive disaggregation, a ToF node is only reachable within its plane.
TOF2ノードとスパインノード間の障害の場合、TOF2のループバックアドレスは、葉までずっと再帰的に分解されなければなりません。パーティション化されたTOFでは、再帰的な分解があっても、TOFノードはその平面内でのみ到達できます。
A possible alternative to recursive disaggregation is to use a ring that interconnects the ToF nodes to transmit packets between them for their loopback addresses only. The idea is that this is mostly control traffic and should not alter the load-balancing properties of the fabric.
再帰的な分解に代わる可能性のある代替手段は、TOFノードを相互接続するリングを使用して、ループバックアドレスのみでパケットを送信することです。アイデアは、これは主に制御トラフィックであり、ファブリックの負荷分散特性を変更すべきではないということです。
Each RIFT node may operate in ZTP mode. It has no configuration (unless it is a ToF node at the top of the topology or if it must operate in the topology as a leaf and/or support leaf-2-leaf procedures), and it will fully configure itself after being attached to the topology.
各リフトノードはZTPモードで動作する場合があります。構成はありません（トポロジの上部にあるTOFノードである場合、またはトポロジーで葉および/またはサポートLeaf-2-Leaf手順として動作しなければならない場合）。
+---+ +---+ +---+
|ToF| |ToF| |ToF| ToF
+---+ +---+ +---+
| | | | | |
| +----------------+ | |
| +----------------+ |
| | | | | |
+----------+--+ +--+----------+
| ToR1 | | ToR2 | Spine
+--+------+---+ +--+-------+--+
+---+ | | | | | | +---+
| +-----------------+ | | |
| | | +-------------+ | |
| | | | | +-----------------+ |
| | | | +--------------+ | | |
| | | | | | | |
+---+ +---+ +---+ +---+
| | | | | | | |
+---+ +---+ ............. +---+ +---+
SV(1) SV(2) SV(n-1) SV(n) Leaf
Figure 12: Dual-Homing Servers
図12：デュアルホーミングサーバー
Sometimes people may prefer to disaggregate from ToR nodes to servers from startup, i.e., the servers have multiple routes in the FIB from startup other than default routes to avoid breakages at the rack level. Full disaggregation of the fabric could be achieved by configuration supported by RIFT.
人々は、TORノードからスタートアップのサーバーに分解することを好む場合があります。つまり、サーバーには、ラックレベルでの破損を避けるために、デフォルトルート以外のStartupのFIBに複数のルートがあります。ファブリックの完全な分解は、Riftでサポートされている構成によって達成できます。
There are many different ways to deploy the controller. One possibility is attaching a controller to the RIFT domain from ToF and another possibility is attaching a controller from the leaf.
コントローラーを展開するには、さまざまな方法があります。1つの可能性は、コントローラーをTOFのRiftドメインに取り付けることであり、別の可能性は、葉からコントローラーを取り付けることです。
+------------+
| Controller |
++----------++
| |
| |
+----++ ++----+
------- | ToF | | ToF |
| +--+--+ +-----+
| | | | |
| | +-------------+ |
| | +--------+ | |
| | | | |
+-----+ +-+---+
RIFT domain |Spine| |Spine|
+--+--+ +-----+
| | | | |
| | +-------------+ |
| | +--------+ | |
| | | | |
| +-----+ +-+---+
------- |Leaf | | Leaf|
+-----+ +-----+
Figure 13: Fabric with a Controller
図13：コントローラー付きのファブリック
If a controller is attaching to the RIFT domain from ToF, it usually uses dual-homing connections. The loopback prefix of the controller should be advertised down by the ToF and spine to the leaves. If the controller loses the link to ToF, make sure the ToF withdraws the prefix of the controller.
コントローラーがTOFからRIFTドメインに接続している場合、通常、デュアルホミング接続を使用します。コントローラーのループバックのプレフィックスは、葉の脊椎と背骨によって宣伝される必要があります。コントローラーがTOFへのリンクを失った場合は、TOFがコントローラーのプレフィックスを引き出していることを確認してください。
If the controller is attaching from a leaf to the fabric, no special provisions are needed.
コントローラーが葉から生地に取り付けられている場合、特別な規定は必要ありません。
If global addressing is running without overlay, an external default route needs to be advertised through the RIFT fabric to achieve internet connectivity. For the purpose of forwarding of the entire RIFT fabric, an internal fabric prefix needs to be advertised in the Prefix South TIE by ToF and spine nodes.
オーバーレイなしでグローバルアドレス指定が実行されている場合、インターネット接続を実現するために、外部デフォルトのルートをRiftファブリックを介して宣伝する必要があります。Riftファブリック全体を転送する目的では、内部ファブリックのプレフィックスを、TOFおよびスパインノードによって接頭辞サウスタイで宣伝する必要があります。
In the case that the internet gateway is a leaf, the leaf node as the internet gateway needs to advertise a default route in its Prefix North TIE.
インターネットゲートウェイがリーフである場合、インターネットゲートウェイがプレフィックスノースタイでデフォルトルートを宣伝する必要があるため、リーフノードが葉のノードです。
In the case that the internet gateway is a ToF, the ToF and spine nodes need to advertise a default route in the Prefix South TIE.
インターネットゲートウェイがTOFである場合、TOFノードとスパインノードは、接頭辞サウスタイでデフォルトルートを宣伝する必要があります。
+--------+ +--------+
| | LIE LIE | |
| A | +----> <----+ | B |
| +---------------------+ |
+--------+ +--------+
X/24 Y/24
Figure 14: Subnet Mismatch
図14：サブネットの不一致
LIEs are exchanged over all links running RIFT to perform Link (Neighbor) Discovery. A node must NOT originate LIEs on an AF if it does not process received LIEs on that family. LIEs on the same link are considered part of the same negotiation independent from the AF they arrive on. An implementation must be ready to accept TIEs on all addresses it used as the source of LIE frames.
嘘は、リンク（隣接）発見を実行するためにRiftを実行しているすべてのリンクで交換されます。ノードは、その家族に受信した処理を処理しない場合、AFに嘘を発信してはなりません。同じリンクにあるのは、到着したAFから独立して同じ交渉の一部と見なされます。実装は、嘘フレームのソースとして使用されたすべてのアドレスのタイを受け入れる準備ができている必要があります。
As shown in Figure 14, an adjacency of nodes A and B may form without further checks, but the forwarding between nodes A and B may fail because subnet X mismatches with subnet Y.
図14に示すように、ノードaとbの隣接性はさらにチェックせずに形成される可能性がありますが、サブネットxのsubnet yを備えたサブネットxの不一致であるため、ノードaとb間の転送は故障する可能性があります。
To prevent this, a RIFT implementation should check for subnet mismatch in a way that is similar to how IS-IS does. This can lead to scenarios where an adjacency, despite the exchange of LIEs in both AFs, may end up having an adjacency in a single AF only. This is especially a consideration in scenarios relating to Section 5.9.
これを防ぐために、Rift実装は、IS-ISの方法と同様の方法でサブネットの不一致を確認する必要があります。これにより、両方のAFで嘘をついているにもかかわらず、隣接が単一のAFのみで隣接することになる可能性があるシナリオにつながる可能性があります。これは、特にセクション5.9に関連するシナリオで考慮されます。
+ traffic
|
v
+------+------+
| ToF |
+---+-----+---+
| | | |
+------------+ | | +------------+
| | | |
+---+---+ +-------+ +-------+ +---+---+
| | | | | | | |
|Spine11| |Spine12| |Spine21| |Spine22| LEVEL 1
+-+---+-+ ++----+-+ +-+---+-+ ++----+-+
| | | | | | | |
| +---------+ | | +---------+ |
| +-------+ | | | +-------+ | |
| | | | | | | |
+-+---+-+ +--+--+-+ +-+---+-+ +--+--+-+
| | | | | | | |
|Leaf111| |Leaf112| |Leaf121| |Leaf122| LEVEL 0
+-+-----+ ++------+ +-----+-+ +-----+-+
+ + + ^ +
PrefixA PrefixB PrefixA | PrefixC
|
+ traffic
Figure 15: Anycast
図15：anycast
If the traffic comes from ToF to Leaf111 or Leaf121, which has anycast prefix PrefixA, RIFT can deal with this case well. However, if the traffic comes from Leaf122, it arrives to Spine21 or Spine22 at LEVEL 1. Additionally, Spine21 or Spine22 doesn't know another PrefixA attaching Leaf111, so it will always get to Leaf121 and never Leaf111. If the intention is that the traffic should be offloaded to Leaf111, then use the policy-guided prefixes defined in RIFT [RFC9692].
トラフィックがTOFからleaf111またはleaf121に届く場合、aycast prefix prefixaを備えた場合、Riftはこのケースをうまく処理できます。ただし、トラフィックがleaf122から来ると、レベル1で脊椎21または脊椎22に到着します。さらに、Spine21またはSpine22はleaf111を取り付けている別のプレフィックスを知りません。トラフィックをLEAF111にオフロードする必要があるという意図がある場合は、RIFT [RFC9692]で定義されたポリシーガイド付きプレフィックスを使用します。
The design of RIFT inherits the anisotropic design of a default route upwards (northwards) from RPL [RFC6550]. It also inherits the capability to inject external host routes at the Leaf level using Wireless ND (WiND) [RFC8505] [RFC8928] between a RIFT-agnostic host and a RIFT router. Both the RPL and the RIFT protocols are meant for a large scale, and WiND enables device mobility at the edge the same way in both cases.
RIFTの設計は、RPL [RFC6550]からデフォルトルートの異方性設計を上方（北向き）に継承します。また、Rift-Angostic HostとRift Routerの間で、ワイヤレスND（Wind）[RFC8505] [RFC8928]を使用して、リーフレベルで外部ホストルートを葉のレベルに注入する機能を継承します。RPLとRIFTプロトコルの両方は、大規模なものであり、風力はどちらの場合も同じ方法でデバイスのモビリティをエッジのモビリティを可能にします。
The main difference between RIFT and RPL is that there's a single root with RPL, whereas RIFT has many ToF nodes. This adds huge capabilities for leaf-2-leaf ECMP paths but additional complexity with the need to disaggregate. Also, RIFT uses link-state flooding northwards and is not designed for low-power operation.
RiftとRPLの主な違いは、RPLの単一ルートがあるのに対し、Riftには多くのTOFノードがあることです。これにより、Leaf-2-Leaf ECMPパスに膨大な機能が追加されますが、分解する必要性とさらに複雑になります。また、Riftはリンク状態の洪水を北に使用し、低電力操作のために設計されていません。
Still, nothing prevents that the IP devices connected at the Leaf are IoT devices, which typically expose their address using WiND -- this is an upgrade from 6LoWPAN ND [RFC6775].
それでも、リーフで接続されているIPデバイスがIoTデバイスであることを防ぐものはありません。これは通常、風を使用してアドレスを公開します。これは6lowpan nd [RFC6775]からのアップグレードです。
A network that serves high speed / high power IoT devices should typically provide deterministic capabilities for applications such as high speed control loops or movement detection. The Fat Tree is highly reliable and, in normal conditions, provides an equivalent multipath operation; however, the ECMP doesn't provide hard guarantees for either delivery or latency. As long as the fabric is non-blocking, the result is the same, but there can be load unbalances resulting in incast and possibly congestion loss that will prevent the delivery within bounded latency.
高速 /高出力IoTデバイスを提供するネットワークは、通常、高速制御ループやムーブメント検出などのアプリケーションに決定論的機能を提供する必要があります。脂肪の木は非常に信頼性が高く、通常の条件では、同等のマルチパス操作を提供します。ただし、ECMPは、配信または遅延のどちらにも厳しい保証を提供しません。ファブリックが非ブロッキングである限り、結果は同じですが、負荷の不均衡が発生する可能性があり、その結果、境界潜伏の潜時の送達を妨げる不浸透性およびおそらくうっ血損失が発生する可能性があります。
This could be alleviated with Packet Replication, Elimination, and Ordering Functions (PREOF) [RFC8655] leaf-2-leaf, but PREOF is hard to provide at the scale of all flows and the replication may increase the probability of the overload that it attempts to solve.
これは、パケットの複製、除去、および順序機能（Preof）[RFC8655] Leaf-2-Leafで緩和される可能性がありますが、PREOFはすべてのフローのスケールで提供するのが困難であり、複製により解決しようとする過負荷の確率が増加する可能性があります。
Note that the load balancing is not RIFT's problem, but it is key to serve IoT adequately.
負荷分散はRiftの問題ではありませんが、IoTを適切に提供する鍵であることに注意してください。
As outlined in Section 9 ("Security Considerations") of [RFC9692], either a private shared key or a public/private key pair is used to authenticate the adjacency. Both the key distribution and key synchronization methods are out of scope for this document. Both nodes in the adjacency must share the same keys, key type, and algorithm for a given key ID. Mismatched keys will not interoperate as their security envelopes will be unverifiable.
[RFC9692]のセクション9（「セキュリティ上の考慮事項」）で概説されているように、プライベート共有キーまたはパブリック/プライベートキーペアのいずれかを使用して、隣接を認証します。このドキュメントの主要な分布と主要な同期方法はどちらも範囲外です。隣接の両方のノードは、特定のキーIDの同じキー、キータイプ、およびアルゴリズムを共有する必要があります。セキュリティエンベロープは検証できないため、不一致のキーは相互運用しません。
Key rollover while the adjacency is active may be supported. The specific mechanism is well documented in [RFC6518]. As outlined in 9.9 ("Host Implementations") of [RFC9692], hosts as well as VMs acting as RIFT devices are possible. Key Management Protocols (KMPs), such as Key Value (KV) for key rollover in the fabric, use a symmetric key that can be changed easily when compromised; in which case, the symmetric key of a host is more likely to be compromised than an in-fabric networking node.
隣接がアクティブである間にキーロールオーバーがサポートされる場合があります。特定のメカニズムは[RFC6518]で十分に文書化されています。[RFC9692]の9.9（「ホスト実装」）で概説されているように、ホストとRIFTデバイスとして機能するVMが可能です。ファブリックのキーロールオーバーのキー値（KV）などのキー管理プロトコル（KMP）は、侵害されたときに簡単に変更できる対称キーを使用します。その場合、ホストの対称キーは、ファブリック内ネットワークノードよりも妥協する可能性が高くなります。
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in RIFT. RIFT explicitly requires the use of a TTL/HL value of 1 or 255 when sending/receiving LIEs and TIEs so that implementers have a choice between the two.
パケットの時間（TTL）（IPv4）またはホップ制限（IPv6）を使用して、接続されたリンク上の隣接ノードによってパケットが発信されたかどうかを確認していることが、Riftで使用されています。Riftは、嘘を送信/受信するときに1または255のTTL/HL値を1つまたは255のTTL/HL値の使用を明示的に必要とし、実装者が2つの間で選択できるようにします。
TTL=1 or HL=1 protects against the information disseminating more than 1 hop in the fabric and should be the default unless configured otherwise. TTL=255 or HL=255 can lead RIFT TIE packet propagation to more than one hop (the multicast address is already in local subnetwork range) in case of implementation problems but does protect against a remote attack as well, and the receiving remote router will ignore such TIE packet unless the remote router is exactly 254 hops away and accepts only TTL=1 or HL=1. [RFC5082] defines a Generalized TTL Security Mechanism (GTSM). The GTSM is applicable to LIE/TIE implementations that use a TTL or HL of 255. It provides a defense from infrastructure attacks based on forged protocol packets from outside the fabric.
TTL = 1またはHL = 1は、ファブリックに1つ以上のホップを広める情報から保護し、特に構成されていない限りデフォルトにする必要があります。TTL = 255またはHL = 255は、実装の問題が発生した場合にリフトタイパケットの伝播を複数のホップに導くことができます（マルチキャストアドレスはすでにローカルサブネットワークの範囲にあります）が、リモート攻撃からも保護します。[RFC5082]は、一般化されたTTLセキュリティメカニズム（GTSM）を定義します。GTSMは、255のTTLまたはHLを使用するLie/Tieの実装に適用できます。ファブリックの外側からの偽造プロトコルパケットに基づいて、インフラストラクチャ攻撃から防御を提供します。
This document presents applicability of RIFT. As such, it does not introduce any security considerations. However, there are a number of security concerns in [RFC9692].
このドキュメントは、Riftの適用性を示しています。そのため、セキュリティ上の考慮事項は導入されません。ただし、[RFC9692]には多くのセキュリティ上の懸念があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[ISO10589-Second-Edition]
ISO/IEC, "Information technology - Telecommunications and
information exchange between systems - Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", ISO/IEC 10589:2002, November 2002,
<https://www.iso.org/standard/30932.html>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February 2012,
<https://www.rfc-editor.org/info/rfc6518>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed.,
Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional
Forwarding Detection (BFD) on Link Aggregation Group (LAG)
Interfaces", RFC 7130, DOI 10.17487/RFC7130, February
2014, <https://www.rfc-editor.org/info/rfc7130>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K.
Patel, "Advertising IPv4 Network Layer Reachability
Information (NLRI) with an IPv6 Next Hop", RFC 8950,
DOI 10.17487/RFC8950, November 2020,
<https://www.rfc-editor.org/info/rfc8950>.
[RFC9692] Przygienda, T., Ed., Head, J., Ed., Sharma, A., Thubert,
P., Rijsman, B., and D. Afanasiev, "RIFT: Routing in Fat
Trees", RFC 9692, DOI 10.17487/RFC9692, April 2025,
<https://www.rfc-editor.org/info/rfc9692>.
[TR-384] Broadband Forum Technical Report, "TR-384: Cloud Central
Office Reference Architectural Framework", TR-384, Issue
1, January 2018,
<https://www.broadband-forum.org/pdfs/tr-384-1-0-0.pdf>.
[CLOS] Yuan, X., "On Nonblocking Folded-Clos Networks in Computer
Communication Environments", 2011 IEEE International
Parallel & Distributed Processing Symposium,
DOI 10.1109/IPDPS.2011.27, May 2011,
<https://ieeexplore.ieee.org/document/6012836>.
[FATTREE] Leiserson, C. E., "Fat-Trees: Universal Networks for
Hardware-Efficient Supercomputing", IEEE Transactions on
Computers, vol. C-34, no. 10, pp. 892-901,
DOI 10.1109/TC.1985.6312192, October 1985,
<https://ieeexplore.ieee.org/document/6312192>.
[IEEEstd1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2019, DOI 10.1109/IEEESTD.2020.9120376, June
2020, <https://ieeexplore.ieee.org/document/9120376>.
[PNNI] The ATM Forum Technical Committee, "Private Network-
Network Interface - Specification Version 1.1 - (PNNI
1.1)", af-pnni-0055.001, April 2002,
<https://www.broadband-forum.org/download/af-pnni-
0055.001.pdf>.
[RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
State Routing Protocol (OLSR)", RFC 3626,
DOI 10.17487/RFC3626, October 2003,
<https://www.rfc-editor.org/info/rfc3626>.
[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>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
The authors would like to thank Jaroslaw Kowalczyk, Alvaro Retana, Jim Guichard, and Jeffrey Zhang for providing invaluable concepts and content for this document.
著者は、この文書に貴重な概念とコンテンツを提供してくれたJaroslaw Kowalczyk、Alvaro Retana、Jim Guichard、Jeffrey Zhangに感謝します。
The following people contributed substantially to the content of this document and should be considered coauthors:
次の人々は、この文書の内容に大きく貢献し、共著者と見なされるべきです。
Jordan Head
Juniper Networks
Email: jhead@juniper.net
Tom Verhaeg
Juniper Networks
Email: tverhaeg@juniper.net
Yuehua Wei (editor)
ZTE Corporation
No.50, Software Avenue
Nanjing
210012
China
Email: wei.yuehua@zte.com.cn
Zheng (Sandy) Zhang
ZTE Corporation
No.50, Software Avenue
Nanjing
210012
China
Email: zhang.zheng@zte.com.cn
Dmitry Afanasiev
Yandex
Email: fl0w@yandex-team.ru
Pascal Thubert
Individual
France
Email: pascal.thubert@gmail.com
Tony Przygienda
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
United States of America
Email: prz@juniper.net