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] > wrote: > 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 >
