[ippm] Re: IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr

xiao.min2@zte.com.cn Fri, 24 May 2024 01:39 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9A34FC151079 for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 18:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.875
X-Spam-Status: No, score=-6.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lbRU_2KKv3J6 for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 18:39:44 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4344C14F6A9 for <ippm@ietf.org>; Thu, 23 May 2024 18:39:35 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown []) (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 4VlnlS29vDz5R9kC for <ippm@ietf.org>; Fri, 24 May 2024 09:39:32 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown []) (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 4Vlnkr3LTwz501bQ; Fri, 24 May 2024 09:39:00 +0800 (CST)
Received: from njy2app03.zte.com.cn ([]) by mse-fl1.zte.com.cn with SMTP id 44O1cqjI068140; Fri, 24 May 2024 09:38:52 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app08[null]) by mapi (Zmail) with MAPI id mid201; Fri, 24 May 2024 09:38:53 +0800 (CST)
Date: Fri, 24 May 2024 09:38:53 +0800
X-Zmail-TransId: 2b00664fefadffffffffcb8-8e162
X-Mailer: Zmail v1.0
Message-ID: <20240524093853630HbHZlgowIBQHYWnDuK3Lg@zte.com.cn>
In-Reply-To: <CAMZsk6f92rPTV+4TQY475b-HwvwQ3t6ug1xQcxxbOR76OasWJw@mail.gmail.com>
References: 9a9f2ac29a6549d2a651af0c8617bac1@huawei.com,20240516111822240TOJrJih-nWtESC5R8_Gfh@zte.com.cn,CAMZsk6f92rPTV+4TQY475b-HwvwQ3t6ug1xQcxxbOR76OasWJw@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-fl1.zte.com.cn 44O1cqjI068140
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 664FEFD4.002/4VlnlS29vDz5R9kC
X-MailFrom: xiao.min2@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: marcus.ihlar=40ericsson.com@dmarc.ietf.org, ippm@ietf.org, zhukeyi@huawei.com
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [ippm] Re: IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Owner: <mailto:ippm-owner@ietf.org>
List-Post: <mailto:ippm@ietf.org>
List-Subscribe: <mailto:ippm-join@ietf.org>
List-Unsubscribe: <mailto:ippm-leave@ietf.org>

Hi Rakesh,

Please see inline.


From: RakeshGandhi <rgandhi.ietf@gmail.com>
To: 肖敏10093570;
Cc: zhoutianran@huawei.com <zhoutianran@huawei.com>;marcus.ihlar=40ericsson.com@dmarc.ietf.org <marcus.ihlar=40ericsson.com@dmarc.ietf.org>;ippm@ietf.org <ippm@ietf.org>;zhukeyi@huawei.com <zhukeyi@huawei.com>;
Date: 2024年05月24日 07:55
Subject: Re: [ippm] Re: IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr

Thank you Xiao Min, Tianran and Greg for your inputs.

Is the conclusion to only reflect Flow-Label / Entropy Label and Hop-Limit/TTL and not the entire IP header with routing header (SRH)?
[XM]>>> That's what I agreed. To be clear, as specified in RFC 8200, routing header is a kind of IPv6 extension header, not part of IPv6 header and not touched in our discussion.

Best Regards,
Xiao Min

P.S. DSCP is already covered in RFC 8972.


On Wed, May 15, 2024 at 11:18 PM <xiao.min2@zte.com.cn> wrote:

Hi Tianran,
Thank you for the thoughts and comments.
Please see inline.


From: TianranZhou <zhoutianran@huawei.com>
To: 肖敏10093570;gregimirsky@gmail.com <gregimirsky@gmail.com>;
Cc: marcus.ihlar=40ericsson.com@dmarc.ietf.org <marcus.ihlar=40ericsson.com@dmarc.ietf.org>;ippm@ietf.org <ippm@ietf.org>;Zhukeyi(Kaiyin,Datacom Standard&Patent) <zhukeyi@huawei.com>;
Date: 2024年05月16日 09:56
Subject: RE: [ippm] Re: IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr

Hi Min,
I find the first use case is interesting. But, I am afraid the relationship between the flow-label and the path is not feasible. 
Hash will include port and ip address and so on. That means with a flow label cannot identify a path. How to further use the flow-label and path mapping?
[XM]>>> You're right the Flow Label can't be the only value served as a hash key, and typically some or all of IP 5-tuple are used jointly. As said in the Abstract of RFC 9197, "IOAM collects operational and telemetry information in the packet while the packet traverses a path between two points in the network". Similar to that, the reflected Flow Lable is a collected information that seems useful to the operator. One simple usage I can think of is to check whether the Flow Lable affects the ECMP selection of the transit nodes and whether its value is changed en route. Furthermore, the mapping between the Flow Label and the path can help the sender to do better load distribution by setting appropriate Flow Labels to the IPv6 data packets.

The second use case seems not necessary. Because the reflector can compare and know whether there is ioam unaware node or not. Hence the end node can send this result to the controller or the sender.
[XM]>>> This STAMP TLV extension I proposed provides a means for the reflector to send this result to the sender. I believe that's a simple and natural way without inventing any new protocol or protocol extension.

Then as rfc 8972 defines some IP header information. Maybe a TLV for IP header here is redundant. I.e. ,maybe a tlv for a specific field.
[XM]>>> That's a design choice. I can live with either way.

Xiao Min 

发件人: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> 
 发送时间: 2024年5月16日 9:14
 收件人: gregimirsky@gmail.com
 抄送: marcus.ihlar=40ericsson.com@dmarc.ietf.org; ippm@ietf.org
 主题: [ippm] Re: IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr
Hi Greg,
Thank you for the continued discussion on the list.

Please see inline.


From: GregMirsky <gregimirsky@gmail.com>

To: Rakesh Gandhi <rgandhi.ietf@gmail.com>;

Cc: 肖敏10093570;marcus.ihlar=40ericsson.com@dmarc.ietf.org <marcus.ihlar=40ericsson.com@dmarc.ietf.org>;ippm@ietf.org <ippm@ietf.org>;

Date: 2024年05月16日 00:12

Subject: Re: [ippm] Re: IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr

Hi Xiao Min and Rakesh,
I thought about the proposal to to add STAMP extension to reflect IPv6 headers to the Session-Sender. It is an interesting idea but I am not sure how it relates to the performance measurement OAM.
[XM]>>> Thank you for your interest on this idea. Let me elaborate it a bit more as below. 
RFC 8972 defines Class of Service TLV that reflects DSCP and ECN values from the received STAMP test packet. Also, Location TLV reflects, although not as a single construct, MAC, Destination and Source IPvX addresses, and destination and source UDP port numbers.
[XM]>>> Yes, you're right RFC 8972 has already provided the capability for STAMP to reflect some fields of IPv6 header, including DSCP, ECN, and DA/SA. I'm a co-author of that RFC and thank you for leading that work.
With that in mind, what could be added to help with the performance measurement?
[XM]>>> Except for what has been specified in RFC 8972, within the IPv6 header, at least two more fields seem useful to me.
The first one is Flow Label, actually I've made this suggestion earlier at IETF 118. Quoted minutes as below.

13:45 10m draft-gandhi-ippm-stamp-ioam R. Gandhi
Rakesh presents. STAMP for IOAM - to implement a method for active
 measurements with IOAM (see IOAM active flag).
 Additional ideas (not yet in the draft, discussion on the list is
 welcome): Asymetric operation (measure one way only), sampled operation.
Xiao Min: Mulitiple STAMP TLVs may not be best choice for this scenario.
 Relation between flow label and forwarding path should be monitored.
 Rakesh welcomes the idea and proposes joint discussion with (Tianran?)
 4 people in the room have read the draft. Interest in adoption: 5 in
 favour, 2 against.
 Footer Foote: Too early to adopt.
 Rakesh: will work on received comments and update the draft.
The second one is Hop Limit, which can tell the STAMP Session-Sender whether there are any IOAM-Unaware nodes along the path.
Xiao Min




On Tue, May 14, 2024 at 5:17 AM Rakesh Gandhi <rgandhi.ietf@gmail.com> wrote:

Hi Xiao Min,


Thank you for your suggestion. We plan to include this in the next update.






On Fri, May 10, 2024 at 9:57 PM <xiao.min2@zte.com.cn> wrote:

Hi all,
At IETF 119, I suggested to add a new STAMP TLV to this draft, at that time a positive response received from Rakesh. Quoted minutes as below.
Rakesh Gandhi (Cisco) presenting.
Xiao Min (ZTE Corporation): Would you consider adding a new STAMP TLV to
 reflect the IPv6 header?
Rakesh Gandhi: That seems like a good idea.
So, what's the follow-up to that discussion?
Best Regards,
Xiao Min


From: MarcusIhlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>

To: IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>;

Date: 2024年05月03日 22:03

Subject: [ippm] IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr

 ippm mailing list

Hello IPPM,
This email starts an adoption call for draft-gandhi-ippm-stamp-ext-hdr. This document has a normative dependency on draft-ietf-ippm-asymmetrical-pkts that was recently adopted by the IPPM working group. 
You can find the draft here:
Please review the draft and respond to this email to indicate if you think IPPM should adopt this document as a working group item.
This call will last for 3 weeks. Please reply by Friday, May 24.
Marcus & Tommy


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

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


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