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

From: "Albert Fu (BLOOMBERG/ 120 PARK)" <[email-masked]>
Date: Thu, 27 Jan 2022 20:25:19 -0000

I support this draft, as one of the authors, as well as a BFD user, and hope  it becomes a standard. 

This draft addresses an issue that we have encountered in our production network, hence we have been actively working with our vendors.

Most people deploy BFD with OSPF (or any routing protocols) to enable fast failure detection. This is to ensure that routing/forwarding path is diverted as soon as a connectivity issue is detected.

OSPF BFD strict mode ensures this, in that it requires that the BFD session to be established before OSPF adjacency will be allowed to be established, thus ensuring that routing/forwarding will not use the path without a working BFD adjacency.

Without this standard, as per most current default OSPF BFD deployment, OSPF adjacency is established without BFD. OSPF adjacency then triggers the BFD session to be established. If a "break-in-middle" issue occurred (where last mile interface status remains up) before BFD session comes up, we would lose the fast failure detection capability. This situation will require lengthy OSPF protocol timeout to detect such failure, resulting in traffic being  black-holed for extended period. 

We have a large network consisting of several thousand links throughout the world, and have seen this issue several times that had impacted production traffic negatively. 

As mentioned in a previous email, we have successfully tested this feature on the Juniper MX (JUNOS 19.4) and also Cisco ASR9k (XR 7.3.2) platforms.

Thanks
Albert Fu
Bloomberg

From: [email-masked] At: 01/27/22 12:08:36 UTC-5:00To:  [email-masked]
Cc:  [email-masked]
Subject: 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: "Aijun Wang" <[email-masked]>
Date: Fri, 28 Jan 2022 10:59:39 +0800

Hi, Albert:

Want to how to accomplish this aim when router conforms to RFC8362?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK)
Sent: Friday, January 28, 2022 4:25 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Thanks

Albert Fu

Bloomberg

From: [email-masked] <mailto:[email-masked]>  At: 01/27/22 12:08:36 UTC-5:00

To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

LSR WG, 

Thanks,
Acee

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 28 Jan 2022 10:25:54 +0530

Hi Aijun,

This document proposes changes to the adjacency establishment procedures
and the use of LLS for negotiations. As such, it is independent of OSPFv3
Extended LSAs. Please let us know if you believe otherwise.

Thanks,
Ketan

On Fri, Jan 28, 2022 at 8:29 AM Aijun Wang <[email-masked]>
wrote:

> *From:* [email-masked] <[email-masked]> *On Behalf Of *Albert
> Fu (BLOOMBERG/ 120 PARK)
> *Sent:* Friday, January 28, 2022 4:25 AM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
>
>
> This draft addresses an issue that we have encountered in our production
> network, hence we have been actively working with our vendors.
>
>
>
> Most people deploy BFD with OSPF (or any routing protocols) to enable fast
> failure detection. This is to ensure that routing/forwarding path is
> diverted as soon as a connectivity issue is detected.
>
>
>
> OSPF BFD strict mode ensures this, in that it requires that the BFD
> session to be established before OSPF adjacency will be allowed to be
> established, thus ensuring that routing/forwarding will not use the path
> without a working BFD adjacency.
>
>
>
> Without this standard, as per most current default OSPF BFD deployment,
> OSPF adjacency is established without BFD. OSPF adjacency then triggers the
> BFD session to be established. If a "break-in-middle" issue occurred (where
> last mile interface status remains up) before BFD session comes up, we
> would lose the fast failure detection capability. This situation will
> require lengthy OSPF protocol timeout to detect such failure, resulting in
> traffic being black-holed for extended period.
>
>
>
> We have a large network consisting of several thousand links throughout
> the world, and have seen this issue several times that had impacted
> production traffic negatively.
>
>
>
> As mentioned in a previous email, we have successfully tested this feature
> on the Juniper MX (JUNOS 19.4) and also Cisco ASR9k (XR 7.3.2) platforms.
>
>
>
> Thanks
>
> Albert Fu
>
> Bloomberg
>
>
>
> From: [email-masked] At: 01/27/22 12:08:36 UTC-5:00
>
> To: [email-masked]
> 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
>
>
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 28 Jan 2022 14:01:48 +0800

Hi, Ketan:

What I want to know is that where to encapsulate the LLS Data Block if the router uses OSPFv3 Extended LSAs to establish the adjacency?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Ketan Talaulikar
Sent: Friday, January 28, 2022 12:56 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

This document proposes changes to the adjacency establishment procedures and the use of LLS for negotiations. As such, it is independent of OSPFv3 Extended LSAs. Please let us know if you believe otherwise.

Thanks,

Ketan

On Fri, Jan 28, 2022 at 8:29 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Albert:

 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK)
Sent: Friday, January 28, 2022 4:25 AM
To: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Thanks

Albert Fu

Bloomberg

LSR WG, 

Thanks,
Acee

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 28 Jan 2022 14:41:14 +0800

Hi, Ketan:

I know. According to the description of RFC 5613, the LLS Data Block is only attached at the OSPF hello and DD packets.

From: [email-masked] <[email-masked]> On Behalf Of Aijun Wang
Sent: Friday, January 28, 2022 2:02 PM
To: 'Ketan Talaulikar' <[email-masked]>
Cc: [email-masked]; [email-masked]; 'Acee Lindem (acee)' <[email-masked]>; 'Albert Fu' <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi, Ketan:

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Ketan Talaulikar
Sent: Friday, January 28, 2022 12:56 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> >; Albert Fu <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

Thanks,

Ketan

Hi, Albert:

 

Best Regards

Aijun Wang

China Telecom

 

Thanks

Albert Fu

Bloomberg

LSR WG, 

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 28 Jan 2022 12:30:25 +0000

Hi Aijun,

From: Aijun Wang <[email-masked]>
Date: Friday, January 28, 2022 at 1:41 AM
To: 'Ketan Talaulikar' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>, 'Albert Fu' <[email-masked]>
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi, Ketan:

If you read section 4 of the draft, you’ll see that the strict mode behavior is based on the LLS block in OSPF Hello packets.

Thanks,
Acee

Hi, Ketan:

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Ketan Talaulikar
Sent: Friday, January 28, 2022 12:56 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Albert Fu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

Thanks,
Ketan

On Fri, Jan 28, 2022 at 8:29 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Albert:

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK)
Sent: Friday, January 28, 2022 4:25 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Thanks
Albert Fu
Bloomberg

From: [email-masked]<mailto:[email-masked]> At: 01/27/22 12:08:36 UTC-5:00
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

LSR WG,

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 29 Jan 2022 10:08:03 +0800

Hi, Acee:

Yes. Then I think the sentence in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode#section-2 as the following should be relaxed:

“A router MUST include the LLS block with the LLS Type 1 Extended

   Options and Flags TLV with the B-bit set in its Hello and DD packets

   when strict-mode for BFD is enabled on the link.”

It seems that there is no use for such information being included in the DD packets.

And, one more question to the Authors of this draft:

What’s the procedures for the interaction of BFD session and OSPF adjacency establishment in the Broadcast/NBMA network type interface, which is involved the DR/BDR election procedures?  The BFD session establishment should be after the DR/BDR election?

Should the procedures in section 4 be updated to cover such scenario?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Friday, January 28, 2022 8:30 PM
To: Aijun Wang <[email-masked]>; 'Ketan Talaulikar' <[email-masked]>
Cc: [email-masked]; [email-masked]; 'Albert Fu' <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun, 

From: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Date: Friday, January 28, 2022 at 1:41 AM
To: 'Ketan Talaulikar' <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, Acee Lindem <[email-masked] <mailto:[email-masked]> >, 'Albert Fu' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi, Ketan:

Thanks,
Acee

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Aijun Wang
Sent: Friday, January 28, 2022 2:02 PM
To: 'Ketan Talaulikar' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 'Acee Lindem (acee)' <[email-masked] <mailto:[email-masked]> >; 'Albert Fu' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi, Ketan:

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Thanks,

Ketan

Hi, Albert:

 

Best Regards

Aijun Wang

China Telecom

 

Thanks

Albert Fu

Bloomberg

LSR WG, 

Thanks,
Acee

---

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 29 Jan 2022 08:42:54 +0530

Hi Aijun,

Please check inline below.

On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Acee:
>
>
>
> Yes. Then I think the sentence in
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode#section-2
> as the following should be relaxed:
>

KT> Since LLS is present in both Hello and DD packets, not including the B
bit in DD packets will result in a different LLS options being seen in
Hello and DD. This can trigger the change in LLS option logic
unnecessarily. Hence, to keep things simple and consistent (and this should
be for technically all LLS options), it makes sense to include them in both
Hello and DD packets.

> What’s the procedures for the interaction of BFD session and OSPF
> adjacency establishment in the Broadcast/NBMA network type interface, which
> is involved the DR/BDR election procedures?  The BFD session establishment
> should be after the DR/BDR election?
>

KT> The procedures in Sec 4 update the transition to INIT state in the OSPF
Neighbor FSM. This happens before DR election and is independent of the
type of network/link - applies also to Broadcast/NMBA. The main goal of
this proposal is to first verify BFD session establishment and only then
trigger OSPF adjacency procedures. Doing DR election before BFD session
does not serve the purpose.

Thanks,
Ketan

>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Friday, January 28, 2022 8:30 PM
> *To:* Aijun Wang <[email-masked]>; 'Ketan Talaulikar' <
> [email-masked]>
> *Cc:* [email-masked]; [email-masked]; 'Albert
> Fu' <[email-masked]>
> *From: *Aijun Wang <[email-masked]>
> *Date: *Friday, January 28, 2022 at 1:41 AM
> *To: *'Ketan Talaulikar' <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, Acee Lindem <[email-masked]>,
> 'Albert Fu' <[email-masked]>
> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> I know. According to the description of RFC 5613, the LLS Data Block is
> only attached at the OSPF hello and DD packets.
>
>
>
> If you read section 4 of the draft, you’ll see that the strict mode
> behavior is based on the LLS block in OSPF Hello packets.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Aijun
> Wang
> *Sent:* Friday, January 28, 2022 2:02 PM
> *To:* 'Ketan Talaulikar' <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; 'Acee
> Lindem (acee)' <[email-masked]>; 'Albert Fu' <[email-masked]>
> What I want to know is that where to encapsulate the LLS Data Block if the
> router uses OSPFv3 Extended LSAs to establish the adjacency?
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Friday, January 28, 2022 12:56 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Acee
> Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 29 Jan 2022 11:36:04 +0800

Hi, Ketan:

RFC5613 just say the followings: 

“The LLS block MAY be attached to OSPF Hello and Database Description

   (DD) packets.  The LLS block MUST NOT be attached to any other OSPF

   packet types on generation and MUST be ignored on reception.”

But your draft say the LLS block MUST be included within the Hello and DD packet. And I don’t see the usage of the DD packet in the adjacency establishment procedures.

For the Broadcast/NMBA network type, if you establish BFD sessions before the DR/BDR selection, then there will be full mesh BFD sessions within the routers on such media type? Instead of establishing the BFD sessions with DR/BDR only, the same as the OSPF adjacency relationship? If so, if one of the BFD session that not with the DR/BDR is DOWN, what’s the action then?

Best Regards

Aijun Wang

China Telecom

From: Ketan Talaulikar <[email-masked]> 
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]; Albert Fu <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

 

On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Acee:

KT> Since LLS is present in both Hello and DD packets, not including the B bit in DD packets will result in a different LLS options being seen in Hello and DD. This can trigger the change in LLS option logic unnecessarily. Hence, to keep things simple and consistent (and this should be for technically all LLS options), it makes sense to include them in both Hello and DD packets.

KT> The procedures in Sec 4 update the transition to INIT state in the OSPF Neighbor FSM. This happens before DR election and is independent of the type of network/link - applies also to Broadcast/NMBA. The main goal of this proposal is to first verify BFD session establishment and only then trigger OSPF adjacency procedures. Doing DR election before BFD session does not serve the purpose.

Thanks,

Ketan

 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Acee Lindem (acee)
Sent: Friday, January 28, 2022 8:30 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >; 'Ketan Talaulikar' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 'Albert Fu' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun, 

Hi, Ketan:

Thanks,
Acee

Hi, Ketan:

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Thanks,

Ketan

Hi, Albert:

 

Best Regards

Aijun Wang

China Telecom

 

Thanks

Albert Fu

Bloomberg

LSR WG, 

Thanks,
Acee

---

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 29 Jan 2022 13:28:22 +0530

Hi Aijun,

Please check inline below

On Sat, Jan 29, 2022 at 9:06 AM Aijun Wang <[email-masked]>
wrote:

> But your draft say the LLS block *MUST* be included within the Hello and
> DD packet.
>

KT> The text is about when B-bit is set as per this specification then the
LLS block MUST be included. LLS options are best carried consistently in
all packets that have LLS block included in them. I've already explained
why we are not doing anything special for DD packets.

> And I don’t see the usage of the DD packet in the adjacency establishment
> procedures.
>
>
>
> For the Broadcast/NMBA network type, if you establish BFD sessions before
> the DR/BDR selection, then there will be full mesh BFD sessions within the
> routers on such media type?
>
Instead of establishing the BFD sessions with DR/BDR only, the same as the
> OSPF adjacency relationship? If so, if one of the BFD session that not with
> the DR/BDR is DOWN, what’s the action then?
>

KT> I think there is perhaps a misunderstanding of the purpose of BFD use
with OSPF. Perhaps a careful reading of RFC5882 would help? In short, BFD
is used to verify bidirectional connectivity between neighbors to ensure
data may be forwarded between them. OSPF adjacency is built between every
router in a LAN since they can directly forward packets between themselves.

Thanks,
Ketan

>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Ketan Talaulikar <[email-masked]>
> *Sent:* Saturday, January 29, 2022 11:13 AM
> *Cc:* Acee Lindem (acee) <acee=[email-masked]>; [email-masked];
> [email-masked]; Albert Fu <
> [email-masked]>
> KT> The procedures in Sec 4 update the transition to INIT state in the
> OSPF Neighbor FSM. This happens before DR election and is independent of
> the type of network/link - applies also to Broadcast/NMBA. The main goal of

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 29 Jan 2022 16:12:56 +0800

Hi, Ketan:

    For the Broadcast/NMBA network type, if you establish BFD sessions before the DR/BDR selection, then there will be full mesh BFD sessions within the routers on such media type? 

Instead of establishing the BFD sessions with DR/BDR only, the same as the OSPF adjacency relationship? If so, if one of the BFD session that not with the DR/BDR is DOWN, what’s the action then?

KT> I think there is perhaps a misunderstanding of the purpose of BFD use with OSPF. Perhaps a careful reading of RFC5882 would help? In short, BFD is used to verify bidirectional connectivity between neighbors to ensure data may be forwarded between them. OSPF adjacency is built between every router in a LAN since they can directly forward packets between themselves. 

[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between the routers and DR/BDR.  

Thanks,

Ketan

Best Regards

Aijun Wang

China Telecom

From: Ketan Talaulikar <[email-masked] <mailto:[email-masked]> > 
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Acee Lindem (acee) <acee=[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; Albert Fu <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

 

Hi, Acee:

 

Thanks,

Ketan

 

Best Regards

Aijun Wang

China Telecom

Hi Aijun, 

Hi, Ketan:

Thanks,
Acee

Hi, Ketan:

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Thanks,

Ketan

Hi, Albert:

 

Best Regards

Aijun Wang

China Telecom

 

Thanks

Albert Fu

Bloomberg

LSR WG, 

Thanks,
Acee

---

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 29 Jan 2022 13:51:45 +0530

Hi Aijun,

The choice of the term "adjacency" was not accurate in my previous response
to you. I meant "neighborship".

That said, the substance of my response still remains the same.

Thanks,
Ketan

On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang <[email-masked]>
wrote:

> Hi, Ketan:
>
>     For the Broadcast/NMBA network type, if you establish BFD sessions
> before the DR/BDR selection, then there will be full mesh BFD sessions
> within the routers on such media type?
>
> *[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between the
> routers and DR/BDR.  *
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 29 Jan 2022 16:45:39 +0800

Hi, Ketan:

OK, then back to my original question:

If one of the BFD session(between DRothers) is DOWN, will it bring DOWN the OSPF adjacency(between the DRother and DR/BDR)?

If not, then the traffic between these DRothers will be lost; If yes, it seems strange, because the BFD session between the DRother and DR/BDR may be still UP.

I think here there are some mismatch between the BFD sessions and the OSPF adjacency in Broadcast/NBMA network, then some clarification for the procedures are needed. 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Ketan Talaulikar
Sent: Saturday, January 29, 2022 4:22 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; [email-masked]; Albert Fu <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

The choice of the term "adjacency" was not accurate in my previous response to you. I meant "neighborship". 

Thanks,

Ketan

On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Ketan:

Thanks,

Ketan

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

 

Hi, Acee:

 

Thanks,

Ketan

 

Best Regards

Aijun Wang

China Telecom

Hi Aijun, 

Hi, Ketan:

Thanks,
Acee

Hi, Ketan:

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Thanks,

Ketan

Hi, Albert:

 

Best Regards

Aijun Wang

China Telecom

 

Thanks

Albert Fu

Bloomberg

LSR WG, 

Thanks,
Acee

---

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 29 Jan 2022 20:49:36 +0530

Hi Aijun,

On Sat, Jan 29, 2022 at 2:15 PM Aijun Wang <[email-masked]>
wrote:

> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
> the OSPF adjacency(between the DRother and DR/BDR)?
>

KT> No. Those are different neighborships and the document does not bring
any dependencies between them.

> If not, then the traffic between these DRothers will be lost;
>

KT> Yes. Since there is a issue with forwarding (which is what BFD
detects), the traffic would not get forwarded between those neighbors in
any way. The neighborship going down (and staying down) prevents silent
failures and flapping of that neighborship as explained in the draft. There
is the possibility that an alternate path exists which might be used
instead.

> If yes, it seems strange, because the BFD session between the DRother and
> DR/BDR may be still UP.
>

KT> That makes no difference. It isn't as if all traffic between routers on
the LAN goes through the DR.

Thanks,
Ketan

> I think here there are some mismatch between the BFD sessions and the OSPF
> adjacency in Broadcast/NBMA network, then some clarification for the
> procedures are needed.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *Sent:* Saturday, January 29, 2022 4:22 PM
> *Cc:* [email-masked]; [email-masked]; Albert
> Fu <[email-masked]>; Acee Lindem (acee) <acee=
> [email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Jan 2022 17:14:51 +0100

Hi Ketan and all,

I support this draft - it is a useful addition.

There are two elements which I would suggest to adjust in the text before
publication.

*#1 Overpromise*

Even below you say:

> Since there is a issue with forwarding *(which is what BFD detects)*

and in the text we see:

"In certain other scenarios, a degraded or poor quality link will allow
OSPF adjacency formation to succeed
   but the *BFD session establishment will fail or the BFD session
will flap*."

Reader may get an impression that if he enables strict mode he is 100%
safe. Sure he is safer then before but not 100% safe.

Real networks prove that there are classes of failures which BFD can not
detect. And Albert knows them too :)

For example some emulated circuits can experience periodic drops only at
some MTUs and only when link utilization reaches X %. While there is
ongoing extension to BFD to fill it with payload I don't think that BFD can
be useful to also saturate say in 80% 10G link with probes to test it well
before allowing OSPF to be established.

*#2 Timer *

What I find missing in the draft is a mutually (between OSPF peers) timer
fired after BFD session is up which in OSPF could hold on allowing BFD to
do some more testing before declaring adj to be established. I think just
bringing OSPF adj immediately after the BFD session is up is not a good
thing. Keep in mind that we are bringing the interface up so by applying
such a timer we are not dropping packets .. in fact quite the reverse we
are making sure user packets would not be dropped.

Cheers,
Robert

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 29 Jan 2022 18:45:22 +0000

Speaking as WG member:

Hi Aijun,
If you want a per-neighbor state and route, you have to use P2MP. This scope of this draft isn’t to try and make NBMA/Broadcast model something that it is not. This is should be common knowledge and the draft needn’t address it. Those of us who remember ATM emulated LANs (which were not always symmetrically reliable) will recall using P2MP on an inherently multi-access network.
Acee

From: Aijun Wang <[email-masked]>
Date: Saturday, January 29, 2022 at 3:46 AM
To: 'Ketan Talaulikar' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'Albert Fu' <[email-masked]>, Acee Lindem <[email-masked]>
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi, Ketan:

Best Regards

Aijun Wang
China Telecom

Hi Aijun,

Thanks,
Ketan

On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Ketan:
    For the Broadcast/NMBA network type, if you establish BFD sessions before the DR/BDR selection, then there will be full mesh BFD sessions within the routers on such media type?
Instead of establishing the BFD sessions with DR/BDR only, the same as the OSPF adjacency relationship? If so, if one of the BFD session that not with the DR/BDR is DOWN, what’s the action then?

Thanks,
Ketan

Best Regards

Aijun Wang
China Telecom

From: Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Albert Fu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Acee:

Thanks,
Ketan

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: Friday, January 28, 2022 8:30 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Ketan Talaulikar' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'Albert Fu' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Aijun,

From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 28, 2022 at 1:41 AM
To: 'Ketan Talaulikar' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, 'Albert Fu' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi, Ketan:

Thanks,
Acee

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Aijun Wang
Sent: Friday, January 28, 2022 2:02 PM
To: 'Ketan Talaulikar' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'Acee Lindem (acee)' <[email-masked]<mailto:[email-masked]>>; 'Albert Fu' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi, Ketan:

Best Regards

Aijun Wang
China Telecom

Hi Aijun,

Thanks,
Ketan

Best Regards

Aijun Wang
China Telecom

Thanks
Albert Fu
Bloomberg

LSR WG,

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 29 Jan 2022 18:49:00 +0000

Speaking as Document Shepherd:

Hi Robert,

From: Robert Raszuk <[email-masked]>
Date: Saturday, January 29, 2022 at 11:15 AM
To: Ketan Talaulikar <[email-masked]>
Cc: lsr <[email-masked]>, "[email-masked]" <[email-masked]>, Albert Fu <[email-masked]>, Acee Lindem <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan and all,

There are two elements which I would suggest to adjust in the text before publication.

#1 Overpromise

Even below you say:

> Since there is a issue with forwarding (which is what BFD detects)

and in the text we see:

"In certain other scenarios, a degraded or poor quality link will allow OSPF adjacency formation to succeed
   but the BFD session establishment will fail or the BFD session will flap."

Reader may get an impression that if he enables strict mode he is 100% safe. Sure he is safer then before but not 100% safe.

Can you suggest text which with you’d be happy? I’m sure the authors would add you to the acknowledgements.

Real networks prove that there are classes of failures which BFD can not detect. And Albert knows them too :)

For example some emulated circuits can experience periodic drops only at some MTUs and only when link utilization reaches X %. While there is ongoing extension to BFD to fill it with payload I don't think that BFD can be useful to also saturate say in 80% 10G link with probes to test it well before allowing OSPF to be established.

#2 Timer

What I find missing in the draft is a mutually (between OSPF peers) timer fired after BFD session is up which in OSPF could hold on allowing BFD to do some more testing before declaring adj to be established. I think just bringing OSPF adj immediately after the BFD session is up is not a good thing. Keep in mind that we are bringing the interface up so by applying such a timer we are not dropping packets .. in fact quite the reverse we are making sure user packets would not be dropped.

This could be described but I don’t think it should be normative. This begs the question as to why a hold down timer is not a part of the BFD protocol itself.

Thanks,
Acee

Cheers,
Robert

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Jan 2022 20:24:48 +0100

Hi Acee,

Can you suggest text which with you’d be happy? I’m sure the authors would
> add you to the acknowledgements.
>

Actually instead of suggesting any new text I would suggest to delete the
two below sentences and it will be fine:

*"In certain other scenarios, a degraded or poor quality link will allow
OSPF adjacency formation to succeed*
*but the BFD session establishment will fail or the BFD session will flap.
In this case, traffic that gets *
*forwarded over such a link may experience packet drops while the failure
of the BFD session establishment *
*would not enable fast routing convergence if the link were to go down or
flap."*

This could be described but I don’t think it should be normative. This begs
> the question as to why a hold down timer is not a part of the BFD protocol
> itself.
>

There is one - BFD calls it multiplier.

But the timer I am suggesting is not related to BFD operation, but to OSPF
(and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about
allowing BFD for more testing (with various parameters (for example
increasing test packet size in some discrete steps) before OSPF is happy to
bring the adj. up.

Thx,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 29 Jan 2022 19:51:24 +0000

Hi Robert,

From: Robert Raszuk <[email-masked]>
Date: Saturday, January 29, 2022 at 2:25 PM
To: Acee Lindem <[email-masked]>
Cc: Ketan Talaulikar <[email-masked]>, lsr <[email-masked]>, "[email-masked]" <[email-masked]>, Albert Fu <[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,

Actually instead of suggesting any new text I would suggest to delete the two below sentences and it will be fine:

"In certain other scenarios, a degraded or poor quality link will allow OSPF adjacency formation to succeed
but the BFD session establishment will fail or the BFD session will flap.  In this case, traffic that gets
forwarded over such a link may experience packet drops while the failure of the BFD session establishment
would not enable fast routing convergence if the link were to go down or flap."

That would be fine with me but I’ll defer to the authors.

But the timer I am suggesting is not related to BFD operation, but to OSPF (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about allowing BFD for more testing (with various parameters (for example increasing test packet size in some discrete steps) before OSPF is happy to bring the adj. up.

I don’t anyone has implemented the later capability. This MTU test extension could be added in a separate draft if there were a strong requirement.

Thanks,
Acee

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Jan 2022 20:54:48 +0100

Acee,

> I don’t anyone has implemented the later capability. This MTU test
> extension could be added in a separate draft if there were a strong
> requirement.
>

I think you are mixing an example of what BFD could be doing to make sure
the link is fine with the delay timer allowing it to do whatever it needs.

The former is a local operator's decision. The latter IMO could be added to
the draft to make the interoperability seamless. But this is just a
suggestion/hint. Nothing more.

Many thx,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 29 Jan 2022 20:08:39 +0000

Robert –

It is good that you take an active interest in this technology – but I think the suggestions you are making should not be targeted at IGP use of BFD.

Discussion of how to make BFD failure detection more robust belongs in the BFD WG – and – as you know – that WG has taken an interest in such problems e.g., MTU.

In regards to “dampening” = which I think is the relevant term for the timer related suggestions you are making - this also does not belong in the IGP. If you do not want the BFD session to come back up too quickly after a failure, the proper place to put timers is either at the interface layer or in the BFD implementation.
I am familiar with implementations which apply this timer at the protocol level (AKA BFD client in this context) and this is done precisely because the protocol does NOT have the functionality being defined in this draft. Once you have implemented “wait-for-BFD” logic as defined in this draft you do not need additional delay timers in the protocol.

I don’t think the suggestions you are making belong in this document.

    Les

From: Lsr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Saturday, January 29, 2022 11:25 AM
To: Acee Lindem (acee) <[email-masked]>
Cc: Ketan Talaulikar <[email-masked]>; [email-masked]; Albert Fu <[email-masked]>; lsr <[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,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Jan 2022 21:20:00 +0100

Hi Les,

> Discussion of how to make BFD failure detection more robust belongs in
the BFD WG
> If you do not want the BFD session to come back up too quickly after a
failure

Nothing I suggested is related to any of the above.

Let me perhaps provide a very simple example.

BFD being used is *AS*IS*.

All the operator wants is to run it for say X sec without ever going
down before bringing OSPF adj up.

That timer and its consistency on both ends clearly belongs to OSPF not to
BFD.

Now what happens within those 30 sec, what BFD packets are formed and how
they are exchanged is all BFD business - but I am not suggesting to include
any of those in this draft.

Do we have a common understanding so far ?

Hint: Albert already stated that he needs that timer and that both vendors
provided it via cfg. All that confirms is that timer is needed. All I am
suggesting (even before being aware of the manual cfg for it) was to
synchronize the value or pick lower configured between two peers.

Kind regards,
R.

On Sat, Jan 29, 2022 at 9:08 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
> It is good that you take an active interest in this technology – but I
> think the suggestions you are making should not be targeted at IGP use of
> BFD.
>
>
>
> Discussion of how to make BFD failure detection more robust belongs in the
> BFD WG – and – as you know – that WG has taken an interest in such problems
> e.g., MTU.
>
>
>
> In regards to “dampening” = which I think is the relevant term for the
> timer related suggestions you are making - this also does not belong in the
> IGP. If you do not want the BFD session to come back up too quickly after a
> failure, the proper place to put timers is either at the interface layer or
> in the BFD implementation.
>
> I am familiar with implementations which apply this timer at the protocol
> level (AKA BFD client in this context) and this is done precisely because
> the protocol does NOT have the functionality being defined in this draft.
> Once you have implemented “wait-for-BFD” logic as defined in this draft you
> do not need additional delay timers in the protocol.
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, January 29, 2022 11:25 AM
> *To:* Acee Lindem (acee) <[email-masked]>
> *Cc:* Ketan Talaulikar <[email-masked]>;
> [email-masked]>; lsr <[email-masked]>
> *but the BFD session establishment will fail or the BFD session
> will flap.  In this case, traffic that gets *
>
> This could be described but I don’t think it should be normative. This
> begs the question as to why a hold down timer is not a part of the BFD
> protocol itself.
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 29 Jan 2022 20:32:21 +0000

Robert -

From: Robert Raszuk <[email-masked]>
Sent: Saturday, January 29, 2022 12:20 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; Ketan Talaulikar <[email-masked]>; [email-masked]; Albert Fu <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Les,

> Discussion of how to make BFD failure detection more robust belongs in the BFD WG
> If you do not want the BFD session to come back up too quickly after a failure

All the operator wants is to run it for say X sec without ever going down before bringing OSPF adj up.

That timer and its consistency on both ends clearly belongs to OSPF not to BFD.
[LES:] I disagree. The definition of UP state belongs to the BFD protocol/implementation.
If you don’t want BFD clients (like OSPF) to react “too quickly” then build additional config/logic into your BFD implementation so it does not signal UP state before additional criteria is met – do not make each BFD client (and there could be multiple for a given session) configure its own definition of BFD UP.

Now what happens within those 30 sec, what BFD packets are formed and how they are exchanged is all BFD business - but I am not suggesting to include any of those in this draft.

Hint: Albert already stated that he needs that timer and that both vendors provided it via cfg. All that confirms is that timer is needed. All I am suggesting (even before being aware of the manual cfg for it) was to synchronize the value or pick lower configured between two peers.

[LES:] I don’t know if Albert and I disagree.
I am saying that the implementations I am familiar with have introduced this capability for OSPF precisely because OSPF did not have strict mode support as defined in this draft.
There has been no need for this with IS-IS – which has had equivalent support (RFC 6213) for many years.
And once OSPF strict-mode support becomes widely deployed there won’t be a need for such a timer for OSPF either.

   Les

Kind regards,
R.

On Sat, Jan 29, 2022 at 9:08 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

    Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Saturday, January 29, 2022 11:25 AM
To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Cc: Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Albert Fu <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[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,

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Jan 2022 21:49:38 +0100

Hi Les,

> *[LES:] I disagree. The definition of UP state belongs to the BFD
> protocol/implementation.*
>
> *If you don’t want BFD clients (like OSPF) to react “too quickly” then
> build additional config/logic into your BFD implementation so it does not
> signal UP state before additional criteria is met – do not make each BFD
> client (and there could be multiple for a given session) configure its own
> definition of BFD UP.*
>

I think we are looking at this from different perspectives.

I am saying bring BFD UP and allow X seconds/minutes/hours to run a
sequence of testing before bringing OSPF adj up.

You are saying do not declare BFD as UP before all of those testing passes.
That test sequence could be just running vanilla normal BFD for X
seconds/minutes/hours.

That would require introducing a completely new BFD state. Worse, that
timer may be very different on a per type of interface basis as each
interface type has completely different characteristics. Also such timer
would need to have a different value on a per BFD client basis. (For
example OSPF adj UP could be very different then PE-PE BFD for BGP as PULSE
alternative :)

Sorry I really do not think this belongs to BFD at all. It is a local
client thing how long from t0 = BFD UP it will wait before proceeding
further.

And last but not least - such extended testing does not need to kick in
every time interface flaps. Maybe the operator only wants to run it during
maintenance windows once per day ? Or once per week ?

But I am not going to even remotely hope I can convince you :) So let's
forget it.

Cheers,
R/

---

From: Aijun Wang <[email-masked]>
Date: Sun, 30 Jan 2022 10:28:15 +0800

Hi, Acee and Ketan:
No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
What I want to express is that you brought up the full mesh BFD sessions among the routers within such network type. Is it necessary to bring some of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency are established between the DRother and DR/BDR router?
If the BFD session is bootstrapped after the OSPF adjacency is established, there will be no such extra/useless BFD sessions 

Aijun Wang
China Telecom

> On Jan 30, 2022, at 02:45, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> Speaking as WG member:
>  
> Hi Aijun,
> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang <[email-masked]> wrote:
> Hi, Ketan:
> On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang <[email-masked]> wrote:
> Hi, Acee:
>  
> On Fri, Jan 28, 2022 at 8:29 AM Aijun Wang <[email-masked]> wrote:
> Hi, Albert:
>  
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 30 Jan 2022 01:59:36 -0500

I support WG Adoption of this draft.

This is a real world problem that has existed with BFD that operators have
to deal with where OSPF adjacency comes up before BFD session establishes
resulting in cases where the link may have L1 issues or maybe a dirty link
or poor link quality resulting in BFD session establishment followed by BFD
immediately taking down the link.  With BFD tight timers with client
protocol registered ends up further exacerbating the issue with link flaps
resulting in IGP instability.

This draft mirrors the ISIS block solution in RFC 6213   ISIS BFD enabled
TLV.

This issue exists with BGP as well where the protocol registered with BFD
bootstrapped per RFC 5882 comes up before BFD resulting in instability.  I
believe this gap still exists for BGP.

When BFD comes up it performs link integrity test before session
establishment to detect dirty errored link does not come Up.

RFC 5880 BFD 3-way session establishment and  does the link integrity and
 quality test by sending the BFD control packets to validate bi-directional
forwarding liveliness detection over any media.

The case mentioned in this draft where the link is dirty, MTU issues or
forwarding plane issues exist that cause BFD not to establish resulting in
the use of default protocol timers and slow convergence is a major issue
for operators being solved with this draft as well as mentioned above where
BFD does come up after the IGP is just as bad if not worse if the link is a
dirty errored link resulting in flapping link.

The main point here as I mentioned is that BFD must validate the link
integrity before routing protocol comes Up, so that routing protocol does
not come Up on a dirty errored link, so the blocking of the adjacency
capabilities solution here nicely solves the issue.

In this thread it has been mentioned maybe a CLI timer knob as far as
implementation for delay knob makes sense.

I would like to note that one workaround used by operators is using RFC
7130 BFD over bundle member called “BOB” or per link BFD,  and in that case
control protocol is in fact blocked and BFD comes up first.  This is a
workaround used putting even individual single links in a bundle to present
the issue from happening.

I would like to note that RFC 5882 Generic Application of BFD does state
that if all neighbors support BFD then the registered control protocol
being bootstrapped should be blocked from coming up until BFD session is
established.  Only in case where all neighbors on a LAN do not have BFD
enabled, blocking the control protocol from coming Up would prevent the
control protocol from coming Up on neighbors that don’t have BFD enabled.

So the way I read it implementations following BFD RFC 5882 should have
been blocking OSPF or ISIS  protocol from coming Up before BFD comes up w/o
having to require a specification for the explicit block.  Apparently most
all vendors implementations did not follow RFC 5882 it appears with this
regard and thus now the requirement for operators for this important
draft.  I think this implementation discrepancy happened due to normative
language SHOULD Block and not MUST Block is the problem.

RFC 5882 excerpt below:

4.1 <https://datatracker.ietf.org/doc/html/rfc5882#section-4.1>.
Adjacency Establishment

   If the session state on either the local or remote system (if known)
   is AdminDown, BFD has been administratively disabled, and the
   establishment of a control protocol adjacency MUST be allowed.

   BFD sessions are typically bootstrapped by the control protocol,
   using the mechanism (discovery, configuration) used by the control
   protocol to find neighbors.  Note that it is possible in some failure
   scenarios for the network to be in a state such that the control
   protocol is capable of coming up, but the BFD session cannot be
   established, and, more particularly, data cannot be forwarded.  To
   avoid this situation, it would be beneficial not to allow the control
   protocol to establish a neighbor adjacency.  However, this would
   preclude the operation of the control protocol in an environment in
   which not all systems support BFD.

   Therefore, the establishment of control protocol adjacencies SHOULD
   be blocked if both systems are willing to establish a BFD session but
   a BFD session cannot be established.  One method for determining that
   both systems are willing to establish a BFD session is if the control
   protocol carries explicit signaling of this fact.  If there is no
   explicit signaling, the willingness to establish a BFD session may be
   determined by means outside the scope of this specification.

   If it is believed that the neighboring system does not support BFD,
   the establishment of a control protocol adjacency SHOULD NOT be
   blocked.

Few comments on the draft below:

Bottom of Introduction

   This document specifies the OSPF protocol extensions using link-local
   signaling (LLS) [RFC5613
<https://datatracker.ietf.org/doc/html/rfc5613>] for a router to
indicate to its neighbor
   the willingness to establish its adjacency using the strict-mode for
   BFD.  It also introduces an extension for OSPFv3 link-local signaling
   of the interface IPv4 address when used for an IPv4 address-family
   (AF) instance to enable discovery of the IPv4 addresses for BFD
   session setup.

Gyan> Could you also introduce extension for IPV6 AF for discovery of
IPv6 address?

Section 3 Local Interface IPv4 address TLV

Gyan> Should we also have a LLS Data block B bit section for Local
Interface IPv6 address TLV

Section 4 Procedure

      In this state, a Hello packet has recently been received from the
      neighbor.  However, bidirectional communication has not yet been
      established with the neighbor (i.e., the router itself did not
      appear in the neighbor's Hello packet).  BFD session establishment
      with the neighbor is requested, if not already completed (e.g., in
      the event of transition from 2-way state).  Neighbors in Init
      state or higher will be listed in the Hello packets associated
      with the interface if they either have a corresponding BFD session
      established or have not advertised strict-mode for BFD in the
      Hello packet LLS Extended Options and Flags.

Gyan> What do you mean by “ e.g., in the event of transition from 2-way state)

I would think OSPF is blocked and so then after BFD is established then
OSPF initialized but this sounds like OSPF maybe in two way state when BFD
establishes which means OSPF is not blocked from forming adjacency.
Confusing.

So this would be a LAN mix mode where not all nodes have BFD enabled maybe
want to mention to make it clear.

   An implementation MUST NOT wait for BFD session establishment in Init
   state unless strict-mode for BFD is enabled on the router and the
   specific neighbor indicates strict-mode for BFD capability via its
   Hello LLS options.  When BFD is enabled, but the strict-mode for
   operation has not be signaled by both neighbors, then an
   implementation SHOULD start the BFD session establishment only in
   2-Way state or higher state.  This makes it possible for an OSPF
   router to support BFD operation in both strict-mode and normal mode
   across different interfaces or even different neighbors on the same
   multi-access interface.

Gyan> So in the LAN case RFC 5882 OSPF should not be blocked with LLS
data block.

So I think that is what you are trying to say that BFD can come up
after OSPF is Up

I see you mention 2-way but not fully Up.  How would you stagger it
allow BFD to come up

in parallel to ospf still coming to Full state.

Nit

OLD

   When BFD is enabled on an interface over which we already have an
   existing OSPF adjacency, it would result in the router setting the
   B-bit in its subsequent Hello packets.  If the adjacency is already
   up (i.e., in its terminal state of Full or 2-way with non-DR routers
   on a multi-access interface) with a neighbor that also supports
   strict-mode for BFD, then an implementation SHOULD NOT bring this

Gyan> 2-way is not terminal state even for DROther routers

NEW

   When BFD is enabled on an interface over which we already have an
   existing OSPF adjacency, it would result in the router setting the
   B-bit in its subsequent Hello packets.  If the adjacency is already
   up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther routers
   on a multi-access interface) with a neighbor that also supports
   strict-mode for BFD, then an implementation SHOULD NOT bring this

Section 4.1 OSPFv3 IPv4 address family specifics

Gyan> Why would you not have also OSPFV3 IPv6 address family specifics

Kind Regards

Gyan

On Sat, Jan 29, 2022 at 9:28 PM Aijun Wang <[email-masked]>
wrote:

> What I want to express is that you brought up the full mesh BFD sessions
> among the routers within such network type. Is it necessary to bring some
> of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency
> are established between the DRother and DR/BDR router?
> If the BFD session is bootstrapped after the OSPF adjacency is
> established, there will be no such extra/useless BFD sessions
>
> Aijun Wang
> China Telecom
>
> If you want a per-neighbor state and route, you have to use P2MP. This
> scope of this draft isn’t to try and make NBMA/Broadcast model something
> that it is not. This is should be common knowledge and the draft needn’t
> address it. Those of us who remember ATM emulated LANs (which were not
> always symmetrically reliable) will recall using P2MP on an inherently
> multi-access network.
>
> Acee
>
>
>
> *Date: *Saturday, January 29, 2022 at 3:46 AM
> [email-masked]>, 'Albert Fu' <
> [email-masked]>, Acee Lindem <[email-masked]>
> If not, then the traffic between these DRothers will be lost; If yes, it
> seems strange, because the BFD session between the DRother and DR/BDR may
> be still UP.
>
-- 

<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, 30 Jan 2022 11:03:34 -0500

Sorry I meant publication.

I support publication.

Thanks

Gyan

On Sun, Jan 30, 2022 at 1:59 AM Gyan Mishra <[email-masked]> wrote:

> 4.1 <https://datatracker.ietf.org/doc/html/rfc5882#section-4.1>.  Adjacency Establishment
>
>    signaling (LLS) [RFC5613 <https://datatracker.ietf.org/doc/html/rfc5613>] for a router to indicate to its neighbor
> Gyan> Could you also introduce extension for IPV6 AF for discovery of IPv6 address?
>
>
> Gyan> Should we also have a LLS Data block B bit section for Local Interface IPv6 address TLV
>
>
> Section 4 Procedure
>
>
> Gyan> So in the LAN case RFC 5882 OSPF should not be blocked with LLS data block.
>
>
> So I think that is what you are trying to say that BFD can come up after OSPF is Up
>
> I see you mention 2-way but not fully Up.  How would you stagger it allow BFD to come up
>
>> I think here there are some mismatch between the BFD sessions and the
>> OSPF adjacency in Broadcast/NBMA network, then some clarification for the
>> procedures are needed.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> Instead of establishing the BFD sessions with DR/BDR only, the same as
>> the OSPF adjacency relationship? If so, if one of the BFD session that not
>> with the DR/BDR is DOWN, what’s the action then?
>>
>>
>>
>> *[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between
>> the routers and DR/BDR.  *
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> KT> Since LLS is present in both Hello and DD packets, not including the
>> B bit in DD packets will result in a different LLS options being seen in
>> *Cc:* [email-masked]; [email-masked];
>> [email-masked]>, Acee Lindem <
>> [email-masked]>, 'Albert Fu' <[email-masked]>
>> What I want to know is that where to encapsulate the LLS Data Block if
>> the router uses OSPFv3 Extended LSAs to establish the adjacency?
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> Most people deploy BFD with OSPF (or any routing protocols) to enable
>> fast failure detection. This is to ensure that routing/forwarding path is
>> As mentioned in a previous email, we have successfully tested this
>> feature on the Juniper MX (JUNOS 19.4) and also Cisco ASR9k (XR 7.3.2)
>> platforms.
>>
>>
>>
>> Thanks
>>
>> Albert Fu
>>
>> Bloomberg
>>
>>
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 30 Jan 2022 22:33:00 +0530

Hi Robert,

Thanks for your review and comments.

This email is in response to your first point "overpromise".

First, there is no text in the draft that "overpromises" that the strict
mode of operation detects "all forwarding" issues. We are talking about BFD
and its capabilities are well-known. It is not in the scope of this
document to discuss BFD capabilities and shortcomings (e.g. the MTU issue
you describe).

The draft text that you have asked to remove is important. It explains the
scenario of a noisy link that experiences traffic drops. I am aware of
issues in production networks, where we've had OSPF adjacency flaps
continuously or sporadically due to OSPF adjacency coming up somehow but
then BFD bringing it down. This causes routing churn and service
degradation. This is one of the key drivers for this draft.

However, welcome any text clarifications/suggestions for improving the
document.

Thanks,
Ketan

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 30 Jan 2022 22:38:14 +0530

Hi Robert,

Thanks for your review again and your comments/discussions.

This thread is about your second point "timer".

I would like to point out that the draft discusses the BFD "dampening" or
"hold-down" mechanism in Sec 5. We are aware of BFD implementations that
include such mechanisms in a protocol-agnostic manner.

This draft indicates that OSPF adjacency will "advance" in the neighbor FSM
only after BFD reports UP.  The BFD mechanisms/timers are outside the scope
of this document.

Please also see a further response on this point in your latest email on
this thread.

Thanks,
Ketan

On Sun, Jan 30, 2022 at 2:19 AM Robert Raszuk <[email-masked]> wrote:

> You are saying do not declare BFD as UP before all of those testing
> passes. That test sequence could be just running vanilla normal BFD for X
> seconds/minutes/hours.
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 30 Jan 2022 22:43:26 +0530

Hi Aijun,

There is a need for a BFD session to be established between neighboring
routers which directly forward data between them to ensure reachability
between them. That is my understanding of various implementations and
deployments at operators. This is independent of the strict mode of
operation.

Perhaps you have a different requirement for "optimization of BFD sessions
on multi-access networks"? If so, it would be clearer if you could put that
requirement/proposal together as a draft for the WG to review. Also, that
would be in any way independent of this specification since what you are
referring to is the base use of BFD by OSPF.

Thanks,
Ketan

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 30 Jan 2022 23:04:09 +0530

Hi Gyan,

Thanks for your review and your comments/feedback. Please check inline
below for responses.

> believe this gap still exists for BGP.

KT> We have
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bfd-strict-mode/

> implementation for delay knob makes sense.

KT> Please check Sec 5. The terminology used might differ between
implementations.

> language SHOULD Block and not MUST Block is the problem.

KT> There are implementations that provided knobs for this strict mode-like
behavior. The draft specifies the procedures for the same to be
standardized for multi-vendor interop and more importantly the ability to
signal/negotiate this mode of operation with neighbors.

> Gyan> Could you also introduce extension for IPV6 AF for discovery of IPv6 address?
KT> That is not required since we have the IPv6 link-local address that is
available for use.

> Gyan> Should we also have a LLS Data block B bit section for Local Interface IPv6 address TLV
KT> This is not required since the adjacency is either for IPv4 or IPv6 in
the case of OSPF in separate protocol instances and not a single adjacency
like in the case of ISIS.

> Gyan> What do you mean by “ e.g., in the event of transition from 2-way state)
KT> We can have OSPF neighbor FSM state transition from 2-way (or greater)
to Init state. In those cases, a BFD session may be already established or
requested and hence does not need to be initiated. You can put this into
the entire neighbor FSM of RFC2328 to get a full picture.

> Gyan> So in the LAN case RFC 5882 OSPF should not be blocked with LLS data block.
KT> We need to be able to interop and be backward compatible. That is the
main motivation. Normally, when all routers on a LAN support this spec,
they would all likely do strict-mode and not a mix.

> I see you mention 2-way but not fully Up.
>
>
KT> Full state comes after 2-way.

>  How would you stagger it allow BFD to come up
>
KT> I am not sure if I follow this question. In the non-strict mode of
operation, the OSPF adjacency can progress to its terminal state (e.g.
full) without any dependence on the BFD session establishment.

> Gyan> 2-way is not terminal state even for DROther routers

KT> We are talking about the Neighbor FSM State here.

> Gyan> Why would you not have also OSPFV3 IPv6 address family specifics

KT> Could you please check RFC5838 to know more about multi-AF operations
for OSPFv3?

Thanks,
Ketan

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 Jan 2022 19:04:56 +0100

Hi Ketan,

> include such mechanisms in a protocol-agnostic manner.

BFD dampening or hold-time are completely orthogonal to my point. Both have
nothing to do with it.

Those timers only fire when BFD goes down. In my example BFD does not go
down. But we want to bring up the client adj. only after X ms/sec/min etc
...of normal BFD operation if no failure is detected during that timer.

> only after BFD reports UP.
>

And that is exactly too soon. In fact if you do that today without waiting
some time (if you retire the current OSPF timer) you will not help at all
in the case you are trying to address.

Reason being that perhaps 200 ms after BFD UP it will go down, but OSPF
adj. will get already established. It is really pretty simple.

Thx,
Robert.

PS. And yes I think ISIS should also get fixed in that respect.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 Jan 2022 19:11:10 +0100

Hi Ketan,

> It explains the scenario of a noisy link that experiences traffic drops.

The point is that BFD may or may not detect noisy links or links with
"degraded or poor quality". There are many failure scenarios - especially
brownouts - where BFD will continue to run just fine over a link and where
at the same time user data will experience very poor performance.

So stating in the RFC that BFD may help to detect such cases is simply very
misleading (to say it gently :).

And you are stating so exactly in the below sentence:

*"In certain other scenarios, a degraded or poor quality link will allow
OSPF adjacency formation to succeed*
*but the BFD session establishment will fail or the BFD session will flap.*

Thx,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 30 Jan 2022 19:38:23 +0000

Robert –

Here is what you said (emphasis added):

<snip>
<end snip>

Point #1: If you want BFD to do more testing (such as MTU testing) then clearly you need extensions to BFD (such as https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )

Point #2: The existing timers (as Ketan points out are mentioned in Section 5) are applied today at the OSPF level precisely because OSPF does not currently have strict-mode operation. So in a flapping scenario you could see the following behavior:

a)BFD goes down
b)OSPF goes down in response to BFD
c)OSPF comes back up
d)Link is still unstable – so traffic is being dropped some of the time – but perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often enough to keep the OSPF adjacency up)

So some implementations have chosen to insert a delay following “b”. This doesn’t guarantee stability, but hopefully makes it less likely. And because OSPF today does NOT wait for BFD to come up, the delay has to be implemented at the OSPF level.

Once you have strict mode support, the sequence becomes:

a)BFD goes down
b)OSPF goes down in response to BFD
c)BFD comes back up
d)OSPF comes back up

Now, if the concern is that BFD comes back up while the link is still unstable, the way to address that is to put a delay either before BFD attempts to bring up a new session or a delay after achieving UP state before it signals UP to its clients – such as OSPF. This is a better solution because all BFD clients benefit from this. Ad if the link is still unstable, it is more likely that the BFD session will go down during the delay period than it would be for OSPF because the BFD timers are significantly more aggressive.
(BTW, this behavior can be done w/o a BFD protocol extension – it is purely an implementation choice.)

From a design perspective, dampening is always best done at the lowest layer possible. In most cases, interface layer dampening is best. If that is not reliable for some reason, then move one layer up – not two layers up.

   Les

From: Robert Raszuk <[email-masked]>
Sent: Sunday, January 30, 2022 10:05 AM
To: Ketan Talaulikar <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]; Albert Fu <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan,

I would like to point out that the draft discusses the BFD "dampening" or "hold-down" mechanism in Sec 5. We are aware of BFD implementations that include such mechanisms in a protocol-agnostic manner.

BFD dampening or hold-time are completely orthogonal to my point. Both have nothing to do with it.

Those timers only fire when BFD goes down. In my example BFD does not go down. But we want to bring up the client adj. only after X ms/sec/min etc ...of normal BFD operation if no failure is detected during that timer.

This draft indicates that OSPF adjacency will "advance" in the neighbor FSM only after BFD reports UP.

And that is exactly too soon. In fact if you do that today without waiting some time (if you retire the current OSPF timer) you will not help at all in the case you are trying to address.

Reason being that perhaps 200 ms after BFD UP it will go down, but OSPF adj. will get already established. It is really pretty simple.

Thx,
Robert.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 30 Jan 2022 14:50:31 -0500

Hi Ketan

Welcome.  Responses in-line

Kind Regards

On Sun, Jan 30, 2022 at 12:34 PM Ketan Talaulikar <[email-masked]>
wrote:

>> This is a real world problem that has existed with BFD that operators
>> have to deal with where OSPF adjacency comes up before BFD session
>> establishes resulting in cases where the link may have L1 issues or maybe a
>> dirty link or poor link quality resulting in BFD session establishment
>> followed by BFD immediately taking down the link.  With BFD tight timers
>> with client protocol registered ends up further exacerbating the issue with
>> link flaps resulting in IGP instability.
>>
Gyan> Understood to solve this issue for OSPF

> KT> Please check Sec 5. The terminology used might differ between

     Gyan> I see mention of BFD dampening for poor link quality issues.
However if BFD comes Up and establishes that would mean that at the time
the BFD session is established as control packet were received based on
interval and timer that the link is in a good state at the time of session
establishment. The main issue we are solving here is not allowing OSPF to
come Up on a link with packet forwarding issues. At that point when OSPF
FSM is initiated and goes to Full state we know the link to be stable as
BFD was established successfully prior.  If a link were in bad shape or
flapping BFD would not establish and that is the crux of this drafts
problem statement.  So I think to some degree this draft does preclude the
need for BFD dampening.

> KT> There are implementations that provided knobs for this strict
> mode-like behavior. The draft specifies the procedures for the same to be
    Gyan> It maybe good to reference RFC 5882 and state what the BFD
specification  says with regards to blocking IGP from coming up and that
this draft is following the specification that has been implemented by
other vendors and now making it standard for interoperability.

> KT> That is not required since we have the IPv6 link-local address that is
     Gyan> RFC 5613 LLS data block only applies to IPv4 and not IPv6 for
OSPFV3, Understood.   OSPFV3 has the Link Local LSA to signal the B bit to
block the adjacency from forming so would you still need that B flag update
to the Link Local LSA to get tbt same IPv4 LLS data block functionality

> like in the case of ISIS.

    Gyan> Understood.  OSPF would have separate v4 and v6 adjacency where
ISIS MT single adjacency.   I understand for OSPFv3 IPv4 AFI we need the
IPv4 address  TLV for discovery of neighbor IPv4 address which is not
needed for IPv6 since we have link local address and link local LSA for the
discovery.  I am still trying to understand how the LLS signaling of the B
bit would happen for OSPF IPv6 Address family using OSPFV3 or OSPFv3
address family instance RFC 5838.  Let’s say the interface is not dual
stacked and it’s IPv6 only how would you block the adjacency from forming?

> the entire neighbor FSM of RFC2328 to get a full picture.

   Gyan> The verbiage seems very loose that it’s not clearly saying that
BFD MUST be established before OSPF FSM is initiated. So you are saying
that when BFD session is requested so has not even started or the request
has completed which the way it’s worded the BFD session is clearly not
established and at the same time - in the event of ospf transition from
 2-way state to init or Full.  Which one.  Also if the LLS B bit is set my
understanding is OSPF has not even started and only after BFD is
established and the B bit is clear would OSPF initiate.

>> So this would be a LAN mix mode where not all nodes have BFD enabled
>> maybe want to mention to make it clear.
>>
>>

Gyan> The main motivation is to fix the problem with OSPF starting before
BFD to be implemented so that there is backwards compatibility.    I think
you should break out scenarios into P2P and LAN scenario.  This is how I
would reword.

   For Multi-access interfaces when BFD is enabled, but the strict-mode for
   operation has been signaled by multiple but not all neighbors, then an
   implementation SHOULD start the BFD session establishment only in
   2-Way state or higher state.  This makes it possible for an OSPF
   router to support BFD operation in both strict-mode and normal mode
   across different interfaces or even different neighbors.

   For interface with P2P subnet when BFD is enabled, but strict-mode for
   operation has been signaled by both neighbors, then an
   implementation SHOULD start the BFD session establishment at init state.

   In case one end of P2P link supports Strict mode and the other neighbor

   does not then BFD would come up in Normal mode.

> full) without any dependence on the BFD session establishment.
    Gyan> This was related to the interoperability with devices not
supporting on LAN with mix of devices.  I think if we reword as I stated
above specifying P2P and LAN scenario that would make it clearer.

> KT> We are talking about the Neighbor FSM State here.
    Gyan> Yes.  The verbiage is not clear.  Non DR is technically called
DROther router I believe.  Also the DROther router would be in Full state
and not 2-way, correct?

> KT> Could you please check RFC5838 to know more about multi-AF operations

    Gyan>  I understand OSPFv3 MI separate control plane and data plane
separate v4 and v6 adjacency I would think that as we have link local
address and link local local LSA we need to still set the B bit flag to
block the adjacency from forming for v6 control plane.   Imagine if no v4
and v6 congruency and v6 had to signal the B bit as we cannot rely on v4
instance for v6 adjacency since it’s separate adjacencies.  Also for IPv6
only scenario as well now you have to signal the B bit somehow so that flag
needs to be specified in the specification.

>>> Albert Fu <[email-masked]>; Acee Lindem (acee) <acee=
>>> KT> I think there is perhaps a misunderstanding of the purpose of BFD
>>> use with OSPF. Perhaps a careful reading of RFC5882 would help? In short,
>>> BFD is used to verify bidirectional connectivity between neighbors to
>>> ensure data may be forwarded between them. OSPF adjacency is built between
>>> every router in a LAN since they can directly forward packets between
>>> themselves.
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 Jan 2022 21:09:45 +0100

Hi Les,

> the way to address that is to put a delay either before BFD attempts to
bring up a new session

No this will not work. The BFD session must be fully up and BFD has to have
a chance for normal operation for X units of time. (By normal I mean with
existing or new BFD extensions which is out of scope of this discussion).

> or a delay after achieving UP state before it signals UP to its clients –
such as OSPF.

This is exactly what I am describing. Except you think that now BFD should
hold on on a per client or per OSPF neighbor basis and I think that it is
clients who should hold on from reacting to signaled UP state.

The way you are suggesting puts unnecessary burden on BFD where from BFD
POV link went up at t0 and never went down. It is the client who may need
to delay his action depending on the nature of the client.

At least we got to the point that both of us are clear on the topic.
Before when I see dampening or hold times insertion only indicates that
there was a mismatch in understanding. And to your examples imagine that
this is a new interface and BFD was never up before on it. The
behavior should be identical.

Thx,
R.

On Sun, Jan 30, 2022 at 8:38 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about *allowing
> BFD for more testing (with various parameters (for example increasing test
> packet size in some discrete steps)* before OSPF is happy to bring the
> adj. up.
>
> <end snip>
>
>
>
> Point #1: If you want BFD to do more testing (such as MTU testing) then
> clearly you need extensions to BFD (such as
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )
>
>
>
> Point #2: The existing timers (as Ketan points out are mentioned in
> Section 5) are applied today at the OSPF level precisely because OSPF does
> not currently have strict-mode operation. So in a flapping scenario you
> could see the following behavior:
>
>
>
> a)BFD goes down
>
> d)Link is still unstable – so traffic is being dropped some of the time –
> but perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often
> enough to keep the OSPF adjacency up)
>
>
>
> So some implementations have chosen to insert a delay following “b”. This
> doesn’t guarantee stability, but hopefully makes it less likely. And
> because OSPF today does NOT wait for BFD to come up, the delay has to be
> implemented at the OSPF level.
>
>
>
> Now, if the concern is that BFD comes back up while the link is still
> unstable, the way to address that is to put a delay either before BFD
> attempts to bring up a new session or a delay after achieving UP state
> before it signals UP to its clients – such as OSPF. This is a better
> solution because all BFD clients benefit from this. Ad if the link is still
> unstable, it is more likely that the BFD session will go down during the
> delay period than it would be for OSPF because the BFD timers are
> significantly more aggressive.
>
> From a design perspective, dampening is always best done at the lowest
> layer possible. In most cases, interface layer dampening is best. If that
> is not reliable for some reason, then move one layer up – not two layers up.
>
>
>
>    Les
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Sunday, January 30, 2022 10:05 AM
> *To:* Ketan Talaulikar <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <
> [email-masked]>; [email-masked]; Albert Fu <

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 30 Jan 2022 16:29:28 -0500

Hi Ketan

Minor cleanup on my part with normative language SHOULD to MUST.  This is
critical as we want to make sure interoperability works and no wiggle room
 or loopholes in misinterpretation of the specification.

The main motivation is to fix the problem with OSPF starting before BFD to
be implemented so that there is backwards compatibility.    I think you
should break out scenarios into P2P and LAN scenario.  This is how I would
reword.

   implementation MUST start the BFD session establishment only in

   For interface with P2P subnet when BFD is enabled, but strict-mode for
   operation has been signaled by both neighbors, then an
   implementation MUST start the BFD session establishment at init state.

Kind Regards

On Sun, Jan 30, 2022 at 2:50 PM Gyan Mishra <[email-masked]> wrote:

>>> This draft mirrors the ISIS block solution in RFC 6213   ISIS BFD
>>> enabled TLV.
>>>
>>> This issue exists with BGP as well where the protocol registered with
>>> BFD bootstrapped per RFC 5882 comes up before BFD resulting in
>>> instability.  I believe this gap still exists for BGP.
>>>
>>
>> KT> We have
>>> RFC 5880 BFD 3-way session establishment and  does the link integrity
>>> and  quality test by sending the BFD control packets to validate
>>> bi-directional forwarding liveliness detection over any media.
>>>
>> KT> That is not required since we have the IPv6 link-local address that
>> is available for use.
>>
>>
>> KT> This is not required since the adjacency is either for IPv4 or IPv6
>> in the case of OSPF in separate protocol instances and not a single
>> adjacency like in the case of ISIS.
>>
>
>> KT> We can have OSPF neighbor FSM state transition from 2-way (or
>> greater) to Init state. In those cases, a BFD session may be already
>> established or requested and hence does not need to be initiated. You can
>> put this into the entire neighbor FSM of RFC2328 to get a full picture.
>>
>
>>>> What I want to express is that you brought up the full mesh BFD
>>>> sessions among the routers within such network type. Is it necessary to
>>>> bring some of them(the BFD sessions between DRothers) to DOWN after the
>>>> OSPF adjacency are established between the DRother and DR/BDR router?
>>>> If not, then the traffic between these DRothers will be lost; If yes,
>>>> it seems strange, because the BFD session between the DRother and DR/BDR
>>>> may be still UP.
>>>>
>>>> *Cc:* Acee Lindem (acee) <acee=[email-masked]>;
>>>> [email-masked]; [email-masked]; Albert Fu <
>>>> [email-masked]>
>>>> KT> Since LLS is present in both Hello and DD packets, not including
>>>> the B bit in DD packets will result in a different LLS options being seen
>>>> in Hello and DD. This can trigger the change in LLS option logic
>>>> 'Acee Lindem (acee)' <[email-masked]>; 'Albert Fu' <[email-masked]
>>>> >
>>>> This document proposes changes to the adjacency establishment
>>>> procedures and the use of LLS for negotiations. As such, it is independent
>>>> of OSPFv3 Extended LSAs. Please let us know if you believe otherwise.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Ketan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This draft addresses an issue that we have encountered in our
>>>> production network, hence we have been actively working with our vendors.
>>>>
>>>>
>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 31 Jan 2022 10:16:20 +0530

Hi Robert,

The draft text refers to dampening and hold-down. The latter can be used
also for the initial session bring-up. The descriptions of those BFD
mechanisms are outside the scope of this document. If this needs to be
standardized at the IETF, then (IMHO) it would be best taken up in the BFD
WG so it can be leveraged for other protocols and use-cases as well.

We can update the text in Sec 5 to clarify this aspect as below.

OLD

   In network deployments with noisy links or those with packet loss,
   BFD sessions may flap frequently.  In such scenarios, OSPF strict-
   mode for BFD may be deployed in conjunction with a BFD dampening or
   hold-down mechanism to avoid frequent adjacency flaps that cause
   routing churn.

NEW

   In network deployments with noisy links with packet loss,
   BFD sessions may flap frequently.  In such scenarios, OSPF strict-
   mode for BFD may be deployed in conjunction with mechanisms such as

   hold-down (to delay initial adjacency bring up) and dampening (to avoid

   frequent adjacency flaps) in BFD to avoid frequent OSPF adjacency

   flaps that cause routing churn. The details of these BFD mechanisms

   are outside the scope of this document.

Thanks,
Ketan

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 31 Jan 2022 10:17:03 +0530

Hi Robert,

We can update this text in the Introduction section as follows:

OLD

   Note that it is possible
   in some failure scenarios for the network to be in a state such that
   an OSPF adjacency can be established but a BFD session cannot be
   established and maintained.  In certain other scenarios, a degraded
   or poor quality link will allow OSPF adjacency formation to succeed
   but the BFD session establishment will fail or the BFD session will
   flap. In this case, traffic that gets forwarded over such a link may

   experience packet drops while the failure of the BFD session
   establishment would not enable fast routing convergence if the link
   were to go down or flap.

NEW

   A degraded or poor quality link may result in intermittent packet

   drops. In such scenarios, sometimes an OSPF adjacency may be still

   get established over such link, but a BFD session may get

   established or maintained over it given the more aggressive

   monitoring intervals supported by BFD.  The traffic that gets forwarded

     over such a link would experience packet drops and the failure of the

   BFD session establishment would not enable fast routing convergence.

   Frequent OSPF adjaceny flaps may occur over such links as OSPF brings up the

      adjacency only for it to be brought down again by BFD.

Thanks,
Ketan

On Sun, Jan 30, 2022 at 11:41 PM Robert Raszuk <[email-masked]> wrote:

> So stating in the RFC that BFD may help to detect such cases is simply
> very misleading (to say it gently :).
>
>> The draft text that you have asked to remove is important. It explains
>> the scenario of a noisy link that experiences traffic drops. I am aware of

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 31 Jan 2022 10:18:11 +0530

Hi Les,

I agree with you that mechanisms like dampening and hold-down are best
achieved at the lowest levels (in this case in the monitoring protocol like
BFD) instead of in each routing protocol on the top.

Now whether this means we include/support the signaling of the parameters
for these mechanisms in BFD or whether they are achieved by provisioning
(as done currently by some implementations) is best discussed in the BFD WG.

Thanks,
Ketan

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 31 Jan 2022 10:18:28 +0530

Hi Gyan,

Please check inline with KT2.

> other vendors and now making it standard for interoperability.

KT2> Ack. We will add text for do this in the Introduction section.

> to the Link Local LSA to get tbt same IPv4 LLS data block functionality

KT2> LLS is for both OSPFv2 and OSPFv3. The B-bit is common and available
for OSPFv3 protocol instances both IPv4 and IPv6.

> stacked and it’s IPv6 only how would you block the adjacency from forming?

KT2> I hope the response to your previous comment clarifies this.

> established and the B bit is clear would OSPF initiate.

KT2> I am not sure if I follow. This document specifies the change in the
OSPF Neighbor FSM and it is assumed that the reader understands that well.
We are not going to describe state transitions into and out of Init state.
In short, BFD session establishment for a neighbor is triggered when it
starts in the Init state and the FSM is not allowed to progress further
into the 2way state until the BFD session is established.

> you should break out scenarios into P2P and LAN scenario.  This is how I

KT2> I am not sure what text and in which section you are suggesting to be
reworded. I do not see the difference in the behavior based on the type of
link when it comes to BFD strict mode.

> DROther router I believe.  Also the DROther router would be in Full state

KT2> This document is talking of OSPF Neighbor FSM state. I don't see the
need to discuss DR-Other or such terminologies in this document.

> needs to be specified in the specification.

KT2> I hope my response to a previous comment clarifies this.

Thanks,
Ketan

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 31 Jan 2022 00:39:31 -0500

Hi  Kethan

Thank you for answering all my questions. I am all set.

Responses in-line

Kind Regards

Gyan
On Sun, Jan 30, 2022 at 11:48 PM Ketan Talaulikar <[email-masked]>
wrote:

>> Welcome.  Responses in-line Gyan2
>>
>> Kind Regards
>>
>>>> I would like to note that RFC 5882 Generic Application of BFD does
>>>> state that if all neighbors support BFD then the registered control
>>>> protocol being bootstrapped should be blocked from coming up until BFD
>>>> session is established.  Only in case where all neighbors on a LAN do not
>>>> have BFD enabled, blocking the control protocol from coming Up would
>>>> prevent the control protocol from coming Up on neighbors that don’t have
>>>> BFD enabled.
>>>>

    Gyan2>  Excellent!  Thank you

> for OSPFv3 protocol instances both IPv4 and IPv6.

   Gyan2> Ack.  Makes sense

> KT2> I hope the response to your previous comment clarifies this.
     Gyan2> Yes it does, Thanks

> into the 2way state until the BFD session is established.
    Gyan2> Ack.  Thank you for explaining

>>> KT> We need to be able to interop and be backward compatible. That is
>>> the main motivation. Normally, when all routers on a LAN support this spec,

    Gyan2> Below verbiage is reword of section 4 6th paragraph.

Here is the original text

       “An implementation MUST NOT wait for BFD session establishment in
Init

   multi-access interface.”

> need to discuss DR-Other or such terminologies in this document.

    Gyan2> Ack

>>> KT> Could you please check RFC5838 to know more about multi-AF
>>> operations for OSPFv3?
>>>
>>

     Gyan2> Yes it does, Thanks

>>>>> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode
>>>>> for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>>>
>>>>>
>>>>>
>>>>> Hi, Ketan:
>>>>>
>>>>> If one of the BFD session(between DRothers) is DOWN, will it bring
>>>>> DOWN the OSPF adjacency(between the DRother and DR/BDR)?
>>>>>
>>>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode
>>>>> for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>>>
>>>>>
>>>>>
>>>>> Hi Aijun,
>>>>>
>>>>>
>>>>>
>>>>>     For the Broadcast/NMBA network type, if you establish BFD
>>>>> sessions before the DR/BDR selection, then there will be full mesh BFD
>>>>> sessions within the routers on such media type?
>>>>>
>>>>> [email-masked]; [email-masked]; Albert Fu
>>>>> <[email-masked]>
>>>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode
>>>>> for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>>>
>>>>>
>>>>>
>>>>> Hi Aijun,
>>>>>
>>>>>
>>>>>
>>>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode
>>>>> for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>>>
>>>>>
>>>>>
>>>>> Hi Aijun,
>>>>>
>>>>>
>>>>>
>>>>> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode
>>>>> for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>>>
>>>>>
>>>>>
>>>>> Hi, Ketan:
>>>>>
>>>>>
>>>>>
>>>>> I know. According to the description of RFC 5613, the LLS Data Block
>>>>> is only attached at the OSPF hello and DD packets.
>>>>>
>>>>>
>>>>>
>>>>> 'Acee Lindem (acee)' <[email-masked]>; 'Albert Fu' <
>>>>> [email-masked]>
>>>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode
>>>>> for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>>>
>>>>>
>>>>>
>>>>> Hi, Ketan:
>>>>>
>>>>> Acee Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>
>>>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode
>>>>> for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>>>
>>>>>
>>>>>
>>>>> Hi Aijun,
>>>>>
>>>>>
>>>>>
>>>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode
>>>>> for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Without this standard, as per most current default OSPF BFD
>>>>> deployment, OSPF adjacency is established without BFD. OSPF adjacency then
>>>>> triggers the BFD session to be established. If a "break-in-middle" issue
>>>>> occurred (where last mile interface status remains up) before BFD session
>>>>> comes up, we would lose the fast failure detection capability. This
>>>>> situation will require lengthy OSPF protocol timeout to detect such
>>>>> failure, resulting in traffic being black-holed for extended period.
>>>>>
>>>>>
>>>>>
>>>>> We have a large network consisting of several thousand links
>>>>> throughout the world, and have seen this issue several times that had
>>>>> impacted production traffic negatively.
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 31 Jan 2022 11:31:56 +0100

HI Ketan & Les,

To finish this topic I would like to observe that IMHO you have it quite
backwords.

*Comment #1*

The tone of your expressions is trying to illustrate that there can be many
clients for given link probing tool (here BFD). In reality the situation is
vastly different. There is usually one link state IGP running on the node
and given set of probing protocols are associated with it. Moreover, the
world does not end on BFD. BFD is just one possible tool, but more and more
path probing tools are emerging or are already deployed. Asking for each of
them to introduce into their state machine a new behaviour to delay
reporting UP state on a per client basis is nothing else then just pushing
the problem aways and not caring for the cost associated with it.

*Comment #2 *

BFD is a great tool to tell you if the end to end path is UP or DOWN. It
was not designed to give you any characteristics or metrics for the path
quality.

So all assertions of that notion in your draft are simply wrong. While sure
there are proposals to extend BFD probe packets with arbitrary large
payload to tell you if at some packet size you can still reach the other
end they are still nothing close to measure any form of link performance or
detect "A degraded or poor quality link"

Thx a lot,
R.

On Mon, Jan 31, 2022 at 5:48 AM Ketan Talaulikar <[email-masked]>
wrote:

> On Mon, Jan 31, 2022 at 1:08 AM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
>> Robert –
>>
>>
>>
>> But the timer I am suggesting is not related to BFD operation, but to
>> OSPF (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is
>> about *allowing BFD for more testing (with various parameters (for
>> example increasing test packet size in some discrete steps)* before OSPF
>> is happy to bring the adj. up.
>>
>> <end snip>
>>
>>
>>
>> [email-masked]>; [email-masked]; Albert Fu
>> <[email-masked]>; lsr <[email-masked]>
>> And that is exactly too soon. In fact if you do that today
>> without waiting some time (if you retire the current OSPF timer) you will
>> not help at all in the case you are trying to address.
>>
>>
>>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jan 2022 14:27:34 -0500

[Note that I read the LSR mailing list infrequently, but this thread was brought to my attention.]

I wish to largely support Robert's point here.  BFD is not intended as a link quality protocol.  It's a very simple hello protocol that can operate quite quickly and provide simple edge transition events of Up and Down.

There has been work in the BFD Working Group over the years to attempt to bring more of "link quality" behaviors to the protocol.  One, of interest to this thread, is the BFD for Large Packets work, which can support MTU probes as part of BFD operation.

draft-ietf-bfd-stability discusses leveraging BFD internal state to help look at link instability issues as BFD sees them.

And, of course, Greg Mirsky had several times he wanted to get BFD to do more active behaviors.  He was encouraged to leverage the BFD machinery in his own non-BFD draft if he found it helpful.  I suspect he'll respond to this thread with comments on his thinking here.

That said, the BFD strict work is about removing control-plane protocol ambiguity with regards to how it uses BFD and how the state machines interact with each other.  I think that work has been reasonably done.

The thing that BFD isn't about in such contexts is being more than a simple proxy for the link being of bad enough quality for BFD to go down taking the client protocols down with it.  It's important for those client protocols and the operators to set the timers and Detection Multiplier (number of lost packets) to speeds they think support their needs.  If you have a noisy link that can drop several packets in succession and that's what you want to be your trigger, BFD is your protocol.  If you want it to take an apparently continuous loss over most of a second, BFD can do that too if you tune your timers appropriately.

But, as you say Robert, it's not intended to be a general IPPM style tool.  I don't believe the BFD strict drafts should try to treat BFD as if it is one.

-- Jeff

> On Jan 31, 2022, at 5:31 AM, Robert Raszuk <[email-masked]> wrote:
> 
> HI Ketan & Les,
> 
> To finish this topic I would like to observe that IMHO you have it quite backwords. 
> 
> Comment #1
> 
> The tone of your expressions is trying to illustrate that there can be many clients for given link probing tool (here BFD). In reality the situation is vastly different. There is usually one link state IGP running on the node and given set of probing protocols are associated with it. Moreover, the world does not end on BFD. BFD is just one possible tool, but more and more path probing tools are emerging or are already deployed. Asking for each of them to introduce into their state machine a new behaviour to delay reporting UP state on a per client basis is nothing else then just pushing the problem aways and not caring for the cost associated with it. 
> 
> Comment #2 
> 
> BFD is a great tool to tell you if the end to end path is UP or DOWN. It was not designed to give you any characteristics or metrics for the path quality. 
> 
> So all assertions of that notion in your draft are simply wrong. While sure there are proposals to extend BFD probe packets with arbitrary large payload to tell you if at some packet size you can still reach the other end they are still nothing close to measure any form of link performance or detect "A degraded or poor quality link"
> 
> Thx a lot,
> R.
> 
> On Mon, Jan 31, 2022 at 5:48 AM Ketan Talaulikar <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Les,
> 
> I agree with you that mechanisms like dampening and hold-down are best achieved at the lowest levels (in this case in the monitoring protocol like BFD) instead of in each routing protocol on the top. 
> 
> Now whether this means we include/support the signaling of the parameters for these mechanisms in BFD or whether they are achieved by provisioning (as done currently by some implementations) is best discussed in the BFD WG.
> 
> Thanks,
> Ketan
> 
> 
> On Mon, Jan 31, 2022 at 1:08 AM Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>> wrote:
> Robert –
> 
>  
> 
> Point #1: If you want BFD to do more testing (such as MTU testing) then clearly you need extensions to BFD (such as https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ <https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/> )
> 
>  
> 
> From: Robert Raszuk <[email-masked] <mailto:[email-masked]>> 
> To: Ketan Talaulikar <[email-masked] <mailto:[email-masked]>>
> Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Albert Fu <[email-masked] <mailto:[email-masked]>>; lsr <[email-masked] <mailto:[email-masked]>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 31 Jan 2022 19:47:57 +0000

Jeff –

I appreciate that you have been pulled into reading a very lengthy thread and then commenting  on it – which is a difficult/time consuming  thing to do accurately.
And I certainly welcome your input and agree with your input.

I have not asked for BFD extensions.
I have stated that “IF” additional functionality is required from BFD that the proper place to discuss that is in the BFD WG – and such discussions are definitely not in scope of this draft.

The main content of this lengthy thread is Robert asking for additional specification in this draft and other folks (myself, Albert, Ketan) saying it doesn’t belong in this draft. Which is why I agree with everything you say below except for your perception that you are agreeing with Robert. You are actually agreeing with myself, Albert, Ketan. 😊

Thanx for your participation.

    Les

From: Jeffrey Haas <[email-masked]>
Sent: Monday, January 31, 2022 11:28 AM
To: Robert Raszuk <[email-masked]>
Cc: Ketan Talaulikar <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

-- Jeff

On Jan 31, 2022, at 5:31 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

HI Ketan & Les,

Comment #1

Comment #2

Thx a lot,
R.

On Mon, Jan 31, 2022 at 5:48 AM Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Les,

Thanks,
Ketan

On Mon, Jan 31, 2022 at 1:08 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

<snip>

a)BFD goes down

a)BFD goes down

   Les

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, January 30, 2022 10:05 AM
To: Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Albert Fu <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan,

Thx,
Robert.

PS. And yes I think ISIS should also get fixed in that respect.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 31 Jan 2022 20:55:08 +0100

> I have stated that “IF” additional functionality is required from BFD

No one says so, It would be not realistic to require for BFD to come up in
a hidden mode, operate for timer X then when timer X expires signal that to
clients. And this is precisely what you are suggesting as a push back.

It is client thing to delay their action according to the operational
needs.

Many thx,
R.

On Mon, Jan 31, 2022 at 8:48 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Jeff –
>
>
>
> I appreciate that you have been pulled into reading a very lengthy thread
> and then commenting  on it – which is a difficult/time consuming  thing to
> do accurately.
>
> I have stated that “IF” additional functionality is required from BFD that
> the proper place to discuss that is in the BFD WG – and such discussions
> are definitely not in scope of this draft.
>
>
>
> The main content of this lengthy thread is Robert asking for additional
> specification in this draft and other folks (myself, Albert, Ketan) saying
> it doesn’t belong in this draft. Which is why I agree with everything you
> say below except for your perception that you are agreeing with Robert. You
> are actually agreeing with myself, Albert, Ketan. 😊
>
>
>
> *From:* Jeffrey Haas <[email-masked]>
> *Sent:* Monday, January 31, 2022 11:28 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* Ketan Talaulikar <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; [email-masked]; Acee
> Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>; lsr <
> [email-masked]>
> I wish to largely support Robert's point here.  BFD is not intended as a
> link quality protocol.  It's a very simple hello protocol that can operate
> quite quickly and provide simple edge transition events of Up and Down.
>
>
>
> There has been work in the BFD Working Group over the years to attempt to
> bring more of "link quality" behaviors to the protocol.  One, of interest
> to this thread, is the BFD for Large Packets work, which can support MTU
> probes as part of BFD operation.
>
>
>
> draft-ietf-bfd-stability discusses leveraging BFD internal state to help
> look at link instability issues as BFD sees them.
>
>
>
> And, of course, Greg Mirsky had several times he wanted to get BFD to do
> more active behaviors.  He was encouraged to leverage the BFD machinery in
> his own non-BFD draft if he found it helpful.  I suspect he'll respond to
> this thread with comments on his thinking here.
>
>
>
> That said, the BFD strict work is about removing control-plane protocol
> ambiguity with regards to how it uses BFD and how the state machines
> interact with each other.  I think that work has been reasonably done.
>
>
>
> The thing that BFD isn't about in such contexts is being more than a
> simple proxy for the link being of bad enough quality for BFD to go down
> taking the client protocols down with it.  It's important for those client
> protocols and the operators to set the timers and Detection Multiplier
> (number of lost packets) to speeds they think support their needs.  If you
> have a noisy link that can drop several packets in succession and that's
> what you want to be your trigger, BFD is your protocol.  If you want it to
> take an apparently continuous loss over most of a second, BFD can do that
> too if you tune your timers appropriately.
>
>
>
> But, as you say Robert, it's not intended to be a general IPPM style
> tool.  I don't believe the BFD strict drafts should try to treat BFD as if
> it is one.
>
>
>
> -- Jeff
>
>
>
>
>
>
>
> The tone of your expressions is trying to illustrate that there can be
> many clients for given link probing tool (here BFD). In reality the
> situation is vastly different. There is usually one link state IGP running
> on the node and given set of probing protocols are associated with it.
> Moreover, the world does not end on BFD. BFD is just one possible tool, but
> more and more path probing tools are emerging or are already deployed.
> Asking for each of them to introduce into their state machine a new
> behaviour to delay reporting UP state on a per client basis is nothing else
> then just pushing the problem aways and not caring for the cost associated
> with it.
>
>
>
> *Comment #2 *
>
>
>
> So all assertions of that notion in your draft are simply wrong. While
> sure there are proposals to extend BFD probe packets with arbitrary large

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 31 Jan 2022 20:16:15 +0000

> I have stated that “IF” additional functionality is required from BFD

No one says so,
[LES:] Good. Can we end this thread then?
[
   Les

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jan 2022 15:29:43 -0500

Les,

> On Jan 31, 2022, at 2:47 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:

Agreed.

> The main content of this lengthy thread is Robert asking for additional specification in this draft and other folks (myself, Albert, Ketan) saying it doesn’t belong in this draft. Which is why I ag…

I was largely agreeing with Robert about the state of BFD and how it likely impacts the OSPF feature.  BFD isn't helpful beyond the Up/Down signaling, how it handles too much noise, etc.  So, I think we're all in agreement about these things.

What the protocol chooses to do about the signaling BFD provides is up to the protocol. I think we're all agreeing that the strict mode helps with making sure implementations use the inputs to their state machines consistently.

Whether there's any sort of "pause button" used by the implementation once the ordering is agreed upon seems to be where the disagreements have been.  Such a pause button isn't appropriate for BFD.  

And now we're fully in sync. :-)

-- Jeff

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 1 Feb 2022 11:57:49 +0530

Hi All,

The authors will work on and share the updated text to review with the WG.

Quickly want to point out that the draft does not bring any new
requirements in BFD for link quality monitoring; the stability issues that
we are discussing are related to BFD sessions going down due to
intermittent packet loss. If/when BFD WG brings any new enhancements,
protocols like OSPF will obviously leverage the same.

Thanks,
Ketan

On Tue, Feb 1, 2022 at 1:59 AM Jeffrey Haas <[email-masked]> wrote:

> I was largely agreeing with Robert about the state of BFD and how it
> likely impacts the OSPF feature.  BFD isn't helpful beyond the Up/Down
> signaling, how it handles too much noise, etc.  So, I think we're all in
> agreement about these things.
>
> What the protocol chooses to do about the signaling BFD provides is up to
> the protocol. I think we're all agreeing that the strict mode helps with
> making sure implementations use the inputs to their state machines
> consistently.
>
> Whether there's any sort of "pause button" used by the implementation once
> the ordering is agreed upon seems to be where the disagreements have been.
> Such a pause button isn't appropriate for BFD.
>