Hi Greg, Thanks for your review and comments. Please check inline below for responses.
From: Greg Mirsky <[email protected]> Sent: 20 March 2018 08:57 To: [email protected]; spring <[email protected]>; [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
