LDP Mapping Server for Interoperability of Segment Routing with LDP Overview
In an LDP network with gradual deployment of segment routing, there can be islands of devices that support either only LDP, or only segment routing. For the devices to interwork, the LDP mapping server feature is required to be configured on any device in the segment routing network.
The LDP mapping server feature is implemented using either OSPF or ISIS.
Interoperability of Segment Routing with LDP Using OSPF
To implement interoperability of segment routing with LDP using OSPF, an extended prefix link-state advertisement (LSA) with Range type, length, and value (TLV) for all the LDP prefixes is generated, and mapping routes corresponding to the prefix is installed in the inet.3 and mpls.0 routing tables.
Figure 1 is a simple LDP network topology used to illustrate the interoperability of segment routing devices with LDP devices using OSPF. The topology has six devices (Devices R1, R2, R3, R4, R5, and R6) with LDP-to-segment routing migration.
In the above topology, Devices R1, R2, and R3 are capable of only segment routing, Devices R5 and R6 are capable of only LDP, and Device R4 supports both LDP and segment routing. Here, Device R1 cannot interwork with Device R6 because of interoperability issues.
To enable interoperability between the LDP-capable devices and segment routing devices, any one interface of the device in the segment routing network segment is configured as the LDP mapping server. Currently, the mapping server configures prefixes under the [edit routing-options source-packet-routing] hierarchy level. With this feature, the LDP mapping server configuration if applied under the [edit protocols ospf] hierarchy level, where a new extended prefix LSA with range TLV for all LDP prefixes is advertised by OSPF. The device capable of segment routing analyze the extended prefix range TLV and mapping routes corresponding to the prefix are installed in the inet.3 and mpls.0 routing tables.
For example, in Figure 1, if Device R2 (in the segment routing network) is the LDP mapping server, the following configuration is included:
The IP address used as the start-prefix is the loopback address of the device in the LDP network (Device R5, in this example).
When the LDP mapping server configuration is committed on Device R2, the extended prefix range TLV is flooded across the OSPF area. The devices capable of segment routing (Devices R1, R2, and R3) install OSPF segment routing routes for the specified loopback address with a segment ID (SID) index. The SID index is also updated in the mpls.0 routing table by the segment routing devices.
Starting in Junos OS Release 19.1R1, segment routing-LDP border router can stitch segment routing traffic to LDP next-hop and vice versa.
Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using OSPF
Prefix conflict is only detected at the source configuration. When there is a prefix range conflict, the prefix SID from the lower router ID prevails. In such cases, a system log error message—RPD_OSPF_PFX_SID_RANGE_CONFLICT—is generated.
IPv6 prefixes are not supported.
Flooding of the OSPF Extended Prefix Opaque LSA generated by the segment routing mapping server for autonomous systems (ASs) is not supported.
Inter-area LDP mapping server functionary is not supported.
ABR functionality of Extended Prefix Opaque LSA is not supported.
ASBR functionality of Extended Prefix Opaque LSA is not supported.
Segment routing mapping server Preference TLV is not supported.
Interoperability of Segment Routing with LDP Using ISIS
To implement interoperability of segment routing with LDP using ISIS, a server-client configuration is required under protocols ISIS and LDP, respectively, and routes from the inet.3 or inet.0 routing tables are used for stitching of segment routing LSP with an LDP LSP and vice-versa.
Figure 2 is a simple LDP network topology used to illustrate the interoperability of segment routing devices with LDP devices using an LDP mapping server-client feature. The topology has four provider edge (PE) devices (Devices PE1, PE2, PE3, and PE4) and four provider (P) devices (Devices P5, P6, P7, and P8).
Devices PE3, PE4, P6, P7 and P8 are the LDP capable devices. Devices PE1, PE2, P5 and P6 are capable of segment routing with segment routing global block (SRGB) value of 100 and 200, and node segment IDs (SIDs) value of 101, 102,105 and 106, respectively.
For a service flow to be tunneled to-and-from Device PE3 and Device PE1 using a continuous MPLS tunnel, the islands of devices supporting segment routing and LDP must interoperate.
LDP Mapping Client Functionality (LDP to Segment Routing)
The LDP client functionality is the LDP-to-segment routing mapping, that is the right-to-left traffic flow in Figure 2. On Device P6, an LDP egress policy is configured to advertise all node SIDs and prefix SIDs from the segment routing network on the left. As a result, on Device P6, LDP advertises Devices PE1, PE2 and P5 as the egress FEC label bindings to Device P7.
Device PE3 has learned a service route with Device PE1 as the protocol next hop. Device PE3 has an LDP label binding from the P8 next hop for the PE1 FEC. As a result, Device PE3 sends its service packet to Device P8 as per classic LDP behavior. Device P8 has an LDP label binding from its P7 next hop for the PE1 FEC, therefore Device P8 forwards to Device P7 as per classic LDP behavior.
Device P7 has an LDP label binding from its P6 next hop the PE1 FEC, as a result, Device P7 forwards to Device P6 as per classic LDP behavior.
Device P6that is acting as an LDP egress for the PE1 FEC, stitches and swaps the incoming egress LDP label for the PE1 FEC with an equivalent segment routing node SID (101 in this example) to forward the traffic to Device P5.
Device P5 pops 101 SID assuming that Device PE1 advertised its node segment 101 with the penultimate-pop flag set, and then forwards traffic to Device PE1. Device PE1receives the tunneled packet and processes the service label.
As a result, the end-to-end MPLS tunnel is built from an LDP LSP from Device PE3 to Device P6, and the related node segment from Device P6 to Device PE1.
LDP Mapping Server Functionality (Segment Routing to LDP)
The LDP server functionality is the mapping of segment routing to LDP, that is the left-to-right traffic flow in Figure 2. On Device P6 the mapping server prefixes configuration is included under the [edit routing-options source-packet-routing] hierarchy level. When the configuration is applied under the specific IGP, the label binding type, length, and value (TLV) for all the LDP FEC-label bindings from the LDP network are advertised as inet.3 LDP routes.
Here, Device P6 acts as a Segment Routing Mapping Server (SRMS) and advertises the following mappings – (P7, 107), (P8, 108), (PE3, 103), (PE4, 104), and (P7, 107). If segment routing was supported on Device PE3, the node SID 103 would have been configured on Device PE3. Because Device PE3 does not support segment routing, the policy is configured at the SRMS on Device P6, and Device P6 is responsible for advertising the mappings.
These mapping server advertisements are only understood by the segment routing devices. The segment routing devices install the related node SIDs in the MPLS data plane exactly how the node segments had been advertised by the nodes themselves. For instance, Device PE1 installs the node SID 103 with P5 next hop exactly as if Device PE3 had advertised SID 103.
Device PE1 has a service route with PE3 as its protocol next hop. Device PE1 has a node segment for that IGP route – 103 with P5 next hop. As a result, Device PE1 sends its service packet to Device P5 with two labels – the bottom label, which is the service label, and the top label, which is SID 103. Device P5 swaps 103 for 103 and forwards to Device P6. The next-hop for Device P6 is the IGP route PE3, which is not capable of segment routing. (Device P7 does not advertise the segment routing capability). However, Device P6 has an LDP label binding from that next hop for the same FEC (for example, LDP label 1037). As a result, on Device P6, the IGP swaps 103 for 1037 and forwards to Device P7.
Device P7 swaps this label with the LDP-label received from Device P8, and then forwards it to Device P8. The LDP label is popped by Device P8 and forwarded to Device PE3.
Device PE3 receives the tunneled packet and processes the service label. The end-to-end MPLS tunnel is built from a segment routing node from Devices PE1 to P6, and an LDP LSP from Devices P6 to PE3.
Segment Routing to LDP Stitching
When the IGP segment routing LSP's IP next hop does not support segment routing, the IGP looks at the inet.3 routing table to see if there is an LDP LSP to the same prefix. If the LDP LSP is present, the IGP stitches the segment routing LSP to the LDP LSP by programming a MPLS transit route that swaps the segment routing label with the LDP label to switch traffic from segment routing domain to the LDP domain.
Figure 3 illustrates the stitching of segment routing and LDP LSPs for enabling interoperability.
In the topology, Device PE3 is LDP-capable and does not support segment routing. The mapping server in the segment routing domain can advertise label binding TLV for devices P7, P8 and PE4. In such a scenario, Device PE1 can have both prefix SID and remote label binding TLV and SID to reach Device PE4. However, Device PE1 prefers prefix SID over remote label binding TLV while programing its ingress segment routing route for Device PE4. As a result, Device PE1 uses the segment routing LSP end-to-end to send traffic to Device PE4, and uses the segment routing-to-LDP stitching while sending traffic to Device PE3.
Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS
Penultimate-hop popping behaviour for label binding TLV is not supported.
Advertising of range of prefixes in label binding TLV is not supported.
Segment Routing Conflict Resolution is not supported.
LDP traffic statistics does not work.
Nonstop active routing (NSR) and graceful Routing Engine switchover (GRES) is not supported.
ISIS inter-level is not supported.
RFC 7794, IS-IS Prefix Attributes for Extended IPv4 is not supported.
Redistributing LDP route as a prefix-sid at the stitching node is not supported.