Hi Boris, Thank you for reviewing the document and providing thoughtful comments and suggestions.
We have posted rev-13 that addresses your comments. Please see replies inline with <RG>... On Wed, Oct 21, 2026 at 4:16 PM Boris Hassanov <bhassanov= [email protected]> wrote: > Hi Alvaro and WG, > > I read the draft, it describes very important STAMP operations details for > SR-MPLS. Especially I like the new loopback and loopback with TSF modes, > which should be very practical and useful IMO. > <RG> Great. > Also I would like to acknowledge very straightforward language of the > document. > Thus I support its publication. > <RG> Many thanks. > > However here are some my comments for the new version: > 1) Part 5 STAMP Reference model. > I afraid that current text have too many MAY for the destination UDP port > allocation scheme that may (apologies for the tautology) create potential > interop issues when a SDN controller and Session-Sender/Session-Reflector > will support different methods. How can they negotiate the common one ? > What if a SDN controller decides to use the User or Dynamic port ranges > (as described in RFC 8762 section 4.1 ) but routers support only default > UDP port 862 ? > There is the much stricter guidance about using Dynamic port ranges in 5.1 > . > > Thus more stronger language is needed there IMO as well as additional > clarification for the interop scenarios. > <RG> Updated Section 5 with a pointer to the reference where this is well-defined, to avoid repetition > > 2) The draft says that the IPv6 flow label must be set to the value used > by the data packets. It means that Session-Sender should track all FL > numbers used for different services (which could use STAMP) and keep them > in some local table. Are there any potential scalability restrictions ? > <RG> Added text for this in Section 14. > 3) 6.2.1 says that to measure delay of a SR Policy there will be separate > STAMP session per each SL of a Candidate Path. I fully support that idea > but what if there will 64, 128 or even more SLs and as result the same > number of STAMP sessions per ONE SR Policy (and potentially even more in > case of composite policy) ? Shouldn't we think about some optimization > proposals for such cases ? > <RG> Section 14 has some text related to the scalability considerations for this. <RG> I am not sure if any deterministic measurement can be done otherwise for taking specific actions. > 4) 9.1.1 says that TSF capability signaling is outside of the draft scope. > I think it will be worth at least to mention some of them. > <RG> Updated section 9.1.1 with additional details. > 5) !2 ECMP measurements in SR-MPLS networks is very important and I think > that currently it is too short/general and we have to think about > additional ideas/details for it in the next versions. > <RG> Updated Section 12 with additional details. Thanks, Rakesh (for authors) > > Thank you. > > SY, > Boris > > > > On Friday, October 16, 2026 at 10:54:04 PM GMT+3, 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 > _______________________________________________ > 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]
