eBGP was designed for the internet and adapted for data centers. RIFT (Routing in Fat Trees, RFC 9692, published April 2025) was designed for fat-tree topologies from first principles. The difference is visible in every design decision it makes.

In a standard eBGP fat-tree fabric, every leaf switch has a complete view of every server prefix but no view of the topology connecting those prefixes. Leaf1 knows it can reach Server5 via Spine1 or Spine2, but it does not know whether Spine1's link to Leaf4 is congested. It cannot perform end-to-end path quality assessment. This is the DLB/GLB problem from Chapter 6: the routing plane is deliberately topology-blind, and load balancing must fill the gap using out-of-band quality signals.

RIFT combines two propagation mechanisms. Northbound (leaf -> spine -> super-spine), RIFT uses link-state flooding: each node advertises its adjacencies and local prefixes to all nodes in the layer above, building a complete topology view at the top of the fabric. Southbound (spine -> leaf), RIFT uses distance-vector: each spine summarises reachability information into aggregated prefixes and distributes them down. The result is that spine and super-spine nodes have full topology awareness (they have seen all northbound link-state), while leaf nodes have a compact distance-vector view that minimises FIB size.

This topology awareness produces automatic traffic engineering that BGP cannot match. When a leaf link fails, the super-spine nodes update their link-state topology and immediately begin disaggregating the summary prefixes -- advertising more-specific prefixes to direct traffic around the failure, without any operator intervention. This "automatic disaggregation" means that RIFT converges as fast as link-state propagation allows (typically under 10ms in a well-tuned fabric), compared to BGP's multiple round-trip convergence cycles.

RIFT's adjacency formation uses UDP hello messages rather than TCP. There is no TCP state machine, no SYN/SYN-ACK/ACK sequence, no TCP retransmit timer. Adjacency formation is nearly instantaneous on link-up. Zero-touch provisioning follows naturally: a new spine is cabled, RIFT discovers it via hellos, the topology updates automatically, and routing entries appear within seconds. No ASN assignment, no BGP neighbor configuration on connecting leafs.

The K-store (Key-Value store) embedded in RIFT advertisements enables metadata distribution that BGP requires extensions for. ASIC-level link quality metrics, overlay configuration data, QoS settings, and administrative metadata can all be propagated through the K-store as part of normal RIFT operation. This is the mechanism that makes RIFT suitable for DragonFly Sparse topologies (the IETF draft draft-przygienda-rift-dragonfly): the inter-group horizontal links between top-of-fabric nodes are encoded as K-store entries, enabling routing across groups without the manual configuration burden that makes BGP-based DragonFly impractical at scale.

RIFT's practical limitation is maturity. RFC 9692 was published in April 2025. Implementations exist in open-source (used for server-level routing) and from selected vendors, but multi-vendor interoperability at the scale of a 10,000-switch AI fabric has not been proven in production. The operational tooling -- debugging, telemetry, audit trails -- is less mature than BGP's decades of tooling. Deployments that need EVPN overlay services for multi-tenancy or complex border routing policies will find RIFT's policy model limited compared to BGP.