Thank you Ruediger for the detailed review of the draft. Sorry for the delay in replying.
Please see replies inline with <RK> From: ruediger.g...@telekom.de <ruediger.g...@telekom.de> Date: Tuesday, October 29, 2024 at 10:31 AM To: Rakesh Gandhi (rgandhi) <rgan...@cisco.com> Cc: spring-cha...@ietf.org <spring-cha...@ietf.org> Subject: [spring] Re: I-D Action: draft-ietf-spring-stamp-srpm-16.txt Hi Rakesh, Thanks for your draft. Please find some comments below. Regards, Ruediger RG/general: This is an info track doc. Please remove all requirements language. As it’s info, I think, “must” and “MUST” will not apply. The text in many instances to me would benefit from more clarity – there are a few “may” and “can”. To me, an interested implementor would benefit from more textual clarity on what to do, also without requirement language. I leave this to the authors. <RK> Updated draft to change MUST and MAY to non-normative language as in the attached draft. <RK> Updated draft to change “may” and “can” to simple sentences. <RK> In the beginning, there was some discussions on the information vs standards track status. Not sure if WG may discuss it could be standards track. Example The Session-Sender MUST ensure that the Session-Sender test packets using the Segment List reach the SRv6 Policy endpoint (for example, by adding the Prefix SID or IPv6 address of the SRv6 Policy endpoint in the Segment List) in both encoding modes. RG (a suggestion – please correct, if wrong): The Session-Sender ensures that the Session-Sender test packets using the Segment List reach the SRv6 Policy endpoint by adding the Prefix SID (or IPv6 address) of the SRv6 Policy endpoint in the Segment List in both encoding modes. <RK> Updated. RG: I’d also be happier, if the text could be clearer on where examples are given and what would change in behaviour with other examples. If this doc proposes one specific solution, it may help to add one statement saying the entire doc is an example for an implementation (rather than having many figures as examples each). The doc itself would then be easier to parse (I’d personally prefer the text to carry less “may” and “can”). <RK> Updated “may” and “can” to regular sentences. <RK> The procedures are generic, but the figure is just an example encoding to highlight the case. Example: “For links, the Session-Sender may request in the test packet for the Session-Reflector to transmit the reply test packet on the same link in the reverse direction. It can use the "Reply Requested on the Same Link" flag in the Control Code Sub-TLV in the Return Path TLV defined in [RFC9503<https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-16.html#RFC9503>] for this request.” RG (proposal): If the Session-Sender wants the Session-Reflector to transmit the reply test packet on the same link in the reverse direction, it sets the "Reply Requested on the Same Link" flag in the Control Code Sub-TLV in the Return Path TLV defined in [RFC9503<https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-16.html#RFC9503>]. <RK> Updated as: “ For links, the Session-Sender sets the "Reply Requested on the Same Link" flag in the Control Code Sub-TLV in the Return Path TLV defined in [RFC9503] to request the Session-Reflector to transmit the reply test packet on the same link in the reverse direction. “ Further comments: 1. Introduction IS: “This limits the scale for the number of STAMP sessions and the ability to provide faster measurement intervals.” [RG] I’d appreciate a clarification on this statement. Do you mean to keep the frequency of probes constant, but the reporting intervals are shortened (i.e. the number of probes per measurement interval reduces, the number of measurement intervals increases), or whether the number of measurement intervals is kept constant while the frequency of probes during a measurement interval is increased. Isn’t the latter the frequency of probes? <RK> Updated as: This limits the frequency of STAMP test packets and the ability to provide faster measurement intervals. #### 6.3.1. Loopback Measurement Mode for SR-MPLS Paths [RG] Please add a ref to RFC 8203: OLD: … or both the forward direction and the return paths in the MPLS header, as shown in Figure 15. NEW: … or both the forward direction and the return paths in the MPLS header, as specified by [RFC8203] and shown in Figure 15. <RK> Do you mean [RFC8403] ? ##### 10. ECMP Measurement in SR Networks [RG] Unless you come up with sufficient text to explain the behaviour of an implementation, please remove the statement: “The forwarding plane has various hashing functions available to forward packets on specific ECMP paths. The mechanisms described in [RFC8029<https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-16.html#RFC8029>] and [RFC5884<https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-16.html#RFC5884>] for handling ECMPs are also applicable to delay measurement.” <RK> Removed. [RG]: This sentence to me indicates, that Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks includes MPLS OAM capabilities as defined by RFC8029. I don’t object to separate executions, i.e. first perform an MPLS trace by RFC 8029 and then use the know how gained to set up a desired number of STAMP for Segment Routing Network measurement flows. The statement needs to express that. If you’ve implemented a mix of RFC8029 and STAMP for Segment Routing, please explain operation in sufficient detail. <RK> Updated text to: In the IPv4 header of the Session-Sender and Session-Reflector test packets, different values of the Destination Address from the range 127/8 are used to exercise different IPv4 ECMP paths taken by them, as described in Section 2.1 of [RFC8029]. ###### 15. Security Considerations ..... STAMP uses the well-known UDP port number. RG ... STAMP uses a well-known UDP port number <RK> Fixed. ## That’s it ### <RK> Many thanks fort the great comments. Regards, Rakesh From: Rakesh Gandhi <rgandhi.i...@gmail.com<mailto:rgandhi.i...@gmail.com>> Date: Wednesday, October 16, 2024 at 3:38 PM To: spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto:spring@ietf.org>> Subject: [spring] Re: I-D Action: draft-ietf-spring-stamp-srpm-16.txt Hi WG, This update contains mainly editorial changes to the draft. We welcome your review comments and suggestions. Thanks, Rakesh (for co-authors) On Mon, Oct 14, 2024 at 9:55 PM <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote: Internet-Draft draft-ietf-spring-stamp-srpm-16.txt is now available. It is a work item of the Source Packet Routing in Networking (SPRING) WG of the IETF. Title: Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks Authors: Rakesh Gandhi Clarence Filsfils Daniel Voyer Mach(Guoyi) Chen Richard Foote Name: draft-ietf-spring-stamp-srpm-16.txt Pages: 52 Dates: 2024-10-14 Abstract: Segment Routing (SR) leverages the source routing paradigm and applies to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for links and SR paths (including SR Policies and SR IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-stamp-srpm/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-16.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-stamp-srpm-16 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ spring mailing list -- spring@ietf.org<mailto:spring@ietf.org> To unsubscribe send an email to spring-le...@ietf.org<mailto:spring-le...@ietf.org>
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
