Re: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Thanks Rakesh!

I support WG adoption.

Kind Regards

Gyan

On Mon, Jun 21, 2021 at 5:19 PM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
wrote:

> Thanks Gyan for your review comments.
>
> We will address the comments highlighted in blue in the next revision of
> the document as per reply to Greg’s email.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *From: *spring <spring-bounces@ietf.org> on behalf of Gyan Mishra <
> hayabusagsm@gmail.com>
> *Date: *Wednesday, June 16, 2021 at 2:37 PM
> *To: *James Guichard <jguichar@futurewei.com>
> *Cc: *spring@ietf.org <spring@ietf.org>, spring-chairs@ietf.org <
> spring-chairs@ietf.org>
> *Subject: *Re: [spring] WG Adoption Call for
> https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
>
>
>
> 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 <jguichar@futurewei.com>
> 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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*