Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)

xiao.min2@zte.com.cn Thu, 17 October 2024 07:07 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98834C169409; Thu, 17 Oct 2024 00:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljUfCt54uWj5; Thu, 17 Oct 2024 00:07:11 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9CDC169403; Thu, 17 Oct 2024 00:07:02 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4XTf5n5HW7z5B18Y; Thu, 17 Oct 2024 15:06:53 +0800 (CST)
Received: from njy2app08.zte.com.cn ([10.40.13.206]) by mse-fl2.zte.com.cn with SMTP id 49H76cnM003582; Thu, 17 Oct 2024 15:06:38 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njb2app06[null]) by mapi (Zmail) with MAPI id mid201; Thu, 17 Oct 2024 15:06:40 +0800 (CST)
Date: Thu, 17 Oct 2024 15:06:40 +0800
X-Zmail-TransId: 2afe6710b78066b-1e6c5
X-Mailer: Zmail v1.0
Message-ID: <202410171506404787tbp4qo2Bgj1LvobhCI8W@zte.com.cn>
In-Reply-To: <308DBE7C-2773-49CD-A87B-E0FB71ED1606@gmail.com>
References: 172901343981.1094646.17406117786916732069@dt-datatracker-78dc5ccf94-w8wgc,20241016110351528jZXD5gr5e30sfuDSc6Q97@zte.com.cn,308DBE7C-2773-49CD-A87B-E0FB71ED1606@gmail.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: mjethanandani@gmail.com
Subject: Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 49H76cnM003582
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6710B78D.002/4XTf5n5HW7z5B18Y
Message-ID-Hash: A7AR4KEE4YVBJIHDCOBWVDM4OAN4ZZQO
X-Message-ID-Hash: A7AR4KEE4YVBJIHDCOBWVDM4OAN4ZZQO
X-MailFrom: xiao.min2@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-bfd.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: iesg@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org, bfd-chairs@ietf.org, rtg-bfd@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection" <rtg-bfd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Ee-1cwVakUQQl6J8ccWcFWmOAXE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-bfd-owner@ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Subscribe: <mailto:rtg-bfd-join@ietf.org>
List-Unsubscribe: <mailto:rtg-bfd-leave@ietf.org>

Hi Mahesh,
Thank you for the prompt feedback.
Please see inline.


Original


From: MaheshJethanandani <mjethanandani@gmail.com>
To: 肖敏10093570;
Cc: The IESG <iesg@ietf.org>;draft-ietf-bfd-unaffiliated-echo@ietf.org <draft-ietf-bfd-unaffiliated-echo@ietf.org>;bfd-chairs@ietf.org <bfd-chairs@ietf.org>;rtg-bfd@ietf. <rtg-bfd@ietf.org>;
Date: 2024年10月17日 02:41
Subject: Re: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)


Hi Xiao,

Thanks for addressing most of my comments. Just a couple of followup question. See inline with [mj]
On Oct 15, 2024, at 8:03 PM, <xiao.min2@zte.com.cn> <xiao.min2@zte.com.cn> wrote:



Hi Mahesh,
Thanks for your review and comments.Please see inline.




[mj] I think I saw a similar comment on one of the other threads. It is not clear whether this “loopback” of packets is happening at layer 1 (physical) or layer 2 (IP layer). From the sound of it, it appears it is happening at layer 1, or at least where there is no lookup of IP address(es) happening. If there was, the destination address could be more than one hop away. In either case, clarifying how the packets are being “looped” back would help.
[XM]>>> I noticed there was some discussion between you and Jeff. I'll respond to that discussion on this item.





[mj] Sorry, if I was not explicit in my ask for being explicit :-). 

What I was referring to was that the notion of a BFD “session” in Unaffiliated BFD Echo only exists on Device A as it is the only one to implement the BFD stack. So when you say “until the session in Up”, what you really mean is “until the session on Device A is Up”. Similarly, when you say “session goes Down”, you really mean “session on Device A goes Down”.

Is this a little more clear?
[XM]>>> Aha, I see your point. :-) Yes, your text is more clear.

Best Regards,
Xiao Min

Thanks.



Cheers,
Xiao Min









Mahesh Jethanandani
mjethanandani@gmail.com




 





From: MaheshJethanandaniviaDatatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>;
Cc: draft-ietf-bfd-unaffiliated-echo@ietf.org <draft-ietf-bfd-unaffiliated-echo@ietf.org>;bfd-chairs@ietf.org <bfd-chairs@ietf.org>;rtg-bfd@ietf.org <rtg-bfd@ietf.org>;
Date: 2024年10月16日 01:31
Subject: Mahesh Jethanandani's No Objection on draft-ietf-bfd-unaffiliated-echo-12: (with COMMENT)

Mahesh Jethanandani has entered the following ballot position fordraft-ietf-bfd-unaffiliated-echo-12: No ObjectionWhen responding, please keep the subject line intact and reply to allemail addresses included in the To and CC lines. (Feel free to cut thisintroductory paragraph, however.)Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  for more information about how to handle DISCUSS and COMMENT positions.The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/----------------------------------------------------------------------COMMENT:----------------------------------------------------------------------Section 1, paragraph 2>    BFD [RFC5880] is a low-overhead, short-duration method to detect>    faults on the communication path between adjacent forwarding engines.>    The faults can be on interfaces, data links, and even the forwarding>    engines.  It is a single, unified mechanism to monitor any media and>    protocol layers in real time.I do not know if "short-duration" is the right way to describe a "BFD session",even as the document says it is not a "BFD session". Whatever you call thecontinious sending of packets that are echoed back, which in my mind is asession, it can run with a short interval, but can run for a very longduration. Maybe "short-interval"?
[XM]>>> Make sense. Will do s/short-duration/short-interval.


Section 1, paragraph 9>    This document updates [RFC5880] by defining a new method of BFD Echo->    Only without requiring an implementation to support the full BFD>    protocol.  It specifies the use of the Unaffiliated BFD Echo over>    IPv4 and IPv6 for a single IP hop.  A full description of the updates>    to [RFC5880] is provided in Section 3.As noted in Gyan Mishra's review, even as it might be obvious to some, it wouldhelp to clarify why Unaffliated BFD Echo cannot be supported over multi-hop BFD.
[XM]>>> OK. Propose to add some text as below.
OLD
It specifies the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. A full description of the updates to [RFC5880] is provided in Section 3.
NEW
It specifies the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for multihop paths is that the Unaffiliated BFD Echo packets would be looped back by the first hop. A full description of the updates to [RFC5880] is provided in Section 3.