[ippm] Re: [pm-dir] Re: draft-ietf-ippm-stamp-ext-hdr-08 early Perfmetrdir review

[Rakesh Gandhi <[e-mail]>]

Thank you Xiao Min for the further review.

Please see replies inline with <RG2>...

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


Secondly, if it's copied from the received IPv6 extension header, it likely
doesn't work. Take IOAM Pre-allocated Trace Option extension header as an
example, the needed extension header size for the forward direction and that
for the reverse direction are usually different, so simply copying the
received
extension header doesn't work.


<RG> Often, any ingress node sending the packet doesn't know the number of
hops to reach the egress node.
<RG> IOAM pre-allocated trace option extension header would be, for
example, configured with a fixed maximum size of say 13 hops on both ends,
irrespective of actual number of hops the packets may take.
[XM]>>> If that's the case, then how can the Session-Sender determine which
part of the received IOAM data within the IPv6 extension header is for the
reverse path and which part is for the forward path?

<RG2> The forward direction IOAM data is copied from the IPv6 extension
header into STAMP TLV on Reflector.
<RG2> New matching IPv6 extension header is added in the packet for the
reverse direction on Reflector.


<snip>


Considering there are many extension headers
defined for IPv6, if this document does require the Session-Reflector to add
the matching IPv6 extension header, then each defined IPv6 extension header
needs to be checked respectively.


<RG> Yes, in the two-way measurement, both sides need to support the
extension header, e.g. IOAM pre-allocated trace option.
[XM]>>> I agree the premise is that both sides need to support the
extension header. My concern is that simply copy the received IPv6
extension header at the Session-Reflector may lead to wrong data reflected
to the Session-Sender. As I recall it, there is an IPv6 extension header
which can record the path MTU, if the Session-Reflector simply copy the
path MTU for the forward path into the Session-Reflector test packets, then
the Session-Sender may receive a wrong path MTU it take for granted that
it's the path MTU for the reverse path but it's really the path MTU for the
forward path.

<RG2> Please see the reply for the previous comment with RG2.


<snip>



* Section 3.2 says
   "When adding multiple IP headers in the Session-Sender test packet,
   multiple corresponding "Reflected Fixed Header Data" TLVs are added,
   each one with the matching length to the IP header and in the same
   order."
It's not clear to me why the multiple IP headers scenario needs to be
included.
To my understanding, the midpoint nodes can only process the outermost IP
header, if that's the case, then how can the Session-Sender expect to
receive a
modified IP header back if it's not the outermost one?


<RG> STAMP packet can be encapsulated with IPinIP or GRE tunnel (with outer
IP header) or SRv6 uSIDs (as a DA in outer IPv6 header), etc.
<RG> Reflector would reflect all of the received IP headers.
[XM]>>> I know that STAMP packets can be encapsulated with multiple IP
headers. My concern is why the Session-Reflector is required to reflect all
the IP headers but not just the outermost IP header, IMHO this requirement
makes the Session-Reflector more complex and error-prone, however the
benefit is not clear.

<RG2> The STAMP extension allows for multiple headers, but the Sender can
only add one STAMP TLV to get only the outer header. Agree, this would be
the norm.
<RG2> It is useful to know at the Sender what was the header transmitted
and what was received at the reflector after the packet got encapsulated.
Anyway, this is optional.

Thanks,
Rakesh



Cheers,
Xiao Min





On Thu, Jun 18, 2026 at 5:30 AM <[e-mail]> wrote:

> Hi Rakesh,
>
> Thanks for the prompt response.
> Most of the resolutions look good to me.
> Please see inline for the remaining ones.
> Original
> *From: *RakeshGandhi <[e-mail]>
> *To: *肖敏10093570;
> *Cc: *[e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>;[e-mail] <[e-mail]>;
> *Date: *2026年06月18日 02:37
> *Subject: **[pm-dir] Re: [ippm] draft-ietf-ippm-stamp-ext-hdr-08 early
> Perfmetrdir review*
> _______________________________________________
> pm-dir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Hi Xiao Min,
>
> Thank you for the perfmetrdir review.
>
> We have addressed your comments in the working copy (rev-09) of the
> document, as replied below <RG>...
>
>
> On Wed, Jun 17, 2026 at 4:35 AM Xiao Min via Datatracker <[e-mail]>
> wrote:
>
>> Document: draft-ietf-ippm-stamp-ext-hdr
>> Title: Simple Two-Way Active Measurement Protocol (STAMP) Extensions for
>> Reflecting STAMP Packet IP Headers Reviewer: Xiao Min Review result: Has
>> Issues
>>
>> Hi,
>>
>> I I have been selected as the Performance Metrics Directorate
>> (perfmetrdir)
>> reviewer for this Internet-Draft. The Performance Metrics Directorate
>> assists
>> the OPS Area Directors, Chairs, and ADs, to review performance-related
>> documents. This is an early review requested by the WG chairs.
>>
>> The Performance Metrics Directorate will be applying the Guidelines for
>> Considering New Performance Metric Development, RFC 6390.
>>
>> - Document: draft-ietf-ippm-stamp-ext-hdr-08
>>
>> - Reviewer: Xiao Min
>>
>> - Review Date: Jun 17, 2026
>>
>> - Intended Status: Standards Track
>>
>> ---
>>
>> ## Summary
>>
>> I have some minor concerns about this document that I think should be
>> resolved
>> before publication.
>>
>> ## Minor Issues
>>
>> * Section 1 says
>>    "Currently, there is
>>    no adopted method defined to reflect the collected IOAM data fields
>>    back to the Sender, where the Sender can use that information to
>>    support the hop-by-hop and edge-to-edge measurement use cases."
>> However as I know, draft-ietf-6man-icmpv6-reflection (in RFC Editor's
>> Queue) is
>> an adopted method defined to reflect the collected IOAM data fields back
>> to the
>> Sender.
>>
>
> <RG> Updated to:
>
>
>
>
>
>
> *   In Situ Operations, Administration, and Maintenance (IOAM) is used
>  for recording and collecting operational and telemetry information   while
> the packet traverses a path between two points in the network.   The IOAM
> data fields are defined in [RFC9197].  The information from   the collected
> IOAM data fields can be used to support Hop-by-Hop   (HBH) and Edge-to-Edge
> (E2E) measurement use cases.*
>
>
>
>>
>> * Section 3.1 says
>>    "The Session-Reflector adds the matching IPv6 extension header in the
>>    IPv6 header of the Session-Reflector test packets in the same order
>>    for the reverse direction measurements, as described in Section 5.3."
>>
>
>
>> It's not clear to me how the Session-Reflector adds the matching IPv6
>> extension
>> header in the IPv6 header. Firstly, the IPv6 header has a fixed length of
>> 40
>> bytes as specified in RFC 8200, the IPv6 extension header can't be added
>> to it.
>>
>
> <RG> Updated to:
>
>
>
>
> *   In the two-way measurement type, the Session-Reflector adds the
>  matching IPv6 extension headers in the Session-Reflector test packets   in
> the same order as received in the Session-Sender test packets for   the
> reverse direction measurement.*
>
>
>
>> Secondly, if it's copied from the received IPv6 extension header, it
>> likely
>> doesn't work. Take IOAM Pre-allocated Trace Option extension header as an
>> example, the needed extension header size for the forward direction and
>> that
>> for the reverse direction are usually different, so simply copying the
>> received
>> extension header doesn't work.
>
>
> <RG> Often, any ingress node sending the packet doesn't know the number of
> hops to reach the egress node.
> <RG> IOAM pre-allocated trace option extension header would be, for
> example, configured with a fixed maximum size of say 13 hops on both ends,
> irrespective of actual number of hops the packets may take.
> [XM]>>> If that's the case, then how can the Session-Sender determine
> which part of the received IOAM data within the IPv6 extension header is
> for the reverse path and which part is for the forward path?
>
>
>> Considering there are many extension headers
>> defined for IPv6, if this document does require the Session-Reflector to
>> add
>> the matching IPv6 extension header, then each defined IPv6 extension
>> header
>> needs to be checked respectively.
>
>
> <RG> Yes, in the two-way measurement, both sides need to support the
> extension header, e.g. IOAM pre-allocated trace option.
> [XM]>>> I agree the premise is that both sides need to support the
> extension header. My concern is that simply copy the received IPv6
> extension header at the Session-Reflector may lead to wrong data reflected
> to the Session-Sender. As I recall it, there is an IPv6 extension header
> which can record the path MTU, if the Session-Reflector simply copy the
> path MTU for the forward path into the Session-Reflector test packets, then
> the Session-Sender may receive a wrong path MTU it take for granted that
> it's the path MTU for the reverse path but it's really the path MTU for the
> forward path.
>
>
>> Thirdly, it's not specified that if the
>> Session-Reflector doesn't support adding the received IPv6 extension
>> headers,
>> then how the Session-Reflector behaves.
>>
>
> <RG> Updated the procedure as follows:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *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).   In the
> absence of this Sub-TLV in the received Session-Sender test   packet, the
> Session-Reflector MUST NOT add matching IPv6 extension   headers
> corresponding to the received IPv6 extension headers in the
>  Session-Reflector test packet.   If for any reason, the Session-Reflector
> cannot add a matching IPv6   extension header in Session-Reflector test
> packets, 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].*
>
>
>
>
>>
>> * Section 3.2 says
>>    "When adding multiple IP headers in the Session-Sender test packet,
>>    multiple corresponding "Reflected Fixed Header Data" TLVs are added,
>>    each one with the matching length to the IP header and in the same
>>    order."
>> It's not clear to me why the multiple IP headers scenario needs to be
>> included.
>> To my understanding, the midpoint nodes can only process the outermost IP
>> header, if that's the case, then how can the Session-Sender expect to
>> receive a
>> modified IP header back if it's not the outermost one?
>>
>
> <RG> STAMP packet can be encapsulated with IPinIP or GRE tunnel (with
> outer IP header) or SRv6 uSIDs (as a DA in outer IPv6 header), etc.
> <RG> Reflector would reflect all of the received IP headers.
> [XM]>>> I know that STAMP packets can be encapsulated with multiple IP
> headers. My concern is why the Session-Reflector is required to reflect all
> the IP headers but not just the outermost IP header, IMHO this requirement
> makes the Session-Reflector more complex and error-prone, however the
> benefit is not clear.
>
> Cheers,
> Xiao Min
>
>
>> ## Nits
>>
>> Section 1, suggest to change "performance delay and packet loss" to
>> "performance metrics, like delay, delay variation, and packet loss" as
>> described in Abstract of RFC 8762.
>>
>
> <RG> Updated.
>
>
>>
>> Section 2.2, it seems DEX and PDM should also be included.
>>
>
> <RG> Updated. Removed the PDM acronym that was not used.
>
>
>>
>> Section 3.1, it says
>>    "When a STAMP Session-
>>    Sender adds an IPv6 extension header, such as an IPv6 Hop-by-Hop
>>    options header or a Destination options header in the IPv6 header
>>    [RFC8200]......"
>> However RFC 8200 defines IPv6 header as a fixed-length header, which
>> means IPv6
>> extension header can't be added in the IPv6 header.
>>
>
> <RG> Fixed as above.
>
>
>>
>> Section 3.1, it should be clarified that within "starting from the Next
>> Header
>> field" the Next Header field means the first field of an IPv6 extension
>> header,
>> but not the Next Header field among the IPv6 header.
>>
>
> <RG> Updated.
>
>
>>
>> Section 3.1, in Figure 2, the numbers for the outer extension headers are
>> from
>> 1 to N and the numbers for the inner extension headers are from K to L,
>> however
>> the numbers for the STAMP TLVs are from 1 to M, what's the relationship
>> of the
>> numbers?
>>
>
> <RG> Updated the Figure to remove outer/inner header as:
>
>     +---------------------------------------------------------------+
>     | IPv6 Header                                                   |
>     +---------------------------------------------------------------+
>     | IPv6 Extension Header-1 RFC 8200                              |
>     +---------------------------------------------------------------+
>     ~ ...                                                           ~
>     +---------------------------------------------------------------+
>     | IPv6 Extension Header-N RFC 8200                              |
>     +---------------------------------------------------------------+
>     | UDP Header                                                    |
>     +---------------------------------------------------------------+
>     | STAMP Packet RFC 8972                                         |
>     +---------------------------------------------------------------+
>     | Reflected IPv6 Extension Header-1 Data STAMP TLV (TBA1)       |
>     +---------------------------------------------------------------+
>     ~ ...                                                           ~
>     +---------------------------------------------------------------+
>     | Reflected IPv6 Extension Header-M Data STAMP TLV (TBA1)       |
>     +---------------------------------------------------------------+
>
>       Note: Value of M <= N
>
>         Figure 2: Example Session-Sender and Session-Reflector Test
>         Packet with Reflected IPv6 Extension Header Data STAMP TLVs
>
>
>>
>> Sections 3.1 and 3.2, s/in the Session-Reflector payload/in the
>> Session-Reflector test packet payload.
>>
>
> <RG> Fixed.
>
>
>>
>> Section 3.2, s/"Reflected Fixed Header Data,"/"Reflected Fixed Header
>> Data",.
>>
>
> <RG> Fixed.
>
>
>>
>> Section 4, it says "......process the IOAM data fields as defined in
>> [RFC9486]", it seems RFC 9197 defines how to process the IOAM data
>> fields, so
>> suggest adding [RFC9197] or replacing [RFC9486] with [RFC9197].
>>
>
> <RG> Fixed.
>
>
>>
>> Section 5.1, it says "the corresponding IPv6 extension header in the IPv6
>> header", as said above, the IPv6 extension header can't be in the IPv6
>> header.
>>
>
> <RG> Fixed as above.
>
>
>>
>> Section 5.2, it says "STAMP test packets may carry multiple TLVs of this
>> type",
>> as said above, suggest to allow only one TLV of this type unless there is
>> real
>> scenario to reflect multiple IP headers.
>>
>
> <RG> Replied as above.
>
>
>>
>> Section 5.3, it says "the Session-Reflector does not add the received IPv6
>> extension headers in the IPv6 header ", as said above, the IPv6 extension
>> header can't be in the IPv6 header.
>>
>
> <RG> Fixed as above.
>
> Thanks,
> Rakesh (for authors)
>
>
>
>>
>> _______________________________________________
>> ippm mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>