Could you run an MPLS-TE-only MPLS/VPN network without LDP?

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 ;)


  1. Well there is also option of statically assigning labels but ... yeah.
  2. In enterprise environments, especially when utilizing Juniper devices, it's actually more common to use RSVP-only based LSPs and not to run LDP at all. Works just fine, if you don't need to add new PE-routers too often. And if you have an NMS with provisioning possibility, it doesn't even matter if you add more routers every now and then. Of course the network will require a lot more state information which has to be soft-refreshed every now and then, but if we are talking about <100 PE-routers, it's not a problem with current hardware having a lot of CPU and ASIC-based processing power.
    1. ... and what happens when one of those tunnels fails for whatever reason?
    2. Fast reroute kicks in. :) Or a backup path. Or the RSVP lsp will come up if you signal it as loose and tie it to a loopback. Anyway if you have L3 VPN in your network and an lsp fails you'll have the same problems with ldp. Come to think of it I haven't really seen many mpls deployments without vpns or te around.
    3. @Jent You can use an NMS or just script it. On Cisco you can use the auto-tunnel feature but I would not really recommended for a big network.
  3. I just did a test of MPLS VPN over TE-FRR with LDP enabled. When doing ping, the packets goiong trough the backup tunnel have 3 stacked labels. The top one should be RSVP-LABEL for backup LSP. ,However the return packets have only 2 labels. The top one should be LDP-LABEL and inner one should be VPN label. This means that the return traffic has to wait the convergence of IGP, which will damage the FRR advantage.

    My question is: Fast reroute is only for one direction of traffic. could we do two directions?
    1. MPLS TE tunnels are unidirectional. If you want to have FRR in both directions, you need two tunnels.
  4. On Cisco, you can use one hop auto tunnel with backup (RSVP), and enable LDP on the RSVP tunnels. This allows you to have the end to end LDP path protected by MPLS-TE FRR, which is quite nice as it does not have much state.

    I was just looking at similar ways to do the same on Juniper. Initial thoughts would be partitioned auto tunnel mesh groups with link protection and ldp-tunneling. Haven't tried it yet, but any thoughts as to the viability of that?
Add comment