Subject: Re: draft-ietf-bfd-unsolicited-09

From: Reshad Rahman <[email-masked]>
Date: Sun, 13 Feb 2022 17:04:47 +0000 (UTC)

Hi Gyan,
Apologies for the delay and thanks for the feedback.
The document is applicable to single-hop and multi-hop. In the next revision, we will clarify this and extend the YANG model to include multi-hop.
The "unsolicited BFD" procedure allows a BFD session to be initiated only by 1 side. Once that BFD session is up, demand mode may or may not kick in, just like for RFC5880 BFD. So unsolicited BFD and demand mode are orthogonal.
The procedures in this document apply to RFC5880, aka classical, BFD. S-BFD session bringup is different, requires sharing S-BFD discriminators etc (as mentioned in the Introduction).
Wrt which RFCs are updated by this document: we need to add 9127 (or 9127-bis).
Regards,Reshad.
    On Sunday, January 2, 2022, 12:47:22 AM EST, Gyan Mishra <[email-masked]> wrote:  

Dear Authors 
This is a very useful specification for operators.
Is this draft applicability for single hop, multi hop, demand  and S-BFD sessions.
Also what RFC’s does this draft update?
Kind Regards 
Gyan-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 13 Feb 2022 14:59:34 -0500

Hi Reshad

Could this unsolicited BFD concept be applied to S-BFD RFC 7880, 7881, 7885?

Also could it be applied to RFC 5880 demand mode?

I will review through the draft again for any further comments.

Many Thanks

Gyan

On Sun, Feb 13, 2022 at 12:04 PM Reshad Rahman <[email-masked]> wrote:

> The document is applicable to single-hop and multi-hop. In the next
> revision, we will clarify this and extend the YANG model to include
> multi-hop.
>
> The "unsolicited BFD" procedure allows a BFD session to be initiated only
> by 1 side. Once that BFD session is up, demand mode may or may not kick in,
> just like for RFC5880 BFD. So unsolicited BFD and demand mode are
> orthogonal.
>
> The procedures in this document apply to RFC5880, aka classical, BFD.
> S-BFD session bringup is different, requires sharing S-BFD discriminators
> etc (as mentioned in the Introduction).
>
> Regards,
> Reshad.
> Gyan
> --
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [email-masked] <[email-masked]>*
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 13 Feb 2022 15:03:07 -0500

Hi Reshad

Also I think unsolicited BFD should apply as well to BFD strict mode.

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode

I will comment on that thread.

Kind Regards

Gyan

*Gyan Mishra*

*M 301 502-1347*

---

From: Reshad Rahman <[email-masked]>
Date: Sun, 20 Feb 2022 17:02:57 +0000 (UTC)

Hi Gyan,
As stated below, this document specifies how classical BFD (RFC5880) sessions can be initiated only by 1 side. This is orthogonal to use of demand mode or echo mode in BFD (which can be used once the sessions are up, whether "unsolicited BFD" has been used or not).
S-BFD has its own procedures for bring-up, and unsolicited BFD only applies to classical BFD (RFC5880). This is mentioned in the introduction.
Regards,Reshad. 
    On Sunday, February 13, 2022, 02:59:46 PM EST, Gyan Mishra <[email-masked]> wrote:  

Hi Reshad

 Hi Gyan,

Dear Authors 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

From: Reshad Rahman <[email-masked]>
Date: Sun, 20 Feb 2022 17:07:26 +0000 (UTC)

Hi Gyan,
BFD strict mode below specifies how OSPF signals its requirement for BFD to be up. If you have OSPF at each end, no need for "unsolicited BFD".
Regards,Reshad.
    On Sunday, February 13, 2022, 03:03:19 PM EST, Gyan Mishra <[email-masked]> wrote:  

Hi Reshad 

Hi Reshad

 Hi Gyan,

Dear Authors 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 20 Feb 2022 12:29:33 -0500

Understood as it only applies to Classical BFD with 3 way handshake which
would preclude S-BFD which does not have 3-way handshake and I believe that
is why it does not apply.

Once the session is up per RFC 588O the session switches to Demand mode
with D bit and initiate Poll sequence P bit and F bit in the control
packet.  So as Demand mode uses Poll sequence for liveliness detection and
not default asynchronous mode it is not applicable.

Agreed.  Should we state in the unsolicited BFD specification that they are
not applicable.

Also I believe multihop BFD would be applicable.  Should that be stated in
the specification.

Thanks

Gyan
On Sun, Feb 20, 2022 at 12:02 PM Reshad Rahman <[email-masked]> wrote:

> Hi Gyan,
>
> As stated below, this document specifies how classical BFD (RFC5880)
> sessions can be initiated only by 1 side. This is orthogonal to use of
> demand mode or echo mode in BFD (which can be used once the sessions are
> up, whether "unsolicited BFD" has been used or not).
>
> S-BFD has its own procedures for bring-up, and unsolicited BFD only
> applies to classical BFD (RFC5880). This is mentioned in the introduction.
>
> Regards,
> Reshad.
>

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 20 Feb 2022 12:39:34 -0500

Hi Reshad

We discussed OSPF strict mode and that is a change to OSPF to run in strict
mode meaning allow BFD to come up before OSPF, and I asked Robert Raszuk on
that drafts WGLC and we agreed that unsolicited BFD is not applicable to
strict mode.

In theory the thought was with unsolicited BFD to 3rd party next hop that
is out of the administrative control or 100s of compute nodes in passive
mode and other initiating end is in active mode the idea was that maybe
strict mode could apply to the active side but because strict mode has to
be applied to both ends it ends up being not applicable.

Also point made was that OSPF Strict BFD is a change to OSPF behavior and
no change to BFD behavior. So overall not applicable.

So I am all set here.

Kind Regards

Gyan

On Sun, Feb 20, 2022 at 12:07 PM Reshad Rahman <[email-masked]> wrote:

> Hi Gyan,
>
> BFD strict mode below specifies how OSPF signals its requirement for BFD
> to be up. If you have OSPF at each end, no need for "unsolicited BFD".
>
> Regards,
> Reshad.
>

*Gyan Mishra*

*M 301 502-1347*

---

From: Reshad Rahman <[email-masked]>
Date: Sun, 27 Feb 2022 16:09:11 +0000 (UTC)

Hi Gyan,
Please see inline.
    On Sunday, February 20, 2022, 12:29:45 PM EST, Gyan Mishra <[email-masked]> wrote:  

Understood as it only applies to Classical BFD with 3 way handshake which would preclude S-BFD which does not have 3-way handshake and I believe that is why it does not apply.
Once the session is up per RFC 588O the session switches to Demand mode with D bit and initiate Poll sequence P bit and F bit in the control packet.  So as Demand mode uses Poll sequence for liveliness detection and not default asynchronous mode it is not applicable.
<RR> Demand mode can be used once the session is up, even if unsolicited procedure is used.

Agreed.  Should we state in the unsolicited BFD specification that they are not applicable.
<RR> If it makes things clearer, we can add statements/text to the document.

Also I believe multihop BFD would be applicable.  Should that be stated in the specification.
<RR> As per my last reply, yes.

Regards,Reshad.
Thanks 
Gyan

 Hi Gyan,

Hi Reshad

 Hi Gyan,

Dear Authors 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 27 Feb 2022 11:44:54 -0500

Hi Reshad

On Sun, Feb 27, 2022 at 11:09 AM Reshad Rahman <[email-masked]> wrote:

> Gyan> Excellent

     Gyan> Thank you

> <RR> As per my last reply, yes.

    Gyan> Ack.

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 27 Feb 2022 11:54:47 -0500

Hi Reshad

> applies to classical BFD (RFC5880). This is mentioned in the introduction.

   Gyan> Understood

*Gyan Mishra*

*M 301 502-1347*