Segment Routing: Simplifying the Routing Control Plane

If you’ve spent any real time running an MPLS network, you know the feeling. Somewhere in your core, LDP is quietly building label bindings hop by hop, while RSVP-TE is off in its own corner maintaining a separate database of signaled paths, complete with PATH and RESV messages, refresh timers, and per-LSP state sitting on every transit router along the way. Two protocols, two philosophies, two things that can break independently, and a debugging session that inevitably involves checking both before you find the actual problem. For a long time, this was just the cost of doing business if you wanted traffic engineering on top of basic MPLS forwarding.

Segment Routing showed up to ask a pretty reasonable question: what if the network didn’t need to remember anything at all, and the path was just written into the packet itself?

That idea, on its surface, sounds almost too simple to replace two mature, widely deployed protocols. But it’s exactly that simplicity that has made Segment Routing the default direction for new MPLS and IP core builds over the last several years, and the reason most major equipment vendors have spent the better part of a decade building it deeper into their platforms.

The problem Segment Routing was built to fix

To appreciate why SR caught on, it helps to remember what it was replacing. LDP is great at one thing: distributing labels for the best IGP path between two points. It’s simple, it scales reasonably well, and it’s been a workhorse since the early days of MPLS. The catch is that it only gives you that one path. If you need traffic engineering, meaning the ability to steer specific flows along a path that isn’t necessarily the IGP shortest path, LDP has nothing to offer.

That’s where RSVP-TE stepped in. It lets you build explicit, constraint-based tunnels and reserve bandwidth along the way, which made it indispensable for service providers who needed real traffic engineering and fast reroute capabilities. The tradeoff is operational weight. Every RSVP-TE tunnel requires signaling to set up, periodic refresh messages to stay alive, and per-LSP state on every router the path touches. In a large core with thousands of tunnels, that state adds up fast, and it directly affects how quickly the network can reconverge after a failure. Running LDP and RSVP-TE side by side, which is how most service provider cores actually looked for the better part of two decades, meant operating two separate signaling systems on top of your IGP just to get full functionality.

Segment Routing’s pitch is that none of that signaling is necessary. The IGP you’re already running, whether that’s IS-IS or OSPF, can carry everything needed to build paths through the network. No separate label distribution protocol, no RSVP sessions, no per-flow state sitting in the middle of your network. The path lives in the packet header, and the core routers just forward based on what’s written there.

Source routing is the whole trick

The architecture, formalized in RFC 8402, rests on a concept that long predates MPLS: source routing. Instead of asking every router along the path to make an independent forwarding decision (or to have previously agreed on one via signaling), the ingress node decides the entire path up front and encodes it as an ordered list of instructions called segments. Each segment is identified by a Segment Identifier, or SID, and represents something the network can act on, like “forward toward this node” or “forward out this specific link.”

Once that list is written into the packet, the rest of the network just executes it. A transit router doesn’t need to know anything about the overall path or hold any state about it. It looks at the active instruction, does what it says, and moves the packet along. When that instruction is complete, it’s removed (or in the IPv6 case, the index moves to the next entry), and the process repeats at the following node. This is the part that eliminates the signaling problem entirely: there is no setup phase, no maintained state, and no protocol exchange required to establish a path through the network. The intelligence lives entirely at the edge, in the head-end router that builds the segment list.

SR was designed from the start to run over two different data planes, and this is usually where people start to get the two technologies mixed up, so it’s worth separating them clearly.

SR-MPLS: the same forwarding plane, a much lighter control plane

SR-MPLS is the more conservative of the two, and it’s usually the easier on-ramp for networks that already run MPLS. The forwarding plane doesn’t change at all. A segment is simply encoded as an MPLS label, and an ordered list of segments becomes a label stack, exactly like a traditional MPLS LSP. If your hardware can already push, swap, and pop labels, it can almost certainly support SR-MPLS forwarding with nothing more than a software upgrade.

What’s different is how those labels get assigned and distributed. Instead of LDP handing out locally significant labels hop by hop, IS-IS and OSPF are extended (via RFC 8667 and RFC 8665, respectively) to advertise SR-specific information directly. Each router advertises a Prefix-SID for its loopback, which maps to a globally significant label drawn from a range called the Segment Routing Global Block, or SRGB. Because every router in the domain reserves the same block of label values for this purpose and maps the same Prefix-SID to the same offset within it, a Prefix-SID effectively means the same thing network-wide. If a router advertises Prefix-SID 100 for its loopback, every other router in the domain knows that pushing the label corresponding to offset 100 in the SRGB will route the packet there, following the IGP shortest path, with no further signaling involved.

Alongside Prefix-SIDs, routers also advertise Adjacency-SIDs, which represent a specific link to a specific neighbor rather than a path to a destination. These are locally significant, generated automatically by each router for its own adjacencies, and they’re what give an operator the ability to steer traffic across a specific link rather than just toward a destination. Stack a few Prefix-SIDs and Adjacency-SIDs together in the right order, and you’ve built an explicit path through the network using nothing but labels the IGP already told everyone about.

The net effect is that an operator can run a fully functional MPLS core, complete with the ability to steer traffic along non-shortest paths, using only the IGP. No LDP. No RSVP-TE. Just IS-IS or OSPF doing slightly more work than before.

SRv6: same idea, dressed in IPv6

SRv6 takes the identical architectural concept, source routing with a segment list, and applies it to a native IPv6 data plane instead of MPLS. Here, a SID isn’t a label, it’s a full IPv6 address. The list of segments is carried in a new IPv6 extension header called the Segment Routing Header, defined in RFC 8754, and the active segment is simply written into the IPv6 destination address field. A router forwards the packet toward that address, and when it’s done processing its instruction, the Segments Left pointer in the SRH decrements and the destination address is updated to the next segment in the list.

What makes SRv6 genuinely interesting, beyond just being an IPv6 version of the same trick, is the network programming model defined in RFC 8986. Because a SID is just an IPv6 address, it can be structured to encode more than “where to go.” A SID is typically split into a locator portion, which gets the packet routed to the right node, and a function portion, which tells that node what to actually do with the packet once it arrives. That function might be as simple as “forward this normally,” but it can also mean “decapsulate this and forward into VRF blue” or “pop into this Layer 3 VPN,” and there’s a whole defined catalog of these endpoint behaviors, things like End, End.X, End.DT4, and End.DT6, each representing a different action. In effect, SRv6 turns a destination address into a small set of instructions the network can execute, which is what people mean when they talk about SRv6 “network programming.” It collapses a lot of overlay and service logic that used to require separate encapsulation and signaling mechanisms into something that’s just expressed natively in the IPv6 header.

The tradeoff is overhead and hardware readiness. An SRH with several SIDs adds real bytes to every packet compared to an MPLS label stack, which has prompted a whole sub-industry of compression work, including Cisco’s uSID approach and the broader IETF effort around compressed SIDs, aimed at shrinking that header back down. SRv6 also generally needs IPv6-capable forwarding ASICs that can parse and act on the SRH efficiently, which means older MPLS-only hardware often can’t just be upgraded with software, the way it can for SR-MPLS.

So which one do you actually deploy?

In practice, this isn’t really an either-or decision for most networks, it’s a sequencing decision. If you’re running an existing MPLS network and your priority is getting rid of LDP and RSVP-TE signaling overhead without touching hardware, SR-MPLS is almost always the practical starting point. It reuses your forwarding plane, your existing label-switching ASICs are already capable of it, and the migration can happen incrementally, router by router, with LDP and SR coexisting in the same domain during the transition.

SRv6 makes more sense when the goal extends beyond just simplifying the control plane and into unifying transport and services on a single IPv6-native plane, particularly relevant for 5G transport networks, multi-domain interconnection, and cases where an operator wants to express rich service chaining without stacking multiple encapsulation layers. A lot of large operators end up running both, with SRv6 deployed as an overlay on top of an existing SR-MPLS or even plain MPLS core during the transition, since that lets services move to SRv6 incrementally without requiring a forklift upgrade of every router in the path.

Traffic engineering without the signaling baggage

The other half of the SR story, beyond just simplifying basic forwarding, is what it does for traffic engineering, which is really where RSVP-TE earned its keep in the first place. The modern answer here is the SR Policy architecture, defined in RFC 9256. An SR Policy is essentially a named container at a head-end router that holds one or more candidate paths, each expressed as an ordered segment list, with a preference value deciding which one is active. That policy can be built two ways: dynamically, where a controller or the head-end computes a path against some constraint like low latency or avoiding a particular link, or explicitly, where an operator or controller just hands the router the exact segment list to use.

What makes this genuinely lighter weight than RSVP-TE is that all of this state lives only at the head-end. Transit routers along the path don’t know an SR Policy exists, they’re just forwarding based on the active segment in the packet, the same as any other SR traffic. There’s no signaling exchange to set the path up and no per-LSP state maintained mid-network. For operators who want centralized, intent-based control over how traffic flows through the network, this pairs naturally with a controller speaking BGP-LS to learn topology and PCEP or BGP to program policies onto head-ends, which is the architecture behind most modern SDN-driven WAN traffic engineering deployments today.

It’s also worth a mention that SR plays well with Flexible Algorithm (Flex-Algo, RFC 9350), which lets an operator define custom IGP metrics and constraints, say, a topology optimized purely for latency rather than hop count, and have the IGP compute Prefix-SID paths against that custom algorithm automatically. That’s a level of routing flexibility that simply wasn’t available in the LDP and RSVP-TE world without bolting on a separate constrained path computation system.

Where this stands today

Segment Routing isn’t a niche or experimental technology anymore, it’s the mainstream direction for new core builds. SR-MPLS in particular has reached the point where it’s a fairly unremarkable, well-understood deployment for service providers replacing legacy LDP and RSVP-TE cores, and most major router platforms have supported it for years.

SRv6 adoption has been climbing more gradually, largely because it asks more of the underlying hardware and requires at least partial IPv6 readiness across the path. That said, the trend is clearly moving in one direction. A 2026 industry survey from the World Broadband Business Alliance, covering several hundred operators globally, found that the large majority had already begun deploying SRv6 in some capacity, with a meaningful share reporting deployments that were already extensive. It’s become a foundational piece of how operators are thinking about building networks that need to support programmable, sliced services, particularly for 5G transport and increasingly for the kind of high-bandwidth, low-latency demands coming out of AI infrastructure buildouts.

Is it worth the migration effort

If you’re sitting on a network still running LDP and RSVP-TE side by side and wondering whether this is worth the project, the honest answer depends on what’s actually driving you to look at it. If your core is stable, your traffic engineering needs are modest, and RSVP-TE state hasn’t become an operational headache, there’s no urgent reason to rip it out. But if you’re scaling toward a point where RSVP-TE state on transit routers is becoming a real convergence and capacity planning concern, or if you find yourself wanting more dynamic, controller-driven traffic engineering than RSVP-TE was ever designed to give you gracefully, SR-MPLS is a genuinely lower-complexity way to get there, and the migration path is incremental enough that you don’t need a flag day to do it.

The bigger architectural bet, SRv6 and its network programming model, is less about replacing what you have and more about whether your network’s future looks like something that needs programmable, service-aware forwarding baked into the data plane itself. For a lot of networks, that’s still a few years out. For operators building 5G transport or next-generation IP cores today, it’s already the starting assumption.

Either way, the underlying shift Segment Routing represents, moving intelligence to the edge and letting the packet carry its own instructions instead of asking the network to remember them, is one of those ideas that, once you’ve worked with it, makes the old way feel like it was carrying a lot of unnecessary weight.