Dear Authors I support WG adoption once the document is updated fixing the critical substantive issues that exist in the draft as it stands today.
I have worked Rakesh and authors on feedback on the draft, and as the draft is well written, I do appreciate that the issues mentioned in previous discussions being incorporated to help improve the draft. This draft was initially on Standards Track and as this draft is procedural only, reusing existing IPPM OAM framework to apply to SR, Greg Mirksy and myself requested this draft be changed to Informational. I am happy to see the authors did follow our comments and recommendations to change to informational. However, for this informational track document to be adopted by the WG, the substantive issues need to be addressed. As this draft is informational from a procedural standpoint if this draft was not proposed, there is nothing preventing STAMP or TWAMP to function over an SR both SR-MPLS or SRv6. By proposing a draft that has substantive issues related to what is being proposed procedurally, the question that come to mind is what is the purpose or benefit to even having this draft given what I stated above that IPPM STAMP and TWAMP will work and function fine without this drafts existence. I think the above statement is all the more reasons that it is critical to get this draft cleaned up prior to WG adoption. This draft PM procedures is in scope for both SR-MPLS and SRv6. This draft is trying to reuse RFC 8762 STAMP for SR, however with the chosen verbiage describing the mode used, it seems to be changing the way STAMP operates per specification. If the goal is to use STAMP in this informational context defining a special procedure for SR, this draft cannot alter or change the inner workings of STAMP. What is the reason for setting TTL to 1 and not use TTL 255 GTSM defined in RFC 5082. Also, Section 5 provides a very intriguing statement: This method can be used for inferred packet loss measurement, however, it does not provide accurate data packet loss metric. >From a measurement and performance metics perspective for SR-MPLS as it reuses the MPLS data plane the preferred method would be to use the entropy label RFC 6790, RFC 8662 for in band native data traffic than using IPv4 as once the packet is labeled the packet is label switched so using a label would be in band and in line with the MPLS forwarding plane. All of these questions as well as ones mentioned by Greg Mirsky should be addressed by the authors before this draft can be adopted. Kind Regards Gyan On Mon, Jun 7, 2021 at 8:34 AM James Guichard <[email protected]> wrote: > Dear WG: > > > > The IPPM WG has adopted > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm-00&data=04%7C01%7Cjguichar%40futurewei.com%7C68a7e8999c0e4d09f3fa08d927af658a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637584456542518360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=G3aKv%2FCnBQskcEVz4GCGVK2tdCrzBldv3yBiUXkYR%2B8%3D&reserved=0> > as a WG document. In a previous communication (December 16th 2020), the > SPRING chairs decided not to adopt > https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt > into the WG until its companion document was accepted by the IPPM WG. This > has now happened and therefore we feel it is now time to revisit the WG > adoption of the SPRING document. > > > > Due to the lapse of several months since the initial WG adoption call, the > chairs would like to start another 2-week WG adoption call for > https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt, > ending June 21st 2021. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as consent. > > > > Thanks! > > > > Jim, Joel & Bruno > > > > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
