Hi Robert, Thanks for your review and comments.
The objective of this draft is to describe how PLR can compute a node-protecting backup path for SR path. > For example I propose that to effectively detect R8 failure as node failure > which is the topic of your proposal a mechanism is clearly defined and includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4-R9, R3-R9 How to find node failed or link failed is not in the scope of this document. If an operator decides to enable node protection, then always node-protecting backup paths will be in-force irrespective of link failed or node-failed. This draft inherits the LFA notion for link and node failure and addresses how this can be handled for SR Paths. I do see that the text in the draft is not enough to clarify what’s in scope of this document and what is not. I’ll add some text in next revision to clarify. Thanks again for pointing it out. Rgds Shraddha From: Robert Raszuk <[email protected]> Sent: Friday, November 22, 2019 2:53 PM To: Shraddha Hegde <[email protected]> Cc: [email protected]; [email protected] Subject: Re: Draft for Node protection of intermediate nodes in SR Paths Hi Shraddha, I have one question to the document. As you know the critical element for the effective protection of any scheme is the failure detection. On that your draft seems to have just one little paragraph: Note that R7 activates the node-protecting backup path when it detects that the link to R8 has failed. R7 does not know that node R8 has actually failed. However, the node-protecting backup path is computed assuming that the failure of the link to R8 implies that R8 has failed. Well IMO this is not enough. Specifically there can be a lot of types of node failure when link is still up. Moreover there can be even running BFD across the link just fine when say fabric failure occurs at R8. While this is not solely issue with this draft, it is our common IETF failure to provide correct means of detecting end to end path or fragments of path failures (I am specifically not calling them segment here :). For example I propose that to effectively detect R8 failure as node failure which is the topic of your proposal a mechanism is clearly defined and includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4-R9, R3-R9 Many thx, Robert. On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde <[email protected]<mailto:[email protected]>> wrote: WG, This is the draft I pointed out that talks about solutions for providing node-protection. It covers Anycast case as well as keeping forwarding plane longer. https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05__;!8WoA6RjC81c!UWVX5SKMz9p87V054empi1a3OtpES7fAr7m1ZwVd-DFqj3-c8iUFGuM4xK8n_DAR$> Review and comments solicited. Rgds Shraddha _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rtgwg__;!8WoA6RjC81c!UWVX5SKMz9p87V054empi1a3OtpES7fAr7m1ZwVd-DFqj3-c8iUFGuM4xNcLZr4T$>
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
