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

Greg Mirsky <gregimirsky@gmail.com> Fri, 24 May 2024 02:06 UTC

Return-Path: <gregimirsky@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 9D531C15106E for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 19:06:17 -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=unavailable 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 pv2vuEtTTHDx for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 19:06:13 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 B0F96C14F704 for <ippm@ietf.org>; Thu, 23 May 2024 19:06:13 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-df4e503983fso2558330276.2 for <ippm@ietf.org>; Thu, 23 May 2024 19:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716516373; x=1717121173; 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=ydZoWx/zzMSUhCHJrxokX6Hritc/I8UM7GsSXvu1TGo=; b=MKZ2HXAbWyL9LfDfhUU1PG30GZ2OM6fvQjAkUY9CPz58S1jQg+Z2dYM5DGFX/auT3g K/IZrOAUu03Y4ffaUly1nBDPHkD1cz1Rtrpd+IoQKpGYJeddsAzLFt3tLh2pJjrB5FtX +QjtOAQRPNgVgP8ykKwGE6aR2d9wke1Im6rKLitBfh9j7ZmUphwgRnwaTDJ9FevfjNIN zn2Px8JUd3K5bs+19hQHWd8YApjbF4MyVFj5ODAetpHIK1kmrClzuTKKcNQn1real/W+ 0Y9YufNYa/dfQWUWtVw48kTLi96npZVxwLY3lbJAG3rXG1hZhKHyMQGGQdKIX9/Kg/CZ YnTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716516373; x=1717121173; 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=ydZoWx/zzMSUhCHJrxokX6Hritc/I8UM7GsSXvu1TGo=; b=sxZpuYi0fbP5fcHPQwQXsl6dA1EYZD1Fp7L1l+1uDaGYZU6fCtE+2fJq+aI5lAQAui oQv++NTRiQD4Y/qMJkSqR/1yECzV8gWE0u2EgYnAJHpx0N3VjDjoyEdD3OfkMyNW0nqe gjf1NX9NTQqAsWnwYsMif/t/HTgUetbC5A0MmtOLYRoc6A1FFiXA+uSuGA33TRDHUUYQ C+LcBSHVrIBWtcaGtrCT5r38B6BLdcDn+tIEcCCxtfdb5RwR4WY47TpBsIJ3B+zAZ2BX ieEElAR6RyYQwhCscwKFV+5ht8sN/ksenGHUzKX9J6hZGODMNOXX4g+mxq48FQTb5w/3 a8Qg==
X-Forwarded-Encrypted: i=1; AJvYcCV2iwCDhs+gGWsI2jKkOu4ripbsX7BV0b3CN6Lc/MaJs13Bm51RUYi4DFkzpdaBjfWchvHdJ+SVPlh7Cr4J
X-Gm-Message-State: AOJu0Yz0U0y6qiEbtLhpzIAVP8kZp4THYuflTmhM6ze1r15W8aniwgoP OLD9ClZ9goqiUV1pAKQ7EaQ3snC5ZgTIo7QuPAoFuIqGfXCDwEMKsOItTOpO+0jx6DSGyHeN+X4 HBBrrFGHPVPG9jwUC4BSpyXksF+4Zhw==
X-Google-Smtp-Source: AGHT+IGAagF2RFKB7VMpS9GmWqweGdsriEr0uRbHVDZc7dQPCR6CcZBJwuOlkWvcYI8WF8RJ8JFF5H7V6q7ClMXujJs=
X-Received: by 2002:a25:ce87:0:b0:df4:b3ca:d318 with SMTP id 3f1490d57ef6-df7721558aemr950225276.10.1716516372677; Thu, 23 May 2024 19:06:12 -0700 (PDT)
MIME-Version: 1.0
References: <9a9f2ac29a6549d2a651af0c8617bac1@huawei.com> <20240516111822240TOJrJih-nWtESC5R8_Gfh@zte.com.cn> <CAMZsk6f92rPTV+4TQY475b-HwvwQ3t6ug1xQcxxbOR76OasWJw@mail.gmail.com>
In-Reply-To: <CAMZsk6f92rPTV+4TQY475b-HwvwQ3t6ug1xQcxxbOR76OasWJw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 23 May 2024 19:06:01 -0700
Message-ID: <CA+RyBmWEPVibxR3ixARHBA3KzHcyz5xqXAz4N2pghydTDC=RYw@mail.gmail.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a5110e0619299c59"
Message-ID-Hash: TF7MBNFMLHPM37NWYL4VL7Q6TOFALPWN
X-Message-ID-Hash: TF7MBNFMLHPM37NWYL4VL7Q6TOFALPWN
X-MailFrom: gregimirsky@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 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
>