Hi Haoyu, SPRING WG, Yes, as a co-author, I agree that the document fits better with the standards track, given the procedure and protocol extensions defined in the document for interoperability.
Thanks, Rakesh On Wed, Jul 29, 2026 at 2:57 PM Haoyu Song <haoyu.song= [email protected]> wrote: > 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] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
