Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify

xiao.min2@zte.com.cn Mon, 05 February 2024 06:40 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D50C14F5E6; Sun, 4 Feb 2024 22:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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_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 7nD8kUcqf-Xf; Sun, 4 Feb 2024 22:40:03 -0800 (PST)
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 58BE9C14F5F8; Sun, 4 Feb 2024 22:40:01 -0800 (PST)
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 4TSxZN2gKRz8XrRH; Mon, 5 Feb 2024 14:39:56 +0800 (CST)
Received: from njy2app02.zte.com.cn ([10.40.13.116]) by mse-fl2.zte.com.cn with SMTP id 4156dreT016690; Mon, 5 Feb 2024 14:39:53 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app04[null]) by mapi (Zmail) with MAPI id mid201; Mon, 5 Feb 2024 14:39:54 +0800 (CST)
Date: Mon, 05 Feb 2024 14:39:54 +0800
X-Zmail-TransId: 2afc65c082ba534-b24af
X-Mailer: Zmail v1.0
Message-ID: <202402051439549447785@zte.com.cn>
In-Reply-To: <990F8663-4E94-4F75-A7F5-2A929EB5D6E5@gmail.com>
References: CACe62MmreLuNR5s10zhDCh+x2p1JXY1_J6dUPDtpcD9jEjsZQw@mail.gmail.com, 98DD113F-F363-4B9B-9011-CC8B594F4B90@pfrc.org, 990F8663-4E94-4F75-A7F5-2A929EB5D6E5@gmail.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: cpignata@gmail.com
Cc: jhaas@pfrc.org, mpls@ietf.org, rtg-bfd@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 4156dreT016690
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 65C082BC.000/4TSxZN2gKRz8XrRH
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/tQuLdBwvLvC_HeKETEyjhndtfWs>
Subject: Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Feb 2024 06:40:06 -0000

The suggestion from Jeff and Carlos seems reasonable to me, although I was not involved in the former mailing-list discussion.
Best Regards,
Xiao Min


Original


From: CarlosPignataro <cpignata@gmail.com>
To: Jeff Haas <jhaas@pfrc.org>;
Cc: mpls@ietf.org <mpls@ietf.org>;rtg-bfd@ietf. <rtg-bfd@ietf.org>;
Date: 2024年02月05日 11:35
Subject: Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify


Thanks Jeff for refreshing the cache on those mailing-list comments.I was part of that conversation, and frankly did not remember them — now I do. And to put that in perspective, that was almost 6 **years** ago! 

I also missed the Errata, which was good.
And there’s also a couple other held for doc update: https://www.rfc-editor.org/errata_search.php?rfc=5884 

I will start with the last bit, borrowing from your text Jeff: Carlos is also completely unaware of anyone experiencing any sort of confusion covering RFC 5884 procedures other than Greg.

And also, it’s a clarification that does not hurt.

I do not feel norao impacts 5884, but at the same time bundling all the updates on a RFC 5884-bis sounds like a most appropriate suggestion to me. I’m happy to help if needed.

And to that, I’d also bundle in the changes from RFC 7726.

Thanks,

Carlos.

On Feb 4, 2024, at 11:36 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

+bfd WG.
Some original comments to Adrian were:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/SYouXfNrVyKHErqacOuM2fICzMc/

Apparently, Greg didn't consider this worth holding his peace over.

https://www.rfc-editor.org/errata/eid5085 was filed and accepted as a clarification for RFC 5884 as part of a prior round of this discussion.


LSP Ping is getting its norao update currently in MPLS.  While it's my opinion that the current set of changes to that document don't negatively impact backward compatibility with RFC 5884, it's a normative enough change that perhaps it's worth moving forward with the small updates to RFC 5884.

In my opinion, the appropriate work is to take this to BFD for RFC 5884-bis, which would be co-reviewed with MPLS.  I believe we can get at least one of the original authors to pick up that work.

That said, the BFD chairs are completely unaware of anyone experiencing any sort of confusion covering RFC 5884 procedures other than Greg.

-- Jeff
 

On Jan 24, 2024, at 2:55 PM, Carlos Pignataro <cpignata@gmail.com> wrote:

Hi!

Review of	draft-mirsky-mpls-bfd-bootstrap-clarify
Version	05
Type		Getting Ready for WG Adoption
Team		MPLS WG Review Team
Reviewer:	Carlos Pignataro 

I have been asked to provide a ‘getting ready for WG adoption’ review of this document, on behalf of the MPLS WG review team.

There are generally two relevant questions at this stage:

1. knowing whether the document is in scope for the working group, and
2. knowing whether the document is ready to be considered for WG adoption

My perspective is that:

1. Maybe - RFC 4884, the RFC that this document would update if approved, was progressed as draft-ietf-bfd-mpls in the bfd wg. As such, I wonder if that ought to be followed here. From a practical standpoint, both WGs (mpls and bfd) would have to review this document, but it is a chair decision and guidance whether this should live in mpls or bfd (and frankly I have no strong position either way so long as both WGs are in the loop, simply pointing historic datapoints.) The document is clearly in scope on the intersection of both WGs, and historically was in bfd.

2. Yes – this document addresses clear clarifications for implementation interoperability. Granted, this protocol is deployed without these clarifications, but are (at least) theoretical gaps.

A couple of further comments, since I read the document. Overall, well written and clear, achieves its goal, and:

a. Backwards compatibility is paramount, and neither of those two words appear in the document. I recommend a section detailing implications.

b. Section 5, IPv6, seems like an after-though, since it is not mentioned in the Abstract. Further, that case and explanation is well covered in RFC 8029, and as such seems like a distraction.

c. There are various nits and an editorial pass would help with clarity. These include things like unqualified “echo reply” uses.

Thanks,

Carlos Pignataro


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls