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

[Greg Mirsky <[e-mail]>]

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
>