Segment Routing over IPv6 (SRv6) takes a fundamentally different approach to traffic engineering: instead of distributing routing decisions across all switches, it encodes the complete path in the packet header at the ingress node. Transit nodes do not make routing decisions -- they read the next segment identifier from the header and forward accordingly.

The header is the SRH (Segment Routing Header), an IPv6 extension header that sits between the outer IPv6 header and the inner Layer 4 header (UDP carrying RoCEv2 in an AI fabric). The SRH contains:

Segment list: An ordered list of 128-bit IPv6 addresses, each representing a SID (Segment Identifier). The currently active SID is pointed to by the Segments Left counter. When a switch processes the packet, it decrements Segments Left and updates the destination address of the outer IPv6 header to the next SID. The packet is then forwarded toward that next destination using normal IPv6 routing.

Node SID: A SID that identifies a specific switch in the SR domain -- similar to a loopback address. Encoding Node SID of Spine3 in the segment list means the packet must traverse Spine3.

Adjacency SID: A SID that identifies a specific link between two switches. More precise than a Node SID -- encoding an Adjacency SID forces the packet to exit via exactly that interface. Used when precise traffic engineering requires avoiding a specific link.

The SRv6 for AI backend draft (draft-filsfils-srv6ops-srv6-ai-backend) describes the operational model: a central controller (using Path Computation Element Protocol, PCEP, or BGP-LS for topology learning) computes an optimal path for each GPU-to-GPU communication pattern at the start of a training job. The controller encodes this path as a segment list and pushes it to the ingress leaf. The ingress leaf prepends the SRH to all packets from that GPU. Transit switches and spines forward based purely on the outer destination address -- no flow state, no load balancing decisions, just destination lookup and SRH processing.

SRv6 uSID (Micro-SID, defined in IETF draft draft-filsfils-spring-net-pgm-extension-srv6-usid) addresses the MTU inflation problem. A full SRH with three 128-bit SIDs adds 48 bytes of overhead before the payload. In an AI fabric where GPU frames are typically at MTU (typically 4200 bytes for RoCEv2 with jumbo frames), this overhead is acceptable. But in a five-stage fabric where segment lists may need five or more SIDs, the overhead grows to 80+ bytes, potentially forcing fragmentation. Micro-SID compresses each SID from 128 bits to 16 bits by sharing a common locator block (the most significant bits) across all SIDs in the domain. A five-SID segment list now adds 10 bytes instead of 80. The locator block approach works because all switches in the SR domain belong to the same administrative network -- their SIDs naturally share the same prefix.

The practical tradeoff for SRv6 in AI fabrics: it requires DCQCN (PFC + ECN) to continue functioning correctly even with SRH encapsulation. The RoCEv2 DSCP value that triggers PFC and ECN marking must survive SRH encapsulation and decapsulation. Early SRv6 implementations did not preserve DSCP through encapsulation, breaking lossless fabric operation. Modern implementations copy DSCP from the inner to the outer header. Operators must verify this behaviour in their hardware before deploying SRv6 in a lossless fabric.

SRv6 is gaining production momentum in service provider networks. For AI fabrics specifically, it is most compelling in two scenarios: very large fabrics where a central controller can compute globally optimal paths more effectively than distributed ECMP, and multi-tenant fabrics where the strict traffic isolation guarantees of explicit path programming are preferable to the probabilistic guarantees of DPF coloring.