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.
https://datatracker.ietf.org/doc/draft-mcb-intarea-icmpv6-loopback/
“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.

Best,
Tianran

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Rakesh Gandhi
Sent: Wednesday, November 1, 2023 4:26 AM
To: xiao.min2@zte.com.cn
Cc: ippm@ietf.org
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.

thanks,
Rakesh

On Thu, Oct 26, 2023 at 4:56 AM <xiao.min2@zte.com.cn<mailto:xiao.min2@zte.com.cn>> 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
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm