After many discussions, whiteboarding sessions, and ‘Design Kitchens’ with customer decision makers, one thing keeps coming up, SRv6 is elegant but not without challenges. So I decided to write this down.

For anyone who has followed the SRv6 evolution, you realize the elegance of the architecture but at the same time notice a practical concern. SRv6 is cool, SIDs are IPv6 addresses, they carry meaning, the control plane becomes simpler, and the data plane becomes programmable, at the same time you might start thinking about what actually lives inside the packet. A Segment Routing Header with multiple 128-bit SIDs, which might be OK for a single instruction, but assuming we have more than one instruction for a given packet flow, we might end up with a packet overhead that we don’t really want to have in a production network.

This is why SRv6 uSID was introduced, and it’s not just a minor optimization. It’s a rethinking of how we use the space inside those 128-bit IPv6 addresses to encode far more forwarding instructions than standard SRv6 can pack into a single SRH. If you’ve spent time thinking about designing or deploying SRv6, understanding uSID is not optional anymore. It’s increasingly where the industry is heading.

Let me be clear about this, SRv6, in its original form, has an overhead problem. Not a fatal one, but one that matters when you’re building high-speed service provider networks with line-rate forwarding requirements.
When a packet traverses an SRv6 domain, it carries an SRH that lists all the SIDs it needs to visit. Each SID is a full 128-bit IPv6 address. If your segment list has, say, 4 SIDs, which is perfectly reasonable in a Traffic Engineering scenario with a few waypoints, you’re looking at an SRH overhead of 4 × 16 bytes = 64 bytes, plus the SRH header itself. That’s before you’ve even added the outer IPv6 header. For small packets, this overhead ratio is significant. And in a service provider network, small packets aren’t rare, they’re very much the norm in many traffic profiles.

The early hardware implementations also had constraints around SRH processing. Line rate parsing of variable-length headers with multiple SIDs puts real pressure on ASIC designs. This isn’t a theoretical concern, it was one of the reasons many hardware vendors were initially cautious about committing to full SRv6 support. The technology was great but the hardware economics were uncomfortable.

So the question became, can we preserve everything that makes SRv6 powerful while reducing the per-packet overhead? The answer was yes, and that answer is uSID.
uSID stands for micro-SID and the concept is simple. Instead of using a full 128-bit IPv6 address for each segment, uSID allows you to pack multiple instructions, multiple micro-SIDs inside a single 128-bit IPv6 address. Think of it as compressing the segment list into the address itself.

To understand how this works, you need to understand the structure of a uSID. A uSID capable IPv6 address is divided into three logical parts:

• uSID Block — the common prefix shared across all uSIDs in the network, typically a /32. This identifies the SRv6 domain or a specific routing locator region.
• uSID Container — the remaining bits of the 128-bit address, divided into fixed-width slots. Each slot holds one micro-SID, typically 16 bits wide (that’s why this format is also known as F3216).
• Active uSID — the leftmost non-zero slot in the container, which is the currently active forwarding instruction.

Imagine a uSID block of FC00::/32. The remaining 96 bits form the container, divided into six 16-bit slots. A single 128-bit IPv6 address could then look like this:

FC00:0001:0002:0003:0004:0005::

This single IPv6 address encodes five micro-SIDs: 0001, 0002, 0003, 0004, and 0005. Five forwarding instructions in 128 bits, the same space a standard SRv6 implementation uses for a single SID. That’s the efficiency gain with SRv6 uSID in one sentence.

Now, in terms of Data Plane, this is where it gets interesting from a hardware perspective. Processing a uSID doesn’t require anything special. The operation is essentially a shift, and shift operations are extremely cheap in silicon (ASIC).
When a router receives a packet whose destination IPv6 address contains a uSID as the active instruction, it does the following:

1. Identifies the active uSID, the leftmost non-zero 16-bit slot in the container.
2. Executes the behavior associated with that uSID.
3. Shifts the remaining uSIDs to the left, effectively advancing to the next instruction (uSID).
4. The result becomes the new destination IPv6 address of the packet.

Notice what this means, there’s no SRH manipulation happening at every transit hop. The segment list is encoded in the destination address itself, and going through the list is just a shift operation on the destination field. This is orders of magnitude simpler to implement in ASICs than parsing and updating a full SRH on every hop. In fact, many uSID deployments can entirely eliminate the SRH from the transit data path, the uSID container in the destination address carries everything the network needs to forward the packet all the way to the egress PE.

Just like standard SRv6 has a well-defined set of behaviors (End, End.X, End.DT4, and so on), uSID has its own micro-SID behavior set that mirrors these functions but is specifically optimized for uSID processing:

• End.uN — It’s a node segment which instructs packets to be forwarded toward the node that owns this uSID, then shift to the next instruction.
• End.uA — An adjacency segment instructing the packets to be forward out a specific interface toward a neighbor, then shift the remaining bits of the container.
• uDT4 / uDT6 / uDT46 — decapsulate and perform a VPN table lookup, specifically for L3VPN scenarios.
• uDX2 — for L2 cross-connect use cases, also known as E-Line service.

Check RFC9800 for a full list of behaviors. The key thing here is that every uSID behavior is intentionally designed to be hardware friendly. The shift operation is consistent across all behaviors, which means ASICs can implement a single generic processing pipeline and apply the appropriate endpoint behavior at the conclusion of that pipeline. This is not an accident, it was a deliberate design decision made to ensure uSID could be commercially viable on real forwarding hardware, not just on software routers in a lab.

From a control plane perspective, uSIDs follow the same model as standard SRv6, IS-IS extensions carry the locator prefixes and associated SID information. The SRv6 locator TLV in IS-IS is used to advertise the uSID block, and individual uSID behaviors are bound to those locators.
The important difference lies in the locator block design. With uSID, operators typically define a common uSID block, say, FC00::/32 — that is shared across the entire domain. Each node then receives an allocation of uSIDs within that block. Node A might own FC00:0:1:/48, Node B might own FC00:0:2:/48, and so on. The uSID values themselves, the 16-bit micro-SID identifiers, are assigned per node and per function (node SID, adjacency SID, etc).

What this means in practice is that the control plane stays lightweight. IS-IS doesn’t need to flood thousands of individual SID mappings. It advertises locator prefixes, and from those prefixes, every router in the domain can derive the forwarding behavior for any uSID it encounters. The state in the network is dramatically reduced compared to both traditional MPLS and even full-SID SRv6 deployments.
BGP is still used as the Protocol for service SIDs, VPN endpoints, EVPN and so on, but the transport layer remains IS-IS driven. That separation is clean and intentional, and it’s one of the things I find architecturally clean about uSID deployments.

I mentioned earlier that hardware vendors were cautious about full SRv6 support. And so, Cisco as the leader, came up with SRv6 uSID which fundamentally changes a lot in terms of packet overhead and packet processing, and there are three reasons why.

First, the overhead reduction is dramatic. In many realistic deployments, several uSIDs can be encoded in a single 128-bit address with no SRH required in the transit path at all. A packet that would have carried a 64-byte SRH in standard SRv6 now carries zero transit overhead beyond the outer IPv6 header. That’s not a small improvement, it’s a fundamentally different cost structure for the data plane.

Second, and maybe more importantly, SRH processing shifts to the edges. The expensive operations, encapsulation, SRH construction and SID list encoding, happen at the ingress PE and decapsulation at the egress PE. Transit routers simply see a standard IPv6 packet with an unusual destination address and perform a destination address shift.

Third, ECMP behavior works naturally with uSID. Because the destination address is a valid IPv6 address throughout the transit path, existing ECMP hashing mechanisms operate exactly as expected. You don’t need special handling to ensure correct load balancing, the uSID fits seamlessly into existing hashing pipelines. This might sound like a small thing, but in a large SP core where ECMP is fundamental to how you use your capacity, it’s actually a significant advantage.

uSID is the right choice for the transport core. If you’re designing a backbone or core network and you want SRv6’s operational and architectural benefits, simplified control plane, programmable data plane, native IPv6 integration without paying the overhead penalty at every transit hop, uSID is the answer. It’s also increasingly the answer that vendors are defaulting to. Cisco’s IOS-XR, and most of other vendors today have uSID support, and it’s not a niche feature anymore, it’s becoming the primary deployment model for SRv6 in real networks including AI Fabrics in large DCs.

If you’re planning an SRv6 deployment today and uSID isn’t already in your design, it should be. And if you’re still on the fence about SRv6 altogether, uSID removes one of the last reasonable objections. And if that’s not enough, then ping me on Linkedin, I’d be happy to talk to you and provide guidance on SRv6 uSID deployment.

Categories: General Networking

Tags: SRv6, usid