Re: Comments on draft-ietf-bfd-unaffiliated-echo-08 Mon, 25 September 2023 06:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2530C14CE42; Sun, 24 Sep 2023 23:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AN0AZ1B9bsVV; Sun, 24 Sep 2023 23:11:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7711FC14CF17; Sun, 24 Sep 2023 23:11:00 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4RvCDH549wz8XrRJ; Mon, 25 Sep 2023 14:10:55 +0800 (CST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4RvCCl63L6z4xVcS; Mon, 25 Sep 2023 14:10:27 +0800 (CST)
Received: from ([]) by with SMTP id 38P68ZAd017197; Mon, 25 Sep 2023 14:09:32 +0800 (+08) (envelope-from
Received: from mapi (njb2app07[null]) by mapi (Zmail) with MAPI id mid201; Mon, 25 Sep 2023 14:09:34 +0800 (CST)
Date: Mon, 25 Sep 2023 14:09:34 +0800
X-Zmail-TransId: 2aff6511241e7a3-f3fb6
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 38P68ZAd017197
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6511246F.000/4RvCDH549wz8XrRJ
Archived-At: <>
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Sep 2023 06:11:07 -0000

Dear Ketan,

Thanks for your review and thoughtful comments.
Please see inline.


From: KetanTalaulikar <>
To: <>;
Cc: <>;Jeffrey Haas <>;
Date: 2023年09月22日 22:55
Subject: Comments on draft-ietf-bfd-unaffiliated-echo-08

Hello Authors,

Looks like I've missed the WGLC on this document, but nevertheless would like to share the following comments:

Sec 1 of the document says:

Section 5 of [RFC5880] indicates that the payload of an affiliated BFD Echo packet is a local matter and hence its contents are outside the scope of that specification. This document, on the other hand, specifies the contents of the Unaffiliated BFD Echo packet and what to do with them.

However, when I go through the procedures in Section 2, there is no description of the actual construction of the IP packet that A sends out to B - what is the source and destination IP - or MAC addresses for that matter? How is it that B would loop it back? I believe it is important for the document to specify this.
[XM]>>> This document does specify the source and destination IP, through reference to RFC 5881. In section 2 it says
"Regarding the selection of IP address, the rules stated in Section 4 of [RFC5881] are applicable to the encapsulation of an Unaffiliated BFD Echo packet."
In -07 version the rules of RFC 5881 were restated, however in -08 version they're removed by following the suggestion from Greg.

Another important part is that normally BFD verifies the bidirectional path, the liveness of the other endpoint, but also validates the presence of a specific IP at that endpoint. Is that still the case when operating in this mode? This question arises since the document talks about liveness to servers - so is it monitoring liveness to the server host or a specific server IP?
[XM]>>> It's monitoring liveness to the server host, not a specific server IP. Also note that the Unaffiliated BFD Echo can be used for multiple use cases, in section 1 it says
"Section 6.2.2 of [BBF-TR-146] describes one use case of the Unaffiliated BFD Echo. Section 2 of [] describes another use case of the Unaffiliated BFD Echo."

Finally, is it normal or natural to expect server hosts to be able to "loop them back by normal IP forwarding"? Or does it require some additional/special capabilities to be turned ON those hosts as hosts don't do forwarding by default.
[XM]>>> As I know of a deployment, there is no need to turn ON those hosts. At the same time, it's feasible to have such a knob. Propose to add some text as below.
The method for provisioning device B to loop back BFD Unaffiliated Echo packets is outside the scope of this document.
There may be a knob to turn on/off the loopback of Unaffiliated BFD Echo packets at device B. The method for provisioning device B to loop back Unaffiliated BFD Echo packets is outside the scope of this document.

Best Regards,
Xiao Min

It would help if these aspects are clarified in the document.


On Thu, Jul 6, 2023 at 7:50 AM <> wrote:

 A New Internet-Draft is available from the on-line Internet-Drafts
 directories. This Internet-Draft is a work item of the Bidirectional
 Forwarding Detection (BFD) WG of the IETF.
    Title           : Unaffiliated BFD Echo
    Authors         : Weiqiang Cheng
                      Ruixue Wang
                      Xiao Min
                      Reshad Rahman
                      Raj Chetan Boddireddy
    Filename        : draft-ietf-bfd-unaffiliated-echo-08.txt
    Pages           : 12
    Date            : 2023-07-05
    Bidirectional Forwarding Detection (BFD) is a fault detection
    protocol that can quickly determine a communication failure between
    two forwarding engines.  This document proposes a use of the BFD Echo
    where the local system supports BFD but the neighboring system does
    not support BFD.  BFD Control packet and its processing procedures
    can be executed over the BFD Echo port where the neighboring system
    only loops packets back to the local system.
    This document updates RFC 5880.
 The IETF datatracker status page for this Internet-Draft is:
 There is also an htmlized version available at:
 A diff from the previous version is available at:
 Internet-Drafts are also available by rsync at