Stitching in the SR-to-LDP direction

Prerequisites

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

In Figure: Stitching in the LDP-to-SR direction, the boundary router R1 performs the following procedure to effect stitching:

Procedure

  1. Router R1 is at the boundary between a SR domain and a 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).

  2. R1 receives an LDP FEC for prefix X owned by router Rx further down in the LDP domain.

    RTM in R1 shows that the interface to R2 is the next-hop for prefix X.

  3. LDP in R1 resolves this FEC in RTM and creates an LDP ILM for it with, for example, ingress label L1, and points it to an LDP NHLFE toward R2 with egress label L2.
  4. Later on, R1 receives a prefix-SID sub-TLV from the mapping server R5 for prefix X.
  5. IGP in R1 is resolving in its routing table the next-hop of prefix X to the interface to R2. R1 knows that R2 did not advertise support of Segment Routing and, therefore, SID resolution for prefix X in routing table fails.
  6. IGP in R1 attempts to resolve prefix SID of X in TTM because it is configured to stitch SR-to-LDP. R1 finds a LDP tunnel to X in TTM, instructs the SR module to program a SR ILM with ingress label L3, and points it to the LDP tunnel endpoint, consequently stitching ingress L3 label to egress L2 label.
    Note:

    • Here, two ILMs, the LDP and SR, are pointing to the same LDP tunnel one via NHLFE and one via tunnel endpoint.

    • No SR tunnel to destination X should be programmed in TTM following this resolution step.

    • A trap is generated for prefix SID resolution failure only after IGP fails to complete step 5 and step 6. The existing trap for prefix SID resolution failure is enhanced to state whether the prefix SID which failed resolution was part of mapping server TLV or a prefix TLV.

  7. The user enables segment routing on R2.
  8. IGP in R1 discovers that R2 supports SR via the SR capability.

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

  9. The operator disables the LDP interface between R1 and R2 (both directions) and the LDP FEC ILM and NHLFE for prefix X are removed in R1.
  10. This triggers the re-evaluation of the SIDs. R1 first attempts the resolution in routing table and because the next-hop for X now supports SR, IGP instructs the SR module to program a NHLFE for prefix-SID of X with egress label L4 and outgoing interface to R2. R1 installs a SR tunnel in TTM for destination 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.

  11. Later, router Rx, which owns prefix X, is upgraded to support SR. R1 now receives a prefix-SID sub-TLV in a ISIS or OSPF prefix TLV originated by Rx for prefix X. The SID information may or may not be the same as the one received from the mapping server R5. In this case, IGP in R1 prefers the prefix-SID originated by Rx and update the SR ILM and NHLFE with appropriate labels.
  12. Finally, the operator cleans up the mapping server and removes the mapping entry for prefix X, which then gets withdrawn by IS-IS.
Parent topic: LDP-SR stitching for IPv4 prefixes