LDP and RSVP together

‎03-27-2014 12:36 AM


We are planning an MPLS network. There are needs to traffic-engineer some services (e.g. certain customer L3VPN and VPLS traffic), but most of the services and traffic can follow IGP best path. We would like to avoid the RSVP LSP full mesh configuration burden between PEs.

I have been thinking about following kind of solution.

1. Enable LDP on all routers on all MPLS interfaces. LDP will ensure that there is a route in inet.3 to all PE loopbacks, so MPLS services work between all PEs.

2. Enable RSVP on all routers on all MPLS interfaces to support 3.

3. Create RSVP LSPs for those services that need to be traffic engineered. Or more precisely if a TE service runs between PE1 and PE2, create two LSPs: one for TE path and one to follow IGP best path.

4. Policy route the TE services to correct LSPs (install-nexthop lsp). Let the rest use RSVP IGP path or LDP path.

RSVP has better route preference than LDP so RSVP route is preferred over LDP when available.

Question: does this make sense? Is this used in real-life? Are there any major caveats?



Re: LDP and RSVP together

‎03-27-2014 04:23 PM

Using LDP and RSVP both is pretty common, especially in a multi vendor environment. One thing you may want to consider is tunneling LDP over RSVP so you can traffic engineer the LDP LSPs and have a more consistent idea of how traffic is routed through the network. 


What are you trying to achieve with the non-TE LSPs? Are you just trying to prevent the administrative overhead? 


Re: LDP and RSVP together

‎03-28-2014 06:48 AM

Thanks for reply.


With this topology tunneling LDP over RSVP does not make much sense. There is no "core" and "access".


We are trying to avoid the need to configure full mesh of RSVP LSPs with LDP. There are too many PE routers.

If you mean (3) and "one to follow IGP best path" the goal is to avoid all traffic taking TE LSP. Otherwise it would be the result as RSVP has better preference than LDP.


Re: LDP and RSVP together

‎03-28-2014 07:08 AM

Imagine you have a network with lots of PEs and Ps, you turn LDP and that becomes your default transport protocol. You also turn on RSVP at the interfaces, no RSVP LSP yet.


Then you need to transport a specific service among PE1, PE2, PE3 using RSVP. You can do the following. I will illustrate it with a MP-BGP route advertised by PE2 for service X, and PE1 signaling a RSVP LSP towards PE2, mapping service X to that LSP. Here is how you can do it:


[STEP 1]


admin@PE1# edit protocols mpls label-switched-path X-SERVICE-TO-PE2

admin@PE1# set to <PE2-lo0-address>

admin@PE1# set no-install-to-address

admin@PE1# set install <PE2-FAKE-ADDRESS>


What is <PE2-FAKE-ADDRESS>? An IP address that does NOT need to be configured at PE2. Just make sure there is one different for each PE, but it's never signaled or advertised by IGP or LDP. You don't even need to configure it at PE2.




Now at PE2, for L3VPN service, you do:


admin@PE2# set routing-instance <X> vrf-export <X-out>

admin@PE2# set policy-options <X-out> term <> then next-hop <PE2-FAKE-ADDRESS>


For VPLS service it's a bit more tricky, you may need to configure vpn-apply-export + change the next-hop for family l2vpn prefixes at the MP-BGP group export policy. Never tried.




At PE1 (not PE2), you change the next-hop in the vrf-import policy (L3VPN only) or, more generic, at the MP-BGP group import policy. Use "from family inet-vpn", "from family l2vpn", etc…


DISCLAIMER: These are just tips, not an official recommendation. Anyway it's a classical approach used by many providers.




Re: LDP and RSVP together

‎04-01-2014 06:58 AM

Thanks for a good reply.


I have to admit that I never thought using no-install-to-address and fake address. But this makes sense. I need to test if [STEP 2 – OPTION B] works with VPLS and L2VPN.