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

From: "Dutta, Pranjal" <[email-masked]>
Date: Thu, 11 Aug 2005 10:08:46 +0530

Hi,
             I think most of the vendors implement min 1 seconds as
hello-intervals as lesser than that might lead to scalability issues (I
am not sure if that is the reason why vendors implement at least 1 sec).
Hardware level detection will be possible only when physical layer has
end-to-end signaling mechanism for failure. In the case where end-to-end
signaling mechanism is not possible, the PLR will still see that link is
up and keep forwarding traffic to downstream LSR, but actually the link
is failed. I am basically looking for some mechanism that can detect
"Node Failure" as early as possible and PLR will initiate node
protection accordingly. I think some kind of OAM mechanism might help.

Thanks,
Pranjal

Date: Wed, 10 Aug 2005 10:02:20 -0400
From: David Charlap <[email-masked]>
Subject: Re: [mpls] Reg: Fast Reroute Timings in RFC 4090
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Dutta, Pranjal wrote:
> 
>                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.

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

------------------------------

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

End of mpls Digest, Vol 16, Issue 7
***********************************

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

---

From: David Charlap <[email-masked]>
Date: Thu, 11 Aug 2005 09:23:50 -0400

> protection accordingly. I think some kind of OAM mechanism might help.

I think you're misunderstanding the purpose of fast reroute.

Fast reroute is designed to kick in only when the immediate downstream 
neighbor has failed.  Detecting link-level failure in hardware is 
perfectly fine for this.

If the failure takes place elsewhere in the network, then either the 
node immediately upstream of the failure must use FRR, or some other 
mechanism must be used to reroute the traffic.

You would never want to trigger an FRR failover in response to an 
end-to-end detectino mechanism.  One big reason is tha any end-to-end 
system will take so long to detect the failure that there would be 
little advantage to FRR vs. simple switching the traffic to a standby 
LSP (1:1 or 1+1 protection).

Second, an end-to-end mechanism may detect a failure anywhere along the 
path.  If the failed node is not your immediate downstream neighbor, 
your bypass/detour LSPs may not even work to route around the failure. 
And if a downstream node also uses FRR, the multiple simultaneous 
attempts at local-repair may well step on each other, making the 
situation worse.

If you want your originating node to detect the failure with an 
end-to-end mechanism and then signal the node upstream of the failure to 
begin FRR, why bother?  The amount of time it would take for this would 
be longer than the time to simply compute a new path and signal a new 
LSP.  (I'm assuming that that node can't detect its downstream 
neighbor's failure directly, because if it could, there would be no need 
for any end-to-end mechanism in the first place.)

-- David