Summary

  • RFC 9992 gives RIFT an interoperable structure for Key/Value TIEs, including Experimental, Well-Known and OUI namespaces; it does not give an arbitrary value authority over RIFT’s own distributed route computation.
  • Flooding, an intended Key Target and deterministic tie-breaking prove different things. None proves that a node understood a value, adopted its policy, programmed a FIB or delivered a packet.
  • A defensible fabric keeps semantic registration, origin, selection, local interpretation, installation, withdrawal and outcome as separately owned and replayable decisions.

The word selected is doing dangerous work in the imagined failure. A leaf has two incoming advertisements with an identical key. RIFT’s southbound keystore chooses one according to the protocol’s selection rule. The result prevents indecision from spreading forever. It does not settle the reason why the two values diverged, determine whether their payload is safe to consume, or turn the losing source into a lie.

RFC 9992, published on the IETF Standards Track in June 2026, defines the structure and processing of Key/Value Topology Information Elements in Routing in Fat Trees. The base protocol, RFC 9692, exchanges TIEs between neighbouring RIFT nodes. RFC 9992 makes a separate extension surface legible: a key type, an identifier and variable values, with a subtype where the namespace requires it.

That is a valuable minimum common specification. It lets different implementations locate a meaning, reject illegal identifiers, preserve an unknown object in the exchange and build a specification for the values. It is not a universal control plane disguised as a small field.

A portable envelope is not a network fact

RFC 9992 deliberately permits values to serve any imaginable purpose. A fabric might carry overlay state, a bounded automation signal or a future operational function. The flexibility is paired with a warning that should be read as a governance boundary: KV TIEs should not carry topology information that RIFT itself uses for distributed computations. Doing so can create convergence races, oscillation or suboptimal behaviour.

The warning rules out a tempting shortcut. An operator sees a working flooding mechanism and assumes that a payload can become another source of route truth. But RIFT's own topology exchange has defined lifetimes, types, adjacency conditions and computations. A locally invented key may be well encoded while remaining semantically unfit to steer those calculations.

This gives a simple chain of questions. Who owns the key’s meaning? Which version of the model is valid? Which node may originate it? Is an unknown receiver obliged only to flood it, or may it interpret it? What local policy permits interpretation? Which controller, route process or forwarding manager owns the next transition? What observation confirms that the transition happened? A single affirmative at the first question cannot answer the later ones.

The numeric boundaries matter too. Key Type and Key Identifier zero are illegal. A receiver must discard and log such a TIE at least once. Experimental and Well-Known key types use a required subtype so their semantics do not collide; an optional OUI type identifies a vendor namespace through its OUI space. These measures constrain syntax and allocation. They do not approve a business purpose, a rollout or an action in every fabric.

Propagation, targeting and adoption are three different verbs

A node that does not recognise a KV TIE can still flood it normally under the RIFT rules. That property protects distribution and incremental deployment. It is also why a topology map that shows an object moving through the fabric is weak evidence of adoption. The node may have relayed bytes it could not parse. A later node may parse them but reject their version. A third may accept the object into a local store yet decline to change a controller or a route.

Key Target adds another useful, limited mechanism. It identifies groups intended to receive a southbound KV TIE. All-zero means every node; all-one means all leaves; other targets use the prescribed calculation. The target must not appear northbound. Nodes without Key Target processing continue forwarding appropriate TIEs to all nodes. Targeting therefore expresses an intended audience. It is not proof of recipient capability or an enforceable policy grant.

The same restraint applies to the standard's explicit tie-breaking guidance. RFC 9992 recommends independently consistent determination of values because identical keys with different values from multiple northbound neighbours result in a highest-System-ID selection. A partitioned pair of ToFs can therefore produce a deterministic winner with an unintended effect. Determinism keeps the protocol moving. It does not explain which value is causally correct, whether both sources were authorised, or whether a condition already ceased to exist.

An operational record must retain the contenders: origin system IDs, receipt time, direction, target, key and subtype, value fingerprint, lifetimes, selected result and the reason that selection applied. Without the rejected value, an incident review sees a clean winner and misses the divergence that made the choice meaningful.

Registration is stewardship, not a delegation of command

RFC 9992 creates the IANA RIFT Well-Known Key Sub-Types registry with Expert Review. Reviewers must require supporting documentation that explains identifiers and their use and, where applicable, normative Thrift models. The current IANA RIFT registry reserves zero as illegal and lists the Southbound Tie-Break Sub-Type at 127.

That governance is important precisely because it is narrow. IANA can keep names from colliding and reviewers can insist on defined semantics. Neither determines an enterprise’s origin controls, a particular leaf’s admission policy, the safety of a payload, the consequences of a false value or a rollback decision. A registered value is a publicly managed label, not a signed warrant to change forwarding.

Likewise, RFC 9719 gives RIFT an NMDA-compatible management model. Intended configuration, observed TIEs, a selected keystore value, computed routes, installed hardware state and service outcome remain different records. Reading one data tree or one controller confirmation as all six collapses the very evidence needed during an outage.

Heng Lu’s running-code principle is useful here as an editorial lens, not an IETF requirement. Inspect the actual originator, protocol trace, receiver, local policy, control-plane decision, FIB programming, counters and probes. His account of reality layers explains why a correctly formatted declaration cannot become proof at a later layer merely by travelling through the network.

RFC 9992 is strongest when treated this way: it standardizes a disciplined carrier and leaves the local decision that follows it where accountability can still be located.