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

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 04 April 2023 09:28 UTC

Return-Path: <wangaijun@tsinghua.org.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 48789C151532 for <rtg-bfd@ietfa.amsl.com>; Tue, 4 Apr 2023 02:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 i_4Wlk1lNz6R for <rtg-bfd@ietfa.amsl.com>; Tue, 4 Apr 2023 02:28:35 -0700 (PDT)
Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D780C15152F for <rtg-bfd@ietf.org>; Tue, 4 Apr 2023 02:28:33 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 200E1800092; Tue, 4 Apr 2023 17:28:30 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Jeffrey Haas' <jhaas@pfrc.org>, rtg-bfd@ietf.org
References: <20230321160207.GA7334@pfrc.org>
In-Reply-To: <20230321160207.GA7334@pfrc.org>
Subject: RE: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
Date: Tue, 04 Apr 2023 17:28:29 +0800
Message-ID: <00b301d966d7$d1094df0$731be9d0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AQGMYII76942ErwpBch7SJc0hUciZq+05aZw
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVlCGU4aVkpLS05LTEMZQkgZS1UTARMWGhIXJB QOD1lXWRgSC1lBWUlKQlVKT0lVTUJVTE5ZV1kWGg8SFR0UWUFZT0tIVUpKS09ISFVKS0tVS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6P006GCo*Az0LPD8PNSsLTCoU OhwaFAJVSlVKTUNLTUtLTkpLTU9MVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUhKSUs3Bg++
X-HM-Tid: 0a874b98aef6b03akuuu200e1800092
X-HM-MType: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/kBUU_Jokeerk0j3Zw-ztN-sbNgA>
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, 04 Apr 2023 09:28:39 -0000

Support its forwarding.

The implementation and deployment of unaffiliated-echo can extend the BFD
based fault detection technology in large scale, because it has no special
BFD related requirements to the other side.

>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 interoperability.

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? 

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

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: rtg-bfd-bounces@ietf.org <rtg-bfd-bounces@ietf.org> On Behalf Of
Jeffrey Haas
Sent: Wednesday, March 22, 2023 12:02 AM
To: rtg-bfd@ietf.org
Subject: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Working Group,

https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/

The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.

The draft, in my opinion, is in fairly good shape.  However, since it
functions via looping packets back to itself and trying to exercise the
normal RFC 5880 state machine behaviors to a large extent, the draft could
use very high scrutiny for several matters:

- Does the state machine behave appropriately at all stages?
- Are the descriptions of the values of the BFD fields clear in all cases?

Please supply the authors and the Working Group with your feedback.

The intended finish date for this WGLC is 7 April, 2023.  This is one week
after the end of IETF 116.

Note that Reshad is an author on the draft, so I'll be handling the full set
of review and shepherding work.

-- Jeff