Hi Alvaro, Thank you for looking into this.
Please see replies inline with <RG>.. On Thu, Aug 13, 2026 at 3:25 PM Alvaro Retana <[email protected]> wrote: > 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. > <RG> Great, thanks! > > 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? > <RG> One-way uses the RFC9503 extension with SR-MPLS encapsulation. <RG> Loopback is specific to how STAMP packet is encapsulated for SR-MPLS where the packet is not processed on the STAMP reflector, it is a local mode of operation on STAMP sender. <RG> Draft explains how these are achieved for SR-MPLS. > > 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? > <RG> Right, the Network action opcode and semantics are locally configured and not signalled or registered. Thanks, Rakesh (for authors) > > 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]
