Subject: [ippm] Re: draft-ietf-ippm-stamp-ext-hdr queries
From: "Footer Foote (Nokia)" <[email-masked]>
To: Rakesh Gandhi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IETF IPPM WG <[email-masked]>
Date: Mon, 10 Nov 2025 22:02:05 +0000
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>

Thank you Rakesh!

From: Rakesh Gandhi <[email-masked]> 
Sent: Thursday, November 6, 2025 10:52 AM
To: Footer Foote (Nokia) <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] draft-ietf-ippm-stamp-ext-hdr queries

Thank you Footer for the review comments.

We have updated the draft with the proposed text highlighted in bold below.

On Tue, Nov 4, 2025 at 5:57 PM Footer Foote (Nokia) <footer.foote=mailto:[email-masked]> wrote:
Hello authors of draft-ietf-ippm-stamp-ext-hdr.

Section 3.1, and 3.2 - I am a bit confused about which four bytes these statements are targeting.  Originally thought this was referring to the first four bytes of the STAMP TLV.  However, that can never be four bytes of zeros because it includes flags (10000000), type (non-zero IANA assigned value), and length.   

3.1 text "If the Session-Reflector receives Session-Sender test packets with non-zero values in the first 4 bytes of the "Reflected IPv6 Extension Header Data" STAMP TLV, it MUST match the values in the corresponding IPv6 extension header before copying data into the STAMP TLV."

3.2 text "If the Session-Reflector receives Session-Sender test packets with non-zero values in the first 4 bytes in the "Reflected Fixed Header Data" STAMP TLV, it MUST match the values in the corresponding IP header before copying data into the STAMP TLV."

<RG> Revised proposed text in both places:

  "If the Session-Reflector receives Session-Sender test packets with
   non-zero values in the first 4 bytes of the value field of the
   "Reflected IPv6 Extension Header Data" STAMP TLV, it MUST match the
   values in the corresponding IPv6 extension header (starting from the
   Next Header field) before copying data into the STAMP TLV. "

Section 4  - Is the text below meant to provide protection when the session-sender inadvertently includes a TLV for reflecting IOAM Data fields.  If so, would it be better to modify this to indicate, the session-sender must not include the STAMP TLV reflecting IOAM when the DEX export option-type is included.

"IOAM Direct Exporting (DEX) [RFC9326] is applicable with STAMP test packets for on-path telemetry use cases [I-D.ietf-ippm-on-path-active-measurements].  In this case, the Session-Reflector does not reflect any IOAM data fields since no data is recorded in the test packets.

<RG> Revised proposed text as follows:

   IOAM Direct Exporting (DEX) [RFC9326] is applicable with STAMP test
   packets for on-path telemetry use cases
   [I-D.ietf-ippm-on-path-active-measurements].  In this case, the
   Session-Reflector does not reflect IOAM data fields since no IOAM
   data is recorded in the STAMP test packets.  Hence, the Session-
   Sender MUST NOT include a corresponding "Reflected IPv6 Extension
   Header Data" STAMP TLV in the Session-Sender test packets in this
   case.

Thanks,
Rakesh

 
Thanks,
Footer

_______________________________________________
ippm mailing list -- mailto:[email-masked]
To unsubscribe send an email to mailto:[email-masked]