[spring] Re: I-D Action: draft-ietf-spring-stamp-srpm-16.txt

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Thanks Ruediger for the review comments and suggestions.

We will update the draft to address your comments and share the updated version.

Thanks,
Rakesh (for authors)


From: [e-mail] <[e-mail]>
Date: Tuesday, October 29, 2024 at 10:31 AM
To: Rakesh Gandhi (rgandhi) <[e-mail]>
Cc: [e-mail] <[e-mail]>
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.

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.

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”).

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>]


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?

####

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.

#####

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.”

[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.

######

15. Security Considerations

..... STAMP uses the well-known UDP port number.

RG ... STAMP uses a well-known UDP port number

## That’s it ###


From: Rakesh Gandhi <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, October 16, 2024 at 3:38 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>