[mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr

xiao.min2@zte.com.cn Wed, 15 May 2024 03:07 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 26E89C1654F3 for <mpls@ietfa.amsl.com>; Tue, 14 May 2024 20:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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_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 EDngj9azMgyq for <mpls@ietfa.amsl.com>; Tue, 14 May 2024 20:07:25 -0700 (PDT)
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 AFF24C151997 for <mpls@ietf.org>; Tue, 14 May 2024 20:07:11 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (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 4VfJ6g6XVzz8XrS7 for <mpls@ietf.org>; Wed, 15 May 2024 11:07:07 +0800 (CST)
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 mxct.zte.com.cn (FangMail) with ESMTPS id 4VfJ6565w1z4x6DP; Wed, 15 May 2024 11:06:37 +0800 (CST)
Received: from njy2app02.zte.com.cn ([10.40.13.116]) by mse-fl2.zte.com.cn with SMTP id 44F36HR8026540; Wed, 15 May 2024 11:06:18 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njb2app05[null]) by mapi (Zmail) with MAPI id mid201; Wed, 15 May 2024 11:06:19 +0800 (CST)
Date: Wed, 15 May 2024 11:06:19 +0800
X-Zmail-TransId: 2afd664426ab5c4-5e980
X-Mailer: Zmail v1.0
Message-ID: <20240515110619125tGOkzbojM1lCtmBXMLDsR@zte.com.cn>
In-Reply-To: <CAMZsk6eQO47mgpscD_hHFW-6m0HAbrABV56CEKH8KTo1_ysnoQ@mail.gmail.com>
References: 0B3D008A-6DCF-414A-9BD4-C6F1F192B171@tony.li,20240507162307532l71Ge0kniVo4vAQ8VHhF7@zte.com.cn,CAMZsk6eQO47mgpscD_hHFW-6m0HAbrABV56CEKH8KTo1_ysnoQ@mail.gmail.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: rgandhi.ietf@gmail.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 44F36HR8026540
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 664426DB.000/4VfJ6g6XVzz8XrS7
Message-ID-Hash: IBTQRU367UR2W2MASPZSRX746KUBK7GS
X-Message-ID-Hash: IBTQRU367UR2W2MASPZSRX746KUBK7GS
X-MailFrom: xiao.min2@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: mpls@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/FQCYExP-_Bbnc3NvZ2bfDotwwgE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Hi Rakesh,
Thank you for the reply.
Please see inline.

Original


From: RakeshGandhi <rgandhi.ietf@gmail.com>
To: 肖敏10093570;
Cc: tony.li@tony.li <tony.li@tony.li>;mpls@ietf.org <mpls@ietf.org>;
Date: 2024年05月15日 06:07
Subject: Re: [mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr



Hi Xiao Min,

Thank you for the review comments. 


Please see replies inline with <RG>...





On Tue, May 7, 2024 at 4:24 AM <xiao.min2@zte.com.cn> wrote:


Hi all,

I've read the latest version of the draft, which introduces two new TLVs - Return Path TLV and Block Number TLV.
With regard to the Return Path TLV, its usage is clear to me, RFC 9503 defines a similar STAMP TLV extension.
However, to the Block Number TLV, its usage is not clear to me. The first paragraph of section 7.2 seems to combine this TLV with Alternate-Marking Method defined in RFC 9341, though I can't figure out how they're combined.



<RG> RFC 9341, Section 3.1, first paragraph defines packet loss measurement using block number (copied text below). 
 "The basic idea is to virtually split traffic flows into consecutive blocks: each block represents a measurable entity unambiguously recognizable by all network devices along the path. By counting the number of packets in each block and comparing the values measured by different network devices along the path, it is possible to measure if packet loss occurred in any single block between any two points."
<RG> This draft defines Block number TLV to carry the above block number associated with the traffic counters.
 "The packet loss measurement using Alternate-Marking Method defined in [RFC9341] MAY use Block Number (BN) for data correlation for the data traffic flow under measurement. To be able to correlate the transmit and receive traffic counters of the matching Block Number, the Block Number of the traffic counters is carried in the LM query and response messages."
[XM]>>> As far as I know, the existing implementations of Alternate-Marking Method rely on the external NMS/controller, which is responsible for the correlation of data (e.g., counter of the same block of packets) collected from each node along the path. As specified in section 4.3 of RFC 9341, a protocol-based distributed solution is also possible, and I believe that's the case for this document. Then, I still have several comments as below.
* This draft is not clear on how the LM query sending node decides the Block Number. In one existing implementation I know, the node calculates the Block Number as the modulo of the node's absolute time since PTP epoch and the marking period. Also note that in the data planes of Alternate-Marking Method, whether RFC 9343 or draft-ietf-mpls-inband-pm-encapsulation, there is no any kind of Block Number field.
* This draft is not clear on the benefit of using Alternate-Marking Method vs Direct Loss Measurement Method of RFC 6374. Please note that for two-way loss measurement the Alternate-Marking Method requires time synchronization between the two endpoints, while Direct LM Method defined in RFC 6374 doesn't require that. 
* This draft may need to mention that it provides a protocol-based distributed solution of Alternate-Marking Method, not a conflict with a centralized solution using the NMS/controller.
* This draft introduces the Block Number TLV that's not included in RFC 9503, then it seems we need to write a new draft defining a similar STAMP TLV extension. An alternative way is to take out the Block Number TLV from this draft and think more about it, and after that the proposal may be brought up in IPPM first.

<RG> How about updating the text as follows?
 "The packet loss measurement using Alternate-Marking Method defined in [RFC9341] is based on dividing the traffic flow into consecutive blocks and
 counting the number of packets in each block. A block number is used to 
 identify the transmit and receive counters in each block and compare for measuring loss.
 The LM query and response messages carry the transmit and receive counters along with the 
 block number when using the AMM defined in [RFC9341] for loss measurement."

[XM]>>> Thank you for the proposed text change. Please see my further comments above.

Cheers,
Xiao Min

Thanks,
Rakesh





Best Regards,
Xiao Min

Original

From: TonyLi <tony.li@tony.li>
To: mpls <mpls@ietf.org>;
Date: 2024年04月30日 23:52
Subject: [mpls] WG last call: draft-ietf-mpls-rfc6374-sr

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


[WG chair hat: on]

Hi all,

This starts a 2 week working group last call on draft-ietf-mpls-rfc6374-sr.

This last call ends at 12:01PM PDT, Tues. May 14th.

Please send all comments to the mailing list.

Thanks,
Tony








_______________________________________________
 mpls mailing list -- mpls@ietf.org
 To unsubscribe send an email to mpls-leave@ietf.org