Re: [ippm] Comments on draft-gandhi-ippm-stamp-ioam Sat, 04 November 2023 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4E68C151545 for <>; Sat, 4 Nov 2023 08:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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, UNPARSEABLE_RELAY=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jsb7fdUAdnda for <>; Sat, 4 Nov 2023 08:34:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80D09C151983 for <>; Sat, 4 Nov 2023 08:34:26 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4SN1qw0sw2z8XrRB for <>; Sat, 4 Nov 2023 23:34:20 +0800 (CST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4SN1qL09yhz4xKRy; Sat, 4 Nov 2023 23:33:50 +0800 (CST)
Received: from ([]) by with SMTP id 3A4FXijX054075; Sat, 4 Nov 2023 23:33:44 +0800 (+08) (envelope-from
Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid201; Sat, 4 Nov 2023 23:33:48 +0800 (CST)
Date: Sat, 04 Nov 2023 23:33:48 +0800
X-Zmail-TransId: 2af96546645cffffffffca4-e18e4
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 3A4FXijX054075
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6546647C.000/4SN1qw0sw2z8XrRB
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: Sat, 04 Nov 2023 15:34:32 -0000

Hi Tianran,

Thanks for sharing your thoughts.
Please see inline.


From: TianranZhou <>
To: Rakesh Gandhi <>;肖敏10093570;
Cc: <>;
Date: 2023年11月02日 20:20
Subject: RE: [ippm] Comments on draft-gandhi-ippm-stamp-ioam

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.
[XM]>>> Thank you for the pointer. As I understand it, the STAMP TLV defined in draft-gandhi-ippm-stamp-ioam covers both IPv6 and MPLS, ICMPv6 could cover IPv6 and LSP Ping could cover MPLS, so it seems STAMP has more coverage. 
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.
[XM]>>> IMHO future proof design is just what's needed, isn't it? 
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.
[XM]>>> IMHO the most clean way is to use one STAMP TLV instead of multiple STAMP TLVs, isn't it?
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.
[XM]>>> The idea is to release the STAMP Session-Reflector, not the STAMP Session-Sender. The STAMP Session-Sender is the one who needs to employ the parsing results, so its work load would not be reduced, whoever gains, who pays.
Xiao Min

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