Haoyu/Rakesh: Hi!
I took a good look at the document and could be convinced that it belongs in the Standard Track because of the SR-MPLS-specific procedures being defined. The opinion of the WG is what counts here, so I can start a poll to see if there are any objections to changing the status. I have a couple of questions/concerns first: 1- Are the one-way and loopback modes intended to become additions to the STAMP protocol itself, or are they SR-MPLS-specific profiles? IOW, can they be generalized? 2- In section 7.1, a new network action (MNA.TSF) is defined. The spring WG is not chartered to define extensions. Aside from the definition, its use is unclear because you say it falls within the private use range in the registry. In other words, it is not registered. Some interoperability-related questions come up: How does a sender determine whether a reflector supports it? Is it actually interoperable, or locally configured? Thanks! Alvaro. On August 4, 2026 at 8:14:29 AM, Rakesh Gandhi ([email protected]) wrote: 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]
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
