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

Rakesh Gandhi <rgandhi.ietf@gmail.com> Thu, 23 May 2024 23:55 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 982D0C14F601 for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 16:55:33 -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=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 T-KTqnwztL4C for <ippm@ietfa.amsl.com>; Thu, 23 May 2024 16:55:29 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 B3E3FC14F6A8 for <ippm@ietf.org>; Thu, 23 May 2024 16:55:29 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-6aa282ece86so15815686d6.1 for <ippm@ietf.org>; Thu, 23 May 2024 16:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716508528; x=1717113328; 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=PZXsIu7I02TKmm8eFw5rTrRzQNoNegAfupJVYRIEpK4=; b=Gp2DruRKWL3yfjHAbzJ16s+ui3BVxjD+XrN8P2Z6OJe2VdyfKJ5g0Z2doF9ZQdUdlU xZ3Yx6cx1rZkBnIV5SNFhqXIl8OgDO4N07j+GzxftZuYO7y37BOR9RkWAY1rFJMAZ8V0 XubCwa3BlDfIOHKAXxCHSCYNRYBLofU/w3wWJl1gY9PEtaFU0nwDBZZw9YtyGlOpqG/9 ZUd/ECGPwnrRPnQYXhbi/FjwPGVVQ4sxglbU+wx7hDG9h9Du8t7GmRuSrGOelnb4BphC 5vRk2jGQnZlW6Ge6XxZDAB7nVyX3Krx2AiOyuD/zpx933oXB/LOK53PW8f+MdkoQtHwI 6+7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716508528; x=1717113328; 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=PZXsIu7I02TKmm8eFw5rTrRzQNoNegAfupJVYRIEpK4=; b=ssPYSPz3my7+gVJTcxEZtKHVH1dW2Aoxen8CfVwz/pEFxw4AiMsu48AU6lUTEAk00e VMpAq50caH/3vUNJX5Ymmr8LVd8Qggc6/H1nJ3cl6KA9WoEiThrAT9Nae32IS8edYCe7 hQ81B4chj26SZ5pfpHIEQsU5fkJBGdUrv7AKghwgNydGPeS2y/sX4+ACncsqJF9naXFI vHv+lCFL3H/YEBV4ZcqegrDmp9X+wnOcL49UErmkxXQwl3HfXybUbaf2Jxrj9HjnHmuK sRxL6IbRPxjTRq55FA69SPeVRBlH+xXfcMt9oBLviFiwmhAqBEQ+4jXPyWs8GRpRmSZo ORyA==
X-Forwarded-Encrypted: i=1; AJvYcCVkGLQDkRvf2ohcQDGDcU5rae8pDzlmyqB1xuas8ktlMrdvSaeYiORHacmrPp8HELPQTXHZGTwxIqNiJN7L
X-Gm-Message-State: AOJu0YyIFmAUoQeLtgDAPxE2waeE5ME1wqqRJp6Z8OtOpIsJ9KAE7QUf 0buFqA3avp1x5lrRS7lKBTnvrTEYeNxCzpysqE0dqEY7f7JYe3izOgkg0Xev4iXtu2iUAJwmkvD C4SCIagGpTIlFO30SXPzdwWBl8Q==
X-Google-Smtp-Source: AGHT+IHwMNFVbUK1+Rf/VurZM24FeOPehQl3NjATDxAlPqCIEjvnlo7WEwFm2wMCABt2Z6Keg1lKH3JA0UDJJu4ZYPk=
X-Received: by 2002:a05:6214:5913:b0:6a9:d2bb:a540 with SMTP id 6a1803df08f44-6abcd0ce235mr6485696d6.54.1716508527964; Thu, 23 May 2024 16:55:27 -0700 (PDT)
MIME-Version: 1.0
References: <9a9f2ac29a6549d2a651af0c8617bac1@huawei.com> <20240516111822240TOJrJih-nWtESC5R8_Gfh@zte.com.cn>
In-Reply-To: <20240516111822240TOJrJih-nWtESC5R8_Gfh@zte.com.cn>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Thu, 23 May 2024 19:55:17 -0400
Message-ID: <CAMZsk6f92rPTV+4TQY475b-HwvwQ3t6ug1xQcxxbOR76OasWJw@mail.gmail.com>
To: xiao.min2@zte.com.cn
Content-Type: multipart/alternative; boundary="000000000000103bbb061927c930"
Message-ID-Hash: GHGBR2SLBNDRSOOZ3HQ3OANRJNZZWPCV
X-Message-ID-Hash: GHGBR2SLBNDRSOOZ3HQ3OANRJNZZWPCV
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>

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
>