Re: [ippm] Comments on draft-gandhi-ippm-stamp-ioam

Tianran Zhou <> Thu, 02 November 2023 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62C65C1519A9 for <>; Thu, 2 Nov 2023 05:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mInfYhsywyfS for <>; Thu, 2 Nov 2023 05:20:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7496C1519A0 for <>; Thu, 2 Nov 2023 05:20:37 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4SLjYd2GWgz6H6hg for <>; Thu, 2 Nov 2023 20:17:25 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 2 Nov 2023 12:20:34 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 2 Nov 2023 20:20:32 +0800
Received: from ([]) by ([]) with mapi id 15.01.2507.031; Thu, 2 Nov 2023 20:20:32 +0800
From: Tianran Zhou <>
To: Rakesh Gandhi <>, "" <>
CC: "" <>
Thread-Topic: [ippm] Comments on draft-gandhi-ippm-stamp-ioam
Thread-Index: AQHaB+qM/XGGmKOnakejNiSNMx+abLBj2wqAgAMWzmA=
Date: Thu, 02 Nov 2023 12:20:32 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_2e04d115177642f4960152083002438ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [ippm] Comments on draft-gandhi-ippm-stamp-ioam
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Nov 2023 12:20:42 -0000

In general, it is correct to reduce the work load on the reflector side.
Just like my another proposal, which use ICMP to loopback the IPv6 level information without parsing.
“The payload of the ICMPv6 Loopback Reply message, which resides after the Sequence Number field, MUST include as much of the invoking IPv6 Loopback Request packet without exceeding the IPv6 MTU. ”
It just copies all the IP layer data without any parsing.

In this STAMP case, I think the parsing is not so hard. Because it will only parse to the option level, no further deeper to understand the IOAM.
And I can see the advantages of separate TLVs.
1. Other than iOAM tracing, I do not see other option need this at present. So I see it’s only future proof. Even if there is another option, I am not sure if two options will work at the same time.
2. There may be some other options which is not intended to be taken in the STAMP TLV, for example router alert, IOAM DEX. So it could be more clean.
3. If we anyway need to parse the options and pick the intended options, it will not reduce work load when putting them all in one STAMP TLV.


From: ippm [] On Behalf Of Rakesh Gandhi
Sent: Wednesday, November 1, 2023 4:26 AM
Subject: Re: [ippm] Comments on draft-gandhi-ippm-stamp-ioam

Thanks Xiao Min for the suggestion.

I think it's a good idea. Let's see if WG has further feedback on this.


On Thu, Oct 26, 2023 at 4:56 AM <<>> wrote:

Hi Rakesh,

I've read draft-gandhi-ippm-stamp-ioam-00 and found it useful.

I have a thought to simplify the STAMP TLV defined in this draft.

In both Section 4.1 and 4.2 it says "STAMP test packets may carry multiple TLVs of this type".

Figure 6 demonstrates that multiple IPv6 Option Data STAMP TLVs are carried in one STAMP test packet if multiple IPv6 EH Options exist.

Why not combine the multiple IPv6 Option Data STAMP TLVs into one IPv6 Data STAMP TLV?

Similarly, why not combine the multiple MNA Sub-Stack Data STAMP TLVs into one MPLS Data STAMP TLV?

In this way, the STAMP Session-Reflector doesn't need to parse the received IPv6 Extension Header or MPLS MNA Sub-Stack, it just mirrors part of the received STAMP test packet and leaves all the parsing work to the STAMP Session-Sender , what do you think?

Best Regards,

Xiao Min
ippm mailing list<>