SR-MPLS vs SRv6: Which Segment Routing Data Plane

Segment routing removes LDP and RSVP-TE from the network by having the IGP distribute the forwarding instructions itself. What it does not remove is the choice of data plane: segments can be encoded as 20-bit MPLS labels (SR-MPLS) or as 128-bit IPv6 addresses (SRv6). Both share the same control plane, the same traffic engineering model and the same source-routing idea, but they differ in header overhead, hardware requirements, monitoring visibility and migration effort. This article lays out the comparison in operational terms and describes the paths from an existing MPLS network to either destination.

The one-line difference, then the consequences

In SR-MPLS a SID is a label that indexes into a Segment Routing Global Block shared fabric-wide. In SRv6 a SID is a routable IPv6 address shaped as locator:function:argument, so the instruction contains its own reachability. That single architectural difference cascades into everything else.

The MPLS label stack carries three practical limitations worth naming. Labels cannot be summarised, so every label must be distributed and programmed on every node; deep stacks consume forwarding table and TCAM space. Merchant silicon typically limits stack depth to six or eight labels. And because the shim header sits between Layer 2 and Layer 3, ordinary IP monitoring and packet analysis cannot see inside it without MPLS awareness.

Why uSID changes the SRv6 calculus

The historical objection to SRv6 was header size: a path of six segments costs 96 bytes of SIDs plus the SRH, which is a real problem at 1500-byte MTU. Micro-SID compression packs multiple 16-bit micro-instructions into a single 128-bit address, so a multi-hop path often fits in the IPv6 destination address with no SRH at all. Each node shifts the next uSID into position and forwards. In that common case the packet is simply an IPv6 packet, and only the routers that participate in traffic engineering need SRv6 support — everything else routes IPv6 normally.

! Cisco IOS XR -- SR-MPLS: prefix SID for the loopback
router isis CORE
 is-type level-2-only
 metric-style wide
 segment-routing mpls
  global-block 16000 23999
 interface Loopback0
  address-family ipv4 unicast
   segment-routing prefix-sid index 1

! Cisco IOS XR -- SRv6 locator for the same node
segment-routing srv6
 locator MAIN
  prefix fcbb:bb00:1::/48

Note the two constants that must be identical fabric-wide in SR-MPLS: the SRGB range and the index-to-label mapping. If one node uses 16000-23999 and another 100000-199999, indices still match but the resulting labels do not, and forwarding breaks exactly at the boundary. In SRv6 the equivalent invariant is that each node's locator is unique inside a shared uSID block, and that the locator prefix is actually advertised into the IGP.

Migration paths that do not require a flag day

For an existing MPLS network, the phased route is usually MPLS → SR-MPLS → SRv6: SR-MPLS reuses the label data plane and hardware often needs only a software upgrade, while SRv6 requires IPv6 across the forwarding path. Where SRv6 is the target, four deployment options cover most situations.

• Ships in the night: SRv6 and MPLS coexist with no interaction; simplest and most common for a first deployment.
• SRv6 overlay over MPLS: SRv6 used for services only, leaving the transport untouched.
• Dual plane: a second backbone built for SRv6, with services migrated gradually.
• Interworking: translation between SRv6 and MPLS domains, needed when service continuity must span both.

Service migration benefits from carrying two routes for the same prefix — one with an MPLS VPN label over an IPv4-based BGP session, one with an SRv6 SID over IPv6 — and then changing the route policy to prefer the IPv6-learned route. That makes the cutover a policy change rather than an outage. The route-target and RD design that underpins those VPNs is unchanged, and the principles in MPLS L3VPN route distinguisher and route target design still apply.

What actually breaks in the field

Four mistakes account for most segment routing incidents: mismatched SRGB, narrow IS-IS metrics (SR extensions ride in wide-metric TLVs, so SIDs flood but never install), MPLS not enabled on the intervening interfaces in software routers, and an unadvertised SRv6 locator whose SID table looks healthy locally while being unreachable remotely. For traffic engineering specifically, a segment list that names the destination only will follow the IGP shortest path and appear to do nothing — you must list the intermediate SIDs you want traversed.

Before deploying SR-TE policies in production, prove the path in a lab and confirm the label trace differs from the IGP default. Policy language specifics for IOS XR are covered in IOS XR routing policy language, and the encapsulation overhead question for tunnels carrying large payloads is addressed in VXLAN MTU and fragmentation with jumbo frames.

原文链接：https://www.wwt.com/blog/cisco-sr-mpls-or-cisco-srv6-usid-choosing-the-right-path-for-your-network