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

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Mar 2018 08:56:39 +0000

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;
   - section 3.4 RFC 7882 already describes use of S-BFD in SR domain. What
   you is missing in the RFC 7882?
   - 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.

Regards,
Greg

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 20 Mar 2018 16:42:40 +0000

Hi Greg,

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

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Mar 2018 16:57:39 +0000

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

> *From:* Greg Mirsky <[email-masked]>
> *Sent:* 20 March 2018 08:57
> *To:* [email-masked]; spring <[email-masked]>;
> [email-masked]
> *Subject:* Couple comments on draft-ali-spring-bfd-sr-policy
>
>
>
> Dear Authors,
>
> *[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
> *[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
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 21 Mar 2018 09:05:05 +0000

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

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: 20 March 2018 08:57
To: [email-masked]<mailto:[email-masked]>; spring <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Couple comments on draft-ali-spring-bfd-sr-policy

Dear Authors,

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 21 Mar 2018 09:28:58 +0000

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) <[email-masked]

> 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
>
>
>
> *Sent:* 20 March 2018 16:58
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* [email-masked]; spring <[email-masked]>;
> [email-masked]
> *Subject:* Re: Couple comments on draft-ali-spring-bfd-sr-policy
>
>
>
> Hi Ketan,
>
> On Tue, Mar 20, 2018 at 4:42 PM, Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Greg,
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 21 Mar 2018 16:51:01 +0000

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

Sent: 21 March 2018 09:29

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Ketan

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: 20 March 2018 16:58
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; spring <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Couple comments on draft-ali-spring-bfd-sr-policy

Hi Ketan,

Regards,
Greg

Dear Authors,

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 22 Mar 2018 10:11:05 +0000

Hi Ketan,
much obliged by you kind comment on BFD Directed work. The issue with IP
network convergence is the reason we've started work to enable optional
control of the reverse path of BFD session over p2p MPLS LSP.
My concern with the current text of draft-ali-spring-bfd-sr-policy is that
the conclusion drawn from comparison of S-BFD and BFD is not based on
analysis of all possible modes of BFD and all issues related to proactive
failure detection in SR domain, whether SR-MPLS or SRv6.

Regards,
Greg

On Wed, Mar 21, 2018 at 4:51 PM, Ketan Talaulikar (ketant) <[email-masked]

> 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
>
>
>
> *Sent:* 21 March 2018 09:29
>
> 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) <
> [email-masked]> wrote:
>
> Hi Greg,
>
>
>