Re: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt

Tianran Zhou <zhoutianran@huawei.com> Fri, 18 August 2023 01:39 UTC

Return-Path: <zhoutianran@huawei.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 76E58C14F736 for <ippm@ietfa.amsl.com>; Thu, 17 Aug 2023 18:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 v1D6svwIeXWZ for <ippm@ietfa.amsl.com>; Thu, 17 Aug 2023 18:39:07 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616F0C151533 for <ippm@ietf.org>; Thu, 17 Aug 2023 18:39:07 -0700 (PDT)
Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RRkvQ01R8z67dCv for <ippm@ietf.org>; Fri, 18 Aug 2023 09:34:57 +0800 (CST)
Received: from kwepemi100013.china.huawei.com (7.221.188.136) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Fri, 18 Aug 2023 02:39:05 +0100
Received: from kwepemi500012.china.huawei.com (7.221.188.12) by kwepemi100013.china.huawei.com (7.221.188.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Fri, 18 Aug 2023 09:39:03 +0800
Received: from kwepemi500012.china.huawei.com ([7.221.188.12]) by kwepemi500012.china.huawei.com ([7.221.188.12]) with mapi id 15.01.2507.031; Fri, 18 Aug 2023 09:39:03 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Rakesh Gandhi <rgandhi.ietf@gmail.com>
CC: IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt
Thread-Index: AQHZ0RHhBrWlISe4FUavhje/wmkx06/uu5aAgACJiUA=
Date: Fri, 18 Aug 2023 01:39:03 +0000
Message-ID: <860721ec68f843c8b0a91874565948d1@huawei.com>
References: <169220506458.60254.8718954545251270966@ietfa.amsl.com> <BL3PR11MB57313AF007583C2F25F2DAE4BF1AA@BL3PR11MB5731.namprd11.prod.outlook.com> <CAMZsk6f=tL4gGqiiZnNdO2ULM9sc1LzFUfZ0LO15uck=P+M0TQ@mail.gmail.com> <CA+RyBmXkMzc30Wb66sYJsWh+KfO91FOCfN7qBBb6QMGCOGEagw@mail.gmail.com>
In-Reply-To: <CA+RyBmXkMzc30Wb66sYJsWh+KfO91FOCfN7qBBb6QMGCOGEagw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.118]
Content-Type: multipart/alternative; boundary="_000_860721ec68f843c8b0a91874565948d1huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/22-XzVjIo81pUjxRSQ8ymmXxiFo>
Subject: Re: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Aug 2023 01:39:11 -0000

Hi Greg,

> I think that collection of on-path telemetry information is more suitable for the management plane, not for OAM.

It seems you think this is to collect on-path telemetry data.
IMHO, this is the key misunderstanding of the proposal. It’s not on-path telemetry. It’s actually active probe, just with IOAM in network layer(say IPv6) to collect node information.
As described in our draft, with only one end to end stamp session, the probe can get hop by hop measurement. Together with SR, this probe can also go through a designated path.
https://datatracker.ietf.org/doc/draft-wang-ippm-stamp-hbh-extensions/

Best,
Tianran

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, August 18, 2023 9:19 AM
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt

Hi Rakesh,
thank you for bringing this contribution to the discussion. I have several notes on the problem and solution presented in the draft. Please find those below:

  *   As I understand it, the purpose of the proposed STAMP extensions is to return collected in IOAM Preallocated or Incremental trace type modes operational and telemetry information. That seems like not a generic solution. I think that collection of on-path telemetry information is more suitable for the management plane, not for OAM. If we consider Large-Scale Measurement of Broadband Performance (LMAP) architecture, when a STAMP test packet is combined with the IOAM Header, the Session-Reflector, from the PoV of on-path telemetry measurement, may be viewed as the Measurement Agent that exports information to a Collector. And such a Collector could be co-located with the Session-Sender or be placed in several nodes. Would you agree? It seems to me like a more generic solution would be beneficial for operators.
  *   And a minor note about the applicability of IOAM in the MPLS Network Action discussion. As I understand it, the MPLS WG is still in the discussion of which mode of IOAM tracing to support with the MNA solution. It could be that only the IOAM-DEX mode will be supported with In-Stack Data (ISD) MNA. It seems like if that is the direction the MPLS WG takes, the proposed STAMP extensions would not be useful in MPLS underlays, e.g., IP/MPLS or SR-MPLS.
My notes above, as I think of it, are also relevant to the work presented at our IETF-117 session. In fact, these notes are an extended version of my comments at the mic.

Regards,
Greg

On Thu, Aug 17, 2023 at 6:50 AM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:

Hi WG,

Like to request your review comments and thoughts on the following new draft on STAMP extensions for HBH.

Thanks,
Rakesh



A new version of I-D, draft-gandhi-ippm-stamp-ioam-00.txt
has been successfully submitted by Rakesh Gandhi and posted to the
IETF repository.

Name:           draft-gandhi-ippm-stamp-ioam
Revision:       00
Title:          Simple TWAMP (STAMP) Extensions for Hop-By-Hop and Edge-To-Edge Measurements
Document date:  2023-08-16
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/archive/id/draft-gandhi-ippm-stamp-ioam-00.txt
Status:         https://datatracker.ietf.org/doc/draft-gandhi-ippm-stamp-ioam/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-stamp-ioam


Abstract:
   Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC
   8762 and its optional extensions defined in RFC 8972 can be used for
   Edge-To-Edge (E2E) active measurement.  In Situ Operations,
   Administration, and Maintenance (IOAM) data fields defined in RFC
   9197 and RFC 9326 can be used for recording and collecting Hop-By-Hop
   (HBH) and E2E operational and telemetry information.  This document
   extends STAMP to carry IOAM data fields for HBH and E2E two-way
   active measurement and telemetry.  The STAMP extensions are generic
   and allow to carry and reflect any type of IPv6 option and MPLS
   Network Action Sub-Stacks for two-way active measurement.


The IETF Secretariat
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm