Return-Path: X-Original-To: ippm@mail2.ietf.org Delivered-To: ippm@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 10F25105766BB for ; Mon, 22 Jun 2026 18:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782177549; bh=JQgEE8Z/lhp/Xc5HE2oUZSAM/vEov0k8I29mG4nrHps=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=RCJn2miZ/MFo6d+KICyeR84AnjkBCUeNeTj1aQiAmuSVGXqUbmFw/osHpp9T/xbGc FKK66JvLZ0q2llSdep2So4MH5TuDxnKLi9vOIyZjttj12ajJ662cnyzHsitq/uAHSS nsPZlAhBR6ylinkx1rHitH3qQB/wAcCRZSzsXJWw= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIfg1u2nAc9G for ; Mon, 22 Jun 2026 18:19:08 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id F04DA105766A8 for ; Mon, 22 Jun 2026 18:19:07 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-2c7c61b5292so2021245ad.0 for ; Mon, 22 Jun 2026 18:19:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782177547; cv=none; d=google.com; s=arc-20240605; b=SIgn0/MoTNHgFOCUtEt5g9r5WGI5dMdwtIAyBhzD7SzhWMrrTC/l5/e5W2sAb1rOCD FhNNQyIDkILLY/pqyrlFfVOvqBzx93Fr/4VhmkcJGPWg9K013t0FBl99doqe07pUbR9h 4oO2R9r8oU1Xva/rYnA53el7xXp+O/7n/bS72a/63nbAgemcYW7vIo2GZN/UOAXVnCvC mLVAvz18ZVBdex4He4TFFPPWRNMSFBHIh/0+w8rN1fXrQ1p+xBI6qhwnKHtpWvXDoC4f UYiXZH8tIunxx237hfWI/tzLMS2WWCfIDP0X64VgGf6a6WrQpfITpLoIPVVwuP4Bv/Tm Qukw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=RJuOL2ifg/gULSuRTbn1f2urJ4kvYGfb66ISKc1PQKw=; fh=EiQZM5j62zEf715+NM72qvORMco5+NdnuJ7OVl4fq5Y=; b=gkdvc/jK0e/8hMhZfWvFVgKL1zeNYW8nC1YE7scVxXM7+xfqzd4FQtUMNnzp8mzg6T OBNlUG01iIAPPjh80WZTxn/0+w7HkYgeyFuEtfibdbo10GWiOBKT378SXZpu5/fxnk+k Ftse3A15ISEYcjcOCUWpxRig4HGqe2WDmpT+Zq7zYerlUkR99OrBKMfPkmF5rVPRNYzp 1qvTxj5h5P79F+u78Sf+/JZ8f4+PDOFLeWuJZNSMsKl2SvEtRv2SVwkobVlFZBwFPqyt ZFFdEmd08auxAHQTVOBBDfRtl6dpS/qIumOo5DKDr+FVERMMPxdeJ/M1q3uT9dFfx907 Z0hQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782177547; x=1782782347; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RJuOL2ifg/gULSuRTbn1f2urJ4kvYGfb66ISKc1PQKw=; b=bDCnC13t1kbXzXPi4vHRqf7ne7lagZAQ3Q9doONSxOv6WgZ2JQhK6+ENnPCzZXPO3n m7bPxAjEth4C44UcGEC+aA9UTfN75FBL80rFEzbqOPUaY0w0B2KCI8+tSYRsF43Wf+aW f3J6iAgq7aP1cS6H5/w4zYfCsQd9QSAyg7kTnYhiUOihqw456Q4B+HJj97fgnzKPO2tN bPZL5muDddiswApixUkWN3CNxR/Aln7sQu7AkGqS7mECUVxyMXitrGNnVGU8ObwpDQUv fTlTRPkxfJVTtcGQmhXQiDKPrYfaLgs5utIQpf6qSDmWmaMYS5maQOSJ2OatbUQz1l4e R7yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782177547; x=1782782347; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RJuOL2ifg/gULSuRTbn1f2urJ4kvYGfb66ISKc1PQKw=; b=IayqXW0sxlWnUCw35P5wDBpbCOEIn7duEPfOj3hKszbuRm+2unB2wcsMH8Qw4wI5Bu I3jglN8V2pU6heTe0ZXP5yqQTpuiA4rWHKSdl4MCbHhD8BAFFrQpxn0/5R76wBNxgoNr tlZ0cN+uy4Qu9JBOigDXq3Kii4dAX9Ke1pkLLnSIuzFN49SF98Dy7YXd9s5NuNk+CDFp UkogLV3diqzakhXFThLw5d5qOilcVWvlvVFZo+neOkZhGTDumEhUG8zqIXrHFH6vN+Q1 wgzyrymyV1dyqV9aL3tus+c7Ot2dQwXDkKVl/EhPhYo9EwgJ8riia19C+uPYmjeCxaE0 0c6w== X-Forwarded-Encrypted: i=1; AHgh+Rp23P1DmR/VIHFTyuSnldE09ZgTM+588OOYvNWeJE12GaGjFId+BQoPwKNEP9bF5UAn0mTB@ietf.org X-Gm-Message-State: AOJu0YxZofhrDWpfZEtVHBMwEoGhPDYeKODbmt0cXVBJ5PnHlXRHSC9r 1K8yja5oQdQBhDLkzZ9ylgDbwg8WHU3u5HksIFPewk/YGLv7mi5ucMj82UkHdLC6OzCR81kTvvT 9ecATJNrSh/5NScrtvH32SZww4G94LA4mD9ZgV+A= X-Gm-Gg: AfdE7ckPIQiKyNDjSgRG/XWPtoWMQS5Vji/alhLgCyKCj/IyTDdY+ti2492qt2ASyPu wIco2jtes+r+iIpokqBtqJo3VGoIN4u2BL3ORgX1EOWP3pyZ4Fryq0VK9v8b9mVqA4fiBHnp7gA jR9T3K2Kex//LBX+rER6OfB4rLYf357OPxVM36l1A2QbvlZsqkQ+9yPbDS2UWARKH8T2FhwqzYS Nc0AW1RtmpgjQZPXWnVhd/HppDYzpLw39b70opw+pbl9LZdHTz5FSHr3PrkxmKKZpRDGpyxJxtE oqalK6DH9DXDw8XNp9gPilNezL5A X-Received: by 2002:a17:902:db0a:b0:2bf:dd0:c8b1 with SMTP id d9443c01a7336-2c71871c4f4mr170400645ad.0.1782177547057; Mon, 22 Jun 2026 18:19:07 -0700 (PDT) MIME-Version: 1.0 References: <178057887506.2824783.4677034043591438217@dt-datatracker-5b4c8598b5-4ztf9> In-Reply-To: From: Greg Mirsky Date: Mon, 22 Jun 2026 18:18:54 -0700 X-Gm-Features: AVVi8CdpdNIaRpw_sZO4roXYH_MuMSQuR3ciJ6y2l_d7U5lMSxK8Xxm5uhcI85Y Message-ID: To: Rakesh Gandhi Content-Type: multipart/alternative; boundary="0000000000009e7d570654e18ba9" Message-ID-Hash: WIIBGF6II7FFWITZCOWKDT3B53QSSFY6 X-Message-ID-Hash: WIIBGF6II7FFWITZCOWKDT3B53QSSFY6 X-MailFrom: gregimirsky@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-ietf-ippm-stamp-ext-hdr@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org X-Mailman-Version: 3.3.9rc6 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?= List-Id: IETF IP Performance Metrics Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009e7d570654e18ba9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Greg Mirsky = 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 > 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 ... >> >> On Wed, Jun 10, 2026 at 8:53=E2=80=AFPM Greg Mirsky >> 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". >>> >>> >> 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. C= ould >>> 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? >>> >>> 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 > packet. That operational decision was the motivation to work on u-SIDs. C= an > you help me with a scenario in which a Session-Reflector receives a packe= t > 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 Head= er > 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 > )? > >> >> >> >>> >>> - Should the first four octets of the Value field of the "Reflected >>> IPv6 Extension Header Data" STAMP TLV be presented as a separate fie= ld for >>> ease of reference and specification of the matching mechanism? >>> >>> >> 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 >>> packet, or only as many as necessary to conform to the IP MTU of the >>> Reflector's egress interface? >>> >>> >> 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 cou= ld >>> be applied in this case. >>> >>> >> 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? >>> >>> >> Added following text: >> >> >> >> >> * STAMP test packets can be used to reflect both IPv6 extension headers >> and IP headers by carrying the corresponding "Reflected IPv6 Extensio= n >> 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 maint= ain >> the same order as the IP headers and extension headers in the STAMP te= st >> packets. If not, the Session-Reflector MUST return both STAMP TLVs wi= th >> 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? >>> >>> >> Added following Figure: >> >> >> >> >> >> >> >> >> >> >> >> >> >> *This document defines the "IPv6 Extension Header Control" Sub-TLV >> (Type TBA3) for the "Reflected Test Packet Control" STAMP TLV (Type 1= 2) >> 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 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 receive= d >> with the "IPv6 Extension Header Control" Sub-TLV, the Session-Reflecto= r >> MUST add matching IPv6 extension headers in the Session-Reflector STAM= P >> test 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 terminology, >>> e.g., Session-Sender vs Sender. >>> >> >> 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 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 t= he >>>> publication of this document by replying to this email keeping >>>> ippm@ietf.org >>>> in copy. Objections should be explained and suggestions to resolve the= m >>>> 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 ca= n >>>> 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=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 >>> >> --0000000000009e7d570654e18ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rakesh,
I misinterpreted the use of the=C2=A0Reflec= ted IPv6 Extension Header Data STAMP TLV, assuming it could carry only the = SRH and not any other IPv6 Extension Header. Please=C2=A0disregard=C2=A0tha= t question below.

Regards,
Greg

On Mon, Jun 22, 2026 at 5:34=E2=80=AFPM Greg Mirsky <= gregimirsky@gmail.com> wrot= e:
Hi=C2=A0Rakesh,
Thank you for your thoughtful cons= ideration 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 do= cument.

We have addressed your comments in the wor= king copy (rev-09) of the document, as replied below <RG>...
On Wed, J= un 10, 2026 at 8:53=E2=80=AFPM Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear A= ll,
I read the latest version of=C2=A0draft-ietf-ippm-stamp-ext-hdr. Th= e draft specifies the STAMP extension useful for IPv6 networks. I have seve= ral questions, please consider them as WG LC comments:
  • A = general=C2=A0observation. I feel=C2=A0that the document would be helpful to= an=C2=A0implementer=C2=A0if it used the normative language rather than &qu= ot;can", "does", and "does not".

<RG> Updated where applicable.
GIM>> Thank you=C2=A0
=C2=A0
  • I got confused by the labeling of the IPv6= extension headers and=C2=A0Reflected IPv6 Extension Header-x Data STAMP TL= Vs 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 f= or simplicity.

=C2=A0 =C2=A0 +----------------------------------------------= -----------------+
=C2=A0 =C2=A0 | IPv6 Header =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 +---------------------------------------------------= ------------+
=C2=A0 =C2=A0 | IPv6 Extension Header-1 RFC 8200 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 +-------------------------------= --------------------------------+
=C2=A0 =C2=A0 ~ ... =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ~
=C2=A0 =C2=A0 +----------------= -----------------------------------------------+
=C2=A0 =C2=A0 | IPv6 Ex= tension Header-N RFC 8200 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 += ---------------------------------------------------------------+
=C2=A0 = =C2=A0 | UDP Header =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 +---= ------------------------------------------------------------+
=C2=A0 =C2= =A0 | STAMP Packet RFC 8972 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 +----------------------------------= -----------------------------+
=C2=A0 =C2=A0 | Reflected IPv6 Extension = Header-1 Data STAMP TLV (TBA1) =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 +---= ------------------------------------------------------------+
=C2=A0 =C2= =A0 ~ ... =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ~
=C2= =A0 =C2=A0 +---------------------------------------------------------------= +
=C2=A0 =C2=A0 | Reflected IPv6 Extension Header-M Data STAMP TLV (TBA1= ) =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 +--------------------------------= -------------------------------+

=C2=A0 =C2=A0 =C2=A0 Note: Value of= M <=3D N

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: Example Session-S= ender and Session-Reflector Test
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet with= Reflected IPv6 Extension Header Data STAMP TLVs
<= /div>
GIM>> Thank you for the figure, but I still wo= nder if the scenario of multiple SRHs is realistic. AFAIK, operators use a = single SRH in the packet. That operational decision was the motivation to w= ork 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.
G= IM>> And an additional question. What are actions of the Session-Refl= ector 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 T= TL case described in Section 4.2 of RFC 5357)?

=C2=A0
  • Should the first four octets of the Value= field of the=C2=A0"Reflected IPv6 Extension Header Data" STAMP T= LV 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.

=C2=A0 =C2=A0 = 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
=C2=A0 = =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0 |STAMP TLV Flags| =C2=A0Type=3DTBA1 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Requested IPv6 Extension Header Data =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reflected IPv6 Extension H= eader Data =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 ~ =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ~
=C2=A0 =C2=A0 = | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 6: Refle= cted IPv6 Extension Header Data TLV
GIM>> Thank you=C2=A0=C2=A0
= =C2=A0
  • It seems that the=C2=A0following processing=C2=A0option ca= n benefit from the use of the normative language:
=C2=A0 =C2=A0If necessary, Reflected Da= ta
=C2=A0 =C2=A0STAMP TLVs can be removed to avoid violating the IP MTU = limit.
And I find the suggestion somewhat ambiguous. Should all Reflected IPv6 E= xtension 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:

=C2=A0 = =C2=A0The Session-Sender and Session-Reflector MUST ensure that the
=C2= =A0 =C2=A0resulting test packets do not exceed the IPv6 MTU after adding=C2=A0 =C2=A0"Reflected IPv6 Extension Header Data" STAMP TLVs.= =C2=A0 If necessary, one
=C2=A0 =C2=A0or more "Reflected IPv6 Exten= sion Header Data" STAMP TLVs MUST be
=C2=A0 =C2=A0removed to avoid = violating the IPv6 MTU limit.
GIM>= ;> Excellent, thanks!=C2=A0

= =C2=A0
  • MUST NOT in the following text seems too restrictive:
    • =
=C2=A0 =C2=A0IOAM = Direct Exporting (DEX) [RFC9326] is applicable with STAMP test
=C2=A0 = =C2=A0packets for on-path telemetry use cases
=C2=A0 =C2=A0[I-D.ietf-ipp= m-on-path-active-measurements].=C2=A0 In this case, the
=C2=A0 =C2=A0Ses= sion-Reflector does not reflect IOAM data fields since no IOAM
=C2=A0 = =C2=A0data is recorded in the STAMP test packets.=C2=A0 Hence, the Session-=
=C2=A0 =C2=A0Sender MUST NOT include a corresponding "Reflected IP= v6 Extension
=C2=A0 =C2=A0Header Data" STAMP TLV in the Session-Sen= der test packets for the
=C2=A0 =C2=A0IOAM DEX option-type.
I think there cou= ld be other valid motivations to use the "Reflected IPv6 Extension Hea= der Data" STAMP TLV. Perhaps softening to MAY NOT could be applied in = this case.

&= lt;RG> Updated to MAY not.
GIM>>= ; Thank you=C2=A0=C2=A0
=C2=A0
  • Can= =C2=A0Reflected IPv6 Extension Header Data STAMP TLVs be used in combinatio= n with=C2=A0Reflected Fixed Header Data STAMP TLV? What are the rules=C2=A0= that=C2=A0govern such a scenario?
<RG> Added following text:

=C2= =A0 =C2=A0STAMP test packets can be used to reflect both IPv6 extension = headers
=C2=A0 =C2=A0and IP headers by carrying the corresponding "= Reflected IPv6
=C2=A0 =C2=A0Extension Header Data" and "Reflec= ted Fixed Header Data" STAMP TLVs
=C2=A0 =C2=A0as shown in Figure 4= .

=C2=A0 =C2=A0The "Reflected Fixed Header Data&q= uot; STAMP TLV MUST be added before
=C2=A0 =C2=A0adding the "Reflec= ted IPv6 Extension Header Data" STAMP TLVs to
=C2=A0 =C2=A0maintain= the same order as the IP headers and extension headers in
=C2=A0 =C2=A0= the STAMP test packets.=C2=A0 If not, the Session-Reflector MUST return
= =C2=A0 =C2=A0both STAMP TLVs with the C flag (Conformance) set to 1 in the = STAMP
=C2=A0 =C2=A0TLV Flags using the procedure defined in
=C2=A0 = =C2=A0[I-D.ietf-ippm-asymmetrical-pkts].
GIM>> Thank you=C2=A0=C2=A0
=
  • Can you please clarify the format of "IPv6 Extensio= n Header Control" sub-TLV?

=
<RG> Added following Figure:

=C2= =A0 =C2=A0This document defines the "IPv6 Extension Header Control&= quot; Sub-TLV
=C2=A0 =C2=A0(Type TBA3) for the "Reflected Test Pack= et Control" STAMP TLV (Type
=C2=A0 =C2=A012) introduced in [I-D.iet= f-ippm-asymmetrical-pkts].=C2=A0 The format of
=C2=A0 =C2=A0"IPv6 E= xtension Header Control" Sub-TLV is shown in Figure 8.

=C2=A0 =C2=A0 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
=C2=A0 =C2=A0 +-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0= | Sub-TLV Flags | =C2=A0Type =3D TBA3 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Sub-TLV Length =3D 0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Figure 8: IPv6 Extension Header Control Sub-TLV

=C2=A0 =C2=A0The Sub-TLV fields are defined as follows:<= /i>

=C2=A0 =C2=A0Type: Sub-TLV Type (value TBA3).

= =C2=A0 =C2=A0Sub-TLV Flags: The Sub-TLV Flags follow the procedure for STAM= P TLV
=C2=A0 =C2=A0Flags described in [RFC8972].

=C2=A0 =C2=A0Sub= -TLV Length: A two-octet field equal to the length of the Data in
=C2=A0= =C2=A0octets.=C2=A0 It is set to 0.

=C2=A0 =C2=A0When a Session-Sen= der test packet is received with the "IPv6
=C2=A0 =C2=A0Extension H= eader Control" Sub-TLV, the Session-Reflector MUST add
=C2=A0 =C2= =A0matching IPv6 extension headers in the Session-Reflector STAMP test
= =C2=A0 =C2=A0packet corresponding to the received IPv6 extension headers (e= xcept
=C2=A0 =C2=A0the routing extension headers specific to the Session= -Sender test
=C2=A0 =C2=A0packet).

=C2=A0
Nit. A document would benefit from consistent use of STAMP terminolog= y, e.g., Session-Sender vs Sender.

<= /div>
<RG> Fixed.
GIM>> = Thank you=C2=A0

Thanks,
Rakesh (for authors)

=C2=A0

Re= gards,
Greg

On Thu, Jun 4, 2026 at 6:14=E2=80=AFAM Marcus Ih= lar 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:
=C2=A0 =C2=A0The Simple Two-Way Active Measurement Protocol (STAMP) and its=
=C2=A0 =C2=A0optional extensions can be used for Edge-to-Edge (E2E) active<= br> =C2=A0 =C2=A0measurement.=C2=A0 In Situ Operations, Administration, and Mai= ntenance
=C2=A0 =C2=A0(IOAM) data fields can be used for recording and collecting Ho= p-by-
=C2=A0 =C2=A0Hop (HBH) and E2E operational and telemetry information.=C2=A0= This
=C2=A0 =C2=A0document extends STAMP to reflect IP headers as well as IPv6 =C2=A0 =C2=A0extension headers for HBH and E2E active measurements, for exa= mple,
=C2=A0 =C2=A0using 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 ippm@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 Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1].
Appropriate IPR disclosures required for full conformance with the provisio= ns
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<= br> 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/draf= t-ietf-ippm-stamp-ext-hdr/

There is also an HTMLized version available at:
https://datatracker.ietf.org/d= oc/html/draft-ietf-ippm-stamp-ext-hdr-08

A diff from the previous version is available at:
https://author-tools.iet= f.org/iddiff?url2=3Ddraft-ietf-ippm-stamp-ext-hdr-08

_______________________________________________
ippm mailing list -- ipp= m@ietf.org
To unsubscribe send an email to ippm-leave@ietf.org
_______________________________________________
ippm mailing list -- ipp= m@ietf.org
To unsubscribe send an email to ippm-leave@ietf.org
--0000000000009e7d570654e18ba9--