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.

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

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

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.

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