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]
