MPLS-TE to SR-TE Migration: A Practical Path

RSVP-TE has carried traffic-engineered traffic for twenty years, and it still works — the problem is what it costs: a signalling protocol running on every node, soft-state refreshes to babysit, per-tunnel state that grows linearly with the number of paths, and a fast-reroute scheme that needs pre-signalled backup tunnels. SR-TE replaces all of that with segment lists carried in the packet: no per-tunnel state on transit routers, no RSVP, and TI-LFA as the protection mechanism. The migration is not a flag day, though; it is a coexistence exercise. This guide walks through the practical path: what SR-TE touches, how to map RSVP tunnels to SR policies, and how to cut traffic across without dropping it.

What changes and what does not

Label distribution changes from RSVP to an IGP extension: Prefix-SID on OSPF or IS-IS distributes node labels, and Adjacency-SID covers the cases where you need a specific link. The data plane stays MPLS — same label stack, same forwarding hardware — which is why SR-MPLS migrations are far less disruptive than they first appear.

Stage 1 — enable segment routing alongside RSVP

The first stage changes nothing about forwarding: SR is enabled in the IGP, Prefix-SIDs are allocated, and RSVP tunnels keep carrying the live traffic. Do this during a normal window and verify that every router has a prefix-SID and that label stacks resolve.

router isis 1
 address-family ipv4 unicast
  segment-routing mpls
  !
 interface Loopback0
  address-family ipv4 unicast
   prefix-sid index 1
 !
 segment-routing mpls sr-prefer
!
show isis segment-routing prefix-sid-map
show mpls forwarding labels | include "SID"
show mpls lsd bindings

Do not enable sr-prefer on day one for LDP coexistence — that flag changes which label source wins for the same prefix and belongs in the cutover stage. In a pure RSVP environment, verify instead that the SR label stack for each SR policy tail-end resolves through the IGP shortest path.

Stage 2 — build SR policies that mirror the RSVP tunnels

For each RSVP tunnel that carries real traffic, create an SR policy with the same endpoint and an explicit or dynamic path. The usual pattern is one candidate path with a segment list built from adjacency SIDs when the exact RSVP path must be preserved, and a dynamic path when IGP-based shortest-path segment lists are acceptable.

segment-routing
 traffic-eng
  segment-list SL-HOP1
   index 10 mpls label 16002
   index 20 mpls label 16003
  !
  policy POL-TO-PE2
   color 100 end-point ipv4 10.0.0.2
   candidate-paths
    preference 200
     explicit segment-list SL-HOP1
    !
    preference 100
     dynamic
      metric type te
      !
   !
  !
 !
!
show segment-routing traffic-eng policy color 100 endpoint ipv4 10.0.0.2
show segment-routing traffic-eng forwarding policy

Stage 3 — steer traffic and verify before you decommission

Steering is where you have choices: BGP colour communities (the cleanest, since the policy is chosen per-prefix), static routes pointing at the policy, or autoroute announce with a metric that makes the policy preferred over the RSVP tunnel. Whichever you pick, verify the forwarding entry before removing anything.

show segment-routing traffic-eng policy detail
show mpls forwarding
show mpls forwarding labels 16002
traceroute 10.0.0.2 source Loopback0

Check four things: the policy's operational state is up with the expected candidate path active; the label stack in the forwarding entry matches the segment list; a traceroute follows the intended path (not the IGP path); and traffic counters on the policy increase while the RSVP tunnel counters fall. Only then disable the RSVP tunnel — and do it one tunnel at a time, keeping the RSVP configuration in place for a rollback window rather than deleting it.

Rollback and the mistakes that cost windows

Rollback is trivial if you kept the RSVP tunnels: remove the steering entry (withdraw the colour community, delete the static route) and the head-end falls back to the RSVP tunnel or plain IGP. What makes rollback hard is deleting RSVP configuration too early, and what makes cutover hard is enabling sr-prefer at the same time as the change for MPLS forwarding of IGP prefixes — that combination can move traffic for all prefixes at once rather than the ones you are deliberately steering. Keep the two changes separate, and remember that TI-LFA must be validated separately: it protects the SR policy's underlying IGP paths, and a policy with an explicit adjacency-SID segment list bypasses the TI-LFA shortcut entirely.

Designing the steering policy before you touch a router

The steering mechanism decides how much of your network changes in one window, and it deserves to be chosen on paper rather than by whichever command is easiest to type. There are three options, and they differ in blast radius.

Colour-based steering is the one to start with. You announce the prefix with a colour extended community at the head-end, the SR policy is matched on colour plus endpoint, and traffic follows the policy only for the prefixes you tagged. Withdrawing the community puts those prefixes back on the IGP path with no configuration change on transit routers — which means your rollback is a single BGP attribute, not a config rollback across the core.

route-policy SR-STEER
  set extcommunity color 100
end-policy
!
router bgp 65100
 address-family ipv4 unicast
  network 10.10.0.0/16 route-policy SR-STEER
 !
!
show bgp ipv4 unicast 10.10.0.0/16 | include Color

Capacity and scale: what replaces RSVP's accounting

One of RSVP-TE's quieter benefits was that the head-end knew the reserved bandwidth of every tunnel, which is how CSPF avoided over-subscribing a link. SR-TE with dynamic paths does not carry that reservation by default: the IGP metric is the steering input, and the network relies on capacity planning rather than on per-flow reservation. If your design depended on explicit bandwidth guarantees, this is the part of the migration that needs a deliberate answer — either use SR-TE with a bandwidth-aware path computation element, or accept that traffic engineering becomes metric-based and manage capacity with monitoring instead of reservation.

segment-routing
 traffic-eng
  pce
   address ipv4 10.0.0.100
  !
  policy POL-DYN
   color 200 end-point ipv4 10.0.0.9
   candidate-paths
    preference 100
     dynamic
      pcep
      !
     !
    !
   !
  !
 !
!
show segment-routing traffic-eng policy color 200 endpoint ipv4 10.0.0.9

Scale improves in the other direction: transit routers hold no per-tunnel state, so the control-plane cost of a thousand policies sits on a handful of head-ends rather than on every router in the path. On platforms where the label stack depth is limited, deep explicit segment lists have to be compressed into a single binding SID with a shorter stack — that is the trick that keeps long explicit paths viable on hardware with shallow stack support.

A cutover runbook

1. Enable SR in the IGP on all nodes; verify every router has a prefix-SID and that the SR label stack resolves for the tail-end addresses.
2. Validate TI-LFA independently with a link-down test, so you know protection works before the policy carries production traffic.
3. Create the SR policy for one low-risk destination; confirm the forwarding entry and that traffic is still on the RSVP path.
4. Apply colour-based steering for that destination; watch latency and loss for a full monitoring cycle.
5. Repeat for the remaining destinations in batches; keep every RSVP tunnel configured throughout.
6. After the final batch is stable for a week, disable RSVP tunnels one at a time, watching for any residual path that depended on them.
7. Only then remove the RSVP configuration, and keep the change documented with the metric and policy identifiers you used.

# per-stage checks worth scripting
show segment-routing traffic-eng policy color 100 endpoint ipv4 10.0.0.2 | include "State|Preference"
show mpls forwarding labels | include "1600"
show bgp ipv4 unicast 10.10.0.0/16 | include "Color|Local"
show mpls traffic-eng tunnels brief
show ip route 10.0.0.2 | include "via|tunnel"

FAQ

Do I need to change the MTU for SR-MPLS? No. SR-MPLS uses the same label mechanism as LDP and RSVP and the same encapsulation sizes, so existing MTU planning carries over unchanged.

Can LDP, RSVP and SR coexist? Yes, and during migration they will. The only sharp edge is the preference order for a prefix when more than one source offers a label; change that order deliberately and as a separate step.

How do I know an SR policy is actually in use? Compare counters. A policy that is programmed but unsteered shows no traffic growth; the policy's forwarding statistics and the IGP path counters together tell you which path packets are taking.

Is TI-LFA a requirement? For a like-for-like replacement of RSVP fast reroute, yes — otherwise you have removed the protection mechanism and not replaced it. Enable it per interface and test it with a link-down drill before the cutover, not during it.

Quick reference: the migration in one table

The stage that gets skipped in practice is stage two. Without a protection drill, the migration replaces a protected transport with an unprotected one and nobody notices until the first link failure — which is exactly the moment the design is supposed to earn its keep.

Related Reading

Related reading: SR-MPLS vs SRv6: Which Segment Routing Data Plane, MPLS TE with RSVP-TE: Tunnels, CSPF and FRR, TI-LFA with Segment Routing: Topology-Free Fast Reroute

原文链接：https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/215215-segment-routing-overview-and-migration-g.html