Subject: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)

From: Jeffrey Haas <[email-masked]>
Date: Tue, 4 Aug 2020 09:15:49 -0400

Working Group,

https://datatracker.ietf.org/doc/draft-cw-bfd-unaffiliated-echo/

At the virtual IETF 108, Unaffiliated BFD Echo Function was presented.  This
is a followup of a presentation given at IETF 106.

The authors have indicated they would like to have this work adopted by the
BFD WG.  This begins the adoption call ending August 16.  Please respond to
the mailing list with your thoughts on this adoption.

It should be noted that this document overlaps work in the Broadband Forum
(BBF) document TR-146.  As noted in the presentation, the BBF document lacks
some clarity and also doesn't discuss interactions with BFD implementations.
This draft has good clarifications with regard to implementations of this
mechanism when the a BFD Echo-capable implementation is used.

This raises two points to consider as part of adoption:
- This document with its current goals would Update RFC 5880.
- The status of this document would need to be Proposed Standard.

-- Jeff

---

From: <[email-masked]>
Date: Wed, 5 Aug 2020 10:37:59 +0800 (CST)

Hi all,

I support WG adoption of this draft (as co-author).

At the same time, I support to change its status to Proposed Standard, and add tag of "Updates RFC5880".

Best Regards,

Xiao Min

原始邮件

发件人：JeffreyHaas <[email-masked]>
收件人：[email-masked] <[email-masked]>;
日 期 ：2020年08月04日 21:04
主 题 ：Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August,2020)

Working Group,

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Aug 2020 19:51:12 -0700

Dear Authors,
thank you for the well-written document. I have several questions and
comments that are listed below:

   - An Introduction, states that

   it is not clear whether the devices
   using echo function need to support the full BFD procotol, including
   maintaining the state machine of BFD session as described in
   [RFC5880] and [RFC5881].

I think that Section 6.8.9 in RFC 5880 explicitly states:
   BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
   Up.  BFD Echo packets MUST NOT be transmitted unless the last BFD
   Control packet received from the remote system contains a nonzero
   value in Required Min Echo RX Interval.

Could you point to a statement in RFC 5880 or RFC 5881 that updates the
requirements above?

   - Based on my understanding of the BFD Echo function definition in RFC
   5880, the use case described in section 6.2.2 TR-146 is not based on the
   standard use of the BFD Echo function.
   - Section 2 describes the behavior of a BFD system in the Unaffiliated
   Echo mode. Would there be a BFD session created? If yes, which BFD state
   variables must be set?
   - Regarding the encapsulation of the BFD Echo in unaffiliated mode
   section 2 states

   device will send the BFD echo packets with the IP
   address destined for itself

Which address will be used in IPv4 and IPv6? Which address will be used as
the source IP address? And as we are discussing the IP encapsulation, which
value be set in the TTL/HL field?

   - in the second paragraph, Section 2 stated that

   the device that does not support
   BFD protocol immediately loops back the packet by normal IP
   forwarding, implementing quick link failure detection
It appears that the quick link failure detection is on the side of the
system that does not support the BFD protocol. Is that right?

   - Further, you describe that system A (Fig.1) "rapidly detect a
   connectivity loss to device B". How in the unaffiliated BFD Echo mode is
   controlled the rate of transition for the BFD Echo packets? RFC 5880 allows
   the remote system to use Required Min Echo RX Interval for that. Which
   mechanism would you recommend in the unaffiliated BFD Echo mode?
   - Additionally, how does system A detects a failure? RFC 5880 in Section
   6.8.5 gives a hint:

   a sufficient number of Echo
   packets have not arrived as they should, the session has gone down
but the mechanism to determine when an Echo packet should arrive and by
that when it is lost, as I understand the text in the section, is outside
the scope of RFC 5880. Do you have a recommendation on how system A
determines that a packet is lost?

   - nits:

s/BFD procotol/BFD protocol/3
s/capablity/capability/

Regards,
Greg

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Wed, 5 Aug 2020 16:51:57 +0800

Hi Greg,

Many thanks for your insightful questions and comments.

We've discussed them, please see inline our responses with <Weiqiang>.

Best Regards,

Weiqiang (on behalf of co-authors)

发件人: Rtg-bfd [mailto:[email-masked]] 代表 Greg Mirsky
发送时间: 2020年8月5日 10:51
收件人: Jeffrey Haas
抄送: rtg-bfd WG
主题: Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)

Dear Authors,

thank you for the well-written document. I have several questions and comments that are listed below:

·         An Introduction, states that

     Could you point to a statement in RFC 5880 or RFC 5881 that updates the requirements above?

     <Weiqiang> This draft would update RFC 5880. We've pointed some other text in RFC 5880 that needs to be updated, in a presentation given at IETF 106.

·         Based on my understanding of the BFD Echo function definition in RFC 5880, the use case described in section 6.2.2 TR-146 is not based on the standard use of the BFD Echo function. 

<Weiqiang> With this draft, we attempt to standardize the use of unaffiliated echo function, which has at least two use cases including that one described in section 6.2.2 of TR-146.

·         Section 2 describes the behavior of a BFD system in the Unaffiliated Echo mode. Would there be a BFD session created? If yes, which BFD state variables must be set?

<Weiqiang> Yes, there would be a BFD session. We think at least the following BFD state variables need be set:

bfd.SessionState

bfd.LocalDiscr

bfd.RemoteDiscr

bfd.DetectMult

·         Regarding the encapsulation of the BFD Echo in unaffiliated mode section 2 states

Which address will be used in IPv4 and IPv6? Which address will be used as the source IP address? And as we are discussing the IP encapsulation, which value be set in the TTL/HL field?

     <Weiqiang> Both the IP DA and IP SA are configurable, usually the local and the remote interface IP addresses of the detected link are used. TTL/HL is set to 255.

·         in the second paragraph, Section 2 stated that

   the device that does not support
   BFD protocol immediately loops back the packet by normal IP
   forwarding, implementing quick link failure detection
It appears that the quick link failure detection is on the side of the system that does not support the BFD protocol. Is that right?

     <Weiqiang> No, it's on the side of the local system that supports BFD protocol. Will reword to make it clear.

·         Further, you describe that system A (Fig.1) "rapidly detect a connectivity loss to device B". How in the unaffiliated BFD Echo mode is controlled the rate of transition for the BFD Echo packets? RFC 5880 allows the remote system to use Required Min Echo RX Interval for that. Which mechanism would you recommend in the unaffiliated BFD Echo mode?

<Weiqiang> It's by configuration, i.e., we configure at the local system the value of Required Min Echo RX Interval for the peer system.

·         Additionally, how does system A detects a failure? RFC 5880 in Section 6.8.5 gives a hint:

   a sufficient number of Echo
   packets have not arrived as they should, the session has gone down
but the mechanism to determine when an Echo packet should arrive and by that when it is lost, as I understand the text in the section, is outside the scope of RFC 5880. Do you have a recommendation on how system A determines that a packet is lost?

     <Weiqiang> The local system behaves the same as it's expecting to receive BFD Control Packets. At the local system, both the Required Min Echo RX Interval for the peer system and the desired Detection Time multiplier for BFD Echo Packets are configured by the operator.

·         nits:

     <Weiqiang> Good catch, will fix them, thank you.

Regards,

Greg

Working Group,

-- Jeff

---

From: Mach Chen <[email-masked]>
Date: Thu, 6 Aug 2020 08:58:27 +0000

Hi Jeff,

I have read the draft, it's useful draft. I support the adoption.

Best regards,
Mach

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Tuesday, August 4, 2020 9:16 PM
> To: [email-masked]
> Subject: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August,
> 2020)
> 
> Working Group,
> 
> BFD WG.  This begins the adoption call ending August 16.  Please respond
> to the mailing list with your thoughts on this adoption.
> 
> (BBF) document TR-146.  As noted in the presentation, the BBF document
> lacks some clarity and also doesn't discuss interactions with BFD
> implementations.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 14 Aug 2020 13:55:17 +0000

Hi All,

I believe the WG should adopt this document since this is a very useful extension for BFD protocol in specific scenarios. While the document needs more details on the applicability, operational guidance and procedures, it does provide a very good starting point for the WG to address this topic/requirement.

I also believe that while the proposal may not involve new/updated encodings, it certainly describes modified protocol procedures and so likely belongs to standards track. I have a feeling that it might also end up updating RFC5880 as we go along.

Thanks,
Ketan

-----Original Message-----
From: Rtg-bfd <[email-masked]> On Behalf Of Jeffrey Haas
Sent: 04 August 2020 18:46
To: [email-masked]
Subject: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)

Working Group,

At the virtual IETF 108, Unaffiliated BFD Echo Function was presented.  This is a followup of a presentation given at IETF 106.

The authors have indicated they would like to have this work adopted by the BFD WG.  This begins the adoption call ending August 16.  Please respond to the mailing list with your thoughts on this adoption.

It should be noted that this document overlaps work in the Broadband Forum
(BBF) document TR-146.  As noted in the presentation, the BBF document lacks some clarity and also doesn't discuss interactions with BFD implementations.
This draft has good clarifications with regard to implementations of this mechanism when the a BFD Echo-capable implementation is used.

-- Jeff

---

From: Santosh P K <[email-masked]>
Date: Sun, 16 Aug 2020 20:55:50 +0530

Hello Authors,
    I read the document and I do have some questions.

In section 1 text below

"When using BFD echo function, it is not clear whether the devices using
echo function need to support the full BFD procotol, including maintaining
the state machine of BFD session as described in [RFC5880] and [RFC5881].
According to different understanding, there are two typical scenarios as
below:"

I think RFC 5880 section 6.4 "The Echo Function and Asymmetry" clearly
calls out BFD echo function is negotiated and also it suggests to keep BFD
state machine on both ends with a sedated interval. So not sure why you
mention it is not clear in RFC 5880.

Secondly if we do not need BFD async then it need not be BFD echo it can be
any packet which is has destination IP set to self IP can do that job isn't
it?

Thanks
Santosh P K

On Tue, Aug 4, 2020 at 6:34 PM Jeffrey Haas <[email-masked]> wrote:

> lacks

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 17 Aug 2020 14:07:33 +0800

Hi Santosh,

Thanks for your review and good questions.

Please see inline responses with <Weiqiang>.

Best Regards,

Weiqiang

发件人: Rtg-bfd [mailto:[email-masked]] 代表 Santosh P K
发送时间: 2020年8月16日 23:26
收件人: Jeffrey Haas
抄送: rtg-bfd WG
主题: Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)

Hello Authors,

In section 1 text below

"When using BFD echo function, it is not clear whether the devices using echo function need to support the full BFD procotol, including maintaining the state machine of BFD session as described in [RFC5880] and [RFC5881]. According to different understanding, there are two typical scenarios as below:"

I think RFC 5880 section 6.4 "The Echo Function and Asymmetry" clearly calls out BFD echo function is negotiated and also it suggests to keep BFD state machine on both ends with a sedated interval. So not sure why you mention it is not clear in RFC 5880. 

<Weiqiang> This draft would update RFC 5880, in other words, some text in RFC 5880 would not apply to unaffiliated BFD echo function.

Secondly if we do not need BFD async then it need not be BFD echo it can be any packet which is has destination IP set to self IP can do that job isn't it? 

<Weiqiang> In this draft, unaffiliated BFD Echo Function is defined as that the local system needs to support BFD protocol. If both the local system and the neighboring system don't support BFD, then it's outside the scope of this draft.

Thanks

Santosh P K 

 

Working Group,

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Aug 2020 16:50:46 -0400

Authors,

We seem to have pretty clear consensus that this work is useful and should
be adopted by the BFD Working Group.

Please re-submit the document as draft-ietf-bfd-unaffiliated-echo.

There's also the start of good discussion on issues in the document.  Please
continue to address those.

-- Jeff