The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Re: Reg: Fast Reroute Timings in RFC 4090
Dutta, Pranjal wrote: > 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. 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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|