RIFT: Routing in Fat Trees
Extracted elements (31)
In a partitioned ToF fabric, positive disaggregation alone cannot solve the fallen leaf problem because ToF planes are isolated; disaggregation from one plane does not reach ToP switches in another plane. Negative, transitive disaggregation is required and must propagate all the way to the leaf nodes, which are the level that selects the ToF plane for each packet.
RIFT's computation principles (southbound forwarding always preferred) guarantee valley-free forwarding: packets may reverse direction from northbound to southbound, and may traverse horizontal links at most once during the northbound phase. This eliminates the need to tie-break identical reachability from multiple directions, enabling loop-free use of all available fabric paths.
RIFT uses a hybrid approach: link-state flooding northbound so each level obtains full topology of levels below it, and distance-vector propagation southbound where each node generates and floods a default route only one hop south. This hybrid minimizes control-plane state, enables natural address aggregation, and supports loop-free valley-free forwarding.
RIFT ZTP requires only ToF nodes to be explicitly configured as such; all other nodes (spines and leaves) derive their level automatically through LIE exchange. This zero-configuration approach allows large fabrics to be provisioned with minimal human intervention.
To allow all ToF nodes across planes to share the same north topology database—required for transitive negative disaggregation to heal fallen leaves—ToF nodes in multi-plane fabrics are interconnected by bidirectional inter-plane rings, reserving at least two ports per ToF node. Rings are preferred over other topologies because they require fewer cables and have shorter flooding paths without single points of failure.
When local and remote neighbors run different address families, RIFT falls back to the intersection: a dual-stack local node adjacent to an IPv6-only remote will form a ThreeWay adjacency and exchange TIEs over IPv6 only. If IPv4 and IPv6 LIEs advertise conflicting _ipv4_forwarding_capable_ flags, protocol behavior is unspecified. Tables 1 and 2 in Section 6.2 enumerate all combinations.
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 regardless of the address family they arrive on.
Any attempt to transition from a state on reception of an event where no FSM action is specified MUST be considered an unrecoverable error; the protocol MUST reset all adjacencies, discard all state, and flush all flooding queues.
Any LIE packet received on an address that is neither the well-known nor the configured multicast or broadcast address MUST be discarded.
Because the LIE source address may not uniquely identify the peer in unnumbered or link-local address cases, response transmission MUST occur over the same interface on which the LIEs were received. An implementation MUST be ready to accept TIEs on all addresses it used as LIE source addresses.
If a link in _ThreeWay_ state needs to stop supporting an address family, change local addresses, or disable IPv4 forwarding, it MUST tear down and rebuild the adjacency, and MUST remove all state stored about the remote side including LIE source addresses.
If IPv4 forwarding is supported on an interface, _ipv4_forwarding_capable_ MUST be set to true in all LIEs advertised from that interface. A node sending IPv4 LIEs MUST set this flag to true. In the absence of IPv4 LIEs with this flag set, a node MUST forward IPv4 packets using IPv6 gateways discovered on IPv6-only links that advertise this capability.
LIEs MUST be sent with an IPv4 TTL or IPv6 Hop Limit of either 1 or 255 to prevent RIFT information from reaching beyond a single Layer 3 next hop. TTL 1 is the more logical choice for link-local multicast addresses, as TTL 255 may cause drops in some environments.
LIEs SHOULD be sent with network control precedence unless an implementation is prevented from doing so (RFC2474).
A Flood Repeater (FR), also called a flood leader, is a northbound neighbor designated by a node to relay northbound TIEs further north. This mechanism prunes redundant flooding over a sufficient subset of links to minimize control-plane overhead.
A Key-Value (KV) TIE carries arbitrary key-value pairs and can be used to distribute non-topology-related information within the protocol after convergence, for example to bootstrap higher-level functions such as operational telemetry.
A Link Information Element (LIE) is exchanged on all links running RIFT to auto-discover neighbors, negotiate Zero Touch Provisioning parameters, and detect miscabling. LIEs are sent over well-known IPv4 multicast (RFC2365) or IPv6 link-local multicast (RFC4291) to a destination UDP port defined in the schema.
A Topology Information Element (TIE) is the fundamental unit of topology exchange in RIFT. Every TIE has a direction (North or South) and a type (Node or Prefix); North TIEs carry link-state descriptions of lower levels while South TIEs carry default routes and node descriptions from higher levels.
Positive disaggregation is originated by a router that can still reach an impacted prefix and is not transitive; it causes receivers to install a more-specific route toward the advertising node. Negative disaggregation is transitive, propagated south when all possible routes are advertised as negative exceptions, effectively punching a hole in the aggregated default route to exclude unreachable next hops.
The Security Envelope wraps every RIFT UDP packet and optionally provides integrity protection via security associations defined in Section 10.2. It allows validation and modification of critical fields without full Thrift deserialization, improving performance and security.
TIDE (Topology Information Description Element) carries descriptors of TIEs stored by a node; TIRE (Topology Information Request Element) carries TIDE descriptors to confirm received TIEs or request missing ones. Together they drive RIFT's database synchronization protocol.
IANA has assigned a well-known IPv4 multicast address and UDP port numbers for RIFT LIE and TIE exchange, registered under the 'Routing in Fat Trees (RIFT)' group. These assignments enable plug-and-play neighbor discovery without per-link configuration.
IANA has created more than 30 sub-registries under 'Routing in Fat Trees (RIFT)' corresponding to individual Thrift schema structures (e.g., RIFTEncodingLIEPacket, RIFTEncodingTIEHeader, RIFTCommonTIETypeType). Each registry records valid field values for the corresponding schema element, enabling future extensibility via IANA allocation.
IANA has created the 'RIFT Security Algorithms' registry under the 'Routing in Fat Trees (RIFT)' registry group. This registry records algorithm identifiers used in the RIFT security envelope to authenticate packets.
An attacker can mount a DoS by flooding a node with TIEs bearing valid-looking but forged origin fingerprints, forcing expensive cryptographic verification. Section 9.8 notes that rate-limiting TIE processing and validating origin fingerprints early in the processing pipeline mitigates this risk.
An attacker that can forge the outer security envelope fingerprint can potentially cause a node to accept malicious TIEs. The outer fingerprint covers the UDP payload before Thrift deserialization; Section 9.7 recommends verifying the outer fingerprint before any further processing to limit the attack surface.
RIFT LIEs MUST carry TTL/HL of 1 or 255 to contain packets to a single L3 hop; receiving implementations SHOULD validate these values and drop packets with unexpected values. This prevents off-link injection attacks against the neighbor discovery plane.
RIFT ZTP automatic level derivation can be exploited if an attacker can inject crafted LIEs to influence level assignment. Section 9.4 notes that ZTP should only be used in environments where physical security of links is assured or authenticated LIEs are employed.
The LIE Finite State Machine governs neighbor discovery with three states: _OneWay_ (initial), _TwoWay_ (remote LIE seen), and _ThreeWay_ (mutual reflection confirmed including security information). TIE exchange begins only after reaching _ThreeWay_; ZTP information is exchanged in any state.
The RIFT ZTP FSM governs automatic level determination. Undefined FSM transitions in any RIFT FSM MUST be treated as unrecoverable errors, forcing the FSM back to _OneWay_ and flushing all flooding queues.
All normative RIFT packet structures are defined using Apache Thrift. The top-level _ProtocolPacket_ contains a _PacketHeader_ and a _PacketContent_ union of _LIEPacket_, _TIEPacket_, _TIDEPacket_, and _TIREPacket_. The serialized _ProtocolPacket_ is carried inside a UDP frame wrapped in a security envelope (Section 6.9.3).