Internet Engineering Task Force (IETF) J. Head, Ed.
Request for Comments: 9992 T. Przygienda
Category: Standards Track HPE
ISSN: 2070-1721 June 2026
The Routing in Fat Trees (RIFT) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). The data contained within these KV TIEs can be used for any imaginable purpose.
Routing in Fat Trees (RIFT) プロトコルを使用すると、キーと値のペアを Key-Value Topology Information Element (KV TIE) 内でアドバタイズできます。これらの KV TIE に含まれるデータは、考えられるあらゆる目的に使用できます。
This document specifies behavior for the various Key Types (i.e., Well-Known, Organizationally Unique Identifier (OUI), and Experimental) and a method to structure corresponding values. It also defines a Well-Known Key Sub-Type used for testing tie-breaking behavior.
この文書では、さまざまなキー タイプ (つまり、よく知られている、組織固有の識別子 (OUI)、および実験的) の動作と、対応する値を構造化する方法を指定します。また、タイブレーク動作のテストに使用される Well-Known Key Sub-Type も定義します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9992.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9992 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Requirements Language
2. Key-Value Structure
2.1. Key Sub-Type
2.2. Experimental Key Type
2.3. Well-Known Key Type
2.4. OUI Key Type
3. Design Considerations
3.1. Tie-Breaking Considerations
3.1.1. Southbound KV TIE Tie-Break Sub-Type
3.2. Key Target
3.2.1. Key Target Processing
4. IANA Considerations
4.1. RIFT Well-Known Key Sub-Types
4.1.1. RIFT Well-Known Key Sub-Types Entries
4.2. Expert Review Guidance
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
The Routing in Fat Trees (RIFT) [RFC9692] protocol allows for key/ value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). There are no restrictions placed on the data that is contained in KV TIEs nor what the data is used for.
Routing in Fat Trees (RIFT) [RFC9692] プロトコルでは、キーと値のペアを Key-Value Topology Information Element (KV TIE) 内でアドバタイズできます。KV TIE に含まれるデータやデータの使用目的には制限はありません。
For example, it might be beneficial to advertise overlay protocol state from leaf nodes to the Top-of-Fabric (ToF) nodes. This would make it possible to view the critical state of a fabric-wide service from a single ToF node rather than retrieving and reconciling the same state from multiple leaf nodes.
たとえば、オーバーレイ プロトコルの状態をリーフ ノードからトップオブファブリック (ToF) ノードにアドバタイズすると有益な場合があります。これにより、複数のリーフ ノードから同じ状態を取得して調整するのではなく、単一の ToF ノードからファブリック全体のサービスの重要な状態を表示できるようになります。
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 describes the generic key structure and semantics; Figure 1 further illustrates these components.
このセクションでは、一般的なキーの構造とセマンティクスについて説明します。図 1 は、これらのコンポーネントをさらに示しています。
Section 6.1 of [RFC9692] specifies the use of Thrift [THRIFT] to define the protocol's packet structure. While no explicit restrictions are placed on Key-Value data or what it is used for, it is RECOMMENDED that a serialized Thrift model also be used to define a KV TIE structure for simpler interoperability. For example, [RIFT-AUTO-EVPN] describes this type of implementation.
[RFC9692] のセクション 6.1 では、プロトコルのパケット構造を定義するために Thrift [THRIFT] を使用することが指定されています。Key-Value データやその使用目的には明示的な制限はありませんが、より単純な相互運用性のために、シリアル化された Thrift モデルを KV TIE 構造の定義にも使用することが推奨されます。たとえば、[RIFT-AUTO-EVPN] ではこのタイプの実装について説明しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Type | Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Values (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generic Key-Value Structure
図 1: 一般的なキーと値の構造
where:
ただし：
*Key Type:*
*キーの種類:*
A 1-byte value that identifies the Key Type. Key Type values are taken from the "RIFTCommonKVTypes" registry defined in [RFC9692].
キーのタイプを識別する 1 バイトの値。Key Type の値は、[RFC9692] で定義されている「RIFTCommonKVTypes」レジストリから取得されます。
The range of valid values is 1 - 255 (2^8-1).
有効な値の範囲は 1 ～ 255 (2^8-1) です。
0 is an illegal value and MUST NOT be allocated to or used by any implementation. KV TIEs received with this value MUST be discarded and logged at least once.
0 は不正な値であり、どの実装にも割り当てたり使用したりしてはなりません。この値で受信した KV TIE は破棄され、少なくとも 1 回ログに記録されなければなりません。
*Key Identifier:*
*キー識別子:*
A 3-byte value that identifies the specific key and describes the semantics of any contained values. It SHOULD be unique within the context of the given Key Type.
特定のキーを識別し、含まれる値のセマンティクスを説明する 3 バイトの値。これは、指定されたキー タイプのコンテキスト内で一意である必要があります。
The range of valid values is 1 - 16777215 (2^24-1).
有効な値の範囲は 1 ～ 16777215 (2^24-1) です。
0 is an illegal value and MUST NOT be allocated to or used by any implementation. KV TIEs received with this value MUST be discarded and logged at least once.
0 は不正な値であり、どの実装にも割り当てたり使用したりしてはなりません。この値で受信した KV TIE は破棄され、少なくとも 1 回ログに記録されなければなりません。
*Values:*
*値:*
A variable length value that contains data associated with the Key Identifier. It SHOULD contain 1 or more elements. The semantics (i.e., existence, order, duplication, etc.) of any contained values is governed by the particular key's specification.
キー識別子に関連付けられたデータを含む可変長の値。1 つ以上の要素を含める必要があります (SHOULD)。含まれる値のセマンティクス (つまり、存在、順序、重複など) は、特定のキーの仕様によって決まります。
The Key Sub-Type is a mechanism to further describe the key's semantics. This is illustrated by Figure 2. The Key Sub-Type MUST be used when the Key Type is either Well-Known or Experimental in order to avoid interoperability issues but is OPTIONAL for other Key Types.
キー サブタイプは、キーのセマンティクスをさらに詳細に記述するメカニズムです。これを図 2 に示します。キー サブタイプは、相互運用性の問題を避けるために、キー タイプが既知または実験的な場合に使用しなければなりませんが、他のキー タイプの場合はオプションです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Type | Key Sub-Type | Key Sub-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Values (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generic Key-Value Structure with Key Sub-Type
図 2: キー サブタイプを含む一般的なキーと値の構造
where:
ただし：
*Key Sub-Type:*
*キーのサブタイプ:*
A 1-byte value that identifies the Key Sub-Type that describes the key and its semantics.
キーとそのセマンティクスを説明するキー サブタイプを識別する 1 バイトの値。
The range of valid values is 1 - 255 (2^8-1).
有効な値の範囲は 1 ～ 255 (2^8-1) です。
0 is an illegal value and MUST NOT be allocated to or used by any implementation. KV TIEs received with this value MUST be discarded and logged at least once.
0 は不正な値であり、どの実装にも割り当てたり使用したりしてはなりません。この値で受信した KV TIE は破棄され、少なくとも 1 回ログに記録されなければなりません。
*Key Sub-Identifier:*
*キーのサブ識別子:*
A 2-byte value that identifies the specific key and describes the semantics of any contained values. It SHOULD be unique within the context of the given Key Sub-Type.
特定のキーを識別し、含まれる値のセマンティクスを説明する 2 バイトの値。これは、指定されたキー サブタイプのコンテキスト内で一意である必要があります。
The range of valid values is 1 - 65535 (2^16-1).
有効な値の範囲は 1 ～ 65535 (2^16-1) です。
0 is an illegal value and MUST NOT be allocated to or used by any implementation. KV TIEs received with this value MUST be discarded and logged at least once.
0 は不正な値であり、どの実装にも割り当てたり使用したりしてはなりません。この値で受信した KV TIE は破棄され、少なくとも 1 回ログに記録されなければなりません。
This section describes the Experimental Key Type.
このセクションでは、実験的なキーのタイプについて説明します。
As shown in Figure 3, the Key Type is set to 1, which identifies the Key Type as Experimental. The Experimental Key Type MUST support the use of a Key Sub-Type. The Key Sub-Identifier will be used to identify the specific key and the semantics of any contained values.
図 3 に示すように、キー タイプは 1 に設定されており、これはキー タイプが実験的であることを示します。実験的なキー タイプは、キー サブタイプの使用をサポートしなければなりません (MUST)。キー サブ識別子は、特定のキーと含まれる値のセマンティクスを識別するために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Key Sub-Type | Key Sub-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Experimental Values |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Experimental Key Type
図 3: 実験的なキーのタイプ
This section describes the Well-Known Key Type.
このセクションでは、既知のキーのタイプについて説明します。
As shown in Figure 4, the Key Type is set to 2, which identifies the Key Type as Well-Known. The Well-Known Key Type MUST support the use of a Key Sub-Type. The Key Sub-Identifier will be used to identify the specific key and the semantics of any contained values.
図 4 に示すように、キー タイプは 2 に設定されており、これはキー タイプが Well-Known であることを示します。Well-Known Key Type は、Key Sub-Type の使用をサポートしなければなりません (MUST)。キー サブ識別子は、特定のキーと含まれる値のセマンティクスを識別するために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Key Sub-Type | Key Sub-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Well-Known Values |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Well-Known Key Type
図 4: よく知られているキーのタイプ
This section describes the OUI (vendor-specific) Key Type that an implementation MAY support.
このセクションでは、実装がサポートしてもよい OUI (ベンダー固有) キー タイプについて説明します。
As shown in Figure 5, the Key Type is set to 3, which identifies the Key Type as OUI. The Key Identifier MUST use the implementing organization's reserved OUI [OUI] space to indicate the key and the semantics of any contained values.
図 5 に示すように、キー タイプは 3 に設定されており、これによりキー タイプが OUI として識別されます。キー識別子は、実装組織の予約済み OUI [OUI] スペースを使用して、含まれる値のキーとセマンティクスを示さなければなりません (MUST)。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | OUI Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Specific Values |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OUI Key Type
図 5: OUI キーのタイプ
*NOTE:* Like [RFC9692], this section uses terms to denote directionality, specifically, "northbound" meaning "toward the top of the fabric" and "southbound" meaning "toward the bottom of the fabric".
*注意:* [RFC9692] と同様に、このセクションでは方向性を示す用語、特に「ファブリックの上部に向かう」を意味する「北向き」と「ファブリックの底部に向かう」を意味する「南向き」を使用します。
While no explicit restrictions are placed on how Key-Value elements are used, it is of critical importance to consider these details. For example, they should not be used to carry topology information used by RIFT itself to perform distributed computations as it would likely lead to race conditions in convergence, oscillations, and/or other suboptimal behaviors.
Key-Value 要素の使用方法に明示的な制限はありませんが、これらの詳細を考慮することが非常に重要です。たとえば、分散計算を実行するために RIFT 自体が使用するトポロジー情報を運ぶためには使用しないでください。これは、収束、発振、その他の次善の動作で競合状態が発生する可能性があるためです。
It is possible that deployments may have nodes that support a given KV TIE and others that do not. In this scenario, nodes that receive KV TIEs that they don't recognize (e.g., an unknown Key Type) will flood them normally as specified in Section 6.3.4 of [RFC9692].
デプロイメントには、特定の KV TIE をサポートするノードとサポートしないノードが存在する可能性があります。このシナリオでは、認識できない KV TIE (例: 不明なキー タイプ) を受信したノードは、[RFC9692] のセクション 6.3.4 に規定されているように、通常どおりそれらをフラッディングします。
New Key Types offer 3 bytes of key identification space, and new Well-Known Key Sub-Types offer 2 bytes. When defining how key identification space is used, it is important to consider how much space is actually necessary in order to help ensure efficient use of available registry values.
新しいキー タイプは 3 バイトのキー識別スペースを提供し、新しい Well-Known Key サブタイプは 2 バイトを提供します。キー識別スペースの使用方法を定義するときは、使用可能なレジストリ値を効率的に使用するために実際にどのくらいのスペースが必要かを考慮することが重要です。
In cases where KV TIEs are flooded southbound, mechanisms SHOULD be implemented in order to avoid network-wide flooding where possible. Key Targets (defined in Section 3.2) are one such mechanism.
KV TIE が南方向にフラッディングされる場合、ネットワーク全体のフラッディングを可能な限り回避するためのメカニズムを実装する必要があります (SHOULD)。キー ターゲット (セクション 3.2 で定義) は、そのようなメカニズムの 1 つです。
Section 6.8.5.1 of [RFC9692] specifies that only one KV TIE is selected when identical keys are received from multiple northbound neighbors. Therefore, it is RECOMMENDED that implementations ensure that nodes determine Values within KV TIEs independently in a consistent fashion in order to prevent scenarios where multiple ToFs advertise KV TIEs with identical keys but differing Values. In such scenarios, node(s) will select the KV TIE with the highest System ID, which may lead to unintended effects. Even with a robust implementation, operators should also consider that this may still happen under failure conditions, for example, multiple ToFs becoming split-brained.
[RFC9692] のセクション 6.8.5.1 では、複数のノースバウンドネイバーから同一のキーを受信した場合、KV TIE を 1 つだけ選択することが指定されています。したがって、複数の ToF がキーは同一だが値が異なる KV TIE をアドバタイズするシナリオを防ぐために、ノードが一貫した方法で KV TIE 内の値を独立して決定することを実装で保証することが推奨されます。このようなシナリオでは、ノードは最も高いシステム ID を持つ KV TIE を選択するため、意図しない影響が生じる可能性があります。たとえ堅牢な実装であっても、運用者は、複数の ToF がスプリットブレイン化するなど、障害状況下では依然としてこの問題が発生する可能性があることも考慮する必要があります。
This section reserves a Key Sub-Type from the "RIFT Well-Known Key Sub-Types" registry.
このセクションでは、「RIFT Well-Known Key Sub-Types」レジストリからキー サブタイプを予約します。
This Key-Value pair contains information that allows implementations to test and verify proper tie-breaking behavior for the Southbound Keystore. All implementations MUST support this Sub-Type.
このキーと値のペアには、実装でサウスバウンド キーストアの適切なタイブレーク動作をテストおよび検証できるようにする情報が含まれています。すべての実装はこのサブタイプをサポートしなければなりません (MUST)。
All implementations SHOULD use the Thrift model defined in Section 3.1.1.1.
すべての実装は、セクション 3.1.1.1 で定義された Thrift モデルを使用する必要があります (SHOULD)。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 127 | Key Sub-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (System ID, |
| Level) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Southbound Tie-Break Sub-Type
図 6: 南行きタイブレークのサブタイプ
where:
ただし：
*System ID:*
*システムID:*
A REQUIRED value indicating the node's unique System ID.
ノードの一意のシステム ID を示す必須の値。
*Level:*
*レベル：*
A RECOMMENDED value indicating the node's level.
ノードのレベルを示す RECOMMENDED 値。
This section contains the normative Thrift model to support testing southbound Key-Value tie-breaking based on System ID. Per Section 7 of [RFC9692], all signed values MUST be interpreted as unsigned values.
このセクションには、システム ID に基づいたサウスバウンドの Key-Value タイブレークのテストをサポートする標準的な Thrift モデルが含まれています。[RFC9692] のセクション 7 に従って、すべての符号付き値は符号なし値として解釈されなければなりません (MUST)。
include "common.thrift"
namespace py southbound_kv
namespace rs models
const i8 GlobalSystemIdentifierKV = 127
/** simple type to test correct tie-breaking based on system ID */
struct SystemIdentifierKV {
1: required common.SystemIDType system_id,
2: optional common.LevelType level,
}
Figure 7: RIFT Common Schema for Southbound Key-Value Tie-Break Key Sub-Type
図 7: サウスバウンド キーと値のタイブレーク キー サブタイプの RIFT 共通スキーマ
The Key Target is an OPTIONAL 64-bit value that identifies group(s) of node(s) that are intended to receive a given KV TIE. Key Targets have a valid range of 0 - 18446744073709551615 (2^64-1).
キー ターゲットは、特定の KV TIE を受信することを目的としたノードのグループを識別するオプションの 64 ビット値です。キー ターゲットの有効範囲は 0 ～ 18446744073709551615 (2^64-1) です。
The Thrift model defined in Section 7.2 of [RFC9692] SHOULD be used for Key Target implementation.
[RFC9692] のセクション 7.2 で定義されている Thrift モデルは、Key Target の実装に使用されるべきです(SHOULD)。
Figure 8 illustrates the format.
図 8 にフォーマットを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Target |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Type | Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Values |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Key Target Format
図 8: 主要なターゲットの形式
A value of all 0s indicates that every node is intended to receive this KV TIE and MUST NOT be used for any other reason.
すべて 0 の値は、すべてのノードがこの KV TIE を受信することを目的としており、他の理由で使用してはいけないことを示します。
A value of all 1s indicates that all leaf nodes are intended to receive this KV TIE and MUST NOT be used for any other reason.
すべて 1 の値は、すべてのリーフ ノードがこの KV TIE を受信することを目的としており、他の理由で使用してはいけないことを示します。
Any other value MUST be derived from the following normative algorithm. Note that while the algorithm is shown using example code written in [Rust], this document does not mandate the use of any particular language for implementation.
他の値は、次の規範的なアルゴリズムから導出されなければなりません。アルゴリズムは [Rust] で書かれたコード例を使用して示されていますが、このドキュメントでは実装に特定の言語の使用を強制するものではないことに注意してください。
<CODE BEGINS>
/// random seeds used in algorithms to increase entropy
pub const RANDOMSEEDS: [UnsignedSystemID; 3] = [
67438371571u64,
37087353685,
88675895388,
];
/// given a system ID delivers the bits set by the according
/// Bloom Filter in the southbound key value target.
pub (crate) fn target2bits(target: UnsignedSystemID) ->
KeyValueTargetType {
(0 as usize .. 3)
.map(|s| {
let rot = (target ^ RANDOMSEEDS[s]).rotate_left(s as _);
rot.to_ne_bytes().iter().fold(0,
|v: u8, nv| v.rotate_right(4) ^ *nv) % 64
})
.fold(0, |v, nv| v | (1 << nv))
}
<CODE ENDS>
Figure 9: Key Target Standard Algorithm
図 9: 主要なターゲットの標準アルゴリズム
Nodes that support the processing of Key Targets MUST only do so on KV TIEs in the southbound direction. Key Targets MUST NOT be present on KV TIEs in the northbound direction and are ignored and logged at least once.
キーターゲットの処理をサポートするノードは、サウスバウンド方向の KV TIE でのみサポートしなければなりません (MUST)。キー ターゲットはノースバウンド方向の KV TIE 上に存在してはならず、無視され、少なくとも 1 回ログに記録されます。
Nodes that do not support the processing of Key Targets MUST continue to send KV TIEs to all nodes in the appropriate direction. Additionally, Key Targets MUST be preserved when KV TIEs are re-originated in the southbound direction.
キーターゲットの処理をサポートしていないノードは、適切な方向ですべてのノードに KV TIE を送信し続けなければなりません (MUST)。さらに、KV TIE が南向きに再発信される場合、キー ターゲットは保存されなければなりません。
There are several reasons a node may select a different KV TIE. For example, the KV TIE is considered newer due to the sequence number incrementing, a change in the original tie-breaking result between multiple KV TIEs, or a loss of northbound connectivity to the node that advertised the previously selected KV TIE.
ノードが異なる KV TIE を選択する理由はいくつかあります。たとえば、シーケンス番号の増加、複数の KV TIE 間の元のタイブレーク結果の変更、または以前に選択された KV TIE をアドバタイズしたノードへのノースバウンド接続の喪失により、KV TIE はより新しいと見なされます。
Consider a case where Leaf-1, Leaf-2, and Leaf-3 are members of a group of nodes represented by Key Target KT1. If Leaf-2 is removed from that group and a newer instance of the KV TIE needs to be flooded, Leaf-2 will have to maintain the older KV TIE in the Link State Database (LSDB) until the lifetime expires. This could lead to suboptimal behavior in the fabric.
リーフ 1、リーフ 2、およびリーフ 3 がキー ターゲット KT1 によって表されるノードのグループのメンバーである場合を考えてみましょう。リーフ 2 がそのグループから削除され、KV TIE の新しいインスタンスをフラッディングする必要がある場合、リーフ 2 は有効期限が切れるまでリンク ステート データベース (LSDB) 内の古い KV TIE を維持する必要があります。これにより、ファブリックで次善の動作が発生する可能性があります。
If the new KV TIE being flooded does not include the previous Key Target value, then implementations SHOULD flood the newer instance of the KV TIE with a very short lifetime to nodes that belonged to the previous Key Target but not the new Key Target.
フラッディングされる新しい KV TIE に以前のキー ターゲット値が含まれていない場合、実装は、非常に短いライフタイムを持つ KV TIE の新しいインスタンスを、以前のキー ターゲットには属しているが新しいキー ターゲットには属していないノードにフラッディングする必要があります (SHOULD)。
Per [RFC8126], IANA has created the "RIFT Well-Known Key Sub-Types" registry in the "Routing in Fat Trees (RIFT)" registry group at <https://www.iana.org/assignments/rift>.
[RFC8126] に従って、IANA は <https://www.iana.org/assignments/rift> の「Routing in Fat Trees (RIFT)」レジストリ グループに「RIFT Well-Known Key Sub-Types」レジストリを作成しました。
IANA has updated the "RIFTCommonKVTypes" registry based on values defined in Section 2 of this document, and this document has been added as a reference.
IANA は、この文書のセクション 2 で定義された値に基づいて「RIFTCommonKVTypes」レジストリを更新し、この文書は参照として追加されました。
Experts reviewing requests for new values to either the "RIFTCommonKVTypes" registry or the "RIFT Well-Known Key Sub-Types" registry MUST consider the items in "Expert Review Guidance" Section 4.2.
「RIFTCommonKVTypes」レジストリまたは「RIFT Well-Known Key Sub-Types」レジストリへの新しい値のリクエストをレビューする専門家は、「専門家レビュー ガイダンス」セクション 4.2 の項目を考慮する必要があります。
IANA has created the following registry:
IANA は次のレジストリを作成しました。
Registry Name:
レジストリ名:
RIFT Well-Known Key Sub-Types
RIFT のよく知られた主要なサブタイプ
Registration Procedures:
登録手順:
Expert Review
専門家のレビュー
Description:
説明：
Well-Known Key Sub-Types registry for the RIFT protocol.
RIFT プロトコルの Well-Known Key Sub-Types レジストリ。
Reference:
参照：
RFC 9992
RFC 9992
IANA has registered the following values in the "RIFT Well-Known Key Sub-Types" registry.
IANA は、「RIFT Well-Known Key Sub-Types」レジストリに次の値を登録しました。
+=========+============+============================+===========+
| Value | Name | Description | Reference |
+=========+============+============================+===========+
| 0 | Illegal | Not allowed. | RFC 9992 |
+---------+------------+----------------------------+-----------+
| 1-126 | Unassigned |
+---------+------------+----------------------------+-----------+
| 127 | Southbound | Used for testing/verifying | RFC 9992 |
| | Tie-Break | Southbound Keystore tie- | |
| | Sub-Type | breaking behavior. | |
+---------+------------+----------------------------+-----------+
| 128-255 | Unassigned |
+---------+-----------------------------------------------------+
Table 1: RIFT Well-Known Key Sub-Types Entries
表 1: RIFT のよく知られている主要なサブタイプのエントリ
Experts reviewing requests for values from the "RIFTCommonKVTypes" registry or the "RIFT Well-Known Key Sub-Types" registry are responsible for the following:
「RIFTCommonKVTypes」レジストリまたは「RIFT Well-Known Key Sub-Types」レジストリからの値のリクエストをレビューする専門家は、次の責任を負います。
1. Ensuring that the supporting documentation accompanying the request properly defines how Key Identifiers and/or Key Sub-Identifiers are used (e.g., as a boolean, an explicit value, an auto-derived value, etc.).
1. リクエストに付随するサポート文書が、キー識別子および/またはキーサブ識別子の使用方法（ブール値、明示的な値、自動導出値などとして）を適切に定義していることを確認します。
2. Ensuring that the supporting documentation provides normative Thrift model(s) (if applicable).
2. サポート文書が標準的な Thrift モデルを提供していることを確認します (該当する場合)。
3. Ensuring that any work originating outside the IETF does not conflict with any work that is already published or in active pursuit of being published.
3. IETF 以外で作成された作品が、すでに出版されている作品、または出版を積極的に目指している作品と競合しないことを保証します。
This document introduces no new security concerns to RIFT or other specifications referenced in this document given that the KV TIEs are already extensively secured by the RIFT [RFC9692] protocol specification itself.
KV TIE が RIFT [RFC9692] プロトコル仕様自体によってすでに広範に保護されていることを考慮すると、このドキュメントでは、RIFT またはこのドキュメントで参照されている他の仕様に新たなセキュリティ上の懸念は導入されません。
[OUI] 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>.
[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>.
[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>.
[RFC9692] Przygienda, T., Ed., Head, J., Ed., Sharma, A., Thubert,
P., Rijsman, B., and D. Afanasiev, "RIFT: Routing in Fat
Trees", RFC 9692, DOI 10.17487/RFC9692, April 2025,
<https://www.rfc-editor.org/info/rfc9692>.
[Rust] Rust Foundation, "The Rust Reference",
<https://doc.rust-lang.org/reference/>.
[THRIFT] Apache Software Foundation, "Thrift Language
Implementation and Documentation", commit 66d8976,
<https://github.com/apache/thrift/tree/0.15.0/doc>.
[RIFT-AUTO-EVPN]
Head, J., Przygienda, T., and W. Lin, "RIFT Auto-EVPN",
Work in Progress, Internet-Draft, draft-ietf-rift-auto-
evpn-06, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rift-
auto-evpn-06>.
Thanks to Italo Busi for his very thoughtful review that yielded an improved spec.
仕様の改善をもたらした非常に思慮深いレビューをしてくれた Italo Busi に感謝します。
Jordan Head (editor)
HPE
1701 East Mossy Oaks Road
Spring, TX 77389
United States of America
Email: jordan.head@hpe.com
Tony Przygienda
HPE
1701 East Mossy Oaks Road
Spring, TX 77389
United States of America
Email: antoni.przygienda@hpe.com