One of my readers sent me a surprising question: “We run only LDP in our MPLS network and need to run RSVP for TE and then phase out LDP. How could we do it?”

My first reaction was “Why would you ever want to do that” and I got no reasonable answer (suggestions, anyone?) but let’s focus on “Could you do it?”

TL&DR summary: You could, but that doesn’t mean you should.

Why do we need end-to-end LSPs?

Most MPLS-based applications (AToM, VPLS, MPLS/VPN, 6PE, BGP-free core) rely on end-to-end LSPs being established across the network. Some of them use the LSP toward the remote PE to transport IP traffic (BGP-free core), others use a stack of two labels (application-specific label and LSP- or MPLS-TE label for remote PE-router) to (1) transport data to remote PE-router and (2) tell the remote PE-router what to do with the data.

Most applications using MPLS break if the LSP is broken (example: route summarization on an ABR) and/or refuse to work if a label for remote peer is not in the local CEF table.

Junos can automatically use MPLS-in-GRE transport if there’s no LSP toward egress MPLS/VPN PE-router, saving you from broken LSPs and potentially introducing interesting MTU issues.

It’s thus mandatory that a PE-router always has an LSP toward each one of its peers (in principle, a PE-router does not need a label toward all other PE-routers, a property that seems to be used heavily in Seamless MPLS, but let’s not overcomplicate things).

What’s wrong with RSVP-only LSPs?

LDP-signaled LSPs are always available – if there’s a path to the destination known to the IGP routing protocol you use in your network, there’s always an associated LSP (assuming you configured LDP correctly).

It’s pretty hard to have guaranteed always-established full mesh of LSPs with traffic engineering tunnels. You could configure automatic establishment of full mesh of tunnels, and all sorts of tunnel protection mechanisms, but if the tunnel establishment ever fails, you’ll be faced with an interesting hard-to-troubleshoot problem (do I have to mention you’ll get the call at 2AM on a Sunday morning at the height of a bachelor party?).

From a more technical perspective, LDP-established LSPs are N-to-1 circuits, whereas RSVP-established LSPs are 1-to-1 circuits. You need O(N) labels in each core router for LDP-established LSPs and (worst case) O(N^2) labels for RSVP-established LSPs. Furthermore, LDP-established LSPs rely on change-driven local signaling (LDP updates), whereas RSVP-established LSPs rely on periodic end-to-end signaling (RSVP soft state has to be refreshed in all nodes along an MPLS TE tunnel).

To summarize

• MPLS TE tunnels are definitely usable, either for traffic steering or fast failover purposes;
• Having a full-mesh of PE-to-PE MPLS TE tunnels in a large network with thousands of PE-routers might not be the best idea you’ve ever had;
• It’s perfectly possible to have a full-mesh of MPLS TE tunnels in network core and run LDP over them;
• MPLS TE tunnels can fail. LDP-established LSPs provide a convenient readily available backup (both Junos and Cisco IOS prefer MPLS TE tunnels over IGP/LDP anyway) without too much overhead;
• If you’re concerned about the number of labels allocated by LDP, allocate them only for loopback interfaces. Default behavior on Junos; easily configurable on Cisco IOS.

Related webinars

None ... but check them out anyway, you might find something interesting ;)