Internet Engineering Task Force (IETF) T. Przygienda, Ed.
Request for Comments: 9692 J. Head, Ed.
Category: Standards Track Juniper Networks
ISSN: 2070-1721 A. Sharma
Hudson River Trading
P. Thubert
B. Rijsman
Individual
D. Afanasiev
Yandex
April 2025
This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof. These topologies were initially used within crossbar interconnects and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP fabrics as well. The protocol specified by this document is optimized towards the minimization of control plane state to support very large substrates as well as the minimization of configuration and operational complexity to allow for a simplified deployment of said topologies.
このドキュメントでは、Clos、Fat Tree、およびそのバリエーション用の特殊な動的ルーティングプロトコルを定義します。これらのトポロジーは当初、クロスバーの相互接続で使用され、その結果、ルーターとスイッチプレーンで使用されていましたが、その特性により、IPファブリックの構築にも最適です。このドキュメントで指定されたプロトコルは、非常に大きな基質をサポートするコントロールプレーン状態の最小化と、構成と運用上の複雑さの最小化をサポートするために最適化されています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9692.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9692で取得できます。
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
1.1. Requirements Language
2. A Reader's Digest
3. Reference Frame
3.1. Terminology
3.2. Topology
4. RIFT: Routing in Fat Trees
5. Overview
5.1. Properties
5.2. Generalized Topology View
5.2.1. Terminology and Glossary
5.2.2. Clos as Crossed, Stacked Crossbars
5.3. Fallen Leaf Problem
5.4. Discovering Fallen Leaves
5.5. Addressing the Fallen Leaves Problem
6. Specification
6.1. Transport
6.2. Link (Neighbor) Discovery (LIE Exchange)
6.2.1. LIE Finite State Machine
6.3. Topology Exchange (TIE Exchange)
6.3.1. Topology Information Elements
6.3.2. Southbound and Northbound TIE Representation
6.3.3. Flooding
6.3.4. TIE Flooding Scopes
6.3.5. RAIN: RIFT Adjacency Inrush Notification
6.3.6. Initial and Periodic Database Synchronization
6.3.7. Purging and Rollovers
6.3.8. Southbound Default Route Origination
6.3.9. Northbound TIE Flooding Reduction
6.3.10. Special Considerations
6.4. Reachability Computation
6.4.1. Northbound Reachability SPF
6.4.2. Southbound Reachability SPF
6.4.3. East-West Forwarding Within a Non-ToF Level
6.4.4. East-West Links Within a ToF Level
6.5. Automatic Disaggregation on Link & Node Failures
6.5.1. Positive, Non-Transitive Disaggregation
6.5.2. Negative, Transitive Disaggregation for Fallen Leaves
6.6. Attaching Prefixes
6.7. Optional Zero Touch Provisioning (RIFT ZTP)
6.7.1. Terminology
6.7.2. Automatic System ID Selection
6.7.3. Generic Fabric Example
6.7.4. Level Determination Procedure
6.7.5. RIFT ZTP FSM
6.7.6. Resulting Topologies
6.8. Further Mechanisms
6.8.1. Route Preferences
6.8.2. Overload Bit
6.8.3. Optimized Route Computation on Leaves
6.8.4. Mobility
6.8.5. Key/Value (KV) Store
6.8.6. Interactions with BFD
6.8.7. Fabric Bandwidth Balancing
6.8.8. Label Binding
6.8.9. L2L Procedures
6.8.10. Address Family and Multi-Topology Considerations
6.8.11. One-Hop Healing of Levels with East-West Links
6.9. Security
6.9.1. Security Model
6.9.2. Security Mechanisms
6.9.3. Security Envelope
6.9.4. Weak Nonces
6.9.5. Lifetime
6.9.6. Security Association Changes
7. Information Elements Schema
7.1. Backwards-Compatible Extension of Schema
7.2. common.thrift
7.3. encoding.thrift
8. Further Details on Implementation
8.1. Considerations for Leaf-Only Implementation
8.2. Considerations for Spine Implementation
9. Security Considerations
9.1. General
9.2. Time to Live and Hop Limit Values
9.3. Malformed Packets
9.4. RIFT ZTP
9.5. Lifetime
9.6. Packet Number
9.7. Outer Fingerprint Attacks
9.8. TIE Origin Fingerprint DoS Attacks
9.9. Host Implementations
9.9.1. IPv4 Broadcast and IPv6 All-Routers Multicast
Implementations
10. IANA Considerations
10.1. Multicast and Port Numbers
10.2. Registry for RIFT Security Algorithms
10.3. Registries with Assigned Values for Schema Values
10.3.1. RIFTVersions Registry
10.3.2. RIFTCommonAddressFamilyType Registry
10.3.3. RIFTCommonHierarchyIndications Registry
10.3.4. RIFTCommonIEEE8021ASTimeStampType Registry
10.3.5. RIFTCommonIPAddressType Registry
10.3.6. RIFTCommonIPPrefixType Registry
10.3.7. RIFTCommonIPv4PrefixType Registry
10.3.8. RIFTCommonIPv6PrefixType Registry
10.3.9. RIFTCommonKVTypes Registry
10.3.10. RIFTCommonPrefixSequenceType Registry
10.3.11. RIFTCommonRouteType Registry
10.3.12. RIFTCommonTIETypeType Registry
10.3.13. RIFTCommonTieDirectionType Registry
10.3.14. RIFTEncodingCommunity Registry
10.3.15. RIFTEncodingKeyValueTIEElement Registry
10.3.16. RIFTEncodingKeyValueTIEElementContent Registry
10.3.17. RIFTEncodingLIEPacket Registry
10.3.18. RIFTEncodingLinkCapabilities Registry
10.3.19. RIFTEncodingLinkIDPair Registry
10.3.20. RIFTEncodingNeighbor Registry
10.3.21. RIFTEncodingNodeCapabilities Registry
10.3.22. RIFTEncodingNodeFlags Registry
10.3.23. RIFTEncodingNodeNeighborsTIEElement Registry
10.3.24. RIFTEncodingNodeTIEElement Registry
10.3.25. RIFTEncodingPacketContent Registry
10.3.26. RIFTEncodingPacketHeader Registry
10.3.27. RIFTEncodingPrefixAttributes Registry
10.3.28. RIFTEncodingPrefixTIEElement Registry
10.3.29. RIFTEncodingProtocolPacket Registry
10.3.30. RIFTEncodingTIDEPacket Registry
10.3.31. RIFTEncodingTIEElement Registry
10.3.32. RIFTEncodingTIEHeader Registry
10.3.33. RIFTEncodingTIEHeaderWithLifeTime Registry
10.3.34. RIFTEncodingTIEID Registry
10.3.35. RIFTEncodingTIEPacket Registry
10.3.36. RIFTEncodingTIREPacket Registry
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Sequence Number Binary Arithmetic
Appendix B. Examples
B.1. Normal Operation
B.2. Leaf Link Failure
B.3. Partitioned Fabric
B.4. Northbound Partitioned Router and Optional East-West Links
Acknowledgments
Contributors
Authors' Addresses
Clos [CLOS] topologies have gained prominence in today's networking, primarily as a result of the paradigm shift towards a centralized data center architecture that is poised to deliver a majority of computation and storage services in the future. Such networks are commonly called a fat tree / network in modern IP fabric considerations [VAHDAT08] as a similar term for the original definition of the term Fat Tree [FATTREE]. In most generic terms, and disregarding exceptions like horizontal shortcuts, those networks are all variations of a structured design isomorphic to a ranked lattice where the least upper bound is the "top of the fabric" and links closer to the top may be "fatter" to guarantee non-blocking bisectional capacity.
主に、将来的に大部分の計算とストレージサービスを提供する態勢が整っている集中データセンターアーキテクチャへのパラダイムシフトの結果として、クローズ（クローズ）トポロジは今日のネットワーキングで顕著になりました。このようなネットワークは、一般に、最新のIPファブリックの考慮事項[Vahdat08]の脂肪ツリー /ネットワークと呼ばれます[Fattree]という用語の元の定義の同様の用語として。ほとんどの一般的な用語では、水平ショートカットなどの例外を無視すると、これらのネットワークはすべて、最小上限が「ファブリックの上部」であり、上部に近いリンクが「fatter」である可能性があるランク付けされた格子に対する構造化されたデザインの異型のバリエーションです。
Many builders of such IP fabrics desire a protocol that autoconfigures itself and deals with failures and misconfigurations with a minimum amount of human intervention. Such a solution would allow local IP fabric bandwidth to be consumed in a "standard component" fashion, i.e., provision it much faster and operate it at much lower costs than today, similar to how compute or storage is consumed already.
このようなIPファブリックの多くのビルダーは、それ自体を自動化し、最小限の人間の介入で障害と誤った統合を扱うプロトコルを望んでいます。このようなソリューションにより、ローカルIPファブリックの帯域幅を「標準コンポーネント」やすりで消費することができます。つまり、既にコンピューティングまたはストレージの消費方法と同様に、今日よりもはるかに低いコストで操作します。
In looking at the problem through the lens of such IP fabric requirements, Routing in Fat Trees (RIFT) addresses those challenges not through an incremental modification of either a link-state (distributed computation) or distance-vector (diffused computation) technique but rather a mixture of both, briefly described as "link-state towards the spines" and "distance vector towards the leaves". In other words, "bottom" levels are flooding their link-state information in the "northern" direction while each node generates under normal conditions a "default route" and floods it in the "southern" direction. This type of protocol naturally supports highly desirable address aggregation. Alas, such aggregation could drop traffic in cases of misconfiguration or while failures are being resolved. It could also cause persistent network partitioning, which has to be addressed by some adequate mechanism. The approach RIFT takes is described in Section 6.5 and is based on automatic, sufficient disaggregation of prefixes in case of link and node failures.
このようなIPファブリック要件のレンズを介した問題を見ると、脂肪ツリー（RIFT）のルーティングは、リンク状態（分散計算）または距離ベクトル（拡散した計算）技術の増分変更ではなく、むしろ「スパインに向かってリンクステート」と「距離ベクトルに向かって」と記述されている両方の混合物のいずれかのインクリメンタル変更を通じて、これらの課題に対処します。言い換えれば、「ボトム」レベルはリンク状態情報を「北」の方向にあふれさせ、各ノードは通常の条件下で「デフォルトルート」を生成し、「南」方向にあふれています。このタイプのプロトコルは、非常に望ましいアドレス集計を自然にサポートします。悲しいかな、このような集約は、誤った構成の場合や障害が解決されている場合にトラフィックを減らす可能性があります。また、持続的なネットワークパーティションを引き起こす可能性があり、適切なメカニズムによって対処する必要があります。Riftが取るアプローチはセクション6.5で説明されており、リンクおよびノードの障害の場合のプレフィックスの自動で十分な分解に基づいています。
The protocol further provides:
プロトコルはさらに提供します。
* optional fully automated construction of fat tree topologies based on detection of links without any configuration (Section 6.7) while allowing for conventional configuration methods or an arbitrary mix of both,
* 従来の構成方法または両方の任意の組み合わせを可能にしながら、構成なしのリンクの検出に基づいて、脂肪ツリートポロジーの完全に自動化されたオプション構造、
* the minimum amount of routing state held by nodes,
* ノードが保有するルーティング状態の最小量、
* automatic pruning and load balancing of topology flooding exchanges over a sufficient subset of links (Section 6.3.9),
* リンクの十分なサブセットを介したトポロジー洪水交換の自動剪定と負荷分散（セクション6.3.9）、
* automatic address aggregation (Section 6.3.8) and consequently automatic disaggregation (Section 6.5) of prefixes on link and node failures to prevent traffic loss and suboptimal routing,
* 自動アドレス集計（セクション6.3.8）およびその結果、トラフィックの損失と最適ではないルーティングを防ぐためのリンクおよびノードの障害の接頭辞の自動分解（セクション6.5）、
* loop-free non-ECMP forwarding due to its inherent valley-free nature,
* その固有の谷のない性質によるループフリーの非ECMP転送、
* fast mobility (Section 6.8.4),
* 高速モビリティ（セクション6.8.4）、
* rebalancing of traffic towards the spines based on bandwidth available (Section 6.8.7.1), and finally
* 利用可能な帯域幅に基づいて棘への交通のリバランス（セクション6.8.7.1）、そして最後に
* mechanisms to synchronize a limited key-value datastore (Section 6.8.5.1) that can be used after protocol convergence to, e.g., bootstrap higher levels of functionality on nodes.
* プロトコルの収束後に使用できる限られたキー価値データストア（セクション6.8.5.1）を同期するメカニズム、たとえば、ノード上のより高いレベルの機能性のブートストラップ。
Figure 1 illustrates a simplified, conceptual view of a RIFT fabric with its routing tables and topology databases using IPv4 as the address family. The top of the fabric's link-state database holds information about the nodes below it and the routes to them. When referring to Figure 1, /32 notation corresponds to each node's IPv4 loopback address (e.g., A/32 is node A's loopback, etc.) and 0/0 indicates a default IPv4 route. The first row of database information represents the nodes for which full topology information is available. The second row of database information indicates that partial information of other nodes in the same level is also available. Such information will be needed to perform certain algorithms necessary for correct protocol operation. When the "bottom" (or in other words leaves) of the fabric is considered, the topology is basically empty and, under normal conditions, the leaves hold a load-balanced default route to the next level.
図1は、IPv4をアドレスファミリとして使用するルーティングテーブルとトポロジデータベースを備えたRiftファブリックの簡略化された概念ビューを示しています。ファブリックのリンク状態データベースの上部には、その下のノードとそれらへのルートに関する情報が保持されます。図1を参照する場合、/32表記は各ノードのIPv4ループバックアドレス（たとえば、A/32はノードAのループバックなど）に対応し、0/0はデフォルトのIPv4ルートを示します。データベース情報の最初の行は、完全なトポロジ情報が利用可能なノードを表します。データベース情報の2番目の行は、同じレベルの他のノードの部分的な情報も利用できることを示しています。このような情報は、正しいプロトコル操作に必要な特定のアルゴリズムを実行するために必要です。ファブリックの「底」（または言い換えれば葉）が考慮されると、トポロジーは基本的に空であり、通常の条件下では、葉は次のレベルまでの負荷バランスの取れたデフォルトルートを保持します。
The remainder of this document fills in the protocol specification details.
このドキュメントの残りの部分は、プロトコルの仕様の詳細を記入します。
[A,B,C,D]
[E]
+---------+ +---------+ A/32 @ [C,D]
| E | | F | B/32 @ [C,D]
+-+-----+-+ +-+-----+-+ C/32 @ C
| | | | D/32 @ D
| | | |
| | +--+ |
| | | |
| +---------)--+ |
| | | |
| | | |
| +---------+ | |
| | | |
[A,B] +-+-----+-+ +-+-----+-+ [A,B]
[D] | C | | D | [C]
+-+-----+-+ +-+-----+-+
0/0 @ [E,F] | | | | 0/0 @ [E,F]
A/32 @ [A] | | | | A/32 @ A
B/32 @ [B] | | +--+ | B/32 @ B
| | | |
| +---------)--+ |
| | | |
| +---------+ | |
| | | |
+-+-----+-+ +-+-----+-+
0/0 @ [C,D] | A | | B | 0/0 @ [C,D]
+---------+ +---------+
Figure 1: RIFT Information Distribution
図1：リフト情報の分布
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This section is an initial guided tour through the document in order to convey the necessary information for different readers, depending on their level of interest. The authors recommend reading the HTML or PDF versions of this document due to the inherent limitation of text version to represent complex figures.
このセクションは、関心のあるレベルに応じて、さまざまな読者に必要な情報を伝えるためのドキュメントを介した最初のガイド付きツアーです。著者は、複雑な数字を表すためにテキストバージョンの固有の制限により、このドキュメントのHTMLまたはPDFバージョンを読むことを推奨しています。
The "Terminology" (Section 3.1) section should be used as a supporting reference as the document is read.
「用語」（セクション3.1）セクションは、ドキュメントが読み取られるときにサポートリファレンスとして使用する必要があります。
The indications of direction (i.e., "top", "bottom", etc.) referenced in Section 1 are of paramount importance. RIFT requires a topology with a sense of top and bottom in order to properly achieve a sorted topology. Clos, fat tree, and other similarly structured networks are conducive to such requirements. Where RIFT allows for further relaxation of these constraints will be mentioned later in this section.
セクション1で参照されている方向（つまり、「トップ」、「下」など）の適応が最も重要です。Riftには、ソートされたトポロジを適切に達成するために、上部と下部の感覚を持つトポロジーが必要です。クロス、ファットツリー、およびその他の同様の構造化されたネットワークは、そのような要件を助長します。Riftにより、これらの制約をさらに緩和できる場合、このセクションの後半で説明します。
Several of the images in this document are annotated with "northern view" or "southern view" to indicate perspective to the reader. A "northern view" should be interpreted as "from the top of the fabric looking down", whereas "southern view" should be interpreted as "from the bottom looking up".
このドキュメントの画像のいくつかは、読者に視点を示すために「ノーザンビュー」または「南ビュー」が注釈されています。「ノーザンビュー」は「下を見下ろす布の上部から」と解釈されるべきであり、「南ビュー」は「底から」と解釈する必要があります。
Operators and implementors alike must decide whether multi-plane IP fabrics are of interest for them. Section 3.2 illustrates an example of both single-plane in Figure 2 and multi-plane fabric in Figure 3. Multi-plane fabrics require understanding of additional RIFT concepts (e.g., negative disaggregation in Section 6.5.2) that are unnecessary in the context of fabrics consisting of a single-plane only. "Overview" (Section 5) and "Generalized Topology View" (Section 5.2) aim to provide enough context to determine if multi-plane fabrics are of interest to the reader. "Fallen Leaf Problem" (Section 5.3) and additionally Sections 5.4 and 5.5 describe further considerations that are specific to multi-plane fabrics.
オペレーターと実装者は、マルチプレーンIPファブリックが彼らにとって興味深いかどうかを決定する必要があります。セクション3.2は、図2の単一平面と図3のマルチプレーンファブリックの両方の例を示しています。マルチプレーンファブリックは、単一平面のみで構成されるファブリックのコンテキストでは不要な追加のリフト概念（セクション6.5.2の負の分解）を理解する必要があります。「概要」（セクション5）および「一般化されたトポロジビュー」（セクション5.2）は、マルチプレーンファブリックが読者にとって興味深いかどうかを判断するのに十分なコンテキストを提供することを目的としています。「葉の問題」（セクション5.3）、さらにセクション5.4および5.5は、マルチプレーンファブリックに固有のさらなる考慮事項について説明します。
The fundamental protocol concepts are described starting in "Specification" (Section 6), but some subsections are less relevant unless the protocol is being implemented. The protocol transport (Section 6.1) is of particular importance for two reasons. First, it introduces RIFT's packet format content in the form of a normative Thrift [thrift] model given in Section 7.3, which is carried in an according security envelope as described in Section 6.9.3. Second, the Thrift model component is a prerequisite to understanding the RIFT's inherent security features as defined in both "Security" (Section 6.9) and "Security Considerations" (Section 9). The normative schema defining the Thrift model can be found in Sections 7.2 and 7.3. Furthermore, while a detailed understanding of Thrift [thrift] and the model is not required unless implementing RIFT, they may provide additional useful information for other readers.
基本的なプロトコルの概念は、「仕様」（セクション6）から始まりますが、プロトコルが実装されていない限り、一部のサブセクションは関連性が低くなります。プロトコル輸送（セクション6.1）は、2つの理由で特に重要です。まず、セクション6.9.3で説明されているように、セキュリティエンベロープで掲載されているセクション7.3に記載されている規範的なリリフト[スリフト]モデルの形で、Riftのパケット形式コンテンツを導入します。第二に、Thriftモデルコンポーネントは、「セキュリティ」（セクション6.9）と「セキュリティ上の考慮事項」（セクション9）の両方で定義されているRiftの固有のセキュリティ機能を理解するための前提条件です。Thriftモデルを定義する規範的スキーマは、セクション7.2および7.3に記載されています。さらに、Riftを実装しない限り、Thrift [Thrift]とモデルの詳細な理解は必要ありませんが、他の読者に追加の有用な情報を提供する場合があります。
If implementing RIFT to support multi-plane topologies, Section 6 should be reviewed in its entirety in conjunction with the previously mentioned Thrift schemas. Sections not relevant to single-plane implementations will be noted later in this section.
マルチプレーントポロジをサポートするためにRIFTを実装する場合、前述のThriftスキーマと併せてセクション6を完全にレビューする必要があります。このセクションの後半では、単一平面の実装に関連しないセクションについて説明します。
All readers dealing with implementation of the protocol should pay special attention to the Link Information Element (LIE) definitions (Section 6.2) as it not only outlines basic neighbor discovery and adjacency formation but also provides necessary context for RIFT's optional Zero Touch Provisioning (ZTP) (Section 6.7) and miscabling detection capabilities that allow it to automatically detect and build the underlay topology with basically no configuration. These specific capabilities are detailed in Section 6.7.
プロトコルの実装を扱うすべての読者は、基本的な近隣の発見と隣接の形成の概要を説明するだけでなく、Riftのオプションのゼロタッチプロビジョニング（ZTP）（セクション6.7）とそれを自動的に検出し、基礎トポロジーを自動的に検出し、基礎となるトポロジーを自動的に検出して構築するために必要なコンテキストを提供するため、リンク情報要素（嘘）定義（セクション6.2）に特別な注意を払う必要があります。これらの特定の機能については、セクション6.7で詳しく説明しています。
For other readers, the following sections provide a more detailed understanding of the fundamental properties and highlight some additional benefits of RIFT, such as link-state packet formats, efficient flooding, synchronization, loop-free path computation, and link-state database maintenance (see Sections 6.3, 6.3.2, 6.3.3, 6.3.4, 6.3.6, 6.3.7, 6.3.8, 6.4, 6.4.1, 6.4.2, 6.4.3, and 6.4.4). RIFT's ability to perform weighted unequal-cost load balancing of traffic across all available links is outlined in Section 6.8.7 with an accompanying example.
他の読者の場合、次のセクションでは、基本的な特性のより詳細な理解を提供し、リンク状態パケット形式、効率的な洪水、同期、ループフリーパス計算、リンク状態のデータベースメンテナンスなど、Riftの追加の利点を強調しています（セクション6.3、6.3.2、6.3.3、6.3.4、6.3.6、6.3.7、6.8、6.4、6.4.1、6.4.1。6.4.4）。利用可能なすべてのリンクにわたるトラフィックの加重不等コストの負荷分散を実行するRiftの機能は、セクション6.8.7に概説されています。
Section 6.5 is the place where the single-plane vs. multi-plane requirement is explained in more detail. For those interested in single-plane fabrics, only Section 6.5.1 is required. For the multi-plane-interested reader, Sections 6.5.2, 6.5.2.1, 6.5.2.2, and 6.5.2.3 are also mandatory. Section 6.6 is especially important for any multi-plane-interested reader as it outlines how the Routing Information Base (RIB) and Forwarding Information Base (FIB) are built via the disaggregation mechanisms but also illustrates how they prevent defective routing decisions that cause traffic loss in both single-plane or multi-plane topologies.
セクション6.5は、単一平面対マルチプレーンの要件をより詳細に説明する場所です。単一平面ファブリックに興味がある人には、セクション6.5.1のみが必要です。マルチプレーンに元気を付けられたリーダーの場合、セクション6.5.2、6.5.2.1、6.5.2.2、および6.5.2.3も必須です。セクション6.6は、ルーティング情報ベース（RIB）と転送情報ベース（FIB）が分解メカニズムを介して構築される方法を概説しているため、マルチプレーンの格付けされたリーダーにとって特に重要です。また、単一平面トポロジーまたはマルチプレーンの両方のトポロジーの両方のトラフィックの損失を引き起こす欠陥のあるルーティング決定を防ぐ方法も示しています。
Appendix B contains a set of comprehensive examples that show how RIFT contains the impact of failures to only the required set of nodes. It should also help cement some of RIFT's core concepts in the reader's mind.
付録Bには、Riftが必要なノードのセットのみに障害の影響をどのように含むかを示す一連の包括的な例が含まれています。また、読者の心の中で、Riftのコア概念のいくつかを固めるのに役立つはずです。
Last but not least, RIFT has other optional capabilities. One example is the key-value datastore, which enables RIFT to advertise data post-convergence in order to bootstrap higher levels of functionality (e.g., operational telemetry). Those are covered in Section 6.8.
最後になりましたが、Riftには他のオプションの機能があります。1つの例は、キー価値のデータストアです。これにより、Riftは、より高いレベルの機能（運用テレメトリなど）をブートストラップするために、コンバージェンス後のデータを宣伝できます。それらはセクション6.8でカバーされています。
More information related to RIFT can be found in the "RIFT Applicability" [RFC9696] document, which discusses alternate topologies upon which RIFT may be deployed, describes use cases where it is applicable, and presents operational considerations that complement this document. "RIFT Day One" [DayOne] covers some practical details of existing RIFT implementations and deployment details.
Riftに関連する詳細情報は、Riftが展開される可能性のある代替トポロジについて説明し、適用可能なユースケースを説明し、このドキュメントを補完する運用上の考慮事項を説明する「RFC9696]ドキュメントに記載されています。「Rift Day One」[DayOne]は、既存のRIFT実装と展開の詳細の実際の詳細について説明します。
This section presents the terminology used in this document.
このセクションでは、このドキュメントで使用されている用語を示します。
Bandwidth Adjusted Distance (BAD):
帯域幅調整距離（悪い）：
Each RIFT node can calculate the amount of northbound bandwidth available towards a node compared to other nodes at the same level and can modify the route distance accordingly to allow for the lower level to adjust their load balancing towards spines.
各リフトノードは、同じレベルの他のノードと比較してノードに向けて利用可能な北行きの帯域幅の量を計算し、それに応じてルート距離を変更して、低レベルがスパインに向かって負荷分散を調整できるようにすることができます。
Bidirectional Adjacency:
双方向の隣接：
Bidirectional adjacency is an adjacency where nodes of both sides of the adjacency advertised it in the Node TIEs with the correct levels and System IDs. Bidirectionality is used to check in different algorithms whether the link should be included.
双方向の隣接は、隣接する両側のノードが正しいレベルとシステムIDと結びついて宣伝する隣接です。双方向性は、リンクを含めるべきかどうかを異なるアルゴリズムをチェックするために使用されます。
Bow-tying:
弓のように：
Traffic patterns in fully converged IP fabrics normally traverse the shortest route based on hop count towards their destination (e.g., leaf, spine, leaf). Some failure scenarios with partial routing information cause nodes to lose the required downstream reachability to a destination and force traffic to utilize routes that traverse higher levels in the fabric in order to turn south again using a different route to resolve reachability (e.g., leaf, spine-1, superspine, spine-2, leaf).
完全に収束したIPファブリックの交通パターンは、通常、目的地（葉、背骨、葉など）に向けてホップ数に基づいて最短ルートを横断します。部分的なルーティング情報を備えたいくつかの障害シナリオにより、ノードは必要な下流の到達可能性を宛先に失い、トラフィックを強制して、別のルートを使用して再び南に曲がるために到達可能性（葉、脊椎、仰向け、脊椎2、葉など）を再び南に回すために、ファブリックのより高いレベルを通過するルートを利用します。
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 L2L shortcuts and multi-level shortcuts are possible and described further in the document.
このドキュメントでは、「クローズ」と「脂肪ツリー」という用語を交換可能に使用します。これは、常に折りたたまれた脊椎と葉トポロジを指し、おそらく複数の配信ポイント（ポッド）と1つまたは複数の布地（TOF）飛行機を指します。L2Lショートカットやマルチレベルのショートカットなどのいくつかの変更が可能であり、ドキュメントでさらに説明されています。
Cost:
料金：
A natural number without a unit associated with a single entity. The cost is a monoid under addition. A cost may be associated with either a single link or prefix, or it may represent the sum of costs (distance) of links in the path between two nodes.
単一のエンティティに関連付けられたユニットのない自然数。コストは追加されているモノイドです。コストは、単一のリンクまたはプレフィックスのいずれかに関連付けられている場合があります。または、2つのノード間のパス内のリンクのコスト（距離）の合計（距離）を表す場合があります。
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 vice versa, each of two such 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.
ノードがより具体的な接頭辞を南に宣伝することを決定したプロセスは、対応するトラフィックを引き付けるか、それを撃退するために否定的に積極的に宣伝することを決定します。より具体的なプレフィックスへのトラフィックの損失と最適ではないルーティングを防ぐために、分解が実行されます。
Distance:
距離：
The sum of costs (bound by the infinite cost constant) between two nodes. A distance is primarily used to express separation between two entities and can be used again as cost in another context.
2つのノード間のコストの合計（無限コスト定数）。距離は主に2つのエンティティ間の分離を表すために使用され、別のコンテキストでコストとして再び使用できます。
East-West (E-W) Link:
East-West（E-W）リンク：
A link between two nodes at the same level. East-West links are normally not part of Clos or fat tree topologies.
同じレベルの2つのノード間のリンク。通常、東西リンクは、クローズまたはファットツリートポロジの一部ではありません。
Flood Repeater (FR):
洪水リピーター（FR）：
A node can designate one or more northbound neighbor nodes to be flood repeaters. The flood repeaters are responsible for flooding northbound TIEs further north. The document sometimes calls them flood leaders as well.
ノードは、1つまたは複数の北行きの隣接ノードを洪水リピーターに指定できます。洪水の繰り返しは、北行きのネクタイをさらに北に浸水させる責任があります。この文書は、時々彼らを洪水の指導者と呼んでいます。
Folded Spine-and-Leaf:
折り畳まれた背骨と葉：
In case the Clos fabric input and output stages are equivalent, the fabric can be "folded" to build a "superspine" or top, which is called the ToF in this document.
クローファブリックの入力と出力段階が同等の場合、このドキュメントのTOFと呼ばれる「超驚異」または上部を構築するために、ファブリックを「折りたたんだ」ことができます。
Interface:
インタフェース：
A layer 3 entity over which RIFT control packets are exchanged.
Rift Controlパケットが交換されるレイヤー3エンティティ。
Key Value (KV) TIE:
キー値（kv）タイ：
A TIE that is carrying a set of key value pairs [DYNAMO]. It can be used to distribute non-topology-related information within the protocol.
キー値のペアのセット[ダイナモ]を運ぶネクタイ。これは、プロトコル内で非トポロジー関連情報を配布するために使用できます。
Leaf-to-Leaf (L2L) Shortcuts:
葉から葉（L2L）ショートカット：
East-West links at leaf level will need to be differentiated from East-West links at other levels.
リーフレベルの東西リンクは、他のレベルの東西リンクと区別する必要があります。
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である必要はありません。
Level:
レベル：
Clos and fat tree networks are topologically partially ordered graphs, and "level" denotes the set of nodes at the same height in such a network. Nodes at the top level (i.e., ToF) are at the level with the highest value and count down to the nodes at the bottom level (i.e., leaf) with the lowest value. A node will have links to nodes one level down and/or one level up. In some circumstances, a node may have links to other nodes at the same level. A leaf node may also have links to nodes multiple levels higher. In RIFT, level 0 always indicates that a node is a leaf but does not have to be level 0. Level values can be configured manually or automatically as described in Section 6.7.
クローズとファットツリーネットワークは、トポロジー的に部分的に順序付けられたグラフであり、「レベル」は、そのようなネットワークの同じ高さのノードのセットを示します。上部レベルのノード（つまり、TOF）は最高値のレベルで、最低値の下部レベル（つまり葉）のノードにカウントダウンします。ノードには、1レベルダウンおよび/または1つのレベルアップノードへのリンクがあります。状況によっては、ノードには同じレベルの他のノードへのリンクがある場合があります。リーフノードには、複数のレベルが高いノードへのリンクがある場合があります。Riftでは、レベル0は常にノードが葉であるが、レベル0である必要はないことを示します。レベル値は、セクション6.7で説明されているように手動または自動的に構成できます。
As a final footnote: Clos terminology often uses the concept of "stage", but due to the folded nature of the fat tree, it is not used from this point on to prevent misunderstandings.
最終的な脚注として：クロス用語はしばしば「ステージ」の概念を使用しますが、脂肪木の折りたたみの性質のために、誤解を防ぐためにこの時点から使用されません。
LIE:
LIE:
This is an acronym for a "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を実行しているすべてのシステムのリンクで交換される「リンク情報要素」の頭字語です。
Metric:
メトリック：
Used interchangeably with "cost".
「コスト」と同じ意味で使用されます。
Neighbor:
近所の人：
Once a _ThreeWay_ adjacency has been formed, a neighborship relationship contains the neighbor's properties. Multiple adjacencies can be formed to a remote node via parallel point-to-point interfaces, but such adjacencies are *not* sharing a neighbor structure. Saying "neighbor" is thus equivalent to saying "a _ThreeWay_ adjacency".
_threeway_隣接が形成されると、隣人の関係には隣人のプロパティが含まれています。複数の隣接は、並列ポイントツーポイントインターフェイスを介してリモートノードに形成できますが、そのような隣接は隣接構造を共有していません。したがって、「隣人」と言うことは、「_threeway_隣接」と言うことと同等です。
Node TIE:
ノードタイ：
This is an acronym for a "Node Topology Information Element", which contains all adjacencies the node discovered and information about the node itself. Node TIE should not be confused with a North TIE since "node" defines the type of TIE rather than its direction. Consequently, North Node TIEs and South Node TIEs exist.
これは、「ノードトポロジ情報要素」の頭字語です。これには、ノードが発見したすべての隣接とノード自体に関する情報が含まれています。「ノード」はその方向ではなくタイのタイプを定義するため、ノードタイを北のネクタイと混同しないでください。その結果、北ノードのタイとサウスノードタイが存在します。
North SPF (N-SPF):
North SPF（N-SPF）：
A reachability calculation that is progressing northbound, for example, SPF that is using South Node TIEs only. Normally it progresses by only a single hop and installs default routes.
たとえば、北に向かって進行している到達可能性計算、たとえば、南ノードタイのみを使用しているSPF。通常、1回のホップで進行し、デフォルトルートをインストールします。
Northbound Link:
ノースバウンドリンク：
A link to a node one level up or, in other words, one level further north.
ノードへのリンク1レベルアップまたは、言い換えれば、さらに北に1レベル。
Northbound Representation:
北行きの表現：
The subset of topology information flooded towards higher levels of the fabric.
トポロジー情報のサブセットは、より高いレベルのファブリックに浸水しました。
Overloaded:
過負荷：
Applies to a node advertising the _overload_ attribute as set. The overload attribute is carried in the _NodeFlags_ object of the encoding schema.
_Overload_属性を設定して_Overload_属性を広告するノードに適用します。オーバーロード属性は、エンコードスキーマの_NodeFlags_オブジェクトに配置されます。
Point of Delivery (PoD):
配達ポイント（POD）：
A self-contained vertical slice or subset of a Clos or fat tree network normally containing only level 0 and level 1 nodes. A node in a PoD communicates with nodes in other PoDs via the ToF nodes. PoDs are numbered to distinguish them, and PoD value 0 (defined later in the encoding schema as _common.default_pod_) is used to denote "undefined" or "any" PoD.
通常、レベル0およびレベル1のノードのみを含む、クローズまたはファットツリーネットワークの自己完結型の垂直スライスまたはサブセット。ポッド内のノードは、TOFノードを介して他のポッドのノードと通信します。ポッドにはそれらを区別するために番号が付けられており、ポッド値0（_common.default_pod_としてエンコードスキーマの後半で定義）は、「未定義」または「任意の」ポッドを示すために使用されます。
Prefix TIE:
プレフィックスタイ：
This is an acronym for a "Prefix Topology Information Element", and it contains all prefixes directly attached to this node in case of a North TIE and the necessary default routes the node advertises southbound in case of a South TIE.
これは「プレフィックストポロジ情報要素」の頭字語であり、北ネクタイと必要なデフォルトルートの場合にこのノードに直接接続されたすべてのプレフィックスが含まれています。
Radix:
基数：
A radix of a switch is the number of switching ports it provides. It's sometimes called "fanout" as well.
スイッチの基数は、提供するスイッチングポートの数です。「ファンアウト」とも呼ばれることもあります。
Routing on the Host (RotH):
ホストのルーティング（ロス）：
A modern data center architecture variant where servers/leaves are multihomed and consequently participate in routing.
サーバー/葉がマルチホームされ、その結果、ルーティングに参加する最新のデータセンターアーキテクチャバリアント。
Security Envelope:
セキュリティエンベロープ：
RIFT packets are flooded within an authenticated security envelope that optionally enables protection of the integrity of information a node accepts if any of the mechanisms in Section 10.2 are used. This is further described in Section 6.9.3.
リフトパケットは、セクション10.2のメカニズムのいずれかが使用されている場合、ノードが受け入れる情報の整合性をオプションで保護できる認証されたセキュリティエンベロープ内に浸水します。これについては、セクション6.9.3でさらに説明します。
Shortest Path First (SPF):
最短パスファースト（SPF）：
A well-known graph algorithm attributed to Dijkstra [DIJKSTRA] that establishes a tree of shortest paths from a source to destinations on the graph. The SPF acronym is used due to its familiarity as a general term for the node reachability calculations RIFT can employ to ultimately calculate routes, of which Dijkstra's algorithm is a possible one.
ソースからグラフ上の目的地まで、最短パスの木を確立するDijkstra [Dijkstra]に起因するよく知られているグラフアルゴリズム。SPFの頭字語は、Node Reachability計算の一般的な用語として、Riftが最終的にルートを計算するために使用できるため、その親しみのために使用されます。Dijkstraのアルゴリズムは可能です。
South Reflection:
南リフレクション：
Often abbreviated just as "reflection", it defines a mechanism where South Node TIEs are "reflected" from the level south back up north to allow nodes in the same level without E-W links to be aware of each other's node Topology Information Elements (TIEs).
多くの場合、「反射」と同じように省略され、南ノードの結びつきが北に戻るレベルから「反射」され、E-Wリンクなしで同じレベルのノードが互いのノードトポロジ情報要素（TIE）を認識できるようにするメカニズムを定義します。
South SPF (S-SPF):
South SPF（S-SPF）：
A reachability calculation that is progressing southbound, for example, SPF that is using North Node TIEs only.
たとえば、南行きの到達可能性計算、たとえば、ノースノードタイのみを使用しているSPF。
South/Southbound and North/Northbound (Direction):
南/南行き、北/北行き（方向）：
When describing protocol elements and procedures, in different situations, the directionality of the compass is used, i.e., "lower", "south", and "southbound" mean moving towards the bottom of the Clos or fat tree network and "higher", "north", and "northbound" mean moving towards the top of the Clos or fat tree network.
プロトコルの要素と手順を説明する場合、さまざまな状況で、コンパスの方向性、つまり「低」、「南」、および「南行きの」とは、クローズまたはファットツリーネットワークの底部に向かって移動し、「より高い」、「北」、および「北行き」とは、クローズまたはファットツリーネットワークの上部に向かって移動することを意味します。
Southbound Link:
サウスバウンドリンク：
A link to a node one level down or, in other words, one level further south.
1レベルダウンまたは言い換えれば、さらに南に1レベルのノードへのリンク。
Southbound Representation:
南行きの表現：
The subset of topology information sent towards a lower level.
トポロジー情報のサブセットは、より低いレベルに送られました。
Spine:
脊椎：
Any nodes north of leaves and south of ToF nodes. Multiple layers of spines in a PoD are possible.
葉の北とTOFノードの南にあるノード。ポッド内の棘の複数の層が可能です。
Superspine, Aggregation/Spine, and Edge/Leaf Switches:
スーパースパイン、集約/脊椎、およびエッジ/リーフスイッチ：
Typical level names in 5 stages folded Clos for levels 2, 1, and 0, respectively (counting up from the bottom). We normalize this language to talk about ToF, Top-of-Pod (ToP), and leaves.
それぞれレベル2、1、および0の場合、5段階の典型的なレベル名が折りたたまれています（下からカウントアップ）。この言語を正規化して、TOF、トップポッド（上）、および葉について話します。
System ID:
システムID：
RIFT nodes identify themselves with a unique network-wide number when trying to build adjacencies or describe their topology. RIFT System IDs can be auto-derived or configured.
Riftノードは、隣接を構築しようとしたり、トポロジを説明しようとするときに、一意のネットワーク全体の数字で自分自身を識別します。RIFTシステムIDは、自動由来または構成できます。
ThreeWay Adjacency:
3ウェイの隣接：
RIFT tries to form a unique adjacency between two nodes over a point-to-point interface and exchange local configuration and necessary RIFT ZTP information. An adjacency is only advertised in Node TIEs and used for computations after it achieved _ThreeWay_ state, i.e., both routers reflected each other in LIEs, including relevant security information. Nevertheless, LIEs before _ThreeWay_ state is reached may already carry information related to RIFT ZTP.
Riftは、ポイントツーポイントインターフェイスで2つのノード間に一意の隣接を形成し、ローカル構成と必要なRift ZTP情報を交換しようとします。隣接はノードタイでのみ宣伝され、_threeway_状態を達成した後、計算に使用されます。つまり、両方のルーターが関連するセキュリティ情報を含む嘘に互いに反映されました。それにもかかわらず、_threeway_状態が到達する前にある嘘は、すでにRift ZTPに関連する情報を運ぶ可能性があります。
TIDE:
潮：
The Topology Information Description Element carries descriptors of the TIEs stored in the node.
トポロジ情報の説明要素には、ノードに保存されているネクタイの記述子が付いています。
TIE:
TIE:
This is an acronym for a "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 are used (sometimes abbreviated as S-TIEs) for the southbound equivalent. TIEs have different types, such as node and prefix TIEs.
これは、「トポロジ情報要素」の頭字語です。タイはリフトノード間で交換され、リンクやアドレスのプレフィックスなどのネットワークの一部を説明します。ネクタイには常に方向とタイプがあります。北のネクタイ（N-Tiesとして略されることもあります）は、北行きの表現での関係を扱うときに使用され、南に同等のサウスタイが使用されます（S-Tiesとして略されることもあります）。ネクタイには、ノードやプレフィックスタイなど、さまざまなタイプがあります。
TIEDB:
Tiedb：
The database holding the newest versions of all TIE headers (and the corresponding TIE content if it is available).
すべてのタイヘッダーの最新バージョンを保持しているデータベース（および使用可能な場合は対応するタイコンテンツ）。
TIRE:
タイヤ：
The Topology Information Request Element carries a set of TIDE descriptors. It can both confirm received and request missing TIEs.
トポロジ情報リクエスト要素には、潮の記述子のセットがあります。受信したことを確認し、不足している関係を要求できます。
Top of Fabric (ToF):
生地の上部（TOF）：
The set of nodes that provide inter-PoD communication and have no northbound adjacencies, i.e., are at the "very top" of the fabric. ToF nodes do not belong to any PoD and are assigned the _common.default_pod_ PoD value to indicate the equivalent of "any" PoD.
ポッド間通信を提供し、北行きの隣接を持たないノードのセット、つまり、ファブリックの「非常に上部」にあります。TOFノードは任意のポッドに属しておらず、_common.default_pod_ pod値に割り当てられて、「任意の」ポッドに相当するものを示します。
Top of PoD (ToP):
ポッドの上部（上）：
The set of nodes that provide intra-PoD communication and have northbound adjacencies outside of the PoD, i.e., are at the "top" of the PoD.
ポッド内通信を提供し、ポッドの外側に北行きの隣接を持つノードのセット、つまり、ポッドの「上」にあります。
ToF Plane or Partition:
TOFプレーンまたはパーティション：
In large fabrics, ToF switches may not have enough ports to aggregate all switches south of them, and with that, the ToF is "split" into multiple independent planes. Section 5.2 explains the concept in more detail. A plane is a subset of ToF nodes that are aware of each other through south reflection or E-W links.
大きなファブリックでは、TOFスイッチにはすべてのスイッチを南に集約するのに十分なポートがない場合があり、それにより、TOFは複数の独立した平面に「分割」されます。セクション5.2では、概念をより詳細に説明します。平面は、南反射またはE-Wリンクを通じて互いに認識しているTOFノードのサブセットです。
Valid LIE:
有効な嘘：
LIEs undergo different checks to determine their validity. The term "valid LIE" is used to describe a LIE that can be used to form or maintain an adjacency. The amount of checking itself depends on the Finite State Machine (FSM) involved and its state. A "minimally valid LIE" is a LIE that passes checks necessary on any FSM in any state. A "ThreeWay valid LIE" is a LIE that successfully underwent further checks with a LIE FSM in _ThreeWay_ state. A minimally valid LIE is a subcategory of a _ThreeWay_ valid LIE.
嘘は異なるチェックを受けて、その有効性を判断します。「有効な嘘」という用語は、隣接を形成または維持するために使用できる嘘を説明するために使用されます。チェック自体の量は、関連する有限状態マシン（FSM）とその状態に依存します。「最小限の有効な嘘」とは、どの状態のFSMに必要なチェックに合格する嘘です。「3ウェイの有効な嘘」は、_threeway_状態の嘘fsmでさらにチェックを受けた嘘です。最小限の有効な嘘は、_threeway_有効な嘘のサブカテゴリです。
RIFT Zero Touch Provisioning (abbreviated as RIFT ZTP or just ZTP):
Rift Zero Touch Provisioning（Rift ZTPまたは単なるZTPとして略されます）：
An optional RIFT mechanism that allows the automatic derivation of node levels based on minimum configuration, as detailed in Section 6.7. Such a minimum configuration consists solely of ToFs being configured as such. RIFT ZTP contains a recommendation for automatic collision-free derivation of the System ID as well.
セクション6.7で詳述されているように、最小構成に基づいてノードレベルの自動導出を可能にするオプションのRIFTメカニズム。このような最小構成は、そのように構成されているTOFのみで構成されています。Rift ZTPには、システムIDの自動衝突のない導出の推奨が含まれています。
Additionally, when the specification refers to elements of packet encoding or the constants provided in Section 7, a special emphasis is used, e.g., _invalid_distance_. The same convention is used when referring to finite state machine states or events outside the context of the machine itself, e.g., _OneWay_.
さらに、仕様がパケットエンコードの要素またはセクション7で提供されている定数を指す場合、_invalid_distance_など、特別な強調が使用されます。同じ規則は、マシン自体のコンテキスト外の有限状態マシンの状態またはイベント、例えば_oneway _を参照する場合に使用されます。
^ N +--------+ +--------+
Level 2 | |ToF 21| |ToF 22|
W <-*-> E ++-+--+-++ ++-+--+-++
| | | | | | | | |
S v P111/2 P121/2 | | | |
MHP MHP | | | |
^ ^ ^ ^ | | | |
| | | | | | | |
+--------------+ | +-----------+ | | | +---------------+
| | | | | | | |
| +-----------------------------+ | | ^
| | | | | | | All
0/0 0/0 0/0 +-----------------------------+ TIEs
v v v | | | | |
| | +-+ +<-0/0----------+ | |
| | | | | | | |
+-+----++ Optional +-+----++ ++----+-+ ++-----++
Level 1 | | E/W Link | | | | | |
|Spin111+----------+Spin112| |Spin121| |Spin122|
+-+---+-+ ++----+-+ +-+---+-+ ++---+--+
| | | | | | | |
| +---0/0--->-----+ 0/0 | +----------------+ |
0/0 | | | | | | |
| +---<-0/0-----+ | v | +--------------+ | |
v | | | | | | |
+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+
Level 0 | | L2L | | | | | |
|Leaf111+~~~~~~~~~~+Leaf112| |Leaf121| |Leaf122|
+-+-----+ +-+---+-+ +--+--+-+ +-+-----+
+ + \ / + +
Prefix111 Prefix112 \ / Prefix121 Prefix122
Multi-homed
Prefix
+---------- PoD 1 ---------+ +---------- PoD 2 ---------+
Figure 2: A Three-Level Spine-and-Leaf Topology
図2：3レベルの背骨と葉トポロジ
The topology in Figure 2 is referred to in all further considerations. This figure depicts a generic "single-plane fat tree" and the concepts explained using three levels apply by induction to further levels and higher degrees of connectivity.
図2のトポロジは、すべてのさらなる考慮事項で言及されています。この図は、一般的な「シングル面脂肪ツリー」を描写しており、概念は、誘導により、さらに高いレベルとより高い接続度に適用される3つのレベルを使用して説明されています。
(Artwork only available as SVG: see
https://www.rfc-editor.org/rfc/rfc9692.html)
Figure 3: Topology with Multiple Planes
図3：複数の平面を持つトポロジー
Further, this document will also deal with designs that provide only sparser connectivity and "partitioned spines", as shown in Figure 3 and explained further in Section 5.2.
さらに、このドキュメントでは、図3に示すように、セクション5.2でさらに説明するように、まばらな接続と「分割された棘」のみを提供する設計も扱います。
The remainder of this document presents the detailed specification of the RIFT protocol, which in the most abstract terms has many properties of a modified link-state protocol when distributing information northbound and a distance-vector protocol when distributing information southbound. While this is an unusual combination, it does quite naturally exhibit desired properties.
このドキュメントの残りの部分は、リフトプロトコルの詳細な仕様を提示します。これは、最も抽象的な用語では、情報を北に分配するときに修正されたリンク状態プロトコルの多くのプロパティと、南行きの情報を配布するときに距離ベクトルプロトコルの多くのプロパティを備えています。これは珍しい組み合わせですが、非常に自然に望ましい特性を示します。
The most singular property of RIFT is that it only floods link-state information northbound so that each level obtains the full topology of levels south of it. Link-State information is, with some exceptions, not flooded East-West nor back south again. Exceptions like south reflection is explained in detail in Section 6.5.1, and east-west flooding at the ToF level in multi-plane fabrics is outlined in Section 5.2. In the southbound direction, the necessary routing information required (normally just a default route as per Section 6.3.8) only propagates one hop south. Those nodes then generate their own routing information and flood it south to avoid the overhead of building an update per adjacency. The East-West direction is described later in the document.
Riftの最も特異な特性は、各レベルがその南のレベルの完全なトポロジーを取得できるように、リンク状態情報を北にflood濫させることです。リンク状態の情報は、いくつかの例外を除いて、東西に浸水したり、南に戻ったりすることはありません。South Reflectionなどの例外については、セクション6.5.1で詳細に説明しており、マルチプレーンファブリックのTOFレベルでの東西洪水については、セクション5.2で概説しています。南行きの方向では、必要なルーティング情報（通常はセクション6.3.8に従ってデフォルトルートのみ）が1つのホップ南部のみを伝播します。次に、これらのノードは独自のルーティング情報を生成し、隣接ごとに更新を構築するオーバーヘッドを回避するために南にあふれます。東西の方向については、文書の後半で説明します。
Those information flow constraints create not only an anisotropic protocol (i.e., the information is not distributed "evenly" or "clumped" but summarized along the north-south gradient) but also a "smooth" information propagation where nodes do not receive the same information from multiple directions at the same time. Normally, accepting the same reachability on any link, without understanding its topological significance, forces tie-breaking on some kind of distance function. And such tie-breaking ultimately leads to hop-by-hop forwarding by shortest paths only. In contrast to that, RIFT, under normal conditions, does not need to tie-break the same reachability information from multiple directions. Its computation principles (south forwarding direction is always preferred) lead to valley-free [VFR] forwarding behavior. In the shortest terms, valley-free paths allow reversal of direction from a packet heading northbound to southbound while permitting traversal of horizontal links in the northbound phase at most once. Those principles guarantee loop-free forwarding and with that can take advantage of all such feasible paths on a fabric. This is another highly desirable property if available bandwidth should be utilized to the maximum extent possible.
これらの情報フローの制約は、異方性プロトコル（つまり、情報が「均等に」または「凝集」されるのではなく、南北勾配に沿って要約される）だけでなく、同時に複数の方向から同じ情報をノードが受け取らない「スムーズな」情報伝播も作成します。通常、リンクで同じ到達可能性を受け入れることは、そのトポロジの重要性を理解せずに、何らかの距離関数を結び付けます。そして、そのようなタイブレイクは、最終的には最短のパスによるホップバイホップの転送につながります。それとは対照的に、Riftは通常の条件下で、複数の方向から同じ到達可能性情報を結び付ける必要はありません。その計算原理（南の転送方向が常に推奨されています）は、谷間のない[VFR]転送挙動につながります。最短言語では、谷のないパスにより、北に向かって北に向かうパケットから南行きに向かう方向の逆転が可能になり、最大で最大で最大で水平リンクを横断することができます。これらの原則は、ループフリーの転送を保証し、それに伴い、ファブリック上のすべての実行可能なパスを利用できます。これは、利用可能な帯域幅を可能な限り最大限に活用する必要がある場合、もう1つの非常に望ましいプロパティです。
To account for the "northern" and the "southern" information split, the link state database (LSDB) is partitioned accordingly into "north representation" and "south representation" Topology Information Elements (TIEs). In the simplest terms, the North TIEs contain a link-state topology description of lower levels and South TIEs simply carry a node description of the level above and default routes pointing north. This oversimplified view will be refined gradually in the following sections while introducing protocol procedures and state machines at the same time.
「ノーザン」と「南」情報分割を説明するために、リンク状態データベース（LSDB）は、それに応じて「北の表現」および「南代表」トポロジ情報要素（TIE）に分割されます。最も簡単に言えば、北のタイには、より低いレベルと南タイのリンク状態トポロジの説明が含まれています。上のレベルのノードの説明と北を指すデフォルトルートがあります。この単純化されたビューは、次のセクションで徐々に洗練され、同時にプロトコル手順と状態マシンを導入します。
This section and Section 6.5.2 are dedicated to multi-plane fabrics, in contrast with the single-plane designs where all ToF nodes are topologically equal and initially connected to all the switches at the level below them.
このセクションとセクション6.5.2は、すべてのTOFノードがトポロジカルに等しく、その下のレベルのすべてのスイッチに最初に接続されている単一平面設計とは対照的に、マルチプレーンファブリック専用です。
The multi-plane design is effectively a multidimensional switching matrix. To make that easier to visualize, this document introduces a methodology depicting the connectivity in two-dimensional pictures. Further, it can be leveraged that what is under consideration here is basically stacked crossbar fabrics where ports align "on top of each other" in a regular fashion.
マルチプレーン設計は、事実上、多次元スイッチングマトリックスです。それを視覚化しやすくするために、このドキュメントでは、2次元の写真の接続性を描いた方法論を紹介します。さらに、ここで検討中のものは、基本的に積み重ねられたクロスバーファブリックであり、ポートが通常の方法で「互いの上に」整列することです。
A word of caution to the reader: At this point, it should be observed that the language used to describe Clos variations, especially in multi-plane designs, varies widely between sources. This description follows the terminology introduced in Section 3.1. This terminology is needed to follow the rest of this section correctly.
読者への注意の言葉：この時点で、特にマルチプレーンのデザインでは、密接なバリエーションを説明するために使用される言語は、ソース間で大きく異なることが観察されるべきです。この説明は、セクション3.1で導入された用語に従います。この用語は、このセクションの残りの部分に正しく従うために必要です。
This section describes the terminology and abbreviations used in the rest of the text. Though the glossary may not be clear on a first read, the following sections will introduce the terms in their proper context.
このセクションでは、テキストの残りの部分で使用されている用語と略語について説明します。用語集は最初の読み取りでは明確ではないかもしれませんが、次のセクションでは、適切なコンテキストで用語を紹介します。
P:
P:
Denotes the number of PoDs in a topology.
トポロジ内のポッドの数を示します。
S:
S:
Denotes the number of ToF nodes in a topology.
トポロジ内のTOFノードの数を示します。
K:
K:
To simplify the visual aids, notations, and further considerations, the assumption is made that the switches are symmetrical, i.e., they have an equal number of ports pointing northbound and southbound. With that simplification, K denotes half of the radix of a symmetrical switch, meaning that the switch has K ports pointing north and K ports pointing south. K_LEAF (K of a leaf) thus represents both the number of access ports in a leaf node and the maximum number of planes in the fabric, whereas K_TOP (K of a ToP) represents the number of leaves in the PoD and the number of ports pointing north in a ToP Node towards a higher spine level and thus the number of ToF nodes in a plane.
視覚補助具、表記、およびさらなる考慮事項を簡素化するために、スイッチが対称的であるという仮定が行われます。つまり、北行きと南行きのポートが同等のポートを持っています。その単純化により、Kは対称スイッチの基数の半分を示します。つまり、スイッチには北を指すKポートとKポートが南に向かっています。したがって、k_leaf（葉のk）は、葉のノード内のアクセスポート数と生地の最大平面数の両方を表しますが、k_top（k）はポッド内の葉の数と、より高い脊椎レベルに向かって上部ノードの北を指すポートの数、したがって平面のTOF nodesの数を表します。
ToF Plane:
TOFプレーン：
Set of ToFs that are aware of each other by means of south reflection. Planes are designated by capital letters, e.g., plane A.
南反射によってお互いを認識しているTOFのセット。飛行機は大文字、たとえば飛行機Aで指定されています。
N:
N:
Denotes the number of independent ToF planes in a topology.
トポロジ内の独立したTOF平面の数を示します。
R:
R:
Denotes a redundancy factor, i.e., the number of ToP nodes in a PoD that are connected to a ToF plane. In a single-plane design, R is equal to K_LEAF.
冗長係数、つまり、TOF平面に接続されているポッドの上部ノードの数を示します。単一平面設計では、rはk_leafに等しくなります。
Fallen Leaf:
倒れた葉：
A fallen leaf in a plane Z is a switch that lost all connectivity northbound to Z.
平面Zの葉の葉は、Zに北に向かってすべての接続性を失ったスイッチです。
The typical topology for which RIFT is defined is built of P number of PoDs and connected together by S number of ToF nodes. A PoD node has 2K number of ports. From here on, half of them (K=Radix/2) are assumed to connect host devices from the south, and the other half is assumed to connect to interleaved PoD top-level switches to the north. The K ratio can be chosen differently without loss of generality when port speeds differ or the fabric is oversubscribed, but K=Radix/2 allows for more readable representation whereby there are as many ports facing north as south on any intermediate node. A node is hence represented in a schematic fashion with ports "sticking out" to its north and south, rather than by the usual real-world front faceplate designs of the day.
Riftが定義されている典型的なトポロジーは、Pの数のポッドで構築され、Sの数のTOFノードによって接続されています。ポッドノードには2kのポート数があります。ここから、それらの半分（k = radix/2）は南からホストデバイスを接続すると想定されており、残りの半分は、インターリーブされたポッドトップレベルのスイッチに北に接続すると想定されています。K比は、ポートスピードが異なる場合、またはファブリックが過剰に登録されている場合、一般性を失うことなく異なる方法で選択できますが、K = RADIX/2では、中間ノードの南と同じように多くのポートが南に面しているより多くのポートがあります。したがって、ノードは、通常の現実世界の正面のフェイスプレートデザインではなく、北と南にポートが「突き出ている」と概略的な方法で表されます。
Figure 4 provides a view of a leaf node as seen from the north, i.e., showing ports that connect northbound. For lack of a better symbol, the document chooses to use the "o" as ASCII visualization of a single port. In this example, K_LEAF has 6 ports. Observe that the number of PoDs is not related to the Radix unless the ToF nodes are constrained to be the same as the PoD nodes in a particular deployment.
図4は、北から見た葉のノードのビューを示しています。つまり、北に接続するポートを示しています。より良いシンボルがないため、ドキュメントは「O」を単一のポートのASCII視覚化として使用することを選択します。この例では、K_Leafには6つのポートがあります。PODの数は、特定の展開のポッドノードと同じに制限されている場合を除き、PODの数が基数に関連していないことを確認してください。
Top View
+---+
| |
| o | e.g., Radix = 12, K_LEAF = 6
| |
| o |
| | -------------------------
| o <------ Physical Port (Ethernet) ----+
| | ------------------------- |
| o | |
| | |
| o | |
| | |
| o | |
| | |
+---+ v
|| || || || || || ||
+----+ +------------------------------------------------+
| | | |
+----+ +------------------------------------------------+
|| || || || || || ||
Side Views
Figure 4: A Leaf Node, K_LEAF=6
図4：リーフノード、k_leaf = 6
The Radix of a PoD's top node may be different than that of the leaf node. Though, more often than not, a same type of node is used for both, effectively forming a square (K*K). In the general case, switches at the top of the PoD with K_TOP southern ports not necessarily equal to K_LEAF could be considered. For instance, in the representations below, we pick a 6-port K_LEAF and an 8-port K_TOP. In order to form a crossbar, K_TOP leaf nodes are necessary as illustrated in Figure 5.
ポッドの上部ノードの基数は、リーフノードの基数とは異なる場合があります。ただし、多くの場合、同じタイプのノードが両方に使用され、正方形（k*k）を効果的に形成します。一般的なケースでは、K_TOPサザンポートを使用してポッドの上部にあるスイッチを必ずしもK_LEAFと等しく考慮することができません。たとえば、以下の表現では、6ポートK_LEAFと8ポートK_TOPを選択します。クロスバーを形成するには、図5に示すようにK_TOPリーフノードが必要です。
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | | | | | | | | |
| O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | |
| O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | |
| O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | |
| O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | |
| O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | |
| O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Figure 5: Southern View of Leaf Nodes of a PoD, K_TOP=8
図5：ポッドの葉節の南ビュー、k_top = 8
As further visualized in Figure 6, the K_TOP leaf nodes are fully interconnected with the K_LEAF ToP nodes, providing connectivity that can be represented as a crossbar when "looked at" from the north. The result is that, in the absence of a failure, a packet entering the PoD from the north on any port can be routed to any port in the south of the PoD and vice versa. And that is precisely why it makes sense to talk about a "switching matrix".
図6でさらに視覚化したように、K_TOPリーフノードはK_LEAFトップノードと完全に相互接続されており、北から「見た」ときにクロスバーとして表現できる接続性を提供します。その結果、障害がない場合、ポートの北からポッドに入るパケットは、ポッドの南の任意のポートにルーティングでき、その逆も同様です。そして、それがまさに「切り替えマトリックス」について話すのが理にかなっている理由です。
W <---*---> E
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | | | | | | | | |
+--------------------------------------------------------+
| o o o o o o o o |
+--------------------------------------------------------+
+--------------------------------------------------------+
| o o o o o o o o |
+--------------------------------------------------------+
+--------------------------------------------------------+
| o o o o o o o o |
+--------------------------------------------------------+
+--------------------------------------------------------+
| o o o o o o o o |
+--------------------------------------------------------+
+--------------------------------------------------------+
| o o o o o o o o |<--+
+--------------------------------------------------------+ |
+--------------------------------------------------------+ |
| o o o o o o o o | |
+--------------------------------------------------------+ |
| | | | | | | | | | | | | | | | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
^ |
| |
| ---------- ----------------------- |
+----- Leaf Node Top of PoD Node (Spine) --+
---------- -----------------------
Figure 6: Northern View of a PoD's Spines, K_TOP=8
図6：ポッドの棘の北ビュー、k_top = 8
Side views of this PoD is illustrated in Figures 7 and 8.
このポッドの側面図は、図7と8に示されています。
Connecting to ToP Nodes
|| || || || || || || ||
+----------------------------------------------------------------+ N
| Top-of-PoD Node (Sideways) | ^
+----------------------------------------------------------------+ |
|| || || || || || || || *
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ |
|Leaf| |Leaf| |Leaf| |Leaf| |Leaf| |Leaf| |Leaf| |Leaf| v
|Node| |Node| |Node| |Node| |Node| |Node| |Node| |Node| S
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
|| || || || || || || ||
Connecting to Client Nodes
Figure 7: Side View of a PoD, K_TOP=8, K_LEAF=6
図7：ポッドのサイドビュー、k_top = 8、k_leaf = 6
Connecting to ToP Nodes
|| || || || || ||
+----+ +----+ +----+ +----+ +----+ +----+ N
|ToP | |ToP | |ToP | |ToP | |ToP | |ToP | ^
|Node| |Node| |Node| |Node| |Node| |Node| |
+----+ +----+ +----+ +----+ +----+ +----+ *
|| || || || || || |
+------------------------------------------------+ v
| Leaf Node (Sideways) | S
+------------------------------------------------+
Connecting to Client Nodes
Figure 8: Other Side View of a PoD, K_TOP=8, K_LEAF=6, 90-Degree Turn in E-W Plane from the Previous Figure
図8：前の図からのe-w平面のポッド、k_top = 8、k_leaf = 6、90度ターン
As a next step, observe that a resulting PoD can be abstracted as a bigger node with a number K of K_POD = K_TOP * K_LEAF, and the design can recurse.
次のステップとして、K_POD = k_top * k_leafの数字を持つ大きなノードとして、結果のポッドを抽象化できることを観察し、デザインが再発する可能性があります。
It will be critical at this point that, before progressing further, the concept and the picture of "crossed crossbars" is understood. Else, the following considerations might be difficult to comprehend.
この時点で、さらに進む前に、「クロスクロスバー」の概念と写真が理解されていることが重要です。そうでなければ、以下の考慮事項を理解するのが難しいかもしれません。
To continue, the PoDs are interconnected with each other through a ToF node at the very top or the north edge of the fabric. The resulting ToF is *not* partitioned if and only if (IIF) every ToP node is connected to every ToF node. This topology is also referred to as a single-plane configuration and is quite popular due to its simplicity. There are K_TOP ToF nodes and K_LEAF ToP nodes because each port of a ToP node connects to a different ToF node. Consequently, it will take at least P * K_LEAF ports on a ToF node to connect to each of the K_LEAF ToP nodes of the P PoDs. Figure 9 illustrates this, looking at P=3 PoDs from above and 2 sides. The large view is the one from above, with the 8 ToF of 3 * 6 ports each interconnecting the PoDs and every ToP Node being connected to every ToF node.
続行するために、ポッドは、生地の最上部または北端のTOFノードを介して互いに相互接続されています。結果のTOFは、すべてのトップノードがすべてのTOFノードに接続されている場合にのみ、および（iif）の場合にのみ、 *パーティション化されません。このトポロジーは、単一平面構成とも呼ばれ、そのシンプルさのために非常に人気があります。トップノードの各ポートが別のTOFノードに接続するため、K_TOP TOFノードとK_LEAFトップノードがあります。したがって、PoDSの各K_LEAFトップノードに接続するには、TOFノード上の少なくともP * K_LEAFポートが必要になります。図9は、これを示しており、上記と2つの辺からのp = 3ポッドを見ています。大きなビューは上からのものであり、3 * 6ポートの8つのTOFがそれぞれポッドを相互接続し、すべてのTOFノードに接続されているすべてのトップノードが接続されています。
[ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] <-----+
| | | | | | | | |
[=================================] | --------------
| | | | | | | | +----- ToF
[ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] +----- Node ---+
| -------------- |
| v
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ <-----+ +-+
| | | | | | | | | | | | | | | | | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] ------------------------- | |
[ |o| |o| |o| |o| |o| |o| |o| |o<--- Physical Port (Ethernet) | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] ------------------------- | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | |
| | | | | | | | | | | | | | | | | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] ---------- | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] <--- ToP Node --------+ | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] (Spine) | | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] ---------- | | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | | |
| | | | | | | | | | | | | | | | -+ +- +-+ v | |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | | --| |--[ ]--| |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | ----- | --| |--[ ]--| |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] +--- PoD ---+ --| |--[ ]--| |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | ----- | --| |--[ ]--| |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | | --| |--[ ]--| |
[ |o| |o| |o| |o| |o| |o| |o| |o| ] | | --| |--[ ]--| |
| | | | | | | | | | | | | | | | -+ +- +-+ | |
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Figure 9: Fabric Spines and ToFs in Single-Plane Design, 3 PoDs
図9：シングルプレーンデザインの生地の棘とTOF、3つのポッド
The top view can be collapsed into a third dimension where the hidden depth index is representing the PoD number. One PoD can be shown then as a class of PoDs and hence save one dimension in the representation. The ToF node expands in the depth and the vertical dimensions, whereas the ToP nodes are constrained in the horizontal dimension. A port in the 2-D representation effectively represents the class of all the ports at the same position in all the PoDs that are projected in its position along the depth axis. This is shown in Figure 10.
上部ビューは、Hidden Depth Indexがポッド数を表している3番目の次元に崩壊させることができます。1つのポッドをポッドのクラスとして表示できるため、表現に1つの次元を保存できます。TOFノードは深さと垂直方向の寸法で拡張されますが、上部ノードは水平方向の次元に制約されます。2-D表現のポートは、深さ軸に沿ってその位置に投影されるすべてのポッドで、同じ位置にあるすべてのポートのクラスを効果的に表します。これを図10に示します。
/ / / / / / / / / / / / / / / /
/ / / / / / / / / / / / / / / /
/ / / / / / / / / / / / / / / /
/ / / / / / / / / / / / / / / / ]
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ ]]
| | | | | | | | | | | | | | | | ] -----------------------
[ |o| |o| |o| |o| |o| |o| |o| |o| ] <-- Top of PoD Node (Spine)
[ |o| |o| |o| |o| |o| |o| |o| |o| ] -----------------------
[ |o| |o| |o| |o| |o| |o| |o| |o| ]]]]
[ |o| |o| |o| |o| |o| |o| |o| |o| ]]] ^^
[ |o| |o| |o| |o| |o| |o| |o| |o| ]] // PoDs
[ |o| |o| |o| |o| |o| |o| |o| |o| ] // (depth)
| |/| |/| |/| |/| |/| |/| |/| |/ //
+-+ +-+ +-+/+-+/+-+ +-+ +-+ +-+ //
^
| --------
+----- ToF Node
--------
Figure 10: Collapsed Northern View of a Fabric for Any Number of PoDs
図10：任意の数のポッドの生地の北の景色
As simple as a single-plane deployment is, it introduces a limit due to the bound on the available radix of the ToF nodes that has to be at least P * K_LEAF. Nevertheless, it will become clear that a distinct advantage of a connected or non-partitioned ToF is that all failures can be resolved by simple, non-transitive, positive disaggregation (i.e., nodes advertising more specific prefixes with the default to the level below them that is not propagated further down the fabric) as described in Section 6.5.1. In other words, non-partitioned ToF nodes can always reach nodes below or withdraw the routes from PoDs they cannot reach unambiguously. And with this, positive disaggregation can heal all failures and still allow all the ToF nodes to be aware of each other via south reflection. Disaggregation will be explained in further detail in Section 6.5.
単一平面の展開と同じくらい簡単なのは、少なくともp * k_leafでなければならないTOFノードの利用可能な基数に縛られているため、制限を導入します。それにもかかわらず、セクション6.5.1で説明されているように、接続されていない、または非公開のTOFの明確な利点は、すべての障害が単純で非耐電子的、肯定的な分離（すなわち、ファブリックの下にさらに伝播されないデフォルトのより具体的なプレフィックスを宣伝するノード）によって解決できることであることが明らかになります。言い換えれば、パーティションではないTOFノードは、常に下のノードに到達するか、明確に到達できないポッドからルートを引き出すことができます。これにより、肯定的な分解はすべての障害を癒し、すべてのTOFノードを南の反射を介して互いに認識できるようにすることができます。分解については、セクション6.5でさらに詳しく説明します。
In order to scale beyond the "single-plane limit", the ToF can be partitioned into N number of identically wired planes where N is an integer divider of K_LEAF. The 1:1 ratio and the desired symmetry are still served, this time with (K_TOP*N) ToF nodes, each of (P*K_LEAF/N) ports. N=1 represents a non-partitioned ToF (superspine), and N=K_LEAF is a maximally partitioned ToF. Further, if R is any integer divisor of K_LEAF, then N=K_LEAF/R is a feasible number of planes and R is a redundancy factor that denotes the number of independent paths between 2 leaves within a plane. It proves convenient for deployments to use a radix for the leaf nodes that is a power of 2 so they can pick a number of planes that is a lower power of 2. The example in Figure 11 splits the ToF in 2 planes with a redundancy factor of R=3, meaning that there are 3 non-intersecting paths between any leaf node and any ToF node. A ToF node must have, in this case, at least 3*P ports and be directly connected to 3 of the 6 ToP nodes (spines) in each PoD. The ToP nodes are represented horizontally with K_TOP=8 ports northwards each.
「単一平面制限」を超えてスケーリングするために、TOFは、nがK_LEAFの整数分裂者である同一に有線平面のN数に分割できます。1：1比と目的の対称性はまだ提供されています。今回は（k_top*n）tofノード、それぞれ（p*k_leaf/n）ポートです。n = 1は、非格闘されていないTOF（スーパースパイン）を表し、n = k_leafは最大の分割されたTOFです。さらに、rがK_LEAFの整数除数である場合、n = k_leaf/rは平面内の2つの葉の間の独立したパスの数を示す冗長性因子であり、n = k_leaf/rは実行可能な数値です。展開が2の電力である葉のノードに基数を使用するのに便利であることが証明されているため、2の低電力である多くの平面を選ぶことができます。図11の例は、r = 3の冗長係数の2つの平面でTOFを分割します。この場合、TOFノードには少なくとも3*Pポートがあり、各ポッドの6つの上部ノード（スパイン）のうち3つに直接接続する必要があります。上部ノードは、それぞれ北にk_top = 8ポートで水平に表されます。
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+-| |--| |--| |--| |--| |--| |--| |--| |-+
| | O | | O | | O | | O | | O | | O | | O | | O | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+
+-| |--| |--| |--| |--| |--| |--| |--| |-+
| | O | | O | | O | | O | | O | | O | | O | | O | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+
+-| |--| |--| |--| |--| |--| |--| |--| |-+
| | O | | O | | O | | O | | O | | O | | O | | O | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Plane 1
----------- . ------------ . ------------ . ------------ . --------
Plane 2
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+-| |--| |--| |--| |--| |--| |--| |--| |-+
| | O | | O | | O | | O | | O | | O | | O | | O | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+
+-| |--| |--| |--| |--| |--| |--| |--| |-+
| | O | | O | | O | | O | | O | | O | | O | | O | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+
+-| |--| |--| |--| |--| |--| |--| |--| |-+
| | O | | O | | O | | O | | O | | O | | O | | O | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
^
|
| ---------------------
+----- ToF Node Across Depth
---------------------
Figure 11: Northern View of a Multi-Plane ToF Level, K_LEAF=6, N=2
図11：マルチプレーンTOFレベルの北ビュー、k_leaf = 6、n = 2
At the extreme end of the spectrum, it is even possible to fully partition the ToF with N=K_LEAF and R=1 while maintaining connectivity between each leaf node and each ToF node. In that case, the ToF node connects to a single port per PoD, so it appears as a single port in the projected view represented in Figure 12. The number of ports required on the ToF node is more than or equal to P, i.e., the number of PoDs.
スペクトルの極端な端では、各リーフノードと各TOFノード間の接続性を維持しながら、n = k_leafとr = 1でtoFを完全に分割することさえ可能です。その場合、TOFノードはポッドごとに単一のポートに接続されるため、図12に表される予測ビューの単一ポートとして表示されます。TOFノードに必要なポートの数は、Podの数以上です。
Plane 1
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ -+
+-| |--| |--| |--| |--| |--| |--| |--| |-+ |
| | O | | O | | O | | O | | O | | O | | O | | O | | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
----------- . ------------------- . ------------ . ------- |
Plane 2 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ |
| | O | | O | | O | | O | | O | | O | | O | | O | | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
----------- . ------------ . ---- . ------------ . ------- |
Plane 3 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ |
| | O | | O | | O | | O | | O | | O | | O | | O | | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
----------- . ------------ . ------------------- . --------+<-+
Plane 4 | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ | |
| | O | | O | | O | | O | | O | | O | | O | | O | | | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | |
----------- . ------------ . ------------ . ---- . ------- | |
Plane 5 | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ | |
| | O | | O | | O | | O | | O | | O | | O | | O | | | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | |
----------- . ------------ . ------------ . -------------- | |
Plane 6 | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ | |
| | O | | O | | O | | O | | O | | O | | O | | O | | | |
+-| |--| |--| |--| |--| |--| |--| |--| |-+ | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ -+ |
^ |
| |
| ---------------- ------------- |
+----- ToF Node Class of PoDs ---+
---------------- -------------
Figure 12: Northern View of a Maximally Partitioned ToF Level, R=1
図12：最大の分割されたTOFレベルの北ビュー、r = 1
As mentioned earlier, RIFT exhibits an anisotropic behavior tailored for fabrics with a north-south orientation and a high level of interleaving paths. A non-partitioned fabric makes a total loss of connectivity between a ToF node at the north and a leaf node at the south a very rare but possible occasion that is fully healed by positive disaggregation as described in Section 6.5.1. In large fabrics or fabrics built from switches with a low radix, the ToF may often become partitioned in planes, which makes it more likely that a given leaf is only reachable from a subset of the ToF nodes. This makes some further considerations necessary.
前述のように、Riftは、南北方向と高レベルのインターリービングパスを備えた生地に合わせた異方性行動を示します。非格付けされていないファブリックは、北部のTOFノードと南のリーフノード間の接続性を完全に失います。低基地のスイッチから作られた大きな生地または生地では、TOFは飛行機で分割されることがよくあるため、特定の葉がTOFノードのサブセットからのみ到達できる可能性が高くなります。これにより、さらに考慮事項が必要になります。
A "fallen leaf" is a leaf that can be reached by only a subset of ToF nodes due to missing connectivity. If R is the redundancy factor, then it takes at least R breakages to reach a "fallen leaf" situation.
「倒れた葉」とは、接続が欠落しているため、TOFノードのサブセットのみが到達できる葉です。Rが冗長係数である場合、「葉の倒れ」の状況に到達するには、少なくともR破損が必要です。
In a maximally partitioned fabric, the redundancy factor is R=1, so any breakage in the fabric will cause one or more fallen leaves in the affected plane. R=2 guarantees that a single breakage will not cause a fallen leaf. However, not all cases require disaggregation. The following cases do not require particular action:
最大の分割されたファブリックでは、冗長係数はr = 1であるため、生地の破損が患部に1つ以上の葉が倒れた葉を引き起こします。R = 2は、単一の破損が葉の倒れを引き起こさないことを保証します。ただし、すべてのケースが分解を必要とするわけではありません。次の場合は、特定のアクションを必要としません。
* If a southern link on a node goes down, then connectivity through that node is lost for all nodes south of that link. There is no need to disaggregate since the connectivity to this node is lost for all spine nodes in the same fashion.
* ノード上の南リンクがダウンすると、そのリンクの南にあるすべてのノードでそのノードを介した接続が失われます。このノードへの接続性はすべての脊椎ノードで同じ方法で失われるため、分解する必要はありません。
* If a ToF node goes down, then northern traffic towards it is routed via alternate ToF nodes in the same plane and there is no need to disaggregate routes.
* TOFノードがダウンすると、同じ平面内の代替TOFノードを介してルーティングされ、ルートを分解する必要はありません。
In a general manner, the mechanism of non-transitive, positive disaggregation is sufficient when the disaggregating ToF nodes collectively connect to all the ToP nodes in the broken plane. This happens in the following case:
一般的な方法では、壊れた平面内のすべてのトップノードに集合的に接続する分解TOFノードがまとめて接続する場合、非転移性の肯定的な分解のメカニズムで十分です。これは、次の場合に発生します。
* If the breakage is the last northern link from a ToP node to a ToF node going down, then the fallen leaf problem affects only that ToF node, and the connectivity to all the nodes in the PoD is lost from that ToF node. This can be observed by other ToF nodes within the plane where the ToP node is located and positively disaggregated within that plane.
* 破損がトップノードからダウンするTOFノードへの最後の北部リンクである場合、倒れた葉の問題はそのTOFノードのみに影響し、ポッド内のすべてのノードへの接続はそのTOFノードから失われます。これは、上部ノードが配置されている平面内の他のTOFノードによって観察され、その平面内で積極的に分解されます。
On the other hand, there is a need to disaggregate the routes to Fallen Leaves within the plane in a transitive fashion, that is, all the way to the other leaves, in the following cases:
一方、平面内の葉へのルートを推移的な方法で分解する必要があります。つまり、次の場合には、他の葉までずっとあります。
* If the breakage is the last northern link from a leaf node within a plane (there is only one such link in a maximally partitioned fabric) that goes down, then connectivity to all unicast prefixes attached to the leaf node is lost within the plane where the link is located. Southern Reflection by a leaf node, e.g., between ToP nodes, if the PoD has only 2 levels, happens in between planes, allowing the ToP nodes to detect the problem within the PoD where it occurs and positively disaggregate. The breakage can be observed by the ToF nodes in the same plane through the north flooding of TIEs from the ToP nodes. However, the ToF nodes need to be aware of all the affected prefixes for the negative, possibly transitive, disaggregation to be fully effective (i.e., a node advertising in the control plane that it cannot reach a certain more specific prefix than the default prefix, whereas such disaggregation in the extreme condition must be propagated further down southbound). The problem can also be observed by the ToF nodes in the other planes through the flooding of North TIEs from the affected leaf nodes, together with non-node North TIEs, which indicate the affected prefixes. To be effective in that case, the positive disaggregation must reach down to the nodes that make the plane selection, which are typically the ingress leaf nodes. The information is not useful for routing in the intermediate levels.
* 破損が平面内の葉のノードからの最後の北リンクである場合（最大の分割されたファブリックにそのようなリンクは1つだけです）、葉のノードに接続されたすべてのユニキャストプレフィックスへの接続がリンクがある平面内で失われます。葉のノードによる南部の反射、たとえば、上部ノードの間に、ポッドに2つのレベルしかない場合、平面間で発生し、上部ノードが発生したポッド内の問題を検出し、積極的に分解します。破損は、上部ノードからのネクタイの北の洪水を通じて、同じ平面内のTOFノードによって観察できます。ただし、TOFノードは、ネガティブ、場合によっては推移的な分解のすべての影響を受けるプレフィックスを認識する必要があります（つまり、コントロールプレーンのノード広告は、デフォルトの接頭辞よりも特定の特定の接頭辞に到達できないが、極端な状態でのそのような分解は南に向かってさらに浸透させる必要があります）。この問題は、影響を受ける接頭辞を示す非ノードの北タイとともに、影響を受けた葉のノードからの北ネクタイの洪水と、他の平面のTOFノードによっても観察できます。その場合に効果的であるためには、正の分解は、通常、侵入葉のノードである平面を選択するノードに到達する必要があります。情報は、中間レベルでのルーティングには役に立ちません。
* If the breakage is a ToP node in a maximally partitioned fabric (in which case it is the only ToP node serving the plane in that PoD that goes down), then the connectivity to all the nodes in the PoD is lost within the plane where the ToP node is located. Consequently, all leaves of the PoD fall in this plane. Since the Southern Reflection between the ToF nodes happens only within a plane, ToF nodes in other planes cannot discover fallen leaves in a different plane. They also cannot determine beyond their local plane whether a leaf node that was initially reachable has become unreachable. As the breakage can be observed by the ToF nodes in the plane where the breakage happened, the ToF nodes in the plane need to be aware of all the affected prefixes for the negative disaggregation to be fully effective. The problem can also be observed by the ToF nodes in the other planes through the flooding of North TIEs from the affected leaf nodes if the failing ToP node is directly connected to its leaf nodes, which can detect the link going down. Then again, the knowledge of the failure at the ToF level can only be useful if it is propagated transitively to all the leaves; it is useless above that level since the decision of placing a packet in a plane happens at the leaf that injects the packet in the fabric.
* 破損が最大のパーティション化されたファブリックのトップノードである場合（この場合、ポッドの下にあるポッドの平面に配信する唯一のトップノードである）、ポッド内のすべてのノードへの接続性は、トップノードがある平面内で失われます。その結果、ポッドのすべての葉がこの飛行機に落ちます。TOFノード間の南部の反射は平面内でのみ発生するため、他の平面のTOFノードは、別の平面で倒れた葉を発見することはできません。彼らはまた、最初に到達可能な葉のノードが到達不能になったかどうかを地元の平面を超えて決定することはできません。破損が発生した平面内のTOFノードによって破損が観察されるため、平面内のTOFノードは、負の分解が完全に効果的であるために影響を受けるすべての接頭辞を認識する必要があります。問題は、故障した上部ノードが葉のノードに直接接続されている場合、影響を受ける葉のノードからの北ネクタイの洪水により、他の平面のTOFノードによっても観察できます。繰り返しになりますが、TOFレベルでの故障の知識は、すべての葉に交換されている場合にのみ役立ちます。平面にパケットを配置する決定が葉にパケットを注入する葉で起こるという決定は、そのレベルを超えて役に立ちません。
These abstractions are rolled back into a simplified example that shows that in Figure 3 the loss of the link between spine node 3 and leaf node 3 will make leaf node 3 a fallen leaf for ToF nodes in plane C. Worse, if the cabling was never present in the first place, plane C will not even be able to know that such a fallen leaf exists. Hence, partitioning without further treatment results in two grave problems:
これらの抽象化は、図3でスパインノード3と葉のノード3の間のリンクの損失が平面CのTOFノードの葉の葉になることを示す単純化された例に巻き戻されます。したがって、さらなる治療なしで分割すると、2つの重大な問題が発生します。
1. Leaf node 1 trying to route to leaf node 3 must not choose spine node 3 in plane C as its next hop since it will inevitably drop the packet when forwarding using default routes or do excessive bow-tying. This information must be in its routing table.
1. リーフノード1リーフノード3にルーティングしようとする3つのノード3を選択しないでください。プレーンCのスパインノード3を次のホップとして選択してはなりません。デフォルトルートを使用して転送するときにパケットを必然的にドロップしたり、弓を過度にしたりするためです。この情報は、ルーティングテーブルにある必要があります。
2. A path computation trying to deal with the problem by distributing host routes may only form paths through leaves. The flooding of information about leaf node 3 would have to go up to ToF nodes in planes A, B, and D and then "loopback" over other leaves to ToF C, leading in extreme cases to traffic for leaf node 3 when presented to plane C taking an "inverted fabric" path where leaves start to serve as ToFs, at least for the duration of a protocol's convergence.
2. ホストルートを配布することで問題に対処しようとするパス計算は、葉を通るパスのみを形成する場合があります。リーフノード3に関する情報の洪水は、平面A、B、DのTOFノードに上がって、他の葉を介して他の葉を「ループバック」する必要があります。
When aggregation is used, RIFT deals with fallen leaves by ensuring that all the ToF nodes share the same north topology database. This happens naturally in single-plane design by the means of northbound flooding and south reflection but needs additional considerations in multi-plane fabrics. To enable routing to fallen leaves in multi-plane designs, RIFT requires additional interconnection across planes between the ToF nodes, e.g., using rings as illustrated in Figure 13. Other solutions are possible, but they either need more cabling or end up having much longer flooding paths and/or single points of failure.
集約を使用すると、RiftはすべてのTOFノードが同じ北トポロジーデータベースを共有することを保証することにより、倒れた葉を扱います。これは、北行きの洪水と南反射の手段により、単一平面設計で自然に起こりますが、マルチプレーンファブリックに追加の考慮事項が必要です。マルチプレーンの設計で葉へのルーティングを有効にするために、Riftには、図13に示すようにリングを使用して、TOFノード間の平面間の追加の相互接続が必要です。他のソリューションが可能ですが、より長い洪水パスおよび/または単一の故障ポイントを持つことが必要です。
In detail, by reserving at least two ports on each ToF node, it is possible to connect them together by interplane bidirectional rings as illustrated in Figure 13. The rings will be used to exchange full north topology information between planes. All ToFs having the same north topology allows, by the means of transitive, negative disaggregation described in Section 6.5.2, to efficiently fix any possible fallen leaf scenario. Somewhat as a side effect, the exchange of information fulfills the requirement for a full view of the fabric topology at the ToF level without the need to collate it from multiple points.
詳細には、各TOFノードに少なくとも2つのポートを予約することにより、図13に示すように、プレーン間の双方向リングでそれらを接続することができます。リングは、飛行機間の完全な北トポロジ情報を交換するために使用されます。同じ北トポロジを持つすべてのTOFは、セクション6.5.2で説明されている推移的で否定的な分解の手段により、倒れた葉のシナリオを効率的に修正することができます。やや副作用として、情報の交換は、複数のポイントから照合する必要なく、TOFレベルでファブリックトポロジの完全なビューの要件を満たします。
(Artwork only available as SVG: see
https://www.rfc-editor.org/rfc/rfc9692.html)
Figure 13: Using Rings to Bring All Planes and Bind Them at the ToF
図13：リングを使用してすべての飛行機を持ち込み、TOFでバインドする
One consequence of the "fallen leaf" problem is that some prefixes attached to the fallen leaf become unreachable from some of the ToF nodes. RIFT defines two methods to address this issue, denoted as positive disaggregation and negative disaggregation. Both methods flood corresponding types of South TIEs to advertise the impacted prefix(es).
「葉の葉」の問題の1つの結果は、倒れた葉に取り付けられたいくつかの接頭辞が、いくつかのTOFノードから到達不能になることです。Riftは、この問題に対処するための2つの方法を定義します。これは、肯定的な分解と否定的な分解として示されます。どちらの方法でも、影響を受けたプレフィックス（ES）を宣伝するために、それに対応する南部のタイプのタイプがあふれています。
When used for the operation of disaggregation, a positive South TIE, as usual, indicates reachability to a prefix of given length and all addresses subsumed by it. In contrast, a negative route advertisement indicates that the origin cannot route to the advertised prefix.
分解の操作に使用する場合、通常のように正の南ネクタイは、指定された長さの接頭辞とそれによって包まれたすべてのアドレスの到達可能性を示します。対照的に、ネガティブルート広告は、原点が宣伝されたプレフィックスにルーティングできないことを示しています。
The positive disaggregation is originated by a router that can still reach the advertised prefix, and the operation is not transitive. In other words, the receiver does *not* generate its own TIEs or flood them south as a consequence of receiving positive disaggregation advertisements from a higher-level node. The effect of a positive disaggregation is that the traffic to the impacted prefix will follow the longest match and will be limited to the northbound routers that advertised the more specific route.
肯定的な分解は、広告されたプレフィックスに到達できるルーターによって発生し、操作は推移的ではありません。言い換えれば、レシーバーは、高レベルのノードから肯定的な分解広告を受け取った結果として、独自のネクタイを生成したり、南にあふれさせたりしません。肯定的な分解の効果は、影響を受けたプレフィックスへのトラフィックが最長の一致に続いて、より具体的なルートを宣伝した北行きのルーターに限定されることです。
In contrast, the negative disaggregation can be transitive and is propagated south when all the possible routes have been advertised as negative exceptions. A negative route advertisement is only actionable when the negative prefix is aggregated by a positive route advertisement for a shorter prefix. In such case, the negative advertisement "punches out a hole" in the positive route in the routing table, making the positive prefix reachable through the originator with the special consideration of the negative prefix removing certain next-hop neighbors. The specific procedures are explained in detail in Section 6.5.2.3.
対照的に、否定的な分解は推移的であり、すべての可能なルートが否定的な例外として宣伝されている場合に南に伝播されます。ネガティブルート広告は、より短いプレフィックスの正のルート広告によってネガティブなプレフィックスが集約されている場合にのみ実用的です。そのような場合、否定的な広告は、ルーティングテーブルの正のルートで「穴を開けて」「穴を開ける」ため、特定のネクストホップ隣人を削除するネガティブなプレフィックスを特に考慮して、オリジネーターを通じて正の接頭辞に到達可能になります。特定の手順については、セクション6.5.2.3で詳しく説明します。
When the ToF switches are not partitioned into multiple planes, the resulting southbound flooding of the positive disaggregation by the ToF nodes that can still reach the impacted prefix is generally enough to cover all the switches at the next level south, typically the ToP nodes. If all those switches are aware of the disaggregation, they collectively create a ceiling that intercepts all the traffic north and forwards it to the ToF nodes that advertised the more specific route. In that case, the positive disaggregation alone is sufficient to solve the fallen leaf problem.
TOFスイッチが複数の飛行機に分割されない場合、衝撃を受けたプレフィックスに到達できるTOFノードによる正の分解のサウスバウンド洪水は、一般に、次のレベルの南、通常はトップノードのすべてのスイッチをカバーするのに十分です。これらのすべてのスイッチが分解を認識している場合、すべてのトラフィックを北に遮断し、より具体的なルートを宣伝したTOFノードに転送する天井を集合的に作成します。その場合、肯定的な分解だけで、葉の問題を解決するのに十分です。
On the other hand, when the fabric is partitioned in planes, the positive disaggregation from ToF nodes in different planes do not reach the ToP switches in the affected plane and cannot solve the fallen leaves problem. In other words, a breakage in a plane can only be solved in that plane. Also, the selection of the plane for a packet typically occurs at the leaf level and the disaggregation must be transitive and reach all the leaves. In that case, the negative disaggregation is necessary. The details on the RIFT approach to deal with fallen leaves in an optimal way are specified in Section 6.5.2.
一方、生地が平面に分割されると、異なる平面のTOFノードからの正の分解は、罹患した平面の上部スイッチに到達せず、倒れた葉の問題を解決できません。言い換えれば、飛行機の破損はその飛行機でのみ解決することができます。また、パケットの平面の選択は通常、葉のレベルで発生し、分解は推移的であり、すべての葉に到達する必要があります。その場合、否定的な分解が必要です。倒れた葉を最適な方法で処理するためのリフトアプローチの詳細は、セクション6.5.2で指定されています。
This section specifies the protocol in a normative fashion by either prescriptive procedures or behavior defined by Finite State Machines (FSMs).
このセクションでは、有限状態マシン（FSM）によって定義された規範的な手順または行動のいずれかによって、プロトコルを規範的に指定します。
The FSMs, as usual, are presented as states a neighbor can assume, events that can occur, and the corresponding actions performed when transitioning between states on event processing.
FSMは、通常のように、隣人が想定できる状態、発生する可能性のあるイベント、およびイベント処理で状態間を移行するときに実行される対応するアクションとして提示されます。
Actions are performed before the end state is assumed.
終了状態が想定される前にアクションが実行されます。
The FSMs can queue events against themselves to chain actions or against other FSMs in the specification. Events are always processed in the sequence they have been queued.
FSMSは、自分自身に対して、チェーンアクションまたは仕様の他のFSMに対してイベントをキューに入れることができます。イベントは常にキューに留められてきたシーケンスで処理されます。
Consequently, "On Entry" actions for an FSM state are performed every time and right before the corresponding state is entered, i.e., after any transitions from previous state.
したがって、FSM状態の「エントリ」アクションは、対応する状態が入力される直前に、つまり前の状態からの移行の後に実行されるたびに実行されます。
"On Exit" actions are performed every time and immediately when a state is exited, i.e., before any transitions towards the target state are performed.
「出口時」のアクションは、ターゲット状態への移行が実行される前に、状態が終了する直後に毎回、そしてすぐに実行されます。
Any attempt to transition from a state towards another on reception of an event where no action is specified MUST be considered an unrecoverable error, and the protocol MUST reset all adjacencies and discard all the states (i.e., force the FSM back to _OneWay_ and flush all of the queues holding flooding information).
アクションが指定されていないイベントの受信で州から別の状態に移行する試みは、回復不可能なエラーと見なされ、プロトコルはすべての隣接をリセットしてすべての状態を破棄する必要があります（つまり、FSMを_oneway_に戻し、洪水情報を保持するすべてのキューをフラッシュします）。
The data structures and FSMs described in this document are conceptual and do not have to be implemented precisely as described here, i.e., an implementation is considered conforming as long as it supports the described functionality and exhibits externally observable behavior equivalent to the behavior of the standardized FSMs.
このドキュメントで説明されているデータ構造とFSMは概念的であり、ここで説明するように正確に実装する必要はありません。つまり、標準化されたFSMの動作に相当する機能をサポートし、外部的に観察可能な動作を示す限り、実装は適合していると見なされます。
The FSMs can use "timers" for different situations. Those timers are started through actions, and their expiration leads to queuing of corresponding events to be processed.
FSMは、さまざまな状況に「タイマー」を使用できます。これらのタイマーはアクションを通じて開始され、それらの有効期限は、処理される対応するイベントのキューイングにつながります。
The term "holdtime" is used often as shorthand for "holddown timer" and signifies either the length of the holding down period or the timer used to expire after such period. Such timers are used to "holddown" the state within an FSM that is cleaned if the machine triggers a _HoldtimeExpired_ event.
「ホールドタイム」という用語は、「ホールドダウンタイマー」の速記として頻繁に使用され、ホールドダウン期間の長さまたはそのような期間後に期限切れになるために使用されるタイマーのいずれかを意味します。このようなタイマーは、マシンが_holdtimeexpired_イベントをトリガーした場合にクリーニングされるFSM内の状態を「ホールドダウン」するために使用されます。
All normative RIFT packet structures and their contents are defined in the Thrift [thrift] models in Section 7. The packet structure itself is defined in _ProtocolPacket_, which contains the packet header in _PacketHeader_ and the packet contents in _PacketContent_. _PacketContent_ is a union of the LIE, TIE, TIDE, and TIRE packets, which are subsequently defined in _LIEPacket_, _TIEPacket_, _TIDEPacket_, and _TIREPacket_, respectively.
すべての規範的リフトパケット構造とその内容は、セクション7のThrift [Thrift]モデルで定義されています。パケット構造自体は、_packetheader_のパケットヘッダーと_packetcontent_のパケットコンテンツを含む_protocolpacket_で定義されています。_PacketContent_は、嘘、ネクタイ、潮、およびタイヤパケットの結合であり、その後_liepacket_、_tiepacket_、_tidepacket_、および_tirepacket_で定義されます。
Further, in terms of bits on the wire, it is the _ProtocolPacket_ that is serialized and carried in an envelope defined in Section 6.9.3 within a UDP frame that provides security and allows validation/modification of several important fields without Thrift deserialization for performance and security reasons. Security models and procedures are further explained in Section 9.
さらに、ワイヤーのビットに関しては、セキュリティを提供し、パフォーマンスとセキュリティ上の理由のためにrift薄化されていないいくつかの重要なフィールドの検証/変更を可能にするUDPフレーム内のセクション6.9.3で定義されたエンベロープでシリアル化および運ばれる_Protocolpacket_です。セキュリティモデルと手順については、セクション9でさらに説明します。
RIFT LIE exchange auto-discovers neighbors, negotiates RIFT ZTP parameters, and discovers miscablings. The formation progresses under normal conditions from _OneWay_ to _TwoWay_ and then _ThreeWay_ state, at which point it is ready to exchange TIEs as described in Section 6.3. The adjacency exchanges RIFT ZTP information (Section 6.7) in any of the states, i.e., it is not necessary to reach _ThreeWay_ for ZTP to operate.
Rift Lie Exchangeの自動車隣人、Rift ZTPパラメーターを交渉し、混乱を発見します。フォーメーションは、_oneway_から_twoway_、次に_threeway_状態までの通常の条件下で進行します。この時点で、セクション6.3で説明されているように、タイを交換する準備ができています。隣接は、いずれかの州でRift ZTP情報（セクション6.7）を交換します。つまり、ZTPが動作するために_threeway_に到達する必要はありません。
RIFT supports any combination of IPv4 and IPv6 addressing, including link-local scope, on the fabric to form adjacencies with the additional capability for forwarding paths that are capable of forwarding IPv4 packets in the presence of IPv6 addressing only.
Riftは、Link-Local Scopeを含むIPv4とIPv6アドレス指定の任意の組み合わせをファブリック上にサポートし、IPv4パケットをアドレス指定のみでIPv4パケットを転送できる追加機能を備えた隣接を形成します。
IPv4 LIE exchange happens by default over a well-known IPv4 multicast address [RFC2365] that may also be administratively configured (e.g., with a local scope). For IPv6 [RFC8200], exchange is performed over the link-local multicast scope [RFC4291] address, which is configured or otherwise well-known. In both cases, a destination UDP port defined in the schema (Section 7.2) is used unless configured otherwise. LIEs MUST be sent with an IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) of either 1 or 255 to prevent RIFT information reaching beyond a single Layer 3 (L3) next hop in the topology. Observe that, for the allocated link-local scope IP multicast address, the TTL value of 1 is a more logical choice since the TTL value of 255 may, in some environments, lead to an early drop due to the suspicious TTL value for a packet addressed to such a destination. LIEs SHOULD be sent with network control precedence unless an implementation is prevented from doing so [RFC2474].
IPv4 Lie Exchangeは、管理的に構成されている可能性のあるよく知られているIPv4マルチキャストアドレス[RFC2365]でデフォルトで発生します（たとえば、ローカルスコープで）。IPv6 [RFC8200]の場合、Link-Local Multicast Scope [RFC4291]アドレスを介して交換が実行されます。どちらの場合も、スキーマで定義されている宛先UDPポート（セクション7.2）が、特に構成されていない限り使用されます。トポロジーの次のホップを超えてリフト情報が到達するリフト情報を防ぐために、嘘は1または255のIPv4時間（TTL）またはIPv6ホップ制限（HL）を送信する必要があります。割り当てられたリンクローカルスコープIPマルチキャストアドレスの場合、TTL値は1のTTL値がより論理的な選択であることに注意してください。これは、このような目的地にアドレス指定されたパケットの疑わしいTTL値のために、255のTTL値が早期に低下する可能性があるためです。嘘は、実装がそうすることを妨げられない限り、ネットワーク制御の優先順位で送信する必要があります[RFC2474]。
Any LIE packet received on an address that is neither the well-known nor configured multicast or a broadcast address MUST be discarded.
有名または構成されたマルチキャストまたはブロードキャストアドレスのいずれでもないアドレスで受け取った嘘パケットを破棄する必要があります。
The originating port of the LIE has no further significance, other than identifying the origination point. LIEs are exchanged over all links running RIFT.
嘘の起源のポートは、発生点を識別することを除いて、それ以上の重要性はありません。嘘は、リフトを実行しているすべてのリンクで交換されます。
An implementation may listen and send LIEs on IPv4 and/or IPv6 multicast addresses. A node MUST NOT originate LIEs on an address family if it does not process received LIEs on that family. LIEs on the same link are considered part of the same LIE FSM independent of the address family they arrive on. The LIE source address may not identify the peer uniquely in unnumbered or link-local address cases so the response transmission MUST occur over the same interface the LIEs have been received on. A node may use any of the adjacency's source addresses it saw in LIEs on the specific interface during adjacency formation to send TIEs (Section 6.3.3). That implies that an implementation MUST be ready to accept TIEs on all addresses it used as sources of LIE frames.
実装は、IPv4および/またはIPv6マルチキャストアドレスに嘘をついて送信する場合があります。ノードは、その家族に受信された処理を処理しない場合、住所ファミリーに嘘を発信してはなりません。同じリンクにあるのは、到着する住所ファミリとは無関係に同じ嘘FSMの一部と見なされます。Lie源アドレスは、数の数またはリンクローカルアドレスのケースでピアを一意に識別できない場合があるため、応答伝送は嘘を受け取ったのと同じインターフェイスで発生する必要があります。ノードは、隣接する形成中に特定のインターフェイスに嘘をついて見た隣接するソースアドレスのいずれかを使用して、タイを送信することができます（セクション6.3.3）。これは、実装が嘘フレームのソースとして使用されているすべてのアドレスのタイを受け入れる準備ができている必要があることを意味します。
A simplified version MAY be implemented on platforms with limited multicast support (e.g., Internet of Things (IoT) devices) by sending and receiving LIE frames on IPv4 subnet broadcast addresses or IPv6 all-routers multicast addresses. However, this technique is less optimal and presents a wider attack surface from a security perspective and should hence be used only as a last resort.
単純化されたバージョンは、IPv4サブネットブロードキャストアドレスまたはIPv6 All-RoutersマルチキャストアドレスでLieフレームを送信および受信することにより、限られたマルチキャストサポート（例：Minternt of Things（IoT）デバイス）を備えたプラットフォームに実装できます。ただし、この手法は最適ではなく、セキュリティの観点からより広い攻撃面を提示するため、最後の手段としてのみ使用する必要があります。
A _ThreeWay_ adjacency (as defined in the glossary) over any address family implies support for IPv4 forwarding if the _ipv4_forwarding_capable_ flag in _LinkCapabilities_ is set to true. In the absence of IPv4 LIEs with _ipv4_forwarding_capable_ set to true, a node MUST forward IPv4 packets using gateways discovered on IPv6-only links advertising this capability. The mechanism to discover the corresponding IPv6 gateway is out of scope for this specification and may be implementation-specific. It is expected that the whole fabric supports the same type of forwarding of address families on all the links; any other combination is outside the scope of this specification. If IPv4 forwarding is supported on an interface, _ipv4_forwarding_capable_ MUST be set to true for all LIEs advertised from that interface. If IPv4 and IPv6 LIEs indicate contradicting information, protocol behavior is unspecified. A node sending IPv4 LIEs MUST set the _ipv4_forwarding_capable_ flag to true on all LIEs advertised from that interface.
アドレスファミリを介した_threeway_隣接（用語集で定義されている）は、_ipv4_forwarding_capable_フラグが_linkcapability_のフラグがtrueに設定されている場合、IPv4転送のサポートを意味します。IPv4が存在しない場合、_ipv4_forwarding_capable_セットをtrueに設定すると、ノードはこの機能を宣伝するIPv6のみのリンクで発見されたゲートウェイを使用してIPv4パケットを転送する必要があります。対応するIPv6ゲートウェイを発見するメカニズムは、この仕様の範囲外であり、実装固有の可能性があります。ファブリック全体が、すべてのリンク上の住所ファミリの転送と同じタイプの転送をサポートすることが期待されています。他の組み合わせは、この仕様の範囲外です。IPv4の転送がインターフェイスでサポートされている場合、_IPv4_Forwarding_Capable_は、そのインターフェイスから宣伝されているすべての嘘に対してTRUEに設定する必要があります。IPv4とIPv6が矛盾する情報を示している場合、プロトコルの動作は不特定です。IPv4の嘘を送信するノードは、そのインターフェイスから宣伝されているすべての嘘で_IPV4_FORWARDING_CAPABLE_フラグをtrueに設定する必要があります。
Operation of a fabric where only some of the links are supporting forwarding on an address family or have an address in a family and others do not is outside the scope of this specification.
住所ファミリでの転送をサポートしているリンクの一部のみが、家族に住所を持っている生地の操作は、この仕様の範囲外ではありません。
Any attempt to construct IPv6 forwarding over IPv4-only adjacencies is outside the scope of this specification.
IPv4のみの隣接を介してIPv6転送を構築しようとする試みは、この仕様の範囲外です。
Table 1 outlines protocol behavior pertaining to LIE exchange over different address family combinations. Table 2 outlines the way in which neighbors forward traffic as it pertains to the _ipv4_forwarding_capable_ flag setting across the same address family combinations. The table is symmetric, i.e., the local and remote columns can be exchanged to construct the remaining combinations.
表1は、異なるアドレスファミリの組み合わせを介した嘘交換に関するプロトコルの動作の概要を示します。表2は、同じアドレスファミリの組み合わせで_IPV4_FORWDERING_CAPABLE_フラグ設定に関連する隣のトラフィックを転送する方法の概要を示しています。テーブルは対称です。つまり、ローカル列とリモートの列を交換して、残りの組み合わせを構築できます。
The specific forwarding implementation to support the described behavior is out of scope for this document.
記載されている動作をサポートするための特定の転送の実装は、このドキュメントの範囲外です。
+==========+==========+==========================================+
| Local | Remote | LIE Exchange Behavior |
| Neighbor | Neighbor | |
| Address | Address | |
| Family | Family | |
+==========+==========+==========================================+
| IPv4 | IPv4 | LIEs and TIEs are exchanged over IPv4 |
| | | only. The local neighbor receives TIEs |
| | | from remote neighbors on any of the LIE |
| | | source addresses. |
+----------+----------+------------------------------------------+
| IPv6 | IPv6 | LIEs and TIEs are exchanged over IPv6 |
| | | only. The local neighbor receives TIEs |
| | | from remote neighbors on any of the LIE |
| | | source addresses. |
+----------+----------+------------------------------------------+
| IPv4, | IPv6 | The local neighbor sends LIEs for both |
| IPv6 | | IPv4 and IPv6, while the remote neighbor |
| | | only sends LIEs for IPv6. The resulting |
| | | adjacency will exchange TIEs over IPv6 |
| | | on any of the IPv6 LIE source addresses. |
+----------+----------+------------------------------------------+
| IPv4, | IPv4, | LIEs and TIEs are exchanged over IPv6 |
| IPv6 | IPv6 | and IPv4. TIEs are received on any of |
| | | the IPv4 or IPv6 LIE source addresses. |
| | | The local neighbor receives TIEs from |
| | | the remote neighbors on any of the IPv4 |
| | | or IPv6 LIE source addresses. |
+----------+----------+------------------------------------------+
| IPv4, | IPv4 | The local neighbor sends LIEs for both |
| IPv6 | | IPv4 and IPv6, while the remote neighbor |
| | | only sends LIEs for IPv4. The resulting |
| | | adjacency will exchange TIEs over IPv4 |
| | | on any of the IPv4 LIE source addresses. |
+----------+----------+------------------------------------------+
Table 1: Control Plane Behavior for Neighbor Address Family Combinations
表1：近隣住所ファミリの組み合わせのコントロールプレーンの動作
+==========+==========+==========================================+
| Local | Remote | Forwarding Behavior |
| Neighbor | Neighbor | |
| Address | Address | |
| Family | Family | |
+==========+==========+==========================================+
| IPv4 | IPv4 | Only IPv4 traffic can be forwarded. |
+----------+----------+------------------------------------------+
| IPv6 | IPv6 | If either neighbor sets |
| | | _ipv4_forwarding_capable_ to false, only |
| | | IPv6 traffic can be forwarded. If both |
| | | neighbors set _ipv4_forwarding_capable_ |
| | | to true, IPv4 traffic is also forwarded |
| | | via IPv6 gateways. |
+----------+----------+------------------------------------------+
| IPv4, | IPv6 | If the remote neighbor sets |
| IPv6 | | _ipv4_forwarding_capable_ to false, only |
| | | IPv6 traffic can be forwarded. If both |
| | | neighbors set _ipv4_forwarding_capable_ |
| | | to true, IPv4 traffic is also forwarded |
| | | via IPv6 gateways. |
+----------+----------+------------------------------------------+
| IPv4, | IPv4, | IPv4 and IPv6 traffic can be forwarded. |
| IPv6 | IPv6 | If IPv4 and IPv6 LIEs advertise |
| | | conflicting _ipv4_forwarding_capable_ |
| | | flags, the behavior is unspecified. |
+----------+----------+------------------------------------------+
| IPv4, | IPv4 | IPv4 traffic can be forwarded. |
| IPv6 | | |
+----------+----------+------------------------------------------+
Table 2: Forwarding Behavior for Neighbor Address Family Combinations
表2：近隣住所ファミリの組み合わせの転送動作
The protocol does *not* support selective disabling of address families after adjacency formation, disabling IPv4 forwarding capability, or any local address changes in _ThreeWay_ state, i.e., if a link has entered ThreeWay IPv4 and/or IPv6 with a neighbor on an adjacency and it wants to stop supporting one of the families, change any of its local addresses, or stop IPv4 forwarding, it MUST tear down and rebuild the adjacency. It MUST also remove any state it stored about the remote side of the adjacency such as associated LIE source addresses.
プロトコルは、隣接順序形成後の住所ファミリの選択的無効化、IPv4転送機能の無効化、または_threeway_状態のローカルアドレスの変更後、アドレスファミリの選択的無効化をサポートしない *サポート *しない *サポート *しない *サポートしない *サポートしない *サポートしない *サポートしない *サポートしない *サポートしません。_threeway_状態のローカルアドレスの変更、つまり、リンクが隣接する隣人とリンクが3way IPv4および/またはIPv6に入った場合、隣接する場合にリンクが隣接する場合、家族の1つをサポートするのを停止したい場合、IPV4の誘導を止めます。隣接。また、関連するLieソースアドレスなど、隣接の遠隔側に保存した状態を削除する必要があります。
Unless RIFT ZTP is used as described in Section 6.7, each node is provisioned with the level at which it is operating and advertises it in the _level_ of the _PacketHeader_ schema element. It MAY also be provisioned with its PoD. If the level is not provisioned, it is not present in the optional _PacketHeader_ schema element and established by ZTP procedures, if feasible. If PoD is not provisioned, it is governed by the _LIEPacket_ schema element assuming the _common.default_pod_ value. This means that switches except ToF do not need to be configured at all. Necessary information to configure all values is exchanged in the _LIEPacket_ and _PacketHeader_ or derived by the node automatically.
セクション6.7で説明されているようにRIFT ZTPが使用されない限り、各ノードには_PackEtheAder_ Schema要素の_Level_に操作しているレベルでプロビジョニングされ、宣伝されます。また、ポッドでプロビジョニングされる場合があります。レベルがプロビジョニングされていない場合、オプションの_packetheader_スキーマ要素には存在せず、実行可能な場合はZTP手順によって確立されます。PODがプロビジョニングされていない場合、_common.default_pod_値を仮定して、_liepacket_スキーマ要素によって管理されます。これは、TOF以外のスイッチを構成する必要がないことを意味します。すべての値を構成するために必要な情報は、_liepacket_および_packetheader_で交換されるか、ノードによって自動的に導出されます。
Further leaf flag definitions are found in Section 6.7 as they have implications in terms of level and adjacency formation. Leaf flags are carried in _HierarchyIndications_.
レベル6.7には、レベルと隣接の形成の点で影響があるため、さらに葉の旗の定義がセクション6.7にあります。葉の旗は_hierarchyindications_で運ばれます。
A node MUST form a _ThreeWay_ adjacency if, at a minimum, the following first order logic conditions are satisfied on a LIE packet, as specified by the _LIEPacket_ schema element and received on a link (such a LIE is considered a "minimally valid" LIE). Observe that, depending on the FSM involved and its state, further conditions may be checked, and even a minimally valid LIE can be considered ultimately invalid if any of the additional conditions fail:
_liepacket_スキーマ要素で指定され、リンクで受信されたように、少なくとも次の一次ロジック条件が嘘パケットで満たされている場合、ノードは_ threeway_隣接を形成する必要があります（そのような嘘は「最小限に有効な」嘘と見なされます）。関係するFSMとその状態に応じて、さらなる条件がチェックされる可能性があり、追加の条件のいずれかが失敗した場合、最終的に無効と見なすことができることを観察してください。
1. the neighboring node is running the same major schema version as indicated in the _major_version_ element in _PacketHeader_ *and*
1. 隣接するノードは、_major_version_要素で_packetheader_ *and *に示されているのと同じ主要なスキーマバージョンを実行しています
2. the neighboring node uses a valid System ID (i.e., a value different from _IllegalSystemID_) in the _sender_ element in _PacketHeader_ *and*
2. 隣接するノードは、_packetheader_ *and *の_Sender_要素で有効なシステムID（つまり、_ILLEGALSSTEMID_とは異なる値）を使用します。
3. the neighboring node uses a different System ID than the node itself *and*
3. 隣接するノードは、ノード自体とは異なるシステムIDを使用します *および *
4. (the advertised MTU values in the _LiePacket_ element match on both sides, while a missing MTU in the _LiePacket_ element is interpreted as _default_mtu_size_) *and*
4. （_liepacket_要素の両側の_liepacket_要素の一致で広告されたmtu値。_liepacket_要素に欠落しているmtuは_default_mtu_size_として解釈されます） *および *
5. both nodes advertise defined level values in the _level_ element in _PacketHeader_ *and*
5. 両方のノードは、_packetheader_ *および *の_Level_要素で定義されたレベル値を宣伝します
6. [
6. [
a. the node is at the _leaf_level_ value and does not already have any _ThreeWay_ adjacencies to nodes that are at the Highest Adjacency _ThreeWay_ (HAT), as defined in Section 6.7.1, with a level that is different than the adjacent node *or*
a. ノードは_LEAF_LEVEL_値にあり、セクション6.7.1で定義されているように、隣接するノード *または *とは異なるレベルで、最高の隣接_Threeway_（hat）のノードへの_threeway_隣接はまだありません。
b. the node is not at the _leaf_level_ value and the neighboring node is at the _leaf_level_ value *or*
b. ノードは_LEAF_LEVEL_値になく、隣接するノードは_LEAF_LEVEL_値 *または *にあります
c. both nodes are at the _leaf_level_ value *and* both indicate support for that described in Section 6.8.9 *or*
c. どちらのノードも_LEAF_LEVEL_値 *にあり、両方ともセクション6.8.9 *または *で説明されているもののサポートを示しています
d. neither node is at the _leaf_level_ value and the neighboring node is, at most, one level away.
d. どちらのノードも_LEAF_LEVEL_値にはなく、隣接するノードはせいぜい1レベルです。
]
]
LIEs arriving with IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) different than 1 or 255 MUST be ignored.
IPv4の時間（TTL）または1または255の異なるIPv6ホップ制限（HL）が到着することは無視する必要があります。
This section specifies the precise, normative LIE FSM, which is also shown in Figure 14. Additionally, some sets of actions often repeat and are hence summarized into well-known procedures.
このセクションでは、図14にも示されている正確で規範的な嘘FSMを指定します。さらに、一部の一連のアクションはしばしば繰り返されるため、よく知られている手順に要約されています。
Events generated are fairly fine grained, especially when indicating problems in adjacency-forming conditions to simplify tracking of problems in deployment.
生成されたイベントは、特に展開の問題の追跡を簡素化するために隣接する形成条件の問題を示す場合、かなり細かい粒子です。
The initial state is _OneWay_.
初期状態は_oneway _です。
The machine sends LIEs proactively on several transitions to accelerate adjacency bring-up without waiting for the corresponding timer tic.
マシンは、対応するタイマーTICを待たずに隣接する供給を加速するために、いくつかの遷移に積極的に嘘を送信します。
Enter
|
V
+-----------+
| OneWay |<----+
| | | TimerTick
| | | LevelChanged
| | | HALChanged
| | | HATChanged
| | | HALSChanged
| | | LieRcvd
| | | NeighborDroppedReflection
| | | NeighborChangedLevel
| | | NeighborChangedAddress
| | | UnacceptableHeader
| | | MTUMismatch
| | | NeighborChangedMinorFields
| | | HoldtimeExpired
| | | FloodLeadersChanged
| | | SendLie
| | | UpdateZTPOffer
| |-----+
| |
| |<--------------------- (ThreeWay)
| |--------------------->
| | ValidReflection
| |
| |---------------------> (Multiple
| | MultipleNeighbors Neighbors
+-----------+ Wait)
^ |
| |
| | NewNeighbor
| V
(TwoWay)
(OneWay)
| ^
| | NeighborChangedLevel
| | NeighborChangedAddress
| | UnacceptableHeader
| | MTUMismatch
| | HoldtimeExpired
| |
V |
+-----------+
| TwoWay |<----+
| | | TimerTick
| | | LevelChanged
| | | HALChanged
| | | HATChanged
| | | HALSChanged
| | | LieRcvd
| | | FloodLeadersChanged
| | | SendLie
| | | UpdateZTPOffer
| |-----+
| |
| |<----------------------
| |----------------------> (Multiple
| | NewNeighbor Neighbors
| | Wait)
| | MultipleNeighbors
+-----------+
^ |
| | ValidReflection
| V
(ThreeWay)
(TwoWay) (OneWay)
^ | ^
| | | LevelChanged
| | | NeighborChangedLevel
| | | NeighborChangedAddress
| | | UnacceptableHeader
| | | MTUMismatch
| | | HoldtimeExpired
NeighborDropped- | | |
Reflection | | |
| V |
+-----------+ |
| ThreeWay |-----+
| |
| |<----+
| | | TimerTick
| | | HALChanged
| | | HATChanged
| | | HALSChanged
| | | LieRcvd
| | | ValidReflection
| | | FloodLeadersChanged
| | | SendLie
| | | UpdateZTPOffer
| |-----+
| |----------------------> (Multiple
| | MultipleNeighbors Neighbors
+-----------+ Wait)
(TwoWay) (ThreeWay)
| |
V V
+------------+
| Multiple |<----+
| Neighbors | | TimerTick
| Wait | | HALChanged
| | | HATChanged
| | | HALSChanged
| | | LieRcvd
| | | ValidReflection
| | | NeighborDroppedReflection
| | | NeighborChangedBFDCapability
| | | NeighborChangedAddress
| | | UnacceptableHeader
| | | MTUMismatch
| | | HoldtimeExpired
| | | MultipleNeighbors
| | | FloodLeadersChanged
| | | SendLie
| | | UpdateZTPOffer
| |-----+
| |
| |<---------------------------
| |---------------------------> (OneWay)
| | LevelChanged
+------------+ MultipleNeighborsDone
Figure 14: LIE FSM
図14：FSMの嘘
The following words are used for well-known procedures:
次の単語は、よく知られている手順に使用されます。
* PUSH Event: queues an event to be executed by the FSM upon exit of this action
* プッシュイベント：このアクションの終了時にFSMによって実行されるイベントをキュー
* CLEANUP: The FSM *conceptually* holds a "current neighbor" variable that contains information received in the remote node's LIE that is processed against LIE validation rules. In the event that the LIE is considered to be invalid, the existing state held by a "current neighbor" MUST be deleted.
* クリーンアップ：FSM *概念 *は、嘘検証ルールに対して処理されるリモートノードの嘘で受け取った情報を含む「現在の隣接」変数を保持します。嘘が無効であると見なされた場合、「現在の隣人」が保有する既存の状態を削除する必要があります。
* SEND_LIE: create and send a new LIE packet
* send_lie：新しい嘘パケットを作成して送信します
1. reflecting the _neighbor_ element as described in ValidReflection,
1. 有効な反射で説明されている_neighbor_要素を反映して、
2. setting the necessary _not_a_ztp_offer_ variable if the level was derived from the last-known neighbor on this interface, and
2. 必要な_NOT_A_ZTP_OFFER_変数を設定するレベルがこのインターフェイスの最後に知られている隣人から派生した場合、
3. setting the _you_are_flood_repeater_ variable to the computed value.
3. _you_are_flood_repeater_変数を計算値に設定します。
* PROCESS_LIE:
* process_lie：
1. if LIE has a major version not equal to this node's major version *or* System ID equal to this node's System ID or _IllegalSystemID_, then CLEANUP, else
1. 嘘がこのノードのメジャーバージョンに等しくないメジャーバージョンを持っている場合 *または *システムIDは、このノードのシステムIDまたは_ILLEGALSSYSTEMID_に等しく、その後クリーンアップなど
2. if both sides advertise Layer 2 MTU values and the MTU in the received LIE does not match the MTU advertised by the local system *or* at least one of the nodes does not advertise an MTU value and the advertising node's LIE does not match the _default_mtu_size_ of the system not advertising an MTU, then CLEANUP, then PUSH UpdateZTPOffer, then PUSH MTUMismatch, else
2. 双方がレイヤー2 MTU値を宣伝し、受信した嘘のMTUがローカルシステムによって宣伝されたMTUと一致しない場合 *または *ノードの少なくとも1つはMTU値を宣伝せず、広告ノードの嘘は_DEFAULT_MTU_SIZE_の_DEFAULT_MTU_SIZE_と一致しません。
3. if the LIE has an undefined level *or* this node's level is undefined *or* this node is a leaf and the remote level is lower than HAT *or* the LIE's level is not leaf *and* its difference is more than one from this node's level, then CLEANUP, then PUSH UpdateZTPOffer, then PUSH UnacceptableHeader, else
3. 嘘が未定義のレベルを持っている場合 *または *このノードのレベルが未定義です *または *このノードは葉であり、リモートレベルは帽子よりも低く *または *嘘のレベルは葉ではなく、 *その違いはこのノードのレベルから1つ以上であり、クリーンアップしてから、updateztpofferをプッシュしてから、アクセシカル可能なheaderをプッシュします。
4. PUSH UpdateZTPOffer, construct a temporary new neighbor structure with values from LIE, if no current neighbor exists, then set current neighbor to new neighbor, PUSH NewNeighbor event, CHECK_THREE_WAY, else
4. updateztpofferを押し、嘘から値を持つ一時的な新しい隣人構造を構築します。現在の隣人が存在しない場合は、現在の隣人を新しい隣人に設定し、newneighborイベントをプッシュ、check_three_wayなど
a. if the current neighbor System ID differs from LIE's System ID, then PUSH MultipleNeighbors, else
a. 現在の隣接システムIDが嘘のシステムIDとは異なる場合は、マルチプレーネフィードをプッシュします。
b. if the current neighbor stored level differs from LIE's level, then PUSH NeighborChangedLevel, else
b. 現在の隣人が保存されているレベルが嘘のレベルとは異なる場合、neighborChangedlevelをプッシュします。
c. if the current neighbor stored IPv4/v6 address differs from LIE's address, then PUSH NeighborChangedAddress, else
c. 現在の隣人が保存されているIPv4/V6アドレスが嘘のアドレスと異なる場合は、neighborChangedAddressを押します。
d. if any of the neighbor's flood address port, name, or local LinkID changed, then PUSH NeighborChangedMinorFields
d. 隣人の洪水アドレスポート、名前、または地元のLinkidが変更された場合は、neighborChangedminorfieldsを押します
e. CHECK_THREE_WAY
e. Check_three_way
* CHECK_THREE_WAY: if the current state is _OneWay_, do nothing, else
* check_three_way：現在の状態が_oneway_の場合、何もしないでください。
1. if LIE packet does not contain a neighbor then if the current state is _ThreeWay_, then PUSH NeighborDroppedReflection, else
1. Lie Packetに隣人が含まれていない場合、現在の状態が_threeway_の場合は、neighbordroppedreflectionを押します。
2. if the packet reflects this System ID and local port and the state is _ThreeWay_, then PUSH the ValidReflection event, else PUSH the MultipleNeighbors event.
2. パケットがこのシステムIDとローカルポートを反映しており、状態が_threeway_の場合、validreflectionイベントをプッシュし、それ以外の場合はマルチプレイングボールイベントをプッシュします。
States:
州：
* OneWay: The initial state the FSM is starting from. In this state, the router did not receive any valid LIEs from a neighbor.
* ワンウェイ：FSMが始まる初期状態。この状態では、ルーターは隣人から有効な嘘を受け取りませんでした。
* TwoWay: This state is entered when a node has received a minimally valid LIE from a neighbor but not a ThreeWay valid LIE.
* Twoway：この状態は、ノードが隣人から最小限に有効な嘘を受け取ったが、3ウェイの有効な嘘ではないときに入力されます。
* ThreeWay: This state signifies that _ThreeWay_ valid LIEs from a neighbor have been received. On achieving this state, the link can be advertised in the _neighbors_ element in _NodeTIEElement_.
* 3ウェイ：この状態は、_Threeway_有効な隣人からの嘘が受け取られたことを意味します。この状態を達成すると、リンクは_nodetieelement_の_neighbors_要素で宣伝できます。
* MultipleNeighborsWait: Occurs normally when more than two nodes become aware of each other on the same link or a remote node is quickly reconfigured or rebooted without regressing to _OneWay_ first. Each occurrence of the event SHOULD generate a notification to help operational deployments.
* MultipleneIghborswait：通常、同じリンクで3つ以上のノードが互いに認識されるか、リモートノードが最初に_oneway_に回帰せずに迅速に再構成または再起動すると発生します。イベントの各発生は、運用展開を支援するための通知を生成するはずです。
Events:
イベント：
* TimerTick: One-second timer tick, i.e., the event is provided to the FSM once a second by an implementation-specific mechanism that is outside the scope of this specification. This event is quietly ignored if the relevant transition does not exist.
* Timertick：1秒のタイマーティック、つまり、この仕様の範囲外の実装固有のメカニズムにより、イベントがFSMに1回1回提供されます。関連する移行が存在しない場合、このイベントは静かに無視されます。
* LevelChanged: Node's level has been changed by ZTP or configuration. This is provided by the ZTP FSM.
* LevelChanged：ノードのレベルはZTPまたは構成によって変更されました。これはZTP FSMによって提供されます。
* HALChanged: Best HAL computed by ZTP has changed. This is provided by the ZTP FSM.
* HALCHANGED：ZTPによって計算された最高のHALが変更されました。これはZTP FSMによって提供されます。
* HATChanged: HAT computed by ZTP has changed. This is provided by the ZTP FSM.
* Hatchanged：ZTPによって計算されたHATが変更されました。これはZTP FSMによって提供されます。
* HALSChanged: Set of HAL offering systems computed by ZTP has changed. This is provided by the ZTP FSM.
* Halschanged：ZTPによって計算されたHAL提供システムのセットが変更されました。これはZTP FSMによって提供されます。
* LieRcvd: Received LIE on the interface.
* liercvd：インターフェイスに嘘をついた。
* NewNeighbor: New neighbor is present in the received LIE.
* Newneighbor：新しい隣人が受け取った嘘に存在します。
* ValidReflection: Received valid reflection of this node from the neighbor, i.e., all elements in the _neighbor_ element in _LiePacket_ have values corresponding to this link.
* validreflection：neighterからのこのノードの有効な反射、つまり_liepacket_の_neighbor_要素のすべての要素には、このリンクに対応する値があります。
* NeighborDroppedReflection: Lost previously held reflection from the neighbor, i.e., the _neighbor_ element in _LiePacket_ does not correspond to this node or is not present.
* neighbordroppedreflection：隣人からの以前に保持されていた失われた反射、つまり_liepacket_の_neighbor_要素はこのノードに対応していないか、存在しません。
* NeighborChangedLevel: Neighbor changed the advertised level from the previously held one.
* NeighborChangedLevel：Neighborは、以前に保持されたレベルから広告レベルを変更しました。
* NeighborChangedAddress: Neighbor changed the IP address, i.e., the LIE has been received from an address different from previous LIEs. Those changes will influence the sockets used to listen to TIEs, TIREs, and TIDEs.
* neighborChangedAddress：隣人はIPアドレスを変更しました。つまり、嘘は以前の嘘とは異なるアドレスから受け取られました。これらの変更は、ネクタイ、タイヤ、潮を聞くために使用されるソケットに影響を与えます。
* UnacceptableHeader: Unacceptable header received.
* 容認できないヘッダー：受け入れられないヘッダーを受け取りました。
* MTUMismatch: MTU mismatched.
* mtumismatch：MTUミスマッチ。
* NeighborChangedMinorFields: Minor fields changed in the neighbor's LIE.
* NeighborChangedMinorfields：隣人の嘘で変化した小さな畑。
* HoldtimeExpired: Adjacency holddown timer expired.
* holdtimeexpired：隣接するホールドダウンタイマーの有効期限が切れました。
* MultipleNeighbors: More than one neighbor is present on the interface.
* MultipleneIghbors：インターフェイスには複数の隣人が存在します。
* MultipleNeighborsDone: Multiple neighbors timer expired.
* MultipleneIghborsdone：複数のNeighborsタイマーが期限切れになりました。
* FloodLeadersChanged: Node's election algorithm determined new set of flood leaders.
* FloodLeadersChanged：Nodeの選挙アルゴリズムは、洪水リーダーの新しいセットを決定しました。
* SendLie: Send a LIE out.
* Sendlie：嘘をついてください。
* UpdateZTPOffer: Update this node's ZTP offer. This is sent to the ZTP FSM.
* UpdateZtPoffer：このノードのZTPオファーを更新します。これはZTP FSMに送信されます。
Actions:
行動：
* on HATChanged in _OneWay_ finishes in OneWay: store HAT
* _oneway_のhatchanged on _oneway_ finishes in windway：store Hat
* on FloodLeadersChanged in _OneWay_ finishes in OneWay: update _you_are_flood_repeater_ LIE elements based on the flood leader election results
* FloodLeadersCanged on _oneway_ finishes in windway：update _you_are_flood_repeater_洪水リーダーの選挙結果に基づく嘘要素
* on UnacceptableHeader in _OneWay_ finishes in OneWay: no action
* _oneway_の容認できないヘッダーでは、一方で終了します：アクションなし
* on NeighborChangedMinorFields in _OneWay_ finishes in OneWay: no action
* neighborChangedMinorfieldsの_oneway_では、一方で終了します：アクションなし
* on SendLie in _OneWay_ finishes in OneWay: SEND_LIE
* _oneway_でsendlieで片方で仕上げます：send_lie
* on HALSChanged in _OneWay_ finishes in OneWay: store the HALS
* _oneway_で終了したhalschanged on theway：halsを保管する
* on MultipleNeighbors in _OneWay_ finishes in MultipleNeighborsWait: start multiple neighbors timer with the interval _multiple_neighbors_lie_holdtime_multiplier_ * _default_lie_holdtime_
* _oneway_ finishes in multipleneighborswaitのマルチプレーンフィートで：インターバルで複数のネイバータイマーを開始します
* on NeighborChangedLevel in _OneWay_ finishes in OneWay: no action
* neighborChangedlevelの_oneway_では、一方で終了します：アクションなし
* on LieRcvd in _OneWay_ finishes in OneWay: PROCESS_LIE
* _oneway_のliercvdでは、一方向：process_lieで仕上げます
* on MTUMismatch in _OneWay_ finishes in OneWay: no action
* _oneway_のmtumismatchでは、一方で終了します：アクションなし
* on ValidReflection in _OneWay_ finishes in ThreeWay: no action
* _oneway_での有効な反射について3ウェイで終了：アクションなし
* on LevelChanged in _OneWay_ finishes in OneWay: update the level with the event value, PUSH the SendLie event
* _oneway_でレベルチャンジで一方的に仕上げます：イベント値でレベルを更新し、sendlieイベントをプッシュします
* on HALChanged in _OneWay_ finishes in OneWay: store the new HAL
* _oneway_のhalchanged on _oneway_ finishes in windway：新しいhalを保存します
* on HoldtimeExpired in _OneWay_ finishes in OneWay: no action
* _oneway_ finishesでholdtimeexpired on thenway：no action
* on NeighborChangedAddress in _OneWay_ finishes in OneWay: no action
* _Oneway_のneighborChangedAddressでは、一方で終了します：アクションなし
* on NewNeighbor in _OneWay_ finishes in TwoWay: PUSH the SendLie event
* _oneway_のnewneighborでTwowayで終了：Sendlieイベントをプッシュ
* on UpdateZTPOffer in _OneWay_ finishes in OneWay: send the offer to the ZTP FSM
* _oneway_のupdateztpofferでdenultes in theway：ztp fsmにオファーを送信します
* on NeighborDroppedReflection in _OneWay_ finishes in OneWay: no action
* _Oneway_の隣のrefertion refertionでは、一方的に終了します：アクションなし
* on TimerTick in _OneWay_ finishes in OneWay: PUSH SendLie event
* _oneway_のティマーティックでは、一方的に終了します：sendlieイベントを押します
* on FloodLeadersChanged in _TwoWay_ finishes in TwoWay: update _you_are_flood_repeater_ LIE elements based on the flood leader election results
* FloodLeadersCanged on _twoway_ finishes in twoway：update _you_are_flood_repeater_洪水リーダーの選挙結果に基づく嘘要素
* on UpdateZTPOffer in _TwoWay_ finishes in TwoWay: send the offer to the ZTP FSM
* _twoway_のupdateztpofferでdefinises in twoway：ztp fsmにオファーを送信します
* on NewNeighbor in _TwoWay_ finishes in MultipleNeighborsWait: PUSH the SendLie event
* _twoway_のnewneighborでMultipleneighborswaitで仕上げます：sendlieイベントをプッシュ
* on ValidReflection in _TwoWay_ finishes in ThreeWay: no action
* _twoway_での有効な反射について、3ウェイで終了：アクションなし
* on LieRcvd in _TwoWay_ finishes in TwoWay: PROCESS_LIE
* _twoway_のliercvdでは、twoway：process_lieで仕上げます
* on UnacceptableHeader in _TwoWay_ finishes in OneWay: no action
* _twoway_の容認できないヘッダーでは、一方で終了します：アクションなし
* on HALChanged in _TwoWay_ finishes in TwoWay: store the new HAL
* _twoway_でhalchanged on twoway：新しいhalを保存する
* on HoldtimeExpired in _TwoWay_ finishes in OneWay: no action
* on holdtimeexpired _twoway_ finishes in thenway：no action
* on LevelChanged in _TwoWay_ finishes in TwoWay: update the level with the event value
* _twoway_でlevelChanged on twowayで仕上げます：イベント値でレベルを更新します
* on TimerTick in _TwoWay_ finishes in TwoWay: PUSH SendLie event, if last valid LIE was received more than _holdtime_ ago as advertised by the neighbor, then PUSH the HoldtimeExpired event
* _twoway_のティマーティックでTwowayで終了：sendlieイベントを押してください。隣人が宣伝したように_holdtime_ Agoよりも最後に有効な嘘が受信された場合、Holdtimeexpiredイベントをプッシュします
* on HATChanged in _TwoWay_ finishes in TwoWay: store HAT
* _twoway_でhatchanged on twoway：store Hatで仕上げます
* on NeighborChangedLevel in _TwoWay_ finishes in OneWay: no action
* _twoway_のneighborchangedlevelでは、一方で終了します：アクションなし
* on HALSChanged in _TwoWay_ finishes in TwoWay: store the HALS
* _twoway_でhalschanged on twoway：halsを保管する
* on MTUMismatch in _TwoWay_ finishes in OneWay: no action
* _twoway_のmtumismatchでは、一方で終了します：アクションなし
* on NeighborChangedAddress in _TwoWay_ finishes in OneWay: no action
* _twoway_のneverychangedaddressでは、一方で終了します：アクションなし
* on SendLie in _TwoWay_ finishes in TwoWay: SEND_LIE
* _twoway_のsendlieでsendlieでdenides in twoway：send_lie
* on MultipleNeighbors in _TwoWay_ finishes in MultipleNeighborsWait: start multiple neighbors timer with the interval _multiple_neighbors_lie_holdtime_multiplier_ * _default_lie_holdtime_
* _twoway_のマルチプレーンフィートでマルチリネイボールウェイトの仕上げ：インターバルで複数のネイバータイマーを開始_multiple_neighbors_lie_holdtime_multiplier_ * _default_lie_holdtime_
* on TimerTick in _ThreeWay_ finishes in ThreeWay: PUSH the SendLie event, if the last valid LIE was received more than _holdtime_ ago as advertised by the neighbor, then PUSH the HoldtimeExpired event
* _threeway_のティマーティックで3wayで仕上げます：sendlieイベントを押して、隣人が宣伝した最後の有効な嘘が_holdtime_ Agaを受け取った場合、holdtimeexpiredイベントをプッシュします
* on LevelChanged in _ThreeWay_ finishes in OneWay: update the level with the event value
* _THREEWAY_でレベルチャンジで一方向で仕上げます：イベント値でレベルを更新します
* on HATChanged in _ThreeWay_ finishes in ThreeWay: store HAT
* _threeway_でhatchanged on hatchanged on threeway：Store Hatで仕上げます
* on MTUMismatch in _ThreeWay_ finishes in OneWay: no action
* _threeway_のmtumismatchでは、一方的に終了します：アクションなし
* on UnacceptableHeader in _ThreeWay_ finishes in OneWay: no action
* _threeway_のacceptableheaderでは、一方で終了します：アクションなし
* on MultipleNeighbors in _ThreeWay_ finishes in MultipleNeighborsWait: start multiple neighbors timer with the interval _multiple_neighbors_lie_holdtime_multiplier_ * _default_lie_holdtime_
* _threeway_のマルチリンヴァーボールでマルチリネイボールウェイトで仕上げます：インターバルで複数のネイバータイマーを開始_multiple_neighbors_lie_holdtime_multiplier_ * _default_lie_holdtime_
* on NeighborChangedLevel in _ThreeWay_ finishes in OneWay: no action
* _threeway_のneighborChangedlevelでは、一方で終了します：アクションなし
* on HALSChanged in _ThreeWay_ finishes in ThreeWay: store the HALS
* _threeway_ 3way：halsを保存する_threeway_でhalschangedでhalschanged
* on LieRcvd in _ThreeWay_ finishes in ThreeWay: PROCESS_LIE
* _threeway_でliercvdで3way：process_lieで仕上げます
* on FloodLeadersChanged in _ThreeWay_ finishes in ThreeWay: update _you_are_flood_repeater_ LIE elements based on the flood leader election results, PUSH the SendLie event
* _threeway_ 3wayで_threeway_仕上げでfloodleaderserschangedでflood _you_are_flood_repeater_洪水リーダーの選挙結果に基づいて、嘘の嘘要素で、sendlieイベントをプッシュします
* on NeighborDroppedReflection in _ThreeWay_ finishes in TwoWay: no action
* Twowayで_threeway_仕上げのNeighbordroppedreflectionで：アクションなし
* on HoldtimeExpired in _ThreeWay_ finishes in OneWay: no action
* HoldTimeExpired _threeway_ Finishes in Thenway：no action
* on ValidReflection in _ThreeWay_ finishes in ThreeWay: no action
* _threeway_でのvalidreflection on threewayで終了：アクションなし
* on UpdateZTPOffer in _ThreeWay_ finishes in ThreeWay: send the offer to the ZTP FSM
* _threeway_ 3wayのupdateZtpofferでdepury fsmに送信するZTP FSMに送信
* on NeighborChangedAddress in _ThreeWay_ finishes in OneWay: no action
* _threeway_のneighborChangedAddressでは、一方で終了します：アクションなし
* on HALChanged in _ThreeWay_ finishes in ThreeWay: store the new HAL
* _threeway_ 3wayで_threeway_仕上げでhalchanged：新しいhalを保存する
* on SendLie in _ThreeWay_ finishes in ThreeWay: SEND_LIE
* _threeway_のsendlieで3way：send_lieで仕上げます
* on MultipleNeighbors in MultipleNeighborsWait finishes in MultipleNeighborsWait: start multiple neighbors timer with the interval _multiple_neighbors_lie_holdtime_multiplier_ * _default_lie_holdtime_
* マルチプレーネフィートウェイトのマルチプレイングボルズウェイトのマルチプレイングボールズの仕上げでマルチプレイングボルズウェイト：インターバルで複数のネイバータイマーを開始します
* on FloodLeadersChanged in MultipleNeighborsWait finishes in MultipleNeighborsWait: update _you_are_flood_repeater_ LIE elements based on the flood leader election results
* MultipleneIghborswaitでのマルチプレイングボルスウェイトフィニッシュでFloodLeaderserschangedのoned：update _you_are_flood_repeater_洪水リーダーの選挙結果に基づく嘘要素
* on TimerTick in MultipleNeighborsWait finishes in MultipleNeighborsWait: check MultipleNeighbors timer, if the timer expired, PUSH MultipleNeighborsDone
* TimertickでMultipleneIghborswaitのMultipleNeighborswaitで仕上げます：マルチプレーネフィートタイマーをチェックしてください。
* on ValidReflection in MultipleNeighborsWait finishes in MultipleNeighborsWait: no action
* MultipleneIghborswaitのMultipleneIghborswaitのMultipleneIghborswait仕上げでの有効な反射について：アクションなし
* on UpdateZTPOffer in MultipleNeighborsWait finishes in MultipleNeighborsWait: send the offer to the ZTP FSM
* MultipleneIghborswaitのMultipleneIghborswaitのMultipleNeighborswaitのUpdateZtpofferで：ZTP FSMにオファーを送信します
* on NeighborDroppedReflection in MultipleNeighborsWait finishes in MultipleNeighborsWait: no action
* MultipleneighborswaitのMultipleneIghborswaitのMultipleneIghborswait仕上げのNeighbordroppedRefrection：アクションなし
* on LieRcvd in MultipleNeighborsWait finishes in MultipleNeighborsWait: no action
* MultipleneighborswaitのMultipleneighborswaitのMultipleneighborswaitのLiercvdで：アクションなし
* on UnacceptableHeader in MultipleNeighborsWait finishes in MultipleNeighborsWait: no action
* MultipleneIghborswaitのMultipleneIghborswaitのMultipleNeighborswaitの概要ヘッダーで：アクションなし
* on NeighborChangedAddress in MultipleNeighborsWait finishes in MultipleNeighborsWait: no action
* MultipleneIghborswaitのMultipleneIghborswaitのMultipleNeighborswaitのneveryChangedAddress：アクションなし
* on LevelChanged in MultipleNeighborsWait finishes in OneWay: update the level with the event value
* 複数の隣人でレベルチャンジで1つの方法で待機します：イベント値でレベルを更新します
* on HATChanged in MultipleNeighborsWait finishes in MultipleNeighborsWait: store HAT
* Multipleneighborswait：Store HatのMultipleneighborswait仕上げでHatchangedでhatchanged
* on MTUMismatch in MultipleNeighborsWait finishes in MultipleNeighborsWait: no action
* MultipleNeighborswaitのMultipleneIghborswaitでのMutipleneighborswaitのMtumismatchについて：アクションなし
* on HALSChanged in MultipleNeighborsWait finishes in MultipleNeighborsWait: store the HALS
* halschanged multipleneighborswait finishes in multipleneighborswait：halsを保管する
* on HALChanged in MultipleNeighborsWait finishes in MultipleNeighborsWait: store the new HAL
* MultipleneighborswaitのマルチプレイングボースウェイトフィニッシュでHalChangedでhalchanged：新しいHALを保存します
* on HoldtimeExpired in MultipleNeighborsWait finishes in MultipleNeighborsWait: no action
* on HoldTimeExpired MultipleneIghborswait Finishes in MultipleneIghborswaitでの仕上げ：アクションなし
* on SendLie in MultipleNeighborsWait finishes in MultipleNeighborsWait: no action
* MultipleneighborswaitのMultipleneighborswaitでのMultipleneighborswaitのSendlieについて：アクションなし
* on MultipleNeighborsDone in MultipleNeighborsWait finishes in OneWay: no action
* MultipleneIghborsdoneでは、マルチプレイングボルスウェイトの片方で仕上げられています。アクションなし
* on Entry into OneWay: CLEANUP
* パンウェイへのエントリ：クリーンアップ
Topology and reachability information in RIFT is conveyed by TIEs.
Riftのトポロジーとリーチ可能性情報は、Tiesによって伝えられます。
The TIE exchange mechanism uses the port indicated by each node in the LIE exchange as _flood_port_ in _LIEPacket_ and the interface on which the adjacency has been formed as the destination. TIEs MUST be sent with an IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) of either 1 or 255 and also MUST be ignored if received with values different than 1 or 255. This helps to protect RIFT information from being accepted beyond a single L3 next hop in the topology. TIEs SHOULD be sent with network control precedence unless an implementation is prevented from doing so [RFC2474].
タイ交換メカニズムは、Lie Exchangeの各ノードで示されるポートを_liepacket_の_flood_port_として使用し、隣接が宛先として形成されたインターフェイスを使用します。ネクタイは、1または255のライブ（TTL）またはIPv6ホップ制限（HL）にIPv4時間（TTL）または255の値で受信された場合は無視する必要があります。これは、トポロジーの単一のL3次のホップを超えてRIFT情報を保護するのに役立ちます。ネットワーク制御の優先順位でTIEを送信する必要があります。
TIEs contain sequence numbers, lifetimes, and a type. Each type has ample identifying number space, and information is spread across multiple TIEs with the same TIEElement type (this is true for all TIE types).
タイには、シーケンス番号、寿命、およびタイプが含まれています。各タイプには十分な識別数スペースがあり、情報は同じタイレメントタイプの複数のネクタイに広がっています（これはすべてのタイ型に当てはまります）。
More information about the TIE structure can be found in the schema in Section 7, starting with _TIEPacket_ root.
ネクタイ構造の詳細については、_tiepacket_ルートから始まるセクション7のスキーマにあります。
A central concept of RIFT is that each node represents itself differently, depending on the direction in which it is advertising information. More precisely, a spine node represents two different databases over its adjacencies, depending on whether it advertises TIEs to the north or to the south/east-west. Those differing TIE databases are called either southbound or northbound (South TIEs and North TIEs), depending on the direction of distribution.
Riftの中心的な概念は、各ノードが広告情報である方向に応じて異なることを表すことです。より正確には、脊椎ノードは、北と南/東西への関係を宣伝するかどうかに応じて、隣接する2つの異なるデータベースを表します。これらの異なるTIEデータベースは、分布の方向に応じて、南行きまたは北行き（南部と北タイ）と呼ばれます。
The North TIEs hold all of the node's adjacencies and local prefixes, while the South TIEs hold all of the node's adjacencies, the default prefix with necessary disaggregated prefixes, and local prefixes. Section 6.5 explains further details.
North Tiesはすべてのノードの隣接とローカルプレフィックスを保持しますが、サウスタイはすべてのノードの隣接、必要な分解プレフィックスを備えたデフォルトのプレフィックス、およびローカルプレフィックスを保持します。セクション6.5では、詳細について説明します。
All TIE types are mostly symmetrical in both directions. Section 7.3 defines the TIE types (i.e., the TIETypeType element) and their directionality (i.e., _direction_ within the _TIEID_ element).
すべてのタイ型は、両方向にほとんど対称的です。セクション7.3は、タイ型（つまり、TietypeType要素）とその方向性（つまり、_tieid_要素内の_direction_）を定義します。
As an example illustrating a database holding both representations, the topology in Figure 2 with the optional link between spine 111 and spine 112 (so that the flooding on an East-West link can be shown) is shown below. Unnumbered interfaces are implicitly assumed and, for simplicity, the key value elements, which may be included in their South TIEs or North TIEs, are not shown. First, Figure 15 shows the TIEs generated by some nodes.
両方の表現を保持しているデータベースを示す例として、図2のトポロジーは、スパイン111とスパイン112の間のオプションのリンク（東西リンクの洪水を示します）を以下に示します。非仮定されたインターフェイスは暗黙的に想定されており、簡単にするために、南ネクタイや北のネクタイに含まれる可能性のある重要な値要素は示されていません。まず、図15は、いくつかのノードによって生成されたタイを示しています。
ToF 21 South TIEs:
South Node TIE:
NodeTIEElement(level=2,
neighbors(
(Spine 111, level 1, cost 1, links(...)),
(Spine 112, level 1, cost 1, links(...)),
(Spine 121, level 1, cost 1, links(...)),
(Spine 122, level 1, cost 1, links(...))
)
)
South Prefix TIE:
PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1))
Spine 111 South TIEs:
South Node TIE:
NodeTIEElement(level=1,
neighbors(
(ToF 21, level 2, cost 1, links(...)),
(ToF 22, level 2, cost 1, links(...)),
(Spine 112, level 1, cost 1, links(...)),
(Leaf111, level 0, cost 1, links(...)),
(Leaf112, level 0, cost 1, links(...))
)
)
South Prefix TIE:
PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1))
Spine 111 North TIEs:
North Node TIE:
NodeTIEElement(level=1,
neighbors(
(ToF 21, level 2, cost 1, links(...)),
(ToF 22, level 2, cost 1, links(...)),
(Spine 112, level 1, cost 1, links(...)),
(Leaf111, level 0, cost 1, links(...)),
(Leaf112, level 0, cost 1, links(...))
)
)
North Prefix TIE:
PrefixTIEElement(prefixes(Spine 111.loopback)
Spine 121 South TIEs:
South Node TIE:
NodeTIEElement(level=1,
neighbors(
(ToF 21, level 2, cost 1, links(...)),
(ToF 22, level 2, cost 1, links(...)),
(Leaf121, level 0, cost 1, links(...)),
(Leaf122, level 0, cost 1, links(...))
)
)
South Prefix TIE:
PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1))
Spine 121 North TIEs:
North Node TIE:
NodeTIEElement(level=1,
neighbors(
(ToF 21, level 2, cost 1, links(...)),
(ToF 22, level 2, cost 1, links(...)),
(Leaf121, level 0, cost 1, links(...)),
(Leaf122, level 0, cost 1, links(...))
)
)
North Prefix TIE:
PrefixTIEElement(prefixes(Spine 121.loopback)
Leaf112 North TIEs:
North Node TIE:
NodeTIEElement(level=0,
neighbors(
(Spine 111, level 1, cost 1, links(...)),
(Spine 112, level 1, cost 1, links(...))
)
)
North Prefix TIE:
PrefixTIEElement(prefixes(Leaf112.loopback, Prefix112, Prefix_MH))
Figure 15: Example TIEs Generated in a 2-Level Spine-and-Leaf Topology
図15：2レベルの脊椎と葉トポロジーで生成された例のネクタイ
It may not be obvious here as to why the South Node TIEs contain all the adjacencies of the corresponding node. This will be necessary for algorithms further elaborated on in Sections 6.3.9 and 6.8.7.
ここでは、サウスノードタイに対応するノードのすべての隣接が含まれている理由については明らかではないかもしれません。これは、セクション6.3.9および6.8.7でさらに詳しく説明されているアルゴリズムに必要です。
For Node TIEs to carry more adjacencies than fit into an MTU-sized packet, the _neighbors_ element may contain a different set of neighbors in each TIE. Those disjointed sets of neighbors MUST be joined during corresponding computation. However, if the following occurs across multiple Node TIEs:
NodeタイがMTUサイズのパケットに適合するよりも多くの隣接を運ぶために、_neighbors_要素には、各タイに異なる隣接セットが含まれる場合があります。これらのばらばらの隣人のセットは、対応する計算中に結合する必要があります。ただし、複数のノードタイで以下が発生した場合：
1. _capabilities_ do not match *or*
1. _capabilities_一致しない *または *
2. _flags_ values do not match *or*
2. _flags_値は一致しません *または *
3. the same neighbor repeats in multiple TIEs with different values.
3. 同じ隣人が異なる値で複数のネクタイで繰り返されます。
The implementation is expected to use the value of any of the valid TIEs it received, as it cannot control the arrival order of those TIEs.
実装は、それらのネクタイの到着順序を制御できないため、受け取った有効なネクタイの値を使用することが期待されています。
The _miscabled_links_ element SHOULD be included in every Node TIE; otherwise, the behavior is undefined.
_miscabled_links_要素は、すべてのノードタイに含める必要があります。それ以外の場合、動作は未定義です。
A ToF node MUST include information on all other ToFs it is aware of through reflection. The _same_plane_tofs_ element is used to carry this information. To prevent MTU overrun problems, multiple Node TIEs can carry disjointed sets of ToFs, which MUST be joined to form a single set.
TOFノードには、反射を通じて認識している他のすべてのTOFに関する情報を含める必要があります。_SAME_PLANE_TOFS_要素は、この情報を携帯するために使用されます。MTUのオーバーランの問題を防ぐために、複数のノードタイは、単一のセットを形成するために結合する必要がある分裂したTOFのセットを運ぶことができます。
Different TIE types are carried in _TIEElement_. Schema enum 'common.TIETypeType' in _TIEID_ indicates which elements MUST be present in _TIEElement_. In case of a mismatch between _TIETypeType_ in the _TIEID_ and the present element, the unexpected elements MUST be ignored. In case of the lack of an expected element in the TIE, an error MUST be reported and the TIE MUST be ignored. The _positive_disaggregation_prefixes_ and _positive_external_disaggregation_prefixes_ elements MUST be advertised southbound only and ignored in North TIEs. The _negative_disaggregation_prefixes_ element MUST be propagated, according to Section 6.5.2, southwards towards lower levels to heal pathological upper-level partitioning; otherwise, traffic loss may occur in multi-plane fabrics. It MUST NOT be advertised within a North TIE and MUST be ignored otherwise.
_tieelement_では、さまざまなタイタイプが掲載されています。_tieid_のスキーマenum 'common.tietypetype' 'は、_tieelement_に存在する必要がある要素を示します。_tieid_の_tietypeType_と現在の要素の間の不一致の場合、予期しない要素を無視する必要があります。ネクタイに予想される要素がない場合は、エラーを報告する必要があり、ネクタイは無視する必要があります。_ positive_disaggregation_prefixes_および_ positive_external_disaggregation_prefixes_要素は、南行きのみ宣伝され、北のネクタイで無視する必要があります。_negative_disaggregation_prefixes_要素は、セクション6.5.2に従って、南のレベルに向かって南に向かって、病理学的上位レベルの分割を癒す必要があります。それ以外の場合、マルチプレーンファブリックでトラフィックの損失が発生する場合があります。それは北のネクタイ内で宣伝してはならず、そうでなければ無視する必要があります。
As described before, TIEs themselves are transported over UDP with the ports indicated in the LIE exchanges and use the destination address on which the LIE adjacency has been formed.
前に説明したように、ネクタイ自体は、嘘交換に示されたポートとともにUDPを介して輸送され、嘘の隣接が形成された宛先アドレスを使用します。
TIEs are uniquely identified by the _TIEID_ schema element. _TIEID_ induces a total order achieved by comparing the elements in sequence defined in the element and comparing each value as an unsigned integer of corresponding length. The _TIEHeader_ element contains a _seq_nr_ element to distinguish newer versions of the same TIE.
ネクタイは、_tieid_スキーマ要素によって一意に識別されます。_tieid_は、要素で定義されたシーケンスの要素を比較し、各値を対応する長さの符号なし整数として比較することにより、達成される合計順序を誘導します。_TieHeader_要素には、同じタイの新しいバージョンを区別するための_SEQ_NR_要素が含まれています。
_TIEHeader_ can also carry an _origination_time_ schema element (for fabrics that utilize precision timing) that contains the absolute timestamp of when the TIE was generated and an _origination_lifetime_ to indicate the original lifetime when the TIE was generated. When carried, they can be used for debugging or security purposes (e.g., to prevent lifetime modification attacks). Clock synchronization is considered in more detail in Section 6.8.4.
_tieheader_は、ネクタイが生成されたときの絶対的なタイムスタンプと_origination_lifetime_の絶対的なタイムスタンプを含む_origination_time_スキーマ要素（精密タイミングを利用するファブリック用）を持ち、タイが生成されたときの元の寿命を示すこともできます。運ばれると、デバッグやセキュリティの目的に使用できます（例：生涯修正攻撃を防ぐため）。クロック同期については、セクション6.8.4で詳細に検討します。
_remaining_lifetime_ counts down to 0 from _origination_lifetime_. TIEs with lifetimes differing by less than _lifetime_diff2ignore_ MUST be considered EQUAL (if all other fields are equal). This constant MUST be larger than _purge_lifetime_ to avoid retransmissions.
_Remaining_lifetime_は、_origination_lifetime_から0にカウントダウンします。寿命との関係は、_lifetime_diff2ignore_よりも低く異なると見なされる必要があります（他のすべてのフィールドが等しい場合）。この定数は、再送信を避けるために_purge_lifetime_よりも大きくなければなりません。
This normative ordering methodology is described in Figure 16 and MUST be used by all implementations.
この規範的順序付け方法は、図16で説明されており、すべての実装で使用する必要があります。
function Compare(X: TIEHeader, Y: TIEHeader) returns Ordering:
seq_nr of a TIEHeader = TIEHeader.seq_nr
TIEID of a TIEHeader = TIEHeader.TIEID
direction of a TIEID = TIEID.direction
# System ID
originator of a TIEID = TIEID.originator
# is of type TIETypeType
tietype of a TIEID = TIEID.tietype
tie_nr of a TIEID = TIEID.tie_nr
if X.direction > Y.direction:
return X is larger
else if X.direction < Y.direction:
return Y is larger
else if X.originator > Y.originator:
return X is larger
else if X.originator < Y.originator:
return Y is larger
else:
if X.tietype == Y.tietype:
if X.tie_nr == Y.tie_nr:
if X.seq_nr == Y.seq_nr:
X.lifetime_left = X.remaining_lifetime
- time since TIE was received
Y.lifetime_left = Y.remaining_lifetime
- time since TIE was received
if absolute_value_of(X.lifetime_left -
Y.lifetime_left) <= common.lifetime_diff2ignore:
return Both are Equal
else:
return TIEHeader with larger lifetime_left is
larger
else:
return TIEHeader with larger seq_nr is larger
else:
return TIEHeader with larger tie_nr is larger
else:
return TIEHeader with larger TIEType is larger
Figure 16: TIEHeader Comparison Function
図16：Tieheader比較機能
All valid TIE types are defined in _TIETypeType_. This enum indicates what TIE type the TIE is carrying. In case the value is not known to the receiver, the TIE MUST be reflooded with the scope identical to the scope of a prefix TIE. This allows for future extensions of the protocol that are within the same major schema and that have types that are opaque to some nodes; some restrictions are defined in Section 7.
すべての有効なタイタイプは、_tietypeType_で定義されています。この列挙は、ネクタイが携帯するタイ型を示しています。値がレシーバーに知られていない場合、ネクタイは、接頭辞タイの範囲と同じスコープで反射する必要があります。これにより、同じ主要なスキーマ内にあり、一部のノードに不透明なタイプを持つプロトコルの将来の拡張が可能になります。いくつかの制限は、セクション7で定義されています。
On reception of a TIE with an undefined level value in the packet header, the node MUST issue a warning and discard the packet.
パケットヘッダーに未定義のレベル値を持つネクタイを受信すると、ノードは警告を発行し、パケットを破棄する必要があります。
This section specifies the precise, normative flooding mechanism and can be omitted unless the reader is pursuing an implementation of the protocol or looks for a deep understanding of underlying information distribution mechanism.
このセクションでは、正確で規範的な洪水メカニズムを指定し、読者がプロトコルの実装を追求しているか、基礎となる情報配信メカニズムの深い理解を求めていない限り省略できます。
Flooding procedures are described in terms of the flooding state of an adjacency, and resulting operations on it are driven by packet arrivals. Implementations MUST implement a behavior that is externally indistinguishable from the FSMs and normative procedures given here.
洪水手順は、隣接の洪水状態の観点から説明されており、結果として生じる操作はパケットの到着によって推進されます。実装は、FSMSとここで示されている規範的手順と外部的に区別できない動作を実装する必要があります。
RIFT does not specify any kind of flood rate limiting. To help with adjustment of flooding speeds, the encoded packets provide hints to react accordingly to losses or overruns via _you_are_sending_too_quickly_ in the _LIEPacket_ and "Packet Number" in the security envelope described in Section 6.9.3. Flooding of all corresponding topology exchange elements SHOULD be performed at the highest feasible rate, but the rate of transmission MUST be throttled by reacting to packet elements and features of the system, such as queue lengths or congestion indications in the protocol packets.
Riftは、いかなる種類の洪水率の制限を指定しません。洪水速度の調整を支援するために、エンコードされたパケットは、セクション6.9.3で説明されているセキュリティエンベロープの_you_are_sending_too_quickly_を介して、_you_are_sending_too_quickly_を介して損失またはオーバーランにそれに応じて反応するヒントを提供します。対応するすべてのトポロジ交換要素の洪水は、最も実現可能な速度で実行する必要がありますが、プロトコルパケットのキューの長さや輻輳指示など、システムのパケット要素と機能に反応することにより、伝送速度をスロットする必要があります。
A node SHOULD NOT send out any topology information elements if the adjacency is not in a _ThreeWay_ state. No further tightening of this rule is possible. For example, link buffering may cause both LIEs and TIEs/TIDEs/TIREs to be reordered.
隣接が_threeway_状態にない場合、ノードはトポロジ情報要素を送信してはなりません。このルールのそれ以上の引き締めは不可能です。たとえば、リンクバッファリングにより、嘘とタイ/潮/タイヤの両方が並べ替えられる場合があります。
A node MUST drop any received TIEs/TIDEs/TIREs unless it is in the _ThreeWay_ state.
ノードは、_threeway_状態にない限り、受信したネクタイ/潮/タイヤをドロップする必要があります。
TIEs generated by other nodes MUST be reflooded. TIDEs and TIREs MUST NOT be reflooded.
他のノードによって生成されたネクタイは、反射型でなければなりません。潮とタイヤを反射的にしてはいけません。
For each adjacency, the structure conceptually contains the following elements. The word "collection" or "queue" indicates a set of elements that can be iterated over the following:
各隣接性について、構造には概念的に次の要素が含まれています。「コレクション」または「キュー」という言葉は、次のように反復できる一連の要素を示しています。
TIES_TX:
ties_tx：
Collection containing all the TIEs to transmit on the adjacency.
隣接するすべての関係を含むコレクション。
TIES_ACK:
Ties_ack：
Collection containing all the TIEs that have to be acknowledged on the adjacency.
隣接することで認められなければならないすべての関係を含むコレクション。
TIES_REQ:
ties_req：
Collection containing all the TIE headers that have to be requested on the adjacency.
隣接する場合に要求する必要があるすべてのタイヘッダーを含むコレクション。
TIES_RTX:
ties_rtx：
Collection containing all TIEs that need retransmission with the corresponding time to retransmit.
再送信に対応する時間とともに再送信を必要とするすべてのネクタイを含むコレクション。
FILTERED_TIEDB:
filtered_tiedb：
A filtered view of TIEDB, which retains for consideration only those headers permitted by is_tide_entry_filtered and which either have a lifetime left > 0 or have no content.
IS_TIDE_ENTRY_FILTEREDによって許可されているヘッダーのみを考慮するために保持されるTIEDBのフィルタリングビュー。
The following words are used for well-known elements and procedures operating on this structure:
次の単語は、この構造で動作するよく知られている要素と手順に使用されます。
TIE:
TIE:
describes either a full RIFT TIE or just the _TIEHeader_ or _TIEID_ equivalent, as defined in Section 7.3. The corresponding meaning is unambiguously contained in the context of each algorithm.
セクション7.3で定義されているように、完全なリフトタイまたは_tieheader_または_tieid_等価のみについて説明します。対応する意味は、各アルゴリズムのコンテキストに明確に含まれています。
is_flood_reduced(TIE):
is_flood_reduced（tie）：
returns whether a TIE can be flood-reduced or not.
ネクタイが洪水を減らすことができるかどうかを返します。
is_tide_entry_filtered(TIE):
is_tide_entry_filtered（tie）：
returns whether a header should be propagated in TIDE according to flooding scopes.
洪水スコープに従って、ヘッダーを潮で伝播する必要があるかどうかを返します。
is_request_filtered(TIE):
is_request_filtered（tie）：
returns whether a TIE request should be propagated to the neighbor or not, according to flooding scopes.
フラッディングスコープによると、ネクタイリクエストを隣人に伝播するかどうかを返します。
is_flood_filtered(TIE):
is_flood_filtered（tie）：
returns whether a TIE requested be flooded to the neighbor or not, according to flooding scopes.
洪水スコープによると、要求されたネクタイが隣人に浸水するかどうかを返します。
try_to_transmit_tie(TIE):
try_to_transmit_tie（tie）：
if not is_flood_filtered(TIE), then
IS_FLOOD_FILTERED（TIE）ではない場合
1. remove the TIE from TIES_RTX if present
1. 存在する場合はties_rtxからネクタイを取り外します
2. if the TIE with same key is found on TIES_ACK, then
2. 同じキーとのネクタイがties_ackで見つかった場合、
a. if the TIE is the same as or newer than TIE, do nothing, else
a. ネクタイがネクタイと同じか新しい場合は、何もしないでください。
b. remove the TIE from TIES_ACK and add TIE to TIES_TX
b. ties_ackからネクタイを削除し、ties_txにネクタイを追加します
3. else insert the TIE into TIES_TX.
3. それ以外の場合は、タイをties_txに挿入します。
ack_tie(TIE):
ack_tie（tie）：
remove the TIE from all collections and then insert the TIE into TIES_ACK.
すべてのコレクションからネクタイを取り外してから、ネクタイをties_ackに挿入します。
tie_been_acked(TIE):
tie_been_acked（tie）：
remove the TIE from all collections.
すべてのコレクションからネクタイを削除します。
remove_from_all_queues(TIE):
remove_from_all_queues（tie）：
same as _tie_been_acked_.
_tie_been_acked_と同じ。
request_tie(TIE):
request_tie（tie）：
if not is_request_filtered(TIE), then remove_from_all_queues(TIE) and add to TIES_REQ.
IS_REQUEST_FILTERED（TIE）ではない場合は、remove_from_all_queues（tie）をremaist_reqに追加します。
move_to_rtx_list(TIE):
move_to_rtx_list（tie）：
remove the TIE from TIES_TX and then add to TIES_RTX, using the TIE retransmission interval.
TIES_TXからタイを削除し、TIE_RTXに追加して、TIEの再送信間隔を使用します。
clear_requests(TIEs):
Clear_Requests（TIES）：
remove all TIEs from TIES_REQ.
すべてのネクタイをties_reqから削除します。
bump_own_tie(TIE):
bump_own_tie（tie）：
for a self-originated TIE, originate an empty or regenerate with the version number higher than the one in the TIE.
自立したネクタイの場合、ネクタイのバージョン数よりも高いバージョン数で空のまたは再生を開始します。
The collection SHOULD be served with the following priorities if the system cannot process all the collections in real time:
システムがすべてのコレクションをリアルタイムで処理できない場合は、次の優先事項をコレクションに提供する必要があります。
1. Elements on TIES_ACK should be processed with highest priority
1. Ties_ackの要素は、最優先事項で処理する必要があります
2. TIES_TX
2. ties_tx
3. TIES_REQ and TIES_RTX should be processed with lowest priority
3. ties_reqおよびties_rtxは、最小の優先度で処理する必要があります
_TIEID_ and _TIEHeader_ spaces form a strict total order (modulo incomparable sequence numbers (found in "TIEHeader.seq_nr"), as explained in Appendix A, in the very unlikely event that a TIE is "stuck" in a part of a network while the originator reboots and reissues TIEs many times to the point its sequence number rolls over and forms an incomparable distance to the "stuck" copy), which implies that a comparison relation is possible between two elements. With that, it is implicitly possible to compare TIEs, TIEHeaders, and TIEIDs to each other, whereas the shortest viable key is always implied.
_tieid_および_tieheader_スペースは厳格な合計順序（付録Aで説明されているように、ネットワークの一部でネットワークの一部でネットワークの一部で「詰まっている」という非常に重要なイベントで、付録Aで説明されているように、厳格な合計順序（Moduloの比類のないシーケンス番号（ "tieheader.seq_nr"にあります））を形成します。コピー）、これは、2つの要素間で比較関係が可能であることを意味します。それにより、タイ、タイヘッダー、タイイドを互いに比較することは暗黙的に可能ですが、最短の実行可能なキーは常に暗示されています。
NEXT_TIDE_ID:
next_tide_id：
ID of the next TIE to be sent in the TIDE.
次のネクタイのIDが潮に送られます。
As given by the timer constant, periodically generate TIDEs by:
タイマー定数によって与えられるように、定期的に潮を生成します。
1. NEXT_TIDE_ID = MIN_TIEID
1. next_tide_id = min_tieid
2. while NEXT_TIDE_ID is not equal to MAX_TIEID do:
2. next_tide_idはmax_tieid doと等しくありません：
a. HEADERS = Exactly TIRES_PER_TIDE_PKT headers from FILTERED_TIEDB starting at NEXT_TIDE_ID, unless fewer than TIRES_PER_TIDE_PKT remain, in which case all remaining headers.
a. headers = tires_tide_pktから始まるfiltered_tiedbからの正確なtires_per_tide_pktヘッダーは、tires_per_tide_pktよりも少ない場合を除き、その場合はすべてのヘッダーがすべて残ります。
b. if HEADERS is empty, then START = MIN_TIEID, else START = first element in HEADERS
b. ヘッダーが空の場合は、start = min_tieid、elseを開始=ヘッダーの最初の要素を開始します
c. if HEADERS size is less than TIRES_PER_TIDE_PKT, then END = MAX_TIEID, else END = last element in HEADERS
c. ヘッダーサイズがtires_per_tide_pktよりも少ない場合、end = max_tieid、else end = last element in headers
d. send *sorted* HEADERS as TIDE, setting START and END as its range
d. 潮のように *ソートされた *ヘッダーを送信し、その範囲として開始と終了を設定します
e. NEXT_TIDE_ID = END
e. next_tide_id = end
The constant _TIRES_PER_TIDE_PKT_ SHOULD be computed per interface and used by the implementation to limit the amount of TIE headers per TIDE so the sent TIDE PDU does not exceed the MTU of the interface.
定数_tires_per_tide_pkt_は、インターフェイスごとに計算され、実装で使用されて、潮の潮のタイヘッダーの量を制限して、送信される潮pduがインターフェイスのMTUを超えないようにする必要があります。
TIDE PDUs SHOULD be transmitted at a rate that does not lead to packet drops.
潮pdusは、パケットドロップにつながらない速度で送信する必要があります。
The algorithm will intentionally enter the loop once and send a single TIDE, even when the database is empty; otherwise, no TIDEs would be sent for in case of an empty database and break the intended synchronization.
アルゴリズムは、データベースが空であっても、意図的にループを1回入力し、単一の潮を送信します。それ以外の場合、空のデータベースの場合、意図した同期を破るために潮は送られません。
TXKEYS:
txkeys：
Collection of TIE headers to be sent after processing of the packet
パケットの処理後に送信されるタイヘッダーのコレクション
REQKEYS:
reqkeys：
Collection of TIEIDs to be requested after processing of the packet
パケットの処理後にリクエストされるTieidsのコレクション
CLEARKEYS:
ClearKeys：
Collection of TIEIDs to be removed from flood state queues
洪水状態のキューから削除されるTieidsのコレクション
LASTPROCESSED:
Last -Processed：
Last processed TIEID in the TIDE
潮の最後の加工されたタイド
DBTIE:
DBTIE：
TIE in the LSDB, if found
見つかった場合、LSDBを結びます
On reception of TIDEs, the following processing is performed:
潮の受容時に、次の処理が実行されます。
1. LASTPROCESSED = TIDE.start_range
1. lastprocessed = tide.start_range
2. For every HEADER in the TIDE do:
2. 潮のすべてのヘッダーについて：
a. DBTIE = find HEADER in the current LSDB
a. dbtie =現在のLSDBでヘッダーを見つけます
b. if HEADER < LASTPROCESSED, then report an error and reset the adjacency and return
b. header <last -processedの場合、エラーを報告し、隣接をリセットして返します
c. put all TIEs in LSDB, where (TIE.HEADER > LASTPROCESSED and TIE.HEADER < HEADER) into TXKEYS
c. すべてのネクタイをLSDBに入れます。
d. LASTPROCESSED = HEADER
d. LastProcessed = Header
e. if DBTIE is not found, then
e. DBTIEが見つからない場合は、
i. if originator is this node, then bump_own_tie
i. Originatorがこのノードの場合、bump_own_tie
ii. else put HEADER into REQKEYS
ii。それ以外の場合は、ヘッダーをreqkeysに入れます
f. if DBTIE.HEADER < HEADER then
f. dbtie.header <header thenの場合
i. if the originator is this node, then bump_own_tie, else
i. オリジネーターがこのノードの場合、bump_own_tie、else
1. if this is a North TIE header from a northbound neighbor, then override DBTIE in LSDB with HEADER
1. これが北行きの隣人からのノースタイヘッダーの場合は、LSDBのDBTIEをヘッダーでオーバーライドします
2. else put HEADER into REQKEYS
2. それ以外の場合は、ヘッダーをreqkeysに入れます
g. if DBTIE.HEADER > HEADER, then put DBTIE.HEADER into TXKEYS
g. dbtie.header>ヘッダーの場合、dbtie.headerをtxkeysに入れます
h. if DBTIE.HEADER = HEADER, then
h. dbtie.header = headerの場合
i. if DBTIE has content already, then put DBTIE.HEADER into CLEARKEYS, else
i. DBTIEがすでにコンテンツを持っている場合は、Dbtie.headerをClearKeysに入れます。
ii. put HEADER into REQKEYS
ii。ヘッダーをreqkeysに入れます
3. put all TIEs in LSDB, where (TIE.HEADER > LASTPROCESSED and TIE.HEADER <= TIDE.end_range) into TXKEYS
3. すべてのネクタイをLSDBに入れます。
4. for all TIEs in TXKEYS, try_to_transmit_tie(TIE)
4. txkeysのすべてのネクタイについて、try_to_transmit_tie（tie）
5. for all TIEs in REQKEYS, request_tie(TIE)
5. reqkeysのすべてのネクタイについて、request_tie（tie）
6. for all TIEs in CLEARKEYS, remove_from_all_queues(TIE)
6. ClearKeysのすべてのネクタイについては、remove_from_all_queues（tie）
Elements from both TIES_REQ and TIES_ACK MUST be collected and sent out as fast as feasible as TIREs. When sending TIREs with elements from TIES_REQ, the _remaining_lifetime_ field in _TIEHeaderWithLifeTime_ MUST be set to 0 to force reflooding from the neighbor even if the TIEs seem to be the same.
Ties_ReqとTies_ackの両方の要素は、タイヤと同じくらい速度に収集し、送信する必要があります。ties_reqから要素を含むタイヤを送信する場合、_tieheaderwithlifetime_の_remaining_lifetime_フィールドは、ネクタイが同じように見えても、隣人からの反射性を強制するために0に設定する必要があります。
TXKEYS:
txkeys：
Collection of TIE headers to be sent after processing of the packet
パケットの処理後に送信されるタイヘッダーのコレクション
REQKEYS:
reqkeys：
Collection of TIEIDs to be requested after processing of the packet
パケットの処理後にリクエストされるTieidsのコレクション
ACKKEYS:
Ackkeys：
Collection of TIEIDs that have been acknowledged
認められたTieidのコレクション
DBTIE:
DBTIE：
TIE in the LSDB, if found
見つかった場合、LSDBを結びます
On reception of TIREs, the following processing is performed:
タイヤの受信時に、次の処理が実行されます。
1. for every HEADER in TIRE do:
1. タイヤのすべてのヘッダーについて：
a. DBTIE = find HEADER in the current LSDB
a. dbtie =現在のLSDBでヘッダーを見つけます
b. if DBTIE is not found, then do nothing
b. DBTIEが見つからない場合は、何もしません
c. if DBTIE.HEADER < HEADER, then put HEADER into REQKEYS
c. dbtie.header <headerの場合、ヘッダーをreqkeysに入れます
d. if DBTIE.HEADER > HEADER, then put DBTIE.HEADER into TXKEYS
d. dbtie.header>ヘッダーの場合、dbtie.headerをtxkeysに入れます
e. if DBTIE.HEADER = HEADER, then put DBTIE.HEADER into ACKKEYS
e. dbtie.header = headerの場合、dbtie.headerをackkeysに入れます
2. for all TIEs in TXKEYS, try_to_transmit_tie(TIE)
2. txkeysのすべてのネクタイについて、try_to_transmit_tie（tie）
3. for all TIEs in REQKEYS, request_tie(TIE)
3. reqkeysのすべてのネクタイについて、request_tie（tie）
4. for all TIEs in ACKKEYS, tie_been_acked(TIE)
4. Ackkeysのすべてのネクタイについては、tie_been_acked（tie）
On reception of TIEs, the following processing is performed:
ネクタイの受信時に、次の処理が実行されます。
ACKTIE:
Acktie：
TIE to acknowledge
認めるためにネクタイ
TXTIE:
txtie：
TIE to transmit
送信するためにネクタイ
DBTIE:
DBTIE：
TIE in the LSDB, if found
見つかった場合、LSDBを結びます
1. DBTIE = find TIE in the current LSDB
1. dbtie =現在のLSDBでネクタイを見つけます
2. if DBTIE is not found, then
2. DBTIEが見つからない場合は、
a. if the originator is this node, then bump_own_tie with a short remaining lifetime
a. オリジネーターがこのノードの場合、残りの寿命のbumb_own_tie
b. else insert TIE into LSDB and ACKTIE = TIE
b. それ以外の場合は、タイをlsdbとacktie = tieに挿入します
else
それ以外
a. if DBTIE.HEADER = TIE.HEADER, then
a. dbtie.header = tie.headerの場合
i. if DBTIE has content already, then ACKTIE = TIE
i. DBTIEが既にコンテンツを持っている場合、Acktie = Tie
ii. else process like the "DBTIE.HEADER < TIE.HEADER" case
ii。それ以外の場合は、「dbtie.header <tie.header」ケースのような処理
b. if DBTIE.HEADER < TIE.HEADER, then
b. dbtie.header <tie.headerの場合
i. if the originator is this node, then bump_own_tie
i. オリジネーターがこのノードの場合、bump_own_tie
ii. else insert TIE into LSDB and ACKTIE = TIE
ii。それ以外の場合は、タイをlsdbとacktie = tieに挿入します
c. if DBTIE.HEADER > TIE.HEADER, then
c. dbtie.header> tie.headerの場合
i. if DBTIE has content already, then TXTIE = DBTIE
i. dbtieがすでにコンテンツを持っている場合、txtie = dbtie
ii. else ACKTIE = DBTIE
ii。else acktie = dbtie
3. if TXTIE is set, then try_to_transmit_tie(TXTIE)
3. txtieが設定されている場合、try_to_transmit_tie（txtie）
4. if ACKTIE is set, then ack_tie(TIE)
4. acktieが設定されている場合、ack_tie（tie）
On a periodic basis, all TIEs with a lifetime of > 0 left MUST be sent out on the adjacency, removed from the TIES_TX list, and requeued onto TIES_RTX list. The specific period is out of scope for this document.
定期的に、残りの寿命が残っている寿命のあるすべての関係は、隣接に送信され、TIES_TXリストから削除され、TIES_RTXリストに要求する必要があります。特定の期間は、このドキュメントの範囲外です。
The LSDB holds the most recent copy of TIEs received via flooding from according peers. Consecutively, after version tie-breaking by LSDB, a peer receives from the LSDB the newest versions of TIEs received by other peers and processes them (without any filtering) just like receiving TIEs from its remote peer. Such a publisher model can be implemented in several ways, either in a single thread of execution or in multiple parallel threads.
LSDBは、仲間からの洪水で受け取ったネクタイの最新のコピーを保持しています。連続して、LSDBによるバージョンのタイブレイキングの後、ピアはLSDBから他のピアが受け取った最新バージョンのネクタイを受け取り、リモートピアからネクタイを受け取るように（フィルタリングなしで）処理します。このようなパブリッシャーモデルは、実行の単一スレッドまたは複数の並列スレッドのいずれかで、いくつかの方法で実装できます。
LSDB can be logically considered as the entity aging out TIEs, i.e., being responsible to discard TIEs that are stored longer than _remaining_lifetime_ on their reception.
LSDBは、エンティティが老化するエンティティと見なすことができます。つまり、レセプションで_Remaining_lifetime_よりも長く保存されている関係を破棄する責任があります。
LSDB is also expected to periodically reoriginate the node's own TIEs. Originating at an interval significantly shorter than _default_lifetime_ is RECOMMENDED to prevent TIE expiration by other nodes in the network, which can lead to instabilities.
LSDBはまた、ノード自身の関係を定期的に再保持することも期待されています。_default_lifetime_よりも大幅に短い間隔で発信されることは、ネットワーク内の他のノードによるタイの有効期限を防ぐために推奨されます。
In a somewhat analogous fashion to link-local, area, and domain flooding scopes, RIFT defines several complex "flooding scopes", depending on the direction and type of TIE propagated.
リンクローカル、エリア、ドメインの洪水スコープに多少類似した方法で、Riftは、伝播されたタイの方向とタイプに応じて、いくつかの複雑な「洪水スコープ」を定義します。
Every North TIE is flooded northbound, providing a node at a given level with the complete topology of the Clos or fat tree network that is reachable southwards of it, including all specific prefixes. This means that a packet received from a node at the same or lower level whose destination is covered by one of those specific prefixes will be routed directly towards the node advertising that prefix, rather than sending the packet to a node at a higher level.
すべての北のネクタイは北に浸水し、特定のレベルでノードを提供し、すべての特定のプレフィックスを含む、その南に到達可能なクローズまたはファットツリーネットワークの完全なトポロジーを提供します。これは、宛先がこれらの特定のプレフィックスのいずれかでカバーされている同じレベルまたは低いレベルのノードから受信したパケットが、より高いレベルでパケットをノードに送信するのではなく、そのプレフィックスのノード広告に直接ルーティングされることを意味します。
A node's South Node TIEs, consisting of all node's adjacencies and South Prefix TIEs limited to those related to default IP prefix and disaggregated prefixes, are flooded southbound in order to inform nodes one level down of connectivity of the higher level as well as reachability to the rest of the fabric. In order to allow an E-W disconnected node in a given level to receive the South TIEs of other nodes at its level, every South Node TIE is "reflected" northbound to the level from which it was received. It should be noted that East-West links are included in South TIE flooding (except at the ToF level); those TIEs need to be flooded to satisfy the algorithms described in Section 6.4. In that way, nodes at same level can learn about each other without using a lower level except in case of leaf level. The precise, normative flooding scopes are given in Table 3. Those rules also govern what SHOULD be included in TIDEs on the adjacency. Again, East-West flooding scopes are identical to southern flooding scopes, except in case of ToF East-West links (rings), which are basically performing northbound flooding.
すべてのノードの隣接とサウスプレフィックスタイで構成されるノードのサウスノードタイは、デフォルトのIPプレフィックスと分解プレフィックスに関連するものに限定されているものであり、ノードがより高いレベルの接続性と残りの生地への到達可能性を通知するために南に浸水します。特定のレベルでE-W切断されたノードをそのレベルで他のノードの南タイを受信できるようにするために、すべての南ノードタイは、それが受信されたレベルまで北に「反射」されます。東西リンクは南ネクタイの洪水に含まれていることに注意する必要があります（TOFレベルを除く）。セクション6.4で説明されているアルゴリズムを満たすために、これらのネクタイを浸水させる必要があります。そのようにして、同じレベルのノードは、葉のレベルの場合を除いて、より低いレベルを使用せずに互いに学習できます。正確で規範的な洪水スコープを表3に示します。これらのルールは、隣接の潮に含まれるべきものも規定しています。繰り返しになりますが、東西の洪水スコープは、基本的に北行きの洪水を実行しているTOF東西リンク（リング）の場合を除き、南部の洪水スコープと同じです。
South Node TIE "south reflection" enables support of positive disaggregation on failures, as described in Section 6.5, and flooding reduction, as described in Section 6.3.9.
South Node Tie "South Reflection"は、セクション6.5で説明されているように、セクション6.3.9で説明されているように、故障に対する肯定的な分解のサポートを可能にします。
+===========+======================+==============+=================+
| Type / | South | North | East-West |
| Direction | | | |
+===========+======================+==============+=================+
| South | flood if the level | flood if the | flood only if |
| Node TIE | of the originator | level of the | this node is |
| | is equal to this | originator | not ToF |
| | node | is higher | |
| | | than this | |
| | | node | |
+-----------+----------------------+--------------+-----------------+
| non-Node | flood self- | flood only | flood only if |
| South TIE | originated only | if the | it is self- |
| | | neighbor is | originated and |
| | | the | this node is |
| | | originator | not ToF |
| | | of TIE | |
+-----------+----------------------+--------------+-----------------+
| all North | never flood | flood always | flood only if |
| TIEs | | | this node is |
| | | | ToF |
+-----------+----------------------+--------------+-----------------+
| TIDE | include at least | include at | if this node is |
| | all non-self- | least all | ToF, then |
| | originated North | South Node | include all |
| | TIE headers and | TIEs and all | North TIEs; |
| | self-originated | South TIEs | otherwise, only |
| | South TIE headers | originated | include self- |
| | and South Node TIEs | by a peer | originated TIEs |
| | of nodes at same | and all | |
| | level | North TIEs | |
+-----------+----------------------+--------------+-----------------+
| TIRE as | request all North | request all | if this node is |
| Request | TIEs and all peer's | South TIEs | ToF, then apply |
| | self-originated | | north scope |
| | TIEs and all South | | rules; |
| | Node TIEs | | otherwise, |
| | | | apply south |
| | | | scope rules |
+-----------+----------------------+--------------+-----------------+
| TIRE as | Ack all received | Ack all | Ack all |
| Ack | TIEs | received | received TIEs |
| | | TIEs | |
+-----------+----------------------+--------------+-----------------+
Table 3: Normative Flooding Scopes
表3：規範的な洪水スコープ
If the TIDE includes additional TIE headers beside the ones specified, the receiving neighbor must apply the corresponding filter to the received TIDE strictly and MUST NOT request the extra TIE headers that were not allowed by the flooding scope rules in its direction.
潮に指定されたものの横に追加のタイヘッダーが含まれている場合、受信隣人は対応するフィルターを厳密に受信した潮に適用する必要があり、その方向に洪水スコープルールで許可されていない追加のタイヘッダーを要求してはなりません。
To illustrate these rules, consider using the topology in Figure 2, with the optional link between spine 111 and spine 112, and the associated TIEs given in Figure 15. The flooding from particular nodes of the TIEs is given in Table 4.
これらのルールを説明するために、図2のトポロジーを使用することを検討します。スパイン111とスパイン112の間のオプションのリンク、および図15に示された関連する結びつき。タイの特定のノードからの洪水を表4に示します。
+============+==========+===========================================+
| Local | Neighbor | TIEs Flooded from Local to Neighbor Node |
| Node | Node | |
+============+==========+===========================================+
| Leaf111 | Spine | Leaf111 North TIEs, Spine 111 South Node |
| | 112 | TIE |
+------------+----------+-------------------------------------------+
| Leaf111 | Spine | Leaf111 North TIEs, Spine 112 South Node |
| | 111 | TIE |
+------------+----------+-------------------------------------------+
| ... | ... | ... |
+------------+----------+-------------------------------------------+
| Spine | Leaf111 | Spine 111 South TIEs |
| 111 | | |
+------------+----------+-------------------------------------------+
| Spine | Leaf112 | Spine 111 South TIEs |
| 111 | | |
+------------+----------+-------------------------------------------+
| Spine | Spine | Spine 111 South TIEs |
| 111 | 112 | |
+------------+----------+-------------------------------------------+
| Spine | ToF 21 | Spine 111 North TIEs, Leaf111 North TIEs, |
| 111 | | Leaf112 North TIEs, ToF 22 South Node TIE |
+------------+----------+-------------------------------------------+
| Spine | ToF 22 | Spine 111 North TIEs, Leaf111 North TIEs, |
| 111 | | Leaf112 North TIEs, ToF 21 South Node TIE |
+------------+----------+-------------------------------------------+
| ... | ... | ... |
+------------+----------+-------------------------------------------+
| ToF 21 | Spine | ToF 21 South TIEs |
| | 111 | |
+------------+----------+-------------------------------------------+
| ToF 21 | Spine | ToF 21 South TIEs |
| | 112 | |
+------------+----------+-------------------------------------------+
| ToF 21 | Spine | ToF 21 South TIEs |
| | 121 | |
+------------+----------+-------------------------------------------+
| ToF 21 | Spine | ToF 21 South TIEs |
| | 122 | |
+------------+----------+-------------------------------------------+
| ... | ... | ... |
+------------+----------+-------------------------------------------+
Table 4: Flooding Some TIEs from Example Topology
表4：トポロジの例からいくつかのネクタイをあふれさせます
The optional RIFT Adjacency Inrush Notification (RAIN) mechanism helps to prevent adjacencies from being overwhelmed by flooding on restart or bring-up with many southbound neighbors. In its LIEs, a node MAY set the corresponding _you_are_sending_too_quickly_ flag to indicate to the neighbor that it SHOULD flood Node TIEs with normal speed and significantly slow down the flooding of any other TIEs. The flag SHOULD be set only in the southbound direction. The receiving node SHOULD accommodate the request to lessen the flooding load on the affected node if it is south of the sender and should ignore the indication if it is north of the sender.
オプションのRift隣接隣接イングラッシュ通知（雨）メカニズムは、再起動時に洪水または多くの南行きの隣人との枠組みによって圧倒されるのを防ぐのに役立ちます。その嘘では、ノードは、対応する_you_are_sending_too_quickly_フラグを設定して、隣人に通常の速度で結び付けられ、他のネクタイの洪水を大幅に遅くする必要があることを隣人に示します。フラグは南方向にのみ設定する必要があります。受信ノードは、送信者の南にある場合、影響を受けるノードの洪水負荷を軽減するという要求に対応する必要があり、送信者の北の場合は表示を無視する必要があります。
The distribution of Node TIEs at normal speed, even at high load, guarantees correct behavior of algorithms like disaggregation or default route origination. Furthermore though, the use of this bit presents an inherent trade-off between processing load and convergence speed since significantly slowing down flooding of northbound prefixes from neighbors for an extended time will lead to traffic losses.
ノードの分布は、通常の速度でも、高負荷であっても、分解やデフォルトルートのオリジネーションなどのアルゴリズムの正しい動作を保証します。さらに、このビットの使用は、長時間近隣から北行きの接頭辞の洪水を大幅に遅くすると、交通量の損失につながるため、処理負荷と収束速度の間に固有のトレードオフを示します。
The initial exchange of RIFT includes periodic TIDE exchanges that contain descriptions of the LSDB and TIREs, which perform the function of requesting unknown TIEs as well as confirming the reception of flooded TIEs. The content of TIDEs and TIREs is governed by Table 3.
Riftの最初の交換には、LSDBとタイヤの説明を含む定期的な潮交換が含まれ、未知のネクタイを要求する機能を実行し、浸水したネクタイの受信を確認します。潮とタイヤの含有量は、表3で管理されています。
When a node exits the network, if "unpurged", residual stale TIEs may exist in the network until their lifetimes expire (which in case of RIFT is by default a rather long period to prevent ongoing reorigination of TIEs in very large topologies). RIFT does not have a "purging mechanism" based on sending specialized "purge" packets. In other routing protocols, such a mechanism has proven to be complex and fragile based on many years of experience. RIFT simply issues a new, i.e., higher sequence number, empty version of the TIE with a short lifetime given by the _purge_lifetime_ constant and relies on each node to age out and delete each TIE copy independently. Abundant amounts of memory are available today, even on low-end platforms, and hence, keeping those relatively short-lived extra copies for a while is acceptable. The information will age out and, in the meantime, all computations will deliver correct results if a node leaves the network due to the new information distributed by its adjacent nodes breaking bidirectional connectivity checks in different computations.
ノードがネットワークを終了すると、「埋められていない」場合、寿命が切れるまでネットワークに残留古いネクタイが存在する可能性があります（リフトの場合、デフォルトでは非常に大きなトポロジのネクタイの継続的な再起動を防ぐためにかなり長い期間です）。Riftには、特殊な「パージ」パケットの送信に基づく「パージメカニズム」はありません。他のルーティングプロトコルでは、このようなメカニズムは、長年の経験に基づいて複雑で脆弱であることが証明されています。Riftは、_Purge_lifetime_定数によって与えられた短い寿命のある新しい、つまり、より高いシーケンス番号、タイの空のバージョンを発行するだけで、各ノードに依存して各ネクタイコピーを独立して削除します。ローエンドのプラットフォームでも、豊富な量のメモリが利用可能であるため、しばらくの間、比較的短命の追加コピーを保持することは受け入れられます。情報は老化し、その間に、すべての計算は、さまざまな計算で隣接するノードによって分配された新しい情報が隣接するノードによって分散された新しい情報のためにネットワークを離れると、すべての計算が正しい結果をもたらします。
Once a RIFT node issues a TIE with an ID, it SHOULD preserve the ID as long as feasible (also when the protocol restarts), even if the TIE looses all content. The re-advertisement of an empty TIE fulfills the purpose of purging any information advertised in previous versions. The originator is free to not reoriginate the corresponding empty TIE again or originate an empty TIE with a relatively short lifetime to prevent a large number of long-lived empty stubs polluting the network. Each node MUST time out and clean up the corresponding empty TIEs independently.
RiftノードがIDでネクタイを発行すると、タイがすべてのコンテンツを失った場合でも、実行可能な場合（プロトコルが再起動するときに）IDを保持する必要があります。空のネクタイの再承認は、以前のバージョンで宣伝されている情報をパージする目的を果たします。オリジネーターは、対応する空のネクタイを再び再調整したり、ネットワークを汚染している多数の長寿命の空のスタブを防ぐために、比較的短い寿命で空のネクタイを起源としています。各ノードはタイムアウトして、対応する空のネクタイを個別にクリーンアップする必要があります。
Upon restart, a node MUST be prepared to receive TIEs with its own System ID and supersede them with equivalent, newly generated, empty TIEs with a higher sequence number. As above, the lifetime can be relatively short since it only needs to exceed the necessary propagation and processing delay by all the nodes that are within the TIE's flooding scope.
再起動すると、ノードを独自のシステムIDでネクタイを受信し、より高いシーケンス番号を持つ同等の新しく生成された空のネクタイでそれらを置き換える必要があります。上記のように、ネクタイの洪水範囲内にあるすべてのノードによって必要な伝播と処理の遅延を超えるだけが必要なため、寿命は比較的短い場合があります。
TIE sequence numbers are rolled over using the method described in Appendix A . The first sequence number of any spontaneously originated TIE (i.e., not originated to override a detected older copy in the network) MUST be a reasonably unpredictable random number (for example, [RFC4086]) in the interval [0, 2^30-1], which will prevent otherwise identical TIE headers to remain "stuck" in the network with content different from the TIE originated after reboot. In typical link-state protocols, this is delegated to a 16-bit checksum on packet content. RIFT avoids this design due to the CPU burden presented by computation of such checksums and additional complications tied to the fact that the checksum must be "patched" into the packet after the generation of the content, which is a difficult proposition in binary, hand-crafted formats already and highly incompatible with model-based, serialized formats. The sequence number space is hence consciously chosen to be 64-bits wide to make the occurrence of a TIE with the same sequence number but different content as much or even more unlikely than the checksum method. To emulate the "checksum behavior", an implementation could choose to compute a 64-bit checksum or hash function over the TIE content and use that as part of the first sequence number after reboot.
付録Aで説明した方法を使用して、タイシーケンス番号が巻き上げられます。自発的に発生したネクタイの最初のシーケンス番号（つまり、ネットワーク内の検出された古いコピーをオーバーライドするように発生しない）は、間隔[0、2^30-1]の合理的に予測不可能な乱数（たとえば[RFC4086]）でなければなりません。典型的なリンク状態プロトコルでは、これはパケットコンテンツの16ビットチェックサムに委任されます。Riftは、このようなチェックサムの計算によって提示されたCPUの負担と、コンテンツの生成後にチェックサムをパケットに「パッチ」しなければならないという事実に関連する追加の合併症によって提示されるCPUの負担により、この設計を回避します。したがって、シーケンス番号スペースは、同じシーケンス番号でタイの発生を行うために64ビットの幅であると意識的に選択されますが、チェックサム法とは異なるコンテンツとは異なります。「チェックサムの動作」をエミュレートするために、実装は、タイコンテンツに対して64ビットチェックサムまたはハッシュ関数を計算し、再起動後の最初のシーケンス番号の一部として使用することを選択できます。
Under certain conditions, nodes issue a default route in their South Prefix TIEs with costs as computed in Section 6.8.7.1.
特定の条件下では、ノードは、セクション6.8.7.1で計算されているように、コストとサウスプレフィックスの関係にデフォルトルートを発行します。
A node X that
ノードxそれ
1. is *not* overloaded *and*
1. *過負荷ではありません *と *
2. has southbound or East-West adjacencies
2. 南行きまたは東西の隣接があります
SHOULD originate such a default route in its South Prefix TIE if and only if
サウスプレフィックスタイのそのようなデフォルトルートを発信する必要があります
1. all other nodes at X's level are overloaded *or*
1. Xのレベルの他のすべてのノードは過負荷になります *または *
2. all other nodes at X's level have NO northbound adjacencies, *or*
2. Xのレベルの他のすべてのノードには、北行きの隣接がありません *または *
3. X has computed reachability to a default route during N-SPF.
3. Xは、N-SPF中にデフォルトルートに到達可能性を計算しました。
The term "all other nodes at X's level" obviously describes just the nodes at the same level in the PoD with a viable lower level (otherwise, the South Node TIEs cannot be reflected; the nodes in PoD 1 and PoD 2 are "invisible" to each other).
「Xのレベルの他のすべてのノード」という用語は、明らかに、実行可能な低レベルのポッドの同じレベルのノードのみを記述しています（そうでなければ、南ノードのネクタイは反射できません。ポッド1とポッド2のノードは互いに「見えない」）。
A node originating a southbound default route SHOULD install a default discard route if it did not compute a default route during N-SPF. This basically means that the top of the fabric will drop traffic for unreachable addresses.
サウスバウンドデフォルトルートを発信するノードは、N-SPF中にデフォルトルートを計算しなかった場合、デフォルトの破棄ルートをインストールする必要があります。これは基本的に、生地の上部が到達不可能なアドレスのためにトラフィックを落とすことを意味します。
RIFT chooses only a subset of northbound nodes to propagate flooding and, with that, both balances it (to prevent "hot" flooding links) across the fabric as well as reduces its volume. The solution is based on several principles:
Riftは、洪水を伝播するために北行きのノードのサブセットのみを選択し、それとともに、両方ともファブリック全体で（「ホット」フラッディングリンクを防ぐために）バランスを取り、ボリュームを減らします。解決策は、いくつかの原則に基づいています。
1. a node MUST flood self-originated North TIEs to all the reachable nodes at the level above, which is called the node's "parents";
1. ノードは、ノードの「親」と呼ばれるレベルのすべての到達可能なノードに、自己造影した北のネクタイを浸水させる必要があります。
2. it is typically not necessary that all parents reflood the North TIEs to achieve a complete flooding of all the reachable nodes two levels above, which we call the node's "grandparents";
2. 通常、すべての親が北の結びつきを反射して、上記の2レベルのすべての到達可能なノードの完全な洪水を達成する必要はありません。これは、ノードの「祖父母」と呼ばれます。
3. to control the volume of its flooding two hops north and yet keep it robust enough, it is advantageous for a node to select a subset of its parents as "Flood Repeaters" (FRs), which when combined, deliver two or more copies of its flooding to all of its parents, i.e., the originating node's grandparents;
3. 北の2ホップの洪水の量を制御するために、それを十分に堅牢に保つために、ノードが両親のサブセットを「洪水リピーター」（FRS）として選択することが有利です。
4. nodes at the same level do *not* have to agree on a specific algorithm to select the FRs, but overall load balancing should be achieved so that different nodes at the same level should tend to select different parents as FRs (consideration of possible strategies in an unrelated but similar field can be found in [RFC2991]);
4. 同じレベルのノードは、FRSを選択するために特定のアルゴリズムに同意する必要はありませんが、同じレベルの異なるノードがFRSとして異なる親として異なる親を選択する傾向があるように、全体的な負荷分散を達成する必要があります（[RFC2991]には、関連していないが同様の分野で可能な戦略を考慮することができます）;
5. there are usually many solutions to the problem of finding a set of FRs for a given node; the problem of finding the minimal set is (similar to) an NP-Complete problem, and a globally optimal set may not be the minimal one if load balancing with other nodes is an important consideration;
5. 通常、特定のノードに対してFRSのセットを見つけるという問題には多くの解決策があります。最小限のセットを見つける問題は、NP完全な問題であり、他のノードとの負荷バランスが重要な考慮事項である場合、グローバルに最適なセットは最小限ではない場合があります。
6. it is expected that sets of equivalent nodes at a level L will often exist, defined as having a common set of parents at L+1. Applying this observation at both L and L+1, an algorithm may attempt to split the larger problem in a sum of smaller, separate problems; and
6. レベルLの同等のノードのセットがしばしば存在し、L+1に共通の親のセットを持つと定義されることが予想されます。この観察結果をLとL+1の両方で適用すると、アルゴリズムはより小さな問題の合計で大きな問題を分割しようとする場合があります。そして
7. it is expected that there will be a broken link between a parent and a grandparent from time to time, and in that case, the parent is probably a poor FR due to its lower reliability. An algorithm may attempt to eliminate parents with broken northbound adjacencies first in order to reduce the number of FRs. Albeit it could be argued that relying on higher fanout FRs will slow flooding due to higher replication, load reliability of FR's links is likely a more pressing concern.
7. 親と祖父母の間に時々壊れたリンクがあることが予想されます。その場合、親はおそらくその信頼性が低いため貧しいFRです。アルゴリズムは、FRSの数を減らすために、最初に北行きの隣接を壊した親を排除しようとする場合があります。より高いファンアウトFRSに依存すると、より高い複製により洪水が遅くなると主張することができますが、FRのリンクの負荷の信頼性はより差し迫った懸念である可能性があります。
In a fully connected Clos network, this means that a node selects one arbitrary parent as the FR and then a second one for redundancy. The computation can be relatively simple and completely distributed without any need for synchronization among nodes. In a "PoD" structure, where the level L+2 is partitioned into silos of equivalent grandparents that are only reachable from respective parents, this means treating each silo as a fully connected Clos network and solving the problem within the silo.
これは、完全に接続されたクローズネットワークでは、ノードがFRとして1つの任意の親を選択し、次に冗長性のために2番目の親を選択することを意味します。計算は比較的単純で、ノード間の同期を必要とせずに完全に分布することができます。レベルL+2がそれぞれの親からのみ到達可能な同等の祖父母のサイロに分割される「ポッド」構造では、各サイロを完全に接続されたクローズネットワークとして扱い、サイロ内の問題を解決することを意味します。
In terms of signaling, a node has enough information to select its set of FRs; this information is derived from the node's parents' South Node TIEs, which indicate the parent's reachable northbound adjacencies to its own parents (the node's grandparents). A node may send a LIE to a northbound neighbor with the optional boolean field _you_are_flood_repeater_ set to false to indicate that the northbound neighbor is not a flood repeater for the node that sent the LIE. In that case, the northbound neighbor SHOULD NOT reflood northbound TIEs received from the node that sent the LIE. If _you_are_flood_repeater_ is absent or _you_are_flood_repeater_ is set to true, then the northbound neighbor is a flood repeater for the node that sent the LIE and MUST reflood northbound TIEs received from that node. The element _you_are_flood_repeater_ MUST be ignored if received from a northbound adjacency.
シグナリングに関しては、ノードにはFRSのセットを選択するのに十分な情報があります。この情報は、ノードの両親のサウスノードネクタイから派生しており、親の親の到達可能な北行きの隣接を自分の親（ノードの祖父母）に導くことを示しています。ノードは、オプションのブールフィールド_you_are_flood_repeater_をfalseに設定して、北行きの隣人に嘘を送ることができます。その場合、北行きの隣人は、嘘をついたノードから受け取った北行きのネクタイを反射してはなりません。_you_are_flood_repeater_が存在しない場合、または_you_are_flood_repeater_がtrueに設定されている場合、北行きの隣人は嘘を送ったノードの洪水リピーターであり、そのノードから受け取った北行きのネクタイを反映しなければなりません。要素_you_are_flood_repeater_は、北行きの隣接から受け取った場合は無視する必要があります。
This specification provides a simple default algorithm that SHOULD be implemented and used by default on every RIFT node.
この仕様は、すべてのRIFTノードでデフォルトで実装および使用する必要があるシンプルなデフォルトアルゴリズムを提供します。
* let |NA(Node) be the set of northbound adjacencies of node Node and CN(Node) be the cardinality of |NA(Node);
* | na（ノード）は、ノードノードとcn（ノード）のノースバウンド隣接のセットとし、| na（ノード）のカーディナリティとします。
* let |SA(Node) be the set of southbound adjacencies of node Node and CS(Node) be the cardinality of |SA(Node);
* | sa（ノード）を、ノードノードとcs（ノード）のサウスバウンド隣接のセットとし、| sa（ノード）のカーディナリティとします。
* let |P(Node) be the set of node Node's parents;
* | p（ノード）をノードノードの両親のセットとします。
* let |G(Node) be the set of node Node's grandparents. Observe that |G(Node) = |P(|P(Node));
* | g（ノード）をノードノードの祖父母のセットとします。| g（node）= | p（| p（node））;
* let N be the child node at level L computing a set of FRs;
* nをレベルLの子ノードとし、FRSのセットを計算します。
* let P be a node at level L+1 and a parent node of N, i.e., bidirectionally reachable over adjacency ADJ(N, P);
* Pをレベルl+1およびnの親ノードのノード、つまり隣接するadj（n、p）で双方向に到達可能にします。
* let G be a grandparent node of N, reachable transitively via a parent P over adjacencies ADJ(N, P) and ADJ(P, G). Observe that N does not have enough information to check bidirectional reachability of ADJ(P, G);
* gをnの祖父母のnodeとし、隣接するadj（n、p）およびadj（p、g）を介して親pを介して到達可能に到達可能になります。nには、adj（p、g）の双方向の到達可能性を確認するのに十分な情報がないことを観察します。
* let R be a redundancy constant integer; a value of 2 or higher for R is RECOMMENDED;
* rを冗長定数整数とします。Rの値2以上の値が推奨されます。
* let S be a similarity constant integer; a value in range 0 .. 2 for S is RECOMMENDED, and the value of 1 SHOULD be used. Two cardinalities are considered as equivalent if their absolute difference is less than or equal to S, i.e., |a-b|<=S;
* Sを類似定数整数とします。sの範囲0 .. 2の値が推奨され、1の値を使用する必要があります。絶対差がS以下、つまり| a-b | <= s;
* let RND be a 64-bit random number (for example, as described in [RFC4086]) generated by the system once on startup.
* RNDを、システムによって1回生成された64ビットの乱数（たとえば、[RFC4086]で説明されているように）とします。
The algorithm consists of the following steps:
アルゴリズムは次の手順で構成されています。
1. Derive a 64-bit number by XORing N's System ID with RND.
1. rndを使用してnのシステムIDをXoringすることにより、64ビット番号を導き出します。
2. Derive a 16-bit pseudo-random unsigned integer PR(N) from the resulting 64-bit number by splitting it into 16-bit-long words W1, W2, W3, W4 (where W1 are the least significant 16 bits of the 64-bit number, and W4 are the most significant 16 bits) and then XORing the circularly shifted resulting words together:
2. 結果の64ビット数から16ビットの擬似ランダムの署名されていない整数PR（n）を導き出し、16ビットの単語W1、W2、W3、W4に分割して派生します（W1は64ビット数の最も重要な16ビットであり、W4は最も重要な16ビットです）。
A. (W1<<1) xor (W2<<2) xor (W3<<3) xor (W4<<4);
A.（w1 << 1）xor（w2 << 2）xor（w3 << 3）xor（w4 << 4）;
where << is the circular shift operator.
ここで、<<は円形シフト演算子です。
3. Sort the parents by decreasing number of northbound adjacencies (using decreasing System ID of the parent as a tie-breaker): sort |P(N) by decreasing CN(P), for all P in |P(N), as the ordered array |A(N)
3. 北行きの隣接の数を減らすことによって親を並べ替えます（親のシステムIDの減少を使用して、タイブレーカーとして親のシステムIDを使用します）：| p（n）のすべてのpに対して、cn（p）を減少させることにより、並べ替えられた配列| a（n）として並べ替えます。
4. Partition |A(N) in subarrays |A_k(N) of parents with equivalent cardinality of northbound adjacencies (in other words, with equivalent number of grandparents they can reach):
4. パーティション|サブアレイのA（n）| A_K（n）北行きの隣接の同等の枢機inalを持つ親のA_K（n）（言い換えれば、到達できる祖父母の同等の数）：
a. set k=0; // k is the ID of the subarray
a. k = 0を設定します。// kはサブアレイのIDです
b. set i=0;
b. 設定i = 0;
c. while i < CN(N) do
c. 私が<cn（n）はします
i. set j=i;
i. set j = i;
ii. while i < CN(N) and CN(|A(N)[j]) - CN(|A(N)[i]) <= S:
ii。i <cn（n）およびcn（| a（n）[j]）-cn（| a（n）[i]）<= s：
1. place |A(N)[i] in |A_k(N) // abstract action, maybe noop
1. | a_k（n）//抽象アクション、おそらくnoop
2. set i=i+1;
2. i = i+1を設定します。
iii. /* At this point, j is the index in |A(N) of the first member of |A_k(N) and (i-j) is C_k(N) defined as the cardinality of |A_k(N). */
iii。/*この時点で、jは| a_k（n）の最初のメンバーの| a（n）のインデックスであり、（i-j）は| a_k（n）のカーディナリティとして定義されています。*/
set k=k+1;
k = k+1を設定します。
/* At this point, k is the total number of subarrays, initialized for the shuffling operation below. */
/*この時点で、kはサブアレイの総数であり、以下のシャッフル操作のために初期化されています。*/
5. Shuffle each subarrays |A_k(N) of cardinality C_k(N) within |A(N) individually using the Durstenfeld variation of the Fisher-Yates algorithm that depends on N's System ID:
5. NのシステムIDに依存するFisher-YatesアルゴリズムのDurstenFeldバリエーションを個別に使用して、| a（n）内のカーディナリティC_K（n）の各サブアレイ| a_k（n）をシャッフルします。
a. while k > 0 do
a. k> 0がします
i. for i from C_k(N)-1 to 1 decrementing by 1 do
i. c_k（n）-1から1のc_k（n）-1から1の減少
1. set j to PR(N) modulo i;
1. jをpr（n）modulo iに設定します。
2. exchange |A_k[j] and |A_k[i];
2. Exchange | a_k [j]および| a_k [i];
ii. set k=k-1;
ii。k = k-1を設定します。
6. For each grandparent G, initialize a counter c(G) with the number of its southbound adjacencies to elected flood repeaters (which is initially zero):
6. 各祖父母Gについて、選出された洪水リピーター（最初はゼロ）に南行きの隣接の数でカウンターC（g）を初期化します。
a. for each G in |G(N), set c(G) = 0;
a. | g（n）の各gについて、c（g）= 0を設定します。
7. Finally, only keep FRs as parents that are needed to maintain the number of adjacencies between the FRs and any grandparent G equal or above the redundancy constant R:
7. 最後に、FRSをFRSと祖父母Gの間の隣接を維持するために必要な親としてのみ、冗長定数Rに等しい祖父母Gと等しいgを維持します。
a. for each P in reshuffled |A(N):
a. 再シャッフルされた各pについて| a（n）：
i. if there exists an adjacency ADJ(P, G) in |NA(P) such that c(G) < R, then
i. | na（p）に隣接するadj（p、g）が存在する場合、c（g）<r、次に
1. place P in FR set;
1. PをFRセットに配置します。
2. for all adjacencies ADJ(P, G') in |NA(P) increment c(G')
2. すべての隣接adj（p、g '）in | na（p）増分C（g'）
8. If any c(G) is still < R, it was not possible to elect a set of FRs that covers all grandparents with redundancy R.
8. C（g）がまだ<rである場合、すべての祖父母を冗長性RでカバーするFRSのセットを選択することはできませんでした。
Additional rules for flooding reduction:
洪水削減のための追加のルール：
1. The algorithm MUST be re-evaluated by a node on every change of local adjacencies or reception of a parent South TIE with changed adjacencies. A node MAY apply a hysteresis to prevent an excessive amount of computation during periods of network instability just like in the case of reachability computation.
1. アルゴリズムは、ローカル隣接のすべての変更または親の南ネクタイのレセプションのすべての変更に関するノードによって再評価されなければなりません。ノードは、到達可能性計算の場合のように、ネットワークの不安定性の期間中に過度の計算を防ぐためにヒステリシスを適用する場合があります。
2. Upon a change of the flood repeater set, a node SHOULD send out LIEs that grant flood repeater status to newly promoted nodes before it sends LIEs that revoke the status to the nodes that have been newly demoted. This is done to prevent transient behavior where the full coverage of grandparents is not guaranteed. Such a condition is sometimes unavoidable in case of lost LIEs, but it will correct itself at possible transient reduction in flooding propagation speeds. The election can use the LIE FSM _FloodLeadersChanged_ event to notify LIE FSMs of the necessity to update the sent LIEs.
2. 洪水リピーターセットを変更すると、ノードは、新たに降格したノードにステータスを取り消す嘘を送信する前に、新たに昇格したノードに洪水リピーターステータスを付与する嘘を送信する必要があります。これは、祖父母の完全な補償が保証されていない一時的な行動を防ぐために行われます。このような状態は、嘘を失った場合には避けられない場合がありますが、洪水伝播速度の一時的な減少の可能性がある場合にそれ自体を修正します。選挙では、FSM _FloodLeadersChanged_イベントを使用して、送信嘘を更新する必要性をFSMに通知することができます。
3. A node MUST always flood its self-originated TIEs to all its neighbors.
3. ノードは常に、そのすべての隣人に自己編成された絆を殺す必要があります。
4. A node receiving a TIE originated by a node for which it is not a flood repeater SHOULD NOT reflood such TIEs to its neighbors, except for the rules described in Section 6.3.9, Paragraph 10, Item 6.
4. セクション6.3.9、パラグラフ10、項目6で説明されている規則を除き、洪水リピーターではないノードから発信されるノードを受信するノードは、そのような結びつきをそのような結びつきを繰り返すべきではありません。
5. The indication of flood reduction capability MUST be carried in the Node TIEs in the _flood_reduction_ element and MAY be used to optimize the algorithm to account for nodes that will flood regardless.
5. 洪水削減能力の兆候は、_FLood_reduction_要素のノードタイで運ばれ、アルゴリズムを最適化して、洪水に関係なく洪水を考慮するために使用する必要があります。
6. A node generates TIDEs as usual, but when receiving TIREs or TIDEs resulting in requests for a TIE of which the newest received copy came on an adjacency where the node was not a flood repeater, it SHOULD ignore such requests on only the first request. Normally, the nodes that received the TIEs as flooding repeaters should satisfy the requesting node and, with that, no further TIREs for such TIEs will be generated. Otherwise, the next set of TIDEs and TIREs MUST lead to flooding independent of the flood repeater status. This solves a very difficult "incast" problem on nodes restarting with a very wide fanout, especially northbound. To retrieve the full database, they often end up processing many inrushing copies, whereas this approach load balances the incoming database between adjacent nodes and flood repeaters and should guarantee that two copies are sent by different nodes to ensure against any losses.
6. ノードはいつものように潮を生成しますが、タイヤまたは潮を受け取ると、最新の受け取ったコピーが隣接するネクタイのリクエストが発生した場合、ノードは洪水リピーターではなかったため、最初のリクエストのみでそのようなリクエストを無視する必要があります。通常、洪水リピーターとしてネクタイを受け取ったノードは、要求するノードを満たす必要があり、それに伴い、そのようなタイのタイヤはそれ以上のタイヤが生成されません。それ以外の場合、次の潮とタイヤのセットは、洪水リピーターの状態とは無関係に洪水につながる必要があります。これにより、特にノースバウンドで非常に広いファンアウトで再起動するノードで非常に困難な「インカスト」問題が解決します。完全なデータベースを取得するために、彼らはしばしば多くのイングリッシュコピーを処理することになりますが、このアプローチは隣接するノードと洪水リピーター間の着信データベースのバランスを負担し、損失に対して確実に保証するために2つのコピーが異なるノードによって送信されることを保証するはずです。
First, due to the distributed, asynchronous nature of ZTP, it can create temporary convergence anomalies where nodes at higher levels of the fabric temporarily become lower than where they ultimately belong. Since flooding can begin before ZTP is "finished" and in fact must do so given there is no global termination criteria for the unsynchronized ZTP algorithm, information may temporarily end up in wrong layers. A special clause when changing level takes care of that.
第一に、ZTPの分布した非同期性により、ファブリックのより高いレベルのノードが最終的に属する場所よりも一時的に低くなる一時的な収束異常を作成できます。ZTPが「終了」する前に洪水が開始される可能性があり、実際には、非シンノーゼ化されたZTPアルゴリズムのグローバル終了基準がないことを考えると、実際にそうしなければならないため、情報は一時的に間違った層で終わる可能性があります。レベルを変更するときの特別な条項がそれを処理します。
More difficult is a condition where a node (e.g., a leaf) floods a TIE north towards its grandparent, then its parent reboots, partitioning the grandparent from the leaf directly, and then the leaf itself reboots. That can leave the grandparent holding the "primary copy" of the leaf's TIE. Normally, this condition is resolved easily by the leaf reoriginating its TIE with a higher sequence number than it notices in the northbound TIEs; here however, when the parent comes back, it won't be able to obtain the leaf's North TIE from the grandparent easily, and with that, the leaf may not issue the TIE with a higher sequence number that can reach the grandparent for a long time. Flooding procedures are extended to deal with the problem by the means of special clauses that override the database of a lower level with headers of newer TIEs received in TIDEs coming from the north. Those headers are then propagated southbound towards the leaf to cause it to originate a higher sequence number of the TIE, effectively refreshing it all the way up to ToF.
より困難なのは、ノード（例えば、葉）が祖父母に向かって北にネクタイをあふれさせ、その後、その親の再起動をし、祖父母を葉から直接分割し、葉自体が再起動するという条件です。それは祖父母がリーフのネクタイの「主要なコピー」を保持することを残す可能性があります。通常、この条件は、葉が北にあるネクタイの通知よりも高いシーケンス数でそのタイを再計算することによって簡単に解決されます。しかし、ここでは、親が戻ってきたとき、祖父母から葉の北のネクタイを簡単に得ることができず、それにより、葉は祖父母に長い間到達できるより高いシーケンス番号でネクタイを発行しないかもしれません。洪水手順は、北からの潮流で受け取った新しいネクタイのヘッダーを使用して、より低いレベルのデータベースをオーバーライドする特別な条項の手段によって問題に対処するために拡張されています。これらのヘッダーは、葉に向かって南に向かって伝播して、ネクタイのシーケンス数が高くなり、効果的にTOFまでリフレッシュします。
A node has three possible sources of relevant information for reachability computation. A node knows the full topology south of it from the received North Node TIEs or alternately north of it from the South Node TIEs. A node has the set of prefixes with their associated distances and bandwidths from corresponding prefix TIEs.
ノードには、Reachability計算のための関連情報の3つの可能なソースがあります。ノードは、受信した北ノードのネクタイから、または南ノードのネクタイから北にあるものから南の完全なトポロジを知っています。ノードには、それに関連する距離と対応するプレフィックスタイからの帯域幅を備えたプレフィックスのセットがあります。
To compute prefix reachability, a node conceptually runs a northbound and a southbound SPF. Here, N-SPF and S-SPF notation denotes the direction in which the computation front is progressing.
接頭辞の到達可能性を計算するために、ノードは概念的にノースバウンドと南行きのSPFを実行します。ここで、N-SPFおよびS-SPF表記は、計算前面が進行している方向を示します。
Since neither computation can "loop", it is possible to compute non-equal costs or even k-shortest paths [EPPSTEIN] and "saturate" the fabric to the extent desired. This specification however uses simple, familiar SPF algorithms and concepts as examples due to their prevalence in today's routing.
どちらの計算も「ループ」できないため、非平等なコストまたはk-shortestパス[eppstein]を計算して、必要な範囲でファブリックを「飽和」することができます。ただし、この仕様では、今日のルーティングの有病率のため、例として、シンプルで馴染みのあるSPFアルゴリズムと概念を使用しています。
For reachability computation purposes, RIFT considers all parallel links between two nodes to be of the same cost advertised in the _cost_ element of _NodeNeighborsTIEElement_. In case the neighbor has multiple parallel links at different costs, the largest distance (highest numerical value) MUST be advertised. Given the range of Thrift encodings, _infinite_distance_ is defined as the largest non-negative _MetricType_. Any link with a metric larger than that (i.e., the negative MetricType) MUST be ignored in computations. Any link with the metric set to _invalid_distance_ MUST also be ignored in computation. In case of a negatively distributed prefix, the metric attribute MUST be set to _infinite_distance_ by the originator, and it MUST be ignored by all nodes during computation, except for the purpose of determining transitive propagation and building the corresponding routing table.
Reghinability計算の目的で、Riftは、2つのノード間のすべての並列リンクを、_NodeneighbortieElement_の_COST_要素で宣伝されているのと同じコストであると考えています。隣人が異なるコストで複数の平行リンクを持っている場合、最大の距離（最高数値）を宣伝する必要があります。リリフトエンコーディングの範囲を考えると、_infinite_distance_は最大の非陰性_metrictype_として定義されます。計算では、それよりも大きいメトリック（つまり、負のメトリックタイプ）を持つリンクはすべて無視する必要があります。_INVALID_DISTANCE_に設定されたメトリックとのリンクも、計算で無視する必要があります。負の分散プレフィックスの場合、メトリック属性はオリジネーターによって_INFINITE_DISTANCE_に設定する必要があり、計算中にすべてのノードによって無視する必要があります。
A prefix can carry the _directly_attached_ attribute to indicate that the prefix is directly attached, i.e., should be routed to even if the node is in overload. In case of a negatively distributed prefix, this attribute MUST NOT be included by the originator, and it MUST be ignored by all nodes during SPF computation. If a prefix is locally originated, the attribute _from_link_ can indicate the interface to which the address belongs to. In case of a negatively distributed prefix, this attribute MUST NOT be included by the originator, and it MUST be ignored by all nodes during computation. A prefix can also carry the _loopback_ attribute to indicate the said property.
プレフィックスは、_directly_attached_属性を運び、プレフィックスが直接接続されていることを示すことができます。つまり、ノードがオーバーロードされている場合でもルーティングする必要があります。否定的に分布したプレフィックスの場合、この属性はオリジネーターに含める必要はなく、SPF計算中にすべてのノードで無視する必要があります。プレフィックスが局所的に発信されている場合、属性_from_link_はアドレスが属するインターフェイスを示すことができます。否定的に分布したプレフィックスの場合、この属性はオリジネーターに含める必要はなく、計算中にすべてのノードで無視する必要があります。プレフィックスは、_loopback_属性を運び、上記のプロパティを示すこともできます。
Prefixes are carried in different types of TIEs indicating their type. For the same prefix being included in different TIE types, tie-breaking is performed according to Section 6.8.1. If the same prefix is included multiple times in multiple TIEs of the same type originating at the same node, the resulting behavior is unspecified.
接頭辞は、タイプを示すさまざまなタイプのネクタイで運ばれます。異なるタイ型に含まれている同じ接頭辞について、セクション6.8.1に従ってタイブレークが実行されます。同じノードで発生する同じタイプの複数のタイに同じ接頭辞が複数回含まれている場合、結果の動作は不特定です。
N-SPF MUST use exclusively northbound and East-West adjacencies in the computing node's North Node TIEs (since if the node is a leaf, it may not have generated a South Node TIE) when starting SPF. Observe that N-SPF is really just a one-hop variety since South Node TIEs are not reflooded southbound beyond a single level (or East-West), and with that, the computation cannot progress beyond adjacent nodes.
N-SPFは、SPFを開始するときに、コンピューティングノードのノースノードタイでのみノースバウンドおよびイーストウエストの隣接を使用する必要があります（ノードが葉である場合、サウスノードタイを生成していない可能性があるため）。南ノードのネクタイは単一のレベル（または東西）を超えてサウスバウンドではないため、N-SPFは実際には1ホップの種類に過ぎないことに注意してください。
Once progressing, the computation uses the next higher level's South Node TIEs to find corresponding adjacencies to verify backlink connectivity. Two unidirectional links MUST be associated to confirm bidirectional connectivity, a process often known as "backlink check". As part of the check, both Node TIEs MUST contain the correct System IDs *and* expected levels.
進行すると、計算は次の高レベルのサウスノードタイを使用して対応する隣接を見つけて、バックリンク接続を確認します。「バックリンクチェック」としてよく知られているプロセスである双方向の接続性を確認するために、2つの単方向リンクを関連付ける必要があります。チェックの一部として、両方のノードタイが正しいシステムID *および *予想されるレベルを含める必要があります。
The default route found when crossing an E-W link SHOULD be used if and only if
e-wリンクを横断するときに見つかったデフォルトルートは、場合にのみ使用する必要があります
1. the node itself does *not* have any northbound adjacencies *and*
1. ノード自体には、 *ノースバウンド隣接 *がありません *と *
2. the adjacent node has one or more northbound adjacencies.
2. 隣接するノードには、1つ以上の北行きの隣接があります。
This rule forms a "one-hop default route split-horizon" and prevents looping over default routes while allowing for "one-hop protection" of nodes that lost all northbound adjacencies, except at the ToF where the links are used exclusively to flood topology information in multi-plane designs.
このルールは、「ワンホップデフォルトルートスプリットホリゾン」を形成し、デフォルトルート上のループを防ぎながら、リンクがマルチプレーンデザインのトポロジー情報のみに使用されるために使用されるTOFを除き、すべての北行きの隣接を失ったノードの「ワンホップ保護」を許可します。
Other south prefixes found when crossing E-W links MAY be used if and only if
E-Wリンクを横切るときに見つかった他の南の接頭辞は、場合にのみ使用できます
1. no north neighbors are advertising the same or a supersuming non-default prefix *and*
1. 北の隣人は、同じまたは上品な非デフォルトプレフィックス *と *を宣伝していません
2. the node does not originate a non-default supersuming prefix itself.
2. ノードは、非デフォルト上位プレフィックス自体を発生しません。
That is, the E-W link can be used as a gateway of last resort for a specific prefix only. Using south prefixes across an E-W link can be beneficial, e.g., on automatic disaggregation in pathological fabric partitioning scenarios.
つまり、E-Wリンクは、特定のプレフィックスのみの最後の手段のゲートウェイとして使用できます。E-Wリンク全体に南の接頭辞を使用することは、たとえば、病理学的布の分割シナリオにおける自動分解について、有益です。
A detailed example can be found in Appendix B.4.
詳細な例は、付録B.4に記載されています。
S-SPF MUST use the southbound adjacencies in the South Node TIEs exclusively, i.e., progresses towards nodes at lower levels. Observe that E-W adjacencies are NEVER used in this computation. This enforces the requirement that a packet traversing in a southbound direction must never change its direction.
S-SPFは、サウスノードタイのサウスバウンド隣接を独占的に使用する必要があります。つまり、より低いレベルのノードに向かって進行します。この計算では、E-Wの隣接が使用されないことを観察してください。これにより、南方向に移動するパケットが方向を変えてはならないという要件が施行されます。
S-SPF MUST use northbound adjacencies in North Node TIEs to verify backlink connectivity by checking for the presence of the link beside the correct System ID and level.
S-SPFは、正しいシステムIDとレベルの横にリンクの存在をチェックすることにより、ノースノードのネクタイのノースバウンド隣接を使用してバックリンク接続を検証する必要があります。
Using south prefixes over horizontal links MAY occur if the N-SPF includes East-West adjacencies in computation. It can protect against pathological fabric partitioning cases that leave only paths to destinations that would necessitate multiple changes of forwarding direction between north and south.
N-SPFに計算に東西の隣接が含まれている場合、水平リンク上の南の接頭辞を使用する可能性があります。それは、北と南の間の転送方向の複数の変更を必要とする目的地への道のみを残す病理学的布の分割ケースから保護することができます。
E-W ToF links behave in terms of flooding scopes defined in Section 6.3.4 like northbound links and MUST be used exclusively for control plane information flooding. Even though a ToF node could be tempted to use those links during southbound SPF and carry traffic over them, this MUST NOT be attempted since it may, in anycast cases, lead to routing loops. An implementation MAY try to resolve the looping problem by following on the ring strictly tie-broken shortest-paths only, but the details are outside this specification. And even then, the problem of proper capacity provisioning of such links when they become traffic-bearing in case of failures is vexing, and when used for forwarding purposes, they defeat statistical non-blocking guarantees that Clos is providing normally.
E-W TOFリンクは、セクション6.3.4で定義された洪水スコープの観点から、北行きリンクのように動作し、制御プレーン情報の洪水のためにのみ使用する必要があります。TOFノードは、南行きのSPF中にこれらのリンクを使用してトラフィックを運ぶように誘惑される可能性がありますが、これは、任意の場合、ルーティングループにつながる可能性があるため、試みてはなりません。実装は、リングに厳密に結びついた最短パスのみをフォローすることにより、ループの問題を解決しようとするかもしれませんが、詳細はこの仕様の外側にあります。そして、それでも、故障の場合に交通を負うときにそのようなリンクの適切な容量プロビジョニングの問題は厄介であり、転送目的で使用される場合、CLOSが正常に提供している統計的な非ブロッキング保証を打ち負かします。
Under normal circumstances, a node's South TIEs contain just the adjacencies and a default route. However, if a node detects that its default IP prefix covers one or more prefixes that are reachable through it but not through one or more other nodes at the same level, then it MUST explicitly advertise those prefixes in a South TIE. Otherwise, some percentage of the northbound traffic for those prefixes would be sent to nodes without corresponding reachability, causing it to be dropped. Even when traffic is not being dropped, the resulting forwarding could "backhaul" packets through the higher-level spines, clearly an undesirable condition affecting the blocking probabilities of the fabric.
通常の状況では、ノードの南ネクタイには、隣接とデフォルトのルートのみが含まれています。ただし、デフォルトのIPプレフィックスが、同じレベルの1つまたは複数の他のノードを介してではなく、到達可能な1つまたは複数のプレフィックスをカバーしていることをノードが検出する場合、それらの接頭辞を南ネクタイで明示的に宣伝する必要があります。それ以外の場合、これらのプレフィックスの北行きのトラフィックの一部の割合は、対応する到達可能性なしにノードに送信され、削除されます。トラフィックがドロップされていない場合でも、結果として得られる転送は、高レベルのスパインを介してパケットを「バックホール」する可能性があります。これは、明らかに生地のブロッキング確率に影響を与える望ましくない状態です。
This specification refers to the process of advertising additional prefixes southbound as "positive disaggregation". Such disaggregation is non-transitive, i.e., its effects are always constrained to a single level of the fabric. Naturally, multiple node or link failures can lead to several independent instances of positive disaggregation necessary to prevent looping or bow-tying the fabric.
この仕様とは、サウスバウンドの追加のプレフィックスを「ポジティブな分解」として広告するプロセスを指します。このような分解は非転写です。つまり、その効果は常に単一のレベルのファブリックに制約されます。当然のことながら、複数のノードまたはリンクの障害は、布地のループや弓のようなものを防ぐために必要な肯定的な分解のいくつかの独立したインスタンスにつながる可能性があります。
A node determines the set of prefixes needing disaggregation using the following steps:
ノードは、次の手順を使用して分解が必要なプレフィックスのセットを決定します。
1. A DAG computation in the southern direction is performed first. The North TIEs are used to find all of the prefixes it can reach and the set of next hops in the lower level for each of them. Such a computation can be easily performed on a fat tree by setting all link costs in the southern direction to 1 and all northern directions to infinity. The set of those prefixes is referred to as |R; for each prefix r in |R, its set of next hops is referred to as |H(r).
1. 南方向のDAG計算が最初に実行されます。ノースタイは、到達できるすべての接頭辞と、それぞれの低レベルの次のホップのセットを見つけるために使用されます。このような計算は、南方向のすべてのリンクコストを1に、すべての北方向に無限に設定することにより、脂肪ツリーで簡単に実行できます。これらのプレフィックスのセットは、| rと呼ばれます。| rの各プレフィックスrについて、次のホップのセットは| h（r）と呼ばれます。
2. The node uses reflected South TIEs to find all nodes at the same level in the same PoD and the set of southbound adjacencies for each. The set of nodes at the same level is termed |N, and for each node, n, in |N, its set of southbound adjacencies is defined to be |A(n).
2. ノードは反射した南タイを使用して、同じポッドで同じレベルのすべてのノードを見つけ、それぞれのサウスバウンド隣接のセットを見つけます。同じレベルのノードのセットは| nと呼ばれ、各ノード、n、| nで、その南行きの隣接セットは| a（n）と定義されます。
3. For a given r, if the intersection of |H(r) and |A(n), for any n, is empty, then that prefix r must be explicitly advertised by the node in a South TIE.
3. 与えられたrの場合、| h（r）と| a（n）の交差点が任意のnに対して空である場合、そのプレフィックスrは南ネクタイのノードによって明示的に宣伝する必要があります。
4. An identical set of disaggregated prefixes is flooded on each of the node's southbound adjacencies. In accordance with the normal flooding rules for a South TIE, a node at the lower level that receives this South TIE SHOULD NOT propagate it southbound or reflect the disaggregated prefixes back over its adjacencies to nodes at the level from which it was received.
4. 同一の分解されたプレフィックスのセットは、各ノードのサウスバウンド隣接のそれぞれにあふれています。南ネクタイの通常の洪水規則に従って、この南ネクタイを受け取る下位レベルのノードは、それを南に伝播したり、隣接する接頭辞を受け取ったレベルでノードに戻したりするべきではありません。
To summarize the above in simplest terms: If a node detects that its default route encompasses prefixes for which one of the other nodes in its level has no possible next hops in the level below, it has to disaggregate it to prevent traffic loss or suboptimal routing through such nodes. Hence, a node X needs to determine if it can reach a different set of south neighbors than other nodes at the same level, which are connected to it via at least one common south neighbor. If it can, then prefix disaggregation may be required. If it can't, then no prefix disaggregation is needed. An example of disaggregation is provided in Appendix B.3.
上記を最も簡単に要約するには、ノードがデフォルトルートを検出すると、そのレベルの他のノードの1つが以下のレベルの次のホップが可能でないプレフィックスを網羅する場合、そのようなノードを介したトラフィックの損失または最適なルーティングを防ぐために、それを分解する必要があります。したがって、ノードXは、同じレベルの他のノードとは異なる南の隣人のセットに到達できるかどうかを判断する必要があります。可能であれば、接頭辞分解が必要になる場合があります。できない場合は、接頭辞分解は必要ありません。分解の例は、付録B.3に記載されています。
Finally, a possible algorithm is described here:
最後に、可能なアルゴリズムについて説明します。
1. Create partial_neighbors = (empty), a set of neighbors with partial connectivity to the node X's level from X's perspective. Each entry in the set is a south neighbor of X and a list of nodes of X.level that can't reach that neighbor.
1. Partial_neighbors =（空）を作成します。これは、Xの観点からノードXのレベルに部分的に接続された近隣のセットです。セット内の各エントリは、Xの南隣人であり、その隣人に到達できないX.Levelのノードのリストです。
2. A node X determines its set of southbound neighbors X.south_neighbors.
2. ノードXは、南行きの近隣x.south_neighborsのセットを決定します。
3. For each South TIE originated from a node Y that X has, which is at X.level, if Y.south_neighbors is not the same as X.south_neighbors but the nodes share at least one southern neighbor, for each neighbor N in X.south_neighbors but not in Y.south_neighbors, add (N, (Y)) to partial_neighbors if N isn't there or add Y to the list for N.
3. For each South TIE originated from a node Y that X has, which is at X.level, if Y.south_neighbors is not the same as X.south_neighbors but the nodes share at least one southern neighbor, for each neighbor N in X.south_neighbors but not in Y.south_neighbors, add (N, (Y)) to partial_neighbors if N isn't there or add Y to the list for N.
4. If partial_neighbors is empty, then node X does not disaggregate any prefixes. If node X is advertising disaggregated prefixes in its South TIE, X SHOULD remove them and re-advertise its South TIEs.
4. Partial_neighborsが空の場合、ノードXはプレフィックスを分解しません。ノードXが南ネクタイに分解された接頭辞を広告している場合、Xはそれらを削除して南のネクタイを再承認する必要があります。
A node X computes reachability to all nodes below it based upon the received North TIEs first. This results in a set of routes, each categorized by (prefix, path_distance, next-hop set). Alternately, for clarity in the following procedure, these can be organized by a next-hop set as ((next-hops), {(prefix, path_distance)}). If partial_neighbors isn't empty, then the procedure in Figure 17 describes how to identify prefixes to disaggregate.
ノードXは、最初に受信した北タイに基づいて、その下のすべてのノードに到達可能性を計算します。これにより、それぞれが（プレフィックス、path_distance、next-hopセット）によって分類される一連のルートになります。あるいは、次の手順を明確にするために、これらは（（Next-Hop）、{（prefix、path_distance）}）として次のホップセットによって編成できます。Partial_neighborsが空でない場合、図17の手順では、分解するプレフィックスを識別する方法について説明します。
disaggregated_prefixes = { empty }
nodes_same_level = { empty }
for each South TIE
if (South TIE.level == X.level and
X shares at least one S-neighbor with X)
add South TIE.originator to nodes_same_level
end if
end for
for each next-hop-set NHS
isolated_nodes = nodes_same_level
for each NH in NHS
if NH in partial_neighbors
isolated_nodes =
intersection(isolated_nodes,
partial_neighbors[NH].nodes)
end if
end for
if isolated_nodes is not empty
for each prefix using NHS
add (prefix, distance) to disaggregated_prefixes
end for
end if
end for
copy disaggregated_prefixes to X's South TIE
if X's South TIE is different
schedule South TIE for flooding
end if
Figure 17: Computation of Disaggregated Prefixes
図17：分解されたプレフィックスの計算
Each disaggregated prefix is sent with the corresponding path_distance. This allows a node to send the same South TIE to each south neighbor. The south neighbor that is connected to that prefix will thus have a shorter path.
各分解されたプレフィックスは、対応するpath_distanceで送信されます。これにより、ノードは各南隣人に同じ南ネクタイを送信できます。したがって、そのプレフィックスに接続されている南の隣人は、より短いパスを持っています。
Finally, to summarize the less obvious points partially omitted in the algorithms to keep them more tractable:
最後に、アルゴリズムで部分的に省略されていない低いポイントを要約するために、それらをより扱いやすくします。
1. All neighbor relationships MUST perform backlink checks.
1. すべての隣人関係は、バックリンクチェックを実行する必要があります。
2. The overload flag as introduced in Section 6.8.2 and carried in the _overload_ schema element has to be respected during the computation. Nodes advertising themselves as overloaded MUST NOT be transited in reachability computation but MUST be used as terminal nodes with prefixes they advertise being reachable.
2. セクション6.8.2で導入され、_Overload_スキーマ要素に携帯されている過負荷フラグは、計算中に尊重する必要があります。過負荷として宣伝するノードは、到達可能性計算で通過する必要はありませんが、到達可能なプレフィックスを備えた端末ノードとして使用する必要があります。
3. All the lower-level nodes are flooded the same disaggregated prefixes since RIFT does not build a South TIE per node, which would complicate things unnecessarily. The lower-level node that can compute a southbound route to the prefix will prefer it to the disaggregated route anyway based on route preference rules.
3. すべての低レベルのノードは、Riftがノードごとにサウスタイを構築しないため、同じ分解されたプレフィックスに浸水します。南行きのルートをプレフィックスに計算できる下位レベルのノードは、とにかくルートの優先ルールに基づいて、分解されたルートよりもそれを好みます。
4. Positively disaggregated prefixes do *not* have to propagate to lower levels. With that, the disturbance in terms of new flooding is contained to a single level experiencing failures.
4. 積極的に分解されたプレフィックスは、より低いレベルに伝播する必要はありません。それにより、新しい洪水の観点からの妨害は、失敗を経験する単一のレベルに含まれています。
5. Disaggregated South Prefix TIEs are not "reflected" by the lower level. Nodes within the same level do *not* need to be aware of which node computed the need for disaggregation.
5. 分解された南の接頭辞タイは、より低いレベルによって「反射」されません。同じレベル内のノードは、どのノードが分解の必要性を計算したかを認識する必要はありません。
6. The fabric is still supporting maximum load balancing properties while not trying to send traffic northbound unless necessary.
6. 生地は、必要でない限り、トラフィックを北に向かって送信しようとはしない一方で、最大負荷分散特性をサポートしています。
In case positive disaggregation is triggered and due to the very stable but unsynchronized nature of the algorithm, the nodes may issue the necessary disaggregated prefixes at different points in time. For a short time, this can lead to an "incast" behavior where the first advertising router based on the nature of the longest prefix match will attract all the traffic. Different implementation strategies can be used to lessen that effect, but those are outside the scope of this specification.
肯定的な分解がトリガーされ、アルゴリズムの非常に安定しているが異常な性質により、ノードは異なる時点で必要な分解プレフィックスを発行する可能性があります。しばらくの間、これは「侵入」動作につながる可能性があり、最長のプレフィックスマッチの性質に基づいた最初の広告ルーターがすべてのトラフィックを引き付けることができます。さまざまな実装戦略を使用してその効果を軽減できますが、それらはこの仕様の範囲外です。
It is worth observing that, in a single-plane ToF, this disaggregation prevents traffic loss up to (K_LEAF * P) link failures in terms of Section 5.2 or, in other terms, it takes at minimum that many link failures to partition the ToF into multiple planes.
単一平面のTOFでは、この分解により、セクション5.2の点で（k_leaf * p）リンクの障害までのトラフィックの損失が妨げられることを観察する価値があります。
As explained in Section 5.3, failures in multi-plane ToF or more than (K_LEAF * P) links failing in single-plane design can generate fallen leaves. Such scenario cannot be addressed by positive disaggregation only and needs a further mechanism.
セクション5.3で説明したように、マルチプレーンTOFまたは（k_leaf * p）リンクの障害は、単一平面設計で故障する可能性があります。このようなシナリオは、肯定的な分解のみによって対処することはできず、さらなるメカニズムが必要です。
Returning in this section to designs with multiple planes as shown originally in Figure 3, Figure 18 highlights how the ToF is cabled in case of two planes by the means of dual-rings to distribute all the North TIEs within both planes.
このセクションでは、図3に元々示されている複数の平面を使用して設計するために戻ると、図18は、両方の飛行機内のすべての北タイを配布するデュアルリングの手段によって2つの平面の場合にTOFがどのようにケーブルできるかを強調しています。
(Artwork only available as SVG: see
https://www.rfc-editor.org/rfc/rfc9692.html)
Figure 18: Topologically Connected Planes
図18：トポロジー的に接続された平面
Section 5.3 already describes how failures in multi-plane fabrics can lead to traffic loss that normal positive disaggregation cannot fix. The mechanism of negative, transitive disaggregation incorporated in RIFT provides the corresponding solution, and the next section explains the involved mechanisms in more detail.
セクション5.3では、マルチプレーンファブリックの障害が、通常の肯定的な分解が修正できないトラフィックの損失にどのようにつながるかをすでに説明しています。Riftに組み込まれた負の推移的分解のメカニズムは、対応するソリューションを提供し、次のセクションでは、関与するメカニズムをより詳細に説明します。
A ToF node discovering that it cannot reach a fallen leaf SHOULD disaggregate all the prefixes of that leaf. For that purpose, it uses negative South Prefix TIEs that are, as usual, flooded southwards with the scope defined in Section 6.3.4.
倒れた葉に到達できないことを発見するTOFノードは、その葉のすべての接頭辞を分解するはずです。その目的のために、セクション6.3.4で定義されたスコープで、通常のように南に浸水しているネガティブサウスプレフィックスタイを使用します。
Transitively, a node explicitly loses connectivity to a prefix when none of its children advertises it and when the prefix is negatively disaggregated by all of its parents. When that happens, the node originates the negative prefix further down south. Since the mechanism applies recursively south, the negative prefix may propagate transitively all the way down to the leaf. This is necessary since leaves connected to multiple planes by means of disjointed paths may have to choose the correct plane at the very bottom of the fabric to make sure that they don't send traffic towards another leaf using a plane where it is "fallen", which would make traffic loss unavoidable.
交換的に、ノードは、子供のいずれも宣伝していない場合、およびプレフィックスがすべての親によって負の分解されたときに、プレフィックスへの接続性を明示的に失います。それが起こると、ノードはさらに南の否定的な接頭辞を発信します。メカニズムは再帰的に南に適用されるため、負の接頭辞は葉までずっと横断的に伝播する可能性があります。これは、分離された経路を使用して複数の平面に接続されているため、生地の最下部にある正しい平面を選択して、「倒れた」平面を使用して別の葉にトラフィックを送らないようにするため、トラフィックの損失を避けられないようにする必要があるため、これが必要です。
When connectivity is restored, a node that disaggregated a prefix withdraws the negative disaggregation by the usual mechanism of re-advertising TIEs omitting the negative prefix.
接続性が復元されると、接頭辞を分解したノードは、ネガティブプレフィックスを省略する通常のメカニズムによって否定的な分解を引き出します。
Negative prefixes can in fact be advertised due to two different triggers. This will be described consecutively.
実際には、2つの異なるトリガーのためにネガティブな接頭辞を宣伝できます。これについては連続して説明されます。
The first origination reason is a computation that uses all the North Node TIEs to build the set of all reachable nodes by reachability computation over the complete graph, including horizontal ToF links. The computation uses the node itself as the root. This is compared with the result of the normal southbound SPF as described in Section 6.4.2. The differences are the fallen leaves and all their attached prefixes are advertised as negative prefixes southbound if the node does not consider the prefix to be reachable within the southbound SPF.
最初のオリジネーション理由は、すべてのノースノードタイを使用して、水平TOFリンクを含む完全なグラフ上のリーチ可能性計算により、すべての到達可能なノードのセットを構築する計算です。計算は、ノード自体をルートとして使用します。これは、セクション6.4.2で説明されているように、通常の南行きのSPFの結果と比較されます。違いは、倒れた葉であり、接続された接頭辞はすべて、ノードが接頭辞を南に向かうSPF内で到達可能であると考えていない場合、ネガティブなプレフィックスとして南に宣伝されます。
The second origination reason hinges on the understanding of how the negative prefixes are used within the computation as described in Figure 19. When attaching the negative prefixes at a certain point in time, the negative prefix may find itself with all the viable nodes from the shorter match next hop being pruned. In other words, all its northbound neighbors provided a negative prefix advertisement. This is the trigger to advertise this negative prefix transitively south and is normally caused by the node being in a plane where the prefix belongs to a fabric leaf that has "fallen" in this plane. Obviously, when one of the northbound switches withdraws its negative advertisement, the node has to withdraw its transitively provided negative prefix as well.
2番目のオリジネーション理由は、図19で説明するように、計算内で負の接頭辞がどのように使用されるかを理解することにかかっています。特定の時点でネガティブな接頭辞を接続する場合、ネギーの次のホップが剪定される短い一致からのすべての実行可能なノードでそれ自体を見つけることができます。言い換えれば、すべての北行きの隣人はネガティブなプレフィックス広告を提供しました。これは、このネガティブな接頭辞をトランタティブに南に宣伝するトリガーであり、通常、ノードがこの平面に「倒れた」ファブリックリーフに属する平面にノードがあることによって引き起こされます。明らかに、ノースバウンドスイッチの1つがネガティブ広告を撤回すると、ノードは同様にトランジータルに提供されたネガティブなプレフィックスを撤回する必要があります。
After an SPF is run, it is necessary to attach the resulting reachability information in the form of prefixes. For S-SPF, prefixes from a North TIE are attached to the originating node with that node's next-hop set and a distance equal to the prefix's cost plus the node's minimized path distance. The RIFT route database, a set of (prefix, prefix-type, attributes, path_distance, next-hop set), accumulates these results.
SPFが実行された後、結果の到達可能性情報を接頭辞の形式で添付する必要があります。S-SPFの場合、ノースタイのプレフィックスは、そのノードの次のホップセットと、プレフィックスのコストとノードの最小化パス距離に等しい距離を使用して、発信ノードに取り付けられます。Rift Routeデータベース（プレフィックス、プレフィックスタイプ、属性、path_distance、next-hopセット）のセットがこれらの結果を蓄積します。
N-SPF prefixes from each South TIE need to also be added to the RIFT route database. The N-SPF is really just a stub so the computing node simply needs to determine, for each prefix in a South TIE that originated from adjacent node, what next hops to use to reach that node. Since there may be parallel links, the next hops to use can be a set; the presence of the computing node in the associated South Node TIE is sufficient to verify that at least one link has bidirectional connectivity. The set of minimum cost next hops from the computing node X to the originating adjacent node is determined.
各サウスタイのN-SPFプレフィックスも、Rift Routeデータベースに追加する必要があります。N-SPFは実際には単なるスタブであるため、コンピューティングノードは、隣接するノードから発生する南ネクタイの各プレフィックスについて、次にそのノードに到達するために使用するものを決定する必要があります。並列リンクがある可能性があるため、次の使用ホップはセットにすることができます。関連するサウスノードタイでのコンピューティングノードの存在は、少なくとも1つのリンクが双方向の接続性を持っていることを確認するのに十分です。コンピューティングノードXから発信元の隣接ノードまでの最小コストの次のホップのセットが決定されます。
Each prefix has its cost adjusted before being added into the RIFT route database. The cost of the prefix is set to the cost received plus the cost of the minimum distance next hop to that neighbor while considering its attributes such as mobility per Section 6.8.4. Then each prefix can be added into the RIFT route database with the next-hop set; ties are broken based upon type first and then distance and further on _PrefixAttributes_. Only the best combination is used for forwarding. RIFT route preferences are normalized by the enum _RouteType_ in the Thrift [thrift] model given in Section 7.
各プレフィックスには、Rift Routeデータベースに追加される前にコストが調整されています。接頭辞のコストは、受信したコストに加えて、次の距離のコストに、セクション6.8.4ごとのモビリティなどの属性を考慮しながら、その隣人への次のホップに設定されます。次に、各プレフィックスを次のホップセットでRIFTルートデータベースに追加できます。タイは最初にタイプに基づいて壊れ、次に距離、さらに_prefixattributes_に壊れます。転送には最適な組み合わせのみが使用されます。リフトルートの設定は、セクション7で示されているThrift [Thrift]モデルのEnum _RouteType_によって正規化されます。
An example implementation for node X follows:
ノードXの実装の例は次のとおりです。
for each South TIE
if South TIE.level > X.level
next_hop_set = set of minimum cost links to the
South TIE.originator
next_hop_cost = minimum cost link to
South TIE.originator
end if
for each prefix P in the South TIE
P.cost = P.cost + next_hop_cost
if P not in route_database:
add (P, P.cost, P.type,
P.attributes, next_hop_set) to route_database
end if
if (P in route_database):
if route_database[P].cost > P.cost or
route_database[P].type > P.type:
update route_database[P] with (P, P.type, P.cost,
P.attributes,
next_hop_set)
else if route_database[P].cost == P.cost and
route_database[P].type == P.type:
update route_database[P] with (P, P.type,
P.cost, P.attributes,
merge(next_hop_set, route_database[P].next_hop_set))
else
// Not preferred route so ignore
end if
end if
end for
end for
Figure 19: Adding Routes from South TIE Positive and Negative Prefixes
図19：サウスタイのプラスおよびネガティブプレフィックスからのルートの追加
After the positive prefixes are attached and tie-broken, negative prefixes are attached and used in case of northbound computation, ideally from the shortest length to the longest. The next-hop adjacencies for a negative prefix are inherited from the longest positive prefix that aggregates it; subsequently, adjacencies to nodes that advertised negative disaggregation for this prefix are removed.
正の接頭辞が取り付けられ、タイブレイクされた後、否定的なプレフィックスが取り付けられ、最短の長さから最長までの北行きの計算の場合に使用されます。ネガティブプレフィックスの次のホップ隣接は、それを集約する最も長い正のプレフィックスから継承されます。その後、このプレフィックスの否定的な分解を宣伝したノードへの隣接は削除されます。
The rule of inheritance MUST be maintained when the next-hop list for a prefix is modified, as the modification may affect the entries for matching negative prefixes of immediate longer prefix length. For instance, if a next hop is added, then by inheritance, it must be added to all the negative routes of immediate longer prefixes length unless it is pruned due to a negative advertisement for the same next hop. Similarly, if a next hop is deleted for a given prefix, then it is deleted for all the immediately aggregated negative routes. This will recurse in the case of nested negative prefix aggregations.
継承ルールは、プレフィックスの次のホップリストが変更されたときに維持する必要があります。これは、変更がすぐに長いプレフィックス長のネガティブプレフィックスを一致させるためのエントリに影響を与える可能性があるためです。たとえば、次のホップが追加されている場合、継承により、同じ次のホップの負の広告のために剪定されない限り、すぐに長いプレフィックスのすべてのネガティブルートに追加する必要があります。同様に、特定のプレフィックスに対して次のホップが削除された場合、すぐに集約されたすべてのネガティブルートに対して削除されます。これは、ネストされたネガティブな接頭辞集約の場合に再発します。
The rule of inheritance MUST also be maintained when a new prefix of intermediate length is inserted or when the immediately aggregating prefix is deleted from the routing table, making an even shorter aggregating prefix the one from which the negative routes now inherit their adjacencies. As the aggregating prefix changes, all the negative routes MUST be recomputed, and then again, the process may recurse in case of nested negative prefix aggregations.
中間長の新しいプレフィックスが挿入された場合、またはすぐに集約されたプレフィックスがルーティングテーブルから削除されたときに、継承ルールを維持する必要があります。集約接頭辞が変更されると、すべての負のルートを再計算する必要があり、その後、ネストされたネガティブプレフィックス集約の場合、プロセスが再発する可能性があります。
Although these operations can be computationally expensive, the overall load on devices in the network is low because these computations are not run very often, as positive route advertisements are always preferred over negative ones. This prevents recursion in most cases because positive reachability information never inherits next hops.
これらの操作は計算高価ですが、これらの計算は頻繁に実行されないため、ネットワーク内のデバイスの全体的な負荷は低くなります。これにより、ほとんどの場合、肯定的な到達可能性情報が次のホップを継承しないため、再帰が防止されます。
To make the negative disaggregation less abstract and provide an example ToP node, T1 with 4 ToF parents S1..S4 as represented in Figure 20 are considered further:
否定的な分解の抽象化を減らし、上部ノードの例を提供するために、図20に示す4人のTOF親S1..S4を備えたT1をさらに考慮します。
+----+ +----+ +----+ +----+ N
| S1 | | S2 | | S3 | | S4 | ^
+----+ +----+ +----+ +----+ W< + >E
| | | | v
|+--------+ | | S
||+-----------------+ |
|||+----------------+---------+
||||
+----+
| T1 |
+----+
Figure 20: A ToP Node with 4 Parents
図20：4人の親がいるトップノード
If all ToF nodes can reach all the prefixes in the network, with RIFT, they will normally advertise a default route south. An abstract Routing Information Base (RIB), more commonly known as a routing table, stores all types of maintained routes, including the negative ones and "tie-breaks" for the best one, whereas an abstract forwarding table (FIB) retains only the ultimately computed "positive" routing instructions. In T1, those tables would look as illustrated in Figure 21:
すべてのTOFノードがネットワーク内のすべての接頭辞に到達できる場合、Riftを使用して、通常はデフォルトのルートを南に宣伝します。より一般的にルーティングテーブルとして知られている抽象的なルーティング情報ベース（RIB）は、ネガティブなルートや「タイブレーク」を含むあらゆる種類のメンテナンスルートを保存しますが、抽象転送テーブル（FIB）は最終的に計算された「正の」ルーティング指示のみを保持します。T1では、これらのテーブルは図21に示されているように見えます。
+---------+
| Default |
+---------+
|
| +--------+
+---> | via S1 |
| +--------+
|
| +--------+
+---> | via S2 |
| +--------+
|
| +--------+
+---> | via S3 |
| +--------+
|
| +--------+
+---> | via S4 |
+--------+
Figure 21: Abstract RIB
図21：要約リブ
In case T1 receives a negative advertisement for prefix 2001:db8::/32 from S1, a negative route is stored in the RIB (indicated by a "~" sign), while the more specific routes to the complementing ToF nodes are installed in FIB. RIB and FIB in T1 now look as illustrated in Figures 22 and 23, respectively:
T1がプレフィックス2001のネガティブ広告を受け取った場合：S1からDB8 ::/32では、ネガティブルートがrib骨に保存されます（「〜」サインで示されます）。T1のリブとFIBは、図22と23にそれぞれ図に示されているように見えます。
+---------+ +-----------------+
| Default | <-------------- | ~2001:db8::/32 |
+---------+ +-----------------+
| |
| +--------+ | +--------+
+---> | via S1 | +---> | via S1 |
| +--------+ +--------+
|
| +--------+
+---> | via S2 |
| +--------+
|
| +--------+
+---> | via S3 |
| +--------+
|
| +--------+
+---> | via S4 |
+--------+
Figure 22: Abstract RIB After Negative 2001:db8::/32 from S1
図22：マイナス2001年後の要約リブ：S1からのDB8 ::/32
The negative 2001:db8::/32 prefix entry inherits from ::/0, so the positive, more specific routes are the complements to S1 in the set of next hops for the default route. That entry is composed of S2, S3, and S4, or in other words, it uses all entries in the default route with a "hole punched" for S1 into them. These are the next hops that are still available to reach 2001:db8::/32 now that S1 advertised that it will not forward 2001:db8::/32 anymore. Ultimately, those resulting next hops are installed in FIB for the more specific route to 2001:db8::/32 as illustrated below:
ネガティブ2001：DB8 ::/32プレフィックスエントリは::/0から継承されるため、正の、より具体的なルートは、デフォルトルートの次のホップのセットにおけるS1の補体です。そのエントリは、S2、S3、およびS4で構成されています。つまり、S1の「ホールパンチ」を使用して、デフォルトルートのすべてのエントリを使用します。これらは、2001年に到達するためにまだ利用できる次のホップです：db8 ::/32では、S1が2001：db8 ::/32を転送しないことを宣伝しました。最終的に、結果として生じる次のホップは、以下に示すように、2001年までのより具体的なルートのためにFIBにインストールされます。
+---------+ +---------------+
| Default | | 2001:db8::/32 |
+---------+ +---------------+
| |
| +--------+ |
+---> | via S1 | |
| +--------+ |
| |
| +--------+ | +--------+
+---> | via S2 | +---> | via S2 |
| +--------+ | +--------+
| |
| +--------+ | +--------+
+---> | via S3 | +---> | via S3 |
| +--------+ | +--------+
| |
| +--------+ | +--------+
+---> | via S4 | +---> | via S4 |
+--------+ +--------+
Figure 23: Abstract FIB After Negative 2001:db8::/32 from S1
図23：マイナス2001年後の要約fib：db8 ::/32 from s1
To illustrate matters further, consider T1 receiving a negative advertisement for prefix 2001:db8:1::/48 from S2, which is stored in RIB again. After the update, the RIB in T1 is illustrated in Figure 24:
さらに問題を説明するために、T1はプレフィックス2001の否定的な広告を受け取ることを検討してください：S2のDB8：1 ::/48は、再びrib ribに保存されます。更新後、T1のリブを図24に示します。
+---------+ +----------------+ +------------------+
| Default | <----- | ~2001:db8::/32 | <------ | ~2001:db8:1::/48 |
+---------+ +----------------+ +------------------+
| | |
| +--------+ | +--------+ |
+---> | via S1 | +---> | via S1 | |
| +--------+ +--------+ |
| |
| +--------+ | +--------+
+---> | via S2 | +---> | via S2 |
| +--------+ +--------+
|
| +--------+
+---> | via S3 |
| +--------+
|
| +--------+
+---> | via S4 |
+--------+
Figure 24: Abstract RIB After Negative 2001:db8:1::/48 from S2
図24：マイナス2001年後の要約リブ：S2からのDB8：1 ::/48
Negative 2001:db8:1::/48 inherits from 2001:db8::/32 now, so the positive, more specific routes are the complements to S2 in the set of next hops for 2001:db8::/32, which are S3 and S4, or in other words, all entries of the parent with the negative holes "punched in" again. After the update, the FIB in T1 shows as illustrated in Figure 25:
ネガティブ2001：DB8：1 ::/48は2001年から継承されます：DB8 ::/32今すぐ、より具体的なルートは、2001年の次のホップのセットのS2を補完します。更新後、図25に示すように、T1のFIBが示しています。
+---------+ +---------------+ +-----------------+
| Default | | 2001:db8::/32 | | 2001:db8:1::/48 |
+---------+ +---------------+ +-----------------+
| | |
| +--------+ | |
+---> | via S1 | | |
| +--------+ | |
| | |
| +--------+ | +--------+ |
+---> | via S2 | +---> | via S2 | |
| +--------+ | +--------+ |
| | |
| +--------+ | +--------+ | +--------+
+---> | via S3 | +---> | via S3 | +---> | via S3 |
| +--------+ | +--------+ | +--------+
| | |
| +--------+ | +--------+ | +--------+
+---> | via S4 | +---> | via S4 | +---> | via S4 |
+--------+ +--------+ +--------+
Figure 25: Abstract FIB After Negative 2001:db8:1::/48 from S2
図25：S2からのネガティブ2001年後の要約FIB：DB8：1 ::/48
Further, assume that S3 stops advertising its service as a default gateway. The entry is removed from RIB as usual. In order to update the FIB, it is necessary to eliminate the FIB entry for the default route, as well as all the FIB entries that were created for negative routes pointing to the RIB entry being removed (::/0). This is done recursively for 2001:db8::/32 and then for 2001:db8:1::/48. The related FIB entries via S3 are removed as illustrated in Figure 26.
さらに、S3がデフォルトゲートウェイとしてサービスを宣伝するのを停止すると仮定します。エントリは通常どおりリブから削除されます。FIBを更新するには、デフォルトルートのFIBエントリと、削除されているリブエントリを指すネガティブルート用に作成されたすべてのFIBエントリ（::/0）を削除する必要があります。これは2001年に再帰的に行われます：db8 ::/32、そして2001年：db8：1 ::/48。S3を介した関連するFIBエントリは、図26に示すように削除されています。
+---------+ +---------------+ +-----------------+
| Default | | 2001:db8::/32 | | 2001:db8:1::/48 |
+---------+ +---------------+ +-----------------+
| | |
| +--------+ | |
+---> | via S1 | | |
| +--------+ | |
| | |
| +--------+ | +--------+ |
+---> | via S2 | +---> | via S2 | |
| +--------+ | +--------+ |
| | |
| | |
| | |
| | |
| | |
| +--------+ | +--------+ | +--------+
+---> | via S4 | +---> | via S4 | +---> | via S4 |
+--------+ +--------+ +--------+
Figure 26: Abstract FIB After Loss of S3
図26：S3の喪失後の要約FIB
Say that at that time, S4 would also disaggregate prefix 2001:db8:1::/48. This would mean that the FIB entry for 2001:db8:1::/48 becomes a discard route, and that would be the signal for T1 to disaggregate prefix 2001:db8:1::/48 negatively in a transitive fashion with its own children.
その時点で、S4はプレフィックス2001：db8：1 ::/48も分解するだろうとします。これは、2001年のFIBエントリ：DB8：1 ::/48が破棄ルートになることを意味し、それはT1がプレフィックス2001：DB8：1 ::/48を自分の子供との否定的に否定的に分解する信号となることを意味します。
Finally, the case occurs where S3 becomes available again as a default gateway, and a negative advertisement is received from S4 about prefix 2001:db8:2::/48 as opposed to 2001:db8:1::/48. Again, a negative route is stored in the RIB, and the more specific route to the complementing ToF nodes is installed in FIB. Since 2001:db8:2::/48 inherits from 2001:db8::/32, the positive FIB routes are chosen by removing S4 from S2, S3, S4. The abstract FIB in T1 now shows as illustrated in Figure 27:
最後に、S3がデフォルトゲートウェイとして再び利用できるようになる場合、2001年とは対照的に、プレフィックス2001：DB8：2 ::/48についてS4からネガティブな広告が受信されます：DB8：1 ::/48。繰り返しますが、負のルートがrib骨に保存され、補完するTOFノードへのより具体的なルートがFIBに設置されます。2001年以降：DB8：2 ::/48は2001年から継承されます：DB8 ::/32、S4、S3、S4からS4を除去することにより、正のFIBルートが選択されます。T1の抽象的なFIBは、図27に示すように示されています。
+-----------------+
| 2001:db8:2::/48 |
+-----------------+
|
+---------+ +---------------+ +-----------------+
| Default | | 2001:db8::/32 | | 2001:db8:1::/48 |
+---------+ +---------------+ +-----------------+
| | | |
| +--------+ | | | +--------+
+---> | via S1 | | | +---> | via S2 |
| +--------+ | | | +--------+
| | | |
| +--------+ | +--------+ | | +--------+
+---> | via S2 | +---> | via S2 | | +---> | via S3 |
| +--------+ | +--------+ | +--------+
| | |
| +--------+ | +--------+ | +--------+
+---> | via S3 | +---> | via S3 | +---> | via S3 |
| +--------+ | +--------+ | +--------+
| | |
| +--------+ | +--------+ | +--------+
+---> | via S4 | +---> | via S4 | +---> | via S4 |
+--------+ +--------+ +--------+
Figure 27: Abstract FIB After Negative 2001:db8:2::/48 from S4
図27：ネガティブ2001年後の要約FIB：S4からのDB8：2 ::/48
Each RIFT node can operate in Zero Touch Provisioning (ZTP) mode, i.e., it has no RIFT-specific configuration (unless it is a ToF or it is explicitly configured to operate in the overall topology as a leaf and/or support L2L procedures), and it will fully automatically derive necessary RIFT parameters itself after being attached to the topology. Manually configured nodes and nodes operating using RIFT ZTP can be mixed freely and will form a valid topology if achievable.
各リフトノードは、ゼロタッチプロビジョニング（ZTP）モードで動作できます。つまり、リフト固有の構成はありません（TOFである場合、またはL2L手順全体としてトポロジ全体で動作するように明示的に構成されていない場合）。Rift ZTPを使用して動作する手動で構成されたノードとノードは自由に混合でき、達成可能な場合は有効なトポロジを形成します。
The derivation of the level of each node happens based on offers received from its neighbors, whereas each node (with the possible exception of nodes configured as leaves) tries to attach at the highest possible point in the fabric. This guarantees that even if the diffusion front of offers reaches a node from "below" faster than from "above", it will greedily abandon an already negotiated level derived from nodes topologically below it and properly peer with nodes above.
各ノードのレベルの導出は、近隣から受け取ったオファーに基づいて発生しますが、各ノード（葉として構成されたノードを除く）は、ファブリックの可能な最高点でアタッチしようとします。これにより、オファーの拡散フロントが「上から」よりも速い「下」からノードに到達したとしても、トポロジカルに由来するノードから派生した既に交渉されたレベルを貪欲に放棄し、上記のノードで適切にピアになります。
The fabric is very consciously numbered from the top down to allow for PoDs of different heights and to minimize the number of configurations necessary, in this case, just a TOP_OF_FABRIC flag on every node at the top of the fabric.
生地は、異なる高さのポッドを可能にし、必要な構成の数を最小限に抑えるために、上部から非常に意識的に番号が付けられています。
This section describes the necessary concepts and procedures of the RIFT ZTP operation.
このセクションでは、RIFT ZTP操作の必要な概念と手順について説明します。
The interdependencies between the different flags and the configured level can be somewhat vexing at first, and it may take multiple reads of the glossary to comprehend them.
異なるフラグと構成されたレベルの間の相互依存関係は、最初はやや厄介になる可能性があり、それらを理解するために用語集の複数の読み取りが必要になる場合があります。
Automatic Level Derivation:
自動レベルの派生：
Procedures that allow nodes without a level configured to derive it automatically. Only applied if CONFIGURED_LEVEL is undefined.
自動的に導出するように構成されたレベルのないノードを許可する手順。configured_levelが未定義の場合にのみ適用されます。
UNDEFINED_LEVEL:
undefined_level：
A "null" value that indicates that the level has not been determined and has not been configured. Schemas normally indicate that by a missing optional value without an available defined default.
レベルが決定されておらず、構成されていないことを示す「null」値。スキーマは通常、使用可能な定義済みデフォルトなしで欠落しているオプション値によってそれを示しています。
LEAF_ONLY:
leaf_only：
An optional configuration flag that can be configured on a node to make sure it never leaves the "bottom of the hierarchy". The TOP_OF_FABRIC flag and CONFIGURED_LEVEL cannot be defined at the same time as this flag. It implies a CONFIGURED_LEVEL value of _leaf_level_. It is indicated in the _leaf_only_ schema element.
ノードで構成できるオプションの構成フラグは、「階層の底部」を離れないようにします。TOP_OF_FABRICフラグとconfigured_levelは、このフラグと同時に定義できません。_leaf_level_のconfigured_level値を意味します。_LEAF_ONLY_スキーマ要素に示されています。
TOP_OF_FABRIC:
top_of_fabric：
A configuration flag that MUST be provided on all ToF nodes. LEAF_FLAG and CONFIGURED_LEVEL cannot be defined at the same time as this flag. It implies a CONFIGURED_LEVEL value. In fact, it is basically a shortcut for configuring the same level at all ToF nodes, which is unavoidable since an initial "seed" is needed for other ZTP nodes to derive their level in the topology. The flag plays an important role in fabrics with multiple planes to enable successful negative disaggregation (Section 6.5.2). It is carried in the _top_of_fabric_ schema element. A standards-conforming RIFT implementation implies a CONFIGURED_LEVEL value of _top_of_fabric_level_ in case of TOP_OF_FABRIC. This value is kept reasonably low to allow for fast ZTP reconvergence on failures.
すべてのTOFノードで提供する必要がある構成フラグ。leaf_flagとconfigured_levelは、このフラグと同時に定義することはできません。configured_level値を意味します。実際、これは基本的に、すべてのTOFノードで同じレベルを構成するためのショートカットです。これは、他のZTPノードがトポロジのレベルを導出するために最初の「シード」が必要であるため避けられません。旗は、複数の飛行機を持つ生地で重要な役割を果たし、否定的な分解を成功させることができます（セクション6.5.2）。_TOP_OF_FABRIC_スキーマ要素で運ばれます。標準を構成するRIFT実装は、TOP_OF_FABRICの場合の_TOP_OF_FABRIC_LEVEL_のconfigured_level値を意味します。この値は、障害に対する速いZTPの再変換を可能にするために、合理的に低く保たれます。
CONFIGURED_LEVEL:
configured_level：
A level value provided manually. When this is defined (i.e., it is not an UNDEFINED_LEVEL), the node is not participating in ZTP in the sense of deriving its own level based on other nodes' information. The TOP_OF_FABRIC flag is ignored when this value is defined. LEAF_ONLY can be set only if this value is undefined or set to _leaf_level_.
手動で提供されるレベル値。これが定義されている場合（つまり、未定義の_levelではありません）、ノードは他のノードの情報に基づいて独自のレベルを導き出すという意味でZTPに参加していません。この値を定義すると、TOP_OF_FABRICフラグは無視されます。leaf_onlyは、この値が未定義であるか、_leaf_level_に設定されている場合にのみ設定できます。
DERIVED_LEVEL:
derived_level：
Level value computed via automatic level derivation when CONFIGURED_LEVEL is equal to UNDEFINED_LEVEL.
configured_levelがundefined_levelに等しい場合、自動レベル導入を介して計算されたレベル値。
LEAF_2_LEAF:
leaf_2_leaf：
An optional flag that can be configured on a node to make sure it supports procedures defined in Section 6.8.9. It is a capability that implies LEAF_ONLY and the corresponding restrictions. The TOP_OF_FABRIC flag is ignored when set at the same time as this flag. It is carried in the _leaf_only_and_leaf_2_leaf_procedures_ schema flag.
セクション6.8.9で定義されている手順をサポートするようにノードで構成できるオプションフラグ。これは、leaf_onlyと対応する制限を暗示する能力です。このフラグと同時に設定すると、TOP_OF_FABRICフラグは無視されます。_LEAF_ONLY_AND_LEAF_2_LEAF_PROCEDURES_ SCHEMAフラグで運ばれます。
LEVEL_VALUE:
level_value：
With ZTP, the original definition of "level" in Section 3.1 is both extended and relaxed. First, the level is defined now as LEVEL_VALUE and is the first defined value of CONFIGURED_LEVEL followed by DERIVED_LEVEL. Second, it is possible for nodes to be more than one level apart to form adjacencies if any of the nodes is at least LEAF_ONLY.
ZTPを使用すると、セクション3.1の「レベル」の元の定義が拡張およびリラックスされています。まず、レベルはレベル_Valueとして定義され、configured_levelの最初に定義された値に続いてderived_levelが続きます。第二に、ノードのいずれかが少なくともleaf_onlyである場合、ノードが複数のレベルに分離して隣接を形成する可能性があります。
Valid Offered Level (VOL):
有効な提供レベル（vol）：
A neighbor's level received in a valid LIE (i.e., passing all checks for adjacency formation while disregarding all clauses involving level values) persisting for the duration of the holdtime interval on the LIE. Observe that offers from nodes offering the level value of _leaf_level_ do not constitute VOLs (since no valid DERIVED_LEVEL can be obtained from those and consequently the _not_a_ztp_offer_ flag MUST be ignored). Offers from LIEs with _not_a_ztp_offer_ being true are not VOLs either. If a node maintains parallel adjacencies to the neighbor, VOL on each adjacency is considered as equivalent, i.e., the newest VOL from any such adjacency updates the VOL received from the same node.
嘘をついている間、有効な嘘で受け取った隣人のレベル（つまり、レベルの値を含むすべての条項を無視しながら、隣接層のすべてのチェックを渡す）は、嘘の保留時間間隔の期間中に持続します。_LEAF_LEVEL_のレベル値を提供するノードからのオファーは、VOLSを構成しません（それらから有効なderived_levelを取得できないため、_NOT_A_ZTP_OFFER_フラグは無視する必要があります）。_NOT_A_ZTP_OFFER_が真実であるという嘘からのオファーもVolsではありません。ノードがネイバーへの並列隣接を維持する場合、各隣接のvolは同等のものと見なされます。つまり、同じノードから受け取ったVoLがvolを更新する最新のVolです。
Highest Available Level (HAL):
利用可能な最高レベル（HAL）：
Highest-defined level value received from all VOLs received.
受信したすべてのVolから受信した最高定義レベル値。
Highest Available Level Systems (HALS):
最高の利用可能レベルシステム（HAL）：
Set of nodes offering HAL VOLs.
HAL Volsを提供するノードのセット。
Highest Adjacency ThreeWay (HAT):
最高の隣接3ウェイ（帽子）：
Highest neighbor level of all the formed _ThreeWay_ adjacencies for the node.
ノードの形成されたすべての_threeway_隣接の最高の隣接レベル。
RIFT nodes require a 64-bit System ID that SHOULD be derived as EUI-64 MAC Address Block Large (MA-L) according to [EUI64]. The organizationally governed portion of this ID (24 bits) can be used to generate multiple IDs if required to indicate more than one RIFT instance.
RIFTノードには、[EUI64]に従って、EUI-64 MACアドレスブロックが大きい（MA-L）として導出される64ビットシステムIDが必要です。このIDの組織的に統治された部分（24ビット）を使用して、複数のRIFTインスタンスを示すために必要な場合に複数のIDを生成できます。
As matter of operational concern, the router MUST ensure that such identifier is not changing very frequently (or at least not without sending all its TIEs with fairly short lifetimes, i.e., purging them) since the network may otherwise be left with large amounts of stale TIEs in other nodes (though this is not necessarily a serious problem if the procedures described in Section 9 are implemented).
運用上の懸念事項として、ルーターは、ネットワークに他のノードに大量の古いネクタイが残されている可能性があるため、そのような識別子が非常に頻繁に変化していないことを保証する必要があります（または、かなり短い寿命ですべての関係を送信せずに、つまりそれらをパージする）必要があります（ただし、セクション9に記載されている手順が実装されている場合、これは必ずしも深刻な問題ではありません）。
ZTP forces considerations of an incorrectly or unusually cabled fabric and how such a topology can be forced into a "lattice" structure that a fabric represents (with further restrictions). A necessary and sufficient physical cabling is shown in Figure 28. The assumption here is that all nodes are in the same PoD.
ZTPは、誤ってまたは異常にケーブル化されたファブリックの考慮事項と、そのようなトポロジをどのようにしてファブリックが表す「格子」構造に押し込むことができるかを強制します（さらなる制限付き）。必要かつ十分な物理ケーブルを図28に示します。ここでの仮定は、すべてのノードが同じポッドにあるということです。
+---+
| A | s = TOP_OF_FABRIC
| s | L = LEAF_ONLY
++-++ L2L = LEAF_2_LEAF
| |
+--+ +--+
| |
+--++ ++--+
| E | | F |
| +-+ | +-----------+
++--+ | ++-++ |
| | | | |
| +-------+ | |
| | | | |
| | +----+ | |
| | | | |
++-++ ++-++ |
| I +-----+ J | |
| | | +-+ |
++-++ +--++ | |
| | | | |
+---------+ | +------+ |
| | | | |
+-----------------+ | |
| | | | |
++-++ ++-++ |
| X +-----+ Y +-+
|L2L| | L |
+---+ +---+
Figure 28: Generic ZTP Cabling Considerations
図28：一般的なZTPケーブルの考慮事項
First, RIFT must anchor the "top" of the cabling and that's what the TOP_OF_FABRIC flag at node A is for. Then, things look smooth until the protocol has to decide whether node Y is at the same level as I, J (and as consequence, X is south of it), or X. This is unresolvable here until we "nail down the bottom" of the topology. To achieve that, the protocol chooses to use the leaf flags in X and Y in this example. In the case where Y does not have a leaf flag, it will try to elect the highest level offered and end up being in same level as I and J.
まず、リフトはケーブルの「上」を固定する必要があり、それがノードAのTOP_OF_FABRICフラグの目的です。次に、プロトコルがI、J、J（および結果としてXが南にある）と同じレベルにあるかどうかを決定する必要があるまで、物事は滑らかに見えます。それを達成するために、プロトコルは、この例でxとyの葉フラグを使用することを選択します。yに葉の旗がない場合、それは提供された最高レベルを選択し、最終的にはIやJと同じレベルになります。
A node starting up with UNDEFINED_VALUE (i.e., without a CONFIGURED_LEVEL or any leaf or TOP_OF_FABRIC flag) MUST follow these additional procedures:
未定義の値で始まるノード（i.n.、構成されたレベルまたは葉またはtop_of_fabricフラグのない）は、これらの追加手順に従う必要があります。
1. It advertises its LEVEL_VALUE on all LIEs (observe that this can be UNDEFINED_LEVEL, which in terms of the schema, is simply an omitted optional value).
1. それはすべての嘘にそのlevel_valueを宣伝しています（これは、スキーマの観点からは、単に省略されたオプションの値であるという未定義であることを観察します）。
2. It computes HAL as the numerically highest available level in all VOLs.
2. HALをすべてのVolsで数値的に最も高い利用可能レベルとして計算します。
3. Then, it chooses MAX(HAL-1,0) as its DERIVED_LEVEL. The node then starts to advertise this derived level.
3. 次に、derived_levelとしてmax（hal-1,0）を選択します。その後、ノードはこの派生レベルの宣伝を開始します。
4. A node that lost all adjacencies with the HAL value MUST holddown computation of the new DERIVED_LEVEL for at least one second unless it has no VOLs from southbound adjacencies. After the holddown timer expired, it MUST discard all received offers, recompute DERIVED_LEVEL, and announce it to all neighbors.
4. HAL値ですべての隣接を失ったノードは、南行きの隣接からのVolがない限り、新しいderived_levelのHolddown計算を少なくとも1秒間保留する必要があります。ホールドダウンタイマーの有効期限が切れた後、受信したすべてのオファーを破棄し、derived_levelを再計算し、すべての隣人に発表する必要があります。
5. A node MUST reset any adjacency that has changed the level it is offering and is in _ThreeWay_ state.
5. ノードは、提供されているレベルを変更し、_threeway_状態にある隣接をリセットする必要があります。
6. A node that changed its defined level value MUST re-advertise its own TIEs (since the new _PacketHeader_ will contain a different level than before). The sequence number of each TIE MUST be increased.
6. 定義されたレベル値を変更したノードは、独自のタイを再承認する必要があります（新しい_packetheader_には以前とは異なるレベルが含まれるため）。各タイのシーケンス番号を増やす必要があります。
7. After a level has been derived, the node MUST set the _not_a_ztp_offer_ on LIEs towards all systems offering a VOL for HAL.
7. レベルが導出された後、ノードは_NOT_A_ZTP_OFFER_をHALのVOLを提供するすべてのシステムに嘘をつく必要があります。
8. A node that changed its level SHOULD flush TIEs of all other nodes from its LSDB; otherwise, stale information may persist on "direction reversal", i.e., nodes that seemed south are now north or east-west. This will not prevent the correct operation of the protocol but could be slightly confusing operationally.
8. レベルを変更するノードは、他のすべてのノードのネクタイをLSDBからフラッシュするはずです。それ以外の場合、古い情報は「方向反転」、つまり南にあると思われるノードに現在北または東西にあるように持続する場合があります。これは、プロトコルの正しい動作を妨げるものではありませんが、操作的にわずかに混乱する可能性があります。
A node starting with LEVEL_VALUE being 0 (i.e., it assumes a leaf function by being configured with the appropriate flags or has a CONFIGURED_LEVEL of 0) MUST follow this additional procedure:
level_valueから始まるノードは0です（つまり、適切なフラグで構成されているか、0のconfigured_levelを持っていることで葉の関数を想定します）この追加の手順に従う必要があります。
1. It computes HAT per the procedures above but does *not* use it to compute DERIVED_LEVEL. HAT is used to limit adjacency formation per Section 6.2.
1. 上記の手順ごとに帽子を計算しますが、それを使用して * derived_levelを計算しません。帽子は、セクション6.2ごとに隣接型の形成を制限するために使用されます。
It MAY also follow this modified procedure:
また、この変更された手順に従うこともあります。
1. It may pick a different strategy to choose VOL, e.g., use the VOL value with highest number of VOLs. Such strategies are only possible since the node always remains "at the bottom of the fabric", while another layer could "invert" the fabric by picking its preferred VOL in a different fashion rather than always trying to achieve the highest viable level.
1. Volを選択するための別の戦略を選択する場合があります。たとえば、Vol値を最も多くのVolsで使用します。このような戦略は、ノードが常に「ファブリックの底部」に残っているためにのみ可能ですが、別のレイヤーは、常に最高の実行可能レベルを達成しようとするのではなく、異なる方法で好ましいVolを選択することで生地を「反転」する可能性があります。
This section specifies the precise, normative ZTP FSM and can be omitted unless the reader is pursuing an implementation of the protocol. For additional clarity, a graphical representation of the ZTP FSM is depicted in Figure 29. It may also be helpful to refer to the normative schema in Section 7.
このセクションでは、正確で規範的なZTP FSMを指定し、読者がプロトコルの実装を追求していない限り省略できます。さらに明確にするために、ZTP FSMのグラフィカルな表現を図29に示します。セクション7の規範スキーマを参照することも役立つ場合があります。
The initial state is ComputeBestOffer.
初期状態はcomputebestofferです。
Enter
|
v
+------------------+
| ComputeBestOffer |
| |<----+
| | | ChangeLocalHierarchyIndications
| | | ChangeLocalConfiguredLevel
| | | NeighborOffer
| | | BetterHAL
| | | BetterHAT
| | | LostHAT
| | | ShortTic
| |-----+
| |
| |<---------------------
| |---------------------> (UpdatingClients)
| | ComputationDone
+------------------+
^ |
| | LostHAL
| V
(HoldingDown)
(ComputeBestOffer)
| ^
| | ChangeLocalHierarchyIndications
| | ChangeLocalConfiguredLevel
| | HoldDownExpired
V |
+------------------+
| HoldingDown |
| |<----+
| | | NeighborOffer
| | | BetterHAL
| | | BetterHAT
| | | LostHAL
| | | LostHat
| | | ComputationDone
| | | ShortTic
| |-----+
+------------------+
^
|
(UpdatingClients)
(ComputeBestOffer)
| ^
| | ChangeLocalHierarchyIndications
| | ChangeLocalConfiguredLevel
| | BetterHAL
| | BetterHAT
| | LostHAT
V |
+------------------+
| UpdatingClients |
| |<----+
| | |
| | | NeighborOffer
| | | ShortTic
| |-----+
+------------------+
|
| LostHAL
V
(HoldingDown)
Figure 29: RIFT ZTP FSM
図29：RIFT ZTP FSM
The following terms are used for well-known procedures:
以下の用語は、よく知られている手順に使用されます。
* PUSH Event: queues an event to be executed by the FSM upon exit of this action
* プッシュイベント：このアクションの終了時にFSMによって実行されるイベントをキュー
* COMPARE_OFFERS: checks whether, based on current offers and held last results, the events BetterHAL/LostHAL/BetterHAT/LostHAT are necessary and returns them
* Compart_offers：現在のオファーに基づいて最後の結果を保持しているかどうかを確認します。
* UPDATE_OFFER: store current offer with adjacency holdtime as lifetime and COMPARE_OFFERS, then PUSH corresponding events
* update_offer：隣接する保留タイムを寿命と比較_offersとして保存してから、対応するイベントをプッシュします
* LEVEL_COMPUTE: compute best offered or configured level and HAL/ HAT, if anything changed, PUSH ComputationDone
* level_compute：最適なレベルまたは構成レベルとhal/ hatを計算してください。
* REMOVE_OFFER: remove the corresponding offer and COMPARE_OFFERS, PUSH corresponding events
* remove_offer：対応するオファーを削除してCompare_offersを削除し、対応するイベントをプッシュします
* PURGE_OFFERS: REMOVE_OFFER for all held offers, COMPARE OFFERS, PUSH corresponding events
* purge_offers：すべての保有オファーのremove_offer、オファーを比較する、対応するイベントをプッシュする
* PROCESS_OFFER:
* process_offer：
1. if no level is offered, then REMOVE_OFFER
1. レベルが提供されていない場合は、remove_offer
2. else
2. それ以外
a. if offered level > leaf, then UPDATE_OFFER
a. 提供されたレベル> leafの場合は、update_offer
b. else REMOVE_OFFER
b. else remove_offer
States:
州：
* ComputeBestOffer: Processes received offers to derive ZTP variables.
* ComputeBestOffer：ZTP変数を導出するためのプロセスが受信されたオファーを受け取りました。
* HoldingDown: Holding down while receiving updates.
* HoldingDown：アップデートの受信中に抑える。
* UpdatingClients: Updates other FSMs on the same node with computation results.
* UpdatingClients：同じノード上の他のFSMを計算結果を備えた更新します。
Events:
イベント：
* ChangeLocalHierarchyIndications: Node locally configured with new leaf flags.
* ChangelocalhierarchyIndications：新しいリーフフラグでローカルに構成されたノード。
* ChangeLocalConfiguredLevel: Node locally configured with a defined level.
* changelocalconfiguredlevel：定義されたレベルでローカルに構成されたノード。
* NeighborOffer: A new neighbor offer with optional level and neighbor state.
* NeighborOffer：オプションのレベルと隣人状態を備えた新しい近隣のオファー。
* BetterHAL: Better HAL computed internally.
* Betterhal：内部的に計算されたHALのBetter。
* BetterHAT: Better HAT computed internally.
* Betterhat：内部的に計算されたより良い帽子。
* LostHAL: Lost last HAL in computation.
* Losthal：ComputationでLast Halを失いました。
* LostHAT: Lost HAT in computation.
* losthat：計算で帽子を失った。
* ComputationDone: Computation performed.
* ComputationDone：計算が実行されました。
* HoldDownExpired: Holddown timer expired.
* HoldDownExpired：Holddownタイマーの有効期限が切れます。
* ShortTic: One-second timer tick. This event is provided to the FSM once a second by an implementation-specific mechanism that is outside the scope of this specification. This event is quietly ignored if the relevant transition does not exist.
* ショート：1秒のタイマーティック。このイベントは、この仕様の範囲外の実装固有のメカニズムによって1秒に1回FSMに提供されます。関連する移行が存在しない場合、このイベントは静かに無視されます。
Actions:
行動：
* on ChangeLocalConfiguredLevel in HoldingDown finishes in ComputeBestOffer: store configured level
* ComputeBestofferのHoldingDown FinishesのChangelocalConfiguredLevel：Store構成レベル
* on BetterHAT in HoldingDown finishes in HoldingDown: no action
* Holding DownのBetterhatで、HoldingDownのフィニッシュ：アクションなし
* on ShortTic in HoldingDown finishes in HoldingDown: remove expired offers, and if holddown timer expired, PUSH_EVENT HoldDownExpired
* HoldingDown Finishes in HoldingDownのショートダウン：期限切れのオファーを削除し、Holddownタイマーが期限切れになった場合、Push_Event HoldDownExppired
* on NeighborOffer in HoldingDown finishes in HoldingDown: PROCESS_OFFER
* HoldingDownのHoldingDown：Process_OfferのHoldingDown FinishesのNeighborEoffer
* on ComputationDone in HoldingDown finishes in HoldingDown: no action
* HoldingDownのComputationDoneで、HoldingDownの仕上げ：アクションなし
* on BetterHAL in HoldingDown finishes in HoldingDown: no action
* HoldingDown Finishes in Holddown：No ActionのBetterhal
* on LostHAT in HoldingDown finishes in HoldingDown: no action
* HolddownでのHoldingDownの終了で、アクションなしでLosthtを使用します
* on LostHAL in HoldingDown finishes in HoldingDown: no action
* ロスタルでは、ホールディングダウンのホールディングダウンフィニッシュで：アクションなし
* on HoldDownExpired in HoldingDown finishes in ComputeBestOffer: PURGE_OFFERS
* HolduteBestoffer：purge_offersの[Holddown Finishes]で保留中
* on ChangeLocalHierarchyIndications in HoldingDown finishes in ComputeBestOffer: store leaf flags
* ComputeBestofferのHoldingDown仕上げのChangelocalhierarchyIndicationsについて：葉の旗を保存します
* on LostHAT in ComputeBestOffer finishes in ComputeBestOffer: LEVEL_COMPUTE
* computebestofferのcomputebestoffer：revel_computeでcomputebestofferでlosth
* on NeighborOffer in ComputeBestOffer finishes in ComputeBestOffer: PROCESS_OFFER
* ComputeBestOfferのcomputeBestoffer：process_offerのneighboreOffer
* on BetterHAT in ComputeBestOffer finishes in ComputeBestOffer: LEVEL_COMPUTE
* computebestofferのcomputebestofferのbetterhat：revel_compute
* on ChangeLocalHierarchyIndications in ComputeBestOffer finishes in ComputeBestOffer: store leaf flags and LEVEL_COMPUTE
* ComputeBestOfferのComputeBestOfferのComputeBestOfferのComputeBestOfferのChangelocalHierarchIndications：leaf flagsとlevel_compute
* on LostHAL in ComputeBestOffer finishes in HoldingDown: if any southbound adjacencies present, then update holddown timer to normal duration, else fire holddown timer immediately
* LosthalのComputeBestOfferのフィニッシュでは、Holddownの仕上げ：サウスバウンド隣接が存在する場合は、Holddownタイマーを通常の期間に更新します。
* on ShortTic in ComputeBestOffer finishes in ComputeBestOffer: remove expired offers
* ComputeBestofferのcomputebestofferのcomputebestofferのショートで：期限切れのオファーを削除します
* on ComputationDone in ComputeBestOffer finishes in UpdatingClients: no action
* ComputeBestOfferのComputationDone on updatingClientsの仕上げ：アクションなし
* on ChangeLocalConfiguredLevel in ComputeBestOffer finishes in ComputeBestOffer: store configured level and LEVEL_COMPUTE
* ComputeBestOfferのComputeBestOfferのComputeBestOfferのChangelocalConfiguredLevel：ストア構成レベルとlevel_compute
* on BetterHAL in ComputeBestOffer finishes in ComputeBestOffer: LEVEL_COMPUTE
* computebestofferのcomputebestofferのbetterhalで：revel_compute
* on ShortTic in UpdatingClients finishes in UpdatingClients: remove expired offers
* updatingClientsの短縮でupdatingClientsで仕上げます。
* on LostHAL in UpdatingClients finishes in HoldingDown: if any southbound adjacencies are present, then update holddown timer to normal duration, else fire holddown timer immediately
* Losthal in updatingClientsのHoldingDownの仕上げ：サウスバウンド隣接が存在する場合は、Holddownタイマーを通常の期間に更新します。
* on BetterHAT in UpdatingClients finishes in ComputeBestOffer: no action
* ComputeBestofferでupdatingClientsのbetterhatの仕上げ：アクションなし
* on BetterHAL in UpdatingClients finishes in ComputeBestOffer: no action
* updatingClientsのBetterhalで、ComputeBestOfferで仕上げます：アクションなし
* on ChangeLocalConfiguredLevel in UpdatingClients finishes in ComputeBestOffer: store configured level
* shangelocalconfiguredlevel in updatingclientsのcomputebestofferで仕上げます：ストア構成レベル
* on ChangeLocalHierarchyIndications in UpdatingClients finishes in ComputeBestOffer: store leaf flags
* ChangelocalhierarchyIndications in updatingClientsのcomputebestofferの仕上げ：leaf flagsを保存する
* on NeighborOffer in UpdatingClients finishes in UpdatingClients: PROCESS_OFFER
* updatingClientsのneighborofferで、updatingclients：process_offerで完了します
* on LostHAT in UpdatingClients finishes in ComputeBestOffer: no action
* updatingでcomputebestofferで終了するlosthatで：アクションなし
* on Entry into ComputeBestOffer: LEVEL_COMPUTE
* computebestofferへの入力時：revel_compute
* on Entry into UpdatingClients: update all LIE FSMs with computation results
* updatingClientsへの入力時：計算結果を含むすべての嘘fsmsを更新する
The procedures defined in Section 6.7.4 will lead to the RIFT topology and levels depicted in Figure 30.
セクション6.7.4で定義されている手順は、図30に示されているリフトトポロジとレベルにつながります。
+---+
| A |
| 24|
++-++
| |
+--+ +--+
| |
+--++ ++--+
| E | | F |
| 23+-+ | 23+-----------+
++--+ | ++-++ |
| | | | |
| +-------+ | |
| | | | |
| | +----+ | |
| | | | |
++-++ ++-++ |
| I +-----+ J | |
| 22| | 22| |
++--+ +--++ |
| | |
+---------+ | |
| | |
++-++ +---+ |
| X | | Y +-+
| 0 | | 0 |
+---+ +---+
Figure 30: Generic ZTP Topology Autoconfigured
図30：ジェネリックZTPトポロジーオートコンチュレーション
In the case where the LEAF_ONLY restriction on Y is removed, the outcome would be very different however and result in Figure 31. This basically demonstrates that autoconfiguration makes miscabling detection hard and, with that, can lead to undesirable effects in cases where leaves are not "nailed" by the appropriately configured flags and arbitrarily cabled.
yのleaf_onlyの制限が削除された場合、結果は非常に異なり、図31になります。これは基本的に、オートコンデューションが誤りの検出を激しくすることを示しており、それにより、適切に構成されたフラグと任意のケーブルで葉が「釘付け」されない場合に望ましくない効果をもたらす可能性があります。
+---+
| A |
| 24|
++-++
| |
+--+ +--+
| |
+--++ ++--+
| E | | F |
| 23+-+ | 23+-------+
++--+ | ++-++ |
| | | | |
| +-------+ | |
| | | | |
| | +----+ | |
| | | | |
++-++ ++-++ +-+-+
| I +-----+ J +-----+ Y |
| 22| | 22| | 22|
++-++ +--++ ++-++
| | | | |
| +-----------------+ |
| | |
+---------+ | |
| | |
++-++ |
| X +--------+
| 0 |
+---+
Figure 31: Generic ZTP Topology Autoconfigured
図31：ジェネリックZTPトポロジーオートコンチュレーション
Since RIFT distinguishes between different route types, such as external routes from other protocols, and additionally advertises special types of routes on disaggregation, the protocol MUST tie-break internally different types on a clear preference scale to prevent traffic loss or loops. The preferences are given in the schema type _RouteType_.
Riftは、他のプロトコルから外部ルートなどの異なるルートタイプを区別し、分解に関する特別なタイプのルートをさらに宣伝するため、プロトコルは、トラフィックの損失やループを防ぐために、明確な優先尺度で内部的に異なるタイプを結び付ける必要があります。設定は、スキーマタイプ_routeType_に記載されています。
Table 5 contains the route type as derived from the TIE type carrying it. Entries are sorted from the most preferred route type to the least preferred route type.
表5には、それを運ぶタイ型から派生したルートタイプが含まれています。エントリは、最も優先されたルートタイプから、最小のルートタイプにソートされます。
+==================================+======================+
| TIE Type | Resulting Route Type |
+==================================+======================+
| None | Discard |
+----------------------------------+----------------------+
| Local Interface | LocalPrefix |
+----------------------------------+----------------------+
| S-PGP | South PGP |
+----------------------------------+----------------------+
| N-PGP | North PGP |
+----------------------------------+----------------------+
| North Prefix | NorthPrefix |
+----------------------------------+----------------------+
| North External Prefix | NorthExternalPrefix |
+----------------------------------+----------------------+
| South Prefix and South Positive | SouthPrefix |
| Disaggregation | |
+----------------------------------+----------------------+
| South External Prefix and South | SouthExternalPrefix |
| Positive External Disaggregation | |
+----------------------------------+----------------------+
| South Negative Prefix | NegativeSouthPrefix |
+----------------------------------+----------------------+
Table 5: TIEs and Contained Route Types
表5：タイと含まれるルートタイプ
The overload attribute is specified in the packet encoding schema (Section 7) in the _overload_ flag.
過負荷属性は、_Overload_フラグのパケットエンコードスキーマ（セクション7）で指定されています。
The overload flag MUST be respected by all necessary SPF computations. A node with the overload flag set SHOULD advertise all locally hosted prefixes, both northbound and southbound; all other southbound prefixes SHOULD NOT be advertised.
過負荷フラグは、必要なすべてのSPF計算によって尊重されなければなりません。オーバーロードフラグセットを備えたノードは、ノースバウンドとサウスバウンドの両方で、ローカルでホストされているすべてのプレフィックスを宣伝する必要があります。他のすべての南行きのプレフィックスを宣伝しないでください。
Leaf nodes SHOULD set the overload attribute on all originated Node TIEs. If spine nodes were to forward traffic not intended for the local node, the leaf node would not be able to prevent routing/ forwarding loops as it does not have the necessary topology information to do so.
リーフノードは、すべての起源のノードタイに過負荷属性を設定する必要があります。スパインノードがローカルノード用に意図されていないトラフィックを転送する場合、リーフノードは、必要なトポロジー情報がないため、ルーティング/転送ループを防ぐことができません。
Leaf nodes only have visibility to directly connected nodes and therefore are not required to run "full" SPF computations. Instead, prefixes from neighboring nodes can be gathered to run a "partial" SPF computation in order to build the routing table.
リーフノードは、直接接続されたノードへの可視性のみを持つため、「完全な」SPF計算を実行するために必要はありません。代わりに、隣接するノードからのプレフィックスを収集して、ルーティングテーブルを構築するために「部分的な」SPF計算を実行できます。
Leaf nodes SHOULD only hold their own N-TIEs and, in cases of L2L implementations, the N-TIEs of their East-West neighbors. Leaf nodes MUST hold all S-TIEs from their neighbors.
葉のノードは、独自のN-Tiesのみを保持する必要があり、L2L実装の場合、東西の隣人のN-Tiesを保持する必要があります。葉のノードは、隣人からすべてのS-Tiesを保持する必要があります。
Normally, a full network graph is created based on local N-TIEs and remote S-TIEs that it receives from neighbors, at which time, necessary SPF computations are performed. Instead, leaf nodes can simply compute the minimum cost and next-hop set of each leaf neighbor by examining its local adjacencies. Associated N-TIEs are used to determine bidirectionality and derive the next-hop set. The cost is then derived from the minimum cost of the local adjacency to the neighbor and the prefix cost.
通常、完全なネットワークグラフは、近隣から受信するローカルN-TiesとリモートS-Tiesに基づいて作成され、その時点で必要なSPF計算が実行されます。代わりに、葉のノードは、ローカルの隣接を調べることにより、各葉の隣人の最小コストと次のホップセットを単純に計算できます。関連付けられたN-TIEは、双方向性を決定し、次のホップセットを導き出すために使用されます。コストは、近隣への地元の隣接の最低コストとプレフィックスコストから得られます。
Leaf nodes would then attach necessary prefixes as described in Section 6.6.
次に、葉のノードは、セクション6.6で説明されているように、必要なプレフィックスを取り付けます。
The RIFT control plane MUST maintain the real time status of every prefix, to which port it is attached, and to which leaf node that port belongs. This is still true in cases of IP mobility where the point of attachment may change several times a second.
リフト制御プレーンは、すべてのプレフィックスのリアルタイムステータスを維持する必要があります。これには、ポートが取り付けられており、ポートが属する葉のノードが属します。これは、添付ファイルのポイントが1秒に数回変化する可能性があるIPモビリティの場合でも当てはまります。
There are two classic approaches to explicitly maintain this information, "timestamp" and "sequence counter", which are defined as follows:
この情報を明示的に維持するための2つの古典的なアプローチがあります。「タイムスタンプ」と「シーケンスカウンター」は次のように定義されています。
timestamp:
タイムスタンプ：
With this method, the infrastructure SHOULD record the precise time at which the movement is observed. One key advantage of this technique is that it has no dependency on the mobile device. One drawback is that the infrastructure MUST be precisely synchronized in order to be able to compare timestamps as the points of attachment change. This could be accomplished by utilizing the Precision Time Protocol (PTP) (IEEE Std. 1588 [IEEEstd1588] or 802.1AS [IEEEstd8021AS]), which is designed for bridged LANs. Both the precision of the synchronization protocol and the resolution of the timestamp must beat the shortest possible roaming time on the fabric. Another drawback is that the presence of a mobile device may only be observed asynchronously, such as when it starts using an IP protocol like ARP [RFC0826], IPv6 Neighbor Discovery [RFC4861], IPv6 Stateless Address Configuration [RFC4862], DHCP [RFC2131], or DHCPv6 [RFC8415].
この方法では、インフラストラクチャは、動きが観察される正確な時間を記録する必要があります。この手法の重要な利点の1つは、モバイルデバイスに依存していないことです。1つの欠点は、タイムスタンプを添付ファイルのポイントと比較できるようにするために、インフラストラクチャを正確に同期する必要があることです。これは、ブリッジラン用に設計された精密時間プロトコル（PTP）（IEEESTD。1588[IEEESTD1588]または802.1AS [IEEESTD8021AS]）を利用することで実現できます。同期プロトコルの精度とタイムスタンプの解像度の両方は、ファブリックの可能な限り短いローミング時間を打ち負かす必要があります。もう1つの欠点は、ARP [RFC0826]、IPv6隣接アドレス設定[RFC4861]、IPv6ステートレスアドレス構成[RFC4862]、DHCP [RFC2131]、またはDHCPV6 [RFC8415]などのIPプロトコルの使用を開始する場合など、モバイルデバイスの存在が非同期にのみ観察される可能性があることです。
sequence counter:
シーケンスカウンター：
With this method, a mobile device notifies its point of attachment on arrival with a sequence counter that is incremented upon each movement. On the positive side, this method does not have a dependency on a precise sense of time, since the sequence of movements is kept in order by the mobile device. The disadvantage of this approach is the need for support for protocols that may be used by the mobile device to register its presence to the leaf node with the capability to provide a sequence counter. Well-known issues with sequence counters, such as wrapping and comparison rules, MUST be addressed properly. Sequence numbers MUST be compared by a single homogenous source to make operation feasible. Sequence number comparison from multiple heterogeneous sources would be extremely difficult to implement.
この方法を使用すると、モバイルデバイスは、各動きで増加するシーケンスカウンターを使用して、到着時にアタッチメントのポイントを通知します。プラス面では、この方法は、モバイルデバイスによって動きのシーケンスが整備されているため、正確な時間感覚に依存しません。このアプローチの欠点は、モバイルデバイスが使用してシーケンスカウンターを提供する機能を備えたリーフノードにその存在を登録するために使用できるプロトコルをサポートする必要性です。ラッピングや比較ルールなど、シーケンスカウンターの有名な問題に適切に対処する必要があります。操作を実行可能にするために、シーケンス番号を単一の均質なソースで比較する必要があります。複数の不均一なソースからのシーケンス数の比較を実装するのは非常に困難です。
RIFT supports a hybrid approach by using an optional 'PrefixSequenceType' attribute (which is also called a _monotonic_clock_ in the schema) that consists of a timestamp and optional sequence number field. In case of a negatively distributed prefix, this attribute MUST NOT be included by the originator and it MUST be ignored by all nodes during computation. When this attribute is present (observe that per data schema, the attribute itself is optional, but in case it is included, the "timestamp" field is required):
Riftは、タイムスタンプとオプションのシーケンス番号フィールドで構成されるオプションの「プレフィックスsequenceCype」属性（スキーマの_monotonic_clock_とも呼ばれる）を使用して、ハイブリッドアプローチをサポートします。否定的に分布したプレフィックスの場合、この属性はオリジネーターに含める必要はなく、計算中にすべてのノードで無視する必要があります。この属性が存在する場合（データスキーマごとに、属性自体がオプションであることを観察しますが、それが含まれている場合は、「タイムスタンプ」フィールドが必要です）：
* The leaf node MAY advertise a timestamp of the latest sighting of a prefix, e.g., by snooping IP protocols or the node using the time at which it advertised the prefix. RIFT transports the timestamp within the desired North Prefix TIEs as the [IEEEstd1588] timestamp.
* リーフノードは、接頭辞を宣伝した時間を使用してIPプロトコルまたはノードをスヌーピングすることにより、プレフィックスの最新の目撃のタイムスタンプを宣伝する場合があります。Riftは、[IEEESTD1588]タイムスタンプとして、目的の北の接頭辞タイム内のタイムスタンプを輸送します。
* RIFT MAY interoperate with "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505], which provides a method for registering a prefix with a sequence number called a Transaction ID (TID). In such cases, RIFT SHOULD transport the derived TID without modification.
* Riftは、「6Lowpan Neighbor Discoveryの登録拡張機能」[RFC8505]と相互運用する場合があります。これは、トランザクションID（TID）と呼ばれるシーケンス番号を持つプレフィックスを登録する方法を提供します。そのような場合、Riftは導出されたTIDを変更せずに輸送する必要があります。
* RIFT also defines an abstract negative clock (ASNC) (also called an "undefined" clock). The ASNC MUST be considered older than any other defined clock. By default, when a node receives a North Prefix TIE that does not contain a 'PrefixSequenceType' attribute, it MUST interpret the absence as the ASNC.
* Riftは、抽象的なネガティブクロック（ASNC）（「未定義の」クロックとも呼ばれます）も定義します。ASNCは、他の定義されたクロックよりも古いと見なされる必要があります。デフォルトでは、ノードが「プレフィックスsequencenceType」属性を含まないノースプレフィックスタイを受信する場合、不在をASNCとして解釈する必要があります。
* Any prefix present on the fabric in multiple nodes that have the *same* clock is considered as anycast.
* *同じ *クロックを持つ複数のノードのファブリックに存在するプレフィックスは、Anycastと見なされます。
* The RIFT specification assumes that all nodes are being synchronized within at least 200 milliseconds or less. This is achievable through the use of NTP [RFC5905]. An implementation MAY provide a way to reconfigure a domain to a different value and provides a variable called MAXIMUM_CLOCK_DELTA for this purpose.
* RIFT仕様は、すべてのノードが少なくとも200ミリ秒以内に同期されていることを前提としています。これは、NTP [RFC5905]を使用することで達成可能です。実装は、ドメインを別の値に再構成する方法を提供し、この目的のためにMaximif_Clock_deltaと呼ばれる変数を提供する場合があります。
All monotonic clock values MUST be compared to each other using the following rules:
すべての単調なクロック値は、次のルールを使用して互いに比較する必要があります。
1. The ASNC is older than any other value except ASNC *and*
1. ASNCは、ASNC *と *を除く他のどの値よりも古い
2. Clocks with timestamps differing by more than MAXIMUM_CLOCK_DELTA are comparable by using the timestamps only *and*
2. タイムスタンプを持つクロックは、最大値を超えることによって異なります。
3. Clocks with timestamps differing by less than MAXIMUM_CLOCK_DELTA are comparable by using their TIDs only, *and*
3. タイムスタンプのある時計は、最大値未満で異なります。
4. An undefined TID is always older than any other TID, *and*
4. 未定義のTIDは、他のどのTIDよりも常に古い *および *
5. TIDs are compared using rules of [RFC8505].
5. [RFC8505]のルールを使用してTIDを比較します。
For attachment changes that occur less frequently (e.g., once per second), the timestamp that the RIFT infrastructure captures should be enough to determine the most current discovery. If the point of attachment changes faster than the maximum drift of the timestamping mechanism (i.e., MAXIMUM_CLOCK_DELTA), then a sequence number SHOULD be used to enable necessary precision to determine currency.
発生する頻度が低い（たとえば、1秒あたり1回）添付ファイルの変更の場合、リフトインフラストラクチャがキャプチャするタイムスタンプは、最新の発見を決定するのに十分なはずです。アタッチメントのポイントがタイムスタンプメカニズムの最大ドリフト（つまり、Maximum_Clock_delta）よりも速く変化する場合、シーケンス番号を使用して、通貨を決定するために必要な精度を可能にする必要があります。
The sequence counter in [RFC8505] is encoded as one octet and wraps around using the arithmetic defined in Appendix A.
[RFC8505]のシーケンスカウンターは、1つのオクテットとしてエンコードされ、付録Aで定義された算術を使用してラップします。
Within the resolution of MAXIMUM_CLOCK_DELTA, sequence counter values captured during 2 sequential iterations of the same timestamp SHOULD be comparable. This means that with default values, a node may move up to 127 times in a 200-millisecond period and the clocks will remain comparable. This allows the RIFT infrastructure to explicitly assert the most up-to-date advertisement.
Maximum_Clock_Deltaの解像度内で、同じタイムスタンプの2つの順次反復中にキャプチャされたシーケンスカウンター値は同等でなければなりません。これは、デフォルト値がある場合、ノードは200ミリ秒の期間で最大127倍に移動する可能性があり、クロックは同等のままであることを意味します。これにより、Riftインフラストラクチャは最新の広告を明示的に主張することができます。
A unicast prefix can be attached to one leaf at most, whereas an anycast prefix may be reachable via more than one leaf.
ユニキャストのプレフィックスはせいぜい1つのリーフに取り付けることができますが、Anycastプレフィックスは複数の葉を介して到達できる場合があります。
If a monotonic clock attribute is provided on the prefix, then the prefix with the *newest* clock value is strictly preferred. An anycast prefix does not carry a clock, or all clock attributes MUST be the same under the rules of Section 6.8.4.1.
プレフィックスに単調なクロック属性が提供される場合、 *最新の *クロック値の接頭辞が厳密に推奨されます。Anycast Prefixにはクロックが含まれていないか、すべてのクロック属性がセクション6.8.4.1のルールで同じでなければなりません。
In mobility events, it is important that the leaf is reflooding as quickly as possible to communicate the absence of the prefix that moved.
モビリティイベントでは、移動した接頭辞がないことを伝えるために、葉ができるだけ迅速に繰り返していることが重要です。
Without support for [RFC8505], movements on the fabric within intervals smaller than 100 msec will be interpreted as anycast.
[RFC8505]のサポートがなければ、100ミリ秒以下の間隔内でファブリックの動きがAnycastとして解釈されます。
RIFT is agnostic to any overlay technologies and their associated control and transports that run on top of it (e.g., Virtual eXtensible Local Area Network (VXLAN)). It is expected that leaf nodes and possibly ToF nodes can perform necessary data plane encapsulation.
Riftは、あらゆるオーバーレイテクノロジーと、その上に実行される関連する制御と輸送（例：仮想拡張可能なローカルエリアネットワーク（VXLAN））にとって不可知論的です。葉のノードと場合によっては、必要なデータプレーンのカプセル化を実行できることが予想されます。
In the context of mobility, overlays provide another possible solution to avoid injecting mobile prefixes into the fabric as well as improving scalability of the deployment. It makes sense to consider overlays for mobility solutions in IP fabrics. As an example, a mobility protocol such as the Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301] may inform the ingress leaf of the location of the egress leaf in real time.
モビリティのコンテキストでは、オーバーレイは、モバイルプレフィックスをファブリックに注入し、展開のスケーラビリティを改善しないようにするための別の可能なソリューションを提供します。IPファブリックのモビリティソリューションのオーバーレイを検討することは理にかなっています。例として、ロケーター/ID分離プロトコル（LISP）[RFC9300] [RFC9301]などのモビリティプロトコルは、エグレス葉の場所をリアルタイムで侵入葉に通知する場合があります。
Another possibility is to consider that mobility is an underlay service and support it in RIFT to an extent. The load on the fabric increases with the amount of mobility since a move forces flooding and computation on all nodes in the scope of the move so tunneling from the leaf to the ToF may be desired to speed up convergence times.
もう1つの可能性は、モビリティがアンダーレイサービスであり、ある程度リフトでそれをサポートすることを考慮することです。動きが移動の範囲内のすべてのノードの洪水と計算を強制するため、生地の負荷はモビリティの量とともに増加します。そのため、葉からTOFへのトンネリングが収束時間を高速化するために望まれる場合があります。
RIFT supports the southbound distribution of key-value pairs that can be used to distribute information to facilitate higher levels of functionality (e.g., distribution of configuration information). KV South TIEs may arrive from multiple nodes and therefore MUST execute the following tie-breaking rules for each key:
Riftは、より高いレベルの機能性（構成情報の分布など）を容易にするために情報を配布するために使用できるキー価値ペアの南行きの分布をサポートします。KVサウスタイは複数のノードから到着する可能性があるため、各キーの次のタイブレイクルールを実行する必要があります。
1. Only KV TIEs received from nodes to which a bidirectional adjacency exists MUST be considered.
1. 双方向の隣接性が存在するノードから受け取ったKV関係のみを考慮する必要があります。
2. For each valid KV South TIEs that contains the same key, the value within the South TIE with the highest level will be preferred. If the levels are identical, the highest originating System ID will be preferred. In the case of overlapping keys in the winning South TIE, the behavior is undefined.
2. 同じキーを含む有効なKVサウスタイごとに、最高レベルの南ネクタイ内の値が推奨されます。レベルが同一の場合、最高の元のシステムIDが推奨されます。勝利した南ネクタイの鍵が重複している場合、動作は未定義です。
Consider that if a node goes down, nodes south of it will lose associated adjacencies, causing them to disregard corresponding KVs. New KV South TIEs are advertised to prevent stale information being used by nodes that are further south. KV advertisements southbound are not a result of independent computation by every node over the same set of South TIEs but a diffused computation.
ノードがダウンした場合、ノードの南には関連する隣接が失われ、対応するKVSを無視するようになります。新しいKVサウスタイは、さらに南にあるノードによって古い情報が使用されるのを防ぐために宣伝されています。南行きのKV広告は、同じ南タイのセットを介したすべてのノードによる独立した計算の結果ではなく、拡散計算です。
Certain use cases necessitate distribution of essential KV information that is generated by the leaves in the northbound direction. Such information is flooded in KV North TIEs. Since the originator of the KV North TIEs is preserved during flooding, the corresponding mechanism will define, if necessary, tie-breaking rules depending on the semantics of the information.
特定のユースケースでは、北方向の葉によって生成される必須KV情報の分布が必要です。このような情報は、KVノースタイで浸水しています。KVノースタイの発信者は洪水中に保存されているため、対応するメカニズムは、必要に応じて、情報のセマンティクスに応じてタイブレークルールを定義します。
Only KV TIEs from nodes that are reachable via multi-plane reachability computation mentioned in Section 6.5.2.3 SHOULD be considered.
セクション6.5.2.3で言及したマルチプレーンリーチ可能性計算を介して到達可能なノードからのKV関係を考慮する必要があります。
RIFT MAY incorporate Bidirectional Forwarding Detection (BFD) [RFC5881] to react quickly to link failures. In such case, the following procedures are introduced:
RIFTは、双方向転送検出（BFD）[RFC5881]を組み込んで、障害をリンクするために迅速に反応する場合があります。そのような場合、次の手順が導入されています。
1. After RIFT _ThreeWay_ hello adjacency convergence, a BFD session MAY be formed automatically between the RIFT endpoints without further configuration using the exchanged discriminators that are equal to the _local_id_ in the _LIEPacket_. The capability of the remote side to support BFD is carried in the LIEs in _LinkCapabilities_.
1. Rift _threeway_ Hello Adjacecency Convergenceの後、_liepacket_の_local_id_に等しい交換された識別器を使用して、さらに構成することなく、Riftエンドポイント間にBFDセッションが自動的に形成される場合があります。BFDをサポートするリモート側の能力は、_linkcapabilities_の嘘に掲載されています。
2. In case an established BFD session goes Down after it was Up, RIFT adjacency SHOULD be re-initialized and subsequently started from Init after it receives a consecutive BFD Up.
2. 確立されたBFDセッションが終了した後にダウンした場合、Rift隣接は再目的化され、その後、連続したBFDを受け取った後、INITから開始する必要があります。
3. In case of parallel links between nodes, each link MAY run its own independent BFD session or they MAY share a session. The specific manner in which this is implemented is outside the scope of this document.
3. ノード間の並列リンクの場合、各リンクは独自の独立したBFDセッションを実行するか、セッションを共有する場合があります。これが実装される特定の方法は、このドキュメントの範囲外です。
4. If link identifiers or BFD capabilities change, both the LIE and any BFD sessions SHOULD be brought down and back up again. In case only the advertised capabilities change, the node MAY choose to persist the BFD session.
4. リンク識別子またはBFD機能が変更された場合、嘘とBFDセッションの両方を倒して再びバックアップする必要があります。広告された機能のみが変更された場合、ノードはBFDセッションを持続することを選択できます。
5. Multiple RIFT instances MAY choose to share a single BFD session; in such cases, the behavior for which discriminators are used is undefined. However, RIFT MAY advertise the same link ID for the same interface in multiple instances to "share" discriminators.
5. 複数のRIFTインスタンスは、単一のBFDセッションを共有することを選択できます。そのような場合、判別器が使用される動作は未定義です。ただし、Riftは、複数のインスタンスで同じインターフェイスに対して同じリンクIDを宣伝して、差別器を「共有」する場合があります。
6. The BFD TTL follows [RFC5082].
6. BFD TTLは[RFC5082]に従います。
A well understood problem in fabrics is that, in case of link failures, it would be ideal to rebalance how much traffic is sent to switches in the next level based on the available ingress and egress bandwidth.
ファブリックでよく理解されている問題は、リンクの障害の場合、利用可能なイングレスと出口帯域幅に基づいて次のレベルのスイッチに送信されるトラフィックの量をバランスすることが理想的であることです。
RIFT supports a light-weight mechanism that can deal with the problem based on the fact that RIFT is loop-free.
Riftは、Riftがループフリーであるという事実に基づいて問題に対処できる軽量メカニズムをサポートしています。
Every RIFT node SHOULD compute the amount of northbound bandwidth available through neighbors at a higher level and modify the distance received on the default route from these neighbors. The bandwidth is advertised in the _NodeNeighborsTIEElement_ element, which represents the sum of the bandwidths of all the parallel links to a neighbor. Default routes with differing distances SHOULD be used to support weighted ECMP forwarding. Such a distance is called Bandwidth Adjusted Distance (BAD). This is best illustrated by a simple example.
すべてのRIFTノードは、より高いレベルで近隣から利用可能な北行きの帯域幅の量を計算し、これらの近隣からデフォルトルートで受信した距離を変更する必要があります。帯域幅は、_nodeneighborstieelement_要素で宣伝されています。これは、隣人へのすべての並列リンクの帯域幅の合計を表します。距離が異なるデフォルトルートは、加重ECMP転送をサポートするために使用する必要があります。このような距離は、帯域幅調整距離（悪い）と呼ばれます。これは、簡単な例で最もよく示されています。
100 x 100 100 Mbit/s
| x | |
+-+---+-+ +-+---+-+
| | | |
|Spin111| |Spin112|
+-+---+++ ++----+++
|x || || ||
|| |+---------------+ ||
|| +---------------+| ||
|| || || ||
|| || || ||
-----All Links 10 Mbit/s-----
|| || || ||
|| || || ||
|| +------------+| || ||
|| |+------------+ || ||
|x || || ||
+-+---+++ +--++-+++
| | | |
|Leaf111| |Leaf112|
+-------+ +-------+
Figure 32: Balancing Bandwidth
図32：帯域幅のバランス
Figure 32 depicts an example topology where links between leaf and spine nodes are 10 Mbit/s and links from spine nodes northbound are 100 Mbit/s. It includes parallel link failure between Leaf 111 and Spine 111, and as a result, Leaf 111 wants to forward more traffic towards Spine 112. Additionally, it includes an uplink failure on Spine 111.
図32は、リーフノードとスパインノードのリンクが10 mbit/sであり、脊椎ノードからのリンクが100 mbit/sである場合の例を示しています。Leaf 111とSpine 111の間の平行リンクの障害が含まれており、その結果、Leaf 111はより多くのトラフィックを脊椎112に転送したいと考えています。さらに、スパイン111のアップリンク障害が含まれます。
The local modification of the received default route distance from the upper level is achieved by running a relatively simple algorithm where the bandwidth is weighted exponentially, while the distance on the default route represents a multiplier for the bandwidth weight for easy operational adjustments.
上部レベルからの受信したデフォルトルート距離のローカル変更は、帯域幅が指数関数的に重み付けされている比較的単純なアルゴリズムを実行することで達成されますが、デフォルトルート上の距離は、簡単な動作調整のための帯域幅の重量の乗数を表します。
On a node, L, use Node TIEs to compute 3 values from each non-overloaded northbound neighbor, N:
ノードでは、ノードタイを使用して、オーバーロードされていない各ノースバウンドネイバーから3つの値を計算します。
1. L_N_u: sum of the bandwidth available from L to N (to account for parallel links)
1. L_N_U：LからNに利用可能な帯域幅の合計（並列リンクを説明するため）
2. N_u: sum of the uplink bandwidth available on N
2. N_U：nで利用可能なアップリンク帯域幅の合計
3. T_N_u: L_N_u * OVERSUBSCRIPTION_CONSTANT + N_u
3. T_N_U：l_n_u * oversubscription_constant + n_u
For all T_N_u, determine the corresponding M_N_u as log_2(next_power_2(T_N_u)) and determine MAX_M_N_u as the maximum value of all such M_N_u values.
すべてのT_N_Uについて、対応するM_N_Uをlog_2（next_power_2（t_n_u））として決定し、max_m_n_uをそのようなすべてのm_n_u値の最大値として決定します。
For each advertised default route from a node N, modify the advertised distance D to BAD = D * (1 + MAX_M_N_u - M_N_u) and use BAD instead of distance D to balance the weight of the default forwarding towards N.
ノードnから広告されたデフォルトルートごとに、広告距離dをbad = d *（1 + max_m_n_u -m_n_u）に変更し、距離dの代わりにbadを使用して、デフォルトの転送の重量のバランスをNにバランスさせます。
For the example above, a simple table of values will help in understanding the concept. The implicit assumption here is that all default route distances are advertised with D=1 and that OVERSUBSCRIPTION_CONSTANT=1.
上記の例では、単純な値の表が概念を理解するのに役立ちます。ここでの暗黙的な仮定は、すべてのデフォルトルート距離がd = 1で宣伝され、そのオーバーサブスクリプション_constant = 1で宣伝されることです。
+=========+===========+=======+=======+=====+
| Node | N | T_N_u | M_N_u | BAD |
+=========+===========+=======+=======+=====+
| Leaf111 | Spine 111 | 110 | 7 | 2 |
+---------+-----------+-------+-------+-----+
| Leaf111 | Spine 112 | 220 | 8 | 1 |
+---------+-----------+-------+-------+-----+
| Leaf112 | Spine 111 | 120 | 7 | 2 |
+---------+-----------+-------+-------+-----+
| Leaf112 | Spine 112 | 220 | 8 | 1 |
+---------+-----------+-------+-------+-----+
Table 6: BAD Computation
表6：悪い計算
If a calculation produces a result exceeding the range of the type, e.g., bandwidth, the result is set to the highest possible value for that type.
計算がタイプの範囲、たとえば帯域幅を超える結果を生成する場合、結果はそのタイプの可能な限り最高の値に設定されます。
BAD SHOULD only be computed for default routes. A node MAY compute and use BAD for any disaggregated prefixes or other RIFT routes. A node MAY use a different algorithm to weight northbound traffic based on the bandwidth. If a different algorithm is used, its successful behavior MUST NOT depend on uniformity of the algorithm or synchronization of BAD computations across the fabric. For example, it is conceivable that leaves could use real time link loads gathered by analytics to change the amount of traffic assigned to each default route next hop.
デフォルトルートに対してのみBADを計算する必要があります。ノードは、分解された接頭辞またはその他のリフトルートに対して、計算して使用する場合があります。ノードは、異なるアルゴリズムを使用して、帯域幅に基づいて北行きのトラフィックを重み付けすることができます。別のアルゴリズムを使用する場合、その成功した動作は、アルゴリズムの均一性や、ファブリック全体の悪い計算の同期に依存してはなりません。たとえば、葉が分析によって収集されたリアルタイムリンク負荷を使用して、次のデフォルトルートの各ルートに割り当てられたトラフィックの量を変更できると考えられます。
A change in available bandwidth will only affect, at most, two levels down in the fabric, i.e., the blast radius of bandwidth adjustments is constrained no matter the fabric's height.
利用可能な帯域幅の変化は、生地の2つのレベルのせいでせいぜい影響します。つまり、帯域幅調整の爆発半径は、生地の高さに関係なく制約されます。
Due to its loop-free nature, during South SPF, a node MAY account for the maximum available bandwidth on nodes in lower levels and modify the amount of traffic offered to the next level's southbound nodes. It is worth considering that such computations may be more effective if they are standardized, but they do not have to be. As long as a packet continues to flow southbound, it will take some viable, loop-free path to reach its destination.
ループフリーの性質により、南SPFの間、ノードは、低レベルのノードで利用可能な最大帯域幅を説明し、次のレベルのサウスバウンドノードに提供されるトラフィックの量を変更する場合があります。そのような計算は、標準化されている場合はより効果的である可能性があるが、そうである必要はないことを考慮する価値があります。パケットが南に向かって流れ続ける限り、目的地に到達するには、実行可能なループフリーのパスが必要になります。
In its LIEs, a node MAY advertise a locally significant, downstream-assigned, interface-specific label. One use of such a label is a hop-by-hop encapsulation allowing forwarding planes to be easily distinguished among multiple RIFT instances.
その嘘では、ノードは、局所的に重要で、下流で割り当てられたインターフェイス固有のラベルを宣伝する場合があります。このようなラベルの1つの使用は、ホップバイホップのカプセル化であり、転送面を複数のリフトインスタンスで簡単に区別できるようにします。
RIFT implementations SHOULD support special East-West adjacencies between leaf nodes. Leaf nodes supporting these procedures MUST:
RIFTの実装は、葉のノード間の特別な東西隣接をサポートする必要があります。これらの手順をサポートする葉のノードは、次のことをしなければなりません。
1. advertise the LEAF_2_LEAF flag in its node capabilities,
1. Node機能でLEAF_2_LEAFフラグを宣伝します。
2. set the overload flag on all leaf's Node TIEs,
2. すべてのリーフのノードタイにオーバーロードフラグを設定し、
3. flood only a node's own North and South TIEs over E-W leaf adjacencies,
3. E-W Leafの隣接を介してノード自身の北と南の結びつきのみを洪水し、
4. always use E-W leaf adjacency in all SPF computations,
4. すべてのSPF計算で常にE-W Leaf隣接を使用してください。
5. install a discard route for any advertised aggregate routes in a leaf's TIE, *and*
5. 葉のネクタイに宣伝されている集計ルートの廃棄ルートを設置します *と *
6. never form southbound adjacencies.
6. 南行きの隣接を形成しないでください。
This will allow the E-W leaf nodes to exchange traffic strictly for the prefixes advertised in each other's North Prefix TIEs since the southbound computation will find the reverse direction in the other node's TIE and install its north prefixes.
これにより、e-w葉のノードは、南行きの計算で他のノードのネクタイに逆方向を見つけてノースプレフィックスをインストールするため、互いのノースプレフィックスタイで宣伝されている接頭辞とトラフィックを厳密に交換できます。
Multi-Topology (MT) [RFC5120] and Multi-Instance (MI) [RFC8202] concepts are used today in link-state routing protocols to support several domains on the same physical topology. RIFT supports this capability by carrying transport ports in the LIE protocol exchanges. Multiplexing of LIEs can be achieved by either choosing varying multicast addresses or ports on the same address.
マルチトポロジー（MT）[RFC5120]およびマルチインスタンス（MI）[RFC8202]の概念は、同じ物理トポロジのいくつかのドメインをサポートするために、リンク状態ルーティングプロトコルで今日使用されています。Riftは、Lieプロトコル交換に輸送ポートを運ぶことにより、この機能をサポートします。嘘の多重化は、同じアドレスでさまざまなマルチキャストアドレスまたはポートを選択することで実現できます。
BFD interactions in Section 6.8.6 are implementation-dependent when multiple RIFT instances run on the same link.
セクション6.8.6のBFD相互作用は、同じリンクで複数のRIFTインスタンスが実行された場合に実装依存です。
Based on the rules defined in Sections 6.4 and 6.3.8 and given the presence of E-W links, RIFT can provide a one-hop protection for nodes that have lost all their northbound links. This can also be applied to multi-plane designs where complex link set failures occur at the ToF when links are exclusively used for flooding topology information. Appendix B.4 outlines this behavior.
セクション6.4および6.3.8で定義されているルールに基づいて、E-Wリンクが存在すると、Riftはすべての北行きリンクを失ったノードの1ホップ保護を提供できます。これは、リンクがトポロジー情報の洪水にのみ使用される場合、TOFで複雑なリンクセット障害が発生するマルチプレーン設計にも適用できます。付録B.4は、この動作の概要を示しています。
An inherent property of any security and ZTP architecture is the resulting trade-off in regard to integrity verification of the information distributed through the fabric vs. provisioning and autoconfiguration requirements. At a minimum, the security of an established adjacency should be ensured. The stricter the security model, the more provisioning must take over the role of ZTP.
セキュリティおよびZTPアーキテクチャの固有のプロパティは、生地とプロビジョニングおよびオートコンフィギュレーション要件を介して分配された情報の整合性の検証に関する結果として得られるトレードオフです。少なくとも、確立された隣接のセキュリティを確保する必要があります。セキュリティモデルが厳しいほど、より多くのプロビジョニングがZTPの役割を引き継ぐ必要があります。
RIFT supports the following security models to allow for flexible control by the operator:
Riftは、次のセキュリティモデルをサポートして、オペレーターによる柔軟な制御を可能にします。
* The most security-conscious operators may choose to have control over which ports interconnect between a given pair of nodes, such a model is called the "Port-Association Model" (PAM). This is achievable by configuring each pair of directly connected ports with a designated shared key or public/private key pair.
* 最もセキュリティに対応するオペレーターは、特定のノードのペア間の相互接続を制御することを選択する場合があります。そのようなモデルは、「ポートアソシエーションモデル」（PAM）と呼ばれます。これは、指定された共有キーまたはパブリック/秘密キーペアで直接接続された各ペアを構成することで達成可能です。
* In physically secure data center locations, operators may choose to control connectivity between entire nodes, called here the "Node-Association Model" (NAM). A benefit of this model is that it allows for simplified port sparing.
* 物理的に安全なデータセンターの場所では、オペレーターはここで「ノードアソシエーションモデル」（NAM）と呼ばれるノード全体の接続性を制御することを選択できます。このモデルの利点は、単純化されたポートスパーリングを可能にすることです。
* In the most relaxed environments, an operator may only choose to control which nodes join a particular fabric. This is denoted as the "Fabric-Association Model" (FAM). This is achievable by using a single shared secret across the entire fabric. Such flexibility makes sense when servers are considered as leaf devices, as those are replaced more often than network nodes. In addition, this model allows for simplified node sparing.
* 最もリラックスした環境では、オペレーターは特定のファブリックを結合するノードのみを制御することのみを選択できます。これは、「ファブリックアソシエーションモデル」（FAM）として示されます。これは、ファブリック全体で単一の共有秘密を使用することで達成できます。このような柔軟性は、ネットワークノードよりも頻繁に交換されるため、サーバーがリーフデバイスと見なされる場合に理にかなっています。さらに、このモデルにより、単純化されたノードスパーリングが可能になります。
* These models may be mixed throughout the fabric depending upon security requirements at various levels of the fabric and willingness to accept increased provisioning complexity.
* これらのモデルは、ファブリックのさまざまなレベルでのセキュリティ要件と、プロビジョニングの複雑さの増加を受け入れる意欲に応じて、ファブリック全体に混合される場合があります。
In order to support the cases mentioned above, RIFT implementations supports, through operator control, mechanisms that allow for:
上記のケースをサポートするために、Rift実装は、オペレーターの制御を通じて、次のことを可能にするメカニズムをサポートしています。
* a specification of the appropriate level in the fabric,
* 生地内の適切なレベルの仕様、
* discovery and reporting of missing connections, and
* 欠落している接続の発見と報告、および
* discovery and reporting of unexpected connections while preventing them from forming insecure adjacencies.
* 予期しない接続の発見と報告は、それらが不安定な隣接を形成するのを防ぎながら。
Operators may only choose to configure the level of each node but not explicitly configure which connections are allowed. In this case, RIFT will only allow adjacencies to establish between nodes that are in adjacent levels. Operators with the lowest security requirements may not use any configuration to specify which connections are allowed. Nodes in such fabrics could rely fully on ZTP and established adjacencies between nodes in adjacent levels. Figure 33 illustrates inherent trade-offs between the different security models.
オペレーターは、各ノードのレベルを構成することのみを選択できますが、許可されている接続を明示的に構成することはできません。この場合、Riftは隣接レベルのノード間で隣接することのみを確立できます。セキュリティ要件が最も低いオペレーターは、構成を使用して許可されている接続を指定することはできません。このようなファブリックのノードは、ZTPに完全に依存し、隣接するレベルのノード間の隣接を確立することができます。図33は、さまざまなセキュリティモデル間の固有のトレードオフを示しています。
Some level of link quality verification may be required prior to an adjacency being used for forwarding. For example, an implementation may require that a BFD session comes up before advertising the adjacency.
隣接が転送に使用される前に、ある程度のリンク品質検証が必要になる場合があります。たとえば、実装では、隣接を宣伝する前にBFDセッションが登場する必要があります。
For the cases outlined above, RIFT has two approaches to enforce that a local port is connected to the correct port on the correct remote node. One approach is to piggyback on RIFT's authentication mechanism. Assuming the provisioning model (e.g., YANG) is flexible enough, operators can choose to provision a unique authentication key for the following conceptual models:
上記のケースでは、Riftには、ローカルポートが正しいリモートノードの正しいポートに接続されていることを強制する2つのアプローチがあります。1つのアプローチは、Riftの認証メカニズムにピギーバックすることです。プロビジョニングモデル（Yangなど）が十分に柔軟であると仮定すると、オペレーターは次の概念モデルに一意の認証キーをプロビジョニングすることを選択できます。
* each pair of ports in "port-association model",
* 「ポートアソシエーションモデル」のポートの各ペア、
* each pair of switches in "node-association model", or
* 「ノードアソシエーションモデル」のスイッチの各ペア、または
* the entire fabric in "fabric-association model".
* 「ファブリックアソシエーションモデル」のファブリック全体。
The other approach is to rely on the System ID, port-id, and level fields in the LIE message to validate an adjacency against the expected cabling topology and optionally introduce some new rules in the FSM to allow the adjacency to come up if the expectations are met.
もう1つのアプローチは、LieメッセージのシステムID、ポートID、およびレベルフィールドに依存して、予想されるケーブルトポロジーに対する隣接性を検証し、オプションでFSMにいくつかの新しいルールを導入して、期待が満たされた場合に隣接することができるようにすることです。
^ /\ |
/|\ / \ |
| / \ |
| / PAM \ |
Increasing / \ Increasing
Integrity +----------+ Flexibility
& / NAM \ &
Increasing +--------------+ Less
Provisioning / FAM \ Configuration
| / \ |
| +--------------------+ \|/
| / Zero Configuration \ v
+------------------------+
Figure 33: Security Model
図33：セキュリティモデル
RIFT security goals are to ensure:
リフトセキュリティの目標は、次のことを確実にすることです。
* authentication,
* 認証、
* message integrity,
* メッセージの整合性、
* the prevention of replay attacks,
* リプレイ攻撃の防止、
* low processing overhead, and
* 低い処理オーバーヘッド、および
* efficient messaging
* 効率的なメッセージング
unless no security is deployed by means of using 'undefined_securitykey_id' as key identifiers (key ID).
「undefined_securitykey_id」をキー識別子（キーID）として使用してセキュリティが展開されない限り。
Message confidentiality is a non-goal.
メッセージの機密性はノンゴールです。
The model in the previous section allows a range of security key types that are analogous to the various security association models. PAM and NAM allow security associations at the port or node level using symmetric or asymmetric keys that are preinstalled. FAM argues for security associations to be applied only at a group level or to be refined once the topology has been established. RIFT does not specify how security keys are installed or updated, though it does specify how the key can be used to achieve security goals.
前のセクションのモデルでは、さまざまなセキュリティアソシエーションモデルに類似したさまざまなセキュリティキータイプを許可します。PAMとNAMは、プリインストールされた対称キーまたは非対称キーを使用して、ポートまたはノードレベルでセキュリティ関連を許可します。FAMは、セキュリティ協会がグループレベルでのみ適用されるか、トポロジが確立されたら洗練されることを主張しています。Riftは、セキュリティキーのインストール方法または更新方法を指定しませんが、セキュリティ目標を達成するためにキーを使用する方法を指定します。
The protocol has provisions for "weak" nonces to prevent replay attacks and includes authentication mechanisms comparable to those described in [RFC5709] and [RFC7987].
このプロトコルには、リプレイ攻撃を防ぐための「弱い」ノンセスの規定があり、[RFC5709]および[RFC7987]に記載されている認証メカニズムに匹敵する認証メカニズムが含まれています。
A serialized schema _ProtocolPacket_ MUST be carried in a secure envelope as illustrated in Figure 34. The _ProtocolPacket_ MUST be serialized using the default Thrift's binary protocol. Any value in the packet following a security fingerprint MUST be used by a receiver only after the fingerprint generated based on an acceptable, advertised key ID has been validated against the data covered by the bare exceptions arising from operational exigencies. Based on local configuration, a node MAY allow for the envelope's integrity checks to be skipped and for the procedure specified in Section 6.9.6 to be implemented. This means that for all packets, in case the node is configured to validate the outer fingerprint based on a key ID, an unexpected key ID or fingerprint not validating against the expected key ID will lead to packet rejection. Further, in case of reception of a TIE and the receiver being configured to validate the originator by checking the TIE Origin Security Envelope Header fingerprint against a key ID, an incorrect key ID or inner fingerprint not validating against the key ID will lead to the rejection of the packet.
シリアル化されたスキーマ_protocolpacket_は、図34に示すように、安全なエンベロープで携帯する必要があります。セキュリティ指紋後のパケットの値は、受け入れ可能で広告されたキーIDに基づいて生成された指紋が、運用上の緊急性から生じる裸の例外でカバーされているデータに対して検証された後にのみ、受信機によって使用される必要があります。ローカル構成に基づいて、ノードはエンベロープの整合性チェックをスキップし、セクション6.9.6で指定された手順を実装することを可能にする場合があります。これは、すべてのパケットで、ノードがキーIDに基づいて外側の指紋を検証するように構成された場合、予想されるキーIDまたは指紋が予想されるキーIDに対して検証しないことがパケットの拒否につながることを意味します。さらに、TIE Origin Security Envelope Header FingerprintをキーIDに対してチェックすることにより、ネクタイと受信機がオリジネーターを検証するように構成されている場合、キーIDに対して検証しない誤ったキーIDまたは内側の指紋がパケットの拒否につながります。
For reasons of clarity, it is important to observe that the specification uses the words "fingerprint" and "signature" interchangeably since the specific properties of the fingerprint part of the envelope depend on the algorithms used to insure the payload integrity. Moreover, any security chosen never implies encryption due to performance impact involved but only fingerprint or signature generation and validation.
明確にするために、エンベロープの指紋部分の特定のプロパティがペイロードの整合性を保証するために使用されるアルゴリズムに依存するため、仕様は「指紋」と「署名」という単語を互換性があることを観察することが重要です。さらに、選択されたセキュリティは、パフォーマンスの影響が関与するため、暗号化を暗示することはありませんが、指紋または署名の生成と検証のみのみを意味します。
An implementation MUST implement at least both sending and receiving HMAC-SHA256 fingerprints as defined in Section 10.2 to ensure interoperability but MAY use 'undefined_securitykey_id' by default.
実装では、少なくとも相互運用性を確保するためにセクション10.2で定義されているように、少なくともHMAC-SHA256フィンガープリントの送信と受信の両方を実装する必要がありますが、デフォルトでは「undefined_securitykey_id」を使用する場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | RIFT destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Security Envelope Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIFT MAGIC | Packet Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | RIFT Major | Outer Key ID | Fingerprint |
| | Version | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Fingerprint covers all following content ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weak Nonce Local | Weak Nonce Remote |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remaining TIE Lifetime (all 1s in case of LIE) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TIE Origin Security Envelope Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TIE Origin Key ID | Fingerprint |
| | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Fingerprint covers all following content ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serialized RIFT Model Object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Serialized RIFT Model Object ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Security Envelope
図34：セキュリティエンベロープ
RIFT MAGIC:
Rift Magic：
16 bits
16ビット
Constant value of 0xA1F7 that allows easy classification of RIFT packets independent of the UDP port used.
使用されているUDPポートとは無関係に、Riftパケットの簡単な分類を可能にする0xA1F7の一定の値。
Packet Number:
パケット番号：
16 bits
16ビット
An optional, per-adjacency, per-packet type number set using the sequence number arithmetic defined in Appendix A. If the arithmetic in Appendix A is not used, the node MUST set the value to _undefined_packet_number_. This number can be used to detect losses and misordering in flooding for either operational purposes or in implementation to adjust flooding behavior to current link or buffer quality. This number MUST NOT be used to discard or validate the correctness of packets. Packet numbers are incremented on each interface and within that for each type of packet independently. This allows parallelizing packet generation and processing for different types within an implementation, if so desired.
付録Aで定義されているシーケンス番号算術を使用して、オプションのパケットごとのタイプ番号を設定します。付録Aの算術を使用しない場合、ノードは_undefined_packet_number_に値を設定する必要があります。この数値は、運用目的または実装で洪水で損失と誤った秩序を検出して、洪水行動を現在のリンクまたはバッファーの品質に調整するために使用できます。この数値は、パケットの正確性を破棄または検証するために使用してはなりません。パケット番号は、各インターフェイスで、および各タイプのパケットの個別のインターフェイス内でインクリメントされます。これにより、必要に応じて実装内のさまざまなタイプのパケット生成と処理を並列化できます。
RIFT Major Version:
RIFTメジャーバージョン：
8 bits
8ビット
This value MUST be set to "protocol_major_version", which is defined in the schema and used to serialize the object contained. It allows checking whether protocol versions are compatible on both sides, i.e., which schema version is necessary to decode the serialized object. An implementation MUST drop packets with unexpected values and MAY report a problem. The specification of how an implementation may negotiate the schema's major version is outside the scope of this document.
この値は、スキーマで定義され、含まれるオブジェクトのシリアル化に使用される「protocol_major_version」に設定する必要があります。プロトコルバージョンが両側に互換性があるかどうかを確認できます。つまり、シリアル化されたオブジェクトをデコードするために必要なスキーマバージョンが必要です。実装は、予期しない値でパケットをドロップする必要があり、問題を報告する場合があります。実装がスキーマのメジャーバージョンをネゴシエートする方法の仕様は、このドキュメントの範囲外です。
Outer Key ID:
外側のキーID：
8 bits
8ビット
A simple, unstructured value acting as indirection into a structure holding an algorithm and any related secrets necessary to validate any provided outer security fingerprint or signature. The value _undefined_securitykey_id_ means that no valid fingerprint was computed or is provided; otherwise, one of the algorithms in Section 10.2 MUST be used to compute the fingerprint. This key ID scope is local to the nodes on both ends of the adjacency.
アルゴリズムを保持する構造と、提供された外部のセキュリティ指紋または署名を検証するために必要な関連秘密を保持する構造への間接として機能する単純で非構造化された値。値_undefined_securitykey_id_は、有効な指紋が計算されていないか、提供されていないことを意味します。それ以外の場合、セクション10.2のアルゴリズムの1つを使用して、指紋を計算する必要があります。このキーIDスコープは、隣接の両端のノードにローカルです。
TIE Origin Key ID:
Tie OriginキーID：
24 bits
24ビット
A simple, unstructured value acting as indirection into a structure holding an algorithm and any related secrets necessary to validate any provided inner security fingerprint or signature. The value _undefined_securitykey_id_ means that no valid fingerprint was computed; otherwise, one of the algorithms in Section 10.2 MUST be used to compute the fingerprint. This key ID scope is global to the RIFT instance since it may imply the originator of the TIE so the contained object does not have to be deserialized to obtain the originator.
アルゴリズムを保持する構造と、提供された内部セキュリティ指紋または署名を検証するために必要な関連秘密を保持する構造への間接として機能する単純で非構造化された値。値_undefined_securitykey_id_は、有効な指紋が計算されなかったことを意味します。それ以外の場合、セクション10.2のアルゴリズムの1つを使用して、指紋を計算する必要があります。このキーIDスコープは、ネクタイの発信元を暗示する可能性があるため、リフトインスタンスにとってグローバルであるため、含まれるオブジェクトを作成者を取得するために脱必要な必要はありません。
Fingerprint Length:
指紋の長さ：
8 bits
8ビット
Length in 32-bit multiples of the following fingerprint (not including lifetime or weak nonces). It allows the structure to be navigated when an unknown key type is present. To clarify, a common corner case when this value is set to 0 is when it signifies an empty (0 bytes long) security fingerprint.
次の指紋の32ビットの倍数の長さ（生涯または弱いノンースを含まない）。未知のキータイプが存在する場合、構造をナビゲートできます。明確にするために、この値が0に設定されている場合の一般的なコーナーケースは、空の（長さ0バイト）セキュリティ指紋を意味する場合です。
Security Fingerprint:
セキュリティ指紋：
32 bits * Fingerprint Length
32ビット *指紋の長さ
This is a signature that is computed over all data following after it. If the significant bits of the fingerprint are fewer than the 32-bit padded length, then the significant bits MUST be left aligned and the remaining bits on the right are padded with 0s. When using Public Key Infrastructure (PKI), the security fingerprint originating node uses its private key to create the signature. The original packet can then be verified, provided the public key is shared and current. Methodology to negotiate, distribute, or rollover keys is outside the scope of this document.
これは、その後のすべてのデータにわたって計算される署名です。指紋のかなりの部分が32ビットのパッド入り長さよりも少ない場合、有意なビットを整列させ、右側の残りのビットは0Sでパッドでパッドにされている必要があります。公開キーインフラストラクチャ（PKI）を使用する場合、セキュリティフィンガープリント発信ノードは秘密キーを使用して署名を作成します。その後、公開キーが共有されている場合、元のパケットを検証できます。交渉、配布、またはロールオーバーキーを交渉、配布、またはロールオーバーする方法は、このドキュメントの範囲外です。
Remaining TIE Lifetime:
残りのタイの寿命：
32 bits
32ビット
In case of anything but TIEs, this field MUST be set to all ones and the Origin Security Envelope Header MUST NOT be present in the packet. For TIEs, this field represents the remaining lifetime of the TIE and the Origin Security Envelope Header MUST be present in the packet.
ネクタイ以外の場合、このフィールドはすべてのフィールドに設定する必要があり、Origin Security Envelopeヘッダーがパケットに存在しないでください。ネクタイの場合、このフィールドはネクタイの残りの寿命を表し、Origin Security Envelopeヘッダーがパケットに存在する必要があります。
Weak Nonce Local:
弱いローカル：
16 bits
16ビット
Local Weak Nonce of the adjacency, as advertised in LIEs.
嘘で宣伝されているように、隣接の地元の弱い非CE。
Weak Nonce Remote:
弱いnonceリモート：
16 bits
16ビット
Remote Weak Nonce of the adjacency, as received in LIEs.
嘘で受け取ったように、隣接の遠隔の弱い非CE。
TIE Origin Security Envelope Header:
Tie Origin Security Envelopeヘッダー：
It MUST be present if and only if the Remaining TIE Lifetime field is *not* all ones. It carries through the originator's key ID and corresponding fingerprint of the object to protect TIE from modification during flooding. This ensures origin validation and integrity (but does not provide validation of a chain of trust).
残りのタイの寿命フィールドがすべてのものではない場合にのみ存在する必要があります。発信者のキーIDと対応するオブジェクトの指紋を介して、洪水時の変更からのネクタイを保護します。これにより、起源の検証と完全性が保証されます（ただし、信頼の連鎖の検証は提供されません）。
Observe that, due to the schema migration rules per Section 7, the contained model can always be decoded if the major version matches and the envelope integrity has been validated. Consequently, description of the TIE is available to flood it properly, including unknown TIE types.
セクション7ごとのスキーマ移行規則により、メジャーバージョンが一致し、エンベロープの完全性が検証されている場合、含まれるモデルは常にデコードできることを観察します。その結果、ネクタイの説明は、未知のネクタイプを含めて適切に浸水するために利用できます。
The protocol uses two 16-bit nonces to salt generated signatures. The term "nonce" is used a bit loosely since RIFT nonces are not being changed in every packet, which is common in cryptography. For efficiency purposes, they are changed at a high enough frequency to dwarf practical replay attack attempts. And hence, such nonces are called from this point on "weak" nonces.
このプロトコルは、2つの16ビットの非セースを塩生成署名に使用します。「nonce」という用語は、暗号化で一般的なすべてのパケットでRift Noncesが変更されていないため、少しゆるく使用されます。効率のために、それらは実用的なリプレイ攻撃の試みをwar走するのに十分な頻度で変更されます。したがって、このようなノンセスは、この時点から「弱い」ノンセスで呼び出されます。
Any implementation using a different outer key ID from 'undefined_securitykey_id' MUST generate and wrap around local nonces properly and SHOULD do it even if not using any algorithm from Section 10.2. When a nonce increment leads to the _undefined_nonce_ value, the value MUST be incremented again immediately. All implementations MUST reflect the neighbor's nonces. An implementation SHOULD increment a chosen nonce on every LIE FSM transition that ends up in a different state from the previous one and MUST increment its nonce at least every _nonce_regeneration_interval_ if using any algorithm in Section 10.2 (such considerations allow for efficient implementations without opening a significant security risk). When flooding TIEs, the implementation MUST use recent (i.e., within allowed difference) nonces reflected in the LIE exchange. The schema specifies in _maximum_valid_nonce_delta_ the maximum allowable nonce value difference on a packet compared to reflected nonces in the LIEs. Any packet received with nonces deviating more than the allowed delta MUST be discarded without further computation of signatures to prevent computation load attacks. The delta is either a negative or positive difference that a mirrored nonce can deviate from the local value to be considered valid. If nonces are not changed on every packet, but at the maximum interval on both sides, this opens statistically a _maximum_valid_nonce_delta_/2 window for identical LIEs, TIE, and TI(x)E replays. The interval cannot be too small since LIE FSM may change states fairly quickly during ZTP without sending LIEs, and additionally, UDP can both loose as well as misorder packets.
「undefined_securitykey_id」からの別の外側キーIDを使用した実装は、ローカルノンセスを適切に生成およびラップする必要があり、セクション10.2のアルゴリズムを使用しない場合でも、それを行う必要があります。nonceの増分が_undefined_nonce_値につながる場合、値はすぐに再度増加する必要があります。すべての実装は、隣人のノンセスを反映する必要があります。実装は、以前の状態とは異なる状態に終わるすべてのLie FSM遷移で選択された非CEを増分する必要があり、セクション10.2でアルゴリズムを使用する場合、少なくともすべての_Nonce_Regeneration_interval_を増やす必要があります（このような考慮事項は、重要なセキュリティリスクを開くことなく効率的な実装を可能にします）。洪水の関係の場合、実装では、嘘交換に反映されている最近の（つまり、許容差の範囲内）ノンセスを使用する必要があります。スキーマは、_maximum_valid_nonce_delta_で、嘘の反射されたノンセと比較して、パケットの最大許容性のない非CE値の差を指定します。許可されたデルタよりも多く逸脱しているNoncesで受け取ったパケットは、計算負荷攻撃を防ぐために署名をさらに計算することなく破棄する必要があります。デルタは、ミラー化されたノンセが現地の価値から逸脱して有効と見なされる否定的または正の違いです。すべてのパケットで非セースが変更されないが、両側の最大間隔で、これにより、統計的には、同一の嘘、タイ、およびTi（x）eリプレイの_maximum_valid_nonce_delta_/2ウィンドウが開きます。Lie FSMは、ZTP中に嘘をつくことなくかなり迅速に状態を変更する可能性があるため、間隔は小さすぎることはありません。さらに、UDPは誤ったパケットと同様に緩める可能性があります。
In cases where a secure implementation does not receive signatures or receives undefined nonces from a neighbor (indicating that it does not support or verify signatures), it is a matter of local policy as to how those packets are treated. A secure implementation MAY refuse forming an adjacency with an implementation that is not advertising signatures or valid nonces, or it MAY continue signing local packets while accepting a neighbor's packets without further security validation.
安全な実装が署名を受け取らない、または隣人から未定義のノンセスを受け取らない場合（署名をサポートまたは検証しないことを示しています）、これらのパケットの扱い方に関するローカルポリシーの問題です。安全な実装では、署名や有効なノンセスを広告しない実装で隣接する形成を拒否したり、セキュリティ検証なしで隣人のパケットを受け入れながらローカルパケットに署名し続ける場合があります。
As a necessary exception, an implementation MUST advertise the remote nonce value as _undefined_nonce_ when the FSM is not in _TwoWay_ or _ThreeWay_ state and accept an _undefined_nonce_ for its local nonce value on packets in any other state than _ThreeWay_.
必要な例外として、FSMが_twoway_または_threeway_状態にない場合、実装は_nundefined_nonce_としてリモートNonce値を宣伝する必要があり、_threeway_以外の状態のパケットのローカルNonce値について_undefined_nonce_を受け入れる必要があります。
As an optional optimization, an implementation MAY send one LIE with a previously negotiated neighbor's nonce to try to speed up a neighbor's transition from _ThreeWay_ to _OneWay_ and MUST revert to sending _undefined_nonce_ after that.
オプションの最適化として、実装は、以前に交渉された隣人のNonCEに1つの嘘を送信して、_threeway_から_oneway_への隣人の移行をスピードアップしようとし、その後_undefined_nonce_を送信する必要があります。
Reflooding the same TIE version quickly with small variations in its lifetime may lead to an excessive number of security fingerprint computations. To avoid this, the application generating the fingerprints for flooded TIEs MAY round the value down to the next _rounddown_lifetime_interval_ on the packet header to reuse previous computation results. TIEs flooded with such rounded lifetimes will only limit the amount of computations necessary during transitions that lead to advertisement of the same TIEs with the same information within a short period of time.
同じタイバージョンを迅速に寿命のバリエーションですぐに繰り返して、セキュリティ指紋計算が過剰になる可能性があります。これを回避するために、浸水したタイの指紋を生成するアプリケーションは、値をパケットヘッダーの次の_rounddown_lifetime_interval_まで締めくくることができ、以前の計算結果を再利用できます。このような丸い寿命であふれたネクタイは、短期間以内に同じ情報を持つ同じネクタイの広告につながる移行中に必要な計算量を制限するだけです。
No mechanism is specified to convert a security envelope for the same key ID from one algorithm to another once the envelope is operational. The recommended procedure to change to a new algorithm is to take the adjacency down, make the necessary changes to the secret and algorithm used by the according key ID, and bring the adjacency back up. Obviously, an implementation MAY choose to stop verifying the security envelope for the duration of the algorithm change to keep the adjacency up, but since this introduces a security vulnerability window, such rollover SHOULD NOT be recommended. Other approaches, such as accepting multiple algorithms for same key ID for a configured time window, are possible but in the realm of implementation choices rather than protocol specification.
エンベロープが動作すると、同じキーIDのセキュリティエンベロープをあるアルゴリズムから別のアルゴリズムに変換するメカニズムは指定されていません。新しいアルゴリズムに変更するための推奨手順は、隣接を削除し、キーIDで使用される秘密とアルゴリズムに必要な変更を加え、隣接を取り戻すことです。明らかに、実装は、アルゴリズムの変更の期間中、隣接を維持するためにセキュリティエンベロープの確認を停止することを選択する場合がありますが、これによりセキュリティの脆弱性ウィンドウが導入されるため、そのようなロールオーバーは推奨されるべきではありません。構成されたタイムウィンドウの同じキーIDの複数のアルゴリズムを受け入れるなど、他のアプローチは可能ですが、プロトコル仕様ではなく実装の選択の領域にあります。
This section introduces the schema for information elements. The Interface Description Language (IDL) is Thrift [thrift].
このセクションでは、情報要素のスキーマを紹介します。インターフェイス説明言語（IDL）はThrift [Thrift]です。
On schema changes that
スキーマはそれを変更します
1. change field numbers *or*
1. フィールド番号を変更 *または *
2. add new *required* fields *or*
2. 新しい *必須 *フィールド *または *を追加する
3. remove any fields *or*
3. フィールドを削除 *または *
4. change lists into sets, unions into structures *or*
4. リストをセットに、組合に構造に変更します *または *
5. change multiplicity of fields *or*
5. フィールドの多様性を変更 *または *
6. changes type or name of any field *or*
6. 任意のフィールドのタイプまたは名前を変更 *または *
7. change data types of the type of any field *or*
7. 任意のフィールドのタイプのデータタイプ *または *
8. adds, changes or removes a default value of any *existing* field *or*
8. 既存の *フィールド *または *のデフォルト値を追加、変更、または削除する
9. removes or changes any defined constant or constant value *or*
9. 定義された定数または定数値を削除または変更します *または *
10. changes any enumeration type except extending `common.TIETypeType` (use of enumeration types is generally discouraged) *or*
10. 「common.tietypeType」を拡張することを除いて、列挙タイプを変更します（列挙タイプの使用は一般的に推奨されていません） *または *
11. adds new TIE type to _TIETypeType_ with flooding scope different from prefix TIE flooding scope
11. プレフィックスタイ洪水スコープとは異なる洪水スコープで、_tietypeType_に新しいネクタイタイプを追加します
the major version of the schema MUST increase. All other changes MUST increase the minor version within the same major.
スキーマのメジャーバージョンは増加する必要があります。他のすべての変更は、同じメジャー内のマイナーバージョンを増やす必要があります。
Introducing an optional field does not cause a major version increase even if the fields inside the structure are optional with defaults.
オプションのフィールドを導入しても、構造内のフィールドがデフォルトでオプションであっても、メジャーバージョンの増加は発生しません。
All signed integers, as forced by Thrift [thrift] support, must be cast for internal purposes to equivalent unsigned values without discarding the signedness bit. An implementation SHOULD try to avoid using the signedness bit when generating values.
Thrift [Thrift]サポートによって強制されているように、すべての署名された整数は、署名ビットを破棄することなく、内部目的で同等の署名されていない値に鋳造する必要があります。実装は、値を生成するときに署名ビットを使用しないようにする必要があります。
The schema is normative.
スキーマは規範的です。
The set of rules in Section 7 guarantees that every decoder can process serialized content generated by a higher minor version of the schema, and with that, the protocol can progress without a 'flag-day'. Contrary to that, content serialized using a major version X is *not* expected to be decodable by any implementation using a decoder for a model with a major version lower than X. Schema negotiation and translation within RIFT is outside the scope of this document.
セクション7のルールのセットは、すべてのデコーダーがスキーマのより高いマイナーバージョンによって生成されたシリアル化コンテンツを処理できることを保証し、それにより、プロトコルは「フラグデー」なしで進行できます。それに反して、メジャーバージョンXを使用してシリアル化されたコンテンツは、Xよりも低いメジャーバージョンのデコーダーを使用してデコーダーを使用してデコードできないと予想されません。Rift内のスキーマ交渉と翻訳は、このドキュメントの範囲外です。
Additionally, based on the propagated minor version in encoded content and added optional node capabilities, new TIE types or even de facto mandatory fields can be introduced without progressing the major version, albeit only nodes supporting such new extensions would decode them. Given the model is encoded at the source and never re-encoded, flooding through nodes not understanding any new extensions will preserve the corresponding fields. However, it is important to understand that a higher minor version of a schema does *not* guarantee that capabilities introduced in lower minors of the same major are supported. The _node_capabilities_ field is used to indicate which capabilities are supported.
さらに、エンコードされたコンテンツの伝播されたマイナーバージョンとオプションのノード機能を追加したことに基づいて、新しいネクタイタイプまたは事実上の必須フィールドをメジャーバージョンを進めることなく導入できます。モデルがソースでエンコードされ、再エンコードされていないことを考えると、新しい拡張機能を理解していないノードを介して浸水すると、対応するフィールドが維持されます。ただし、スキーマのより高いマイナーバージョンは、同じ専攻の下位未成年者に導入された機能がサポートされていることを *保証しないことを理解することが重要です。_Node_Capabilities_フィールドは、どの機能がサポートされているかを示すために使用されます。
Specifically, the schema SHOULD add elements to the _NodeCapabilities_ field's future capabilities to indicate whether it will support interpretation of schema extensions on the same major revision if they are present. Such fields MUST be optional and have an implicit or explicit false default value. If a future capability changes route selection or generates conditions that cause packet loss if some nodes are not supporting it, then a major version increment will be unavoidable. _NodeCapabilities_ shown in LIE MUST match the capabilities shown in the Node TIEs; otherwise, the behavior is unspecified. A node detecting the mismatch SHOULD generate a notification.
具体的には、スキーマは_nodeCapabilities_フィールドの将来の機能に要素を追加して、存在する場合と同じ主要な改訂でスキーマ拡張の解釈をサポートするかどうかを示す必要があります。そのようなフィールドはオプションであり、暗黙的または明示的な誤ったデフォルト値を持っている必要があります。将来の機能がルートの選択を変更するか、一部のノードがサポートしていない場合にパケット損失を引き起こす条件を生成する場合、メジャーバージョンの増分は避けられません。_nodecapability _嘘に示されている_ノードタイに示されている機能と一致する必要があります。それ以外の場合、動作は特定されていません。不一致を検出するノードは、通知を生成するはずです。
Alternately or additionally, new optional fields can be introduced into, e.g., _NodeTIEElement_, if a special field is chosen to indicate via its presence that an optional feature is enabled (since capability to support a feature does not necessarily mean that the feature is actually configured and operational).
代替またはさらに、新しいオプションフィールドは、_nodetieElement_などに導入できます。特別なフィールドが選択されている場合は、オプションの機能が有効になっていることをその存在から示すために選択されている場合（機能をサポートする機能は必ずしも設定されていることを意味するわけではありません）。
To support new TIE types without increasing the major version enumeration, _TIEElement_ can be extended with new optional elements for new 'common.TIETypeType' values as long the scope of the new TIE matches the prefix TIE scope. In case it is necessary to understand whether all nodes can parse the new TIE type, a node capability MUST be added in _NodeCapabilities_ to prevent a non-homogenous network.
メジャーバージョンの列挙を増やすことなく新しいネクタイプをサポートするために、_tieelement_は、新しいタイの範囲が接頭辞タイの範囲と一致する長い間、新しい「common.tietypeType」値の新しいオプション要素で拡張できます。すべてのノードが新しいタイ型を解析できるかどうかを理解する必要がある場合は、非同種ネットワークを防ぐために_nodeCapability_にノード機能を追加する必要があります。
This schema references [RFC5837], [RFC5880], and [RFC6550].
このスキーマは[RFC5837]、[RFC5880]、および[RFC6550]を参照しています。
/**
Thrift file with common definitions for RIFT
*/
namespace py common
/** @note MUST be interpreted in implementation as unsigned 64 bits.
*/
typedef i64 SystemIDType
typedef i32 IPv4Address
typedef i32 MTUSizeType
/** @note MUST be interpreted in implementation as unsigned
rolling over number */
typedef i64 SeqNrType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32 LifeTimeInSecType
/** @note MUST be interpreted in implementation as unsigned */
typedef i8 LevelType
typedef i16 PacketNumberType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32 PodType
/** @note MUST be interpreted in implementation as unsigned.
/** this has to be long enough to accommodate prefix */
typedef binary IPv6Address
/** @note MUST be interpreted in implementation as unsigned */
typedef i16 UDPPortType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32 TIENrType
/** @note MUST be interpreted in implementation as unsigned
This is carried in the security envelope and must
hence fit into 8 bits. */
typedef i8 VersionType
/** @note MUST be interpreted in implementation as unsigned */
typedef i16 MinorVersionType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32 MetricType
/** @note MUST be interpreted in implementation as unsigned
and unstructured */
typedef i64 RouteTagType
/** @note MUST be interpreted in implementation as unstructured
label value */
typedef i32 LabelType
/** @note MUST be interpreted in implementation as unsigned */
typedef i32 BandwidthInMegaBitsType
/** @note Key Value key ID type */
typedef i32 KeyIDType
/** node local, unique identification for a link (interface/tunnel/
* etc., basically anything RIFT runs on). This is kept
* at 32 bits so it aligns with BFD (RFC 5880) discriminator size.
*/
typedef i32 LinkIDType
/** @note MUST be interpreted in implementation as unsigned,
especially since we have the /128 IPv6 case. */
typedef i8 PrefixLenType
/** timestamp in seconds since the epoch */
typedef i64 TimestampInSecsType
/** security nonce.
@note MUST be interpreted in implementation as rolling
over unsigned value */
typedef i16 NonceType
/** LIE FSM holdtime type */
typedef i16 TimeIntervalInSecType
/** Transaction ID type for prefix mobility as specified by RFC 6550,
value MUST be interpreted in implementation as unsigned */
typedef i8 PrefixTransactionIDType
/** Timestamp per IEEE 802.1AS, all values MUST be interpreted in
implementation as unsigned. */
struct IEEE802_1ASTimeStampType {
1: required i64 AS_sec;
2: optional i32 AS_nsec;
}
/** generic counter type */
typedef i64 CounterType
/** Platform Interface Index type, i.e., index of interface on
hardware, can be used, e.g., with RFC 5837 */
typedef i32 PlatformInterfaceIndex
/** Flags indicating node configuration in case of ZTP.
*/
enum HierarchyIndications {
/** forces level to 'leaf_level' and enables
according procedures */
leaf_only = 0,
/** forces level to 'leaf_level' and enables
according procedures */
leaf_only_and_leaf_2_leaf_procedures = 1,
/** forces level to 'top_of_fabric' and enables according
procedures */
top_of_fabric = 2,
}
const PacketNumberType undefined_packet_number = 0
/** used when node is configured as top of fabric in ZTP.*/
const LevelType top_of_fabric_level = 24
/** default bandwidth on a link */
const BandwidthInMegaBitsType default_bandwidth = 100
/** fixed leaf level when ZTP is not used */
const LevelType leaf_level = 0
const LevelType default_level = leaf_level
const PodType default_pod = 0
const LinkIDType undefined_linkid = 0
/** invalid key for key value */
const KeyIDType invalid_key_value_key = 0
/** default distance used */
const MetricType default_distance = 1
/** any distance larger than this will be considered infinity */
const MetricType infinite_distance = 0x7FFFFFFF
/** represents invalid distance */
const MetricType invalid_distance = 0
const bool overload_default = false
const bool flood_reduction_default = true
/** default LIE FSM LIE TX interval time */
const TimeIntervalInSecType default_lie_tx_interval = 1
/** default LIE FSM holddown time */
const TimeIntervalInSecType default_lie_holdtime = 3
/** multiplier for default_lie_holdtime to
holddown multiple neighbors */
const i8 multiple_neighbors_lie_holdtime_multiplier = 4
/** default ZTP FSM holddown time */
const TimeIntervalInSecType default_ztp_holdtime = 1
/** by default LIE levels are ZTP offers */
const bool default_not_a_ztp_offer = false
/** by default everyone is repeating flooding */
const bool default_you_are_flood_repeater = true
/** 0 is illegal for System IDs */
const SystemIDType IllegalSystemID = 0
/** empty set of nodes */
const set<SystemIDType> empty_set_of_nodeids = {}
/** default lifetime of TIE is one week */
const LifeTimeInSecType default_lifetime = 604800
/** default lifetime when TIEs are purged is 5 minutes */
const LifeTimeInSecType purge_lifetime = 300
/** optional round down interval when
* TIEs are sent with security signatures
* to prevent excessive computation.
*/
const LifeTimeInSecType rounddown_lifetime_interval = 60
/** any 'TieHeader' that has a smaller lifetime difference
than this constant is equal (if other fields equal). */
const LifeTimeInSecType lifetime_diff2ignore = 400
/** default UDP port to run LIEs on */
const UDPPortType default_lie_udp_port = 914
/** default UDP port to receive TIEs on,
which can be peer specific */
const UDPPortType default_tie_udp_flood_port = 915
/** default MTU link size to use */
const MTUSizeType default_mtu_size = 1400
/** default link being BFD capable */
const bool bfd_default = true
/** type used to target nodes with key value */
typedef i64 KeyValueTargetType
/** default target for key value are all nodes. */
const KeyValueTargetType keyvaluetarget_default = 0
/** value for _all leaves_ addressing.
Represented by all bits set. */
const KeyValueTargetType keyvaluetarget_all_south_leaves = -1
/** undefined nonce, equivalent to missing nonce */
const NonceType undefined_nonce = 0;
/** outer security key ID, MUST be interpreted as in implementation
as unsigned */
typedef i8 OuterSecurityKeyID
/** security key ID, MUST be interpreted as in implementation
as unsigned */
typedef i32 TIESecurityKeyID
/** undefined key */
const TIESecurityKeyID undefined_securitykey_id = 0;
/** Maximum delta (negative or positive) that a mirrored nonce can
deviate from local value to be considered valid. */
const i16 maximum_valid_nonce_delta = 5;
const TimeIntervalInSecType nonce_regeneration_interval = 300;
/** Direction of TIEs. */
enum TieDirectionType {
Illegal = 0,
South = 1,
North = 2,
DirectionMaxValue = 3,
}
/** Address family type. */
enum AddressFamilyType {
Illegal = 0,
AddressFamilyMinValue = 1,
IPv4 = 2,
IPv6 = 3,
AddressFamilyMaxValue = 4,
}
/** IPv4 prefix type. */
struct IPv4PrefixType {
1: required IPv4Address address;
2: required PrefixLenType prefixlen;
}
/** IPv6 prefix type. */
struct IPv6PrefixType {
1: required IPv6Address address;
2: required PrefixLenType prefixlen;
}
/** IP address type. */
union IPAddressType {
/** Content is IPv4 */
1: optional IPv4Address ipv4address;
/** Content is IPv6 */
2: optional IPv6Address ipv6address;
}
/** Prefix advertisement.
@note: For interface
addresses, the protocol can propagate the address part beyond
the subnet mask and on reachability computation that has to
be normalized. The non-significant bits can be used
for operational purposes.
*/
union IPPrefixType {
1: optional IPv4PrefixType ipv4prefix;
2: optional IPv6PrefixType ipv6prefix;
}
/** Sequence of a prefix in case of move.
*/
struct PrefixSequenceType {
1: required IEEE802_1ASTimeStampType timestamp;
/** Transaction ID set by the client in, e.g., 6LoWPAN. */
2: optional PrefixTransactionIDType transactionid;
}
/** Type of TIE.
*/
enum TIETypeType {
Illegal = 0,
TIETypeMinValue = 1,
/** first legal value */
NodeTIEType = 2,
PrefixTIEType = 3,
PositiveDisaggregationPrefixTIEType = 4,
NegativeDisaggregationPrefixTIEType = 5,
PGPrefixTIEType = 6,
KeyValueTIEType = 7,
ExternalPrefixTIEType = 8,
PositiveExternalDisaggregationPrefixTIEType = 9,
TIETypeMaxValue = 10,
}
/** RIFT route types.
@note: The only purpose of those values is to introduce an
ordering, whereas an implementation can internally choose
any other values as long the ordering is preserved.
*/
enum RouteType {
Illegal = 0,
RouteTypeMinValue = 1,
/** First legal value. */
/** Discard routes are most preferred */
Discard = 2,
/** Local prefixes are directly attached prefixes on the
* system, such as interface routes.
*/
LocalPrefix = 3,
/** Advertised in S-TIEs */
SouthPGPPrefix = 4,
/** Advertised in N-TIEs */
NorthPGPPrefix = 5,
/** Advertised in N-TIEs */
NorthPrefix = 6,
/** Externally imported north */
NorthExternalPrefix = 7,
/** Advertised in S-TIEs, either normal prefix or positive
disaggregation */
SouthPrefix = 8,
/** Externally imported south */
SouthExternalPrefix = 9,
/** Negative, transitive prefixes are least preferred */
NegativeSouthPrefix = 10,
RouteTypeMaxValue = 11,
}
enum KVTypes {
Experimental = 1,
WellKnown = 2,
OUI = 3,
}
/**
Thrift file for packet encodings for RIFT
*/
include "common.thrift"
namespace py encoding
/** Represents protocol encoding schema major version */
const common.VersionType protocol_major_version = 8
/** Represents protocol encoding schema minor version */
const common.MinorVersionType protocol_minor_version = 0
/** Common RIFT packet header. */
struct PacketHeader {
/** Major version of protocol. */
1: required common.VersionType major_version =
protocol_major_version;
/** Minor version of protocol. */
2: required common.MinorVersionType minor_version =
protocol_minor_version;
/** Node sending the packet, in case of LIE/TIRE/TIDE
also the originator of it. */
3: required common.SystemIDType sender;
/** Level of the node sending the packet, required on everything
except LIEs. Lack of presence on LIEs indicates
UNDEFINED_LEVEL and is used in ZTP procedures.
*/
4: optional common.LevelType level;
}
/** Prefix community. */
struct Community {
/** Higher order bits */
1: required i32 top;
/** Lower order bits */
2: required i32 bottom;
}
/** Neighbor structure. */
struct Neighbor {
/** System ID of the originator. */
1: required common.SystemIDType originator;
/** ID of remote side of the link. */
2: required common.LinkIDType remote_id;
}
/** Capabilities the node supports. */
struct NodeCapabilities {
/** Must advertise supported minor version dialect that way. */
1: required common.MinorVersionType protocol_minor_version =
protocol_minor_version;
/** indicates that node supports flood reduction. */
2: optional bool flood_reduction =
common.flood_reduction_default;
/** indicates place in hierarchy, i.e., top of fabric or
leaf only (in ZTP) or support for L2L
procedures. */
3: optional common.HierarchyIndications hierarchy_indications;
}
/** Link capabilities. */
struct LinkCapabilities {
/** Indicates that the link is supporting BFD. */
1: optional bool bfd =
common.bfd_default;
/** Indicates whether the interface will support IPv4
forwarding. */
2: optional bool ipv4_forwarding_capable =
true;
}
/** RIFT LIE Packet.
@note: This node's level is already included on the packet header.
*/
struct LIEPacket {
/** Node or adjacency name. */
1: optional string name;
/** Local link ID. */
2: required common.LinkIDType local_id;
/** UDP port to which we can receive flooded TIEs. */
3: required common.UDPPortType flood_port =
common.default_tie_udp_flood_port;
/** Layer 2 MTU, used to discover mismatch. */
4: optional common.MTUSizeType link_mtu_size =
common.default_mtu_size;
/** Local link bandwidth on the interface. */
5: optional common.BandwidthInMegaBitsType
link_bandwidth = common.default_bandwidth;
/** Reflects the neighbor once received to provide
3-way connectivity. */
6: optional Neighbor neighbor;
/** Node's PoD. */
7: optional common.PodType pod =
common.default_pod;
/** Node capabilities supported. */
10: required NodeCapabilities node_capabilities;
/** Capabilities of this link. */
11: optional LinkCapabilities link_capabilities;
/** Required holdtime of the adjacency, i.e., for how long a
period adjacency should be kept up without valid LIE
reception. */
12: required common.TimeIntervalInSecType
holdtime = common.default_lie_holdtime;
/** Optional, unsolicited, downstream assigned locally significant
label value for the adjacency. */
13: optional common.LabelType label;
/** Indicates that the level on the LIE must not be used
to derive a ZTP level by the receiving node. */
21: optional bool not_a_ztp_offer =
common.default_not_a_ztp_offer;
/** Indicates to northbound neighbor that it should
be reflooding TIEs received from this node to achieve flood
reduction and balancing for northbound flooding. */
22: optional bool you_are_flood_repeater =
common.default_you_are_flood_repeater;
/** Indicates to neighbor to flood node TIEs only and slow down
all other TIEs. Ignored when received from southbound
neighbor. */
23: optional bool you_are_sending_too_quickly =
false;
/** Instance name in case multiple RIFT instances running on same
interface. */
24: optional string instance_name;
/** It provides the optional ID of the fabric configured. This
MUST match the information advertised on the node element. */
35: optional common.FabricIDType fabric_id =
common.default_fabric_id;
}
/** LinkID pair describes one of parallel links between two nodes. */
struct LinkIDPair {
/** Node-wide unique value for the local link. */
1: required common.LinkIDType local_id;
/** Received remote link ID for this link. */
2: required common.LinkIDType remote_id;
/** Describes the local interface index of the link. */
10: optional common.PlatformInterfaceIndex
platform_interface_index;
/** Describes the local interface name. */
11: optional string platform_interface_name;
/** Indicates whether the link is secured, i.e., protected by
outer key, absence of this element means no indication,
undefined outer key means not secured. */
12: optional common.OuterSecurityKeyID
trusted_outer_security_key;
/** Indicates whether the link is protected by established
BFD session. */
13: optional bool bfd_up;
/** Optional indication which address families are up on the
interface */
14: optional set<common.AddressFamilyType>
address_families;
}
/** Unique ID of a TIE. */
struct TIEID {
/** direction of TIE */
1: required common.TieDirectionType direction;
/** indicates originator of the TIE */
2: required common.SystemIDType originator;
/** type of the tie */
3: required common.TIETypeType tietype;
/** number of the tie */
4: required common.TIENrType tie_nr;
}
/** Header of a TIE. */
struct TIEHeader {
/** ID of the tie. */
2: required TIEID tieid;
/** Sequence number of the tie. */
3: required common.SeqNrType seq_nr;
/** Absolute timestamp when the TIE was generated. */
10: optional common.IEEE802_1ASTimeStampType origination_time;
/** Original lifetime when the TIE was generated. */
12: optional common.LifeTimeInSecType origination_lifetime;
}
/** Header of a TIE as described in TIRE/TIDE.
*/
struct TIEHeaderWithLifeTime {
1: required TIEHeader header;
/** Remaining lifetime. */
2: required common.LifeTimeInSecType remaining_lifetime;
}
/** TIDE with *sorted* TIE headers. */
struct TIDEPacket {
/** First TIE header in the TIDE packet. */
1: required TIEID start_range;
/** Last TIE header in the TIDE packet. */
2: required TIEID end_range;
/** _Sorted_ list of headers. */
3: required list<TIEHeaderWithLifeTime>
headers;
}
/** TIRE packet */
struct TIREPacket {
1: required set<TIEHeaderWithLifeTime>
headers;
}
/** neighbor of a node */
struct NodeNeighborsTIEElement {
/** level of neighbor */
1: required common.LevelType level;
/** Cost to neighbor. Ignore anything equal/larger than
'infinite_distance' or equal 'invalid_distance' */
3: optional common.MetricType cost
= common.default_distance;
/** can carry description of multiple parallel links in a TIE */
4: optional set<LinkIDPair>
link_ids;
/** total bandwidth to neighbor as sum of all parallel links */
5: optional common.BandwidthInMegaBitsType
bandwidth = common.default_bandwidth;
}
/** Indication flags of the node. */
struct NodeFlags {
/** Indicates that node is in overload, do not transit traffic
through it. */
1: optional bool overload = common.overload_default;
}
/** Description of a node. */
struct NodeTIEElement {
/** Level of the node. */
1: required common.LevelType level;
/** Node's neighbors. Multiple node TIEs can carry disjoint sets
of neighbors. */
2: required map<common.SystemIDType,
NodeNeighborsTIEElement> neighbors;
/** Capabilities of the node. */
3: required NodeCapabilities capabilities;
/** Flags of the node. */
4: optional NodeFlags flags;
/** Optional node name for easier operations. */
5: optional string name;
/** PoD to which the node belongs. */
6: optional common.PodType pod;
/** Optional startup time of the node */
7: optional common.TimestampInSecsType startup_time;
/** If any local links are miscabled, this indication is
flooded. */
10: optional set<common.LinkIDType>
miscabled_links;
/** ToFs in the same plane. Only carried by ToF. Multiple Node
TIEs can carry disjoint sets of ToFs that MUST be joined to
form a single set. */
12: optional set<common.SystemIDType>
same_plane_tofs;
/** It provides the optional ID of the fabric configured */
20: optional common.FabricIDType fabric_id =
common.default_fabric_id;
}
/** Attributes of a prefix. */
struct PrefixAttributes {
/** Distance of the prefix. */
2: required common.MetricType metric
= common.default_distance;
/** Generic unordered set of route tags, can be redistributed
to other protocols or used within the context of real time
analytics. */
3: optional set<common.RouteTagType>
tags;
/** Monotonic clock for mobile addresses. */
4: optional common.PrefixSequenceType monotonic_clock;
/** Indicates if the prefix is a node loopback. */
6: optional bool loopback = false;
/** Indicates that the prefix is directly attached. */
7: optional bool directly_attached = true;
/** Link to which the address belongs to. */
10: optional common.LinkIDType from_link;
/** Optional, per-prefix significant label. */
12: optional common.LabelType label;
}
/** TIE carrying prefixes */
struct PrefixTIEElement {
/** Prefixes with the associated attributes. */
1: required map<common.IPPrefixType, PrefixAttributes> prefixes;
}
/** Defines the targeted nodes and the value carried. */
struct KeyValueTIEElementContent {
1: optional common.KeyValueTargetType targets =
common.keyvaluetarget_default;
2: optional binary value;
}
/** Generic key value pairs. */
struct KeyValueTIEElement {
1: required map<common.KeyIDType, KeyValueTIEElementContent>
keyvalues;
}
/** Single element in a TIE. */
union TIEElement {
/** Used in case of enum common.TIETypeType.NodeTIEType. */
1: optional NodeTIEElement node;
/** Used in case of enum common.TIETypeType.PrefixTIEType. */
2: optional PrefixTIEElement prefixes;
/** Positive prefixes (always southbound). */
3: optional PrefixTIEElement positive_disaggregation_prefixes;
/** Transitive, negative prefixes (always southbound) */
5: optional PrefixTIEElement negative_disaggregation_prefixes;
/** Externally reimported prefixes. */
6: optional PrefixTIEElement external_prefixes;
/** Positive external disaggregated prefixes (always
southbound). */
7: optional PrefixTIEElement
positive_external_disaggregation_prefixes;
/** Key-Value store elements. */
9: optional KeyValueTIEElement keyvalues;
}
/** TIE packet */
struct TIEPacket {
1: required TIEHeader header;
2: required TIEElement element;
}
/** Content of a RIFT packet. */
union PacketContent {
1: optional LIEPacket lie;
2: optional TIDEPacket tide;
3: optional TIREPacket tire;
4: optional TIEPacket tie;
}
/** RIFT packet structure. */
struct ProtocolPacket {
1: required PacketHeader header;
2: required PacketContent content;
}
RIFT can and is intended to be stretched to the lowest level in the IP fabric to integrate ToRs or even servers. Since those entities would run as leaves only, it is worth it to observe that a leaf-only version is significantly simpler to implement and requires much less resources:
Riftは、TORやサーバーを統合するために、IPファブリックの最低レベルに伸ばすことができます。これらのエンティティは葉のみを実行するため、リーフのみのバージョンの実装が大幅に簡単で、リソースがはるかに少ないことを観察することは価値があります。
1. Leaf nodes only need to maintain a multipath default route under normal circumstances. However, in cases of catastrophic partitioning, leaf nodes SHOULD be capable of accommodating all the leaf routes in their own PoD to prevent traffic loss.
1. リーフノードは、通常の状況下でマルチパスデフォルトルートを維持するだけで済む必要があります。ただし、壊滅的な分配の場合、葉のノードは、交通量の損失を防ぐために、独自のポッドのすべての葉のルートに対応できる必要があります。
2. Leaf nodes only hold their own North TIEs and the South TIEs of level 1 nodes they are connected to.
2. リーフノードは、独自の北ネクタイと、接続されているレベル1ノードの南タイのみを保持します。
3. Leaf nodes do not have to support any type of disaggregation computation or propagation.
3. 葉のノードは、いかなるタイプの分解計算や伝播をサポートする必要もありません。
4. Leaf nodes are not required to support the overload flag.
4. 葉のノードは、過負荷フラグをサポートするために必要はありません。
5. Leaf nodes do not need to originate S-TIEs unless optional L2L features are desired.
5. 葉のノードは、オプションのL2L機能が望まない限り、S-TIEを発信する必要はありません。
Nodes that do not act as ToF are not required to discover fallen leaves by comparing reachable destinations with peers and therefore do not need to run the computation of disaggregated routes based on that discovery. On the other hand, non-ToF nodes need to respect disaggregated routes advertised from the north. In the case of negative disaggregation, spines nodes need to generate southbound disaggregated routes when all parents are lost for a fallen leaf.
TOFとして作用しないノードは、到達可能な目的地をピアと比較することで倒れた葉を発見する必要はありません。したがって、その発見に基づいて分解されたルートの計算を実行する必要はありません。一方、非TOFノードは、北から宣伝されている分解ルートを尊重する必要があります。負の分解の場合、すべての親が倒れた葉のために失われた場合、棘ノードは南行きの分解ルートを生成する必要があります。
One can consider attack vectors where a router may reboot many times while changing its System ID and pollute the network with many stale TIEs or TIEs that are sent with very long lifetimes and not cleaned up when the routes vanish. Those attack vectors are not unique to RIFT. Given large memory footprints available today, those attacks should be relatively benign. Otherwise, a node SHOULD implement a strategy of discarding contents of all TIEs that were not present in the SPF tree over a certain, configurable period of time. Since the protocol is self-stabilizing and will advertise the presence of such TIEs to its neighbors, they can be re-requested again if a computation finds that it has an adjacency formed towards the System ID of the discarded TIEs.
システムIDを変更しながらルーターが何度も再起動し、非常に長い寿命で送信され、ルートが消滅したときにクリーンアップされない多くの古いネクタイまたはネットワークでネットワークを汚染する攻撃ベクトルを考慮することができます。これらの攻撃ベクトルは、Riftに固有のものではありません。今日利用可能な大きなメモリフットプリントを考えると、これらの攻撃は比較的良性でなければなりません。それ以外の場合、ノードは、特定の構成可能な期間にわたってSPFツリーに存在しなかったすべてのタイの内容を破棄する戦略を実装する必要があります。プロトコルは自己安定化しており、そのような関係の存在を隣接者に宣伝するため、計算が廃棄されたネクタイのシステムIDに向かって隣接することを発見した場合、それらは再度再起動することができます。
The inner protection configured based on any of the mechanisms in Section 10.2 guarantees the integrity of TIE content, and when combined with the outer part of the envelope, using any of the mechanisms in Section 10.2, guarantees protection against replay attacks as well. If only outer protection (i.e., an outer key ID different from 'undefined_securitykey_id') is applied to an adjacency by the means of any mechanism in Section 10.2, the integrity of the packet and replay protection is guaranteed only over the adjacency involved in any of the configured directions. Further considerations can be found in Sections 9.7 and 9.8.
セクション10.2のメカニズムのいずれかに基づいて構成された内部保護は、タイ含有量の完全性を保証し、セクション10.2のメカニズムを使用して、エンベロープの外側部分と組み合わせると、リプレイ攻撃に対する保護も保証します。セクション10.2のあらゆるメカニズムの手段によって隣接に適用される外部保護（つまり、「未定義」と「undefined_securitykey_id」とは異なる外側のキーID）のみが、パケットとリプレイ保護の完全性は、構成された方向のいずれかに関与する隣接にのみ保証されます。さらに考慮事項は、セクション9.7および9.8に記載されています。
RIFT explicitly requires the use of a TTL/HL value of 1 *or* 255 when sending/receiving LIEs and TIEs so that implementors have a choice between the two.
Riftは、嘘を送信/受信するときに1 *または * 255のTTL/HL値の使用を明示的に必要とし、実装者が2つの間で選択できるようにします。
Using a TTL/HL value of 255 does come with security concerns, but those risks are addressed in [RFC5082]. However, this approach may still have difficulties with some forwarding implementations (e.g., incorrectly processing TTL/HL, loops within the forwarding plane itself, etc.).
255のTTL/HL値を使用するには、セキュリティ上の懸念がありますが、これらのリスクは[RFC5082]で対処されています。ただし、このアプローチには、いくつかの転送の実装（たとえば、TTL/HLの処理、転送面自体内のループなど）でまだ困難がある場合があります。
It is for this reason that RIFT also allows implementations to use a TTL/HL of 1. Attacks that exploit this by spoofing it from several hops away are indeed possible but are exceptionally difficult to engineer. Replay attacks are another potential attack vector, but as described in the subsequent security sections, RIFT is well protected against such attacks if any of the mechanisms in Section 10.2 are applied. Additionally, for link-local scoped multicast addresses used for LIE, the value of 1 presents a more consistent choice.
このため、Riftは、実装が1のTTL/HLを使用することも許可しています。これを悪用する攻撃は、実際に可能ですが、エンジニアリングするのは非常に困難です。リプレイ攻撃は別の潜在的な攻撃ベクトルですが、後続のセキュリティセクションで説明されているように、セクション10.2のメカニズムのいずれかが適用される場合、Riftはそのような攻撃に対して十分に保護されています。さらに、Lieに使用されるLink-Local Scoped Multicastアドレスの場合、1の値はより一貫した選択を示します。
The protocol protects packets extensively through optional signatures and nonces, so if the possibility of maliciously injected malformed or replayed packets exist in a deployment, algorithms in Section 10.2 must be applied.
このプロトコルは、オプションの署名とノンセスを介してパケットを広く保護するため、展開に悪意のある注入不正パケットが存在する可能性がある場合、セクション10.2のアルゴリズムを適用する必要があります。
Even with the security envelope, since RIFT relies on Thrift encoders and decoders generated automatically from IDL, it is conceivable that errors in such encoders/decoders could be discovered and lead to delivery of corrupted packets or reception of packets that cannot be decoded. Misformatted packets normally lead to the decoder returning an error condition to the caller, and with that, the packet is basically unparsable with no other choice but to discard it. Should the unlikely scenario occur of the decoder being forced to abort the protocol, this is neither better nor worse than today's behavior of other protocols.
セキュリティエンベロープを使用しても、RiftはIDLから自動的に生成されるリリフトエンコーダーとデコーダーに依存するため、このようなエンコーダ/デコーダーのエラーを発見し、破損したパケットの配信またはデコードできないパケットの受信につながる可能性があると考えられます。誤ったパケットは通常、デコーダーが発信者にエラー条件を返すことにつながります。これにより、パケットは基本的に比類のないものであり、他の選択肢はありません。デコーダーがプロトコルを中止することを余儀なくされていることのありそうもないシナリオが発生した場合、これは他のプロトコルの今日の動作よりも優れていることも悪いことでもありません。
Section 6.7 presents many attack vectors in untrusted environments, starting with nodes that oscillate their level offers to the possibility of nodes offering a _ThreeWay_ adjacency with the highest possible level value and a very long holdtime trying to put itself "on top of the lattice", thereby allowing it to gain access to the whole southbound topology. Session authentication mechanisms are necessary in environments where this is possible, and RIFT provides the security envelope to ensure this, if so desired, if any mechanism in Section 10.2 is deployed.
セクション6.7は、信頼できない環境で多くの攻撃ベクトルを示します。ノードから始まるレベルのオファーを振動させて、可能な限り最高レベルの値を備えたノードを提供するノードと、「格子の上に」自分自身を置くために非常に長いホールドタイムを提供し、それにより、それによってサウスバウンド全体の全体にアクセスできるようにします。セッション認証メカニズムは、これが可能な環境で必要であり、Riftはセキュリティエンベロープを提供して、セクション10.2のメカニズムが展開されている場合にこれを確実にします。
RIFT removes lifetime modification and replay attack vectors by protecting the lifetime behind a signature computed over it and additional nonce combination, which results in the inability of an attacker to artificially shorten the _remaining_lifetime_. This only applies if any mechanism in Section 10.2 is used.
Riftは、寿命の変更とリプレイ攻撃ベクトルを削除し、その上に計算された署名の背後にある寿命を保護することと、攻撃者が_Remaining_lifetime_を人為的に短縮できないようになります。これは、セクション10.2のメカニズムが使用されている場合にのみ適用されます。
A packet number is an optional defined value number that is carried in the security envelope without any fingerprint protection and is hence vulnerable to replay and modification attacks. Contrary to nonces, this number must change on every packet and would present a very high cryptographic load if signed. The attack vector packet number present is relatively benign. Changing the packet number by a man-in-the-middle attack will only affect operational validation tools and possibly some performance optimizations on flooding. It is expected that an implementation detecting too many "fake losses" or "misorderings" due to the attack on the packet number would simply suppress its further processing.
パケット番号は、指紋保護なしでセキュリティエンベロープに携帯されるオプションの定義値番号であるため、リプレイおよび変更攻撃に対して脆弱です。Noncesに反して、この数値はすべてのパケットで変更されなければならず、署名された場合、非常に高い暗号化負荷を示します。存在する攻撃ベクトルパケット番号は比較的良性です。中間の攻撃によるパケット番号を変更すると、運用上の検証ツールと、洪水に関するパフォーマンスの最適化のみにのみ影響します。パケット番号への攻撃により、「偽の損失」または「誤った命令」をあまりにも多く検出する実装は、単にさらに処理を抑制することが予想されます。
Even when a mechanism in Section 10.2 is enabled to generate outer fingerprints, further attack considerations apply.
セクション10.2のメカニズムが有効になっている場合でも、外側の指紋を生成すると、さらなる攻撃の考慮事項が適用されます。
A node can try to inject LIE packets observing a conversation on the wire by using the observed outer key ID, albeit it cannot generate valid signatures in case it changes the integrity of the message, so the only possible attack is DoS due to excessive LIE validation if any mechanism in Section 10.2 is used.
ノードは、メッセージの整合性を変更した場合に有効な署名を生成することはできませんが、観測された外側キーIDを使用してワイヤー上の会話を観察する嘘パケットを注入しようとすることができます。
A node can try to replay previous LIEs with a changed state that it recorded, but the attack is hard to replicate since the nonce combination must match the ongoing exchange and is then limited to only a single flap since both nodes will advance their nonces in case the adjacency state changed. Even in the most unlikely case, the attack length is limited due to both sides periodically increasing their nonces.
ノードは、記録された状態の変更された状態で以前の嘘をリプレイしようとすることができますが、ノンセの組み合わせは進行中の交換と一致しなければならず、両方のノードが隣接状態が変更された場合に非セースを前進させるため、単一のフラップのみに制限されるため、攻撃を複製するのが困難です。最もありそうもないケースでさえ、攻撃の長さは、両側が定期的に非セースを増加させるために制限されています。
Generally, since weak nonces are not changed on every packet for performance reasons, a conceivable attack vector by a man in the middle is to flood a receiving node with the maximum bandwidth of recently observed packets, both LIEs as well as TIEs. In a scenario where such attacks are likely, _maximum_valid_nonce_delta_ and _nonce_regeneration_interval_ can be implemented as configurable and set to small values. This will likely present a significant computational load on large fabrics under normal operation.
一般的に、パフォーマンスの理由ですべてのパケットで弱い非性能が変更されないため、中央の男性が考えられる攻撃ベクターは、最近観察されたパケットの最大帯域幅で受信ノードに浸水することです。そのような攻撃が可能性が高いシナリオでは、_maximum_valid_nonce_delta_および_nonce_regeneration_interval_は、構成可能として実装し、小さな値に設定できます。これにより、通常の操作中の大きなファブリックに大きな計算負荷が発生する可能性があります。
Even when a mechanism in Section 10.2 is enabled to generate inner fingerprints or signatures, further attack considerations apply.
セクション10.2のメカニズムが有効になっていても、内部の指紋または署名を生成すると、さらなる攻撃の考慮事項が適用されます。
In case the inner fingerprint could be generated by a compromised node in the network other than the originator based on shared secrets, the deployment must fall back on use of signatures that can be validated but not generated by any other node except the originator.
共有された秘密に基づいたオリジネーター以外のネットワーク内の侵害されたノードによって内部指紋が生成される場合、展開は、検証できるが、オリジネーターを除く他のノードによって生成されない署名の使用に頼る必要があります。
A compromised node in the network can attempt to brute force "fake TIEs" using other nodes' TIE origin key ID without possessing the necessary secrets. Albeit the ultimate validation of the origin signature will fail in such scenarios and not progress further than immediately peering nodes, the resulting DoS attack seems unavoidable since the TIE origin key ID is only protected by the (here assumed to be compromised) node.
ネットワーク内の侵害されたノードは、必要な秘密を所有することなく、他のノードのTIE Origin Key IDを使用して「偽のネクタイ」を強制的に強制的に試みることができます。Origin Signatureの最終的な検証は、そのようなシナリオで失敗し、すぐにピアリングノードよりも進行することはありませんが、結果のDOS攻撃は、（ここでは妥協されると想定される）ノードによってのみ保護されているため、避けられないようです。
It can be reasonably expected that the proliferation of RotH servers, rather than dedicated networking devices, will represent a significant amount of RIFT devices. Given their normally far wider software envelope and access granted to them, such servers are also far more likely to be compromised and present an attack vector on the protocol. Hijacking of prefixes to attract traffic is a trust problem and cannot be easily addressed within the protocol if the trust model is breached, i.e., the server presents valid credentials to form an adjacency and issue TIEs. In an even more devious way, the servers can present DoS (or even DDoS) vectors from issuing too many LIE packets, flooding large amounts of North TIEs, and attempting similar resource overrun attacks. A prudent implementation forming adjacencies to leaves should implement threshold mechanisms and raise warnings when, e.g., a leaf is advertising an excess number of TIEs or prefixes. Additionally, such implementation could refuse any topology information except the node's own TIEs and authenticated, reflected South Node TIEs at their own level.
専用のネットワークデバイスではなく、Rothサーバーの増殖がかなりの量のRiftデバイスを表すことが合理的に予想されることができます。通常、はるかに広いソフトウェアエンベロープとアクセスが付与されていることを考えると、そのようなサーバーは侵害され、プロトコルに攻撃ベクトルを提示する可能性がはるかに高くなります。トラフィックを引き付けるためのプレフィックスのハイジャックは信頼の問題であり、信頼モデルが侵害されている場合、プロトコル内で簡単に対処することはできません。つまり、サーバーは有効な資格情報を提示して、隣接関係を形成し、関係を発行します。さらに不正な方法で、サーバーはDOS（またはDDOS）ベクトルをあまりにも多くの嘘パケットを発行し、大量の北ネクタイをあふれさせ、同様のリソースオーバーラン攻撃を試みることから提示できます。葉の隣接を形成する慎重な実装は、しきい値メカニズムを実装し、例えば、葉が過剰な数のネクタイまたは接頭辞を宣伝している場合に警告を提起する必要があります。さらに、このような実装は、ノード自身の関係と認証されたサウスノードのネクタイを除くトポロジ情報を拒否する可能性があります。
To isolate possible attack vectors on the leaf to the largest possible extent, a dedicated leaf-only implementation could run without any configuration by:
可能な限り葉の可能な攻撃ベクトルを可能な限り最大の範囲で分離するために、専用のリーフのみの実装を構成なしで実行できます。
* hard-coding a well-known adjacency key (which can be always rolled over by means of, e.g., a well-known key-value distributed from top of the fabric),
* ハードコーディングよく知られている隣接キー（ファブリックの上部から分散されたよく知られているキー価値など、常にロールオーバーすることができます）
* hard-coding a leaf level value, and
* ハードコーディングリーフレベルの値、および
* always setting the overload flag.
* 常にオーバーロードフラグを設定します。
Section 6.2 describes an optional implementation that supports LIE exchange over IPv4 broadcast addresses and/or the IPv6 all-routers multicast address. It is important to consider that if an implementation supports this, the attack surface widens as LIEs may be propagated to devices outside of the intended RIFT topology. This may leave RIFT nodes more susceptible to the various attack vectors already described in this section.
セクション6.2では、IPv4ブロードキャストアドレスおよび/またはIPv6 All-Routersマルチキャストアドレスを超えるLie Exchangeをサポートするオプションの実装について説明します。実装がこれをサポートする場合、嘘が意図したRIFTトポロジ外のデバイスに伝播するにつれて攻撃面が広がる可能性があることを考慮することが重要です。これにより、このセクションで既に説明されているさまざまな攻撃ベクトルの影響を受けやすくする可能性があります。
As detailed below, multicast addresses and standard port numbers have been assigned. Additionally, registries for the schema have been created with initial values assigned.
以下に詳述するように、マルチキャストアドレスと標準ポート番号が割り当てられています。さらに、スキーマのレジストリは、初期値が割り当てられた状態で作成されています。
In the "IPv4 Multicast Address Space" registry, the value of 224.0.0.121 has been assigned for 'ALL_V4_RIFT_ROUTERS'. In the "IPv6 Multicast Address Space" registry, the value of ff02::a1f7 has been assigned for 'ALL_V6_RIFT_ROUTERS'.
「IPv4マルチキャストアドレススペース」レジストリでは、224.0.0.121の値が「ALL_V4_RIFT_ROUTERS」に割り当てられています。「IPv6マルチキャストアドレススペース」レジストリでは、FF02 :: A1F7の値が「ALL_V6_RIFT_ROUTERS」に割り当てられています。
The following assignments have been made in the "Service Name and Transport Protocol Port Number Registry":
次の割り当ては、「サービス名と輸送プロトコルポート番号レジストリ」で行われています。
_RIFT LIE Port_
_RIFT LIE PORT_
Service Name:
サービス名：
rift-lies
裂け目
Port Number:
ポート番号：
914
914
Transport Protocol:
輸送プロトコル：
udp
UDP
Description:
説明：
Routing in Fat Trees Link Information Element
脂肪木のルーティングは情報要素をリンクします
Assignee:
譲受人：
IESG (iesg@ietf.org)
iesg（iesg@ietf.org）
Contact:
接触：
IETF Chair (chair@ietf.org)
IETF椅子（椅子@ietf.org）
Reference:
参照：
RFC 9692
RFC 9692
_RIFT TIE Port_
_RIFT TIE PORT_
Service Name:
サービス名：
rift-ties
リフトタイ
Port Number:
ポート番号：
915
915
Transport Protocol:
輸送プロトコル：
udp
UDP
Description:
説明：
Routing in Fat Trees Topology Information Element
脂肪木のトポロジ情報要素のルーティング
Assignee:
譲受人：
IESG (iesg@ietf.org)
iesg（iesg@ietf.org）
Contact:
接触：
IETF Chair (chair@ietf.org)
IETF椅子（椅子@ietf.org）
Reference:
参照：
RFC 9692
RFC 9692
A new registry has been created to hold the allowed RIFT security algorithms. No particular enumeration values are necessary since RIFT uses a key ID abstraction on packets without disclosing any information about the algorithm or secrets used and only carries the resulting fingerprint or signature protecting the integrity of the data.
許可されたRiftセキュリティアルゴリズムを保持するために、新しいレジストリが作成されました。Riftは、使用されているアルゴリズムまたは秘密に関する情報を開示せずにパケットのキーID抽象化を使用し、結果の指紋またはデータの完全性を保護する署名のみを運ぶため、特定の列挙値は必要ありません。
The registry applies the "Specification Required" policy per [RFC8126]. The designated expert should ensure that the algorithms suggested represent the state of the art at a given point in time and avoid introducing algorithms that do not represent enhanced security properties or ensure such properties at a lower cost as compared to existing registry entries.
レジストリは、[RFC8126]ごとに「必要な仕様」ポリシーを適用します。指定された専門家は、提案されたアルゴリズムが特定の時点で最新技術を表すことを確認し、拡張されたセキュリティプロパティを表していないアルゴリズムの導入を避けたり、既存のレジストリエントリと比較して低コストでそのようなプロパティを確保する必要があります。
+==========================+==========================+============+
| Name | Recommendation | Reference |
+==========================+==========================+============+
| HMAC-SHA256 | Simplest way to ensure | [SHA-2] |
| | integrity of | and |
| | transmissions across | [RFC2104] |
| | adjacencies when used as | |
| | outer keys and integrity | |
| | of TIEs when used as | |
| | inner keys. Recommended | |
| | for most interoperable | |
| | security protection. | |
+--------------------------+--------------------------+------------+
| HMAC-SHA512 | Same as HMAC-SHA256 with | [SHA-2] |
| | stronger protection. | and |
| | | [RFC2104] |
+--------------------------+--------------------------+------------+
| SHA256-RSASSA-PKCS1-v1_5 | Recommended for high | [RFC8017], |
| | security applications | Section |
| | where private keys are | 8.2 |
| | protected by according | |
| | nodes. Recommended as | |
| | well in case not only | |
| | integrity but origin | |
| | validation is necessary | |
| | for TIEs. Recommended | |
| | when adjacencies must be | |
| | protected without | |
| | disclosing the secrets | |
| | on both sides of the | |
| | adjacency. | |
+--------------------------+--------------------------+------------+
| SHA512-RSASSA-PKCS1-v1_5 | Same as SHA256-RSASSA- | [RFC8017] |
| | PKCS1-v1_5 with stronger | |
| | protection. | |
+--------------------------+--------------------------+------------+
Table 7: RIFT Security Algorithms
表7：リフトセキュリティアルゴリズム
This section requests registries that help govern the schema via the usual IANA registry procedures. The registry group "Routing in Fat Trees (RIFT)" holds the following registries. Registry values are stored with their minimum and maximum version in which they are available. All values not provided are to be considered "Unassigned". The range of every registry is a 16-bit integer. Allocation of new values is performed via "Expert Review" action only in the case of minor changes per the rules in Section 7. All other allocations are performed via "Specification Required".
このセクションでは、通常のIANAレジストリ手順を介してスキーマを管理するのに役立つレジストリを要求します。レジストリグループ「Fat Trees（Rift）のルーティング」には、次のレジストリが保持されます。レジストリ値は、利用可能な最小および最大バージョンで保存されます。提供されていないすべての値は、「未割り当て」と見なされます。すべてのレジストリの範囲は16ビット整数です。新しい値の割り当ては、セクション7のルールごとにわずかな変更の場合にのみ「エキスパートレビュー」アクションを介して実行されます。他のすべての割り当ては「必要な仕様」を介して実行されます。
In some cases, the registries do not contain necessary information such as whether the fields are optional or required, what units are used, or what datatype is involved. This information is encoded in the normative schema itself by the means of IDL syntax or necessary type definitions and their names.
場合によっては、レジストリには、フィールドがオプションであるか、必要か、使用されるユニット、またはどのデータ型が関係しているかなどの必要な情報が含まれていません。この情報は、IDL構文または必要なタイプ定義とその名前の手段によって規範的スキーマ自体にエンコードされています。
This registry stores all RIFT protocol schema major and minor versions, including the reference to the document introducing the version. This also means that, if multiple documents extend rift schema, they have to serialize using this registry to increase the minor or major versions sequentially.
このレジストリには、バージョンを導入するドキュメントへの参照を含む、すべてのRIFTプロトコルスキーマのメジャーおよびマイナーバージョンが保存されています。これはまた、複数のドキュメントがRiftスキーマを拡張する場合、このレジストリを使用してシリアル化して、マイナーバージョンまたはメジャーバージョンを順番に増やす必要があることを意味します。
+================+=====================+
| Schema Version | Reference |
+================+=====================+
| 8.0 | RFC 9692, Section 7 |
+----------------+---------------------+
Table 8
This registry has the following initial values. In addition to the columns shown below, the IANA registry also includes Comment and Reference columns.
このレジストリには、次の初期値があります。以下に示す列に加えて、IANAレジストリにはコメントと参照列も含まれています。
+=======+=======================+=====================+=============+
| Value | Name | Min. Schema | Max. Schema |
| | | Version | Version |
+=======+=======================+=====================+=============+
| 0 | Illegal | 8.0 | |
+-------+-----------------------+---------------------+-------------+
| 1 | AddressFamilyMinValue | 8.0 | |
+-------+-----------------------+---------------------+-------------+
| 2 | IPv4 | 8.0 | |
+-------+-----------------------+---------------------+-------------+
| 3 | IPv6 | 8.0 | |
+-------+-----------------------+---------------------+-------------+
| 4 | AddressFamilyMaxValue | 8.0 | |
+-------+-----------------------+---------------------+-------------+
Table 9: Address Family Type
表9：アドレスファミリタイプ
This registry has the following initial values. In addition to the columns below, the IANA registry also includes Comment and Reference columns.
このレジストリには、次の初期値があります。以下の列に加えて、IANAレジストリにはコメントと参照列も含まれています。
+=======+======================================+=========+=========+
| Value | Name | Min. | Max. |
| | | Schema | Schema |
| | | Version | Version |
+=======+======================================+=========+=========+
| 0 | leaf_only | 8.0 | |
+-------+--------------------------------------+---------+---------+
| 1 | leaf_only_and_leaf_2_leaf_procedures | 8.0 | |
+-------+--------------------------------------+---------+---------+
| 2 | top_of_fabric | 8.0 | |
+-------+--------------------------------------+---------+---------+
Table 10: Flags Indicating Node Configuration in Case of ZTP
表10：ZTPの場合のノード構成を示すフラグ
This registry has the following initial values. In addition to the columns below, the IANA registry also includes Comment and Reference columns.
このレジストリには、次の初期値があります。以下の列に加えて、IANAレジストリにはコメントと参照列も含まれています。
The timestamp is per IEEE 802.1AS; all values MUST be interpreted in implementation as unsigned.
タイムスタンプはIEEE 802.1ASごとにあります。すべての値は、実装では符号なしと解釈する必要があります。
+=======+==========+=====================+=====================+
| Value | Name | Min. Schema Version | Max. Schema Version |
+=======+==========+=====================+=====================+
| 0 | Reserved | 8.0 | All Versions |
+-------+----------+---------------------+---------------------+
| 1 | AS_sec | 8.0 | |
+-------+----------+---------------------+---------------------+
| 2 | AS_nsec | 8.0 | |
+-------+----------+---------------------+---------------------+
Table 11
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+=============+=====================+=============+=========+
| Value | Name | Min. Schema | Max. Schema | Comment |
| | | Version | Version | |
+=======+=============+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+-------------+---------------------+-------------+---------+
| 1 | ipv4address | 8.0 | | Content |
| | | | | is IPv4 |
+-------+-------------+---------------------+-------------+---------+
| 2 | ipv6address | 8.0 | | Content |
| | | | | is IPv6 |
+-------+-------------+---------------------+-------------+---------+
Table 12: IP Address Type
表12：IPアドレスタイプ
This registry has the following initial values.
このレジストリには、次の初期値があります。
Note: For interface addresses the protocol can propagate the address part beyond the subnet mask and on reachability computation the non-significant bits have to be normalized. Those bits can be used for operational purposes.
注：インターフェイスアドレスの場合、プロトコルはサブネットマスクを超えてアドレス部分を伝播できます。また、到達可能性計算では、重要でないビットを正規化する必要があります。これらのビットは、運用目的で使用できます。
+=======+============+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+============+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+------------+---------------------+-------------+---------+
| 1 | ipv4prefix | 8.0 | | |
+-------+------------+---------------------+-------------+---------+
| 2 | ipv6prefix | 8.0 | | |
+-------+------------+---------------------+-------------+---------+
Table 13: Prefix Advertisement
表13：プレフィックス広告
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+===========+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+===========+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+-----------+---------------------+-------------+---------+
| 1 | address | 8.0 | | |
+-------+-----------+---------------------+-------------+---------+
| 2 | prefixlen | 8.0 | | |
+-------+-----------+---------------------+-------------+---------+
Table 14: IPv4 Prefix Type
表14：IPv4プレフィックスタイプ
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+===========+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+===========+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+-----------+---------------------+-------------+---------+
| 1 | address | 8.0 | | |
+-------+-----------+---------------------+-------------+---------+
| 2 | prefixlen | 8.0 | | |
+-------+-----------+---------------------+-------------+---------+
Table 15: IPv6 Prefix Type
表15：IPv6プレフィックスタイプ
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+==============+=============+=============+=========+
| Value | Name | Min. Schema | Max. Schema | Comment |
| | | Version | Version | |
+=======+==============+=============+=============+=========+
| 0 | Unassigned | | | |
+-------+--------------+-------------+-------------+---------+
| 1 | Experimental | 8.0 | | |
+-------+--------------+-------------+-------------+---------+
| 2 | WellKnown | 8.0 | | |
+-------+--------------+-------------+-------------+---------+
| 3 | OUI | 8.0 | | |
+-------+--------------+-------------+-------------+---------+
Table 16
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+===============+=========+==========+===================+
| Value | Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=======+===============+=========+==========+===================+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+---------------+---------+----------+-------------------+
| 1 | timestamp | 8.0 | | |
+-------+---------------+---------+----------+-------------------+
| 2 | transactionid | 8.0 | | Transaction ID |
| | | | | set by client in, |
| | | | | e.g., 6LoWPAN. |
+-------+---------------+---------+----------+-------------------+
Table 17: Sequence of a Prefix in Case of Move
表17：移動の場合のプレフィックスのシーケンス
This registry has the following initial values.
このレジストリには、次の初期値があります。
Note: The only purpose of these values is to introduce an ordering, whereas an implementation can internally choose any other values as long the ordering is preserved.
注：これらの値の唯一の目的は、順序付けを導入することですが、実装は順序が保存されている間、他の値を内部的に選択できます。
+=======+=====================+=============+=============+=========+
| Value | Name | Min. Schema | Max. | Comment |
| | | Version | Schema | |
| | | | Version | |
+=======+=====================+=============+=============+=========+
| 0 | Illegal | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 1 | RouteTypeMinValue | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 2 | Discard | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 3 | LocalPrefix | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 4 | SouthPGPPrefix | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 5 | NorthPGPPrefix | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 6 | NorthPrefix | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 7 | NorthExternalPrefix | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 8 | SouthPrefix | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 9 | SouthExternalPrefix | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 10 | NegativeSouthPrefix | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
| 11 | RouteTypeMaxValue | 8.0 | | |
+-------+---------------------+-------------+-------------+---------+
Table 18: RIFT Route Types
表18：リフトルートタイプ
This registry has the following initial values. In addition to the columns below, the IANA registry also includes Comment and Reference columns.
このレジストリには、次の初期値があります。以下の列に加えて、IANAレジストリにはコメントと参照列も含まれています。
+=====+===========================================+=======+=======+
|Value|Name |Min. |Max. |
| | |Schema |Schema |
| | |Version|Version|
+=====+===========================================+=======+=======+
|0 |Illegal |8.0 | |
+-----+-------------------------------------------+-------+-------+
|1 |TIETypeMinValue |8.0 | |
+-----+-------------------------------------------+-------+-------+
|2 |NodeTIEType |8.0 | |
+-----+-------------------------------------------+-------+-------+
|3 |PrefixTIEType |8.0 | |
+-----+-------------------------------------------+-------+-------+
|4 |PositiveDisaggregationPrefixTIEType |8.0 | |
+-----+-------------------------------------------+-------+-------+
|5 |NegativeDisaggregationPrefixTIEType |8.0 | |
+-----+-------------------------------------------+-------+-------+
|6 |PGPrefixTIEType |8.0 | |
+-----+-------------------------------------------+-------+-------+
|7 |KeyValueTIEType |8.0 | |
+-----+-------------------------------------------+-------+-------+
|8 |ExternalPrefixTIEType |8.0 | |
+-----+-------------------------------------------+-------+-------+
|9 |PositiveExternalDisaggregationPrefixTIEType|8.0 | |
+-----+-------------------------------------------+-------+-------+
|10 |TIETypeMaxValue |8.0 | |
+-----+-------------------------------------------+-------+-------+
Table 19: Type of TIE
表19：タイのタイプ
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+===================+=============+=============+=========+
| Value | Name | Min. Schema | Max. Schema | Comment |
| | | Version | Version | |
+=======+===================+=============+=============+=========+
| 0 | Illegal | 8.0 | | |
+-------+-------------------+-------------+-------------+---------+
| 1 | South | 8.0 | | |
+-------+-------------------+-------------+-------------+---------+
| 2 | North | 8.0 | | |
+-------+-------------------+-------------+-------------+---------+
| 3 | DirectionMaxValue | 8.0 | | |
+-------+-------------------+-------------+-------------+---------+
Table 20: Direction of TIEs
表20：ネクタイの方向
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+==========+=====================+=============+============+
| Value | Name | Min. Schema | Max. Schema | Comment |
| | | Version | Version | |
+=======+==========+=====================+=============+============+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------+---------------------+-------------+------------+
| 1 | top | 8.0 | | Higher |
| | | | | order bits |
+-------+----------+---------------------+-------------+------------+
| 2 | bottom | 8.0 | | Lower |
| | | | | order bits |
+-------+----------+---------------------+-------------+------------+
Table 21: Prefix Community
表21：プレフィックスコミュニティ
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+===========+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+===========+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+-----------+---------------------+-------------+---------+
| 1 | keyvalues | 8.0 | | |
+-------+-----------+---------------------+-------------+---------+
Table 22: Generic Key Value Pairs
表22：一般的なキー値のペア
This registry has the following initial values. It defines the targeted nodes and the value carried.
このレジストリには、次の初期値があります。ターゲットノードと伝達される値を定義します。
+=======+==========+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+==========+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------+---------------------+-------------+---------+
| 1 | targets | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
| 2 | value | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
Table 23
This registry has the following initial values.
このレジストリには、次の初期値があります。
Note: This node's level is already included on the packet header.
注：このノードのレベルは、すでにパケットヘッダーに含まれています。
+=====+=============================+=======+========+==============+
|Value| Name |Min. |Max. |Comment |
| | |Schema |Schema | |
| | |Version|Version | |
+=====+=============================+=======+========+==============+
|0 | Reserved |8.0 |All | |
| | | |Versions| |
+-----+-----------------------------+-------+--------+--------------+
|1 | name |8.0 | |Node or |
| | | | |adjacency |
| | | | |name. |
+-----+-----------------------------+-------+--------+--------------+
|2 | local_id |8.0 | |Local link |
| | | | |ID. |
+-----+-----------------------------+-------+--------+--------------+
|3 | flood_port |8.0 | |UDP port to |
| | | | |which we can |
| | | | |receive |
| | | | |flooded TIEs. |
+-----+-----------------------------+-------+--------+--------------+
|4 | link_mtu_size |8.0 | |Layer 2 MTU, |
| | | | |used to |
| | | | |discover |
| | | | |mismatch. |
+-----+-----------------------------+-------+--------+--------------+
|5 | link_bandwidth |8.0 | |Local link |
| | | | |bandwidth on |
| | | | |the |
| | | | |interface. |
+-----+-----------------------------+-------+--------+--------------+
|6 | neighbor |8.0 | |Reflects the |
| | | | |neighbor once |
| | | | |received to |
| | | | |provide 3-way |
| | | | |connectivity. |
+-----+-----------------------------+-------+--------+--------------+
|7 | pod |8.0 | |Node's PoD. |
+-----+-----------------------------+-------+--------+--------------+
|10 | node_capabilities |8.0 | |Node |
| | | | |capabilities |
| | | | |supported. |
+-----+-----------------------------+-------+--------+--------------+
|11 | link_capabilities |8.0 | |Capabilities |
| | | | |of this link. |
+-----+-----------------------------+-------+--------+--------------+
|12 | holdtime |8.0 | |Required |
| | | | |holdtime of |
| | | | |the |
| | | | |adjacency, |
| | | | |i.e., for how |
| | | | |long a period |
| | | | |adjacency |
| | | | |should be |
| | | | |kept up |
| | | | |without valid |
| | | | |LIE |
| | | | |reception. |
+-----+-----------------------------+-------+--------+--------------+
|13 | label |8.0 | |Optional, |
| | | | |unsolicited, |
| | | | |downstream |
| | | | |assigned |
| | | | |locally |
| | | | |significant |
| | | | |label value |
| | | | |for the |
| | | | |adjacency. |
+-----+-----------------------------+-------+--------+--------------+
|21 | not_a_ztp_offer |8.0 | |Indicates |
| | | | |that the |
| | | | |level on the |
| | | | |LIE must not |
| | | | |be used to |
| | | | |derive a ZTP |
| | | | |level by the |
| | | | |receiving |
| | | | |node. |
+-----+-----------------------------+-------+--------+--------------+
|22 | you_are_flood_repeater |8.0 | |Indicates to |
| | | | |the |
| | | | |northbound |
| | | | |neighbor that |
| | | | |it should be |
| | | | |reflooding |
| | | | |TIEs received |
| | | | |from this |
| | | | |node to |
| | | | |achieve flood |
| | | | |reduction and |
| | | | |balancing for |
| | | | |northbound |
| | | | |flooding. |
+-----+-----------------------------+-------+--------+--------------+
|23 | you_are_sending_too_quickly |8.0 | |Indicates to |
| | | | |the neighbor |
| | | | |to flood node |
| | | | |TIEs only and |
| | | | |slow down all |
| | | | |other TIEs. |
| | | | |Ignored when |
| | | | |received from |
| | | | |the |
| | | | |southbound |
| | | | |neighbor. |
+-----+-----------------------------+-------+--------+--------------+
|24 | instance_name |8.0 | |Instance name |
| | | | |in case |
| | | | |multiple RIFT |
| | | | |instances are |
| | | | |running on |
| | | | |the same |
| | | | |interface. |
+-----+-----------------------------+-------+--------+--------------+
|35 | fabric_id |8.0 | |It provides |
| | | | |the optional |
| | | | |ID of the |
| | | | |fabric |
| | | | |configured. |
| | | | |This must |
| | | | |match the |
| | | | |information |
| | | | |advertised on |
| | | | |the node |
| | | | |element. |
+-----+-----------------------------+-------+--------+--------------+
Table 24: RIFT LIE Packet
表24：Rift Lieパケット
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=====+=========================+=========+==========+==============+
|Value| Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=====+=========================+=========+==========+==============+
|0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-----+-------------------------+---------+----------+--------------+
|1 | bfd | 8.0 | | Indicates |
| | | | | that the |
| | | | | link is |
| | | | | supporting |
| | | | | BFD. |
+-----+-------------------------+---------+----------+--------------+
|2 | ipv4_forwarding_capable | 8.0 | | Indicates |
| | | | | whether the |
| | | | | interface |
| | | | | will |
| | | | | support |
| | | | | IPv4 |
| | | | | forwarding. |
+-----+-------------------------+---------+----------+--------------+
Table 25: Link Capabilities
表25：リンク機能
The LinkID pair describes one of the parallel links between two nodes.
LinkIDペアは、2つのノード間の並列リンクの1つを記述します。
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=====+============================+=======+========+==============+
|Value| Name |Min. |Max. | Comment |
| | |Schema |Schema | |
| | |Version|Version | |
+=====+============================+=======+========+==============+
|0 | Reserved |8.0 |All | |
| | | |Versions| |
+-----+----------------------------+-------+--------+--------------+
|1 | local_id |8.0 | | Node-wide |
| | | | | unique value |
| | | | | for the |
| | | | | local link. |
+-----+----------------------------+-------+--------+--------------+
|2 | remote_id |8.0 | | Received the |
| | | | | remote link |
| | | | | ID for this |
| | | | | link. |
+-----+----------------------------+-------+--------+--------------+
|10 | platform_interface_index |8.0 | | Describes |
| | | | | the local |
| | | | | interface |
| | | | | index of the |
| | | | | link. |
+-----+----------------------------+-------+--------+--------------+
|11 | platform_interface_name |8.0 | | Describes |
| | | | | the local |
| | | | | interface |
| | | | | name. |
+-----+----------------------------+-------+--------+--------------+
|12 | trusted_outer_security_key |8.0 | | Indicates |
| | | | | whether the |
| | | | | link is |
| | | | | secured, |
| | | | | i.e., |
| | | | | protected by |
| | | | | outer key, |
| | | | | absence of |
| | | | | this element |
| | | | | means no |
| | | | | indication, |
| | | | | undefined |
| | | | | outer key |
| | | | | means not |
| | | | | secured. |
+-----+----------------------------+-------+--------+--------------+
|13 | bfd_up |8.0 | | Indicates |
| | | | | whether the |
| | | | | link is |
| | | | | protected by |
| | | | | an |
| | | | | established |
| | | | | BFD session. |
+-----+----------------------------+-------+--------+--------------+
|14 | address_families |8.0 | | Optional |
| | | | | indication |
| | | | | that address |
| | | | | families are |
| | | | | up on the |
| | | | | interface. |
+-----+----------------------------+-------+--------+--------------+
Table 26
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+============+=============+=============+=================+
| Value | Name | Min. Schema | Max. Schema | Comment |
| | | Version | Version | |
+=======+============+=============+=============+=================+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+------------+-------------+-------------+-----------------+
| 1 | originator | 8.0 | | System ID of |
| | | | | the originator. |
+-------+------------+-------------+-------------+-----------------+
| 2 | remote_id | 8.0 | | ID of remote |
| | | | | side of the |
| | | | | link. |
+-------+------------+-------------+-------------+-----------------+
Table 27: Neighbor Structure
表27：隣接構造
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=====+========================+=========+==========+==============+
|Value| Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=====+========================+=========+==========+==============+
|0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-----+------------------------+---------+----------+--------------+
|1 | protocol_minor_version | 8.0 | | Must |
| | | | | advertise |
| | | | | supported |
| | | | | minor |
| | | | | version |
| | | | | dialect that |
| | | | | way. |
+-----+------------------------+---------+----------+--------------+
|2 | flood_reduction | 8.0 | | Indicates |
| | | | | that node |
| | | | | supports |
| | | | | flood |
| | | | | reduction. |
+-----+------------------------+---------+----------+--------------+
|3 | hierarchy_indications | 8.0 | | Indicates |
| | | | | place in |
| | | | | hierarchy, |
| | | | | i.e., top of |
| | | | | fabric or |
| | | | | leaf only |
| | | | | (in ZTP) or |
| | | | | support for |
| | | | | L2L |
| | | | | procedures. |
+-----+------------------------+---------+----------+--------------+
Table 28: Capabilities the Node Supports
表28：ノードがサポートする機能
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+==========+=========+==========+===========================+
| Value | Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=======+==========+=========+==========+===========================+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------+---------+----------+---------------------------+
| 1 | overload | 8.0 | | Indicates that node |
| | | | | is in overload; do |
| | | | | not transit traffic |
| | | | | through it. |
+-------+----------+---------+----------+---------------------------+
Table 29: Indication Flags of the Node
表29：ノードの表示フラグ
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+===========+=========+==========+======================+
| Value | Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=======+===========+=========+==========+======================+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+-----------+---------+----------+----------------------+
| 1 | level | 8.0 | | Level of neighbor. |
+-------+-----------+---------+----------+----------------------+
| 3 | cost | 8.0 | | Cost to neighbor. |
| | | | | Ignore anything |
| | | | | equal or larger than |
| | | | | 'infinite_distance' |
| | | | | and equal to |
| | | | | 'invalid_distance'. |
+-------+-----------+---------+----------+----------------------+
| 4 | link_ids | 8.0 | | Carries description |
| | | | | of multiple parallel |
| | | | | links in a TIE. |
+-------+-----------+---------+----------+----------------------+
| 5 | bandwidth | 8.0 | | Total bandwidth to |
| | | | | neighbor as sum of |
| | | | | all parallel links. |
+-------+-----------+---------+----------+----------------------+
Table 30: Neighbor of a Node
表30：ノードの隣
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+=================+=========+==========+====================+
| Value | Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=======+=================+=========+==========+====================+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+-----------------+---------+----------+--------------------+
| 1 | level | 8.0 | | Level of the |
| | | | | node. |
+-------+-----------------+---------+----------+--------------------+
| 2 | neighbors | 8.0 | | Node's neighbors. |
| | | | | Multiple node |
| | | | | TIEs can carry |
| | | | | disjoint sets of |
| | | | | neighbors. |
+-------+-----------------+---------+----------+--------------------+
| 3 | capabilities | 8.0 | | Capabilities of |
| | | | | the node. |
+-------+-----------------+---------+----------+--------------------+
| 4 | flags | 8.0 | | Flags of the |
| | | | | node. |
+-------+-----------------+---------+----------+--------------------+
| 5 | name | 8.0 | | Optional node |
| | | | | name for easier |
| | | | | operations. |
+-------+-----------------+---------+----------+--------------------+
| 6 | pod | 8.0 | | Pod to which the |
| | | | | node belongs. |
+-------+-----------------+---------+----------+--------------------+
| 7 | startup_time | 8.0 | | Optional startup |
| | | | | time of the node. |
+-------+-----------------+---------+----------+--------------------+
| 10 | miscabled_links | 8.0 | | If any local |
| | | | | links are |
| | | | | miscabled, this |
| | | | | indication is |
| | | | | flooded. |
+-------+-----------------+---------+----------+--------------------+
| 12 | same_plane_tofs | 8.0 | | ToFs in the same |
| | | | | plane. Only |
| | | | | carried by ToF. |
| | | | | Multiple node |
| | | | | TIEs can carry |
| | | | | disjoint sets of |
| | | | | ToFs that must be |
| | | | | joined to form a |
| | | | | single set. |
+-------+-----------------+---------+----------+--------------------+
| 20 | fabric_id | 8.0 | | It provides the |
| | | | | optional ID of |
| | | | | the fabric |
| | | | | configured. |
+-------+-----------------+---------+----------+--------------------+
Table 31: Description of a Node
表31：ノードの説明
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+==========+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+==========+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------+---------------------+-------------+---------+
| 1 | lie | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
| 2 | tide | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
| 3 | tire | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
| 4 | tie | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
Table 32: Content of a RIFT Packet
表32：リフトパケットの内容
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+===============+=========+==========+===================+
| Value | Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=======+===============+=========+==========+===================+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+---------------+---------+----------+-------------------+
| 1 | major_version | 8.0 | | Major version of |
| | | | | protocol. |
+-------+---------------+---------+----------+-------------------+
| 2 | minor_version | 8.0 | | Minor version of |
| | | | | protocol. |
+-------+---------------+---------+----------+-------------------+
| 3 | sender | 8.0 | | Node sending the |
| | | | | packet; in case |
| | | | | of LIE/TIRE/TIDE |
| | | | | also the |
| | | | | originator of it. |
+-------+---------------+---------+----------+-------------------+
| 4 | level | 8.0 | | Level of the node |
| | | | | sending the |
| | | | | packet, required |
| | | | | on everything |
| | | | | except LIEs. |
| | | | | Lack of presence |
| | | | | on LIEs indicates |
| | | | | undefined_level |
| | | | | and is used in |
| | | | | ZTP procedures. |
+-------+---------------+---------+----------+-------------------+
Table 33: Common RIFT Packet Header
表33：一般的なリフトパケットヘッダー
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+===================+=========+==========+==================+
| Value | Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=======+===================+=========+==========+==================+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+-------------------+---------+----------+------------------+
| 2 | metric | 8.0 | | Distance of the |
| | | | | prefix. |
+-------+-------------------+---------+----------+------------------+
| 3 | tags | 8.0 | | Generic |
| | | | | unordered set |
| | | | | of route tags, |
| | | | | can be |
| | | | | redistributed |
| | | | | to other |
| | | | | protocols or |
| | | | | used within the |
| | | | | context of real |
| | | | | time analytics. |
+-------+-------------------+---------+----------+------------------+
| 4 | monotonic_clock | 8.0 | | Monotonic clock |
| | | | | for mobile |
| | | | | addresses. |
+-------+-------------------+---------+----------+------------------+
| 6 | loopback | 8.0 | | Indicates if |
| | | | | the prefix is a |
| | | | | node loopback. |
+-------+-------------------+---------+----------+------------------+
| 7 | directly_attached | 8.0 | | Indicates that |
| | | | | the prefix is |
| | | | | directly |
| | | | | attached. |
+-------+-------------------+---------+----------+------------------+
| 10 | from_link | 8.0 | | Link to which |
| | | | | the address |
| | | | | belongs to. |
+-------+-------------------+---------+----------+------------------+
| 12 | label | 8.0 | | Optional, per- |
| | | | | prefix |
| | | | | significant |
| | | | | label. |
+-------+-------------------+---------+----------+------------------+
Table 34: Attributes of a Prefix
表34：プレフィックスの属性
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+==========+=============+=============+================+
| Value | Name | Min. Schema | Max. Schema | Comment |
| | | Version | Version | |
+=======+==========+=============+=============+================+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------+-------------+-------------+----------------+
| 1 | prefixes | 8.0 | | Prefixes with |
| | | | | the associated |
| | | | | attributes. |
+-------+----------+-------------+-------------+----------------+
Table 35: TIE Carrying Prefixes
表35：キャリングプレフィックスを獲得します
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+==========+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+==========+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------+---------------------+-------------+---------+
| 1 | header | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
| 2 | content | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
Table 36: RIFT Packet Structure
表36：リフトパケット構造
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+=============+=============+=============+===============+
| Value | Name | Min. Schema | Max. Schema | Comment |
| | | Version | Version | |
+=======+=============+=============+=============+===============+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+-------------+-------------+-------------+---------------+
| 1 | start_range | 8.0 | | First TIE |
| | | | | header in the |
| | | | | TIDE packet. |
+-------+-------------+-------------+-------------+---------------+
| 2 | end_range | 8.0 | | Last TIE |
| | | | | header in the |
| | | | | TIDE packet. |
+-------+-------------+-------------+-------------+---------------+
| 3 | headers | 8.0 | | _sorted_ list |
| | | | | of headers. |
+-------+-------------+-------------+-------------+---------------+
Table 37: TIDE with Sorted TIE Headers
表37：ソートされたネクタイヘッダーで潮
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=====+========================+=======+========+===================+
|Value|Name |Min. |Max. |Comment |
| | |Schema |Schema | |
| | |Version|Version | |
+=====+========================+=======+========+===================+
|0 |Reserved |8.0 |All | |
| | | |Versions| |
+-----+------------------------+-------+--------+-------------------+
|1 |node |8.0 | |Used in case of |
| | | | |enum |
| | | | |common.tietypetype.|
| | | | |nodetietype. |
+-----+------------------------+-------+--------+-------------------+
|2 |prefixes |8.0 | |Used in case of |
| | | | |enum |
| | | | |common.tietypetype.|
| | | | |prefixtietype. |
+-----+------------------------+-------+--------+-------------------+
|3 |positive_disaggregation_|8.0 | |Positive prefixes |
| |prefixes | | |(always |
| | | | |southbound). |
+-----+------------------------+-------+--------+-------------------+
|5 |negative_disaggregation_|8.0 | |Transitive, |
| |prefixes | | |negative prefixes |
| | | | |(always southbound)|
+-----+------------------------+-------+--------+-------------------+
|6 |external_prefixes |8.0 | |Externally |
| | | | |reimported |
| | | | |prefixes. |
+-----+------------------------+-------+--------+-------------------+
|7 |positive_external_ |8.0 | |Positive external |
| |disaggregation_prefixes | | |disaggregated |
| | | | |prefixes |
| | | | |(always |
| | | | |southbound). |
+-----+------------------------+-------+--------+-------------------+
|9 |keyvalues |8.0 | |Key-value |
| | | | |store elements. |
+-----+------------------------+-------+--------+-------------------+
Table 38: Single Element in a TIE
表38：ネクタイの単一要素
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+======================+=========+==========+==============+
| Value | Name | Min. | Max. | Comment |
| | | Schema | Schema | |
| | | Version | Version | |
+=======+======================+=========+==========+==============+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------------------+---------+----------+--------------+
| 2 | tieid | 8.0 | | ID of TIE. |
+-------+----------------------+---------+----------+--------------+
| 3 | seq_nr | 8.0 | | Sequence |
| | | | | number of |
| | | | | TIE. |
+-------+----------------------+---------+----------+--------------+
| 10 | origination_time | 8.0 | | Absolute |
| | | | | timestamp |
| | | | | when TIE was |
| | | | | generated. |
+-------+----------------------+---------+----------+--------------+
| 12 | origination_lifetime | 8.0 | | Original |
| | | | | lifetime |
| | | | | when TIE was |
| | | | | generated. |
+-------+----------------------+---------+----------+--------------+
Table 39: Header of a TIE
表39：ネクタイのヘッダー
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+====================+=============+==========+===========+
| Value | Name | Min. Schema | Max. | Comment |
| | | Version | Schema | |
| | | | Version | |
+=======+====================+=============+==========+===========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+--------------------+-------------+----------+-----------+
| 1 | header | 8.0 | | |
+-------+--------------------+-------------+----------+-----------+
| 2 | remaining_lifetime | 8.0 | | Remaining |
| | | | | lifetime. |
+-------+--------------------+-------------+----------+-----------+
Table 40: Header of a TIE as Described in TIRE/TIDE
表40：タイヤ/潮に記載されているネクタイのヘッダー
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+============+=============+=============+============+
| Value | Name | Min. Schema | Max. Schema | Comment |
| | | Version | Version | |
+=======+============+=============+=============+============+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+------------+-------------+-------------+------------+
| 1 | direction | 8.0 | | Direction |
| | | | | of TIE. |
+-------+------------+-------------+-------------+------------+
| 2 | originator | 8.0 | | Indicates |
| | | | | originator |
| | | | | of TIE. |
+-------+------------+-------------+-------------+------------+
| 3 | tietype | 8.0 | | Type of |
| | | | | TIE. |
+-------+------------+-------------+-------------+------------+
| 4 | tie_nr | 8.0 | | Number of |
| | | | | TIE. |
+-------+------------+-------------+-------------+------------+
Table 41: Unique ID of a TIE
表41：ネクタイの一意のID
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+==========+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+==========+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------+---------------------+-------------+---------+
| 1 | header | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
| 2 | element | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
Table 42: TIE Packet
表42：タイパケット
This registry has the following initial values.
このレジストリには、次の初期値があります。
+=======+==========+=====================+=============+=========+
| Value | Name | Min. Schema Version | Max. Schema | Comment |
| | | | Version | |
+=======+==========+=====================+=============+=========+
| 0 | Reserved | 8.0 | All | |
| | | | Versions | |
+-------+----------+---------------------+-------------+---------+
| 1 | headers | 8.0 | | |
+-------+----------+---------------------+-------------+---------+
Table 43: TIRE Packet
表43：タイヤパケット
[EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier
(EUI), Organizationally Unique Identifier (OUI), and
Company ID (CID)", <https://standards-support.ieee.org/hc/
en-us/articles/4888705676564-Guidelines-for-Use-of-
Extended-Unique-Identifier-EUI-Organizationally-Unique-
Identifier-OUI-and-Company-ID-CID>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, DOI 10.17487/RFC2365, July 1998,
<https://www.rfc-editor.org/info/rfc2365>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>.
[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>.
[RFC7987] Ginsberg, L., Wells, P., Decraene, B., Przygienda, T., and
H. Gredler, "IS-IS Minimum Remaining Lifetime", RFC 7987,
DOI 10.17487/RFC7987, October 2016,
<https://www.rfc-editor.org/info/rfc7987>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS
Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June
2017, <https://www.rfc-editor.org/info/rfc8202>.
[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>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.
[SHA-2] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, July 2015,
<https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.
[thrift] Apache Software Foundation, "Apache Thrift Documentation",
<https://thrift.apache.org/docs/>.
[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>.
[DayOne] Aelmans, M., Vandezande, O., Rijsman, B., Head, J., Graf,
C., Alberro, L., Mali, H., and O. Steudler, "Day One:
Routing in Fat Trees (RIFT)", Juniper Network Books,
ISBN 978-1-7363160-0-9, December 2020.
[DIJKSTRA] Dijkstra, E. W., "A Note on Two Problems in Connexion with
Graphs", Numerische Mathematik, vol. 1, pp. 269-271,
DOI 10.1007/BF01386390, December 1959,
<https://link.springer.com/article/10.1007/BF01386390>.
[DYNAMO] De Candia, G., Hastorun, D., Jampani, M., Kakulpati, G.,
Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall,
P., and W. Vogels, "Dynamo: amazon's highly available key-
value store", ACM SIGOPS Operating Systems Review, vol.
41, no. 6, pp. 205-220, DOI 10.1145/1323293.1294281,
October 2007,
<https://dl.acm.org/doi/10.1145/1323293.1294281>.
[EPPSTEIN] Eppstein, D., "Finding the k Shortest Paths", March 1997,
<https://ics.uci.edu/~eppstein/pubs/Epp-SJC-98.pdf>.
[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-2008, DOI 10.1109/IEEESTD.2008.4579760, July
2008, <https://ieeexplore.ieee.org/document/4579760/>.
[IEEEstd8021AS]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Timing and Synchronization for Time-Sensitive
Applications in Bridged Local Area Networks", IEEE Std
802.1AS-2011, DOI 10.1109/IEEESTD.2011.5741898, March
2011, <https://ieeexplore.ieee.org/document/5741898/>.
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991,
DOI 10.17487/RFC2991, November 2000,
<https://www.rfc-editor.org/info/rfc2991>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[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>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen,
N., and JR. Rivers, "Extending ICMP for Interface and
Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837,
April 2010, <https://www.rfc-editor.org/info/rfc5837>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC9696] Wei, Y., Ed., Zhang, Z., Afanasiev, D., Thubert, P., and
T. Przygienda, "Routing in Fat Trees (RIFT) Applicability
and Operational Considerations", RFC 9696,
DOI 10.17487/RFC9696, April 2025,
<https://www.rfc-editor.org/info/rfc9696>.
[VAHDAT08] Al-Fares, M., Loukissas, A., and A. Vahdat, "A Scalable,
Commodity Data Center Network Architecture", ACM SIGCOMM
Computer Communication Review, vol. 38, no. 4, pp. 63-74,
DOI 10.1145/1402946.1402967, August 2008,
<https://dl.acm.org/doi/10.1145/1402946.1402967>.
[VFR] Giotsas, V. and S. Zhou, "Valley-free violation in
Internet routing - Analysis based on BGP Community data",
2012 IEEE International Conference on Communications
(ICC), DOI 10.1109/ICC.2012.6363987, June 2012,
<https://ieeexplore.ieee.org/document/6363987>.
This section defines a variant of sequence number arithmetic related to [RFC1982] explained over two complement arithmetic, which is easy to implement.
このセクションでは、[RFC1982]に関連するシーケンス番号算術のバリアントを定義します。これは、実装が簡単な2つの補体算術について説明します。
Assuming straight two complement's subtractions on the bit width of the sequence numbers, the corresponding >: and =: relations are defined as:
シーケンス番号のビット幅に関する2つの補数の減算を想定すると、対応する>：および=：関係は次のように定義されます。
* U_1, U_2 are 12-bits aligned unsigned version number
* U_1、U_2は、署名されていないバージョン番号の12ビットです
* D_f is ( U_1 - U_2 ) interpreted as two complement signed 12-bits
* D_Fは（U_1 -U_2）2つの補完署名12ビットとして解釈されます
* D_b is ( U_2 - U_1 ) interpreted as two complement signed 12-bits
* D_Bは（U_2 -U_1）2つの補完署名12ビットとして解釈されます
* U_1 >: U_2 IIF D_f > 0 *and* D_b < 0
* u_1>：u_2 iif d_f> 0 *および * d_b <0
* U_1 =: U_2 IIF D_f = 0
* u_1 =：u_2 iif d_f = 0
The >: relationship is anti-symmetric but not transitive. Observe that this leaves >: of the numbers having maximum two complement distance, e.g., ( 0 and 0x800 ) undefined in the 12-bits case since D_f and D_b are both -0x7ff.
>：関係は反対称ですが、推移的ではありません。D_FとD_Bは両方とも-0x7FFであるため、12ビットの場合、最大2つの補数距離を持つ数値の>
A simple example of the relationship in case of 3-bit arithmetic follows as table indicating D_f/D_b values and then the relationship of U_1 to U_2:
3ビットの算術の場合の関係の簡単な例は、D_F/D_B値を示す表として続き、U_1とU_2の関係を示します。
+=========+=====+=====+=====+=====+=====+=====+=====+=====+
| U2 / U1 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+=========+=====+=====+=====+=====+=====+=====+=====+=====+
| 0 | +/+ | +/- | +/- | +/- | -/- | -/+ | -/+ | -/+ |
+---------+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | -/+ | +/+ | +/- | +/- | +/- | -/- | -/+ | -/+ |
+---------+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | -/+ | -/+ | +/+ | +/- | +/- | +/- | -/- | -/+ |
+---------+-----+-----+-----+-----+-----+-----+-----+-----+
| 3 | -/+ | -/+ | -/+ | +/+ | +/- | +/- | +/- | -/- |
+---------+-----+-----+-----+-----+-----+-----+-----+-----+
| 4 | -/- | -/+ | -/+ | -/+ | +/+ | +/- | +/- | +/- |
+---------+-----+-----+-----+-----+-----+-----+-----+-----+
| 5 | +/- | -/- | -/+ | -/+ | -/+ | +/+ | +/- | +/- |
+---------+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | +/- | +/- | -/- | -/+ | -/+ | -/+ | +/+ | +/- |
+---------+-----+-----+-----+-----+-----+-----+-----+-----+
| 7 | +/- | +/- | +/- | -/- | -/+ | -/+ | -/+ | +/+ |
+---------+-----+-----+-----+-----+-----+-----+-----+-----+
Table 44
+=========+===+===+===+===+===+===+===+===+
| U2 / U1 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+=========+===+===+===+===+===+===+===+===+
| 0 | = | > | > | > | ? | < | < | < |
+---------+---+---+---+---+---+---+---+---+
| 1 | < | = | > | > | > | ? | < | < |
+---------+---+---+---+---+---+---+---+---+
| 2 | < | < | = | > | > | > | ? | < |
+---------+---+---+---+---+---+---+---+---+
| 3 | < | < | < | = | > | > | > | ? |
+---------+---+---+---+---+---+---+---+---+
| 4 | ? | < | < | < | = | > | > | > |
+---------+---+---+---+---+---+---+---+---+
| 5 | > | ? | < | < | < | = | > | > |
+---------+---+---+---+---+---+---+---+---+
| 6 | > | > | ? | < | < | < | = | > |
+---------+---+---+---+---+---+---+---+---+
| 7 | > | > | > | ? | < | < | < | = |
+---------+---+---+---+---+---+---+---+---+
Table 45
^ N +--------+ +--------+
Level 2 | |ToF 21| |ToF 22|
W <-*-> E ++-+--+-++ ++-+--+-++
| | | | | | | | |
S v P111/2 P121/2 | | | |
MHP MHP | | | |
^ ^ ^ ^ | | | |
| | | | | | | |
+--------------+ | +-----------+ | | | +---------------+
| | | | | | | |
| +-----------------------------+ | | ^
| | | | | | | All
0/0 0/0 0/0 +-----------------------------+ TIEs
v v v | | | | |
| | +-+ +<-0/0----------+ | |
| | | | | | | |
+-+----++ Optional +-+----++ ++----+-+ ++-----++
Level 1 | | E/W Link | | | | | |
|Spin111+----------+Spin112| |Spin121| |Spin122|
+-+---+-+ ++----+-+ +-+---+-+ ++---+--+
| | | | | | | |
| +---0/0--->-----+ 0/0 | +----------------+ |
0/0 | | | | | | |
| +---<-0/0-----+ | v | +--------------+ | |
v | | | | | | |
+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+
Level 0 | | L2L | | | | | |
|Leaf111+~~~~~~~~~~+Leaf112| |Leaf121| |Leaf122|
+-+-----+ +-+---+-+ +--+--+-+ +-+-----+
+ + \ / + +
Prefix111 Prefix112 \ / Prefix121 Prefix122
Multi-homed
Prefix
+---------- PoD 1 ---------+ +---------- PoD 2 ---------+
Figure 35: Normal Case Topology
図35：通常のケーストポロジー
This section describes RIFT deployment in the example topology given in Figure 35 without any node or link failures. The scenario disregards flooding reduction for simplicity's sake and compresses the node names in some cases to fit them into the picture better.
このセクションでは、ノードやリンクの障害なしに図35に示すトポロジの例のリフト展開について説明します。このシナリオは、シンプルさのために洪水の削減を無視し、場合によってはノード名を圧縮して、それらを写真によく合わせます。
First, the following bidirectional adjacencies will be established:
まず、次の双方向の隣接が確立されます。
1. ToF 21 (PoD 0) to Spine 111, Spine 112, Spine 121, and Spine 122
1. TOF 21（ポッド0）からスパイン111、スパイン112、スパイン121、および脊椎122
2. ToF 22 (PoD 0) to Spine 111, Spine 112, Spine 121, and Spine 122
2. TOF 22（ポッド0）から背骨111、背骨112、背骨121、および脊椎122
3. Spine 111 to Leaf 111 and Leaf 112
3. 脊椎111から葉111および葉112
4. Spine 112 to Leaf 111 and Leaf 112
4. 脊椎112から葉111およびリーフ112
5. Spine 121 to Leaf 121 and Leaf 122
5. 脊椎121から葉121およびリーフ122
6. Spine 122 to Leaf 121 and Leaf 122
6. 脊椎122から葉121およびリーフ122
Leaf 111 and Leaf 112 originate N-TIEs for Prefix 111 and Prefix 112 (respectively) to both Spine 111 and Spine 112 (Leaf 112 also originates an N-TIE for the multihomed prefix). Spine 111 and Spine 112 will then originate their own N-TIEs, as well as flood the N-TIEs received from Leaf 111 and Leaf 112 to both ToF 21 and ToF 22.
リーフ111とリーフ112は、脊椎111と脊椎112の両方にプレフィックス111およびプレフィックス112（それぞれ）のN-Tiesを発生します（Leaf 112は、マルチホームのプレフィックスのn-tieも発生します）。スパイン111とスパイン112は、独自のN-Tiesを発信し、Leaf 111とLeaf 112からTOF 21とTOF 22の両方に受け取ったNタイを洪水にします。
Similarly, Leaf 121 and Leaf 122 originate North TIEs for Prefix 121 and Prefix 122 (respectively) to Spine 121 and Spine 122 (Leaf 121 also originates a North TIE for the multihomed prefix). Spine 121 and Spine 122 will then originate their own North TIEs, as well as flood the North TIEs received from Leaf 121 and Leaf 122 to both ToF 21 and ToF 22.
同様に、リーフ121とリーフ122は、プレフィックス121およびプレフィックス122（それぞれ）の脊椎121および脊椎122の北タイを開始します（Leaf 121は、マルチホームのプレフィックスの北タイも発生します）。スパイン121とスパイン122は、独自の北ネクタイを発信し、リーフ121とリーフ122から受け取った北ネクタイをTOF 21とTOF 22の両方に洪水にします。
Spines hold only North TIEs of level 0 for their PoD, while leaves only hold their own North TIEs while, at this point, both ToF 21 and ToF 22 (as well as any northbound connected controllers) would have the complete network topology.
スパインはポッドのレベル0の北タイのみを保持しますが、葉は独自の北タイのみを保持しますが、この時点では、TOF 21とTOF 22（および北行きの接続コントローラー）の両方が完全なネットワークトポロジを持ちます。
ToF 21 and ToF 22 would then originate and flood South TIEs containing any established adjacencies and a default IP route to all spines. Spine 111, Spine 112, Spine 121, and Spine 122 will reflect all South Node TIEs received from ToF 21 to ToF 22 and all South Node TIEs from ToF 22 to ToF 21. South TIEs will not be re-propagated southbound.
その後、TOF 21とTOF 22は、確立された隣接とすべての棘へのデフォルトのIPルートを含む南ネクタイを発生および洪水にします。背骨111、脊椎112、脊椎121、および脊椎122は、TOF 21からTOF 22に受け取ったすべての南ノードネクタイを反映し、TOF 22からTOF 21へのすべてのサウスノードネクタイを反映します。
South TIEs containing a default IP route are then originated by both Spine 111 and Spine 112 towards Leaf 111 and Leaf 112. Similarly, South TIEs containing a default IP route are originated by Spine 121 and Spine 122 towards Leaf 121 and Leaf 122.
デフォルトのIPルートを含むサウスタイは、脊椎111と脊椎112の両方から葉111と葉112に向かって発生します。同様に、デフォルトのIPルートを含む南のタイは、脊椎121と脊椎122が葉121とリーフ122に向かって発信されます。
At this point, IP connectivity across the maximum number of viable paths has been established for all leaves, with routing information constrained to only the minimum amount that allows for normal operation and redundancy.
この時点で、すべての葉に対して最大数の実行可能なパス数にわたるIP接続が確立されており、通常の操作と冗長性を可能にする最小量のみに制限されているルーティング情報が確立されています。
| | | |
+-+---+-+ +-+---+-+
| | | |
|Spin111| |Spin112|
+-+---+-+ ++----+-+
| | | |
| +---------------+ X
| | | X
| +-------------+ | X
| | | |
+-+---+-+ +--+--+-+
| | | |
|Leaf111| |Leaf112|
+-------+ +-------+
+ +
Prefix111 Prefix112
Figure 36: Single Leaf Link Failure
図36：単一の葉のリンク障害
In the event of a link failure between Spine 112 and Leaf 112, both nodes will originate new Node TIEs that contain their connected adjacencies, except for the one that just failed. Leaf 112 will send a North Node TIE to Spine 111. Spine 112 will send a North Node TIE to ToF 21 and ToF 22 as well as a new South Node TIE to Leaf 111 that will be reflected to Spine 111. Necessary SPF recomputation will occur, resulting in Spine 112 no longer being in the forwarding path for Prefix 112.
スパイン112とLeaf 112の間のリンク障害が発生した場合、両方のノードは、故障したものを除き、接続された隣接を含む新しいノードタイを発生します。リーフ112は、スパイン111にノースノードタイを送信します。スパイン112は、TOF 21とTOF 22にノースノードタイを送信し、葉111に新しいサウスノードタイを送信します。これは脊椎111に反映されます。
Spine 111 will also disaggregate Prefix 112 by sending new South Prefix TIE to Leaf 111 and Leaf 112. Though disaggregation is covered in more detail in the following section, it is worth mentioning in this example as it further illustrates RIFT's mechanism to mitigate traffic loss. Consider that Leaf 111 has yet to receive the more specific (disaggregated) route from Spine 111. In such a scenario, traffic from Leaf 111 towards Prefix 112 may still use Spine 112's default route, causing it to traverse ToF 21 and ToF 22 back down via Spine 111. While this behavior is suboptimal, it is transient in nature and preferred to dropping traffic.
また、スパイン111は、新しいサウスプレフィックスタイをLeaf 111およびLeaf 112に送信することにより、接頭辞112を分解します。次のセクションでは、分解については詳細に説明しますが、トラフィックの損失を軽減するためのRiftのメカニズムをさらに示しているため、この例で言及する価値があります。Leaf 111は、背骨111からより具体的な（分解された）ルートをまだ受け取っていないことを考慮してください。このようなシナリオでは、Leaf 111からプレフィックス112へのトラフィックは、スパイン112のデフォルトルートを使用する可能性があります。
+--------+ +--------+
Level 2 |ToF 21| |ToF 22|
++-+--+-++ ++-+--+-++
| | | | | | | |
| | | | | | | 0/0
| | | | | | | |
| | | | | | | |
+--------------+ | +--- XXXXXX + | | | +---------------+
| | | | | | | |
| +-----------------------------+ | | |
0/0 | | | | | | |
| 0/0 0/0 +- XXXXXXXXXXXXXXXXXXXXXXXXX -+ |
| 1.1/16 | | | | | |
| | +-+ +-0/0-----------+ | |
| | | 1.1./16 | | | |
+-+----++ +-+-----+ ++-----0/0 ++----0/0
Level 1 | | | | | 1.1/16 | 1.1/16
|Spin111| |Spin112| |Spin121| |Spin122|
+-+---+-+ ++----+-+ +-+---+-+ ++---+--+
| | | | | | | |
| +---------------+ | | +----------------+ |
| | | | | | | |
| +-------------+ | | | +--------------+ | |
| | | | | | | |
+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+
Level 3 | | | | | | | |
|Leaf111| |Leaf112| |Leaf121| |Leaf122|
+-+-----+ ++------+ +-----+-+ +-+-----+
+ + + +
Prefix111 Prefix112 Prefix121 Prefix122
1.1/16
Figure 37: Fabric Partition
図37：ファブリックパーティション
Figure 37 shows more catastrophic scenario where ToF 21 is completely severed from access to Prefix 121 due to a double link failure. If only default routes existed, this would result in 50% of traffic from Leaf 111 and Leaf 112 towards Prefix 121 being dropped.
図37は、ダブルリンクの障害により、TOF 21が接頭辞121へのアクセスから完全に切断される、より壊滅的なシナリオを示しています。デフォルトルートのみが存在する場合、これにより、Leaf 111とLeaf 112からプレフィックス121に向かって葉112から削除されるのは50％になります。
The mechanism to resolve this scenario hinges on ToF 21's South TIEs being reflected from Spine 111 and Spine 112 to ToF 22. Once ToF 22 is informed that Prefix 121 cannot be reached from ToF 21, it will begin to disaggregate Prefix 121 by advertising a more specific route (1.1/16), along with the default IP prefix route to all spines (ToF 21 still only sends a default route). The result is Spine 111 and Spine 112 using the more specific route to Prefix 121 via ToF 22. All other prefixes continue to use the default IP prefix route towards both ToF 21 and ToF 22.
このシナリオを解決するメカニズムは、TOF 21の南ネクタイが背骨111と背骨112からTOF 22に反映されていることにかかっています。TOF22は、TOF 21からプレフィックス121に到達できないことを通知します。その結果、スパイン111とスパイン112は、より特定のルートを使用してTOF 22を介してプレフィックス121になります。
The more specific route for Prefix 121 being advertised by ToF 22 does not need to be propagated further south to the leaves, as they do not benefit from this information. Spine 111 and Spine 112 are only required to reflect the new South Node TIEs received from ToF 22 to ToF 21. In short, only the relevant nodes received the relevant updates, thereby restricting the failure to only the partitioned level rather than burdening the whole fabric with the flooding and recomputation of the new topology information.
TOF 22によって宣伝されているプレフィックス121のより具体的なルートは、この情報の恩恵を受けていないため、葉までさらに南に伝播する必要はありません。脊椎111と脊椎112は、TOF 22から受信した新しい南ノードのネクタイをTOF 21に反映するためにのみ必要です。要するに、関連するノードのみが関連する更新を受け取り、それにより、新しいトポロジ情報の洪水と償還を備えたファブリック全体に負担をかけるのではなく、パーティションレベルのみに失敗することを制限します。
To finish this example, the following list shows sets computed by ToF 22 using notation introduced in Section 6.5:
この例を完了するために、次のリストは、セクション6.5で導入された表記を使用して、TOF 22によって計算されたセットを示しています。
|R = Prefix 111, Prefix 112, Prefix 121, Prefix 122
| r =プレフィックス111、プレフィックス112、プレフィックス121、プレフィックス122
|H (for r=Prefix 111) = Spine 111, Spine 112
| h（r = prefix 111）=脊椎111、脊椎112
|H (for r=Prefix 112) = Spine 111, Spine 112
| h（r = prefix 112）=脊椎111、脊椎112
|H (for r=Prefix 121) = Spine 121, Spine 122
| h（r = prefix 121）=脊椎121、脊椎122
|H (for r=Prefix 122) = Spine 121, Spine 122
| H（R =プレフィックス122）=背骨121、脊椎122
|A (for ToF 21) = Spine 111, Spine 112
| A（TOF 21の場合）=脊椎111、脊椎112
With that and |H (for r=Prefix 121) and |H (for r=Prefix 122) being disjoint from |A (for ToF 21), ToF 22 will originate a South TIE with Prefix 121 and Prefix 122, which will be flooded to all spines.
その場合、| h（r = prefix 121）および| h（r = prefix 122の場合）は| a（tof 21）から矛盾しています。TOF22は、すべての棘に浸水するプレフィックス121およびプレフィックス122で南ネタを発信します。
+ + +
X N1 | N2 | N3
X | |
+--+----+ +--+----+ +--+-----+
| |0/0> <0/0| |0/0> <0/0| |
| A01 +----------+ A02 +----------+ A03 | Level 1
++-+-+--+ ++--+--++ +---+-+-++
| | | | | | | | |
| | +----------------------------------+ | | |
| | | | | | | | |
| +-------------+ | | | +--------------+ |
| | | | | | | | |
| +----------------+ | +-----------------+ |
| | | | | | | | |
| | +------------------------------------+ | |
| | | | | | | | |
++-+-+--+ | +---+---+ | +-+---+-++
| | +-+ +-+ | |
| L01 | | L02 | | L03 | Level 0
+-------+ +-------+ +--------+
Figure 38: North Partitioned Router
図38：北部のルーター
Figure 38 shows a part of a fabric where level 1 is horizontally connected and A01 lost its only northbound adjacency. Based on N-SPF rules in Section 6.4.1, A01 will compute northbound reachability by using the link A01 to A02. However, A02 will *not* use this link during N-SPF. The result is A01 utilizing the horizontal link for default route advertisement and unidirectional routing.
図38は、レベル1が水平に接続されており、A01が北行きの隣接のみを失ったファブリックの一部を示しています。セクション6.4.1のN-SPFルールに基づいて、A01はリンクA01からA02を使用して北行きの到達可能性を計算します。ただし、A02はN-SPF中にこのリンクを使用しません。その結果、A01は、デフォルトのルート広告と単方向ルーティングに水平リンクを利用しています。
Furthermore, if A02 also loses its only northbound adjacency (N2), the situation evolves. A01 will no longer have northbound reachability while it receives A03's northbound adjacencies in South Node TIEs reflected by nodes south of it. As a result, A01 will no longer advertise its default route in accordance with Section 6.3.8.
さらに、A02も北に隣接する唯一の隣接（N2）を失った場合、状況は進化します。A01は、北の到達可能性を持つことができなくなり、南ノードのネクタイでA03の北行きの隣接を受け取ります。その結果、A01はセクション6.3.8に従ってデフォルトルートを宣伝しなくなります。
A new routing protocol in its complexity is not a product of a parent but of a village, as the author list already shows. However, many more people provided input and fine-combed the specification based on their experience in design, implementation, or application of protocols in IP fabrics. This section will make an inadequate attempt in recording their contribution.
著者リストがすでに示しているように、その複雑さにおける新しいルーティングプロトコルは、親の産物ではなく村の産物です。ただし、より多くの人々が入力を提供し、IPファブリックでのプロトコルの設計、実装、または適用の経験に基づいて仕様を細かく締めました。このセクションでは、貢献を記録するのに不十分な試みが行われます。
Many thanks to Naiming Shen for some of the early discussions around the topic of using IGPs for routing in topologies related to Clos. Russ White is especially acknowledged for the key conversation on epistemology that tied the current asynchronous distributed systems theory results to a modern protocol design presented in this scope. Adrian Farrel, Joel Halpern, Jeffrey Zhang, Krzysztof Szarkowicz, Nagendra Kumar, Melchior Aelmans, Kaushal Tank, Will Jones, Moin Ahmed, Zheng (Sandy) Zhang, and Donald Eastlake provided thoughtful comments that improved the readability of the document and found a good amount of corners where the light failed to shine. Kris Price was first to mention single router, single arm default considerations. Jeff Tantsura helped out with some initial thoughts on BFD interactions while Jeff Haas corrected several misconceptions about BFD's finer points and helped to improve the security section around leaf considerations. Artur Makutunowicz pointed out many possible improvements and acted as a sounding board in regard to modern protocol implementation techniques RIFT is exploring. Barak Gafni formalized the problem of partitioned spine and fallen leaves for the first time clearly on a (clean) napkin in Singapore that led to the very important part of the specification centered around multiple ToF planes and negative disaggregation. Igor Gashinsky and others shared many thoughts on problems encountered in design and operation of large-scale data center fabrics. Xu Benchong found a delicate error in the flooding procedures and a schema datatype size mismatch.
Closに関連するトポロジーのルーティングにIGPを使用するというトピックに関する初期の議論のいくつかについて、Naiming Shenに感謝します。ラス・ホワイトは、現在の非同期分散システム理論の結果をこの範囲で提示された最新のプロトコル設計に結び付けた認識論に関する重要な会話で特に認められています。エイドリアン・ファレル、ジョエル・ハルパーン、ジェフリー・チャン、クルツィシトフ・サルコウィッツ、ナゲンドラ・クマール、メルチオール・エルマンズ、カウシャル・タンク、ウィル・ジョーンズ、モイン・アーメド、Zheng（サンディ）Zhang、ドナルド・イーストレイクは、読みやすさを見つけました。Kris Priceは、最初に単一のルーターであるシングルアームのデフォルトの考慮事項について言及しました。Jeff Tantsuraは、BFDの相互作用に関する最初の考えを手伝いましたが、Jeff HaasはBFDのより細かい点に関するいくつかの誤解を修正し、葉の考慮事項に関するセキュリティセクションの改善に役立ちました。Artur Makutunowiczは、多くの可能性のある改善を指摘し、Riftが調査している最新のプロトコル実装技術に関してサウンドボードとして行動しました。バラク・ガフニは、シンガポールの（きれいな）ナプキンで、脊椎と倒れた葉の問題を初めて明確に形式化し、複数のTOF平面と負の分解を中心とした仕様の非常に重要な部分につながりました。Igor Gashinskyなどは、大規模なデータセンターファブリックの設計と運用で遭遇する問題について多くの考えを共有しました。Xu Benchongは、洪水手順とスキーマデータ型サイズの不一致で繊細なエラーを発見しました。
Too many people to mention provided reviews from many directions in IETF, often pointing to critical defects, sometimes asking for things again that have been removed by one of the previous reviewers as objectionable or superfluous, and many times claiming the document being somewhere on the extremes between too crowded with the obvious and omitting introduction to cryptic concepts everywhere. The result is the best editors could do to find a balance of a document guiding the reader by Section 2 into a specification tight enough to result in interoperable implementations while at the same time introducing enough operational context of IP routable fabrics to guarantee a concise, common language when facing unaccustomed concepts the protocol relies on. In the process, it was important to not end up carrying Aesop's donkey of course, so while the result may not be perceived as perfect by everyone, it should be practically speaking more than sufficient for everyone that ends up using it in the future.
言及するにはあまりにも多くの人がIETFの多くの方向からレビューを提供し、しばしば重大な欠陥を指しており、時には以前のレビュアーの1人によって不快または余分なものとして削除されたものを再び求め、多くの場合、文書がどこでも明白で省略した紹介が混雑している間に極端に混雑していると主張しています。その結果、セクション2で読者を導くドキュメントのバランスを見つけるためにできる最良の編集者ができることができます。同時に、プロトコルが依存している慣れない概念に直面しているときに、IPルーティング可能なファブリックの十分な運用コンテキストを導入すると同時に、同時に、IPルーファブルファブリックの十分な運用コンテキストを導入します。その過程で、もちろんイソップのロバを運ぶことにならないことが重要でした。そのため、結果は誰もが完璧であると認識されないかもしれませんが、将来それを使用するすべての人にとって十分なもの以上のものであるべきです。
Last but not least, Alvaro Retana, John Scudder, Andrew Alston, and Jim Guichard guided the undertaking as ADs by asking many necessary procedural and technical questions that did not only improve the content but also laid out the track towards publication. And Roman Danyliw is mentioned very last but not least for both his painstakingly detailed review and improvement of security aspects of the specification.
最後になりましたが、Alvaro Retana、John Scudder、Andrew Alston、およびJim Guichardは、コンテンツを改善するだけでなく、出版物に向けてトラックを配置した多くの必要な手続き的および技術的な質問をすることで、広告として取り組みを導きました。そして、ローマのダニリウは、彼の骨の折れるほど詳細なレビューと仕様のセキュリティの側面の改善の両方について、非常に最後に言及されています。
This work is a product of a list of individuals who are all to be considered major contributors, independent of the fact whether or not their name made it to the limited author list.
この作業は、すべてが主要な貢献者と見なされる個人のリストであり、その名前が限られた著者リストに到達したかどうかは事実とは無関係です。
Tony Przygienda, Ed.
Juniper
Jordan Head, Ed.
Juniper
Alankar Sharma
Hudson River Trading
Pascal Thubert
Cisco
Bruno Rijsman
Individual
Dmitry Afanasiev
Individual
Don Fedyk
LabN
Alia Atlas
Individual
John Drake
Individual
Ilya Vershkov
Nvidia
Tony Przygienda (editor)
Juniper Networks
1137 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: prz@juniper.net
Jordan Head (editor)
Juniper Networks
1137 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: jhead@juniper.net
Alankar Sharma
Hudson River Trading
United States of America
Email: as3957@gmail.com
Pascal Thubert
Individual
France
Email: pascal.thubert@gmail.com
Bruno Rijsman
Individual
Email: brunorijsman@gmail.com
Dmitry Afanasiev
Yandex
Email: fl0w@yandex-team.ru