MIME-Version: 1.0
References: 
 <178057887506.2824783.4677034043591438217@dt-datatracker-5b4c8598b5-4ztf9>
 <CA+RyBmX+UQBU4bZ+PnS-9Scm0P8PANPDAWbk_QZVSupYPB6rpQ@mail.gmail.com>
 <CAMZsk6cHkc0Pje9r9WfHPiUk4qiGfG5EOS+zkG-yk1nSYCFftQ@mail.gmail.com>
 <CA+RyBmVZC39u_Nm329WHKGUzJoZZX5gnynmdrkNQFUKqyYup4A@mail.gmail.com>
 <CA+RyBmXd5SARj6=n3C=CPb__f+aXyBFpdiyNSeMbAk624sc30A@mail.gmail.com>
 <CADx9qWik5EpdQi92xp0a9b-85JFxQzLV6u4uCY8QHBaBdvyngA@mail.gmail.com>
 <CA+RyBmWtC8sYEhhsJ6moq3cFVH9PB-xG_vFFwxUtUSvGgfhu9A@mail.gmail.com>
In-Reply-To: 
 <CA+RyBmWtC8sYEhhsJ6moq3cFVH9PB-xG_vFFwxUtUSvGgfhu9A@mail.gmail.com>
From: Will Hawkins <hawkinsw@obs.cr>
Date: Wed, 24 Jun 2026 04:48:21 -0400
Message-ID: 
 <CADx9qWj_97uHEZHAN7gMo-QVTAw-VjY493vNXusvkh-wD7WYzw@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: ZMVV5J7UTXSV25VEVZ4HMEQARPBFJ3TP
CC: draft-ietf-ippm-stamp-ext-hdr@ietf.org, ippm-chairs@ietf.org,
 ippm@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bippm=5D_Re=3A_WG_Last_Call=3A_draft-ietf-ippm-stamp-ext-hdr-08_?=
	=?utf-8?q?=28Ends_2026-06-25=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ippm/jMLiHpGX5HTv8EAE6roWyg1wwa4>

On Tue, Jun 23, 2026 at 6:09=E2=80=AFPM Greg Mirsky <gregimirsky@gmail.com>=
 wrote:
>
> Hi Will,
> Thank you for your thoughtful proposal. Please find my notes below, tagge=
d GIM2>>.
> And I apologize for coming back to my question about the figures that dis=
play examples of STAMP test packets for Session-Sender and Session-Reflecto=
r. As defined in RFC 8972, the Extra Padding TLV is used to make STAMP pack=
ets 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=E2=80=AFPM Will Hawkins <hawkinsw@obs.cr> wr=
ote:
>>
>> On Mon, Jun 22, 2026 at 9:19=E2=80=AFPM Greg Mirsky <gregimirsky@gmail.c=
om> wrote:
>> >
>> > Hi Rakesh,
>> > I misinterpreted the use of the Reflected IPv6 Extension Header Data S=
TAMP TLV, assuming it could carry only the SRH and not any other IPv6 Exten=
sion Header. Please disregard that question below.
>> >
>> > Regards,
>> > Greg
>> >
>> > On Mon, Jun 22, 2026 at 5:34=E2=80=AFPM Greg Mirsky <gregimirsky@gmail=
.com> 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=E2=80=AFAM Rakesh Gandhi <rgandhi.ietf@=
gmail.com> 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=E2=80=AFPM Greg Mirsky <gregimirsky@gma=
il.com> wrote:
>> >>>>
>> >>>> Dear All,
>> >>>> I read the latest version of draft-ietf-ippm-stamp-ext-hdr. The dra=
ft specifies the STAMP extension useful for IPv6 networks. I have several q=
uestions, 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 Re=
flected IPv6 Extension Header-x Data STAMP TLVs in Figure 2. Could you clar=
ify for me the format of an IPv6 STAMP packet constructed by a Session-Send=
er 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 <=3D 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 packe=
t. 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-Ref=
lector that received a STAMP packet with a IPv6 Extension Header Control Su=
b-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#s=
ection-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 Ex=
tension Header Data TLVs. If that is the case, I assume that the C flag mus=
t be set in all Reflected Extension Header Data TLVs in the reflected STAMP=
 test packet. Is that correct?

Hello!

I believe that the ("asymmetric") Sub-TLV that directs the
Session-Reflector to copy the extension headers from the received
packet into the IP headers of the reflected packet is orthogonal to
the operation of the two (2) other TLVs defined in the document. I
read the draft to say that the ("asymmetric") Sub-TLV's sole purpose
is to direct the Session-Reflector to copy the extension headers from
the IP header of the received test packet into the IP headers of the
reflected test packet. The other TLVs defined in the document control
if/how the extension headers from the received test packet are
reflected in the STAMP packet generated by the Session-Reflector. If
that is correct, then I think that it would only be necessary to set
the C flag in the Sub-TLV in the STAMP packet generated by the
Session-Reflector in the case you describe.

(I could be misunderstanding the meaning/purpose of the ("asymmetric")
Sub-TLV! So, please help me! I am taking my interpretation from the
draft. In particular, I am basing my interpretation on

"The IPv6 extension headers received in the Session-Sender test
packets MUST be copied and reflected in the corresponding "Reflected
IPv6 Extension Header Data" TLVs to the Session-Sender regardless of
whether "IPv6 Extension Header Control" Sub-TLV is present or not."

)

Let me know if that helps and whether my interpretation matches yours!

Even if that interpretation is correct, I think that I understand your
additional point: What is the specified behavior in the case where the
test packet specifies the Session-Reflector to copy the extension
headers into the STAMP contents of the reflected test packet but
cannot do so. Am I reading your additional questions correctly??

Will

> 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 i=
s the case, which scenario leads to setting C flag to 1? Also, which TLVs a=
re 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 I=
Pv6 Extension Header Data" STAMP TLV be presented as a separate field for e=
ase 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=3DTBA1    |         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 p=
acket, or only as many as necessary to conform to the IP MTU of the Reflect=
or'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 t=
est
>> >>>>    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 IOA=
M
>> >>>>    data is recorded in the STAMP test packets.  Hence, the Session-
>> >>>>    Sender MUST NOT include a corresponding "Reflected IPv6 Extensio=
n
>> >>>>    Header Data" STAMP TLV in the Session-Sender test packets for th=
e
>> >>>>    IOAM DEX option-type.
>> >>>>
>> >>>> I think there could be other valid motivations to use the "Reflecte=
d 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 comb=
ination 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 hea=
ders
>> >>>    and IP headers by carrying the corresponding "Reflected IPv6
>> >>>    Extension Header Data" and "Reflected Fixed Header Data" STAMP TL=
Vs
>> >>>    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 i=
n
>> >>>    the STAMP test packets.  If not, the Session-Reflector MUST retur=
n
>> >>>    both STAMP TLVs with the C flag (Conformance) set to 1 in the STA=
MP
>> >>>    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 (Ty=
pe
>> >>>    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 =3D TBA3  |         Sub-TLV Length =3D 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 T=
LV
>> >>>    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 te=
st
>> >>>    packet corresponding to the received IPv6 extension headers (exce=
pt
>> >>>    the routing extension headers specific to the Session-Sender test
>> >>>    packet).
>> >>>
>> >>>
>> >>>>
>> >>>> Nit. A document would benefit from consistent use of STAMP terminol=
ogy, 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=E2=80=AFAM Marcus Ihlar via Datatracker=
 <noreply@ietf.org> 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 Maintenan=
ce
>> >>>>>    (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 exam=
ple,
>> >>>>>    using IOAM data fields.
>> >>>>>
>> >>>>> File can be retrieved from:
>> >>>>>
>> >>>>> Please review and indicate your support or objection to proceed wi=
th the
>> >>>>> publication of this document by replying to this email keeping ipp=
m@ietf.org
>> >>>>> in copy. Objections should be explained and suggestions to resolve=
 them are
>> >>>>> highly appreciated.
>> >>>>>
>> >>>>> Authors, and WG participants in general, are reminded of the Intel=
lectual
>> >>>>> 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 an=
y.
>> >>>>> Sanctions available for application to violators of IETF IPR Polic=
y 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-hd=
r-08
>> >>>>>
>> >>>>> A diff from the previous version is available at:
>> >>>>> https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-stamp-=
ext-hdr-08
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> ippm mailing list -- ippm@ietf.org
>> >>>>> To unsubscribe send an email to ippm-leave@ietf.org
>> >>>>
>> >>>> _______________________________________________
>> >>>> ippm mailing list -- ippm@ietf.org
>> >>>> To unsubscribe send an email to ippm-leave@ietf.org