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
- Re: [ippm] New Version Notification for draft-gan… Rakesh Gandhi
- Re: [ippm] New Version Notification for draft-gan… Tianran Zhou
- Re: [ippm] New Version Notification for draft-gan… Greg Mirsky
- Re: [ippm] New Version Notification for draft-gan… Tianran Zhou
- Re: [ippm] New Version Notification for draft-gan… Greg Mirsky
- Re: [ippm] New Version Notification for draft-gan… Tianran Zhou
- Re: [ippm] New Version Notification for draft-gan… Rakesh Gandhi
- Re: [ippm] New Version Notification for draft-gan… Greg Mirsky
- Re: [ippm] New Version Notification for draft-gan… Rakesh Gandhi