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

[Rakesh Gandhi (rgandhi)]

Thank you Greg for reviewing the document and providing your comments and 
suggestions.

Regards,
Rakesh


From: gregory.mir...@ztetx.com 
Date: Thursday, June 24, 2021 at 11:42 AM
To: Rakesh Gandhi (rgandhi) 
Cc: spring@ietf.org , spring-cha...@ietf.org 
, jguic...@futurewei.com 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for sharing your thoughts on the loopback mode. Please find my notes 
in-lined in your last mail under GIM>> tags.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn<http://www.zte.com.cn>
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/23 19:37
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,
In loopback mode, either it is STAMP (as in this draft) or BFD (as in 
draft-ietf-bfd-unaffiliated-echo), the reflector simply loops the test packet 
back in forwarding and does not participate in test. In both cases, I hope you 
agree that the loopback  mode is useful as it removes the dependency on the 
reflector.

GIM>> Of course, I agree. The self-addressed test probe is a well-known OAM 
tool, and IETF has published several documents that apply that principle in 
different environments. However, I don't believe that the loopback in SR needs 
more coverage than already in draft-ietf-6man-spring-srv6-oam. Note that that 
document has a detailed explanation of the loopback mode and the right level of 
abstraction.

The loopback mode does require specification on the sender, e.g. how the test 
packet is encapsulated in SR, test packet is transmitted as well as how the 
received test packet is processed. The metrics are  computed differently than 
the one-way or two-way modes, etc.

GIM>> Is the SR encapsulation of a self-addressed test probe any different 
from, in principle, from encapsulating a packet in SR? I think it is not. Add 
an SRH or a label stack designed to reach the intended destination. It doesn't 
make any difference if the destination is the sender or any arbitrary SR node. 
Hence, anyone familiar with SR is expected to understand how to encapsulate a 
test probe to get it to come back to the sender. Besides, how metrics are 
calculated is better to be left to the implementor. I'd argue that the packet 
delay can be measured more accurately, especially in the SRv6 environment, if 
T1 is recorded by the sender locally as the test packet being transmitted. Thus 
an implementation can exclude variable delay caused by recalculating IP 
checksum after T1 is copied into the test packet.

The loopback mode does belong to the same specification where all measurement 
modes are described, to fully understand the behaviours of the sender and 
reflector in each mode. For example, it can also help  an operator make an 
informed decision on which mode to enable in the network after reading the 
standard.

GIM>> We have different views on the value of that. However, I believe in the 
following principle: "A document is ready not when there's nothing left to add 
to it but when there's nothing left to remove from it without it losing 
informational value."

Thanks,
Rakesh
From: gregory.mir...@ztetx.com 
Date: Wednesday, June 23, 2021 at 9:34 PM
To: Rakesh Gandhi (rgandhi) 
Cc: spring@ietf.org , spring-cha...@ietf.org 
, jguic...@futurewei.com 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
I'm top-posting to share my understanding of why 
draft-ietf-bfd-unaffiliated-echo is on the Standards track. As you've noted, 
draft-ietf-bfd-unaffiliated-echo describes the use of BFD Echo between a BFD 
system and a system that might not support BFD. But RFC  5880 excludes such use 
cases by requiring that a BFD Echo be transmitted only after the BFD session is 
in the Upstate. In other words, BFD peers must bring the session by exchanging 
BFD control messages to the Upstate, and only after that, any system can 
transmit  a BFD Echo packet. draft-ietf-bfd-unaffiliated-echo will update RFC 
5880 in that, and that is why, as I understand it, the draft is on the 
Standards Track, not because it defines behavior entirely internal for the 
sender of a BFD Echo. As I have pointed, this  draft is not updating STAMP, and 
the loopback mode is not affecting the Session-Reflector. I don't see that 
including the description of one of the possible implementations in the 
document adds value as t
 her
e is no interoperabi

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

[gregory.mirsky]

Hi Rakesh,
thank you for sharing your thoughts on the loopback mode. Please find my notes 
in-lined in your last mail under GIM>> tags.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/23 19:37
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,
In loopback mode, either it is STAMP (as in this draft) or BFD (as in 
draft-ietf-bfd-unaffiliated-echo), the reflector simply loops the test packet 
back in forwarding and does not participate in test. In both cases, I hope you 
agree that the loopback  mode is useful as it removes the dependency on the 
reflector.
GIM>> Of course, I agree. The self-addressed test probe is a well-known OAM 
tool, and IETF has published several documents that apply that principle in 
different environments. However, I don't believe that the loopback in SR needs 
more coverage than already in draft-ietf-6man-spring-srv6-oam. Note that that 
document has a detailed explanation of the loopback mode and the right level of 
abstraction.
The loopback mode does require specification on the sender, e.g. how the test 
packet is encapsulated in SR, test packet is transmitted as well as how the 
received test packet is processed. The metrics are  computed differently than 
the one-way or two-way modes, etc.
GIM>> Is the SR encapsulation of a self-addressed test probe any different 
from, in principle, from encapsulating a packet in SR? I think it is not. Add 
an SRH or a label stack designed to reach the intended destination. It doesn't 
make any difference if the destination is the sender or any arbitrary SR node. 
Hence, anyone familiar with SR is expected to understand how to encapsulate a 
test probe to get it to come back to the sender. Besides, how metrics are 
calculated is better to be left to the implementor. I'd argue that the packet 
delay can be measured more accurately, especially in the SRv6 environment, if 
T1 is recorded by the sender locally as the test packet being transmitted. Thus 
an implementation can exclude variable delay caused by recalculating IP 
checksum after T1 is copied into the test packet.
The loopback mode does belong to the same specification where all measurement 
modes are described, to fully understand the behaviours of the sender and 
reflector in each mode. For example, it can also help  an operator make an 
informed decision on which mode to enable in the network after reading the 
standard.
GIM>> We have different views on the value of that. However, I believe in the 
following principle: "A document is ready not when there's nothing left to add 
to it but when there's nothing left to remove from it without it losing 
informational value."
Thanks,
Rakesh
From: gregory.mir...@ztetx.com 
Date: Wednesday, June 23, 2021 at 9:34 PM
To: Rakesh Gandhi (rgandhi) 
Cc: spring@ietf.org , spring-cha...@ietf.org 
, jguic...@futurewei.com 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
I'm top-posting to share my understanding of why 
draft-ietf-bfd-unaffiliated-echo is on the Standards track. As you've noted, 
draft-ietf-bfd-unaffiliated-echo describes the use of BFD Echo between a BFD 
system and a system that might not support BFD. But RFC  5880 excludes such use 
cases by requiring that a BFD Echo be transmitted only after the BFD session is 
in the Upstate. In other words, BFD peers must bring the session by exchanging 
BFD control messages to the Upstate, and only after that, any system can 
transmit  a BFD Echo packet. draft-ietf-bfd-unaffiliated-echo will update RFC 
5880 in that, and that is why, as I understand it, the draft is on the 
Standards Track, not because it defines behavior entirely internal for the 
sender of a BFD Echo. As I have pointed, this  draft is not updating STAMP, and 
the loopback mode is not affecting the Session-Reflector. I don't see that 
including the description of one of the possible implementations in the 
document adds value as t
 her
e is no interoperability to be defined.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部   Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/23 15:59
Subj

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

[Gyan Mishra]

Thanks Rakesh!

I support WG adoption.

Kind Regards

Gyan

On Mon, Jun 21, 2021 at 5:19 PM Rakesh Gandhi (rgandhi) 
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  on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Wednesday, June 16, 2021 at 2:37 PM
> *To: *James Guichard 
> *Cc: *spring@ietf.org , spring-cha...@ietf.org <
> spring-cha...@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 
> 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=04%7C01%7Cjguichar%40futurewei.com%7C68a7e8999c0e4d09f3fa08d927af658a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637584456542518360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=G3aKv%2FCnBQskcEVz4GCGVK2tdCrzBldv3yBiUXkYR%2B8%3D=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/archiv

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

[Rakesh Gandhi (rgandhi)]

Hi Greg,

In loopback mode, either it is STAMP (as in this draft) or BFD (as in 
draft-ietf-bfd-unaffiliated-echo), the reflector simply loops the test packet 
back in forwarding and does not participate in test. In both cases, I hope you 
agree that the loopback mode is useful as it removes the dependency on the 
reflector.

The loopback mode does require specification on the sender, e.g. how the test 
packet is encapsulated in SR, test packet is transmitted as well as how the 
received test packet is processed. The metrics are computed differently than 
the one-way or two-way modes, etc.

The loopback mode does belong to the same specification where all measurement 
modes are described, to fully understand the behaviours of the sender and 
reflector in each mode. For example, it can also help an operator make an 
informed decision on which mode to enable in the network after reading the 
standard.

Thanks,
Rakesh


From: gregory.mir...@ztetx.com 
Date: Wednesday, June 23, 2021 at 9:34 PM
To: Rakesh Gandhi (rgandhi) 
Cc: spring@ietf.org , spring-cha...@ietf.org 
, jguic...@futurewei.com 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
I'm top-posting to share my understanding of why 
draft-ietf-bfd-unaffiliated-echo is on the Standards track. As you've noted, 
draft-ietf-bfd-unaffiliated-echo describes the use of BFD Echo between a BFD 
system and a system that might not support BFD. But RFC 5880 excludes such use 
cases by requiring that a BFD Echo be transmitted only after the BFD session is 
in the Upstate. In other words, BFD peers must bring the session by exchanging 
BFD control messages to the Upstate, and only after that, any system can 
transmit a BFD Echo packet. draft-ietf-bfd-unaffiliated-echo will update RFC 
5880 in that, and that is why, as I understand it, the draft is on the 
Standards Track, not because it defines behavior entirely internal for the 
sender of a BFD Echo. As I have pointed, this draft is not updating STAMP, and 
the loopback mode is not affecting the Session-Reflector. I don't see that 
including the description of one of the possible implementations in the 
document adds value as ther
 e is no interoperability to be defined.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn<http://www.zte.com.cn>
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/23 15:59
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,
Many thanks for your review comments. Please see replies inline with …
From: gregory.mir...@ztetx.com 
Date: Wednesday, June 23, 2021 at 4:57 PM
To: Rakesh Gandhi (rgandhi) 
Cc: spring@ietf.org , spring-cha...@ietf.org 
, jguic...@futurewei.com 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for your consideration. Please find my follow-up notes in-lined under 
the GIM2>> tag.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部   Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn<http://www.zte.com.cn>
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/21 12:44
Subject: Re: [spring] WG Adoption Call for  
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: gregory.mir...@ztetx.com 
Date: Thursday, June 17, 2021 at 10:57 PM
To: Rakesh Gandhi (rgandhi) 
Cc: jguic...@futurewei.com , spring@ietf.org 
, spring-cha...@ietf.org 
Subject: Re:[spring] WG Adoption Call for  
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for responding to my comments. I've added follow-up notes in-line 
tagged GIM>>.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn<http://www.zte.com.cn>
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;jguic...@futurewei.com;
CC: spring@ietf.org;spring-

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

[gregory.mirsky]

Hi Rakesh,
I'm top-posting to share my understanding of why 
draft-ietf-bfd-unaffiliated-echo is on the Standards track. As you've noted, 
draft-ietf-bfd-unaffiliated-echo describes the use of BFD Echo between a BFD 
system and a system that might not support BFD. But RFC 5880 excludes such use 
cases by requiring that a BFD Echo be transmitted only after the BFD session is 
in the Upstate. In other words, BFD peers must bring the session by exchanging 
BFD control messages to the Upstate, and only after that, any system can 
transmit a BFD Echo packet. draft-ietf-bfd-unaffiliated-echo will update RFC 
5880 in that, and that is why, as I understand it, the draft is on the 
Standards Track, not because it defines behavior entirely internal for the 
sender of a BFD Echo. As I have pointed, this draft is not updating STAMP, and 
the loopback mode is not affecting the Session-Reflector. I don't see that 
including the description of one of the possible implementations in the 
document adds value as ther
 e is no interoperability to be defined.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/23 15:59
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,
Many thanks for your review comments. Please see replies inline with …
From: gregory.mir...@ztetx.com 
Date: Wednesday, June 23, 2021 at 4:57 PM
To: Rakesh Gandhi (rgandhi) 
Cc: spring@ietf.org , spring-cha...@ietf.org 
, jguic...@futurewei.com 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for your consideration. Please find my follow-up notes in-lined under 
the GIM2>> tag.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部   Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/21 12:44
Subject: Re: [spring] WG Adoption Call for  
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: gregory.mir...@ztetx.com 
Date: Thursday, June 17, 2021 at 10:57 PM
To: Rakesh Gandhi (rgandhi) 
Cc: jguic...@futurewei.com , spring@ietf.org 
, spring-cha...@ietf.org 
Subject: Re:[spring] WG Adoption Call for  
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for responding to my comments. I've added follow-up notes in-line 
tagged GIM>>.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;jguic...@futurewei.com;
CC: spring@ietf.org;spring-cha...@ietf.org;
Date: 2021/06/16 12:50
Subject: Re: [spring] WG Adoption Call for   
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: spring  on behalf of gregory.mir...@ztetx.com 

Date: Friday, June 11, 2021 at 3:19 AM
To: jguic...@futurewei.com 
Cc: spring@ietf.org , spring-cha...@ietf.org 

Subject: Re: [spring] WG Adoption Call for   
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear Authors, et al.,
I've read the draft. Thank you for your thoughtful consideration of comments 
from earlier discussions. The document is well-written and I agree with it 
being on the Informational track.
 Many thanks.
I've several questions and much appreciate it if you help me to understand.
In the example of a STAMP test packet (Figure 2) the text suggests that IPv4 
addresses can be used as the source and destination. In which case you see IPv4 
address family should be used in the SR environment?
 Figure 2 shows both IPv4 and IPv6 address family and they are the 
addresses of the Session-Sender and Session-Reflector as defi

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

[Rakesh Gandhi (rgandhi)]

Hi Greg,
Many thanks for your review comments. Please see replies inline with …

From: gregory.mir...@ztetx.com 
Date: Wednesday, June 23, 2021 at 4:57 PM
To: Rakesh Gandhi (rgandhi) 
Cc: spring@ietf.org , spring-cha...@ietf.org 
, jguic...@futurewei.com 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for your consideration. Please find my follow-up notes in-lined under 
the GIM2>> tag.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn<http://www.zte.com.cn>
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/21 12:44
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: gregory.mir...@ztetx.com 
Date: Thursday, June 17, 2021 at 10:57 PM
To: Rakesh Gandhi (rgandhi) 
Cc: jguic...@futurewei.com , spring@ietf.org 
, spring-cha...@ietf.org 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for responding to my comments. I've added follow-up notes in-line 
tagged GIM>>.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部   Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn<http://www.zte.com.cn>
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;jguic...@futurewei.com;
CC: spring@ietf.org;spring-cha...@ietf.org;
Date: 2021/06/16 12:50
Subject: Re: [spring] WG Adoption Call for  
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: spring  on behalf of gregory.mir...@ztetx.com 

Date: Friday, June 11, 2021 at 3:19 AM
To: jguic...@futurewei.com 
Cc: spring@ietf.org , spring-cha...@ietf.org 

Subject: Re: [spring] WG Adoption Call for  
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear Authors, et al.,
I've read the draft. Thank you for your thoughtful consideration of comments 
from earlier discussions. The document is well-written and I agree with it 
being on the Informational track.
 Many thanks.
I've several questions and much appreciate it if you help me to understand.
In the example of a STAMP test packet (Figure 2) the text suggests that IPv4 
addresses can be used as the source and destination. In which case you see IPv4 
address family should be used in the SR environment?
 Figure 2 shows both IPv4 and IPv6 address family and they are the 
addresses of the Session-Sender and Session-Reflector as defined in STAMP.  The 
STAMP packet is further encapsulated with an SR-MPLS/SRv6 header depending on 
SR-MPLS  Policy or SRv6 Policy  being measured.
GIM>> Can you please clarify for me SRv6 scenario. The authors of the draft 
propose to encapsulate a STAMP packet, from a Session-Sender or 
Session-Reflector, in IP/UDP and then, on top of that, add another IPv6 
encapsulation with SRH? Any reason why not simply  add the SRH to a STAMP 
packet encapsulated in IPv6?
 When using the SIDs of the forward path in SRH, the top IPv6/SRH is added 
to bring the test packet to the Session-Reflector from the Session-Sender. In 
loopback mode, the bottom IPv6 header is used to bring  the test packet back 
from the Session-Reflector to the Session-Sender. The bottom IPv6 header is not 
required when using SIDs of both forward + reverse paths in SRH.
GIM2>> Thank you for the clarification. If I understand it correctly, in the 
loopback mode the STAMP Session-Reflector function is not involved in 
processing the STAMP test packet. If that is the case, what is the value of 
including the description of the loopback mode in the draft?

 This is similar to BFD in loopback mode as defined in 
draft-ietf-bfd-unaffiliated-echo-02.txt, where the remote side does not support 
BFD protocol for example, and simply loops back the packet. It is also a 
Standards-track document.

I suggest changing the reference in Figure 2 from Section 4.2 of RFC 8762 to 
Section 3 of RFC 8972 (Figure 1). Thus the STAMP Session Identifier will be 
supported in SR environments and implementations can use the value of the field 
to simplify demultipl

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

[Voyer, Daniel]

Support for WG adoption.
Thanks

dan

From: James Guichard 
Date: Monday, June 7, 2021 at 8:34 AM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[gregory.mirsky]

Hi Rakesh,
thank you for your consideration. Please find my follow-up notes in-lined under 
the GIM2>> tag.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/21 12:44
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: gregory.mir...@ztetx.com 
Date: Thursday, June 17, 2021 at 10:57 PM
To: Rakesh Gandhi (rgandhi) 
Cc: jguic...@futurewei.com , spring@ietf.org 
, spring-cha...@ietf.org 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for responding to my comments. I've added follow-up notes in-line 
tagged GIM>>.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部   Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;jguic...@futurewei.com;
CC: spring@ietf.org;spring-cha...@ietf.org;
Date: 2021/06/16 12:50
Subject: Re: [spring] WG Adoption Call for  
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: spring  on behalf of gregory.mir...@ztetx.com 

Date: Friday, June 11, 2021 at 3:19 AM
To: jguic...@futurewei.com 
Cc: spring@ietf.org , spring-cha...@ietf.org 

Subject: Re: [spring] WG Adoption Call for  
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear Authors, et al.,
I've read the draft. Thank you for your thoughtful consideration of comments 
from earlier discussions. The document is well-written and I agree with it 
being on the Informational track.
 Many thanks.
I've several questions and much appreciate it if you help me to understand.
In the example of a STAMP test packet (Figure 2) the text suggests that IPv4 
addresses can be used as the source and destination. In which case you see IPv4 
address family should be used in the SR environment?
 Figure 2 shows both IPv4 and IPv6 address family and they are the 
addresses of the Session-Sender and Session-Reflector as defined in STAMP.  The 
STAMP packet is further encapsulated with an SR-MPLS/SRv6 header depending on 
SR-MPLS  Policy or SRv6 Policy  being measured.
GIM>> Can you please clarify for me SRv6 scenario. The authors of the draft 
propose to encapsulate a STAMP packet, from a Session-Sender or 
Session-Reflector, in IP/UDP and then, on top of that, add another IPv6 
encapsulation with SRH? Any reason why not simply  add the SRH to a STAMP 
packet encapsulated in IPv6?
 When using the SIDs of the forward path in SRH, the top IPv6/SRH is added 
to bring the test packet to the Session-Reflector from the Session-Sender. In 
loopback mode, the bottom IPv6 header is used to bring  the test packet back 
from the Session-Reflector to the Session-Sender. The bottom IPv6 header is not 
required when using SIDs of both forward + reverse paths in SRH.
GIM2>> Thank you for the clarification. If I understand it correctly, in the 
loopback mode the STAMP Session-Reflector function is not involved in 
processing the STAMP test packet. If that is the case, what is the value of 
including the description of the loopback mode in the draft?

I suggest changing the reference in Figure 2 from Section 4.2 of RFC 8762 to 
Section 3 of RFC 8972 (Figure 1). Thus the STAMP Session Identifier will be 
supported in SR environments and implementations can use the value of the field 
to simplify demultiplexing   STAMP test sessions.
 Thanks for the suggestion, agree to update it in the next revision.
I couldn't understand the last sentence in Section 4.1.1:
An IPv4 address from the range 127/8 or IPv6
loopback address ::1/128 [RFC4291] must not be used to IP route test
packets in a network.
How this requirement (if that is the requirement, then s/must not/MUST NOT/ 
might be needed), is related to RFC 1801 that states that:
A router SHOULD NOT forward, except over a loopback interface, any
packet that has a destination address on network 127.
 Agree to remove this sentence in the next revision.
GIM>> Thank you, looking forward to the next version.

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

[Gyan Mishra]

Hi Ketan


See the mail archive from December 2020 below where it was proposed to the
authors to change from Standards Track to Informational or experimental.

The authors took that recommendation  into consideration and updated the
draft to Informational.

Reason being is that nothing new was being introduced as the IPPM PM
monitoring STAMP, TWAMP, OWAMP are data plane agnostic, as this is a
procedural draft that is not updating any IPPM or SPRING specification, but
rather using existing specifications as normative references to define a
procedure for PM over SR.  There is nothing that prevents PM monitoring to
work today without this draft.

What is crucial for this draft as informational is as Greg and myself have
mentioned is that it not try to update normative references to existing
IPPM specifications. That would break any existing implementations of PM
over SR.

https://mailarchive.ietf.org/arch/msg/spring/t1GSKCrV4NBzTWP7HsxNr4gQpG8/

Kind Regards

Gyan


On Fri, Jun 18, 2021 at 10:43 AM Ketan Talaulikar (ketant)  wrote:

> Hello,
>
>
>
> I’ve reviewed this document and thanks for the updates over the past few
> months since the last WG adoption. The changes made to align with the STAMP
> work in IPPM WG and the companion IPPM document look good to me. The
> document overall has improved as well.
>
>
>
> The requirement for performance measurement in SR networks is essential
> for delivering services for different SLAs and this work is critical to
> monitor key parameters like delay and loss in SR networks and especially
> for SR Policies. The choice of STAMP is also very apt as something that is
> supported in various data-plane implementations and also importantly works
> for both SR-MPLS and SRv6 – a common mechanism. Therefore I support the
> adoption of this work by the WG.
>
>
>
> Coming to the document itself, given that this is an adoption call, I
> would like to provide two high-level comments to the authors (but also for
> the WG/chairs to discuss/consider) :
>
>
>
>1. I find it odd that this work is categorized as Informational where
>it clearly needs to be Standards Track. IIRC, it was Standards Track at the
>previous adoption call. The document contains the procedures for the
>performance measurements that need to be standardized to have
>interoperability and consistency across vendor implementations. Operators
>expect this. Standardization is not just about packet formats on the wire
>and procedures are equally important.
>2. Somewhat related to (1), I would expect the language for the
>procedures to be described in a bit more formal/tighter way and perhaps
>make use of normative language. I will give a couple of examples below:
>
>
>
> Sec 4.1.2 :  Shouldn’t the selection of Destination
> Address/Session-Reflector Address be specified in a more normative way?
>
>The STAMP Session-Sender IPv4 or IPv6 address is used as the Source
>
>Address.  The SR Policy endpoint IPv4 or IPv6 address is used as the
>
>Destination Address.
>
>
>
> Sec 4.1.2.1 – isn’t it required that all SLs be monitored? So that would
> be a MUST monitor all SLs?
>
>An SR-MPLS Policy may contain a number of Segment Lists (SLs).  A
>
>STAMP Session-Sender test packet is transmitted for each Segment List
>
>of the SR-MPLS Policy.
>
>
>
>
>
> The above are not really blocking comments for the adoption and I will
> request the authors to consider this.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* spring  *On Behalf Of *James Guichard
> *Sent:* 07 June 2021 18:04
> *To:* spring@ietf.org
> *Cc:* spring-cha...@ietf.org
> *Subject:* [spring] WG Adoption Call for
> https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
>
>
>
> Dear WG:
>
>
>
> The IPPM WG has adopted
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
> 
> 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 

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

[Rakesh Gandhi (rgandhi)]

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  on behalf of Gyan Mishra 

Date: Wednesday, June 16, 2021 at 2:37 PM
To: James Guichard 
Cc: spring@ietf.org , spring-cha...@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 
mailto:jguic...@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=04%7C01%7Cjguichar%40futurewei.com%7C68a7e8999c0e4d09f3fa08d927af658a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637584456542518360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=G3aKv%2FCnBQskcEVz4GCGVK2tdCrzBldv3yBiUXkYR%2B8%3D=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<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Rakesh Gandhi (rgandhi)]

Hi Greg,

Many thanks for your review comments and suggestions.
Please see replies inline with …

From: gregory.mir...@ztetx.com 
Date: Thursday, June 17, 2021 at 10:57 PM
To: Rakesh Gandhi (rgandhi) 
Cc: jguic...@futurewei.com , spring@ietf.org 
, spring-cha...@ietf.org 
Subject: Re:[spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for responding to my comments. I've added follow-up notes in-line 
tagged GIM>>.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn<http://www.zte.com.cn>
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;jguic...@futurewei.com;
CC: spring@ietf.org;spring-cha...@ietf.org;
Date: 2021/06/16 12:50
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: spring  on behalf of gregory.mir...@ztetx.com 

Date: Friday, June 11, 2021 at 3:19 AM
To: jguic...@futurewei.com 
Cc: spring@ietf.org , spring-cha...@ietf.org 

Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear Authors, et al.,
I've read the draft. Thank you for your thoughtful consideration of comments 
from earlier discussions. The document is well-written and I agree with it 
being on the Informational track.
 Many thanks.
I've several questions and much appreciate it if you help me to understand.
In the example of a STAMP test packet (Figure 2) the text suggests that IPv4 
addresses can be used as the source and destination. In which case you see IPv4 
address family should be used in the SR environment?
 Figure 2 shows both IPv4 and IPv6 address family and they are the 
addresses of the Session-Sender and Session-Reflector as defined in STAMP.  The 
STAMP packet is further encapsulated with an SR-MPLS/SRv6 header depending on 
SR-MPLS  Policy or SRv6 Policy being measured.
GIM>> Can you please clarify for me SRv6 scenario. The authors of the draft 
propose to encapsulate a STAMP packet, from a Session-Sender or 
Session-Reflector, in IP/UDP and then, on top of that, add another IPv6 
encapsulation with SRH? Any reason why not simply add the SRH to a STAMP packet 
encapsulated in IPv6?

 When using the SIDs of the forward path in SRH, the top IPv6/SRH is added 
to bring the test packet to the Session-Reflector from the Session-Sender. In 
loopback mode, the bottom IPv6 header is used to bring the test packet back 
from the Session-Reflector to the Session-Sender. The bottom IPv6 header is not 
required when using SIDs of both forward + reverse paths in SRH.

I suggest changing the reference in Figure 2 from Section 4.2 of RFC 8762 to 
Section 3 of RFC 8972 (Figure 1). Thus the STAMP Session Identifier will be 
supported in SR environments and implementations can use the value of the field 
to simplify demultiplexing  STAMP test sessions.
 Thanks for the suggestion, agree to update it in the next revision.

I couldn't understand the last sentence in Section 4.1.1:
An IPv4 address from the range 127/8 or IPv6
loopback address ::1/128 [RFC4291] must not be used to IP route test
packets in a network.
How this requirement (if that is the requirement, then s/must not/MUST NOT/ 
might be needed), is related to RFC 1801 that states that:
A router SHOULD NOT forward, except over a loopback interface, any
packet that has a destination address on network 127.
 Agree to remove this sentence in the next revision.
GIM>> Thank you, looking forward to the next version.

Also, it appears that only IP encapsulation is explained in Section 4.1.1. 
Since the draft includes in its scope both SRv6 and SR-MPLS, I wonder in what 
case IPv4 addressing will be used? It seems that rather than including IPv4, 
the section should document  the encapsulation of a STAMP test packet over an 
MPLS link.
 It is not necessary to add SR encapsulate for sending test packets for 
links.
 However, we could add text to state
“SR encapsulation (e.g. adjacency SID of the link) can be added for 
transmitting the test packets for links.”

Section 4.1.2 also refers to IPv4 address family being used by a Session-Sender 
and SR Policy. What could be the use case for IPv4 in SR?
 As mentioned above, RFC 8762 base STAMP packets carry IP/UDP header.
GIM>> I disagree. RFC 8762 does not require STAMP test packet use IP/UDP 
encapsulation. It states that if STAMP test message is enapculated in IP/UDP, 
then it may use destination port 862 for a Session-Sender test packets. Other 
encapsulations are outside the scope of

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

[Wen, Bin]

Dear WG,

I have reviewed the updated version and support the workgroup adoption. Thanks,


From: James Guichard 
Date: Monday, June 7, 2021 at 8:34 AM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Robert Raszuk]

Support.

Thx,
r.

On Mon, Jun 7, 2021 at 2:34 PM James Guichard 
wrote:

> Dear WG:
>
>
>
> The IPPM WG has adopted
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
> 
> 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
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Chengli (Cheng Li)]

Yes, support. The document describes a mature and useful method for PM in SR 
networking.

Thanks,
Cheng





From: James Guichard [mailto:jguic...@futurewei.com]
Sent: Monday, June 7, 2021 8:35 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Pablo Camarillo (pcamaril)]

I support the WG adoption. This draft describes procedures for various SR-MPLS 
and SRv6 encapsulations for IP/UDP based Simple TWAMP, including different PM 
modes on top of what is specified in RFC 8762. It adds a very much needed PM 
toolkit in SR environment (both SR-MPLS and SRv6).

Thanks,
Pablo.

From: spring  On Behalf Of James Guichard
Sent: lunes, 7 de junio de 2021 14:34
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Ketan Talaulikar (ketant)]

Hello,

I've reviewed this document and thanks for the updates over the past few months 
since the last WG adoption. The changes made to align with the STAMP work in 
IPPM WG and the companion IPPM document look good to me. The document overall 
has improved as well.

The requirement for performance measurement in SR networks is essential for 
delivering services for different SLAs and this work is critical to monitor key 
parameters like delay and loss in SR networks and especially for SR Policies. 
The choice of STAMP is also very apt as something that is supported in various 
data-plane implementations and also importantly works for both SR-MPLS and SRv6 
- a common mechanism. Therefore I support the adoption of this work by the WG.

Coming to the document itself, given that this is an adoption call, I would 
like to provide two high-level comments to the authors (but also for the 
WG/chairs to discuss/consider) :


  1.  I find it odd that this work is categorized as Informational where it 
clearly needs to be Standards Track. IIRC, it was Standards Track at the 
previous adoption call. The document contains the procedures for the 
performance measurements that need to be standardized to have interoperability 
and consistency across vendor implementations. Operators expect this. 
Standardization is not just about packet formats on the wire and procedures are 
equally important.
  2.  Somewhat related to (1), I would expect the language for the procedures 
to be described in a bit more formal/tighter way and perhaps make use of 
normative language. I will give a couple of examples below:



Sec 4.1.2 :  Shouldn't the selection of Destination Address/Session-Reflector 
Address be specified in a more normative way?
   The STAMP Session-Sender IPv4 or IPv6 address is used as the Source
   Address.  The SR Policy endpoint IPv4 or IPv6 address is used as the
   Destination Address.



Sec 4.1.2.1 - isn't it required that all SLs be monitored? So that would be a 
MUST monitor all SLs?

   An SR-MPLS Policy may contain a number of Segment Lists (SLs).  A

   STAMP Session-Sender test packet is transmitted for each Segment List

   of the SR-MPLS Policy.



The above are not really blocking comments for the adoption and I will request 
the authors to consider this.

Thanks,
Ketan

From: spring  On Behalf Of James Guichard
Sent: 07 June 2021 18:04
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[gregory.mirsky]

Hi Rakesh,
thank you for responding to my comments. I've added follow-up notes in-line 
tagged GIM>>.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
--Original Mail--
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;jguic...@futurewei.com;
CC: spring@ietf.org;spring-cha...@ietf.org;
Date: 2021/06/16 12:50
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with …
From: spring  on behalf of gregory.mir...@ztetx.com 

Date: Friday, June 11, 2021 at 3:19 AM
To: jguic...@futurewei.com 
Cc: spring@ietf.org , spring-cha...@ietf.org 

Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear Authors, et al.,
I've read the draft. Thank you for your thoughtful consideration of comments 
from earlier discussions. The document is well-written and I agree with it 
being on the Informational track.
 Many thanks.
I've several questions and much appreciate it if you help me to understand.
In the example of a STAMP test packet (Figure 2) the text suggests that IPv4 
addresses can be used as the source and destination. In which case you see IPv4 
address family should be used in the SR environment?
 Figure 2 shows both IPv4 and IPv6 address family and they are the 
addresses of the Session-Sender and Session-Reflector as defined in STAMP.  The 
STAMP packet is further encapsulated with an SR-MPLS/SRv6 header depending on 
SR-MPLS  Policy or SRv6 Policy being measured.
GIM>> Can you please clarify for me SRv6 scenario. The authors of the draft 
propose to encapsulate a STAMP packet, from a Session-Sender or 
Session-Reflector, in IP/UDP and then, on top of that, add another IPv6 
encapsulation with SRH? Any reason why not simply add the SRH to a STAMP packet 
encapsulated in IPv6?

I suggest changing the reference in Figure 2 from Section 4.2 of RFC 8762 to 
Section 3 of RFC 8972 (Figure 1). Thus the STAMP Session Identifier will be 
supported in SR environments and implementations can use the value of the field 
to simplify demultiplexing  STAMP test sessions.
 Thanks for the suggestion, agree to update it in the next revision.

I couldn't understand the last sentence in Section 4.1.1:
An IPv4 address from the range 127/8 or IPv6
loopback address ::1/128 [RFC4291] must not be used to IP route test
packets in a network.
How this requirement (if that is the requirement, then s/must not/MUST NOT/ 
might be needed), is related to RFC 1801 that states that:
A router SHOULD NOT forward, except over a loopback interface, any
packet that has a destination address on network 127.
 Agree to remove this sentence in the next revision.
GIM>> Thank you, looking forward to the next version.

Also, it appears that only IP encapsulation is explained in Section 4.1.1. 
Since the draft includes in its scope both SRv6 and SR-MPLS, I wonder in what 
case IPv4 addressing will be used? It seems that rather than including IPv4, 
the section should document  the encapsulation of a STAMP test packet over an 
MPLS link.
 It is not necessary to add SR encapsulate for sending test packets for 
links.
 However, we could add text to state
“SR encapsulation (e.g. adjacency SID of the link) can be added for 
transmitting the test packets for links.”

Section 4.1.2 also refers to IPv4 address family being used by a Session-Sender 
and SR Policy. What could be the use case for IPv4 in SR?
 As mentioned above, RFC 8762 base STAMP packets carry IP/UDP header. 
GIM>> I disagree. RFC 8762 does not require STAMP test packet use IP/UDP 
encapsulation. It states that if STAMP test message is enapculated in IP/UDP, 
then it may use destination port 862 for a Session-Sender test packets. Other 
encapsulations are outside the scope of RFC 8762. If we consider MPLS, then, in 
addition to using IP/UDP, a new ACH type can be used to carry STAMP messages.
The IP address family in the base STAMP test packet can be IPv4 or IPv6 address 
of the Session-Sender and Session-Reflector. In SR, the STAMP packets are 
further  encapsulated with an SR header.
GIM>> As noted earlier, I'm interested in SRv6 scenario. Does it add the whole 
IP/UDP encapsulation or only SRH?
What is the benefit of using the inner IP Header as presented in Figure 4?
 The inner IP header is useful in loopback mode, the outer header is 
responsible for transmitting the test packet to the Session-Reflector. The 
Session-Reflector will decap SRv6 tunnel header and forward the test packet 
back to the  Session-Sender according to the inner

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

[Rakesh Gandhi (rgandhi)]

Hi Greg,

Many thanks for your review comments and suggestions.
Please see replies inline with …

From: spring  on behalf of gregory.mir...@ztetx.com 

Date: Friday, June 11, 2021 at 3:19 AM
To: jguic...@futurewei.com 
Cc: spring@ietf.org , spring-cha...@ietf.org 

Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear Authors, et al.,
I've read the draft. Thank you for your thoughtful consideration of comments 
from earlier discussions. The document is well-written and I agree with it 
being on the Informational track.

 Many thanks.

I've several questions and much appreciate it if you help me to understand.
In the example of a STAMP test packet (Figure 2) the text suggests that IPv4 
addresses can be used as the source and destination. In which case you see IPv4 
address family should be used in the SR environment?

 Figure 2 shows both IPv4 and IPv6 address family and they are the 
addresses of the Session-Sender and Session-Reflector as defined in STAMP.  The 
STAMP packet is further encapsulated with an SR-MPLS/SRv6 header depending on 
SR-MPLS Policy or SRv6 Policy being measured.

I suggest changing the reference in Figure 2 from Section 4.2 of RFC 8762 to 
Section 3 of RFC 8972 (Figure 1). Thus the STAMP Session Identifier will be 
supported in SR environments and implementations can use the value of the field 
to simplify demultiplexing STAMP test sessions.

 Thanks for the suggestion, agree to update it in the next revision.


I couldn't understand the last sentence in Section 4.1.1:
   An IPv4 address from the range 127/8 or IPv6
   loopback address ::1/128 [RFC4291] must not be used to IP route test
   packets in a network.
How this requirement (if that is the requirement, then s/must not/MUST NOT/ 
might be needed), is related to RFC 1801 that states that:
  A router SHOULD NOT forward, except over a loopback interface, any
  packet that has a destination address on network 127.

 Agree to remove this sentence in the next revision.

Also, it appears that only IP encapsulation is explained in Section 4.1.1. 
Since the draft includes in its scope both SRv6 and SR-MPLS, I wonder in what 
case IPv4 addressing will be used? It seems that rather than including IPv4, 
the section should document the encapsulation of a STAMP test packet over an 
MPLS link.

 It is not necessary to add SR encapsulate for sending test packets for 
links.
 However, we could add text to state
“SR encapsulation (e.g. adjacency SID of the link) can be added for 
transmitting the test packets for links.”

Section 4.1.2 also refers to IPv4 address family being used by a Session-Sender 
and SR Policy. What could be the use case for IPv4 in SR?

 As mentioned above, RFC 8762 base STAMP packets carry IP/UDP header. The 
IP address family in the base STAMP test packet can be IPv4 or IPv6 address of 
the Session-Sender and Session-Reflector. In SR, the STAMP packets are further 
encapsulated with an SR header.

What is the benefit of using the inner IP Header as presented in Figure 4?

 The inner IP header is useful in loopback mode, the outer header is 
responsible for transmitting the test packet to the Session-Reflector. The 
Session-Reflector will decap SRv6 tunnel header and forward the test packet 
back to the Session-Sender according to the inner header.
 We can update this in the next revision.

As for Figure 2, I propose changing the reference to Section 3 of RFC 8792 
(Figure 2).

 We are ok to update it in the next revision.

As for Figure 4, I have a question about the inner IP header in Figure 7.

 It is not necessary. We can update in the next revision.

Can you point to the definition (or provide it) of the loopback mode?


 In this (informational) draft, it is defined for SR networks in Section 
4.2.3.

The second paragraph of Section 4.2.3 suggests that the Session-Sender is 
expected to receive a self-addressed STAMP test packet. Can you point out the 
text in RFC 8762 that defines the base STAMP functionality on which this model 
is based?


 In this (informational) draft, it is defined for SR networks in Section 
4.2.3.


In the same paragraph, the draft states:
   The Session-Sender sets the Reflector UDP port that it uses to receive the 
test packet.
Can you clarify the definition of the Reflector UDP port?

 It is destination UDP port in the Session-Sender test packet. We are ok to 
update in the next revision.

The third paragraph, as I understand it, assumes that the Session-Sender does 
not use some fields to calculate performance metrics. I couldn't find such a 
mode is described in RFC 8762. Does this draft propose changes to the RFC 8762?

 This informational draft explains various delay metrics in SR. It does not 
change RFC 8762.


I've got confused by the rules listed for setting TTL in Section 4.4.1. For 
example, according to the rule in the third paragraph, TTL must be set to 1 for 
the STAMP measurement over a link

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

[Gyan Mishra]

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

> Dear WG:
>
>
>
> The IPPM WG has adopted
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
> 
> 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
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Mike Koldychev (mkoldych)]

Yes, support.

From: James Guichard 
Sent: Monday, June 7, 2021 8:35 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Ahmed Abdelsalam (ahabdels)]

Support for WG adoption.
Thanks
Ahmed

From: James Guichard 
Date: Monday, 7 June 2021 at 14:34
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[gregory.mirsky]

Dear Authors, et al.,
I've read the draft. Thank you for your thoughtful consideration of comments 
from earlier discussions. The document is well-written and I agree with it 
being on the Informational track. I've several questions and much appreciate it 
if you help me to understand.
In the example of a STAMP test packet (Figure 2) the text suggests that IPv4 
addresses can be used as the source and destination. In which case you see IPv4 
address family should be used in the SR environment?
I suggest changing the reference in Figure 2 from Section 4.2 of RFC 8762 to 
Section 3 of RFC 8972 (Figure 1). Thus the STAMP Session Identifier will be 
supported in SR environments and implementations can use the value of the field 
to simplify demultiplexing STAMP test sessions.
I couldn't understand the last sentence in Section 4.1.1:
   An IPv4 address from the range 127/8 or IPv6
   loopback address ::1/128 [RFC4291] must not be used to IP route test
   packets in a network.
How this requirement (if that is the requirement, then s/must not/MUST NOT/ 
might be needed), is related to RFC 1801 that states that:
  A router SHOULD NOT forward, except over a loopback interface, any
  packet that has a destination address on network 127.
Also, it appears that only IP encapsulation is explained in Section 4.1.1. 
Since the draft includes in its scope both SRv6 and SR-MPLS, I wonder in what 
case IPv4 addressing will be used? It seems that rather than including IPv4, 
the section should document the encapsulation of a STAMP test packet over an 
MPLS link.
Section 4.1.2 also refers to IPv4 address family being used by a Session-Sender 
and SR Policy. What could be the use case for IPv4 in SR?
What is the benefit of using the inner IP Header as presented in Figure 4?
As for Figure 2, I propose changing the reference to Section 3 of RFC 8792 
(Figure 2).
As for Figure 4, I have a question about the inner IP header in Figure 7.
Can you point to the definition (or provide it) of the loopback mode?
The second paragraph of Section 4.2.3 suggests that the Session-Sender is 
expected to receive a self-addressed STAMP test packet. Can you point out the 
text in RFC 8762 that defines the base STAMP functionality on which this model 
is based?
In the same paragraph, the draft states:
   The Session-Sender sets the Reflector UDP port that it uses to receive the 
test packet.
Can you clarify the definition of the Reflector UDP port?
The third paragraph, as I understand it, assumes that the Session-Sender does 
not use some fields to calculate performance metrics. I couldn't find such a 
mode is described in RFC 8762. Does this draft propose changes to the RFC 8762?
I've got confused by the rules listed for setting TTL in Section 4.4.1. For 
example, according to the rule in the third paragraph, TTL must be set to 1 for 
the STAMP measurement over a link. But that seems like the opposite to what is 
required in RFC 5082 The Generalized TTL Security Mechanism (GTSM). I hope you 
can share why TTL must be set to 1 in this case.
The same question for the use case described in the second paragraph.
Two previous questions are also applicable to Section 4.4.2.
Section 5, as I understand it, suggests that all modes of operation described 
in Section 4 can be used to measure packet loss. At the same time, in Section 
4.2.3. Loopback Measurement Mode is noted (or required) that the Session-Sender 
sets the value of the Session-Sender Sequence Number field to zero. If that is 
the case, how the packet loss is calculated in the loopback mode?
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.
Do you have more information, perhaps a reference to a study or RFC, to support 
this statement? Following the logic of that statement, if packet loss measured 
using STAMP is not accurate, wouldn't measured packet delay also be not 
accurate? It seems that, if authors want to maintain this position, the 
definition of the accuracy of the measurement must be introduced.
I feel that the suggestion to variate IPv4 address in measuring performance 
metrics in the SR-MPLS environment is somewhat outdated and is not in step with 
RFCs 6790 and 8662. Why choosing addresses from the 127/8 range is preferred to 
using the Entropy label which is more likely to be used on the data traffic?
I have another question on the last sentence of Section 8:
   The STAMP Session-Reflector must not transmit reply test packet if it is
   not the intended destination node in the "Destination Node Address"
   TLV [I-D.gandhi-ippm-stamp-srpm].
How does this requirement work in the case of a P2MP SR policy? And which 
address would be used in the Destination Node Address TLV in that case?


I believe that while some questions are non-blocking and can be addressed at a 
later time, there is a significant number of technical substantive issues 

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

[Martin Horneffer]

Yes, support.

From an operator's point of view: I think this can add valuable 
enhancements to SR enabled networks.


Best regards, Martin


Am 07.06.21 um 14:33 schrieb James Guichard:

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00 
 
as a WG document. In a previous communication (December 16^th 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 21^st 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



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Rakesh Gandhi (rgandhi)]

Hi WG,

As a co-author, I support the WG adoption of this draft that uses Simple TWAMP 
RFC 8762 and its extensions RFC 8972, both recently published by IPPM WG.

This draft further builds on the draft “Simple TWAMP Extensions for SR 
Networks” recently adopted by IPPM WG: 
draft-ietf-ippm-stamp-srpm-00.

Many thanks to the WG for providing valuable review comments. We believe that 
the latest draft addresses those comments.

Thanks,
Rakesh



From: spring  on behalf of James Guichard 

Date: Monday, June 7, 2021 at 8:34 AM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Wangyali(Yali,Data Communication Standards and Patents Dept)]

Yes. Support.

Best,
Yali

From: James Guichard [mailto:jguic...@futurewei.com]
Sent: Monday, June 7, 2021 8:35 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Linda Dunbar]

Yes, support.

Best regards,
Linda Dunbar

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Monday, June 7, 2021 8:34 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Mach Chen]

Yes, support.

Best regards,
Mach

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Monday, June 7, 2021 8:34 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Zafar Ali (zali)]

Dear chairs and the WG,

I have reviewed the draft and find it a needed companion of the work adopted by 
the IPPM WG

I support the adoption

Thanks

Regards … Zafar

From: spring  on behalf of James Guichard 

Date: Monday, June 7, 2021 at 8:34 AM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Luay Jalil]

Support for WG adoption

Regards,
Luay

From: spring  on behalf of James Guichard 

Date: Monday, June 7, 2021 at 7:34 AM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Mankamana Mishra (mankamis)]

Support adoption. Read the document, it is important area to work and make 
progress .

From: James Guichard 
Date: Monday, June 7, 2021 at 5:34 AM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

I support this document for WG adoption. It addresses an important issue.
Thanks.
Jorge

From: spring  on behalf of James Guichard 

Date: Monday, June 7, 2021 at 2:34 PM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Foote, Footer (Nokia - CA)]

I support as co-author.

Footer

From: spring  On Behalf Of James Guichard
Sent: Monday, 7 June 2021 08:34
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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

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

[Samuel Sidor (ssidor)]

I support the adoption of this draft.

Regards,
Samuel

From: spring  On Behalf Of Jaganbabu Rajamanickam 
(jrajaman)
Sent: Monday, June 7, 2021 3:25 PM
To: James Guichard ; spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

I support

From: James Guichard mailto:jguic...@futurewei.com>>
Date: Monday, June 7, 2021 at 8:34 AM
To: "spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>
Cc: "spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>" 
mailto:spring-cha...@ietf.org>>
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

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=04%7C01%7Cjguichar%40futurewei.com%7C68a7e8999c0e4d09f3fa08d927af658a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637584456542518360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=G3aKv%2FCnBQskcEVz4GCGVK2tdCrzBldv3yBiUXkYR%2B8%3D=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

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

[Jaganbabu Rajamanickam (jrajaman)]

I support

From: James Guichard 
Date: Monday, June 7, 2021 at 8:34 AM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
 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