[ippm] Re: WG Last Call: draft-ietf-ippm-stamp-ext-hdr-08 (Ends 2026-06-25)

[Greg Mirsky <[e-mail]>]

Hi Rakesh,
I misinterpreted the use of the Reflected IPv6 Extension Header Data STAMP
TLV, assuming it could carry only the SRH and not any other IPv6 Extension
Header. Please disregard that question below.

Regards,
Greg

On Mon, Jun 22, 2026 at 5:34 PM Greg Mirsky <[e-mail]> wrote:

> Hi Rakesh,
> Thank you for your thoughtful consideration of my notes. Please find my
> follow-up notes below, tagged GIM>>.
>
> Regards,
> Greg
>
> On Wed, Jun 17, 2026 at 11:11 AM Rakesh Gandhi <[e-mail]>
> wrote:
>
>> Hi Greg,
>>
>> Thank you for the detailed review of the document.
>>
>> We have addressed your comments in the working copy (rev-09) of the
>> document, as replied below <RG>...
>>
>> On Wed, Jun 10, 2026 at 8:53 PM Greg Mirsky <[e-mail]>
>> wrote:
>>
>>> Dear All,
>>> I read the latest version of draft-ietf-ippm-stamp-ext-hdr. The draft
>>> specifies the STAMP extension useful for IPv6 networks. I have several
>>> questions, please consider them as WG LC comments:
>>>
>>>    - A general observation. I feel that the document would be helpful
>>>    to an implementer if it used the normative language rather than "can",
>>>    "does", and "does not".
>>>
>>>
>> <RG> Updated where applicable.
>>
> GIM>> Thank you
>
>>
>>
>>>
>>>    - I got confused by the labeling of the IPv6 extension headers
>>>    and Reflected IPv6 Extension Header-x Data STAMP TLVs in Figure 2. Could
>>>    you clarify for me the format of an IPv6 STAMP packet constructed by a
>>>    Session-Sender and the format of the reflected STAMP test packet?
>>>
>>> <RG> It should be the same format. Updated the figure as follows to
>> remove outer/inner headers for simplicity.
>>
>>     +---------------------------------------------------------------+
>>     | IPv6 Header                                                   |
>>     +---------------------------------------------------------------+
>>     | IPv6 Extension Header-1 RFC 8200                              |
>>     +---------------------------------------------------------------+
>>     ~ ...                                                           ~
>>     +---------------------------------------------------------------+
>>     | IPv6 Extension Header-N RFC 8200                              |
>>     +---------------------------------------------------------------+
>>     | UDP Header                                                    |
>>     +---------------------------------------------------------------+
>>     | STAMP Packet RFC 8972                                         |
>>     +---------------------------------------------------------------+
>>     | Reflected IPv6 Extension Header-1 Data STAMP TLV (TBA1)       |
>>     +---------------------------------------------------------------+
>>     ~ ...                                                           ~
>>     +---------------------------------------------------------------+
>>     | Reflected IPv6 Extension Header-M Data STAMP TLV (TBA1)       |
>>     +---------------------------------------------------------------+
>>
>>       Note: Value of M <= N
>>
>>         Figure 2: Example Session-Sender and Session-Reflector Test
>>         Packet with Reflected IPv6 Extension Header Data STAMP TLVs
>>
> GIM>> Thank you for the figure, but I still wonder if the scenario of
> multiple SRHs is realistic. AFAIK, operators use a single SRH in the
> packet. That operational decision was the motivation to work on u-SIDs. Can
> you help me with a scenario in which a Session-Reflector receives a packet
> with a single IPv6 header and multiple SRHs.
> GIM>> And an additional question. What are actions of the
> Session-Reflector that received a STAMP packet with a IPv6 Extension Header
> Control Sub-TLV, but has no access to the extension headers (similar to
> Sender's TTL case described in Section 4.2 of RFC 5357
> <https://datatracker.ietf.org/doc/rfc5357/>)?
>
>>
>>
>>
>>>
>>>    - Should the first four octets of the Value field of the "Reflected
>>>    IPv6 Extension Header Data" STAMP TLV be presented as a separate field for
>>>    ease of reference and specification of the matching mechanism?
>>>
>>>
>> <RG> Updated the Figure to show the field separately.
>>
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |STAMP TLV Flags|  Type=TBA1    |         Length                |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> *    |                  Requested IPv6 Extension Header Data         |*
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |                  Reflected IPv6 Extension Header Data         |
>>     ~                                                               ~
>>     |                                                               |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>              Figure 6: Reflected IPv6 Extension Header Data TLV
>>
> GIM>> Thank you
>
>>
>>
>>>
>>>    - It seems that the following processing option can benefit from the
>>>    use of the normative language:
>>>
>>>    If necessary, Reflected Data
>>>    STAMP TLVs can be removed to avoid violating the IP MTU limit.
>>>
>>> And I find the suggestion somewhat ambiguous. Should all Reflected IPv6
>>> Extension Header Data STAMP TLVs be removed from the reflected STAMP
>>> packet, or only as many as necessary to conform to the IP MTU of the
>>> Reflector's egress interface?
>>>
>>>
>> <RG> Updated to:
>>
>>
>>
>>
>>
>> *   The Session-Sender and Session-Reflector MUST ensure that the
>>  resulting test packets do not exceed the IPv6 MTU after adding
>>  "Reflected IPv6 Extension Header Data" STAMP TLVs.  If necessary, one   or
>> more "Reflected IPv6 Extension Header Data" STAMP TLVs MUST be   removed to
>> avoid violating the IPv6 MTU limit.*
>>
> GIM>> Excellent, thanks!
>
>>
>>
>>
>>>
>>>    - MUST NOT in the following text seems too restrictive:
>>>
>>>    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 for the
>>>    IOAM DEX option-type.
>>>
>>> I think there could be other valid motivations to use the "Reflected
>>> IPv6 Extension Header Data" STAMP TLV. Perhaps softening to MAY NOT could
>>> be applied in this case.
>>>
>>>
>> <RG> Updated to MAY not.
>>
> GIM>> Thank you
>
>>
>>
>>>
>>>    - Can Reflected IPv6 Extension Header Data STAMP TLVs be used in
>>>    combination with Reflected Fixed Header Data STAMP TLV? What are the
>>>    rules that govern such a scenario?
>>>
>>>
>> <RG> Added following text:
>>
>>
>>
>>
>> * STAMP test packets can be used to reflect both IPv6 extension headers
>>  and IP headers by carrying the corresponding "Reflected IPv6   Extension
>> Header Data" and "Reflected Fixed Header Data" STAMP TLVs   as shown in
>> Figure 4.*
>>
>>
>>
>>
>>
>>
>>
>>
>> *   The "Reflected Fixed Header Data" STAMP TLV MUST be added before
>>  adding the "Reflected IPv6 Extension Header Data" STAMP TLVs to   maintain
>> the same order as the IP headers and extension headers in   the STAMP test
>> packets.  If not, the Session-Reflector MUST return   both STAMP TLVs with
>> the C flag (Conformance) set to 1 in the STAMP   TLV Flags using the
>> procedure defined in   [I-D.ietf-ippm-asymmetrical-pkts].*
>>
> GIM>> Thank you
>
>>
>>
>>>    - Can you please clarify the format of "IPv6 Extension Header
>>>    Control" sub-TLV?
>>>
>>>
>> <RG> Added following Figure:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *This document defines the "IPv6 Extension Header Control" Sub-TLV
>>  (Type TBA3) for the "Reflected Test Packet Control" STAMP TLV (Type   12)
>> introduced in [I-D.ietf-ippm-asymmetrical-pkts].  The format of   "IPv6
>> Extension Header Control" Sub-TLV is shown in Figure 8.    0 1 2 3 4 5 6 7
>> 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
>> Sub-TLV Flags |  Type = TBA3  |         Sub-TLV Length = 0    |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     Figure 8: IPv6 Extension Header Control Sub-TLV   The Sub-TLV fields
>> are defined as follows:*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *   Type: Sub-TLV Type (value TBA3).   Sub-TLV Flags: The Sub-TLV Flags
>> follow the procedure for STAMP TLV   Flags described in [RFC8972].
>>  Sub-TLV Length: A two-octet field equal to the length of the Data in
>>  octets.  It is set to 0.   When a Session-Sender test packet is received
>> with the "IPv6   Extension Header Control" Sub-TLV, the Session-Reflector
>> MUST add   matching IPv6 extension headers in the Session-Reflector STAMP
>> test   packet corresponding to the received IPv6 extension headers (except
>>  the routing extension headers specific to the Session-Sender test
>>  packet).*
>>
>>
>>
>>> Nit. A document would benefit from consistent use of STAMP terminology,
>>> e.g., Session-Sender vs Sender.
>>>
>>
>> <RG> Fixed.
>>
> GIM>> Thank you
>
>>
>> Thanks,
>> Rakesh (for authors)
>>
>>
>>
>>>
>>> Regards,
>>> Greg
>>>
>>> On Thu, Jun 4, 2026 at 6:14 AM Marcus Ihlar via Datatracker <
>>> [e-mail]> wrote:
>>>
>>>> This message starts a WG Last Call for:
>>>> draft-ietf-ippm-stamp-ext-hdr-08
>>>>
>>>> This Working Group Last Call ends on 2026-06-25
>>>>
>>>> Abstract:
>>>>    The Simple Two-Way Active Measurement Protocol (STAMP) and its
>>>>    optional extensions can be used for Edge-to-Edge (E2E) active
>>>>    measurement.  In Situ Operations, Administration, and Maintenance
>>>>    (IOAM) data fields can be used for recording and collecting Hop-by-
>>>>    Hop (HBH) and E2E operational and telemetry information.  This
>>>>    document extends STAMP to reflect IP headers as well as IPv6
>>>>    extension headers for HBH and E2E active measurements, for example,
>>>>    using IOAM data fields.
>>>>
>>>> File can be retrieved from:
>>>>
>>>> Please review and indicate your support or objection to proceed with the
>>>> publication of this document by replying to this email keeping
>>>> [e-mail]
>>>> in copy. Objections should be explained and suggestions to resolve them
>>>> are
>>>> highly appreciated.
>>>>
>>>> Authors, and WG participants in general, are reminded of the
>>>> Intellectual
>>>> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
>>>> Appropriate IPR disclosures required for full conformance with the
>>>> provisions
>>>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
>>>> Sanctions available for application to violators of IETF IPR Policy can
>>>> be
>>>> found at [3].
>>>>
>>>> Thank you.
>>>>
>>>> [1] https://datatracker.ietf.org/doc/bcp78/
>>>> [2] https://datatracker.ietf.org/doc/bcp79/
>>>> [3] https://datatracker.ietf.org/doc/rfc6701/
>>>>
>>>> The IETF datatracker status page for this Internet-Draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-ext-hdr/
>>>>
>>>> There is also an HTMLized version available at:
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-ext-hdr-08
>>>>
>>>> A diff from the previous version is available at:
>>>>
>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-stamp-ext-hdr-08
>>>>
>>>> _______________________________________________
>>>> ippm mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>>> ippm mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>