LDP Tunneling over RSVP Paths between LER/LSR for L2VPN/L3VPN.

‎01-21-2020 05:32 AM

Hello J-net community,


I was trying to figure out whether if it's possible or not to achieve a setup that consists of a bidriectional RSVP path between an LER and an LSR which tunnels a LDP session between them, that would be from its role to carry applications such L2VPN and L3VPN to other LERs.


This is a custom setup, so please bear with me, normally we're enabling LDP/RSVP on all core-facing interfaces, the main purpose for that setup is to carry L2VPN/L3VPN  applications traffic from their edge [PE1] to other ends [PE2] using RSVP traffic engineering features, but only till a specific hop [P2] where it wouldn't be optimal for the rest of the path [till PE2] to be forwarded using RSVP, but rather we would prefer LDP instead, for many reasons such as load-balancing if different payload header information exists.


In other words, we want to create an end-to-end PE1 to PE2 LDP path, where two sections of the path takes place, one is tunneled through RSVP paths [bidirectional] from PE1 to P2, and the other is plain LDP from P2 till PE2. This RSVP path would be used to carry applications traffic that is destained to be end-to-end, althought this path ends at P2. I guess the LDP session that is carried over the RSVP path should exchange PE1/2 transport address labels for this approach to work.


Now, I know that this setup would work if we simply create two RSVP paths with the transport address in the "to" field for remote node direction and enable "ldp-tunneling" feature for this path, as I saw instantly all LDP learned routes in inet.3 table are forwarded through the RSVP path at PE-2, and on the other hand P2 is installing the PE-2 loopback through an LDP route over its RSVP path.


However, in order to selectively forward traffic over this RSVP path on PE-2 only when needed, I thought of creating RSVP paths with secondary loopback addresses for both nodes, so that the next-hop installed into inet.3 table would be a different address to the primary one which is used mainly for mpls  forwarding based on plain LDP LSPs, and the result for this was that only a route to the remote node address was installed in each inet.3 table for both nodes, and this would make the setup obviously break, as PE-1 wouldn't be able to exchange labels with PE-2 through P2.


I see a manual workaround to this is to add on PE-2 the "install " command follows by the PE-1 primary transport to the label-switched-path stanza, and the same goes to P2, but with PE-1 address. However, that does defy with the main purpose of creating the tunnel from the first place, which is selectively forwarding PE-2 to PE-1 traffic over it. 


Can anyone have any different ideas about how to bring this setup to an operational state taking in consideration its purpose? 


Thanks in advance.


The HLD topology is as following: [All used nodes models are Juniper MX104, 480 and M10i]


<- L2VPN/L3VPN apps traffic ->

<- LDP Tunnel ->

<- RSVP Paths -><- Plain LDP ->



Re: LDP Tunneling over RSVP Paths between LER/LSR for L2VPN/L3VPN.

‎01-21-2020 08:30 AM



Theoratically this should work. Lots of implementation like this. Using LDP for end-to-end. And RSVP tunnels wherever available. If not, using plain ldp. This has been used in multi-vendor environment 


first, make sure you have ldp on all interfaces/loopbacks between PE1 and PE2

second, on PE1, P1, P2, enable ldp-tunneling and define bi-directional rsvp tunnels PE1<>P2


In this mode, suppose you have PHP:

PE1: push rsvp label, push ldp label, push vpn label 

P1: pop rsvp label 

P2: swap ldp label 

P3: pop ldp label 

PE2: pop vpn label 


Mengzhe Hu

Re: LDP Tunneling over RSVP Paths between LER/LSR for L2VPN/L3VPN.

[ Edited ]
‎01-22-2020 01:24 AM
Hi Mengzhe,
First of all, thanks for your reply,
second, on PE1, P1, P2, enable ldp-tunneling and define bi-directional rsvp tunnels PE1&P2

》》I'm sorry I didn't explain myself clearly enough. I already achieved this setup and it works well. However, that will replace the LDP LSPs for our primary mpls forwarding path, and subsequently will NOT selectively enable the use of the tunnel. I guess I've figured out a manual workaround for this setup. Which is to configure on each PE-1, P2, and PE-2 secondary inet addresses, where P2 and PE-2 secondary addresses would be the sources and destinations of the bidirectional RSVP paths.

This would obviously break the end-to-end LDP path through this tunnel, as on PE-2, PE-1 primary route in inet.3 would be still learned via plain LDP LSP, and not the tunneled LDP LSP (Not not be forwarded via RSVP path), and on the other hand, on P2, PE-2 route in inet.3 primary route would also still be learned via plain LDP. To fix this LSP, we have to add "install to " to each of the RSVP LSPs [PE-2 AND P2] with PE-1 secondary address and PE-2 secondary address respectively. This will also inquire to selectively use those new [secondary] next-hops for the L3VPN/L2VPN..etc applications that will use this tunnel.

Anyways, thanks for your feedback,

Mina Nasry