RE: Couple comments on draft-ali-spring-bfd-sr-policy

["Ketan Talaulikar (ketant)" <[e-mail]>]

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 <[e-mail]>
Sent: 20 March 2018 16:58
To: Ketan Talaulikar (ketant) <[e-mail]>
Cc: [e-mail]; spring <[e-mail]>; [e-mail]
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) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Thanks for your review and comments. Please check inline below for responses.


From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: 20 March 2018 08:57
To: [e-mail]<mailto:[e-mail]>; spring <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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