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

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

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]>
Date: Monday, November 9, 2020 at 11:48 AM
To: Tommy Pauly <tpauly=[e-mail]>
Cc: IPPM Chairs <[e-mail]>, [e-mail] <[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
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.
<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.

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

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

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