Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 10 Feb 2022 15:50:43 +0000

The WG last call has all but ended and we’ve had a lot of support, two implementations, and some good discussion. Please review the -05 version of the draft reflecting including changes reflecting this discussion. There was debate regarding making the delay timer described in section 5 a normative requirement. The consensus was to not make this a normative part of the specification. I feel this is the right decision – especially given that this is new functionality being requested at Working Group Last Call and implementations accomplish the dampening in vary ways.

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

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Thursday, January 27, 2022 at 12:09 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

LSR WG,

This begins a two week last call for the subject draft. Please indicate your support or objection on this list prior to 12:00 AM UTC on February 11th, 20222. Also, review comments are certainly welcome.
Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Feb 2022 16:57:20 +0100

Hi Acee,

> There was debate regarding making the delay timer described in section 5
a normative requirement.

I see added into new version of the draft the following text into section
5:

   The use of OSPF BFD strict-
   mode along with mechanisms such as hold-down
*(a delay in the initial   OSPF adjacency bringup following BFD session
establishment)* and/or
   dampening
*(a delay in the OSPF adjacency bringup following failure   detected by
BFD)* may help reduce the frequency of adjacency flaps and
   therefore reduce the associated routing churn.

Not sure if this is normative or informative, but it addresses my point.

Thx,
Robert.

On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> The WG last call has all but ended and we’ve had a lot of support, two
> implementations, and some good discussion. Please review the -05 version of
> the draft reflecting including changes reflecting this discussion. There
> was debate regarding making the delay timer described in section 5 a
> normative requirement. The consensus was to not make this a normative part
> of the specification. I feel this is the right decision – especially given
> that this is new functionality being requested at Working Group Last Call
> and implementations accomplish the dampening in vary ways.
>
>
>
> *From: *Lsr <[email-masked]> on behalf of "Acee Lindem (acee)"
> <acee=[email-masked]>
> *Date: *Thursday, January 27, 2022 at 12:09 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>
> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> LSR WG,
>
>
>
> This begins a two week last call for the subject draft. Please indicate
> your support or objection on this list prior to 12:00 AM UTC on February 11
> th, 20222. Also, review comments are certainly welcome.
>
> Thanks,
> Acee
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 10 Feb 2022 15:59:26 +0000

Hi Robert,
This is great to hear – I thought you wanted to make this required for implementation as opposed to a recommendation.
Thanks,
Acee

From: Robert Raszuk <[email-masked]>
Date: Thursday, February 10, 2022 at 10:57 AM
To: Acee Lindem <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Acee,

> There was debate regarding making the delay timer described in section 5 a normative requirement.

I see added into new version of the draft the following text into section 5:

   The use of OSPF BFD strict-
   mode along with mechanisms such as hold-down (a delay in the initial
   OSPF adjacency bringup following BFD session establishment) and/or
   dampening (a delay in the OSPF adjacency bringup following failure
   detected by BFD) may help reduce the frequency of adjacency flaps and
   therefore reduce the associated routing churn.

Thx,
Robert.

On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
The WG last call has all but ended and we’ve had a lot of support, two implementations, and some good discussion. Please review the -05 version of the draft reflecting including changes reflecting this discussion. There was debate regarding making the delay timer described in section 5 a normative requirement. The consensus was to not make this a normative part of the specification. I feel this is the right decision – especially given that this is new functionality being requested at Working Group Last Call and implementations accomplish the dampening in vary ways.

Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of "Acee Lindem (acee)" <acee=[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 27, 2022 at 12:09 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

LSR WG,

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

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

Hi Robert

Would this BFD strict  mode apply to unsolicited BFD of which you are
author?

https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-03

I think if applicable I think would be a good idea.

Many Thanks

Gyan
On Thu, Feb 10, 2022 at 10:59 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Hi Robert,
>
> This is great to hear – I thought you wanted to make this required for
> implementation as opposed to a recommendation.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Thursday, February 10, 2022 at 10:57 AM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Acee,
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 13 Feb 2022 21:19:51 +0100

Gyan,

The OSPF draft you quote does not make any assumptions nor restrictions on
how BFD session itself is setup.

So yes procedures described in draft-ietf-bfd-unsolicited could be used as
a way to bring up BFD session between peers.

Rgs,
R.

On Sun, Feb 13, 2022 at 9:05 PM Gyan Mishra <[email-masked]> wrote:

>> *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
>> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>
>>
>>
>> LSR WG,
>>
>>
>>

---

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

Excellent!

Many Thanks

Gyan

*Gyan Mishra*

*M 301 502-1347*