SR-MPLS migration on an LDP/RSVP network with an SRv6 pilot
A 10-year-old MPLS network has 42 PE and 180 P routers on 7750 SR and 7250 IXR, running LDP for service labels plus 30 manually provisioned RSVP-TE tunnels. A new SLA requires TI-LFA repair within 50 ms for any single link or node failure. Two maintenance events caused 900 ms outages during LDP convergence, and a traffic study shows the TE tunnels average 40% utilisation while some LDP paths run at 85%. Access links are 1500-byte MTU and the core is 9214. The operator wants fewer protocols, automated traffic steering, and an SRv6 pilot for one government customer. About 20 older line cards support SR-MPLS but not SRv6.
1. SR-MPLS or SRv6 for the main migration? Justify with the MTU and hardware facts.
Read the worked answer
SR-MPLS now. SR-MPLS reuses the existing MPLS forwarding plane and label stack, so the 1500-byte access MTU is untouched and the 20 older line cards that support SR-MPLS but not SRv6 remain usable. The core MTU of 9214 is more than sufficient.
SRv6 payload cost. An SRv6 encapsulation adds the IPv6 header (40 bytes) plus the segment routing header and segment list (8 + 16n bytes), so a 1500-byte access link will either fragment or drop. uSID compresses this substantially, but it still requires hardware support and an addressing plan. With 20 line cards unable to forward SRv6, an enterprise-wide SRv6 migration is not justified.
Recommendation. Migrate the core to SR-MPLS with node SIDs and TI-LFA. Run the SRv6 pilot only for the government customer, on a path where MTU is at least 1600 end-to-end, and treat it as a technology trial with a clear exit criterion. Do not mix SRv6 into the shared transport until the older cards are replaced and the MTU is verified hop by hop.
2. Give the migration sequence that reaches sub-50 ms TI-LFA without a flag day.
Read the worked answer
Phase 1 - enable SR everywhere. Configure a consistent SRGB on all 222 routers and verify it matches. Keep LDP running. Enable LDP-to-SR mapping so SR-capable nodes can interwork with any node that is still LDP-only; this is the safety net that removes the need for a flag day.
Phase 2 - prefix and node SIDs, then TI-LFA. Allocate prefix SIDs, then enable TI-LFA with node SIDs. Test in the lab against link, node and shared-risk-link-group failures before touching production. Confirm the repair path is computed and installed, not signalled on failure.
Phase 3 - timer budget. With 10 ms BFD × 3 = 30 ms detection plus about 10 ms repair, you are at roughly 40 ms, leaving headroom under 50 ms. Verify the actual BFD interval on each interface; a default 100 ms BFD will blow the SLA before TI-LFA is even exercised.
Phase 4 - RSVP to SR-TE. Migrate the 30 TE tunnels one at a time to SR-TE policies, with PCE-computed paths. Drain and delete each RSVP tunnel only after the SR policy carries traffic and passes a failure test.
Phase 5 - remove LDP once every node is SR-capable and the mapping is no longer needed.
3. How does SR-TE with a PCE correct the 40%/85% utilisation imbalance, and what would you measure?
Read the worked answer
Why the imbalance exists. Thirty manually provisioned RSVP tunnels reflect last year's traffic matrix. They pin traffic on paths that are no longer optimal, while LDP follows IGP shortest path and overloads the same links. Nobody re-optimises because doing so means touching every tunnel by hand.
What SR-TE plus PCE changes. A stateful PCE holds the topology, the bandwidth reservations and the policies, and computes paths centrally, so it can move a policy's segment list off an 85% link onto a 40% one without per-node tunnel configuration. Policies can carry bandwidth constraints and disjointness constraints, and re-optimisation can run on a schedule rather than a change window. This also avoids the N×M policy explosion of distributed SR-TE by keeping transport policies between a limited set of PE pairs.
What to measure. Per-link utilisation with a p95 and a peak, per-policy delivered bandwidth versus reserved, path delay and jitter, and the number of policies whose computed path differs from the installed path (drift). Track the maximum link utilisation before and after re-optimisation; the target is to hold the busiest link below about 70% while keeping reserved bandwidth honest. If reservations are not enforced, the PCE will optimise against fiction.