Re: [mpls] WG last call: draft-ietf-mpls-inband-pm-encapsulation

xiao.min2@zte.com.cn Mon, 06 May 2024 02:30 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 D4352C14F75F; Sun, 5 May 2024 19:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.193
X-Spam-Level:
X-Spam-Status: No, score=-4.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 VXcM-KykLsis; Sun, 5 May 2024 19:30:53 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C296C14F74E; Sun, 5 May 2024 19:30:52 -0700 (PDT)
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 4VXlky423Kz6FK1m; Mon, 6 May 2024 10:30:50 +0800 (CST)
Received: from njb2app07.zte.com.cn ([10.55.22.95]) by mse-fl2.zte.com.cn with SMTP id 4462UYeB093505; Mon, 6 May 2024 10:30:34 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid201; Mon, 6 May 2024 10:30:35 +0800 (CST)
Date: Mon, 06 May 2024 10:30:35 +0800
X-Zmail-TransId: 2af9663840cb583-77d4f
X-Mailer: Zmail v1.0
Message-ID: <20240506103035651KVK8quHPRo2KfK8dgWLY-@zte.com.cn>
In-Reply-To: <CA+RyBmVzCW5gYAqi6O=LAW0pbN3hozbZY5Os+A5eGLJQkX0F0g@mail.gmail.com>
References: 2576EDD5-2D41-4635-AF38-7A63BD595154@tony.li, CA+RyBmVzCW5gYAqi6O=LAW0pbN3hozbZY5Os+A5eGLJQkX0F0g@mail.gmail.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: gregimirsky@gmail.com
Cc: tony.li@tony.li, mpls@ietf.org, mpls-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 4462UYeB093505
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 663840DA.000/4VXlky423Kz6FK1m
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/2BbCnD2qMHPC_OhMqXUzt86A6xU>
Subject: Re: [mpls] WG last call: draft-ietf-mpls-inband-pm-encapsulation
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, 06 May 2024 02:30:58 -0000

Hi Greg,
Thanks for your review and comments.
Please see inline.

Original


From: GregMirsky <gregimirsky@gmail.com>
To: Tony Li <tony.li@tony.li>;
Cc: mpls <mpls@ietf.org>;mpls-chairs <mpls-chairs@ietf.org>;
Date: 2024年05月04日 03:38
Subject: Re: [mpls] WG last call: draft-ietf-mpls-inband-pm-encapsulation

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





Hi, Tony and All,I've read the latest version of the draft. Please find my comments below:
The proposed mechanism, as stated in Abstract, applies to "MPLS live traffic". I couldn't find the definition of the term "live traffic" and appreciate it if you can clarify it for me. Does that apply to any MPLS packet or a particular class of MPLS packets in a network?
[XM]>>> That applies to a flow of MPLS packets in a network. In the Abstract of RFC 9341 it says "This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic".


I appreciate that the document mentions work on Synonymous Flow Labels. However, it is not clear to me why SFL-based application of the AMM is characterized as hop-by-hop, while the solution described in the draft - as edge-to-edge. I would appreciate it if the authors can clarify that characterization of measurement methods, particularly since the T-bit (defined in Figure 1) differentiates between edge-to-edge and hop-by-hop measurements using the proposed solution.
[XM]>>> Note that the text means the SFL method mainly aims at edge-to-edge processing, not hop-by-hop. And you're right that the method described in this document can be used for both hop-by-hop and edge-to-edge, although the main application scenario is hop-by-hop.


Furthermore, it seems like the comparison of the impact on an MPLS packet of the proposed solution and IOAM is inaccurate. As I understand it, contrary to the statement in Introduction that "the former doesn't introduce any new header whereas the latter introduces a new In-situ OAM header", both introduce (unlike SFL-based application of AMM) extra ancillary data in an MPLS packet.
[XM]>>> Can the ISD be seen as a new header? I personally don't think so. If you have any text change proposal, it's much appreciated. :-)


And, on the last paragraph in Introduction. I believe that publishing a draft on Standard track and then moving it to Historic once another solution is standardized by IETF is sub-optimal. I recognize the value of the work put in by implementers of the described in the draft solution. The deployment experience is invaluable. On the other hand, there seems to be an agreement that the MNA is the preferred mechanism to support AMM in the MPLS networks. (Note that draft-ietf-mpls-mna-usecases is being updated to include AMM as another use cases of on-path telemetry in the MPLS networks, in addition of IOAM). Hence my proposal to switch this document to Experimental track (see my question about the requested IANA allocation below).
[XM]>>> I agree with Tony and Loa on this point. To be clear, it's preferred to publish this document as a Standards Track RFC.


The list of implementations is impressive and suggests that there are several deployments. If that is the case, which value of eSPL for Flow-ID Label Indicator is used?
[XM]>>> It's my fault not requesting an early allocation. Anyway, I believe allocating a permanent code point for this feature is optimal for the existing and potential implementers and deployers.


Best Regards,
Xiao Min

In conclusion, I don't support progressing this draft on the Standard track. I would support progressing it as Experimental or Informational (perhaps that means that the IANA section is removed).


Regards,
Greg







On Thu, Apr 25, 2024 at 8:09 AM Tony Li <tony.li@tony.li> wrote:


 [WG chair hat: on]
 
 
 Hi all,
 
 This starts a 2 week working group last call on draft-ietf-mpls-inband-pm-encapsulation.
 
 This last call ends at 12:01 PM PDT, Thurs. May 9, 2024.
 
 Please send all comments to the mailing list.
 
 Regards,
 Tony
 
 
 _______________________________________________
 mpls mailing list
 mpls@ietf.org
 https://www.ietf.org/mailman/listinfo/mpls