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

[Greg Mirsky <[e-mail]>]

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
>
>
>