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]
