SRv6 in the AI Era (part 1 - uSID Data Plane)

This article is written independently from my role at Cisco. All opinions are my own.

We don't know exactly how AI networks will be built over the next 10 to 20 years. Solving the AI-specific network problems will be accomplished in different ways in the beginning. As a network engineer or architect, you could bet on your favorite technology, learn it, and call it a day.

One of the philosophies that has guided my career is that my knowledge should be rooted in technology from as many vendors as possible, and that I should stay open to all possible solutions.

I believe SRv6 has tremendous promise in the AI era. This architecture applies to a wide variety of use cases — AI is just one of them. This is part of what gives it its strength. It can be applied to the private wide area network, traditional data center use cases, cloud service chaining, SD-WAN, and much more.

One challenge I believe a traditional network engineer faces when trying to learn SRv6 is that the topic is large and can seem complex when examined through the wrong lens.

I aim to simplify this architecture for the traditional network engineer who works in enterprise networking, or hasn't spent 30 years building service provider networks. If your style of learning is to read IETF drafts and RFCs, you're in luck — they're exceptionally well written and provide all the depth you'd need to master this topic.

This series is for everyone else.

uSID

This article focuses on the SRv6 uSID data plane. I'm starting here because these functions are central to one of the leading solutions AI network operators use to solve the ECMP entropy problem — Multipath Reliable Connection (MRC). MRC will get its own deep dive later in this series.

SRv6 is a network architecture that allows network operators and application owners to decide how their traffic will traverse the network before the first packet ever leaves the server NIC or is forwarded by the first-hop switch. The traffic intent is encoded in the packets. That intent could be setting the expectation that a service-level agreement must be honored, signaling the need for special traffic handling for security reasons, or forcing a carefully curated path that has been devised for optimal application performance.

IPv6

One of the first questions I get about SRv6 is how it relates to IP version 6. People who ask this are often a little hesitant, worried about their own IPv6 experience level. Let me reassure you: IPv6 is not really the point here. SRv6 is not another IPv6 migration technology. While it borrows some of IPv6's benefits and works around some of IPv4's limitations, SRv6 can carry traffic for applications that are themselves IPv4-based or purely Ethernet-based. The only IPv6 skill you actually need is a working knowledge of how the addressing scheme is written.

Not Another Shim Layer

For decades, the industry has given us different ways to layer extra addressing, tunneling, or service logic on top of plain IP — MPLS, VXLAN, NSH, NVGRE, Geneve, and more. Each of these solves a real problem (traffic engineering, multi-tenant overlays, service chaining, and so on), but most of them do it by bolting a separate header or label stack onto the packet. That adds encapsulation overhead, can require more expensive silicon to encap/decap at line rate, and adds complexity to the network.

The modern iteration of SRv6 takes a different approach: it encodes a complete set of forwarding instructions directly inside the IP packet's own destination address, rather than adding a new header for them. One of the advantages of IPv6 is that its 128-bit address gives us plenty of headroom to do this.

uSID

These instructions are called the uSID. The micro-SID, or uSID for short, is a segment identifier value with roots in the original Segment Routing implementation for MPLS data planes. A uSID is just a 16-bit slice of the destination IP address.

The IETF and some vendors refer to these instructions as the Compressed SID, or CSID — that's the formal term used in RFC 9800, "Compressed SRv6 Segment List Encoding" (June 2025): https://www.rfc-editor.org/rfc/rfc9800.html

While SRv6 relies on IPv6's larger address, I'd like to offer an IPv4 analogy for readers who are more comfortable there. To be clear up front: IPv4 doesn't actually support what I'm about to describe — this is a thought experiment purely to build intuition, not a real IPv4 capability.

We've all been taught that an IP address has two parts: a network portion and a host portion. For 192.168.10.0/24, 192.168.10 is the network portion, and the last octet — minus two values — is set aside for hosts on that network.

Now imagine that the "10" in that address could mean something else entirely — a specific piece of traffic-engineering intent. What if encoding "10" in that exact spot in the destination address forced the packet to make a pit stop at router 10 along the way to its final destination?

That's essentially what SRv6 does.

The problem is that a 32-bit IPv4 address doesn't leave enough spare room for this to work. There's barely space to encode one instruction, let alone a sequence of them. That's where IPv6 comes in.

SRv6 is built on IPv6 because 128 bits is more address space than most networks will ever need for host addressing alone — which leaves plenty to spend on instructions instead. I can reserve a chunk of my own IPv6 private address space — commonly a /32 — as the SRv6 Locator, shared across my entire network. I'll never miss those bits. The format supports up to six — 32 bits for the Locator leaves 96, and 96 ÷ 16 = 6, the minimum every implementation must support per RFC 9800.

A common, real-world choice for the SRv6 Locator is a slice of the Unique Local Address range (fd00::/8), which RFC 4193 sets aside specifically for this kind of private, internal use — similar in spirit to RFC 1918 for IPv4: https://www.rfc-editor.org/rfc/rfc4193.html

You don't need to register anything with an outside authority.

With that much room, it becomes practical to embed several instructions in a single packet. Most real deployments don't go beyond two or three 16-bit uSIDs in a single destination address but we can add up to six instructions. (SRv6 has additional mechanics for extending a path further than six instructions — worth its own discussion, but outside the scope of this article.)

Shift Operation

The elegant part of SRv6 is how it handles a whole sequence of instructions without building up massive per-flow state in the network — and without needing an SDN controller that becomes a single point of failure or a performance bottleneck.

Here's a simplified view of how it works:

• The first instruction lives in the "network" part of the destination address. It's the active instruction. There may be additional, optional instructions sitting further along in what would normally be the host part of the address — but we can ignore those for now.
• The active instruction determines which router the packet gets steered to next. This isn't an IGP running shortest-path-first, which would send every packet for a given destination down the same path every time, regardless of current conditions, until something breaks badly enough to force reconvergence.
• Once the packet reaches the router named by that instruction, the router performs a shift operation: it removes that instruction from the destination address, shifts everything remaining 16 bits to the left, and the next instruction becomes active.
• This repeats until every instruction has been consumed, producing an end-to-end path that was completely decided before the first packet left the source.

Key Points

• Only one instruction (uSID) is active at a time. It's "active" because it currently sits in the part of the address that routers actually look at.
• The remaining, not-yet-active uSIDs are — for the moment — part of what looks like the host portion of the address, and routers ignore them entirely until it's their turn.
• Up to six uSIDs fit directly in the destination address when using a 32-bit Locator — the minimum every SRv6 implementation must support. Extending a path beyond that uses additional mechanics not covered here.
• Routers that aren't SRv6-capable simply route the packet normally, using whatever portion of the address they do understand. That means you don't have to convert your whole network at once — you can adopt as much or as little SRv6 as you need, on whatever timeline makes sense for you.

Life of a Packet

In this example, we will examine the source forwarding a packet to the destination that has a traffic intent encoded in the packet's destination IP address. The intent is that the packet is forwarded via R1 > R2 > R3, which avoids the link between R1 and R3, which happens to be the shortest path based on hop count.

• The first 32 bits — fd00:9999 — are the SRv6 Locator. Every device in this SRv6 domain shares this exact value; it never changes no matter which path a given packet takes. Written as a prefix, that's fd00:9999::/32.
• The next three 16-bit blocks — 1, 2, and 3 — are the uSID instructions, in order. Let's say these mean "go via Router 1," "go via Router 2," and "go via Router 3" — and since Router 3 is the last instruction in the list, it's also the one that will actually hand the packet to the destination server.
• Router 1 has fd00:9999:1::/48 (its 32-bit Locator plus its own 16-bit uSID, 48 bits total) configured as one of its own addresses. Any packet whose first 48 bits match that value belongs to Router 1 — and only Router 1. That's how a router recognizes a packet is meant for it.
• Router 1 receives the packet, performs the shift operation, and removes uSID "1" from the destination address.
• uSID "2" is now active. The process repeats at Router 2, then again at Router 3.
• Router 3 receives the packet with uSID "3" active, matches it against its own configured fd00:9999:3::/48, and shifts — exactly like Router 1 and Router 2 did before it. The result is fd00:9999::: every instruction consumed, nothing left active. That all-zero result is what tells Router 3 there's nothing further to forward — its own table has an ordinary, non-SRv6 route for that outcome, straight to the attached server.

Wrapping Up

We opened this piece by saying SRv6 lets you encode intent directly into a packet's own address — an SLA that has to be honored, a path chosen for security reasons, a route hand-picked for performance. The "Life of a Packet" walkthrough is that idea in its simplest form: three routers, three instructions, one deterministic path decided before the packet ever left the source — deliberately passing up a shorter route that just wasn't the right one for this traffic.

That's the whole mechanic. A Locator every device agrees on, a stack of 16-bit instructions riding behind it, and a shift operation simple enough to run at line rate on every hop. No control plane in the loop, no per-flow state, nothing that has to converge.

I don't want to leave you with the impression this is all there is to SRv6. There is much more including:

• In MRC, how NIC decides which instructions to write in the first place, how it reacts the instant a path stops working, or whether any of this holds up when there are a hundred thousand GPUs instead of one server.

• Numerous SRv6 implementation options: WAN, data center fabric, the cloud, SD-WAN, and more.

• Flexible Algorithms (Flex Algo)
• Transport Independent Loop-Free Avoidance (TI-LFA) for extremely fast failover
• Service chaining

We're examine this in future parts.