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..
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.
Introduction: The "external-out enable" command is available for
configuration under the "router ospf process" in case of the IOS-XR
operating system. This command basically enables advertisement of
intra-area routes on the device as external routes in th...
Introduction Basic configuration for netflow Scale parameters for
netflow Netflow support Architecture Packet flow for netflow Inside the
LC CPU Netflow Cache size, maintenance and memory Sample usage Cache
Size Aging Permanent cache Characteristics Which...