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

Aijun Wang <> Fri, 07 April 2023 00:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93270C152A3D for <>; Thu, 6 Apr 2023 17:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 VLqmDVMSVQCu for <>; Thu, 6 Apr 2023 17:53:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B2B25C1522CB for <>; Thu, 6 Apr 2023 17:53:31 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown []) by (Hmail) with ESMTPA id 5718F800015; Fri, 7 Apr 2023 08:53:29 +0800 (CST)
From: Aijun Wang <>
To: 'Jeffrey Haas' <>
References: <> <00b301d966d7$d1094df0$731be9d0$> <>
In-Reply-To: <>
Subject: RE: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Date: Fri, 07 Apr 2023 08:53:27 +0800
Message-ID: <004a01d968eb$5da8d810$18fa8830$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGMYII76942ErwpBch7SJc0hUciZgG8RUu0Aak8ENyvnebucA==
Content-Language: zh-cn
X-HM-Tid: 0a87593440d0b03akuuu5718f800015
X-HM-MType: 1
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: Fri, 07 Apr 2023 00:53:38 -0000

Hi, Jeffrey:

Please see the inline replies [WAJ]

-----Original Message-----
From: Jeffrey Haas <> 
Sent: Thursday, April 6, 2023 10:22 PM
To: Aijun Wang <>
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April,


> On Apr 4, 2023, at 5:28 AM, Aijun Wang <> wrote:
> From the description of this document, the state machine of local 
> device is conformed that described in RFC5880, the main standard parts 
> of this document are the contents of related fields within the BFD 
> ECHO Packet. If so, I suggested to point out these fields and its 
> value in more explicit manner, to facilitate the implementation

Perversely, the fact that this mechanism has an implementation "talking to
itself" means the interoperability considerations are not a primary issue.

Providing additional detail to help illustrate the mechanism would be
in-scope and perhaps helpful.  Did you have any explicit recommendations for
the text?
[WAJ] How about to refer the style of

> Should the section 2(update to RFC5880) be moved afterwards the 
> section 3(Unaffiliated BFD Echo Procedures)?
> And I am worrying that is it easy for the reader/implementer to keep 
> up with the updated contents in current manner, because they must 
> compare the two documents simultaneously?

I agree that this would be a helpful change.  It would move the procedure
ahead of the changes that impact the BFD normative text.

> Is there any other better style to point out the update to RFC5880?

Unfortunately, this is a common problem for internet-drafts that impact
protocol state machinery.  We have either the option of trying to issue a
"patch" on the draft, as we're doing here, or do a -bis of the base RFC to
more cleanly integrate the changes.
[WAJ] How about to give the RFC also the version attribute like the draft?
That is to say, for such "patch" or verbose text update, once the proposed
draft is published, the updated contents will be incorporated into the base
RFC automatically(no need to the overall long procedures for the bis
document), but give its one new version number?  The bit RFC document can be
labelled with the source that the updates are coming from.
Maybe this should be discussed in more general scope?
The final bis RFC document will be more easily referred and readable.

Since I think this feature is best documented as an optional extension at
this time, the "patch" format is our best option.

-- Jeff