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

<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*