Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

xiao.min2@zte.com.cn Tue, 11 April 2023 06:52 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 88A50C14CE52 for <rtg-bfd@ietfa.amsl.com>; Mon, 10 Apr 2023 23:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6qN3yjAB5kUQ for <rtg-bfd@ietfa.amsl.com>; Mon, 10 Apr 2023 23:52:35 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA30C14CE42 for <rtg-bfd@ietf.org>; Mon, 10 Apr 2023 23:52:34 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (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 4Pwc3N2JkZz8RV7V; Tue, 11 Apr 2023 14:52:32 +0800 (CST)
Received: from njb2app07.zte.com.cn ([10.55.22.95]) by mse-fl1.zte.com.cn with SMTP id 33B6qL0L017973; Tue, 11 Apr 2023 14:52:21 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid201; Tue, 11 Apr 2023 14:52:23 +0800 (CST)
Date: Tue, 11 Apr 2023 14:52:23 +0800
X-Zmail-TransId: 2af9643503a7ffffffff95b-2a652
X-Mailer: Zmail v1.0
Message-ID: <202304111452239222213@zte.com.cn>
In-Reply-To: <B353182A-8BC6-4F25-BD8B-33E2919311BE@pfrc.org>
References: CA+RyBmXtST1EZcba_RM90NLf5hYAiKL2+XjSZwO2r-d_XNjwqA@mail.gmail.com, 202304101042442739296@zte.com.cn, B353182A-8BC6-4F25-BD8B-33E2919311BE@pfrc.org
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: jhaas@pfrc.org
Cc: gregimirsky@gmail.com, rtg-bfd@ietf.org
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 33B6qL0L017973
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 643503B0.000/4Pwc3N2JkZz8RV7V
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/-LxTY3OKfN4IHFYPNYUpOUKsmCI>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2023 06:52:36 -0000

Jeff,






Please see inline...









Original



From: JeffreyHaas <jhaas@pfrc.org>
To: 肖敏10093570;
Cc: Greg Mirsky <gregimirsky@gmail.com>;rtg-bfd@ietf.org <rtg-bfd@ietf.org>;
Date: 2023年04月11日 01:34
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)




Xiao Min,

On Apr 9, 2023, at 10:42 PM, <xiao.min2@zte.com.cn> <xiao.min2@zte.com.cn> wrote:







After further thought, I think copying the RFC 5881 advice is perhaps best answer.  It provides wisdom that attempts to avoid redirect messages.  However, since it's SHOULD NOT rather than MUST NOT, it doesn't make any existing implementations non-conformance; e.g. Broadcom.
[XM]>>> Got it. I'll copy the RFC 5881 advice.




Best Regards,

Xiao Min




-- Jeff







From: JeffreyHaas <jhaas@pfrc.org>







"could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" is more appropriate?

[XM-2]>>> If we would like to use normative term for SA, then that can also apply to DA, suggest s/would/MUST. As Greg pointed out, there may be implicit conflict with RFC 5881 section 4 that says "In particular, the source address SHOULD NOT be part of the subnet bound to the interface over which the BFD Echo packet is being transmitted".