RIFT KV TIEs: Routing in Fat Trees (RIFT) Key/Value Topology Information Elements Structure and Processing
How RIFT routers label and structure the free-form key/value data they flood through a fat-tree fabric.
Head, J., Ed. and T. Przygienda, "Routing in Fat Trees (RIFT) Key/Value Topology Information Elements Structure and Processing", RFC 9992, DOI 10.17487/RFC9992, June 2026, <https://www.rfc-editor.org/info/rfc9992>.
@misc{rfc9992,
series = {Request for Comments},
number = 9992,
howpublished = {RFC 9992},
publisher = {RFC Editor},
doi = {10.17487/RFC9992},
url = {https://www.rfc-editor.org/info/rfc9992},
author = {J. Head and T. Przygienda},
title = {{Routing in Fat Trees (RIFT) Key/Value Topology Information Elements Structure and Processing}},
pagetotal = 12,
year = 2026,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Head, Ed.
Request for Comments: 9992 T. Przygienda
Category: Standards Track HPE
ISSN: 2070-1721 June 2026
Routing in Fat Trees (RIFT) Key/Value Topology Information Elements
Structure and Processing
Abstract
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.
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.
Status of This Memo
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.
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.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
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
1. Introduction
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.
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.
1.1. Requirements Language
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.
2. Key-Value Structure
This section describes the generic key structure and semantics;
Figure 1 further illustrates these components.
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.
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
where:
*Key Type:*
A 1-byte value that identifies the Key Type. Key Type values
are taken from the "RIFTCommonKVTypes" registry defined in
[RFC9692].
The range of valid values is 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.
*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.
The range of valid values is 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.
*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.
2.1. Key Sub-Type
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.
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
where:
*Key Sub-Type:*
A 1-byte value that identifies the Key Sub-Type that describes
the key and its semantics.
The range of valid values is 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.
*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.
The range of valid values is 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.
2.2. Experimental Key Type
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.
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
2.3. Well-Known Key Type
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.
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
2.4. OUI Key Type
This section describes the OUI (vendor-specific) Key Type that an
implementation MAY support.
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.
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
3. Design Considerations
| *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".
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.
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].
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.1. Tie-Breaking Considerations
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.
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.
3.1.1. Southbound KV TIE Tie-Break Sub-Type
This section reserves a Key Sub-Type from the "RIFT Well-Known Key
Sub-Types" registry.
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.
All implementations SHOULD use the Thrift model defined in
Section 3.1.1.1.
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
where:
*System ID:*
A REQUIRED value indicating the node's unique System ID.
*Level:*
A RECOMMENDED value indicating the node's level.
3.1.1.1. Thrift Models
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.
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
3.2. Key Target
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).
The Thrift model defined in Section 7.2 of [RFC9692] SHOULD be used
for Key Target implementation.
Figure 8 illustrates the format.
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
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.
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.
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.
<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
3.2.1. Key Target Processing
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.
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.
3.2.1.1. Purging/Rollover
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.
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.
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.
4. IANA Considerations
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>.
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.
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.
4.1. RIFT Well-Known Key Sub-Types
IANA has created the following registry:
Registry Name:
RIFT Well-Known Key Sub-Types
Registration Procedures:
Expert Review
Description:
Well-Known Key Sub-Types registry for the RIFT protocol.
Reference:
RFC 9992
4.1.1. RIFT Well-Known Key Sub-Types Entries
IANA has registered the following values in the "RIFT Well-Known Key
Sub-Types" registry.
+=========+============+============================+===========+
| 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
4.2. Expert Review Guidance
Experts reviewing requests for values from the "RIFTCommonKVTypes"
registry or the "RIFT Well-Known Key Sub-Types" registry are
responsible for the following:
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.).
2. Ensuring that the supporting documentation provides normative
Thrift model(s) (if applicable).
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.
5. Security Considerations
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.
6. References
6.1. Normative References
[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>.
6.2. Informative References
[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>.
Acknowledgements
Thanks to Italo Busi for his very thoughtful review that yielded an
improved spec.
Authors' Addresses
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
AI ELI5
On this page
§1Why Key/Value Data in RIFT
The Routing in Fat Trees protocol (RIFT, RFC 9692) can advertise key/value pairs inside Key-Value Topology Information Elements (KV TIEs). The RFC places no restrictions on what that data holds or what it is used for.
The motivating example is overlay protocol state. Leaf nodes could advertise it up to the Top-of-Fabric (ToF) nodes, so an operator can see the critical state of a fabric-wide service from a single ToF node instead of collecting and reconciling it from many leaves.
What the RFC adds is structure: how keys are named, how values are laid out, and a few behaviors that make interoperability simpler.
Routers sometimes want to pass along extra notes, like a sticky note on a shared fridge. This RFC makes sure everyone writes the notes in the same tidy way.
§2The Key-Value Structure
Every KV TIE starts with a Key Type, a 1-byte value taken from the RIFTCommonKVTypes registry defined in RFC 9692. Next comes a 3-byte Key Identifier that names the specific key and says what the values mean. Then come the variable-length Values.
Valid Key Types run from 1 to 255, and valid Key Identifiers from 1 to 16777215. Zero is illegal in both fields: it MUST NOT be allocated or used, and a KV TIE received with a zero there MUST be discarded and logged at least once. The Key Identifier SHOULD be unique within its Key Type, and the Values SHOULD hold one or more elements.
The RFC does not limit what the values contain, but it RECOMMENDS defining a KV TIE structure with a serialized Thrift model, as RFC 9692 does for the protocol's own packets, for simpler interoperability.
Each note has a type sticker, a number on the label and then the message. Zero is never a real number on the label, so a note with zero gets thrown away.
§3Key Sub-Types and the Three Key Types
A Key Sub-Type splits the 3-byte identifier into a 1-byte Key Sub-Type (1 to 255) and a 2-byte Key Sub-Identifier (1 to 65535). Zero is illegal in both, with the same discard-and-log rule. The sub-type MUST be used with the Well-Known and Experimental key types and is OPTIONAL for others.
- Experimental (Key Type 1): MUST support a Key Sub-Type; the Key Sub-Identifier selects the specific key.
- Well-Known (Key Type 2): MUST support a Key Sub-Type; sub-types come from a new IANA registry.
- OUI (Key Type 3): vendor-specific, and an implementation MAY support it. The Key Identifier MUST use the implementing organization's reserved OUI space.
There are three kinds of labels: one for experiments, one for everyone's agreed-upon notes and one where a company uses its own personal code so it never clashes with others.
- 1Experimental — Uses a Key Sub-Type; Key Sub-Identifier selects the key.
- 2Well-Known — Uses a Key Sub-Type from the IANA registry.
- 3OUI — Vendor-specific; Key Identifier uses the organization's OUI space.
§4Design Considerations and Tie-Breaking
Because KV data is unrestricted, the RFC warns that it should not carry topology information that RIFT itself uses for distributed computations. That would likely cause race conditions in convergence, oscillations or other suboptimal behavior.
Nodes that do not recognize a KV TIE, for example because of an unknown Key Type, flood it normally as specified in Section 6.3.4 of RFC 9692. Mixed deployments are therefore fine.
When identical keys arrive from several northbound neighbors, only one KV TIE is selected, and the node picks the one with the highest System ID. To avoid surprises, implementations are RECOMMENDED to compute Values independently but consistently, so several ToFs do not advertise the same key with different values. The RFC notes this can still happen under failure, for example if multiple ToFs become split-brained.
Southbound KV TIE flooding SHOULD avoid network-wide flooding where possible. Key Targets are one mechanism for that.
If two parents send the same note with different words, the child keeps the note from the parent with the biggest ID number. So parents should agree before writing.
§5The Southbound Tie-Break Sub-Type and Key Targets
The RFC reserves Well-Known Key Sub-Type 127 for testing and verifying tie-breaking of the Southbound Keystore. All implementations MUST support it. Its value carries a REQUIRED System ID and a RECOMMENDED node level, and implementations SHOULD use the normative Thrift model given in the RFC.
A Key Target is an OPTIONAL 64-bit value that identifies the group of nodes meant to receive a KV TIE. All zeros means every node, and all ones means all leaf nodes; neither may be used for any other purpose. Any other value MUST be derived with the normative algorithm, shown in Rust, which sets bits in the 64-bit value from the System ID using three fixed random seeds, in the manner of a Bloom filter.
Key Targets apply only to southbound KV TIEs. They MUST NOT appear northbound, where they are ignored and logged at least once. Nodes that do not process Key Targets keep sending KV TIEs to all nodes in that direction, and Key Targets MUST be preserved when a KV TIE is re-originated southbound.
If a node leaves a Key Target group and the new KV TIE no longer includes the previous Key Target, implementations SHOULD flood the newer instance with a very short lifetime to the nodes that belonged to the old group, so stale copies do not linger in the link-state database.
A Key Target is like a mailing list code on a note. Only the routers whose codes match need to read it, and when someone leaves the list, they are told to throw their old copy away quickly.
§6IANA Registries and Expert Review
IANA created the RIFT Well-Known Key Sub-Types registry, using the Expert Review procedure, and updated the RIFTCommonKVTypes registry with the values from this document. In the sub-type registry, 0 is Illegal, 127 is the Southbound Tie-Break Sub-Type, and 1-126 and 128-255 are unassigned.
Experts reviewing requests for either registry must check three things: that the request properly defines how identifiers are used (for example as a boolean, an explicit value or an auto-derived value), that it supplies normative Thrift models where applicable, and that work originating outside the IETF does not conflict with work already published or being published.
There is an official list of label numbers. Before a new one is added, an expert checks that it is clearly explained and does not clash with anyone else's.
§7Security Considerations
The RFC says it introduces no new security concerns to RIFT or the specifications it references, because KV TIEs are already extensively secured by the RIFT specification itself (RFC 9692).
The notes already travel in the same locked mailbag as everything else in RIFT, so this RFC adds no new locks to worry about.