SR-MPLS Migration with LDP Islands and Anycast DNS
Northline is a regional ISP with 12 PoPs, 240 routers, a 400G core and 100G edge. Its transport runs LDP plus RSVP-TE for 120 bandwidth-constrained tunnels, 8,000 VPNv4 routes, and 24 multicast streams. Thirty-five percent of access routers are older LDP-only platforms, and replacing them is not funded in the 18-month plan. Northline wants to introduce SR-MPLS and a central path computation element (PCE), reduce dependence on RSVP-TE, and offer two anycast DNS service instances from PoPs A and B. The design must avoid customer downtime, preserve multicast, and keep legacy access routers forwarding. Current traffic growth is 30% year over year, and the core has 40% headroom. The CTO has asked for an architecture that can start in the core and extend to the edge without a flag-day cutover.
1. Recommend how to interwork SR-MPLS with the LDP-only access routers without a flag-day. What role should a mapping server play, and where would you place it?
Read the worked answer
Use a staged SR/LDP interworking model rather than converting every router at once. The legacy access routers stay on LDP; the SR core uses prefix-SIDs for SR-capable prefixes and a mapping server to advertise SID mappings for LDP-only prefixes. SR nodes act as mapping clients and install a SID for those legacy prefixes, so traffic entering the SR domain can be steered toward the LDP island without an end-to-end SR path.
At the boundary, the SR and LDP domains must stitch labels in both directions: LDP-only routers need a labeled path to SR locators, and SR routers need SIDs for LDP prefixes. Advertise only the SR locators that are needed, not every core loopback. Place the mapping server function on a redundant pair of core routers or route reflectors, not on access devices, so its withdrawal does not isolate an island. Keep the SID index range stable and document it. Validate MTU and label-stack depth on legacy platforms. This preserves multicast reachability, because the multicast topology still follows the IGP/LDP paths while SR is introduced around it.
2. Compare a stateless PCE with a stateful PCE for the 120 RSVP-TE tunnels and the new SR policies. Which would you deploy, and what topology feed would you use?
Read the worked answer
A stateless PCE computes a path on request but does not retain LSP state, so it cannot reliably track delegated tunnels, reoptimize them, or reconcile a failed path without external inventory. A stateful PCE maintains the LSP database, accepts delegation from PCCs, and can recompute and update both RSVP-TE tunnels and SR policies. With 120 TE tunnels and a requirement to reduce RSVP-TE dependence, the stateful model is the better fit because it supports centralized bandwidth optimization and a controlled migration from RSVP-TE to SR.
Use PCEP between the PCE and head-end routers, with a redundant PCE pair and state synchronization. Feed topology and TE attributes with BGP-LS from the IGP and BGP, rather than relying on SNMP polling or static configuration. Start in monitor-only mode, compare PCE-computed paths with the current tunnels, then delegate a small set of low-risk tunnels. For SR policies, have the PCE return an explicit segment list and test it against TI-LFA behavior. Keep a documented fallback to local CSPF if both PCEs are unavailable.
3. For the anycast DNS service, would you use an anycast prefix-SID? Explain how forwarding and failure behavior change compared with advertising the service prefix via BGP only.
Read the worked answer
An anycast prefix-SID is appropriate if both DNS PoPs advertise the same service prefix with the same SID and identical service capacity. Inside the SR domain, IGP forwarding sends users to the nearest PoP or ECMP across equal-cost paths, which is typically better for DNS latency than BGP best-path selection, especially when BGP policy prefers a distant PoP.
With BGP-only anycast, the service prefix is chosen by BGP path selection; failover depends on BGP withdrawal and reconvergence, which can be seconds. With an anycast SID, the IGP withdraws the SID when a PoP fails, and TI-LFA or LFA can preinstall a backup path, so intra-domain failover is sub-second. The trade-off is that the SID attracts traffic based on IGP reachability, not DNS load or health. Both PoPs need enough capacity for the shifted load, and the service must be stateless enough to survive a switch. If DNS uses TCP, existing connections may reset on failover; test that behavior. Keep BGP anycast for the service VIP and use the anycast SID as transport, not as a replacement for health-aware load balancing.