Dear Authors, et al. Thank you for your work on this specification. Please find my notes on the draft below. As the draft, as I believe, defines new performance metrics, I invite the BPM WG and the Performance Directorate to the discussion. My main concern is about the relationship between the "loopback round-trip delay" measurement method defined in the draft and the round-trip delay performance metric (RTDelay) and its measurement method, as defined in RFC 2681 <https://www.rfc-editor.org/info/rfc2681/>, and referenced in the IANA Performance Metrics registry <https://www.iana.org/assignments/performance-metrics>.
My reading of the draft is that loopback round-trip delay, while operationally similar to RTT, is not obviously identical to the RFC 2681 Type-P-Round-trip-Delay metric. If the draft intends to claim conformance with RFC 2681/IANA RTDelay metrics, it should probably: - explicitly justify the equivalence, or - define the loopback result as a new metric, derived from but distinct from RFC 2681 RTDelay. A minor note. The draft references a two-way delay metric, while no such metric is listed in the IANA Performance Metrics registry. Regards, Greg On Fri, Oct 16, 2026 at 12:53 PM Alvaro Retana via Datatracker < [email protected]> wrote: > This message starts a WG Last Call for: > draft-ietf-spring-stamp-srpm-mpls-12 > > This Working Group Last Call ends on 2026-11-04 > > Abstract: > Segment Routing (SR) can be used to steer packets through a network > employing source routing. SR can be applied to both MPLS (SR-MPLS) > and IPv6 (SRv6) data planes. This document specifies procedures for > performance measurement in SR-MPLS networks using the Simple Two-Way > Active Measurement Protocol (STAMP), as specified in RFC 8762, along > with its optional extensions specified in RFC 8972 and the SR- > specific extensions specified in RFC 9503. These procedures measure > SR-MPLS paths, including Segment Lists of SR-MPLS Policies, SR-MPLS > IGP best paths, and SR-MPLS IGP Flexible Algorithm (Flex-Algo) paths, > as well as Layer-3 and Layer-2 services carried over those paths. > > File can be retrieved from: > https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-mpls-12.txt > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping > [email protected] in copy. Objections should be explained and suggestions to > resolve them are highly appreciated. > > This document requires in-depth technical reviews to move forward. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-stamp-srpm-mpls/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-mpls-12.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-stamp-srpm-mpls-12 > _______________________________________________ > mpls 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]
