Re: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt
Tianran Zhou <zhoutianran@huawei.com> Fri, 18 August 2023 03:03 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 802E9C15107A for <ippm@ietfa.amsl.com>; Thu, 17 Aug 2023 20:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 kSRUJ4QAaqr7 for <ippm@ietfa.amsl.com>; Thu, 17 Aug 2023 20:03:50 -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 D37C1C15106B for <ippm@ietf.org>; Thu, 17 Aug 2023 20:03:49 -0700 (PDT)
Received: from lhrpeml500003.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RRmsM3KJsz6H8xV for <ippm@ietf.org>; Fri, 18 Aug 2023 11:03:19 +0800 (CST)
Received: from kwepemi500013.china.huawei.com (7.221.188.120) by lhrpeml500003.china.huawei.com (7.191.162.67) 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 04:03:46 +0100
Received: from kwepemi500012.china.huawei.com (7.221.188.12) by kwepemi500013.china.huawei.com (7.221.188.120) 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 11:03:44 +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 11:03:44 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Rakesh Gandhi <rgandhi.ietf@gmail.com>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt
Thread-Index: AQHZ0RHhBrWlISe4FUavhje/wmkx06/uu5aAgACJiUD//4jyAIAAifuA
Date: Fri, 18 Aug 2023 03:03:44 +0000
Message-ID: <4c8b4655fcb74497a7e9eb760b5b11bf@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> <860721ec68f843c8b0a91874565948d1@huawei.com> <CA+RyBmVrJwr9r4zi+L6AkNrbYoJt+OaoV+_c-fubU7gisudnog@mail.gmail.com>
In-Reply-To: <CA+RyBmVrJwr9r4zi+L6AkNrbYoJt+OaoV+_c-fubU7gisudnog@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_4c8b4655fcb74497a7e9eb760b5b11bfhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/VQhsxc3PDIS9ExpaFncMZz6PVRM>
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 03:03:54 -0000
Hi Greg, For one way measurement, I do not see any protocol extension requirement. Bidirectional measurement is the reason we choose stamp+ioam solution. And I see this is different from normal ioam framework. Because on-path telemetry is mainly for one way use. Of cause, we can combine two one-way into bidirection, just like owamp and twamp. But we see it’s really difficult to use. For example, we need the configuration from controller, a new element. The result is also on the controller. But with stamp, we can get the measurement from the head node. And, the controller need to correlate the two ways with session id and the sequence number. Best, Tianran From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Friday, August 18, 2023 10:25 AM To: Tianran Zhou <zhoutianran@huawei.com> Cc: Rakesh Gandhi <rgandhi.ietf@gmail.com>; IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt Hi Tianran, I think that I have a general understanding of STAMP and IOAM. I agree that combining STAMP and IOAM can be operationally useful. But I cannot find any need for any extensions to STAMP in order to achieve those advantages. IOAM works on a network layer, e.g., IPv6, MPLS, or even Service Function Chaining with Network Service Header. But the application of IOAM to a data flow or a flow of test packets does not require any special add-ons on the part of the protocol that sources those packets. For example, if IOAM is added to the encapsulation of ICMPv6 or LSP Ping, would that, in your opinion, require an extension to ICMPv6 or LSP Ping? I don't see the path of extending this and that protocol as a good approach. In my opinion, exporting on-path IOAM information is a task for a function that is part of the management plane. And if an operator sees a benefit of combining IOAM with a bidirectional protocol, e.g., BFD or STAMP, then that is a part of the configuration process that can be approached using an extension of a YANG model. Regards, Greg On Thu, Aug 17, 2023 at 6:39 PM Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> wrote: 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<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<mailto:rgandhi.ietf@gmail.com>> Cc: IETF IPPM WG <ippm@ietf.org<mailto: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