Subject: [mpls] Reg: Fast Reroute Timings in RFC 4090

From: "Dutta, Pranjal" <[email-masked]>
Date: Wed, 10 Aug 2005 14:50:17 +0530

Hi,

               As per RFC 4090- Fast Reroute Extensions to RSVP-TE for
LSP Tunnels, it takes 10 ms to reroute the LSP at PLR either by facility
back up or one-to-one back up method. The re-route timing is definitely
lesser when compared to time taken for global rerouting (at Ingress
LSR). My concern is PLR will reroute the LSP locally only when it has
the fault notification (after missing hellos from the downstream
neighbor). Assuming that min 1 second of RSVP hello interval is being
used, it will take at least 1 second in total to re-route the traffic
locally which will lead to loss of voice/video packets and affects
traffic performance. I would like to know if there is some effort going
on in this group to address this issue. Any pointers will be helpful.

Thanks,

Pranjal

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: David Charlap <[email-masked]>
Date: Wed, 10 Aug 2005 10:02:20 -0400

> on in this group to address this issue. Any pointers will be helpful.

First of all, the Hello interval may be faster than 1s, depending on the 
implementation.  The RFC actually recommends 5ms intervals, but I don't 
know if anyone actually implements that rate.

Second, a switch may detect a link failure by means other than loss of 
RSVP-Hello.  For instance, the hardware may detect a loss of carrier on 
the interface.  (As a matter of fact, I would expect hardware detection 
of link failure to be the only way that can reroute traffic fast enough 
for real-time applications.)

If a switch loses RSVP Hellos, but does not lose carrier, then the link 
is still physically active.  It is probably still forwarding data-plane 
traffic as well (even though the control plane has probably failed.)  So 
actual losses may not be nearly as severe as you are assuming.

-- David