Hi Greg, S-BFD allows for continuous monitoring of the SR path corresponding to the SR Policy. The proposal is to use it for continuous monitoring. This is where there is perhaps a disconnect?
They key part is that the authors of draft-ali-spring-bfd-sr-policy do not propose to have ANY SR policy specific state on any router other than the head-end. The mechanism is otherwise stateless and does not involve any bootstrapping of state or such mechanism. This is entirely in sync with the spirit of SR and draft-filsfils-spring-segment-routing-policy. Your proposals are very interesting and perhaps relevant to other signalled circuits and TE paths like RSVP-TE or MPLS-TP, but they do not seem appropriate for SR Policies to me. Thanks, Ketan From: Greg Mirsky <[email protected]> Sent: 20 March 2018 16:58 To: Ketan Talaulikar (ketant) <[email protected]> Cc: [email protected]; spring <[email protected]>; [email protected] Subject: Re: Couple comments on draft-ali-spring-bfd-sr-policy Hi Ketan, thank you for the most expedient and very detailed response. I'd note that using S-BFD leaves fault detection dependent on convergence time of the IP network. This problem discussed in details in draft-ietf-mpls-bfd-directed and draft-mirsky-spring-bfd. Regards, Greg On Tue, Mar 20, 2018 at 4:42 PM, Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>> wrote: Hi Greg, Thanks for your review and comments. Please check inline below for responses. From: Greg Mirsky <[email protected]<mailto:[email protected]>> Sent: 20 March 2018 08:57 To: [email protected]<mailto:[email protected]>; spring <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Couple comments on draft-ali-spring-bfd-sr-policy Dear Authors, I've read the new draft and would appreciate your consideration of my comments and questions: * if I understand correctly, you prefer using S-BFD in SR domain over use of the base BFD. Without arguing with your choice, I'll note that the title of the draft doesn't reflect your preference; [KT] The choice of title seemed correct since the draft does analysis of the different BFD options for SR Policies before preferring SBFD. * section 3.4 RFC 7882 already describes use of S-BFD in SR domain. What you is missing in the RFC 7882? [KT] RFC7882 describes the SBFD use cases and its applicability to SR. This draft does comparison between the BFD modes that borrows from RSVP-TE tunnels usage against S-BFD mode to analyze what is more suitable for SR Policies. This analysis is important to document and to indicate why the authors propose S-BFD rather than BFD is more suitable for SR Policies. * on more technical side. Use of S-BFD will still result in multiplicity of S-BFD packets reflected by egress to ingress. To avoid that we propose method to use BFD Demand mode in MPLS data plane as described in draft-mirsky-bfd-mlps-demand<https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-02>. It will be presented in BFD WG meeting and discussed in SPRING as part of BFD in SPRING presentation. [KT] The BFD on-demand proposal along with the draft-mirsky-spring-bfd basically re-uses concepts like need for bootstrap with LSP ping, setup of state on the egress router from RSVP-TE and IMHO is not suitable for SR Policies unlike S-BFD which is a much simpler and scalable solution that does not setup a per SR Policy state on the egress node. Thanks, Ketan Regards, Greg
