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

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

Hi Greg,

I am familiar with draft-ietf-mpls-bfd-directed and that it provides a way for signalling the reverse path to be used by the egress. This relies on LSP ping bootstrap. Fully support this work in general.

When using SBFD for monitoring of SR Policy, the reverse path failure can cause false negatives. This I agree and is well known. The other draft-ietf-mpls-bfd-directed allows the head-end to specify another alternative reverse path that IP shortest path. But even that can fail and result in similar false positive.

I find it totally confusing when you say it like “convergence time of IP network” and “convergence of the IP network will play role”. What exactly has convergence got to do with false negatives with reverse path failures at BFD level?

In any case, the main point about draft-ali-spring-bfd-sr-policy is about presenting the analysis of choice of BFD/sBFD for SR Policy and recommending SBFD. It is an informational draft for the Spring WG to evaluate against other proposals being presented for doing BFD for SR Policies.

There is no change in BFD mechanism proposed at all but still appreciate the viewpoints of the BFD WG on this debate. However, the authors of draft-ali-spring-bfd-sr-policy request that the analysis be done with SR architecture in mind and not just bringing in concepts from stateful and circuit oriented MPLS LSPs into SR Policies.

Thanks,
Ketan

From: Greg Mirsky <[e-mail]>
Sent: 21 March 2018 09:29
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,
I'd point that even though you believe that S-BFD session monitors only the SR tunnel, it, in fact, monitors the return path from egress to the ingress of the tunnel. And that is where convergence of the IP network will play role. I can provide you with more detailed explanation of the scenario or you can read the draft-ietf-mpls-bfd-directed as it is applicable to all TE paths monitored by xBFD.

Regards,
Greg

On Wed, Mar 21, 2018 at 9:05 AM, Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
Sent: 20 March 2018 16:58
To: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; spring <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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