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

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

Hi Greg,
Please see inline for reply on one of the comments below with <RG1>…
 <snip>
•  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.

<RG1> There has been a requirement to measure “direct-mode” packet loss (i.e. actual customer data traffic loss) in a network using probe messages. To address them, probe messages for various protocols have been developed like RFC 6374 (please see Section 2.9.8 and 3.1) for MPLS data plane and ITU Y.1731 for Ethernet-based networks. In segment routing networks, there are use-cases, for example, like measuring packet loss metrics for links which are based on the packet counters (please see RFC 8570, Section 4.4). TWAMP and STAMP ideally suited for them given widely they are deployed and its ability to support IPv4/IPv6/SR-MPLS/SRv6 etc. data planes in segment routing networks. Other than timestamp vs. traffic counter and it’s format, the test-packet formats are the same, hence existing implementation of TWAMP/STAMP can be easily leveraged in SR networks. We will add related information in the Introduction section of the draft.
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