SR-MPLS vs SRv6: Choosing a Segment Routing Data Plane

Segment Routing keeps the source-routing idea - the headend encodes the path - but removes the need for a signalling protocol to distribute per-flow state. The interesting engineering question is no longer whether to use SR but which data plane to carry it: an MPLS label stack, or IPv6 segment lists. This article compares the two on overhead, hardware maturity and operational reality.

The Shared Idea

A segment is an instruction: "forward along this path", "send to this node", "apply this service". The headend pushes an ordered segment list, and each hop acts on the top segment. There is no LDP, no RSVP-TE for basic LSPs - the IGPs (IS-IS or OSPF) advertise the SIDs, and path policy is computed centrally or statically. That is the simplification that made SR the default in modern service-provider and large-enterprise cores.

Everything the two data planes share comes from that model: a prefix SID gives every router a stable identifier that any other router can reach without a signalling protocol, adjacency SIDs encode "use this specific link" for strict paths and repair tunnels, and the IGP's own flooding mechanism distributes both. Convergence, loop-free alternates and per-flow steering all rest on the same SID table, which is why an SR design usually changes the IGP configuration more than it changes the forwarding configuration.

SR-MPLS

• Segments are ordinary MPLS labels. The segment list is a label stack, so forwarding is exactly MPLS forwarding.
• Overhead is 4 bytes per label - typically 2 to 4 labels in a basic path, so 8-16 bytes.
• Runs on hardware that has supported MPLS for two decades; line-rate, hardware-programmed, predictable.
• Limitation: label stacks have practical depth limits, and some traffic-engineering constructs become awkward at scale.

segment-routing mpls
 global-block 16000 23999
!
router isis CORE
 address-family ipv4 unicast
  segment-routing mpls sr-prefer

The global block (SRGB) is the label range the node reserves for SR segments, and it must be consistent across the domain or SIDs stop resolving. The IGP advertises a prefix SID for each loopback by index (the 16000 + index convention), so the same index produces the same label on every node regardless of the loopback addresses in use. Operation seems simple until one router's SRGB differs - then a path that looks correct in the IGP database punishes you with a black hole, and the fix is a migration window to align the blocks rather than a config tweak.

SRv6

• Segments are 128-bit IPv6 addresses carried in a segment routing header, so the path is visible in the packet itself.
• Overhead is a new IPv6 header plus extension headers - materially larger than a label stack, which matters for MTU planning.
• Native programmability: network functions (service chaining, NFV steering, slicing) become segment behaviours rather than special-case features.
• Cost: requires modern silicon and MPLS-free forwarding; pure IPv6-only deployments gain the most, because they avoid running two forwarding planes.

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

An SRv6 SID is a 128-bit address that encodes structure rather than a flat identifier: a locator (the routable part - here 2001:db8:100::/48, usually broken into a /32 or /48 block plus a node sub-block), a function (the behaviour the node executes) and, optionally, an argument carrying per-instance parameters such as a VPN identifier or a service index. That is what makes SRv6 programmable: a new behaviour is a new function value, not a new label allocation convention.

Micro-segment (uSID) encodings compress the same idea: a carrier block plus 16-bit SID fragments packed into a single address, so a path of several hops fits in one header and the "128 bits per segment is too much overhead" objection weakens considerably. uSID support is a hardware question, not a standards one, and it is the feature that makes SRv6 usable in high-density access and aggregation designs, not just in a core with three hops.

Overhead and MTU Maths

The comparison is easier with numbers. Take a 1,500-byte payload on a link with a 1,500-byte MTU:

• SR-MPLS, four labels - 1,500 + 16 = 1,516 bytes, so either the transport raises the MTU to 1,516+ or the payload is clamped. In practice provider cores run jumbo MTU for exactly this reason.
• SRv6, IPv6 outer header plus SRH with four segments - a 40-byte IPv6 header, an 8-byte routing header base, then 16 bytes per segment plus padding: comfortably over 100 bytes of encapsulation. The payload that fits without fragmentation drops by nearly 10 percent unless MTU is raised.
• SRv6 with uSID - the same four hops inside the 128-bit address, so the encapsulation approaches the SR-MPLS case at the cost of a stricter locator design.

Whichever plane you pick, the MTU has to be raised end to end, and the interfaces, the optical transport and every tunnel in between have to agree. This is the part of an SR migration that is genuinely infrastructure work rather than routing configuration; see the parameters in DWDM system components and the power budgets in optical transceiver dBm thresholds.

Hardware and Forwarding Maturity

SR-MPLS is the conservative choice because the data plane already exists. Any platform with MPLS forwarding, an IGP with SR extensions and a modern control plane supports it; the SID list is pushed and popped by the same hardware that handles LDP and BGP labels, at line rate, on ASICs and NPUs designed a decade ago.

SRv6 needs several things at once: an IPv6 forwarding plane at full rate with no performance cliff, the ability to parse and process the segment routing header in hardware rather than punting to the CPU, and enough SRH and uSID table depth for the path lengths in the design. Where those are present the forwarding is fast; where they are not, a "supported" feature can collapse to software processing under load. This is why SRv6 availability differs by line card within the same chassis on some vendors, and why a pilot on a lab box proves less than it appears to.

Traffic Engineering, Fast Reroute and Flex-Algo

Both planes carry the SR traffic-engineering stack, with different ergonomics:

• TI-LFA computes a backup path at every node from the SID list and the topology database, delivering sub-50 ms repair without RSVP-TE state. On SR-MPLS this is mature and widely deployed; see our TI-LFA configuration guide.
• Explicit paths. An SR-TE policy is a short SID list plus a candidate-path strategy. Label stacks make this compact; segment lists make it verbose but readable, since every hop appears as an address.
• Flex-Algo gives the IGP multiple topologies with different metric types - latency-optimised, bandwidth-optimised - computed inside the routing protocol rather than configured as tunnels. SLA routing becomes "put this prefix in algorithm 128" instead of a policy database.
• Slicing and service chaining. SRv6's real differentiator: "send through the firewall, then the load balancer, then to this VPN" is a list of function SIDs, with no extra protocol and no per-vendor feature to configure.

Long SR-TE paths are where the label-stack depth limit bites: each hop in an explicit path consumes one label, and deep stacks push hardware limits and MTU at the same time. SRv6 lists read better and pack better with uSID, but require hardware that can process the full header.

How to Decide

• Existing MPLS core, mixed hardware - SR-MPLS. Reuse the forwarding plane you already have, and interoperate with legacy LDP/RSVP domains during the transition.
• IPv6-only greenfield, modern silicon, service chaining requirements - SRv6. The whole point is native programmability without a separate label plane.
• Hybrid - SR-MPLS for transport with SRv6 selected where specific functions require it; migration stages are now well documented by the vendors.
• Neither, yet - if the requirement is simply faster convergence on a small L3 fabric, ECMP with BFD will deliver it with less change. Policy and prefix management stay identical either way - see IOS-XR RPL route policy and BGP route reflector design.

Whichever plane you choose, plan the optical and MTU budget first: the transport below SR still has to carry the extra header, so the parameters in DWDM system components and the power budgets in optical transceiver dBm thresholds are part of the design. Origin validation and hijack protection on the BGP layer above are covered in RPKI deployment.

Migration and Interworking

Nobody replaces a core in one weekend, so the transition questions matter as much as the end state:

• SR-MPLS over an MPLS core. SR-capable and legacy nodes can coexist; keep LDP running on the legacy segment while SR islands grow, and use mapping services (SR/LDP interworking, or the vendor's equivalent) at the boundary while you plan the removal.
• SR-MPLS to SRv6. Vendors document interworking at domain edges, typically through a translation or a dual-stack border where the label stack is mapped to a segment list. Treat these borders as handover points with their own capacity and MTU budgets, because that is where encapsulation grows twice.
• Mixed vendor domains. SID allocation conventions differ more than the standards suggest; agree on the SRGB and the SID index plan, then verify with an end-to-end traceroute of the SID list before cutover.

Test the failure cases, not just the working path: shut a link with traffic flowing and verify TI-LFA returns traffic before the IGP reconverges, then confirm the monitoring still reports the new path. A migration is done when the degraded states are as predictable as the happy path.

Security and Operational Considerations

Segment Routing moves complexity rather than removing it, and two areas deserve explicit design attention on either plane:

• Control-plane trust. SIDs are advertised by the IGP, so anyone who can inject a prefix advertisement can advertise a SID. Authentication and prefix filtering on IS-IS or OSPF, plus origin validation on the BGP layer above, are not optional extras in an SR core.
• Header-based attacks. SRv6 packets carry an explicit path, and a device that processes segment lists from untrusted sources can be steered by them. Configure locator ranges so that only your own address space can be used as SIDs, and discard packets claiming foreign locators.
• Coexistence and capability mismatch. A node that does not understand the encapsulation drops the traffic, so staging matters: enable the new plane on the whole path before expecting end-to-end reachability.
• Observability. Label stacks are invisible to tools that read IP headers, and segment lists make traceroute output long. Plan for packet capture at the edge of the SR domain and for a monitoring stack that understands the encapsulation - the commands in MPLS VPN troubleshooting and TI-LFA verification are the starting point.

Finally, decide who owns the SID plan. It is a numbering plan that every node must agree on, and it belongs in the same change-control process as the IP addressing and the VLAN plan - not in a per-engineer spreadsheet that drifts the moment two people configure different sites.

A Short Deployment Checklist

• Confirm platform and line-card support for the chosen plane, including SRH processing on the specific cards you bought.
• Align the SRGB (and the locator plan for SRv6) across the domain before enabling anything.
• Raise MTU end to end and test with a 1,500-byte payload that must not fragment.
• Enable SR under the IGP address family, then verify SIDs in the IGP database and in the LFIB or the IPv6 FIB.
• Add TI-LFA, then test repair, not just convergence.
• Decide the security posture: RPKI and route filtering above (see RPKI deployment), and for MPLS-layer troubleshooting the techniques in MPLS VPN troubleshooting.
• Document the segment list convention and the SID plan where the next engineer will find it.

原文链接：https://blog.ipspace.net/2022/09/greenfield-sr-mpls-srv6/