Skip to content

Chapter 15: IP Routing for AI/ML Fabrics · Part 2 of 10

Act 1 -- Why routing protocol choice matters

The first question in any AI fabric deployment is: which dynamic routing protocol? OSPF, IS-IS, BGP, RIFT -- all of them can move packets from A to B. What separates them in an AI context is what they do when things get hard: a link fails at 03:00, 32 spines are simultaneously receiving AllReduce traffic, one tenant's elephant flows are colliding with another tenant's gradient synchronisation.

BGP became the dominant protocol in data center fabrics for a specific reason: RFC 7938, "Use of BGP for Routing in Large-Scale Data Centers," published in 2016, documented how hyperscalers were already using eBGP as an IGP replacement. The reasoning was sound. OSPF floods link-state information to every node -- fine at 20 switches, pathological at 200 when LSA churn from link flaps creates CPU storms. IS-IS scales better but was considered exotic outside service provider networks. BGP, by contrast, is a path-vector protocol that propagates reachability, not topology. A leaf switch running eBGP knows how to reach every destination but does not know the complete topology between here and there. That information hiding is a feature, not a bug: it prevents the flooding amplification that kills OSPF at scale.

Routing protocol comparison
Click a protocol to see detail. Bar = score 1–5 for each AI fabric dimension.
Scale (nodes)
5/5
4/5
4/5
Convergence speed
2/5
4/5
5/5
Topology awareness
2/5
4/5
5/5
Link quality signalling
1/5
4/5
5/5
Multi-plane routing
3/5
5/5
4/5
Zero-touch provisioning
2/5
2/5
5/5
Deployment maturity
5/5
4/5
2/5

The limitation BGP accepted in exchange for this scalability is now becoming the central problem in AI fabrics. BGP's path-vector model gives you per-prefix best-path selection. It does not give you real-time link utilisation awareness. When a 400 Gbps spine link is at 98% and a DLB update needs to redirect flows away from it, BGP cannot express that state -- that awareness lives in the ASIC and the DLB quality tables, not in the routing protocol. When you want to partition the fabric into logical routing planes so Tenant A's GPU traffic never shares a spine with Tenant B's, BGP needs custom extensions (DPF, Link Bandwidth Community) that were not part of its original design.

The emerging alternatives -- RIFT (RFC 9692) and IS-IS Flex Algo (RFC 9502) -- were designed with these requirements in mind from the start. They carry link-quality metadata natively. They support multiple simultaneous routing topologies. They converge faster on failure. But they sacrifice BGP's policy richness and multi-vendor maturity. The practical answer in most deployments is a layered approach: eBGP for scale and policy, augmented with DPF for deterministic path control, with RIFT emerging as a candidate for pure-scale deployments that do not need BGP's policy machinery.

The new pressure on all of these protocols comes from microsecond requirements. AllReduce synchronisation barriers mean that a single slow GPU can stall 10,000 others. When a link degrades and the routing protocol takes 50ms to converge, that is 50ms of stalled training -- at $2-4 per GPU-hour across a 10,000-GPU cluster, that is hundreds of dollars of wasted compute. The routing protocol must react fast, ideally before the application layer notices anything has changed.