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

We don't know exactly what AI networks will look like 10 years from now. Like many technologies in their infancy, solving the AI-specific network problems will be accomplished in many different ways. As a network engineer or architect, you could bet on your favorite technology, learn it, and call it a day.

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 wide area network, traditional data center deployments, cloud service chaining, SD-WAN, and much more.

One challenge when trying to learn SRv6 is that the topic is large and can seem complex when examined through the wrong lens.

I hope to simplify this architecture for the traditional network engineer who works in enterprise networking, or hasn't spent decades building service provider networks. If your style of learning is to read IETF drafts and RFCs, you're in luck — they are 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 the uSID is central to one of the leading solutions AI network operators are using to solve the ECMP entropy problem — Multipath Reliable Connection (MRC). MRC and the entropy problem 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 is ever transmitted. 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 acronym in the long list of IPv6 migration implementations. 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 primary 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 without wasting address space.

uSID Basics

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 uSIDs — 32 bits for the Locator leaves 96, and 96 ÷ 16 = 6, which is the minimum number of uSIDs 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 the rest of the address 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 — six being 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'll examine a packet forwarded from the source to the destination, with the traffic intent encoded in the packet's destination IP address. The intent is that the packet is forwarded via R1 > R2 > R3, avoiding the direct link between R1 and R3 — which happens to be the shortest path based on hop count.

Wrapping Up

We opened this piece by saying SRv6 lets you encode intent directly into a packet's own address — an SLA that will be honored, a path chosen for security reasons, or a path hand-picked for performance. This gives the network architect a great deal of creativity to bring to network design. So, what can you do with SRv6?

A lot.

In the case of building artificial intelligence networks, there are significant problems to solve. OpenAI introduced MRC (Multipath Reliable Connection) through the Open Compute Project (OCP). This aims to solve the problems that have been inherent to ECMP over the years.

But there is much more promise for SRv6. There are use cases that apply to traffic engineering with a wide area network, data center fabrics, the cloud, SD-WAN, and more.

To be continued...

---

This content is created independently and is not sponsored by or affiliated with any technology organization. All opinions are my own.