IETF Logo Mail Archive

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

Jeffrey Haas <jhaas@pfrc.org> Mon, 10 April 2023 17:34 UTC

Return-Path: <jhaas@pfrc.org>
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 E45CBC151536 for <rtg-bfd@ietfa.amsl.com>; Mon, 10 Apr 2023 10:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 yPYvueaB7KpC for <rtg-bfd@ietfa.amsl.com>; Mon, 10 Apr 2023 10:34:20 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A4DBCC14CF1C for <rtg-bfd@ietf.org>; Mon, 10 Apr 2023 10:34:15 -0700 (PDT)
Received: from smtpclient.apple (104-10-90-238.lightspeed.livnmi.sbcglobal.net [104.10.90.238]) by slice.pfrc.org (Postfix) with ESMTPSA id 5E4DE1E037; Mon, 10 Apr 2023 13:34:14 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_786ACB16-1A30-4606-B134-0473E82EB2AC"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <202304101042442739296@zte.com.cn>
Date: Mon, 10 Apr 2023 13:34:13 -0400
Cc: Greg Mirsky <gregimirsky@gmail.com>, rtg-bfd@ietf.org
Message-Id: <B353182A-8BC6-4F25-BD8B-33E2919311BE@pfrc.org>
References: <CA+RyBmXtST1EZcba_RM90NLf5hYAiKL2+XjSZwO2r-d_XNjwqA@mail.gmail.com, 202304071515047394062@zte.com.cn, B97890D2-3EA7-40D0-87A0-9DD114B9B418@pfrc.org> <202304101042442739296@zte.com.cn>
To: Xiao Min <xiao.min2@zte.com.cn>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/nd4L3slx_tEw-wsaF0Rp7W7av3U>
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: Mon, 10 Apr 2023 17:34:23 -0000

Xiao Min,


> On Apr 9, 2023, at 10:42 PM, <xiao.min2@zte.com.cn> <xiao.min2@zte.com.cn> wrote:
> 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".
> 
> 

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.

-- Jeff

v2.31.3 | Report a Bug | By Email | System Status