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

[Rakesh Gandhi <[e-mail]>]

Thank you Greg for the thorough review of the document.

Regards,
Rakesh


On Thu, Jul 9, 2026 at 5:47 PM Greg Mirsky <[e-mail]> wrote:

> Hi Rakesh,
> Thank you for your patience and a great discussion. I appreciate
> your diligence in addressing my comments.
>
> Best regards,
> Greg
>
> On Sun, Jul 5, 2026 at 6:58 AM Rakesh Gandhi <[e-mail]>
> wrote:
>
>> Hi Greg,
>>
>> Thank you for your follow-up comments. One reply below with <RG4>
>>
>> <snip>
>>
>>
>>
>>
>>
>>
>>
>>
>> *<RG2> STAMP test packets MUST NOT carry more than one "IPv6 Extension
>>  Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
>>  the "Reflected Test Packet Control" TLV in the Session-Sender test
>>  packet contains more than one "IPv6 Extension Header Control" Sub-   TLV,
>> the Session-Reflector MUST return the "Reflected Test Packet   Control" TLV
>> with the U flag (Unrecognized TLV) set to 1 in the Sub-   TLV Flags of all
>> "IPv6 Extension Header Control" Sub-TLVs, using the   procedure defined in
>> [RFC8972].*
>>
>>
>> GIM3>> Could it be that the C flag is more suitable in this case? As I
>> understand it, the Session-Reflector recognizes the IPv6 Extension Header
>> Control sub-TLV, but finds that the Reflected Test Packet Control TLV
>> includes more than one IPv6 Extension Header Control sub-TLV. In other
>> word, construction of the Reflected Test Packet Control TLV is
>> non-conformant to this specification. WDYT?
>>
>> <RG4> Ok, updated to use the C flag for this case in the latest revision.
>>
>> Thanks,
>> Rakesh (for authors)
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 26, 2026 at 11:43 AM Rakesh Gandhi <[e-mail]>
>> wrote:
>>
>>> Hi Greg,
>>>
>>> Thank you for reviewing the suggested updates.
>>>
>>> Please see the replies inline with <RG3>...
>>>
>>>
>>> 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?
>>>
>>>
>>> <RG2> Both Session-Sender and Session-Reflector test packets carry the
>>> same number of Reflected IPv6 Extension Header Data STAMP and the Fixed
>>> IPv6 Header Data TLVs, making them symmetric in size, no?
>>>
>>>
>>> GIM3>> Thank you for confirming that to me. My question was about the
>>> use of the Extra Padding TLV in the STAMP test packet constructed by the
>>> Session-Sender. It seems that attribution of Figure 1 to both
>>> Session-Sender and Session-Reflector hides from a reader that the STAMP
>>> test packet transmitted by the Session-Sender MUST have Extra Padding TLV
>>> to make up for the difference in  length between base and reflected packets.
>>>
>>> <RG3> I fail to see how extra padding would be applicable to this draft
>>> as Sender adds new fixed length STAMP TLVs defined in this draft and
>>> Reflector sends them back with data. So the reflected STAMP packet size
>>> does not change.
>>>
>>> GIM3>> Also, should the document clarify whether the Session-Reflector
>>> must use information other than the Type field value, in IPv6 Extension
>>> Header Data or Fixed Header Data TLVs for sanity verification? If nothing
>>> of the kind, should the document state that all Value fields MUST be zeroed
>>> on transmission by the Session-Sender and ignored by the Session-Reflector
>>> on receipt?
>>>
>>> <RG3> This is covered in the “Requested IPv6 Extension Header Data”
>>> field in the draft where additional fields are compared.
>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>> GIM3>> Could you please clarify to which STAMP TLV and Sub-TLV this
>>> applies?
>>>
>>> <RG3> Revised the text as follows to add these TLV and Sub-TLV.
>>>
>>>   * If the Session-Reflector cannot add a new matching IPv6 extension*
>>> *   header in the Session-Reflector test packet, the Session-Reflector*
>>> *   MUST return the "Reflected Test Packet Control" TLV with the C flag*
>>> *   (Conformance) set to 1 in the Sub-TLV Flags of the "IPv6 Extension*
>>> *   Header Control" Sub-TLV using the procedure defined in*
>>> *   [I-D.ietf-ippm-asymmetrical-pkts].  This can occur, for example,
>>> when*
>>> *   the Session-Reflector does not support the IPv6 extension header, or*
>>> *   when the Session-Reflector cannot access the received IPv6 extension*
>>> *   headers, etc.*
>>>
>>> ---------------------------------------------------------------------------------
>>>
>>>
>>>
>>> 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?
>>>
>>>
>>>
>>> <RG2> Revised the text as follows.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *   When the Session-Reflector does not use the received "Reflected
>>> IPv6   Extension Header Data" TLV for reflecting the IPv6 extension
>>> header,   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].  This can occur, for example, if   there is a
>>> mismatch in the length between the received IPv6 extension   headers and
>>> the "Reflected IPv6 Extension Header Data" TLVs, or when   the
>>> Session-Reflector cannot access the received IPv6 extension   headers, etc.*
>>>
>>>
>>> GIM3>> I got confused when reading the previous text and the one above.
>>> It seems to me that the case when the Session-Reflector doesn't have access
>>> to IPv6 extension headers, the Session-Reflector MUST set both C and U
>>> flags in the TLV flags field of the IPv6 Extension Header Data TLV in the
>>> reflected STAMP test packet. Am I missing something here?
>>>
>>> <RG3> Revised the text as follows to indicate the TLV type to avoid
>>> confusion.
>>>
>>>    *When the Session-Reflector could not use the received "Reflected
>>> IPv6*
>>> *   Extension Header Data" TLV for reflecting any IPv6 extension header,*
>>> *   the Session-Reflector MUST return the "Reflected IPv6 Extension*
>>> *   Header Data" TLV with the U flag (Unrecognized TLV) set to 1 in the*
>>> *   STAMP TLV Flags using the procedure defined in [RFC8972].  This can*
>>> *   occur, for example, if there is a mismatch in the length between the*
>>> *   received IPv6 extension headers and the "Reflected IPv6 Extension*
>>> *   Header Data" TLVs, or when the Session-Reflector cannot access the*
>>> *   received IPv6 extension headers, or when the IPv6 extension header*
>>> *   corresponding to the "Requested IPv6 Extension Header Data" field
>>> was*
>>> *   not found, etc.*
>>>
>>>
>>> ---------------------------------------------------------------------------------
>>> <snip>
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> <RG2> Revised the test as follows:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *   STAMP test packets MUST NOT carry more than one "IPv6 Extension
>>>  Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
>>>  the "Reflected Test Packet Control" TLV in the Session-Sender test
>>>  packet contains more than one "IPv6 Extension Header Control" Sub-   TLV,
>>> the Session-Reflector MUST return the "Reflected Test Packet   Control" TLV
>>> with the U flag (Unrecognized TLV) set to 1 in the Sub-   TLV Flags of all
>>> "IPv6 Extension Header Control" Sub-TLVs, using the   procedure defined in
>>> [RFC8972].*
>>>
>>>
>>> GIM3>> Could it be that the C flag is more suitable in this case? As I
>>> understand it, the Session-Reflector recognizes the IPv6 Extension Header
>>> Control sub-TLV, but finds that the Reflected Test Packet Control TLV
>>> includes more than one IPv6 Extension Header Control sub-TLV. In other
>>> word, construction of the Reflected Test Packet Control TLV is
>>> non-conformant to this specification. WDYT?
>>>
>>> <RG3> C flag is already used for the following case in this Sub-TLV.
>>> <RG3> U flag in Sub-TLV is used to distinguish the below case with the
>>> above case case for the multiple Sub-TLVs.
>>> <RG3> draft-ietf-ippm-asymmetrical-pkts unfortunately does not cover the
>>> multiple sub-TLVs case for "Reflected Test Packet Control” TLV although it
>>> defines several sub-TLVs.
>>> <RG3> I think, the draft-ietf-ippm-asymmetrical-pkts could also
>>> benefit from above U flag behaviour, since the C flag was already used for
>>> a different purpose in draft-ietf-ippm-asymmetrical-pkts.
>>>
>>> <RG3> Related existing text in the draft.
>>>
>>>    *If the Session-Reflector cannot add a new matching IPv6 extension*
>>> *   header in the Session-Reflector test packet, the Session-Reflector*
>>> *   MUST return the "Reflected Test Packet Control" TLV with the **C
>>> flag*
>>> *   (Conformance) set to 1 i**n the Sub-TLV Flags of the "IPv6
>>> Extension*
>>> *   Header Control" Sub-TLV using the procedure defined in*
>>> *   [I-D.ietf-ippm-asymmetrical-pkts].  This can occur, for example,
>>> when*
>>> *   the Session-Reflector does not support the IPv6 extension header, or*
>>> *   when the Session-Reflector cannot access the received IPv6 extension*
>>> *   headers, etc.*
>>>
>>>
>>> Thanks,
>>> Rakesh (for authors)
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 25, 2026 at 6:53 PM Greg Mirsky <[e-mail]>
>>> wrote:
>>>
>>>> Hi Rakesh,
>>>> Thank you for your careful consideration of my notes and thoughtful
>>>> updates. Please find my additional notes below, tagged GIM3>>.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Wed, Jun 24, 2026 at 6:33 AM Rakesh Gandhi <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> Thank you for the further review comments and the discussions.
>>>>>
>>>>> Please see replies inline with <RG2>...
>>>>>
>>>>> On Tue, Jun 23, 2026 at 6:09 PM Greg Mirsky <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>> <RG2> Both Session-Sender and Session-Reflector test packets carry the
>>>>> same number of Reflected IPv6 Extension Header Data STAMP and the Fixed
>>>>> IPv6 Header Data TLVs, making them symmetric in size, no?
>>>>>
>>>> GIM3>> Thank you for confirming that to me. My question was about the
>>>> use of the Extra Padding TLV in the STAMP test packet constructed by the
>>>> Session-Sender. It seems that attribution of Figure 1 to both
>>>> Session-Sender and Session-Reflector hides from a reader that the STAMP
>>>> test packet transmitted by the Session-Sender MUST have Extra Padding TLV
>>>> to make up for the difference in  length between base and reflected packets.
>>>> GIM3>> Also, should the document clarify whether the Session-Reflector
>>>> must use information other than the Type field value, in IPv6 Extension
>>>> Header Data or Fixed Header Data TLVs for sanity verification? If nothing
>>>> of the kind, should the document state that all Value fields MUST be zeroed
>>>> on transmission by the Session-Sender and ignored by the Session-Reflector
>>>> on receipt?
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 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]."
>>>>>>
>>>>>>
>>>>>
>>>>> <RG2> Revised the text as follows.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *  If the Session-Reflector cannot add a new matching IPv6 extension
>>>>>  header in the Session-Reflector test packet, 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].  This can occur, for example, when
>>>>>  the Session-Reflector does not support the IPv6 extension header, or
>>>>>  when the Session-Reflector cannot access the received IPv6 extension
>>>>>  headers, etc.*
>>>>>
>>>>> GIM3>> Could you please clarify to which STAMP TLV and Sub-TLV this
>>>> applies?
>>>>
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>>
>>>>> <RG2> Revised the text as follows.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *   When the Session-Reflector does not use the received "Reflected
>>>>> IPv6   Extension Header Data" TLV for reflecting the IPv6 extension
>>>>> header,   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].  This can occur, for example, if   there is a
>>>>> mismatch in the length between the received IPv6 extension   headers and
>>>>> the "Reflected IPv6 Extension Header Data" TLVs, or when   the
>>>>> Session-Reflector cannot access the received IPv6 extension   headers, etc.*
>>>>>
>>>> GIM3>> I got confused when reading the previous text and the one above.
>>>> It seems to me that the case when the Session-Reflector doesn't have access
>>>> to IPv6 extension headers, the Session-Reflector MUST set both C and U
>>>> flags in the TLV flags field of the IPv6 Extension Header Data TLV in the
>>>> reflected STAMP test packet. Am I missing something here?
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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"?
>>>>>>
>>>>>
>>>>>
>>>>> <RG2> Revised the test as follows:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *  The "Reflected Fixed Header Data" TLVs MUST be added before adding
>>>>>  the "Reflected IPv6 Extension Header Data" TLVs to maintain the same
>>>>>  order as the IP headers and IPv6 extension headers in the Session-
>>>>>  Sender test packets.  If the "Reflected Fixed Header Data" TLVs and   the
>>>>> "Reflected IPv6 Extension Header Data" TLVs are not received in   this
>>>>> order, the Session-Reflector MUST return these 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].*
>>>>>
>>>> GIM3>> Thank you.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>> <RG2> Revised the test as follows:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *   STAMP test packets MUST NOT carry more than one "IPv6 Extension
>>>>>  Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
>>>>>  the "Reflected Test Packet Control" TLV in the Session-Sender test
>>>>>  packet contains more than one "IPv6 Extension Header Control" Sub-   TLV,
>>>>> the Session-Reflector MUST return the "Reflected Test Packet   Control" TLV
>>>>> with the U flag (Unrecognized TLV) set to 1 in the Sub-   TLV Flags of all
>>>>> "IPv6 Extension Header Control" Sub-TLVs, using the   procedure defined in
>>>>> [RFC8972].*
>>>>>
>>>> GIM3>> Could it be that the C flag is more suitable in this case? As I
>>>> understand it, the Session-Reflector recognizes the IPv6 Extension Header
>>>> Control sub-TLV, but finds that the Reflected Test Packet Control TLV
>>>> includes more than one IPv6 Extension Header Control sub-TLV. In other
>>>> word, construction of the Reflected Test Packet Control TLV is
>>>> non-conformant to this specification. WDYT?
>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Rakesh (for authors)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> 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]
>>>>>>>
>>>>>>