Hello, I've reviewed this document and thanks for the updates over the past few months since the last WG adoption. The changes made to align with the STAMP work in IPPM WG and the companion IPPM document look good to me. The document overall has improved as well.
The requirement for performance measurement in SR networks is essential for delivering services for different SLAs and this work is critical to monitor key parameters like delay and loss in SR networks and especially for SR Policies. The choice of STAMP is also very apt as something that is supported in various data-plane implementations and also importantly works for both SR-MPLS and SRv6 - a common mechanism. Therefore I support the adoption of this work by the WG. Coming to the document itself, given that this is an adoption call, I would like to provide two high-level comments to the authors (but also for the WG/chairs to discuss/consider) : 1. I find it odd that this work is categorized as Informational where it clearly needs to be Standards Track. IIRC, it was Standards Track at the previous adoption call. The document contains the procedures for the performance measurements that need to be standardized to have interoperability and consistency across vendor implementations. Operators expect this. Standardization is not just about packet formats on the wire and procedures are equally important. 2. Somewhat related to (1), I would expect the language for the procedures to be described in a bit more formal/tighter way and perhaps make use of normative language. I will give a couple of examples below: Sec 4.1.2 : Shouldn't the selection of Destination Address/Session-Reflector Address be specified in a more normative way? The STAMP Session-Sender IPv4 or IPv6 address is used as the Source Address. The SR Policy endpoint IPv4 or IPv6 address is used as the Destination Address. Sec 4.1.2.1 - isn't it required that all SLs be monitored? So that would be a MUST monitor all SLs? An SR-MPLS Policy may contain a number of Segment Lists (SLs). A STAMP Session-Sender test packet is transmitted for each Segment List of the SR-MPLS Policy. The above are not really blocking comments for the adoption and I will request the authors to consider this. Thanks, Ketan From: spring <[email protected]> On Behalf Of James Guichard Sent: 07 June 2021 18:04 To: [email protected] Cc: [email protected] Subject: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt Dear WG: The IPPM WG has adopted https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm-00&data=04%7C01%7Cjguichar%40futurewei.com%7C68a7e8999c0e4d09f3fa08d927af658a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637584456542518360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=G3aKv%2FCnBQskcEVz4GCGVK2tdCrzBldv3yBiUXkYR%2B8%3D&reserved=0> as a WG document. In a previous communication (December 16th 2020), the SPRING chairs decided not to adopt https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt into the WG until its companion document was accepted by the IPPM WG. This has now happened and therefore we feel it is now time to revisit the WG adoption of the SPRING document. Due to the lapse of several months since the initial WG adoption call, the chairs would like to start another 2-week WG adoption call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt, ending June 21st 2021. After review of the SPRING document please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or lack thereof) as silence will not be considered as consent. Thanks! Jim, Joel & Bruno
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
