[ippm] FW: Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

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

Thanks Greg for your comments. Please see inline, I have added some replies below inline with <RG3>…

From: Greg Mirsky <[e-mail]>
Date: Thursday, November 19, 2020 at 12:28 PM
To: Mach Chen <[e-mail]>
Cc: Tianran Zhou <[e-mail]>, Rakesh Gandhi (rgandhi) <[e-mail]>, spring <[e-mail]>, IPPM Chairs <[e-mail]>, [e-mail] <[e-mail]>, Tommy Pauly <[e-mail]>, IETF IPPM WG ([e-mail]) <[e-mail]>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Mach,
thank you for your email. I've added my understanding of what has been proposed in-line tagged GIM>>.

Regards,
Greg

On Wed, Nov 18, 2020 at 11:41 PM Mach Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Tianran, Rakesh and Greg,
 Please see some responses inline with [Mach]…
From: ippm [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Tianran Zhou
Sent: Thursday, November 19, 2020 1:33 PM
To: Rakesh Gandhi (rgandhi) <rgandhi=[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: spring <[e-mail]<mailto:[e-mail]>>; IPPM Chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Tommy Pauly <tpauly=[e-mail]<mailto:[e-mail]>>; IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
 Hi Rakesh and Greg,
I may not very clear about the context. Please allow me to jump in.
It seems both of you make some valid point.
Please see in line with <ZTR>.
Cheers,
Tianran
From: spring [mailto:[e-mail]] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: spring <[e-mail]<mailto:[e-mail]>>; IPPM Chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>; IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
 Hi Greg,
Thank you for your review and discussions on the drafts. This will help improve the work on this important work.
Please see replies inline with <RG>..

 From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 17, 2020 at 5:27 PM
To: Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>>
Cc: Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>, IPPM Chairs <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>, spring <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Rakesh, WG Chairs, and All,
I've read the responses to my detailed comments. I don't think that only adding references will solve the problems with the documents. If authors are interested in addressing my comments, we can start working on solving them one by one.
 <RG> As mentioned in previous replies, we can add references for the well-known terms “Links”, “Congruent Paths”, “SR Path”. If you prefer, we can define them here. For Zero checksum field, we can add a reference for the RFC 6936 in Security section and also add some text for it. Will be happy to work with you to address these.
 But I am very much concerned with the technical value of these drafts. And here's why I feel that the proposed documents don't provide a sound technical solution to the task of direct loss measurement. Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

  *   What is being proposed in these drafts?
Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support direct packet loss measurements. Note, that RFC 6374 includes a method for direct loss measurement in MPLS networks that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct packet loss measurement. STAMP and all its extensions are applicable in IPv6 networks and, thus, can be used in the SRv6 domain.
 <RG> As mentioned in previous replies, both RFC 6374 (in Section 4.2) and ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and RX counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that take advantage of the widely deployed TWAMP protocol and as well this same protocol can be deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.
 <ZTR> I think RFC6374 for MPLS and Y.1731 make some noise here. The point is if we need a new direct packet loss measurement for STAMP, when STAMP already defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement, then how about proposing a new TLV.
 [Mach] Given that TWAMP does not support TLV, I assume that the discussions are mainly about draft*-stamp-srpm.
GIM>> You've brought a very good question on how the return path, in case required by the Sender Control Code, introduced in draft-gandhi-ippm-twamp-srpm, is specified? As you've pointed out, RFC 5357 does not use TLV extensions. Should I assume that the return path, if required, provisioned through the management plane? I think that that requires clarification.

<RG3> Here the return SR path may be dynamic and can often change (when ingress nodes re-compute SR paths). Using controller based signaling/provisioning for it defeats the purpose of overcoming scale limitations and using TWAMP Light.
 [Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-stamp-srpm assumes that marking-based solution (which can address the packet out-ordering issue) is used, hence the block number is introduced. The block number is used to correlate the counters from the sender and reflector. The current direct loss measurement TLV may just apply to the scenario without packet out-ordering.
GIM>> I agree with your observation on the purpose of the Block Number field in both TWAMP-Light and STAMP documents. In my understanding, the new protocol may be also used to collect counters generated by methods other than Alternate Marking. In that case, I assume, the value of Block Number may not convey any information.

<RG3> When TX and RX counters are collected by the TWAMP Light and STAMP based probe message defined in this draft, it’s block number carried in the message provides the context for the counters to be able to correlate the TX and RX counters to measure the traffic loss “at the Sender when the response is received”.
 [Mach] In addition, whether to keep it as current design or to define a new TLV for direct loss measurement can be debatable.
GIM>> I agree with you. And that what I am proposing - review the requirements, agree on requirements, and review the proposed solution based on these requirements.

<RG3> Please see the previous reply sent:
As TWAMP Light does not have a TLV, we need to define a stand-alone message for direct-mode LM. STAMP is just the same message but fixed length, so this way both can interoperate and also we can leverage the message for both of these protocols.

For STAMP direct-mode LM TLV approach, some technical details are in the draft as well:

   The STAMP message with a TLV for "direct measurement" can be used for
   combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv<https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00#ref-I-D.ietf-ippm-stamp-option-tlv>].
   However, in order to use only for loss measurement purpose, it
   requires the node to support the delay measurement messages and
   support timestamp for these messages (which may also require clock
   synchronization for one-way delay).  Furthermore, for hardware-based counter collection
   for direct-mode loss measurement, the optional TLV based processing
   adds unnecessary overhead (as counters are not at well-known
   locations).
 How the proposed method of direct packet loss is related to TWAMP light and STAMP?
There's no apparent technical relationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the basic mechanisms defined for  TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mode and new formats of test packets that are decisively different from the formats defined in respective specifications. As a result, the new protocols are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responder. And that is another clear indication that the proposed mechanism represents a new protocol, neither extends TWAMP Light and/or STAMP nor updates their specifications.
<RG> As mentioned in previous replies, other than timestamp vs. counter and it’s format, the messages and processing of them are the same for delay and direct-mode loss measurement.

  *   Is there any advantage in introducing a dedicated packet format for the direct packet loss in STAMP comparing to using the Direct Measurement TLV extension?
Though it appears the using a dedicated packet format instead of TLV is more efficient, but the dedicated for the direct loss measurement format is likely to precede one or even two TLVs, Node Address TLV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with TLVs is unlikely to be more efficient and reduce the processing delay, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-stamp-option-tlv.
<RG> As mentioned in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/>. For link loss measurement (direct-mode), there is no TLV required for example. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss measurement (and not bidirectional).
•         What are the potential benefits of specifying the return path in the new test packet's Sender Control Code?
Using the Sender Control Code may require the use of the additional TLV that carries the return path information, Path TLV. If the ability to control the return path is required that can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each test packet. Hence, there seem no technical requirements to introduce the Sender Control Code field in the Base STAMP format defined in RFC 8762.
<RG> Per session basis between different sender nodes and this reflector node, some senders will request the replies in-band (e.g. for two-way mode). Sessions are provisioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for a bidirectional SR path). This is also similar to as described Section 3.1 in RFC 6374, top of page 22. There is no need to create a such state for each session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scale limitation by eliminating the Control protocol signaling.
<ZTR> I find some value to include the path TLV in wire. As Rakesh mentioned, this can reduce the reflector configuration. But I am not convinced to introduce the sender control code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa.
[Mach] Regarding how to specify the return path, the draft defines two ways to achieve that, one is to use control code to direct whether the reflected Test should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the case of STAMP, it also defines the return path TLV to explicitly specify the return path, which bring more options to specify the return path. Therefore, I see benefit of the two ways.
GIM>> I think you've pointed to some vagueness in the definition of a mechanism used to define the return path. My understanding is that if a response required, the Return Path TLV must be present in a test packet. But, if TLVs are not used for TWAMP-like direct loss measurement, why not use the same method to control the return path? I believe that consistency is a good quality of a protocol (yes, I see *-twamp-srpm and *-stmp-srpm as a single protocol only presented as different entities).

<RG3> Yes, it is the intention to be consistent between the two drafts. TWAMP Light and STAMP are using the same method using the “Sender control code”. Obviously STAMP provides additional capability to specify Return Path via TLV. Both drafts explain the methods used.

Thanks,
Rakesh

 Best regards,
Mach
 What is the relationship between the *-srpm drafts and BFD?
Some text in the *-srpm drafts suggest that the proposed method can be used to monitor for the loss of a path continuity. That may be viewed as an alternative to the BFD protocol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness remain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs be made aware of the proposals. I didn't take the liberty of adding BFD WG or its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs.
 <RG> As mentioned in previous replies, STAMP/TWAMP test messages are also used today for synthetic packet loss measurement which can be also used to detect/monitor connection loss (performance metric). The draft simply highlights this obvious metric. This is also very similar to what is described in ITU Y.1731, Section 7.1.
 Thanks,
Rakesh
Regards,
On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Rakesh,
thank you for your prompt response, much appreciated. I'll carefully read your responses. Looking forward to the continued discussion.
 Regards,
Greg
 On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,
 Thank you for your review comments. As mentioned in the IPPM session today, the email response was sent as attachments, see archive blow:
https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/
 I am attaching them in word documents for the convenience. We can address your comments below in the next revision of the document.
 Thanks,
Rakesh
From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Friday, November 13, 2020 at 10:09 AM
To: Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>>
Cc: Tommy Pauly <tpauly=[e-mail]<mailto:[e-mail]>>, IPPM Chairs <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Rakesh,
thank you for your response to my review. Please find my follow-up notes in-lined below under the GIM>> tag.
I hope you've found more detailed comments in the attachments (re-attached for your convenience). I'm looking forward to reading your responses to the detailed comments of all four drafts.
Regards,
Greg
On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>> wrote:
Thank you Greg for taking time for thoroughly reviewing the documents and providing the comments.  Attached please find the email replies to your review sent earlier.  The replies are copied inline below for convenience, tagged with <RG00>.
From: ippm <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 9, 2020 at 11:48 AM
To: Tommy Pauly <tpauly=[e-mail]<mailto:[e-mail]>>
Cc: IPPM Chairs <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Dear WG Chairs, Authors, and IPPM WG community,
I've reviewed these drafts and have some comments to share. Below, please find my thoughts on whether these drafts can be adopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying draft targetted to the SPRING WG) are in the attached documents.
Usually, the bar for the adoption of a document can be evaluated by answers to these three questions:
•  Is the document(s) reasonably well-written
I've got surprised that the drafts don't use the terminology from RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents without proper definitions. Other than that both drafts are readable and reasonably well-written.
<RG00> We can change Sender to Session-Sender and Reflector to Session-Reflector if it helps.
GIM>> I believe that the consistency in terminology between the core RFC and what is intended as its extension is not only helpful to a reader but, to the best of my understanding, is required for IETF specifications.
<RG00> There are many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we can add a reference for them if it helps.
GIM>> Thank you for listing these RFCs. I think I need to clarify my questions. While a reference to any of RFCs you've mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs used the lower case form for the term "link". Can these be used interchangeably? Do they refer to the same network object?
Now I'll try to illustrate my concern with using the term "congruent path" in these drafts (using ASCII-art):
                       C---------D
                     /                 \
            A----B                   E-----F
                     \                  /
                     G------------H
Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F. From the definition of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and size as the mirror image of the other", path A-B-G-H-E-F is congruent to the SR tunnel. But a packet of an active OAM intended to monitor a flow over the SR tunnel is out-of-band and will not produce any meaningful measurement. Of course, for the case of the extensions in drafts, direct loss measurement can be performed, as information collected from node F. So, this example, in my opinion, illustrates two of my concerns:

  *   using a congruent path for an active OAM protocol may produce information that does not reflect the condition experienced by the monitored flow. It seems that the terminology should reflect the fundamental requirement for using active OAM to maintain the test packets in-band with the monitored flow.
  *   there are no technical requirements to justify using in-band active OAM protocol for direct packet loss measurement. As demonstrated in this example, direct packet loss can be performed using an out-of-band mechanism, e.g., SNMP queries, Netconf notifications based on YANG data model.


  *   Does the document solve a real problem?
No, it appears that  both TWAMP and STAMP drafts  define a new performance measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP functionality in the respective drafts, and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms like ICMP multi-part message extension per RFC 4884.
 <RG00> There is a requirement to measure performance delay as well as synthetic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measurement today. I am not sure extending ICMP for LM is a good option here.
GIM>> I agree with the requirements you've listed (though the SPRING WG OAM requirements document<https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03> has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement.

  *   Is the proposed solution technically viable?
There are too many unaddressed aspects, particularly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.
 <RG00> About your comment on zero checksum, this is described in Security section in RFC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for STAMP or TWAMP Light. Other than this, I did not find any other security related issue in your review.
GIM>> I don't think that a mere reference sufficiently explains why the use of zero UDP checksum in IPv6 header is not decremental, does not create a security risk for the protocol.
 Thanks,
Rakesh
 Regards,
Greg
On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly=[e-mail]<mailto:[e-mail]>> wrote:
Hello IPPM,
For the past few meetings, we’ve had updates on the work in the SPRING WG that was using STAMP and TWAMP. Since those documents ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be best to split the documents and track the IPPM extension work in the IPPM WG.
 As such, we are starting a Working Group call for adoption for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.
 The documents are here:

https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00
https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00

The related SPRING documents are here:

https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
 Please provide your feedback on these documents, and state whether or not you believe the IPPM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.
 Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm