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 3DBF510F18CDA for ; Sun, 5 Jul 2026 06:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783259909; bh=se/9JY0O5ZbdBFID0UXK8Gl2DXqS77K9pBwSU9DOiwk=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=J7R79qgr0C1ZVxn25TxLhZ0kksWNYeIK10V5QJjRfXxedXnxp6p5rPVEt06/OIIOV ue8PDYZyHSqmrriKVRxAnTral75yHwrrRyirnSQaF5Nw9p1q3yTrgiZncmQbKyvSRi PyymMd4zaDTi++QLXA1+lCKbNDA5Cp8Hn/9zTPM8= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, T_KAM_HTML_FONT_INVALID=0.01] 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 GgIklv-mwAKI for ; Sun, 5 Jul 2026 06:58:27 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 0C83D10F18CBA for ; Sun, 5 Jul 2026 06:58:27 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-691c5776f95so4003124a12.3 for ; Sun, 05 Jul 2026 06:58:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783259906; cv=none; d=google.com; s=arc-20260327; b=GpzxjDTHpx8InxEmF8JBfp9E7yYyb6KUnzRirkF1o1uBvVOi/uJWRuzX7dyU3abacT 8L/DVex6jFsJwLgy4XSy1yTsNhWN9Z4P4srPwW6HxY3TjQiAeOCQg6+G3A0+ZEIvuXnh pg27A7JcwhNug2JHySB1xCtLlbyG/fNuifeU50BMX91ORj+THjlyQHazDj4aAcikXwov YbKjlBV1hCo0PJOKVkhD4QXW+xp4qCrzPVkModu8FYjcfSVo0KikRdf3Zpk43D+qnsdv PEC7Baj4I/ofbpYozarqoVBZAob8JiWOYVTsS5pxAFpApgB7rIO2zHNvWGIB9TDNdw50 DyAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=14q4nMweC2SwC3/CBEkjXJyQW5LsHw4R6I2DZzmcRwU=; fh=YZlGyStOb25fdgnb5E4YOmLfkNvu2gTaKcteAmTsnKM=; b=I2YukV67p5BVqoiVz82FLuQF9j+WxCRuTWIf13D0T1IHl8FCL/ier1XlfTYuipXcsN WiUx7DxcbSR06uiagJKh5pympUETFGBbFFGVnWHQ89aeU54csYm+zTA/FDLu08vLFBB2 DJDPxsu/iHUOJfHA58RApfJH8n3/bEWhJplvjYBvPy7wqAd/THMfnuzPzs7VWaGCOWoG cde1MFl4akegS/FbMlrcXajdn7o7TDTshFDqDS15dfet74AAo463kZqVK1ZfXyTEoIN/ PtZxXzLD6V1m7oP3EN7GqxN/5uqTFZfX/6NiyncwpIOC4nrm5PoCuP5BqPwl8+ntLb3i mugg==; 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=1783259906; x=1783864706; 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=14q4nMweC2SwC3/CBEkjXJyQW5LsHw4R6I2DZzmcRwU=; b=cFlJ/BAjUdBdXMwWlQDGtHTHXj7E5F2v+LbceqXUP6yyU/1pn+4BwYUdTqQ/7PCh3d D9VSbw2S2Bq4ChXrPuKrt0yv43riDJsXhIpt2r2CZDmcUO4d7xfy7J0/pKudztWdN9W2 tstmcx5B5JZDIncGG9+bHhrZXdc9rV0JC/2jCZ9V2fq5u/Tuiwk/kQd9evXIL2Zb6+kM uzxtc/r58gJQOpOlyZyqgxLIo6Uv3mtrYOk+6vteGFAc25ADEv+6STFlWWxT58a4zxiS Hl2F0oXm4Dy9MXKYEkjWQcwaZqqR7+v5xJRETrfWUse7tnLW4Ku6Ka9yKFbdClvbNfsr KIOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783259906; x=1783864706; 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=14q4nMweC2SwC3/CBEkjXJyQW5LsHw4R6I2DZzmcRwU=; b=aes9RvTFO+UxEXZ4E3v62Kj+zhZ+/KMWI64NFn59rGD6wbwdF0VH3eAm+vuRvmwccJ wz59t8UmpDtyy7tBp7lkuaYH19X0o9sh7JBWQe1tpKEFQXmHTvckZAS45nGGhhxqEND0 H0GRO7wMw92ujWtR9FyJx67xLrM5DLNVH5frlJme0vQkFuz/xFAUYVCVZlka/0hrsHkK TzaiLB6l11cTR1aYYJDL5g5rJgaJvH4hvV/3HTPQvWj7II545m5w8jUCIq2GIHVAvU+C J/1TjhC9Dk2/sguvBvbBO41aOUxtlUkEbZ+C0cXbldS4Us2dER6tZEPtAbsViz45LNGK NpjQ== X-Forwarded-Encrypted: i=1; AHgh+RqtH4puQYE8aNjWJEuNj8swHyiRHtQ+K5h+A0v//GrQmfr7soy9duaz+2BQUHWYFpsd2X6I@ietf.org X-Gm-Message-State: AOJu0YyQ3/plzrkVw2dX9i6T0T2Qp5y8El951R6yRvJjA3rzVY8nJucr kiKJ6hm38RLEE2uCc0Uf4S1BC+nnODsXo2ODMXVTSBpdYcf48u3y0P9bREo3OQVZDUwRGa+c3bw Be+xgkHfwJtYBI4BDAYBC4+QLVdwg4w== X-Gm-Gg: AfdE7clpPoeLnB5m75IHww0OvOGuN88+OVJpyYtqXN60KVsKIKvTyNNqHUN+tsxRUre bm/8HE1k7TN0qH9Od1F3xHEO7JeuqBzl8rc0zJwa3PDiJ9sW2NOtAC6UbU1NNkgplS+G4DtD0QI /Jso/ECRMtdidtckNac4bopzRDieTDZZDgxjJ8h/gOZstbW97hBYcVjnEdJFlZcZR+itQaa04+S SIOw2jIQW2xHHwGH1EYPjZyFTXlXrJu5aHnzKZuAhQ5BdnZTiJJxmqn7rLiJ2CVNRCDQJHVuzP/ tk4+T+tlv4A9ovgKujLkckA0ddf+SmH1OEcArXR+8xBWMqjMRovUqbBNUg== X-Received: by 2002:a05:6402:43c6:b0:699:cf4d:e484 with SMTP id 4fb4d7f45d1cf-69a1a3a9759mr1943887a12.21.1783259905644; Sun, 05 Jul 2026 06:58:25 -0700 (PDT) MIME-Version: 1.0 References: <178057887506.2824783.4677034043591438217@dt-datatracker-5b4c8598b5-4ztf9> In-Reply-To: From: Rakesh Gandhi Date: Sun, 5 Jul 2026 09:58:13 -0400 X-Gm-Features: AVVi8CdUEGM0A7rpcP0mcTL8RR_f5foxT5nmmc7NIae1D5ODrU9r25e572RlTjg Message-ID: To: Greg Mirsky Content-Type: multipart/alternative; boundary="00000000000037de9a0655dd8d60" Message-ID-Hash: GTHTSDXE2D7XMINUZGLDGH6G3GVJGJDX X-Message-ID-Hash: GTHTSDXE2D7XMINUZGLDGH6G3GVJGJDX X-MailFrom: rgandhi.ietf@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: Will Hawkins , 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: --00000000000037de9a0655dd8d60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you for your follow-up comments. One reply below with * 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? 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=E2=80=AFAM Rakesh Gandhi wrote: > Hi Greg, > > Thank you for reviewing the suggested updates. > > Please see the replies inline with ... > > > 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 Reflecte= d > 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? > > > 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 packe= ts. > > I fail to see how extra padding would be applicable to this draft a= s > Sender adds new fixed length STAMP TLVs defined in this draft and Reflect= or > 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 zero= ed > on transmission by the Session-Sender and ignored by the Session-Reflecto= r > on receipt? > > This is covered in the =E2=80=9CRequested IPv6 Extension Header Dat= a=E2=80=9D field > in the draft where additional fields are compared. > > > > -------------------------------------------------------------------------= ------- > > > GIM3>> Could you please clarify to which STAMP TLV and Sub-TLV this > applies? > > 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? > > > > 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, t= he > Session-Reflector MUST return the STAMP TLV with the U flag (Unrecogniz= ed > 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. I= t > 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? > > 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.* > > > -------------------------------------------------------------------------= -------- > > > > > 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. > > > > 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" T= LV > with the U flag (Unrecognized TLV) set to 1 in the Sub- TLV Flags of al= l > "IPv6 Extension Header Control" Sub-TLVs, using the procedure defined i= n > [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? > > C flag is already used for the following case in this Sub-TLV. > U flag in Sub-TLV is used to distinguish the below case with the > above case case for the multiple Sub-TLVs. > draft-ietf-ippm-asymmetrical-pkts unfortunately does not cover the > multiple sub-TLVs case for "Reflected Test Packet Control=E2=80=9D TLV al= though it > defines several sub-TLVs. > I think, the draft-ietf-ippm-asymmetrical-pkts could also > benefit from above U flag behaviour, since the C flag was already used fo= r > a different purpose in draft-ietf-ippm-asymmetrical-pkts. > > 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=E2=80=AFPM Greg Mirsky 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=E2=80=AFAM Rakesh Gandhi >> wrote: >> >>> Hi Greg, >>> >>> Thank you for the further review comments and the discussions. >>> >>> Please see replies inline with ... >>> >>> On Tue, Jun 23, 2026 at 6:09=E2=80=AFPM Greg Mirsky >>> 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 us= ed to >>>> make STAMP packets symmetrical. If that is also the case for the Refle= cted >>>> 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? >>>> >>> >>> 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 us= e >> 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 TL= V >> to make up for the difference in length between base and reflected pack= ets. >> 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 nothin= g >> of the kind, should the document state that all Value fields MUST be zer= oed >> on transmission by the Session-Sender and ignored by the Session-Reflect= or >> on receipt? >> >>> >>> >>>> >>>> Regards, >>>> Greg >>>> >>>> On Mon, Jun 22, 2026 at 8:04=E2=80=AFPM Will Hawkins = wrote: >>>> >>>>> On Mon, Jun 22, 2026 at 9:19=E2=80=AFPM Greg Mirsky >>>>> wrote: >>>>> > >>>>> > Hi Rakesh, >>>>> > I misinterpreted the use of the Reflected IPv6 Extension Header Dat= a >>>>> STAMP TLV, assuming it could carry only the SRH and not any other IPv= 6 >>>>> 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 < >>>>> 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 ... >>>>> >>> >>>>> >>> 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. 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? >>>>> >>> >>>>> >>> 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 Te= st >>>>> >>> Packet with Reflected IPv6 Extension Header Data STAMP TL= Vs >>>>> >> >>>>> >> 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 t= he >>>>> packet. That operational decision was the motivation to work on u-SID= s. Can >>>>> you help me with a scenario in which a Session-Reflector receives a p= acket >>>>> 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 a= s >>>>> 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]." >>>> >>>> >>> >>> 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 M= UST >>> 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 th= at >>>> the C flag must be set in all Reflected Extension Header Data TLVs in = the >>>> reflected STAMP test packet. Is that correct? >>>> >>> >>> >>> 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 fl= ag >>> (Unrecognized TLV) set to 1 in the STAMP TLV Flags using the procedu= re >>> defined in [RFC8972]. This can occur, for example, if there is a >>> mismatch in the length between the received IPv6 extension headers an= d >>> 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 acc= ess >> 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 th= e >> 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, w= hich >>>> TLVs are included in "both STAMP TLVs"? >>>> >>> >>> >>> 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 def= ined >>> 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 STAM= P >>>> 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. >>>> >>> >>> >>> 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- T= LV, >>> 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 Heade= r >> 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 respons= e >>>>> is helpful! >>>>> >>>>> Will >>>>> >>>>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>>> >>>>> >>>> Should the first four octets of the Value field of the "Reflecte= d >>>>> IPv6 Extension Header Data" STAMP TLV be presented as a separate fiel= d 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 th= e 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 STAM= P >>>>> test >>>>> >>>> packets for on-path telemetry use cases >>>>> >>>> [I-D.ietf-ippm-on-path-active-measurements]. In this case, t= he >>>>> >>>> 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 t= o MAY >>>>> NOT could 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 >>>>> >>> 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 befo= re >>>>> >>> adding the "Reflected IPv6 Extension Header Data" STAMP TLVs t= o >>>>> >>> maintain the same order as the IP headers and extension header= s >>>>> 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? >>>>> >>> >>>>> >>> >>>>> >>> 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 =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 STAM= P >>>>> 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. >>>>> >>> >>>>> >>> >>>>> >>> Fixed. >>>>> >> >>>>> >> GIM>> Thank you >>>>> >>> >>>>> >>> >>>>> >>> Thanks, >>>>> >>> Rakesh (for authors) >>>>> >>> >>>>> >>> >>>>> >>>> >>>>> >>>> >>>>> >>>> Regards, >>>>> >>>> Greg >>>>> >>>> >>>>> >>>> On Thu, Jun 4, 2026 at 6:14=E2=80=AFAM Marcus Ihlar via Datatrac= ker < >>>>> 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 i= ts >>>>> >>>>> optional extensions can be used for Edge-to-Edge (E2E) activ= e >>>>> >>>>> 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. Th= is >>>>> >>>>> 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 >>>>> 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 7= 9 >>>>> [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-0= 8 >>>>> >>>>> >>>>> >>>>> 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 >>>>> >>>> --00000000000037de9a0655dd8d60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

Th= ank you for your follow-up comments. One reply below with <RG4>

<snip&= gt;

<RG2> STAMP test pac= kets MUST NOT carry more than one "IPv6 Extension
=C2=A0 =C2=A0Head= er Control" Sub-TLV in a "Reflected Test Packet Control" TLV= .=C2=A0 If
=C2=A0 =C2=A0the "Reflected Test Packet Control" TL= V in the Session-Sender test
=C2=A0 =C2=A0packet contains more than one = "IPv6 Extension Header Control" Sub-
=C2=A0 =C2=A0TLV, the Ses= sion-Reflector MUST return the "Reflected Test Packet
=C2=A0 =C2=A0= Control" TLV with the U flag (Unrecognized TLV) set to 1 in=C2= =A0the Sub-
=C2=A0 =C2=A0TLV Flags of all "IPv6 Extension= Header Control" Sub-TLVs,=C2=A0using the
=C2=A0 =C2=A0procedur= e defined in [RFC8972].

GIM3= >> Could it be that the C flag is more suitable in this case? As I=20 understand it, the Session-Reflector recognizes the IPv6 Extension=20 Header Control sub-TLV, but finds that the Reflected Test Packet Control TLV includes more than one IPv6 Extension Header Control sub-TLV. In=20 other word, construction of the Reflected Test Packet Control TLV is=20 non-conformant to this specification. WDYT?

<RG4> Ok, updated to use the C flag for this ca= se in the latest revision.

Thanks,
Rakesh (for authors)


=




On Fri, = Jun 26, 2026 at 11:43=E2=80=AFAM Rakesh Gandhi <rgandhi.ietf@gmail.com> wrote:
Hi Greg,

Thank you for reviewing the suggested updates.=C2=A0

Please see the replies inline with <RG3>...


And I apologize for coming back to my question abo= ut the figures that display examples of STAMP test packets for Session-Send= er 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 Re= flected 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. WDY= T?

<RG2> Both Session-Sender and Sessio= n-Reflector test packets carry the same number of=C2=A0Reflected IPv6 Exten= sion Header Data STAMP and the Fixed IPv6 Header Data TLVs, making them sym= metric 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-Sende= r. 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 th= e Session-Sender MUST have Extra Padding TLV to make up for=C2=A0the differ= ence in=C2=A0 length between base and reflected packets.

<RG3> I fail to see how extra p= adding would be applicable to this draft as Sender adds new fixed length ST= AMP 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-Refl= ector must use information other than the Type field value, in IPv6 Extensi= on Header Data or Fixed Header Data TLVs for sanity verification? If nothin= g of the kind, should the document state that all Value fields MUST be zero= ed on transmission by the Session-Sender and ignored by the Session-Reflect= or on receipt?

=
<= RG3> This is covered in the =E2=80=9CRequested IPv6 Extension Header Dat= a=E2=80=9D field in the draft where additional fields are compared.

--= ---------------------------------------------------------------------------= ---

GIM3>> Could you pleas= e clarify to which STAMP TLV and Sub-TLV this applies?=C2=A0

<RG3> Revised the text as f= ollows to add these TLV and Sub-TLV.

=C2=A0=C2=A0=C2=A0If the Session-Ref= lector cannot add a new matching IPv6 extension
=C2=A0 =C2=A0header in the Sessio= n-Reflector test packet, the Session-Reflector
=C2=A0 =C2=A0MUST return the= =C2=A0"Reflected Test Packet Control" TLV=C2=A0with the C flag
=C2=A0 =C2=A0(Conformance) set to 1 in the Sub-TLV Flags= of the=C2=A0"IPv6 Extension
=C2=A0 =C2=A0Header Co= ntrol" Sub-TLV=C2=A0using the procedure defined in
=C2=A0 = =C2=A0[I-D.ietf-ippm-asymmetrical-pkts].=C2=A0 This can occur, for example,= when
= =C2=A0 =C2=A0the Session-Reflector does not support the IPv6 extension head= er, or
=C2=A0 =C2=A0when the Session-Reflector cannot access the received IPv6 ex= tension
<= i>=C2=A0 =C2=A0headers, etc.
----------------------------------------------= -----------------------------------
=C2=A0
GIM2>> As I understand it (please co= rrect me if I misunderstand it), the STAMP test packet transmitted by the S= ession-Sender includes M Reflected Extension Header Data TLVs. If that is t= he case, I assume that the C flag must be set in all Reflected Extension He= ader Data TLVs in the reflected STAMP test packet. Is that correct?


<RG2> R= evised the text as follows.=C2=A0

=C2=A0 =C2=A0When the Session-Reflector does not use the received &quo= t;Reflected IPv6
=C2=A0 =C2=A0Extension Header Data" TLV for reflec= ting the IPv6 extension header,
=C2=A0 =C2=A0the Session-Reflector MUST = return the STAMP TLV with the U flag
=C2=A0 =C2=A0(Unrecognized TLV) set= to 1 in the STAMP TLV Flags using the
=C2=A0 =C2=A0procedure defined in= [RFC8972].=C2=A0 This can occur, for example, if
=C2=A0 =C2=A0there is = a mismatch in the length between the received IPv6 extension
=C2=A0 =C2= =A0headers and the "Reflected IPv6 Extension Header Data" TLVs, o= r when
=C2=A0 =C2=A0the Session-Reflector cannot access the received = IPv6 extension
=C2=A0 =C2=A0headers,=C2=A0etc.

GIM3>> I got confused when reading the prev= ious 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-Re= flector MUST set both C and U flags in the TLV flags field of the IPv6 Exte= nsion Header Data TLV in the reflected STAMP test packet. Am I missing some= thing here?

<RG3= > Revised the text as follows to indicate the TLV type to avoid confusio= n.

=C2=A0 =C2=A0When the Session= -Reflector could not use the received "Reflected IPv6
=
=C2=A0 =C2=A0Ex= tension Header Data" TLV for reflecting any IPv6 extension header,=
=C2=A0 = =C2=A0the Session-Reflector MUST return the=C2=A0"Refl= ected IPv6 Extension
=C2=A0 =C2=A0Header Data" TLV=C2=A0= with the U flag (Unrecognized TLV) set to 1 in the
=C2=A0 =C2=A0STAMP TLV Fl= ags using the procedure defined in [RFC8972].=C2=A0 This can
=C2=A0 =C2=A0occur, = for example, if there is a mismatch in the length between the
=C2=A0 =C2=A0receiv= ed IPv6 extension headers and the "Reflected IPv6 Extension
<= div style=3D"font-size:12pt;font-style:normal;font-variant-caps:normal;font= -weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tra= nsform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;t= ext-decoration-style:solid;font-family:"\000026quot;Aptos\000026quot;&= quot;,Arial,Helvetica,sans-serif;color:rgb(118,62,155)">=C2=A0 =C2=A0Hea= der Data" TLVs, or when the Session-Reflector cannot access the
=C2=A0 =C2= =A0received IPv6 extension headers, or when the IPv6 extension header
=C2=A0 =C2= =A0corresponding to the "Requested IPv6 Extension Header Data" fi= eld was
<= i>=C2=A0 =C2=A0not found, etc.

----------= -----------------------------------------------------------------------
<snip>

=C2=A0
GIM2>> I returned to the last paragraph of Section= 5.3:
=C2=A0 =C2=A0STAMP test packets MUS= T NOT carry more than one "IPv6 Extension
=C2=A0 =C2=A0Header Contr= ol" Sub-TLV in a "Reflected Test Packet Control" TLV.=C2=A0 = If
=C2=A0 =C2=A0a Session-Sender test packet contains more than one &quo= t;IPv6 Extension
=C2=A0 =C2=A0Header Control" Sub-TLV, the Session-= Reflector MUST return the STAMP
=C2=A0 =C2=A0TLV with the U flag (Unreco= gnized TLV) set to 1 in the STAMP TLV
=C2=A0 =C2=A0Flags using the proce= dure defined in [RFC8972].
<= br>
I couldn&= #39;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 tes= t as follows:

<= /i>
=C2=A0 =C2=A0ST= AMP test packets MUST NOT carry more than one "IPv6 Extension
=C2= =A0 =C2=A0Header Control" Sub-TLV in a "Reflected Test Packet Con= trol" TLV.=C2=A0 If
=C2=A0 =C2=A0the "Reflected Test Packet Co= ntrol" TLV in the Session-Sender test
=C2=A0 =C2=A0packet contains = more than one "IPv6 Extension Header Control" Sub-
=C2=A0 =C2= =A0TLV, the Session-Reflector MUST return the "Reflected Test Packet=C2=A0 =C2=A0Control" TLV with the U flag (Unrecognized TLV) set to = 1 in=C2=A0the Sub-
=C2=A0 =C2=A0TLV Flags of all "I= Pv6 Extension Header Control" Sub-TLVs,=C2=A0using the
=C2=A0 = =C2=A0procedure 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 Extens= ion Header Control sub-TLV, but finds that the Reflected Test Packet Contro= l TLV includes more than one IPv6 Extension Header Control sub-TLV. In othe= r word, construction of the Reflected Test Packet Control TLV is non-confor= mant to this specification. WDYT?

<RG3> C flag is already used for the following ca= se in this Sub-TLV.=C2=A0
<RG3> U flag in Sub-TLV is used to disting= uish the below case with the above case case for the multiple Sub-TLVs.=C2= =A0
<RG3> draft-ietf-ippm-asymmetrical-pkts unfortunately does not c= over the multiple sub-TLVs case for "Reflected Test Packet Control=E2= =80=9D TLV although it defines several sub-TLVs.=C2=A0
<RG3> I think= , the draft-ietf-ippm-asymmetrical-pkts=C2=A0could also benefit=C2=A0from a= bove U flag behaviour, since the C flag was already used for a=C2=A0differe= nt purpose in draft-ietf-ippm-asymmetrical-pkts.

<RG3> Related existing text in the draft.

=C2=A0 =C2=A0If the Sess= ion-Reflector cannot add a new matching IPv6 extension
=C2=A0 =C2=A0header in th= e Session-Reflector test packet, the Session-Reflector
=C2=A0 =C2=A0MUST return = the "Reflected Test Packet Control" TLV with the=C2=A0C flag
=C2=A0 =C2=A0(Conformance) set to 1 i= n the Sub-TLV Flags of the "IPv6 Extension
=C2=A0 =C2=A0Header Contr= ol" Sub-TLV using the procedure defined in
=C2=A0 =C2=A0[I-D.ietf-ippm-asymm= etrical-pkts].=C2=A0 This can occur, for example, when
=C2=A0 =C2=A0the Session-= Reflector does not support the IPv6 extension header, or
=C2=A0 =C2=A0when the Se= ssion-Reflector cannot access the received IPv6 extension
=C2=A0 =C2=A0headers, e= tc.


Thanks,
Rakesh (for authors)


<= /div>



On Thu, Jun 25, 2026 at 6:53=E2=80=AFPM = Greg Mirsky <= gregimirsky@gmail.com> wrote:
Hi Rakesh,
Thank= you for your careful consideration of my notes and thoughtful updates. Ple= ase find my additional notes below, tagged GIM3>>.

Regards,
Greg

On Wed, Jun 24, 2026 at 6:33=E2=80=AFAM= Rakesh Gandhi <rgandhi.ietf@gmail.com> 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=E2=80=AFPM Gre= g Mirsky <gre= gimirsky@gmail.com> wrote:
Hi Will,
Thank you = for your thoughtful proposal. Please find my notes below, tagged GIM2>&g= t;.
=C2=A0
And I apol= ogize for coming back to my question about the figures that display example= s of STAMP test packets for Session-Sender and Session-Reflector. As define= d in RFC 8972, the Extra Padding TLV is used to make STAMP packets symmetri= cal. If that is also the case for the Reflected IPv6 Extension Header Data = STAMP TLV and the=C2=A0Fixed I= Pv6 Header Data TLV, it seems that the Extra Padding TLV must be reflected = in figures. WDYT?

= <RG2> Both Session-Sender and Sess= ion-Reflector test packets carry the same number of=C2=A0Reflected IPv6 Ext= ension Header Data STAMP and the=C2=A0Fixed IPv6 Header Data TLVs, making them symmetric in size, no?
GIM3>> Thank you for co= nfirming 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=C2=A0the difference in=C2=A0 len= gth between base and reflected packets.
GIM3>> Also, should= the document clarify whether the Session-Reflector must use information ot= her than the Type field value, in IPv6 Extension Header Data or Fixed Heade= r Data TLVs for sanity verification? If nothing of the kind, should the doc= ument state that all Value fields MUST be zeroed on transmission by the Ses= sion-Sender and ignored by the Session-Reflector on receipt?
=C2=A0

Regards,
= Greg

On Mon, Jun 22, 2026 at 8:04=E2=80=AFPM Will Hawkins <hawkinsw@obs.cr> wrote= :
On Mon, Jun 22= , 2026 at 9:19=E2=80=AFPM Greg Mirsky <gregimirsky@gmail.com> 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 fi= nd 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) o= f the document, as replied below <RG>...
>>>
>>> On Wed, Jun 10, 2026 at 8:53=E2=80=AFPM Greg Mirsky <gregimirsky@gmail.com<= /a>> 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 h= elpful to an implementer if it used the normative language rather than &quo= t;can", "does", and "does not".
>>>
>>>
>>> <RG> Updated where applicable.
>>
>> GIM>> Thank you
>>>
>>>
>>>>
>>>> I got confused by the labeling of the IPv6 extension heade= rs 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 Ses= sion-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.
>>>
>>>=C2=A0 =C2=A0 =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+------------------------------------------= ---------------------+
>>>=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 =C2=A0 =C2=A0+------------------------------------------= ---------------------+
>>>=C2=A0 =C2=A0 =C2=A0| IPv6 Extension 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 =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 =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+------------------------------------------= ---------------------+
>>>=C2=A0 =C2=A0 =C2=A0| Reflected IPv6 Extension Header-1 Data ST= AMP 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~
>>>=C2=A0 =C2=A0 =C2=A0+------------------------------------------= ---------------------+
>>>=C2=A0 =C2=A0 =C2=A0| Reflected IPv6 Extension Header-M Data ST= AMP TLV (TBA1)=C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>=C2=A0 =C2=A0 =C2=A0+------------------------------------------= ---------------------+
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Note: Value of M <=3D N
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2: Example Session-Sen= der and Session-Reflector Test
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet with Reflected IPv6 Ex= tension Header Data STAMP TLVs
>>
>> GIM>> Thank you for the figure, but I still wonder if the sc= enario 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 pa= cket with a single IPv6 header and multiple SRHs.

>> GIM>> And an additional question. What are actions of the Se= ssion-Reflector that received a STAMP packet with a IPv6 Extension Header C= ontrol Sub-TLV, but has no access to the extension headers (similar to Send= er'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'l= l
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.iet= f.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.

=C2=A0 =C2=A0If the Session-Reflector cannot add a new matching IPv6 = extension
=C2=A0 =C2=A0header in the Session-Reflector test packet, the = Session-Reflector
=C2=A0 =C2=A0MUST return the STAMP TLV with the C flag= (Conformance) set to 1 in
=C2=A0 =C2=A0the Sub-TLV Flags of the Sub-TLV= using the procedure defined in
=C2=A0 =C2=A0[I-D.ietf-ippm-asymmetrical= -pkts].=C2=A0 This can occur, for example, when
=C2=A0 =C2=A0the Session= -Reflector does not support the IPv6 extension header, or
=C2=A0 =C2= =A0when the Session-Reflector cannot access the received IPv6 extension
= =C2=A0 =C2=A0headers, etc.

GIM3>> Could you please clarify to which STAMP TLV and Su= b-TLV this applies?=C2=A0
=C2=A0
GIM2>> As I understand it (please correct me if I misu= nderstand it), the STAMP test packet transmitted by the Session-Sender incl= udes 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.=C2=A0

=C2=A0 =C2=A0When the Session-Reflector does not use the re= ceived "Reflected IPv6
=C2=A0 =C2=A0Extension Header Data" TLV= for reflecting the IPv6 extension header,
=C2=A0 =C2=A0the Session-Refl= ector MUST return the STAMP TLV with the U flag
=C2=A0 =C2=A0(Unrecogniz= ed TLV) set to 1 in the STAMP TLV Flags using the
=C2=A0 =C2=A0procedure= defined in [RFC8972].=C2=A0 This can occur, for example, if
=C2=A0 =C2= =A0there is a mismatch in the length between the received IPv6 extension=C2=A0 =C2=A0headers and the "Reflected IPv6 Extension Header Data&qu= ot; TLVs, or when
=C2=A0 =C2=A0the Session-Reflector cannot access th= e received IPv6 extension
=C2=A0 =C2=A0headers, etc.
GIM3>> I got confused when reading the= previous text and the one above. It seems to me that the case when the Ses= sion-Reflector doesn't have access to IPv6 extension headers, the Sessi= on-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?

=C2=A0
GIM2>> I looked once more at the text in Sectio= n 3.3:
=C2=A0 =C2=A0If not, the Session-Reflector MUST return both STA= MP TLVs
=C2=A0 =C2=A0with the C flag (Conformance) set to 1 in the STAMP= TLV Flags using
=C2= =A0 =C2=A0the procedure defined in [I-D.ietf-ippm-asymmetrical-pkts].=C2=A0
Based on my understanding of Figure 4,=C2=A0Reflected Fix= ed Header Data STAMP TLV already precedes the list of=C2=A0Reflected IPv6 E= xtension 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 fla= g to 1? Also, which TLVs are included in "both STAMP TLVs"?
=


<RG2> Revised the test as follows:

=C2=A0 =C2=A0The "Reflected Fixed Header Data&q= uot; TLVs MUST be added before adding
=C2=A0 =C2=A0the "Reflected I= Pv6 Extension Header Data" TLVs to maintain the same
=C2=A0 =C2=A0o= rder as the IP headers and IPv6 extension headers in the Session-
=C2=A0= =C2=A0Sender test packets. =C2=A0If the "Reflected Fixed Header Da= ta" TLVs and
=C2=A0 =C2=A0the "Reflected IPv6 Extension Header= Data" TLVs are not received in
=C2=A0 =C2=A0this order, the Se= ssion-Reflector MUST return these TLVs with the C
=C2=A0 =C2=A0flag (Con= formance) set to 1 in the STAMP TLV Flags using the
=C2=A0 =C2=A0procedu= re defined in [I-D.ietf-ippm-asymmetrical-pkts].
GIM3>> Thank you.=C2=A0
<= div>


=
=C2=A0
GIM2>> I returned to the las= t paragraph of Section 5.3:
=C2=A0 =C2=A0STAMP test packets MUST = NOT carry more than one "IPv6 Extension
=C2=A0 =C2=A0Header Control= " Sub-TLV in a "Reflected Test Packet Control" TLV.=C2=A0 If=
=C2=A0 =C2=A0a Session-Sender test packet contains more than one "= IPv6 Extension
=C2=A0 =C2=A0Header Control" Sub-TLV, the Session-Re= flector MUST return the STAMP
=C2=A0 =C2=A0TLV with the U flag (Unrecogn= ized TLV) set to 1 in the STAMP TLV
=C2=A0 =C2=A0Flags using the procedu= re defined in [RFC8972].
I couldn't figure out in which TLV i= n the reflected STAMP test packt the U flag must be set to 1. Could you ple= ase clarify it for me.

<RG2> Revised the tes= t as follows:

=C2=A0 =C2=A0STAM= P test packets MUST NOT carry more than one "IPv6 Extension
=C2=A0 = =C2=A0Header Control" Sub-TLV in a "Reflected Test Packet Control= " TLV.=C2=A0 If
=C2=A0 =C2=A0the "Reflected Test Packet Contro= l" TLV in the Session-Sender test
=C2=A0 =C2=A0packet contains more= than one "IPv6 Extension Header Control" Sub-
=C2=A0 =C2=A0TL= V, the Session-Reflector MUST return the "Reflected Test Packet
=C2= =A0 =C2=A0Control" TLV with the U flag (Unrecognized TLV) set to 1 in = the Sub-
=C2=A0 =C2=A0TLV Flags of all "IPv6 Extension Header Co= ntrol" Sub-TLVs, using the
=C2=A0 =C2=A0procedure defined in [R= FC8972].
GIM3>> Could i= t 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, bu= t finds that the Reflected Test Packet Control TLV includes more than one= =C2=A0IPv6 Extension Header Co= ntrol sub-TLV. In other word, construction of=C2=A0the Reflected Test Packet Control TLV is non-co= nformant to this specification. WDYT?
<= br>

Thanks,
Rakesh (for authors)



=C2=A0

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 &qu= ot;Reflected IPv6 Extension Header Data" STAMP TLV be presented as a s= eparate field for ease of reference and specification of the matching mecha= nism?
>>>
>>>
>>> <RG> Updated the Figure to show the field separately. >>>
>>>=C2=A0 =C2=A0 =C2=A00 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 =C2=A0 =C2=A0|STAMP TLV Flags|=C2=A0 Type=3DTBA1=C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Length=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 Requested 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=A0 = =C2=A0 =C2=A0 =C2=A0 Reflected 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=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 Figure 6: Refl= ected IPv6 Extension Header Data TLV
>>
>> GIM>> Thank you
>>>
>>>
>>>>
>>>> It seems that the following processing option can benefit = from the use of the normative language:
>>>>
>>>>=C2=A0 =C2=A0 If necessary, Reflected Data
>>>>=C2=A0 =C2=A0 STAMP TLVs can be removed to avoid violating = the IP MTU limit.
>>>>
>>>> And I find the suggestion somewhat ambiguous. Should all R= eflected IPv6 Extension Header Data STAMP TLVs be removed from the reflecte= d STAMP packet, or only as many as necessary to conform to the IP MTU of th= e Reflector's egress interface?
>>>
>>>
>>> <RG> Updated to:
>>>
>>>=C2=A0 =C2=A0 The Session-Sender and Session-Reflector MUST ens= ure that the
>>>=C2=A0 =C2=A0 resulting 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=A0 or more "Reflected IPv6 Extension Header Dat= a" STAMP TLVs MUST be
>>>=C2=A0 =C2=A0 removed to avoid violating the IPv6 MTU limit. >>
>> GIM>> Excellent, thanks!
>>>
>>>
>>>
>>>>
>>>> MUST NOT in the following text seems too restrictive:
>>>>
>>>>=C2=A0 =C2=A0 IOAM Direct Exporting (DEX) [RFC9326] is appl= icable with STAMP test
>>>>=C2=A0 =C2=A0 packets for on-path telemetry use cases
>>>>=C2=A0 =C2=A0 [I-D.ietf-ippm-on-path-active-measurements].= =C2=A0 In this case, the
>>>>=C2=A0 =C2=A0 Session-Reflector does not reflect IOAM data = fields since no IOAM
>>>>=C2=A0 =C2=A0 data is recorded in the STAMP test packets.= =C2=A0 Hence, the Session-
>>>>=C2=A0 =C2=A0 Sender MUST NOT include a corresponding "= ;Reflected IPv6 Extension
>>>>=C2=A0 =C2=A0 Header Data" STAMP TLV in the Session-Se= nder test packets for the
>>>>=C2=A0 =C2=A0 IOAM DEX option-type.
>>>>
>>>> I think there could be other valid motivations to use the = "Reflected IPv6 Extension Header Data" STAMP TLV. Perhaps softeni= ng 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 use= d in combination with Reflected Fixed Header Data STAMP TLV? What are the r= ules that govern such a scenario?
>>>
>>>
>>> <RG> Added following text:
>>>
>>>=C2=A0 =C2=A0 STAMP test packets can be used to reflect both IP= v6 extension headers
>>>=C2=A0 =C2=A0 and IP headers by carrying the corresponding &quo= t;Reflected IPv6
>>>=C2=A0 =C2=A0 Extension Header Data" and "Reflected F= ixed Header Data" STAMP TLVs
>>>=C2=A0 =C2=A0 as shown in Figure 4.
>>>
>>>=C2=A0 =C2=A0 The "Reflected Fixed Header Data" STAMP= TLV MUST be added before
>>>=C2=A0 =C2=A0 adding the "Reflected IPv6 Extension Header = Data" STAMP TLVs to
>>>=C2=A0 =C2=A0 maintain the same order as the IP headers and ext= ension headers in
>>>=C2=A0 =C2=A0 the STAMP test packets.=C2=A0 If not, the Session= -Reflector MUST return
>>>=C2=A0 =C2=A0 both STAMP TLVs with the C flag (Conformance) set= to 1 in the STAMP
>>>=C2=A0 =C2=A0 TLV Flags using the procedure defined in
>>>=C2=A0 =C2=A0 [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:
>>>
>>>=C2=A0 =C2=A0 This document defines the "IPv6 Extension He= ader Control" Sub-TLV
>>>=C2=A0 =C2=A0 (Type TBA3) for the "Reflected Test Packet C= ontrol" STAMP TLV (Type
>>>=C2=A0 =C2=A0 12) introduced in [I-D.ietf-ippm-asymmetrical-pkt= s].=C2=A0 The format of
>>>=C2=A0 =C2=A0 "IPv6 Extension Header Control" Sub-TLV= is shown in Figure 8.
>>>
>>>=C2=A0 =C2=A0 =C2=A00 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 =C2=A0 =C2=A0| Sub-TLV Flags |=C2=A0 Type =3D TBA3=C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sub-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 =C2=A0 =C2=A0Figure 8= : IPv6 Extension Header Control Sub-TLV
>>>
>>>=C2=A0 =C2=A0 The Sub-TLV fields are defined as follows:
>>>
>>>=C2=A0 =C2=A0 Type: Sub-TLV Type (value TBA3).
>>>
>>>=C2=A0 =C2=A0 Sub-TLV Flags: The Sub-TLV Flags follow the proce= dure for STAMP TLV
>>>=C2=A0 =C2=A0 Flags described in [RFC8972].
>>>
>>>=C2=A0 =C2=A0 Sub-TLV Length: A two-octet field equal to the le= ngth of the Data in
>>>=C2=A0 =C2=A0 octets.=C2=A0 It is set to 0.
>>>
>>>=C2=A0 =C2=A0 When a Session-Sender test packet is received wit= h the "IPv6
>>>=C2=A0 =C2=A0 Extension Header Control" Sub-TLV, the Sessi= on-Reflector MUST add
>>>=C2=A0 =C2=A0 matching IPv6 extension headers in the Session-Re= flector STAMP test
>>>=C2=A0 =C2=A0 packet corresponding to the received IPv6 extensi= on headers (except
>>>=C2=A0 =C2=A0 the routing extension headers specific to the Ses= sion-Sender test
>>>=C2=A0 =C2=A0 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=E2=80=AFAM Marcus Ihlar via Da= tatracker <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=A0 The Simple Two-Way Active Measurement Pro= tocol (STAMP) and its
>>>>>=C2=A0 =C2=A0 optional extensions can be used for Edge-= to-Edge (E2E) active
>>>>>=C2=A0 =C2=A0 measurement.=C2=A0 In Situ Operations, Ad= ministration, and Maintenance
>>>>>=C2=A0 =C2=A0 (IOAM) data fields can be used for record= ing and collecting Hop-by-
>>>>>=C2=A0 =C2=A0 Hop (HBH) and E2E operational and telemet= ry information.=C2=A0 This
>>>>>=C2=A0 =C2=A0 document extends STAMP to reflect IP head= ers as well as IPv6
>>>>>=C2=A0 =C2=A0 extension headers for HBH and E2E active = measurements, for example,
>>>>>=C2=A0 =C2=A0 using IOAM data fields.
>>>>>
>>>>> File can be retrieved from:
>>>>>
>>>>> Please review and indicate your support or objection t= o proceed with the
>>>>> publication of this document by replying to this email= keeping ippm@ietf.org
>>>>> in copy. Objections should be explained and suggestion= s 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 conforma= nce 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 IE= TF IPR Policy can be
>>>>> found at [3].
>>>>>
>>>>> Thank you.
>>>>>
>>>>> [1] https://datatracker.ietf.org/doc/bcp= 78/
>>>>> [2] https://datatracker.ietf.org/doc/bcp= 79/
>>>>> [3] https://datatracker.ietf.org/doc/r= fc6701/
>>>>>
>>>>> The IETF datatracker status page for this Internet-Dra= ft is:
>>>>> https://datatrac= ker.ietf.org/doc/draft-ietf-ippm-stamp-ext-hdr/
>>>>>
>>>>> There is also an HTMLized version available at:
>>>>> https://d= atatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-ext-hdr-08
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> h= ttps://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
--00000000000037de9a0655dd8d60--