Dear SPRING WG and the draft authors, When preparing the review and the shepherd writeup, I noticed the current requested document type is “informational”. Based on the evaluation of the document content, a better fit for the requested type may be “proposed standard”. I raised this issue for further discussion.
Here’s the reason to support the standard type: the document describes standard procedures and protocol extensions for using STAMP over SR-MPLS networks. It specifies control and data plane interactions, encapsulation methods, and interoperability mechanisms that require standardization to ensure consistent implementations across different vendor hardware. Protocol extensions designed for widespread implementation and interoperability belong on the standards track. I think we need to resolve this issue before moving forward. Thanks! Best regards, Haoyu From: Haoyu Song Sent: Tuesday, July 28, 2026 4:33 PM To: SPRING WG <[email protected]>; '[email protected]' <[email protected]> Subject: shepherd review of draft-ietf-spring-stamp-srpm-mpls Hi SPRING WG and the authors of the draft, I’m the assigned shepherd of this draft. As a part of the procedure, I have read the draft and the related work, and provide the review below. The draft introduces the operational procedures for network performance measurement using the Simple Two-Way Active Measurement Protocol (STAMP) over Segment Routing with MPLS data plane (SR-MPLS) networks. The core objective of this document is to address the scalability limitations of the traditional STAMP protocol, and introduces the following new mechanisms and measurement modes: two-way measurement mode, one-way measurement mode, loopback measurement mode, loopback measurement mode with timestamp and forward. The last mode leverages the MPLS MNA mechanism. The proposed methods are fully compatible with RFC8762, 8972, 9503, and 9994. It fully reuses the reference model of STAMP, and provides non-disruptive protocol extensions. It fits in SR-MPLS data plane with MNA capability. The protocol design is rigorous. It leverages existing standard mechanisms to implement its extended functionalities. Provided that network devices explicitly support the new modes defined in this document, it can operate seamlessly and be compatible with existing SR, MPLS, and IP infrastructures. This document strictly adheres to the formatting and structural requirements of an Internet Draft and a future RFC. Below are a few text editing suggestions the authors may consider in a future revision. * Consistency of abbreviation and terminology：timestamp and forward. In some places, the usage is “timestamp and forward” in parentheses, but some other places it becomes Timestamp and Forward. In Sec. 7.1.1, it’s further specified as Timestamp and Forward Network Action. It’s suggested to use the specified abbreviation in Sec 2.2 (e.g., TSF) consistently throughout the draft. * In Sec. 3. “Note that the two-way measurement mode is referenced in the STAMP process in [RFC8762] and is further described for SR-MPLS networks in this document. The other measurement modes, which are new and specifically described for SR-MPLS networks in this document, are not defined by the STAMP process in [RFC8762].” This sentence has several repeated clauses and appears redundant. The authors may consider to rewrite it to make it more succinct. For example, “The other measurement modes are new, specific to SR-MPLS networks, and not defined in [RFC8762].” * Sec 6.1. “The Session-Reflector does not perform the STAMP process, as the loopback function simply processes the encapsulation including the IP and MPLS headers (but does not process the UDP header) to forward the received Session-Sender test packet to the Session-Sender without STAMP modifications, as defined in [RFC8762].” The long sentence is hard to read. Suggested text: “The Session-Reflector does not perform the STAMP process. Instead, its loopback function simply processes the IP and MPLS headers (ignoring the UDP header) to forward the test packet back to the Session-Sender without any STAMP modifications [RFC8762]." * In Sec. 11. “The threshold-based notification for delay and packet loss metrics is not generated if the delay and packet loss metrics do not change significantly.” The double-negative sentence is a little awkward and redundant. Suggested text: “The threshold-based notification for delay and packet loss metrics is generated only when the metrics change significantly.” Other than these, I think the draft is in good shape and ready for the next step. Best regards, Haoyu
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
