Hi Greg, Thank you for the careful review.
Please see replies inline with <RG>… - The document, as I understand it, suggests that STAMP-Reflector is required to process received STAMP-Test packets in the control plane: STAMP requires protocol support on the Session-Reflector to process the received test packets. As a result, the received test packets need to be punted from the fast path in the data plane for control- plane processing, and return test packets need to be generated. This limits the frequency of STAMP test packets and the ability to provide shorter measurement intervals. I cannot find that requirement in either the STAMP base specification or in any document that defines STAMP extensions. True, STAMP-Reflector may process received STAMP-Test packets in the control plane, but you can also achieve that as a bump-in-the-wire in the forwarding plane. <RG> STAMP packet carrying IP/UDP header requires Session-Reflector to process the UDP header where the STAMP UDP port is subject to the security threats, rate limiting, and operational considerations and follow an exception path. <RG> We can update as follows: *STAMP requires protocol support as specified in [RFC8762] on the* * Session-Reflector to process the received STAMP-Test packets,* * including optional TLVs specified in [RFC8972], and to generate* * Session-Reflector test packets as well as reflect received TLVs. In* * addition, use of the UDP port in STAMP-Test packets exposes the* * Session-Reflector to security threats and requires rate limiting and* * operational considerations. These requirements necessitate that* * STAMP-Test packets follow an exception path (e.g., be punted from the* * IP- or MPLS-forwarding fast path). This results in limiting the* * frequency of STAMP-Test packets and the ability to provide shorter* * measurement intervals.* The manner in which processing is performed is, in my opinion, an implementation detail, an internal behavior that may be reported similarly to reporting the source of the timestamp at the STAMP-Reflector using the Timestamp Information TLV (RFC 8972 <https://datatracker.ietf.org/doc/rfc8972/>) or an extension to LSP Ping based on the STAMP Test session bootstrapping mechanism described in draft-ietf-mpls-stamp <https://datatracker.ietf.org/doc/draft-ietf-mpls-stamp/>. <RG> This document uses the extension defined in the RFC9503 for SR-MPLS return path. - https://www.rfc-editor.org/info/rfc9503/ - I have a question about the conclusion that STAMP cannot be used to measure a round-trip delay: This mode can compute one-way and two-way delay metrics, but it cannot compute the round-trip delay metric defined in [RFC2681]. According to RFC 2681 <https://www.rfc-editor.org/info/rfc2681/>, Type-P-Round-trip-Delay is measured as: dT<< means that Src sent the first bit of a Type-P packet to Dst at wire-time* T, that Dst received that packet, *then immediately sent a Type-P packet back to Src, *and that Src received the last bit of that packet at wire-time T+dT. It is not clear to me what prevents using STAMP to measure the round-trip delay. Could you please clarify? <RG> For one-way [T2-T1], two-way [(T4-T1)-(T3-T2)] and round-trip [T4-T1] delay definitions, please refer to https://www.rfc-editor.org/info/rfc6374/#section-2.4 <RG> Loopback mode helps computing round-trip delay by immediately IP or MPLS forwarding the packet just like on a transit node as defined in [RFC2681]. <RG> We can update as follows: * As defined in [RFC2681], round-trip delay measurement requires the* * destination to immediately send the packet back to the source. STAMP* * does not provide an accurate measurement of the round-trip delay,* * defined as (T4 - T1) in Section 2.4 of [RFC6374], because of the* * STAMP-Test packet processing time at the Session-Reflector. This* * processing includes handling the UDP header in the exception path,* * generating STAMP-Test packets, and reflecting optional TLVs.* - As noted above, the loopback modes introduced in this draft don't seem to benefit STAMP and are internal to a particular implementation of the STAMP-Reflector function. <RG> Loopback mode eliminates STAMP packet and UDP header processing on the Session-Reflector with the motivations described in the draft. <RG> FWIW, there is a precedence in RFC9779 where the loopback mode is defined for SR-MPLS PM. This draft defines that for STAMP. - https://www.rfc-editor.org/info/rfc9779/#name-loopback-measurement-mode - The mechanism proposed in draft-ietf-spring-stamp-srpm-mpls to control the path of a reflected STAMP packet seems burdensome. I assume that an operator is intended to use the same path for the reflected packets for the duration of the STAMP-Test session. If so, using the STAMP-Test session bootstrapping mechanism to control the path for reflected STAMP-Test packets seems reasonable (analogous to the mechanism for the reverse BFD defined in RFC 9612 <https://datatracker.ietf.org/doc/rfc9612/>). <RG> This document uses the extensions defined in RFC9503 for SR-MPLS return paths for STAMP. Similar to RFC9779 for SR-MPLS PM using return path. - https://www.rfc-editor.org/info/rfc9503/ - On Section 5, note that "near-end delay (forward direction), and far-end delay (backward direction)" are instances of one-way delay, and their combination is the round-trip delay. <RG> You mean as (T2-T1) + (T4-T3) - this is not round-trip delay which is defined as (T4- T1) in Section 2.4 of RFC6374. <RG> This is two-way delay metric [(T4-T1)-(T3-T2)] defined in Section 2.4 of RFC6374: https://www.rfc-editor.org/info/rfc6374/#section-2.4 - Section 5.1 suggests that A different destination UDP port number can be selected for one-way measurement mode instead of the UDP port number used by the Session- Reflector for two-way measurement mode. I think that requires more detailed specification, i.e., the range of port numbers that can be used. RFC 8762 <https://datatracker.ietf.org/doc/rfc8762/> does allow port numbers other than UDP port 862, but with some precautions. <RG> Right, we can update as follows: *The UDP port number must be chosen from the Dynamic Ports range (49152-65535) [RFC6335] to avoid conflicts with well-known and registered service ports.* - The document uses the term "loopback function" extensively. I couldn't find its interpretation in this document being defined, so I looked for the interpretation of the "loopback address" instead: A loopback address is a special IP address that a computer or network device uses to send data back to itself. So, I assume the loopback function sends a packet internally, without transmitting it on the wire, which contradicts the behavior described in the draft. <RG> “loopback function" is present at one place in the document (in Section 5.2). Will change it to loopback mode. - Aside from defining the new MNA opcodes, I don't see anything in the draft that requires switching to the Standard track. It might be viewed as a report on implementation choices. <RG> There is a precedence in RFC9779 for SR-MPLS PM which is standards track. - https://www.rfc-editor.org/info/rfc9779/#section-4.2 <RG> This draft also requests IANA allocated codepoints (IETF review) typical for a standards track document. Thanks, Rakesh (for authors) On Tue, Oct 6, 2026 at 1:59 PM Greg Mirsky <[email protected]> wrote: > Dear All, > Following the discussion on the intended track > for draft-ietf-spring-stamp-srpm-mpls, I read the latest version > <https://datatracker.ietf.org/doc/draft-ietf-spring-stamp-srpm-mpls/10/>. > Below, please find my notes: > > - The document, as I understand it, suggests that STAMP-Reflector is > required to process received STAMP-Test packets in the control plane: > > STAMP requires protocol support on the Session-Reflector to process > the received test packets. As a result, the received test packets > need to be punted from the fast path in the data plane for control- > plane processing, and return test packets need to be generated. This > limits the frequency of STAMP test packets and the ability to provide > shorter measurement intervals. > > I cannot find that requirement in either the STAMP base specification or > in any document that defines STAMP extensions. True, STAMP-Reflector may > process received STAMP-Test packets in the control plane, but you can also > achieve that as a bump-in-the-wire in the forwarding plane. The manner in > which processing is performed is, in my opinion, an implementation detail, > an internal behavior that may be reported similarly to reporting the source > of the timestamp at the STAMP-Reflector using the Timestamp Information TLV > (RFC 8972 <https://datatracker.ietf.org/doc/rfc8972/>) or an extension to > LSP Ping based on the STAMP Test session bootstrapping mechanism described > in draft-ietf-mpls-stamp > <https://datatracker.ietf.org/doc/draft-ietf-mpls-stamp/>. > > > - I have a question about the conclusion that STAMP cannot be used to > measure a round-trip delay: > > This mode can compute one-way and two-way delay metrics, but it > cannot compute the round-trip delay metric defined in [RFC2681]. > According to RFC 2681 <https://www.rfc-editor.org/info/rfc2681/>, > Type-P-Round-trip-Delay > is measured as: > dT<< means that Src sent the first bit of a Type-P packet to > Dst at wire-time* T, that Dst received that packet, then immediately > sent a Type-P packet back to Src, and that Src received the last bit > of that packet at wire-time T+dT. > It is not clear to me what prevents using STAMP to measure the round-trip > delay. Could you please clarify? > > > - As noted above, the loopback modes introduced in this draft don't > seem to benefit STAMP and are internal to a particular implementation of > the STAMP-Reflector function. > - The mechanism proposed in draft-ietf-spring-stamp-srpm-mpls to > control the path of a reflected STAMP packet seems burdensome. I assume > that an operator is intended to use the same path for the reflected packets > for the duration of the STAMP-Test session. If so, using the STAMP-Test > session bootstrapping mechanism to control the path for reflected > STAMP-Test packets seems reasonable (analogous to the mechanism for the > reverse BFD defined in RFC 9612 > <https://datatracker.ietf.org/doc/rfc9612/>). > - On Section 5, note that "near-end delay (forward direction), and > far-end delay (backward direction)" are instances of one-way delay, and > their combination is the round-trip delay. > - Section 5.1 suggests that > > A different destination UDP port number can be selected for one-way > measurement mode instead of the UDP port number used by the Session- > Reflector for two-way measurement mode. > I think that requires more detailed specification, i.e., the range of port > numbers that can be used. RFC 8762 > <https://datatracker.ietf.org/doc/rfc8762/> does allow port numbers other > than UDP port 862, but with some precautions. > > > - The document uses the term "loopback function" extensively. I > couldn't find its interpretation in this document being defined, so I > looked for the interpretation of the "loopback address" instead: > > A loopback address is a special IP address that a computer or network > device uses to send data back to itself. > > So, I assume the loopback function sends a packet internally, without > transmitting it on the wire, which contradicts the behavior described in > the draft. > > > - Aside from defining the new MNA opcodes, I don't see anything in the > draft that requires switching to the Standard track. It might be viewed as > a report on implementation choices. > > Regards, > Greg > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
