Subject: [Idr] WG adoption call for draft-haas-idr-bfd-subcode-00.txt - Ends 02/04/2022

From: Keyur Patel <[email-masked]>
Date: Fri, 21 Jan 2022 23:01:19 +0000

Hi Folks:

This is a Working Group adoption call for draft-haas-idr-bfd-subcode-00, “BGP Cease Notification Subcode for BFD”.  Please reply to the list with your comments. This adoption call will conclude on February 4th, 2022.

The draft can be found at: https://datatracker.ietf.org/doc/draft-haas-idr-bfd-subcode/.

Best Regards,
Keyur

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 Jan 2022 07:47:34 +0800

Hi, Jeffrey:

Would you like to illustrate the scenarios that “when the BFD session is in DOWN state, but the BGP speakers can send out the NOTIFICATION messages to the remote peer? “ Also what you mentioned in your draft as “partial loss of connection”.

Aijun Wang
China Telecom

> On Jan 22, 2022, at 07:01, Keyur Patel <[email-masked]> wrote:
> 
> 
> Hi Folks:
>  
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Jan 2022 18:56:37 -0500

Aijun,

BFD can have very quick timers compared to BGP and TCP. Consider the case where BFD is running between two systems with an interval of 50ms and a detection multiplier of 3. 

150ms of link loss will cause BFD to go down. 

BGP and TCP operating at much longer time lines might need a retransmission or two for the same event, if anything at all can be noticed. 

This discrepancy between what BGP can notice and leave the session up enough to send messages and BFD going down fast often can lead operators to need to figure out what the root cause is. This notification message helps standardize a method to report when BFD is that root cause. 

Jeff

> On Jan 21, 2022, at 6:47 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Jeffrey:
>

---

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

Even faster than a speeding Prefix Unreachable Advertisement…
Acee

From: Idr <[email-masked]> on behalf of Jeff Haas <[email-masked]>
Date: Friday, January 21, 2022 at 6:57 PM
To: Aijun Wang <[email-masked]>
Cc: Keyur Patel <[email-masked]>, IDR List <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-haas-idr-bfd-subcode-00.txt - Ends 02/04/2022

Aijun,

Jeff

Aijun Wang
China Telecom

Best Regards,
Keyur

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 22 Jan 2022 00:13:26 +0000

I also support WG adoption of the draft.
Thanks,
Acee

From: Acee Lindem <[email-masked]>
Date: Friday, January 21, 2022 at 7:04 PM
To: Jeff Haas <[email-masked]>, Aijun Wang <[email-masked]>
Cc: Keyur Patel <[email-masked]>, IDR List <[email-masked]>
Subject: Re: [Idr] WG adoption call for draft-haas-idr-bfd-subcode-00.txt - Ends 02/04/2022

Aijun,

Jeff

Aijun Wang
China Telecom

Best Regards,
Keyur

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 Jan 2022 08:20:50 +0800

Hi, Jeffrey:
Yes. I know the discrepancy.
What I think is that if the BFD session is in DOWN state, then the peer will not be reachable. Any message sent out from the Local BGP Peer cannot reach the remote BGP Peer.
Or, you are aiming at the scenarios that the BFD detection gives the wrong information, or “false positive”?

Aijun Wang
China Telecom

> On Jan 22, 2022, at 07:56, Jeffrey Haas <[email-masked]> wrote:
> 
> Aijun,
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 22 Jan 2022 01:32:25 +0100

Aijun,

BFD can be down (LC serving that session has an issue) but RP/RE and BGP
could still run just fine.

Moreover I think there is still value in sending those additional
information as in many network BGP sessions (as well as user sessions) are
monitored and recorded so it will be more informative to the operators to
troubleshoot the root cause.

No one states here that the information needs to arrive at the other BGP
peer not that the other BGP peer needs to do some action upon receiving it.

Thx,
R.

On Sat, Jan 22, 2022 at 1:21 AM Aijun Wang <[email-masked]>
wrote:

> What I think is that if the BFD session is in DOWN state, then the peer
> will not be reachable. Any message sent out from the Local BGP Peer cannot
> reach the remote BGP Peer.
> BFD can have very quick timers compared to BGP and TCP. Consider the case
> where BFD is running between two systems with an interval of 50ms and a
> detection multiplier of 3.
>
> BGP and TCP operating at much longer time lines might need a
> retransmission or two for the same event, if anything at all can be
> noticed.
>
> This discrepancy between what BGP can notice and leave the session up
> enough to send messages and BFD going down fast often can lead operators to
> need to figure out what the root cause is. This notification message helps
> standardize a method to report when BFD is that root cause.
>
>
>
> Jeff
>
> Would you like to illustrate the scenarios that “when the BFD session is
> in DOWN state, but the BGP speakers can send out the NOTIFICATION messages
> to the remote peer? “ Also what you mentioned in your draft as “partial
> loss of connection”.
>
>
> Aijun Wang
> China Telecom
>
> This is a Working Group adoption call for draft-haas-idr-bfd-subcode-00,
> “BGP Cease Notification Subcode for BFD”.  Please reply to the list with
> your comments. This adoption call will conclude on February 4th, 2022.
>
>
>
> The draft can be found at:
> https://datatracker.ietf.org/doc/draft-haas-idr-bfd-subcode/.
>
>
>
> Best Regards,
>
> Keyur

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 Jan 2022 08:56:39 +0800

Hi, Robert:

> On Jan 22, 2022, at 08:32, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> BFD can be down (LC serving that session has an issue) but RP/RE and BGP could still run just fine. 
[WAJ]Yes. What I want to state is that if the LC has issues, the BGP control messages will not be sent out also.

> 
> Moreover I think there is still value in sending those additional information as in many network BGP sessions (as well as user sessions) are monitored and recorded so it will be more informative to the operators to troubleshoot the root cause. 
[WAJ]Then I think you are mentioning it is useful at the debug state in local BGP peer?  
> 
> No one states here that the information needs to arrive at the other BGP peer not that the other BGP peer needs to do some action upon receiving it. 

[WAJ]The draft describes the possibility, I am just curious in which situation it will occur:

“In the event of a BGP session being terminated due to a BFD Down
   event from partial loss of connectivity as detected by BFD, the
   remote BGP Speaker might be able to receive the BGP NOTIFICATION
   message with the BFD Down Subcode.  The receiving BGP Speaker will
   then have an understanding that the session is being terminated
   because of a BFD-detected issue and not an issue with the BGP
   implementation.”

> 
> Thx,
> R.
> 
>> On Sat, Jan 22, 2022 at 1:21 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Jeffrey:

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 22 Jan 2022 02:05:07 +0100

> [WAJ]Yes. What I want to state is that if the LC has issues, the BGP
control messages will not be sent out also.

That may not be the correct statement. LC ASIC bugs or failures are likely
to affect local processing of BFD replies not RP/RE traffic.

> [WAJ]Then I think you are mentioning it is useful at the debug state in
local BGP peer?

Oh yes ... 100%. That's main (if not only use for it).

Thx,
R.

On Sat, Jan 22, 2022 at 1:56 AM Aijun Wang <[email-masked]>
wrote:

> [WAJ]Yes. What I want to state is that if the LC has issues, the BGP
> control messages will not be sent out also.
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 21 Jan 2022 21:59:39 -0500

I support WG adoption.

This will really help the NOC in troubleshooting partial one way link
failures where  BFD went down.

Thanks

Gyan

On Fri, Jan 21, 2022 at 8:05 PM Robert Raszuk <[email-masked]> wrote:

>>> BFD can have very quick timers compared to BGP and TCP. Consider the
>>> case where BFD is running between two systems with an interval of 50ms and
>>> a detection multiplier of 3.
>>>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 22 Jan 2022 08:35:28 +0000

Aijun Wang wrote on 22/01/2022 00:20:
> will not be reachable. Any message sent out from the Local BGP Peer 
> cannot reach the remote BGP Peer.

not necessarily true: for example, if a link flipped from full-duplex to 
half-duplex (a reasonable common failure mode on longer haul links), the 
bfd session might be down, even if one of the sides could communicate 
unidirectionally with the other, and could send a failure message like 
this. Not every link failure is a complete failure.

In any event, whether the message gets through or not, the sending side 
will log the failure in the bgpPeerLastError oid of the relevant bgp 
mib, which will be visible to monitoring systems.  This alone is worth 
the draft from an operational viewpoint.

Nick

---

From: Aijun Wang <[email-masked]>
Date: Sat, 22 Jan 2022 17:02:15 +0800

Hi, Nick:
Thanks for your explanation.
It will be better to add these descriptions within the draft.

Support its adoption.

Aijun Wang
China Telecom

> On Jan 22, 2022, at 16:35, Nick Hilliard <[email-masked]> wrote:
> 
> not necessarily true: for example, if a link flipped from full-duplex to half-duplex (a reasonable common failure mode on longer haul links), the bfd session might be down, even if one of the sides could communicate unidirectionally with the other, and could send a failure message like this. Not every link failure is a complete failure.
> 
> In any event, whether the message gets through or not, the sending side will log the failure in the bgpPeerLastError oid of the relevant bgp mib, which will be visible to monitoring systems.  This alone is worth the draft from an operational viewpoint.
> 
> Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 22 Jan 2022 08:43:16 -0500

> [WAJ]Yes. What I want to state is that if the LC has issues, the BGP control messages will not be sent out also.

Even in the absence of half duplex errors mentioned later in the thread, it
is possible for BFD to transition to down without impacting BGP's ability to
transmit.  I gave the earlier example of temporary line loss.  Perhaps
someone got some fiber a bit too twisted while moving cabling. :-)

Protocols, like BGP, that use BFD look for the edge transition from Up to Down
to make their decisions.  The BGP implementations I'm aware of using BFD
don't wait for BFD to be down for a specific period of time - once BFD goes
down, the BGP session goes down.

> [WAJ]Then I think you are mentioning it is useful at the debug state in local BGP peer?  

That's the main purpose in the draft.

The primary purpose for me is to stop servicing bug reports that "BGP went
down" when my BGP group should pass the bug report to the BFD group. :-)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 22 Jan 2022 08:46:35 -0500

> It will be better to add these descriptions within the draft.

It's here in the draft:
:   When there is a total loss of connectivity between two BGP Speakers,
:   it may not be possible for the NOTIFICATION message to have been
:   sent.  Even so, BGP implementations may provide this reason as part
:   of their operational state; e.g. bgpPeerLastError in the BGP MIB.
:   [RFC4273].

I'd prefer to not try to enumerate every failure scenario that BFD can go
down in a BGP focused draft.  There are many.

That said, if there's a specific bit of text you think would help clarity,
please supply a suggested edit.

> Support its adoption.

Thanks!

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 25 Jan 2022 13:24:02 -0500

<wg-member hat on> 

Support for adoption.   More debugging information on outages is good. 

BGP connections in the past have had the “half-duplex” problem and TCP session going a “long-way around” from loop back to remote Peer. 

Sue

From: Idr [mailto:[email-masked]] On Behalf Of Keyur Patel
Sent: Friday, January 21, 2022 6:01 PM
To: [email-masked]
Subject: [Idr] WG adoption call for draft-haas-idr-bfd-subcode-00.txt - Ends 02/04/2022

Hi Folks:

Best Regards,

Keyur