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

Rakesh Gandhi <rgandhi.ietf@gmail.com> Fri, 24 May 2024 02:12 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 E9100C14F73E for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 19:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qLBE014q_aHN for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 19:12:13 -0700 (PDT)
Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (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 E98BFC15106E for <ippm@ietf.org>; Thu, 23 May 2024 19:12:12 -0700 (PDT)
Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-62a08271bf8so4471957b3.1 for <ippm@ietf.org>; Thu, 23 May 2024 19:12:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716516732; x=1717121532; 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=6Z0hufhc97dfSm0mEoaiz1W9U/EHJPtaglFUtmNjSx8=; b=Rku3vNV+nEs9XmrStwhmtu0ETdgNonfzkXOI0RwyjHhXXdos6I5bElQZseC9wFLj6N WB7EyEJPzGVjY/2U4zvjGKyXiohOGKeSEYIp5dXUqyk+qLoD/oPvvouLZVVSGF00tG1G TlTXfT8yIaLXmcRZa2ytiwHEIeGDt6H66+qvvDJJ2DFQDG3dXnQpYWtY1WnK2KtlU+6P 6z3WzgGIJN0h6W/Z1QMFyJ0weL1Y5iHephQaG5HUynbsJpYAvcQaBz0M6CxIIxlQoQj0 plomwMNsYsiCLyoaLpqH2qtN1ir28gpyzsvRXVSlE3rdyPB1wo4Y5mIYkDtTvOWdF0Tn HUow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716516732; x=1717121532; 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=6Z0hufhc97dfSm0mEoaiz1W9U/EHJPtaglFUtmNjSx8=; b=uGOxEAXfUa0IR3xTJg2J9S2HleID+v75KGjtV0DDuechA00a2PpWIa5ATEQJ5RzHle wBIbPAUWgH6Vr3FeXbrN9Wd2ljMLifE4zLhtnml8bFwOt90Qv/uE4Htae8Vx80MmHnvj vEivqNqJS/VP0lr7NS3N9ypuuhTr1Bq9S2N79+RmI7dQczEdIwCfvEBVazBzxKVDDSZY uw3+1V7Swlqnw6HU+bypPkKw8ZovLaTu2qUy0tt6kcZd2nXXaW9JBsVw2IgdhSozGRt7 KC/x4KDTXcTYF+nQ21byC/hkb2EOmcn+vx6PKevV0YZNBfFO4e/FuXn/bRx290Anv9yd gI0A==
X-Forwarded-Encrypted: i=1; AJvYcCXuLatwCJzSVZmVLgg+k/jgnplV6WnxxpxGl900uMOBcsXOr75hL5CbfL+qezuLHxcjsp+MkfMwCaXPzaJ9
X-Gm-Message-State: AOJu0Yyr46/3mS4k06JYU35Ew6+xvYZ0zuK86jRIDB4IEmLMxisni6YQ q4mzEnvzMQJkZrtQadc1yazZ4EmYwoYEd6aBT6ADOxQw/gUgmVtqqnwEEAqg21Fhtdkj3MHfApc 5HceIpi1zbM3TGALp4NsG6dqC0Q==
X-Google-Smtp-Source: AGHT+IFteV4W004s5LK5prhk6MqD7eGW7oCQyxmMzp6lldffBNpo0vNdZrydAJIJ8Kn4qStaN3+zYtDbC2cQQ5t/2QI=
X-Received: by 2002:a0d:dd02:0:b0:61a:c2fc:1128 with SMTP id 00721157ae682-62a08db1a3dmr9830647b3.28.1716516731770; Thu, 23 May 2024 19:12:11 -0700 (PDT)
MIME-Version: 1.0
References: <9a9f2ac29a6549d2a651af0c8617bac1@huawei.com> <20240516111822240TOJrJih-nWtESC5R8_Gfh@zte.com.cn> <CAMZsk6f92rPTV+4TQY475b-HwvwQ3t6ug1xQcxxbOR76OasWJw@mail.gmail.com> <CA+RyBmWEPVibxR3ixARHBA3KzHcyz5xqXAz4N2pghydTDC=RYw@mail.gmail.com>
In-Reply-To: <CA+RyBmWEPVibxR3ixARHBA3KzHcyz5xqXAz4N2pghydTDC=RYw@mail.gmail.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Thu, 23 May 2024 22:12:01 -0400
Message-ID: <CAMZsk6fHPh9iOLPGPEpUTf-2xwg3At8fh8ZSrDLE_216-zzikw@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000c5fff061929b256"
Message-ID-Hash: W6S5OOJNB3QCHER4NC6IUIZDTJKSMSNY
X-Message-ID-Hash: W6S5OOJNB3QCHER4NC6IUIZDTJKSMSNY
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>

Hi Greg,

Ok, sure. Will not rush to make changes for them.

I will let others comment, but I think it is related to transmitting STAMP
test packets on multiple paths between sender and reflector using different
flow-label values.

Thanks,
Rakesh




On Thu, May 23, 2024 at 10:06 PM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Rakesh,
> thank you for your question. I still don't see how these additions benefit
> the performance measurement in IPv6 networks. Perhaps we need more
> discussion about the value such enhancement will have. WDYT?
>
> Regards,
> Greg
>
> On Thu, May 23, 2024 at 4:55 PM Rakesh Gandhi <rgandhi.ietf@gmail.com>
> wrote:
>
>> 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)?
>>
>> 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
>>>
>> _______________________________________________
>> ippm mailing list -- ippm@ietf.org
>> To unsubscribe send an email to ippm-leave@ietf.org
>>
>