LDP migration and TI-LFA lab

Theoretical foundations and architecture

Laboratory: a phased migration from LDP to Segment Routing (SR-MPLS) with minimal risk to services. On a live network a hard cutover of hundreds of nodes is not possible, so the migration goes through coexistence of LDP and SR (ships-in-the-night), SR/LDP interworking (RFC 8661) and the Segment Routing Mapping Server (SRMS). The SRMS advertises prefix-SID bindings on behalf of nodes that do not support SR yet, and border nodes stitch SR and LDP segments. When SR reachability and TI-LFA are verified on all nodes, the preference is switched to SR with a platform-specific setting (for example sr-prefer on Cisco). After L3VPN/EVPN services are verified and monitored, LDP is removed. Every step must be verified and have a rollback plan: change windows and tests are not replaced by the word hitless.

Why the migration is done in stages

Moving from LDP to SR-MPLS cannot be done in one night: equipment in different cities is upgraded in turn, some nodes do not support SR or lack a licence, and services (L3VPN, EVPN, VPWS) must not suffer. Therefore LDP and SR coexist: both protocols populate the LFIB, and the choice between them is made by an operational preference setting. The base document is RFC 8661 (SR and LDP interworking), which relies on RFC 8665/8667 (IGP extensions) and RFC 8402.

Prerequisites

• IS-IS with wide metrics (or OSPF with opaque LSAs), a single SRGB, an index plan without duplicates: reserve indexes for nodes that have not migrated yet.
• All nodes that must be on the SR path support SR-MPLS; the MSD is sufficient for the planned stacks and TI-LFA.
• The core MTU is calculated for the label stack; test large packets with DF before and after the switchover.
• A label range is reserved for the SRGB; make sure it is not occupied by dynamic LDP labels or static labels.

Stages

1. Enable SR next to LDP. The SRGB, a Prefix-SID for every loopback, SR in the IGP. SR labels are already in the LFIB, but the preference stays with LDP: traffic does not change. Monitoring starts, and the SID databases are cross-checked (no conflicts).
2. Interworking through an SR Mapping Server (SRMS). For nodes that do not have SR yet, one or more SRMS advertise a "prefix - SID index" binding on their behalf: in IS-IS this is the SID/Label Binding TLV 149 (flags F, M, S, D, A; S means flooding across the whole domain), in OSPF the Extended Prefix Range TLV with a Prefix-SID and the M flag; the SRMS priority in OSPF is given by the SRMS Preference TLV. The binding does not take effect on the legacy node itself; it lets the other nodes use an SR label for its prefix. The owner's own Prefix-SID normally takes precedence over an SRMS entry, but the exact conflict-resolution rules depend on the implementation.
3. Stitching at the border. A border node with SR and LDP performs two operations (RFC 8661): SR to LDP - the incoming SR label of the legacy node's prefix is swapped for the LDP label received from it; LDP to SR - for the prefix of an SR node the border node advertises an LDP binding and, on receiving an LDP label, substitutes the SR label. This makes the LSP continuous from PE to PE on a mixed path.
4. Switching the preference. Cisco IOS-XE: sr-label-preferred in set-attributes; Junos: SR in IS-IS (L-ISIS) has preference 14 and LDP has 9, so LDP wins by default, and to switch over the LDP preference is raised (set protocols ldp preference 20); Huawei: the order of tunnel types in the tunnel-policy (tunnel select-seq sr-lsp lsp). Switch first on one PE, check the services and only then extend to the domain: this makes rollback a one-command operation.
5. Validation. Check L3VPN/EVPN/VPWS (ping between CEs), traceroute, LSP ping and traceroute for the SR FEC (RFC 8287), interface counters, TI-LFA (coverage and repair lists), behaviour when a link fails and returns, and MTU.
6. Removing LDP. After a soak period (days or weeks): remove LDP from interfaces (no mpls ip, no mpls ldp), then globally; remove SRMS entries for migrated nodes; remove LDP-IGP sync. Until then LDP remains the rollback reserve.

Rollback

As long as LDP has not been removed, rollback consists of switching the preference back: the LFIB already contains LDP labels, so traffic returns without an IGP recalculation. Rollback after LDP removal means configuring LDP again on all links, so do not rush step 6. Rule for the SRMS: first enable the node's own SIDs, then delete its SRMS entry.

Pitfalls

• SID conflict. An index in an SRMS entry equals the index of another node: different routers end up with different winners and traffic goes to the wrong node. All indexes, including the SRMS ones, are kept in a single table.
• A single SRMS. This is a control-plane point of failure; use two SRMS with different priorities.
• PHP and explicit-null at the border. A legacy node does not understand SR labels: on the last hop before it the label must be popped or replaced by an LDP label, otherwise a packet with an unknown label is dropped.
• Preference without readiness. Switching to SR on a PE whose path contains nodes without SIDs and without SRMS entries sends part of the traffic back to LDP or causes loss on paths where the border node has no stitching.
• MTU. An SR stack is longer than an LDP label; the problem shows up only with large packets.
• TI-LFA and nodes without SR. A repair path cannot pass through nodes without a Prefix-SID: coverage stays incomplete until the migration ends.
• Mixed vendors. Different SRGB and preference defaults require explicit checks on every platform.

What remains for later

LDP sessions are needed as long as the network has nodes that get labels only through LDP, and for some services (for example targeted LDP for pseudowires in old configurations). RSVP-TE and SR Policy coexist on one node independently of the LDP-SR migration.

Architecture Diagram & Topology

+---------------------+      LDP-to-SR Interworking (SRMS)      +---------------------+
| Legacy LDP Domain   | <=====================================> | Modern SR-MPLS Core |
| Runs LDP only       |           SR Mapping Server (SRMS)      | Runs IS-IS/OSPF SR  |
| Needs SR translation|        Stitches LDP and SR Labels       | No LDP required     |
+---------------------+                                         +---------------------+

Traffic Flow & Label Stack Scheme

Segment Routing Mapping Server (SRMS) and LDP/SR stitching:
1. The SRMS advertises prefix-to-SID-index mappings on behalf of nodes that do not run SR (they only run LDP).
2. The border node has an SR label (SRGB base + index, for example 16002) for the prefix and an LDP label (from the LDP pool, for example 24005) received from the legacy neighbour.
3. SR -> LDP: the incoming SR label of the legacy node's prefix is swapped for the LDP label received from it.
4. LDP -> SR: for the prefix of an SR node the border node advertises an LDP binding; the incoming LDP label is swapped for the SR label.
5. Traffic crosses the mixed domain during the phased migration; labels differ per domain, so each border does a swap.

State & Parameter Comparison Table

Architectural model and principles