MPLS TE Link Protection with FRR

Question

Hi Sir,
Due to inconsistent result during my customer UAT TE link FRR. All the 3 PEs (C7609) link are connected in triangular (three different POPs). From PE-to-PE it's interconnected via DWDM devices. In this scenario, how can we know what type of mechanism is being used to detect GE link failure?
From my understanding, the router can issues thru' an IGP advertisement or an RSVP message.
Need to clarify with your expertise on ip rsvp configuration below, whether can use in our environment and to improve the link detection or not?
# ip rsvp signaling refresh interval ... (default 20ms; 10-30,000ms)
# ip rsvp signaling hello interface
# ip rsvp signaling refresh misses (default 4)
# ip rsvp signaling hello dcsp
If not, what is the alternative or leave it default with FRR configuration as below;
interface Tunnel1
description *** Primary TE Tunnel to SKBMPLS1GW ***
ip unnumbered Loopback0
tag-switching ip
tunnel destination 172.18.255.3
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 1 1
tunnel mpls traffic-eng path-option 1 explicit name path1_SKBMPLS1GW
tunnel mpls traffic-eng path-option 2 dynamic
tunnel mpls traffic-eng record-route
tunnel mpls traffic-eng fast-reroute
TQ

Answer 1

Use the RSVP timers for fast TE Tunnel re-optimization, that is when your existing tunnel fails, then doing a state timeout and signalling a fresh LSP on a different path to the tail end.
FRR will depend on the Link failure and the moment a link falure is detected it switches to the pre-configured backup tunnel, as it cannot wait till the Tunnel re-optimization happens as it has to provide the healing in sub 50ms. And the sub 50 ms value cannot be achieved relying only on Tunnel Re-Optimization. So RSVP is used to signal that the specific primary Tunnel requires protection in the RSVP path messages.
So you can keep you current FRR configuration to what it is right now, and changing the default RSVP timers wont help you to achieve or reduce the FRR healover times (close to 50ms).
The kickin of FRR would depend on the interface status when it goes down, which is dependent on LOS to be received from your DWDM device. And this will happen much faster than the RSVP hello misses.
HTH-Cheers,
Swaroop
For Reference:
http://www.cisco.com/en/US/products/ps6922/products_feature_guide09186a008027dbda.html