Unanswered Question
irisrios Fri, 08/10/2007 - 06:41

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


configure terminal

tunnel mpls traffic-eng fast-reroute


frenzeus Fri, 08/10/2007 - 07:27

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..

jiangu Fri, 08/10/2007 - 15:18

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?

mheusing Tue, 08/14/2007 - 03:01

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


This Discussion