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 1, the boundary router R1 performs the following procedure to effect stitching:
-
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).
-
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.
-
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.
-
Later on, R1 receives a prefix-SID sub-TLV from the mapping server R5 for
prefix X.
-
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.
-
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.
-
The user enables segment routing on R2.
-
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.
-
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.
-
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.
-
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.
-
Finally, the operator cleans up the mapping server and removes the mapping
entry for prefix X, which then gets withdrawn by IS-IS.