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

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Fri, 24 May 2024 09:25 UTC

Return-Path: <giuseppe.fioccola@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 1FEBCC1840C2 for <ippm@ietfa.amsl.com>; Fri, 24 May 2024 02:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.893
X-Spam-Level:
X-Spam-Status: No, score=-6.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=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 ymQBv0e5WpDS for <ippm@ietfa.amsl.com>; Fri, 24 May 2024 02:25:32 -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 E9720C14CF1E for <ippm@ietf.org>; Fri, 24 May 2024 02:25:31 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Vm00X4pbkz6K5jg; Fri, 24 May 2024 17:21:32 +0800 (CST)
Received: from frapeml100005.china.huawei.com (unknown [7.182.85.132]) by mail.maildlp.com (Postfix) with ESMTPS id 2963D140C72; Fri, 24 May 2024 17:25:30 +0800 (CST)
Received: from frapeml500006.china.huawei.com (7.182.85.219) by frapeml100005.china.huawei.com (7.182.85.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 24 May 2024 11:25:29 +0200
Received: from frapeml500006.china.huawei.com ([7.182.85.219]) by frapeml500006.china.huawei.com ([7.182.85.219]) with mapi id 15.01.2507.039; Fri, 24 May 2024 11:25:29 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Thread-Topic: [ippm] Re: IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr
Thread-Index: AdqdYZ4gvKkX37OVRHK72sWowQnuyAFUB48AAqpYcQAAExbo0A==
Date: Fri, 24 May 2024 09:25:29 +0000
Message-ID: <01ae083ff4744cbd8dba822a47004950@huawei.com>
References: <DB9PR07MB8983B9EDCD816FA4F586E2EEE21F2@DB9PR07MB8983.eurprd07.prod.outlook.com> <2537c58565904b1c84380a6cef536c68@huawei.com> <CAMZsk6c1LT=ZyJZ_DmfkSSbXD-x0D=6+FS+Yb0OpYLBd7Qcn2Q@mail.gmail.com>
In-Reply-To: <CAMZsk6c1LT=ZyJZ_DmfkSSbXD-x0D=6+FS+Yb0OpYLBd7Qcn2Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.154.148]
Content-Type: multipart/alternative; boundary="_000_01ae083ff4744cbd8dba822a47004950huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: BZHQIUKOXTZWQGV4CEYTEVZTM2Q2IASA
X-Message-ID-Hash: BZHQIUKOXTZWQGV4CEYTEVZTM2Q2IASA
X-MailFrom: giuseppe.fioccola@huawei.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: "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>
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 reply.
Regarding the Abstract, if we extend the scope, the document will also describe how to implement hop-by-hop active measurements with STAMP in general.
Regarding Section 5 of draft-gandhi-ippm-stamp-ioam, I agree that it needs to be further explained. Indeed, there are some cases where the Reflected STAMP TLV does not help so much. For example, for AltMark, it is used IPFIX/YANG Push to report AltMark telemetry information from each intermediate node. These considerations are included in Section 4 of draft-wang-ippm-stamp-hbh-extensions.
If we integrate draft-gandhi-ippm-stamp-ext-hdr, it would become more general and cover all the variations of the STAMP HBH measurements.

Regards,

Giuseppe

From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Sent: Friday, May 24, 2024 1:50 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: Marcus Ihlar <marcus.ihlar@ericsson.com>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: Re: [ippm] Re: IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr

Hi Giuseppe,

Thank you for your support and suggestions.

As mentioned in the Abstract -

This document extends

STAMP to reflect any IPv6 options and MPLS Network Action Sub-Stacks

for hop-by-hop and edge-to-edge active measurements, including IOAM

data fields.

We will further describe use-cases that were in the previous version in Section 5.
https://www.ietf.org/archive/id/draft-gandhi-ippm-stamp-ioam-00.txt


5.  Generic Applicability



   The procedure and extensions defined in this document for STAMP for

   IPv6 data plane are generic and can be used by Session-Sender and

   Session-Reflector test packets to reflect any IPv6 option (not just

   limited to the IPv6 options with IOAM data fields) for HBH and E2E

   two-way active measurement as shown in Figure 6.  For example, using

   the Alternate Marking Method (AMM) IPv6 destination option defined in

   RFC 9343, Performance and Diagnostic Metrics (PDM) IPv6 option

   defined in RFC 8250, Maximum Path MTU IPv6 option defined in RFC

   9268, and any other IPv6 option that may be defined in future.



Thank you for your willingness to work together on this to cover various use-cases.

Regards,

Rakesh (for authors)

On Fri, May 10, 2024 at 11:34 AM Giuseppe Fioccola <giuseppe.fioccola=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Dear All,
I support the adoption of this draft, but I think that the scope of the document should become more general and cover all the variations of the STAMP HBH measurements leveraging the IPv6 options/MNA sub-stacks.
We recently updated draft-wang-ippm-stamp-hbh-extensions to add a section on how to perform HBH active measurements by using STAMP in combination with the IPv6 HBH options (IOAM, AltMark). In addition to the Reflected STAMP TLV, it is described the use of IPFIX/YANG Push to report telemetry information from each intermediate node to a collector.
It would make sense to describe all the possibilities in a single document.
As also discussed offline with Rakesh, I’m fully available to cooperate and integrate draft-gandhi-ippm-stamp-ext-hdr.

Regards,

Giuseppe


From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> On Behalf Of Marcus Ihlar
Sent: Friday, May 3, 2024 4:03 PM
To: IETF IPPM WG (ippm@ietf.org<mailto:ippm@ietf.org>) <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: [ippm] IPPM adoption call for draft-gandhi-ippm-stamp-ext-hdr

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<mailto:ippm@ietf.org>
To unsubscribe send an email to ippm-leave@ietf.org<mailto:ippm-leave@ietf.org>