MPLS LDP FRR

per.nielsen · ‎08-05-2007

HI all,

I'm aware that you can enable MPLS FRR with RSVP. But how do you achieve FRR capabilities with LDP ??

Many Thanks

irisrios · ‎08-10-2007

To enable MPLS FRR on each TE tunnel, perform the following steps.

enable

configure terminal

tunnel mpls traffic-eng fast-reroute

end

frenzeus · ‎08-10-2007

Since FRR provides a sub-second (more or less 50ms) convergence due to the fact that it uses a pre-signalled backup tunnel, and that the backup tunnel is pre-setup via RSVP (hence the label returned by RESV msg hop-by-hop back to the PLR).

What makes you think that there is support for FRR using LDP? Is there a requirement of some sort? Do provide more info..

oldcreek12 · ‎08-10-2007

There are discussions to add this functionality in LDP (ldp next-next-hop). What is your requirement that can not be achieved by RSVP FRR?

per.nielsen · ‎08-13-2007

I ware of this functionality is available with RSVP.

The issue is that the customer uses LDP and only LDP

Thanks

Per

mheusing · ‎08-14-2007

Hi Per,

From RFC 4090 (Fast Reroute Extensions to RSVP-TE for LSP Tunnels):

"A protected LSP is an explicitly-routed LSP that is provided with protection. The repair methods described here are applicable only to explicitly-routed LSPs. Application of these methods to LSPs that dynamically change their routes, such as LSPs used in unicast IGP routing, is beyond the scope of this document."

So currently there is no standard covering the required functionality. Imho the underlying reason is avoidance of routing loops. As TE tunnels have fixed starting and endpoints, you might reroute them in any way without creating loops, if preventing loops for the backup tunnel. When it comes to IGP based LSPs the problems are not that easy to solve. Example: R1-R2-R3 Assume the link from R2 to R3 is protected by a tunnel from R2 to R1 ... In IGP based LSPs a routing loop will be created and is hard to detect/avoid.

In case you have a feature request for your customer, drop me an email and we can discuss things offline.

Regards, Martin