Stitching in the SR-to-LDP Direction

Stitching in the data plane in the SR-to-LDP direction is based on the IGP monitoring the TTM for an LDP tunnel of a prefix matching an entry in the SR TTM export policy.

In Figure: Stitching in the LDP-to-SR Direction, router R1 is at the boundary between an SR domain and an LDP domain and is configured to stitch between SR and LDP. Link R1-R2 is LDP-enabled but router R2 does not support SR or SR is disabled.

The following steps are performed by the boundary router R1 to configure stitching:

  1. R1 receives an LDP FEC for prefix X from router Rx in the LDP domain. The RTM in R1 indicates that the interface to R2 is the next hop for prefix X.

  2. LDP in R1 resolves the received FEC in the RTM and creates an LDP ILM for the FEC with an ingress label (for example, label L1), and points it to an LDP NHLFE toward R2 with egress label L2.

  3. R1 receives a prefix SID sub-TLV from the R5 mapping server for prefix X.

  4. The IGP in R1 attempts to resolve in its routing table the next hop of prefix X over the interface to R2. R1 detects that R2 did not advertise support of SR and therefore the SID resolution for prefix X in the routing table fails.

  5. The IGP in R1 then attempts to resolve the prefix SID of prefix X in the TTM because it detects that it is configured for SR-to-LDP stitching. R1 finds an LDP tunnel to prefix X in the TTM, instructs the SR module to program an SR ILM with ingress label L3, and points it to the LDP tunnel endpoint, therefore stitching ingress label L3 to egress label L2.

    Note:

    • The ILMs for LDP and SR are both pointing to the same LDP tunnel, one via NHLFE and one via the tunnel endpoint.

    • No SR tunnel to destination prefix X should be programmed in the TTM following the resolution of the prefix SID of prefix X in the TTM.

    • If the IGP is not able to resolve the SID resolution for prefix X in step4 and step5, a trap is generated for the prefix SID resolution failure. An existing trap for the prefix SID resolution failure is enhanced to state whether the prefix SID that failed the resolution attempts was part of a mapping server TLV or an IP reachability TLV.

  6. The user enables segment routing on R2.

  7. The IGP in R1 discovers that R2 supports SR.

    Because R1 still has a prefix SID for prefix X from the mapping server R5, it maintains the stitching of the SR ILM for prefix X to the LDP FEC.

  8. The user disables the LDP interface between R1 and R2 in both directions. This causes the LDP FEC ILM and NHLFE for prefix X to be removed in R1 and triggers the re-evaluation of the SIDs.

  9. R1 first attempts the resolution in the routing table. Because the next hop for prefix X supports SR, the IGP instructs the SR module to program an NHLFE for the prefix SID of prefix X with egress label L4 and with an outgoing interface to R2. R1 creates an SR tunnel in the TTM for destination prefix X. R1 also changes the SR ILM with ingress label L3 to point to the SR NHLFE with egress label L4.

    Router R2 now becomes the SR-LDP stitching router.

  10. Router Rx, which owns prefix X, is upgraded to support SR. Rx sends a prefix SID sub-TLV to R1 in an IS-IS IP reachability TLV for prefix X. The SID information may or may not be the same as the information received from the mapping server R5. If the SID information is not the same, the IGP in R1 chooses the prefix SID originated by Rx and updates the SR ILM and NHLFE with the appropriate labels.

  11. The user then cleans up the mapping server and removes the mapping entry for prefix X, which is then withdrawn by IS-IS.