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

Rakesh Gandhi <rgandhi.ietf@gmail.com> Fri, 24 May 2024 02:01 UTC

Return-Path: <rgandhi.ietf@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84917C14F6A9 for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 19:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 EqGUSraduEDE for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 19:01:21 -0700 (PDT)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4095BC14F6EA for <ippm@ietf.org>; Thu, 23 May 2024 19:01:21 -0700 (PDT)
Received: by mail-qv1-xf32.google.com with SMTP id 6a1803df08f44-6ab9d406101so2492426d6.3 for <ippm@ietf.org>; Thu, 23 May 2024 19:01:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716516080; x=1717120880; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XPiK9+LZXcAbxCaBTdB0/0scxpJrn8cKpStaVhn4HBo=; b=OxKRvif2LEV5l6QktAcOC0iD2cSnSxrEuVryOg2eVL9PB9wshRwDnBzeSBNK2Nz9nY sHK7gvdpDChjmYfgJE1hGokxyyPZjq/vBAaKaHFyUcNYT61NAkvrIN0ZL+IrYvjQ1/hc 9S4HPQnqExs9CfVxQOXmgdCvyM+V/ilrvkhuQ1s4L3sHWwabooVyF0yNZbppZDi0CYZi 1AG6/Kbx1VRVSA1siQnzvSymY8cLzELd2dngE+KLhndd/EaOw7PM94njM81QETAX5HlG 5xXJE3TdJMDYhZg8SdmPeP5YAjfxmMv6ZuxRdqhEeUDoEhRoLOZDgK9X1N3DjAT5QEe+ sJiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716516080; x=1717120880; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XPiK9+LZXcAbxCaBTdB0/0scxpJrn8cKpStaVhn4HBo=; b=hAy5QBUIH8+eBHEcGAHw/HC1mtpLGz9gpvmOozR8JT7qmxNSXNGLTwbw7xRrnECe08 a/5DXPiAE+CyCoreegJ0Gswo2aH/AFqjVKQkf0XzHtmAvKq51UbprilINHpRTO6ke+5I 65anYp6PgwlAG+afKRdpw6vDRQXQa9uZ3gq7aIiwwbz7b5pGnfAg6b4AIai0TEDU5Ivp 1Moz1LRUP0e+U04BA8p9CJbQ+2EXQ67en3O4TqH9lmLQaFa5HsMJc6VfxPr5nqEAi2Iu S1goH+D15poFBMdIvEndn8tGymGvPWRhaUi+NN0TpFYOPnkweABjU+TAvz6lrVbrv4Cc 0mfw==
X-Forwarded-Encrypted: i=1; AJvYcCXrs/JMjkJkI6ctNWQSqYd10iM+Y8KreuFhtNoUOY0+HkRZonU2PMFtizHQZNXF47p6czCrxzhNdR8b21C4
X-Gm-Message-State: AOJu0YwfmqBgascgfQ8nGEfvoGuFMYQ3+fx4vKFyeFzFCD6tan8Ig4xc er1uxmIQVEt/zuacQaQ6xtKF3uP2VYpi2qBA5SOqm0zHar+kfdGyciuWuhLaAHFTSt88gyjy9Et 91Y+nzhrYIV/NVYXWa1bhka1DaA==
X-Google-Smtp-Source: AGHT+IFz/zsakVXKa2F3uIce/D5W+nTEqlMHSNRgVyXSnXacnTFm5k45ZKW/VPCXk984rbYum8H2/496Pc1/C+rAFL8=
X-Received: by 2002:a05:6214:2b9a:b0:6a3:5d84:e0a8 with SMTP id 6a1803df08f44-6abbbc5e9femr9359756d6.9.1716516079775; Thu, 23 May 2024 19:01:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZsk6f92rPTV+4TQY475b-HwvwQ3t6ug1xQcxxbOR76OasWJw@mail.gmail.com> <20240524093853630HbHZlgowIBQHYWnDuK3Lg@zte.com.cn>
In-Reply-To: <20240524093853630HbHZlgowIBQHYWnDuK3Lg@zte.com.cn>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Thu, 23 May 2024 22:01:09 -0400
Message-ID: <CAMZsk6eyDM7ob-ktG6GDQT6vzNtKgCHAMwNBQ36EZw_NS7J9mw@mail.gmail.com>
To: xiao.min2@zte.com.cn
Content-Type: multipart/alternative; boundary="0000000000002fb79b0619298b55"
Message-ID-Hash: 7ABDO2OV7CBCVEWIWML7YNIHNNVKS6MY
X-Message-ID-Hash: 7ABDO2OV7CBCVEWIWML7YNIHNNVKS6MY
X-MailFrom: rgandhi.ietf@gmail.com
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>

Thanks Xiao Min for confirming.

Acking to make the suggested changes.

Regards,
Rakesh



On Thu, May 23, 2024 at 9:39 PM <xiao.min2@zte.com.cn> wrote:

> Hi Rakesh,
>
>
> Please see inline.
> Original
> *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.
>
> thanks,
> Rakesh
>
>
>
> 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.
>> Original
>> *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.
>>
>>
>> Cheers,
>>
>> Xiao Min
>>
>>
>> Tianran
>>
>>
>>
>> *发件人:* 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.
>>
>> Original
>>
>> *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 <https://datatracker.ietf.org/doc/rfc8972/> 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
>> <https://datatracker.ietf.org/doc/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.
>>
>>
>>
>> Cheers,
>>
>> Xiao Min
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> 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.
>>
>>
>>
>> Regards,
>>
>> Rakesh
>>
>>
>>
>>
>>
>> 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.
>>
>> =========================================================
>>
>> draft-gandhi-ippm-stamp-ext-hdr
>> <https://datatracker.ietf.org/doc/draft-gandhi-ippm-stamp-ext-hdr/>
>>
>> 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
>>
>> Original
>>
>> *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
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>> 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:
>>
>> https://datatracker.ietf.org/doc/draft-gandhi-ippm-stamp-ext-hdr/
>>
>> https://www.ietf.org/archive/id/draft-gandhi-ippm-stamp-ext-hdr-00.html
>>
>>
>>
>> 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*.
>>
>>
>>
>> Best,
>>
>> 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
>>
>
>