MPLS vs SRv6 for Operators: What Actually Changes

The MPLS versus SRv6 argument is usually conducted with diagrams. The diagrams are the easy part. What actually decides the question in an operator is something less photogenic: which tools your on-call engineers reach for when a path is not doing what the diagram says, and whether those tools still exist after the migration. I came up through the ATM and Frame Relay to IP/MPLS migration of a national backbone in the mid-2000s, and the lesson from that project was not that MPLS was better. It was that the migration cost lived in the runbooks and the reflexes, not in the equipment.

What changes in the data plane

MPLS carries a 4-byte label stack between the Ethernet header and the IP header. Each hop swaps the top label for another and forwards toward the next hop. The label-switched path is either signalled by a protocol such as LDP, reserved by RSVP-TE, or, in segment routing, constructed from labels that the IGP advertises as segment identifiers. The important property is that forwarding state is distributed: every hop holds state about the paths it participates in, and the data plane is a cheap fixed-size lookup.

SRv6 removes the label. The path is encoded as a list of IPv6 addresses, carried in the segment routing header defined in RFC 8754, and the forwarding behaviour of each segment is defined in RFC 8986. The headend puts the segment list into the packet; the core forwards ordinary IPv6 packets and processes segments only where a segment endpoint lives. There is no per-LSP state distributed hop by hop, because each packet carries its own instructions. That is the structural difference: MPLS keeps state in the network, SRv6 keeps state in the packet.

The engineering consequences are not symmetric. Removing distributed state simplifies the control plane and makes traffic steering an end-to-end decision rather than a per-hop reservation. That is genuinely attractive if you want to express policy the way a service or an application thinks about it. The price is a larger header, which interacts with MTU, with hardware parser depth, and with the cost of per-hop IPv6 lookup. Static random access memory in the forwarding pipeline is finite, and a header that grows by 16 bytes per segment is not free on a router that was specified for label stacks.

One honest complication: SR-MPLS is the middle point, and it is easy to forget in these debates. It uses the same MPLS forwarding plane as today, with labels distributed by the IGP as segment identifiers instead of by LDP. You get much of the segment routing policy story without changing the data plane or the OAM tooling. If the question is really "should I move off MPLS forwarding", SR-MPLS is not the answer, but if the question is "do I need segment routing policy", it often is.

Dimension	MPLS with SR-MPLS	SRv6
Forwarding state	Per-path labels distributed by IGP; SR-MPLS removes LDP but keeps label forwarding	No per-path state in the core; segments carried in the packet
Header cost	4 bytes per label	IPv6 header plus SRH and 16 bytes per segment; uSID compresses this
Hardware dependency	Mature on almost every platform shipped in the last fifteen years	Depends on ASIC and line card support, segment depth and uSID capability
OAM	LSP ping and traceroute are decades old and understood by every NOC	Defined in RFC 9259 and improving, but less uniformly deployed
Fast reroute	TE fast reroute and TI-LFA, both well trodden	TI-LFA and SRv6 repair paths, requiring hardware support for segment processing
Failure domain	Forwarding plane and label distribution	IPv6 forwarding, locator reachability and segment processing
Team familiarity	Deep in most operators over a certain age	Still thin in most NOCs, and concentrated in a few engineers

The migration is five migrations

When people say "we are moving to SRv6", they usually mean the data plane change. That is the easy one. A production migration is at least five changes happening on different timescales, and they are rarely funded together.

The first is the control plane and IGP. Locators must be advertised, IPv6 reachability must be solid, and the IGP extensions in RFC 9352 must be supported by every platform in the path, not just the headends. The second is OAM. Your team knows how to trace an LSP and how to read an LSP ping return code. Tracing an SRv6 path means reading a segment list, mapping locators back to routers, and understanding which segment failed. That is a different tool and a different mental model, and the runbook that used to be one page becomes a training problem.

The third is telemetry and the operations stack. Capacity planning, path accounting and fault correlation in an MPLS network are built around LSPs and label stacks. The OSS that collects this data has to understand SIDs. If the collector does not, the migration can be technically complete while the network becomes less visible than before. The fourth is hardware. A feature can be present in software and absent in the ASIC, and the difference shows up as a line card that cannot do the thing the design assumes. The fifth is interworking: your peers, your partner networks, your PE-CE edges and your inter-AS design all have to agree on a transport, and some of them will not have migrated.

Why does this matter more for SRv6 than for the last decade of MPLS work? Because MPLS was the shared assumption for almost every carrier network in the world, so every tool, every vendor and every engineer had already solved it. SRv6 is not yet that shared assumption, so the migration is partly a migration of the ecosystem around you. Where that argument does not hold: a greenfield operator building with current hardware, an IPv6-only strategy and a small team can collapse all five migrations into one build, because there is no installed runbook to unlearn. That is a real advantage of being late.

Where SRv6 wins, and where it does not

SRv6 wins where the network needs to express end-to-end intent. If you are building transport for mobile, for a slice-based service, or for a data centre interconnect where the path itself is a product decision, the ability to put the path in the packet and steer it per flow without a signalling protocol is not a nice-to-have. It also wins on operational simplicity at scale: no label distribution state to reconcile, fewer protocols to run, and a natural fit with an IPv6-only underlay. The locator plus IS-IS advertisement below is an illustrative shape, not vendor-verified output.

segment-routing srv6
 locator MAIN
  prefix 2001:db8:100::/48
  behavior usid
!
router isis CORE
 address-family ipv6 unicast
  segment-routing srv6
   locator MAIN

SRv6 does not win by default. If the MPLS estate is mature, the runbooks are stable and the hardware is a few years old, the marginal policy benefit may not pay for a migration that touches every card, every OSS integration and every on-call engineer. It does not win if the requirement is deep OAM maturity today, because MPLS OAM has been exercised by every operator for twenty years and SRv6 OAM is still catching up in uniform deployment. It also does not win if MTU is tight in the existing design and header growth cannot be absorbed, which is exactly the kind of constraint that a diagram never shows.

The failure mode of both directions is the same: choosing the technology and deferring the operations work. An SRv6 network with no SRv6-literate NOC is worse than an MPLS network with a well-trained team, and vice versa.

What I would do on a real network

First, I would separate the two questions. If the problem is path policy and traffic steering, SR-MPLS on the existing data plane solves most of it and costs a fraction of the migration. If the problem is an eventual move to an IPv6-only transport with end-to-end programmability, then SRv6 is the destination and the timing is a separate argument.

Second, I would pilot SRv6 in a domain that is new anyway: a greenfield site, a new DCI pair, a new mobile transport ring. New domains do not require anyone to unlearn a working runbook, and they give the team a safe place to build OAM tooling and telemetry before production depends on it.

The checklist I would want answered before committing budget:

• Which problem is being solved: policy expressiveness, IPv6-only transport, or vendor lifecycle?
• Does every platform in the path support the required segment depth, or only the headends?
• Is the hardware ASIC qualified for the feature, not just the software train?
• Can the NOC trace a path without the vendor's escalation, and how long does it take?
• Does the telemetry and OSS stack understand SIDs, locators and segment lists?
• What is the interworking plan for peers, partners and inter-AS links that stay on MPLS?
• What is the MTU budget in the existing design, and does it survive the header change?
• Which new domain gets the pilot, and what does success look like in numbers?
• Is SR-MPLS a sufficient and cheaper answer to the same problem?
• What is the rollback story if the pilot fails, and how much of the estate is affected?