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

[Greg Mirsky <[e-mail]>]

Hi Will,
Thank you for your thoughtful proposal. Please find my notes below, tagged
GIM2>>.
And I apologize for coming back to my question about the figures that
display examples of STAMP test packets for Session-Sender and
Session-Reflector. As defined in RFC 8972, the Extra Padding TLV is used to
make STAMP packets symmetrical. If that is also the case for the Reflected
IPv6 Extension Header Data STAMP TLV and the Fixed IPv6 Header Data TLV, it
seems that the Extra Padding TLV must be reflected in figures. WDYT?

Regards,
Greg

On Mon, Jun 22, 2026 at 8:04 PM Will Hawkins <[e-mail]> wrote:

> On Mon, Jun 22, 2026 at 9:19 PM Greg Mirsky <[e-mail]> wrote:
> >
> > 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)?
>
> Hello Greg!!
>
> I always love your analysis. I don't want to speak for Rakesh, but I
> thought perhaps I could help him by answering this question (and, of
> course, it's possible that I am not giving the right answer -- we'll
> let him verify!). All that said, I think that
>
> "If for any reason, the Session-Reflector cannot add a new matching
> IPv6 extension header in the Session-Reflector test packet, for
> example, if the Session-Reflector does not support the IPv6 extension
> header, the Session-Reflector MUST return the STAMP TLV with the C
> flag (Conformance) set to 1 in the Sub-TLV Flags of the Sub-TLV using
> the procedure defined in [I-D.ietf-ippm-asymmetrical-pkts]."
>
> would govern the situation you describe. That is taken from -9
> (
> https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-ext-hdr-09.html#section-5.3-10
> ).
>
> Let me know if that text is responsive to your question.
>
> It seems like the situation you describe (where the Session-Reflector
> is running at a privilege level that will not allow it to access
> certain information about the test packet) has come up repeatedly in
> the design and specification of TLVs. Would it make sense to add it as
> one of the "for example"s in the text? Maybe something like:
>
> "If the Session-Reflector cannot add a new matching IPv6 extension
> header in the Session-Reflector test packet for any reason (e.g., if
> the Session-Reflector does not support the IPv6 extension header, or
> the Session-Reflector is running at a privilege level where headers
> are inaccessible), the Session-Reflector MUST return the STAMP TLV
> with the C flag (Conformance) set to 1 in the Sub-TLV Flags of the
> Sub-TLV using the procedure defined in
> [I-D.ietf-ippm-asymmetrical-pkts]."
>
GIM2>> As I understand it (please correct me if I misunderstand it), the
STAMP test packet transmitted by the Session-Sender includes M Reflected
Extension Header Data TLVs. If that is the case, I assume that the C flag
must be set in all Reflected Extension Header Data TLVs in the reflected
STAMP test packet. Is that correct?
GIM2>> I looked once more at the text in Section 3.3:
   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].
Based on my understanding of Figure 4, Reflected Fixed Header Data STAMP
TLV already precedes the list of Reflected IPv6 Extension Header Data STAMP
TLVs in the STAMP test packet transmitted by the Session-Sender. If that is
the case, which scenario leads to setting C flag to 1? Also, which TLVs are
included in "both STAMP TLVs"?
GIM2>> I returned to the last paragraph of Section 5.3:
   STAMP test packets MUST NOT carry more than one "IPv6 Extension
   Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
   a Session-Sender test packet contains more than one "IPv6 Extension
   Header Control" Sub-TLV, the Session-Reflector MUST return the STAMP
   TLV with the U flag (Unrecognized TLV) set to 1 in the STAMP TLV
   Flags using the procedure defined in [RFC8972].
I couldn't figure out in which TLV in the reflected STAMP test packt the U
flag must be set to 1. Could you please clarify it for me.

>
> As I said, I always enjoy reading your analysis and I hope my response
> is helpful!
>
> Will
>
>
> >>>
> >>>
> >>>
> >>>>
> >>>> 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]
>