Re: [spring] Couple comments on draft-ali-spring-bfd-sr-policy

[Greg Mirsky <[e-mail]>]

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) <[e-mail]
> wrote:

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