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

From: James Guichard <[email-masked]>
Date: Mon, 7 Jun 2021 12:33:53 +0000

Dear WG:

The IPPM WG has adopted https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm-00&data=04%7C01%7Cjguichar%40futurewei.com%7C68a7e8999c0e4d09f3fa08d927af658a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637584456542518360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=G3aKv%2FCnBQskcEVz4GCGVK2tdCrzBldv3yBiUXkYR%2B8%3D&reserved=0> as a WG document. In a previous communication (December 16th 2020), the SPRING chairs decided not to adopt https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt into the WG until its companion document was accepted by the IPPM WG. This has now happened and therefore we feel it is now time to revisit the WG adoption of the SPRING document.

Due to the lapse of several months since the initial WG adoption call, the chairs would like to start another 2-week WG adoption call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt, ending June 21st 2021.

After review of the SPRING document please indicate support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support (or lack thereof) as silence will not be considered as consent.

Thanks!

Jim, Joel & Bruno

---

From: "Foote, Footer (Nokia - CA)" <[email-masked]>
Date: Mon, 7 Jun 2021 13:39:38 +0000

I support as co-author.

Footer

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

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 7 Jun 2021 15:09:31 +0000

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

From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Date: Monday, June 7, 2021 at 2:34 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Luay Jalil <[email-masked]>
Date: Mon, 7 Jun 2021 22:00:58 +0000

Support for WG adoption

Regards,
Luay

Date: Monday, June 7, 2021 at 7:34 AM

Thanks!

Jim, Joel & Bruno

---

From: Mach Chen <[email-masked]>
Date: Tue, 8 Jun 2021 02:53:01 +0000

Yes, support.

Best regards,
Mach

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

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Jun 2021 21:07:10 +0000

Yes, support.

Best regards,
Linda Dunbar

From: spring [mailto:[email-masked]] On Behalf Of James Guichard
Sent: Monday, June 7, 2021 8:34 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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&data=04%7C01%7Cldunbar%40futurewei.com%7Cfb3c6d1737a648418bcf08d92a289209%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637587176059822365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q%2B2MGnALPDsEAVrsKLWYBAMtJEHvjZTQ5lCorGJ977E%3D&reserved=0> as a WG document. In a previous communication (December 16th 2020), the SPRING chairs decided not to adopt https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-gandhi-spring-stamp-srpm-06.txt&data=04%7C01%7Cldunbar%40futurewei.com%7Cfb3c6d1737a648418bcf08d92a289209%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637587176059827333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aGRG8ObRAQxBsAKNGnBL6TPr5AKj2eDFFM5ivbFkKqI%3D&reserved=0> 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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-gandhi-spring-stamp-srpm-06.txt&data=04%7C01%7Cldunbar%40futurewei.com%7Cfb3c6d1737a648418bcf08d92a289209%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637587176059827333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aGRG8ObRAQxBsAKNGnBL6TPr5AKj2eDFFM5ivbFkKqI%3D&reserved=0>, ending June 21st 2021.

Thanks!

Jim, Joel & Bruno

---

From: "Wangyali(Yali,Data Communication Standards and Patents Dept)" <[email-masked]>
Date: Thu, 10 Jun 2021 15:19:00 +0000

Yes. Support.

Best,
Yali

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

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 10 Jun 2021 18:10:49 +0000

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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm-00&data=04%7C01%7Cjguichar%40futurewei.com%7C68a7e8999c0e4d09f3fa08d927af658a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637584456542518360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=G3aKv%2FCnBQskcEVz4GCGVK2tdCrzBldv3yBiUXkYR%2B8%3D&reserved=0>.

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

Thanks,
Rakesh

Date: Monday, June 7, 2021 at 8:34 AM

Thanks!

Jim, Joel & Bruno

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 11 Jun 2021 09:14:30 +0200

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 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm-00&data=04%7C01%7Cjguichar%40futurewei.com%7C68a7e8999c0e4d09f3fa08d927af658a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637584456542518360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=G3aKv%2FCnBQskcEVz4GCGVK2tdCrzBldv3yBiUXkYR%2B8%3D&reserved=0> 
> as a WG document. In a previous communication (December 16^th 2020), the 
> SPRING chairs decided not to adopt 
> https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt 
> <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 
> <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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: <[email-masked]>
Date: Fri, 11 Jun 2021 15:18:47 +0800 (CST)

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 that must be resolved before the adoption of this draft.
I am looking forward to the Authors' feedback.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [email-masked]
www.zte.com.cn
------------------Original Mail------------------
Sender: JamesGuichard
To: [email-masked];
CC: [email-masked];
Date: 2021/06/07 05:34
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

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jun 2021 09:07:58 +0800

Support the WG adoption.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: Rakesh Gandhi \(rgandhi\)
Date: 2021-06-11 02:10
To: James Guichard; [email-masked]
CC: [email-masked]
Subject: Re: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi 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.

Thanks,
Rakesh

 

 
Thanks!
 
Jim, Joel & Bruno

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Wed, 16 Jun 2021 16:10:26 +0000

Yes, support.

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

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 16 Jun 2021 14:36:19 -0400

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.

>From a measurement and performance metics perspective for SR-MPLS as it
reuses the MPLS data plane the preferred method would be to use the entropy
label RFC 6790, RFC 8662 for in band native data traffic than using IPv4 as
once the packet is labeled the packet is label switched so using a label
would be in band and in line with the MPLS forwarding plane.

All of these questions as well as ones mentioned by Greg Mirsky should be
addressed by the authors before this draft can be adopted.

Kind Regards

Gyan

On Mon, Jun 7, 2021 at 8:34 AM James Guichard <[email-masked]>
wrote:

> as a WG document. In a previous communication (December 16th 2020), the
> 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.
>
>
>
> 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
>
>
>
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 16 Jun 2021 19:49:26 +0000

Hi Greg,

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

From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Friday, June 11, 2021 at 3:19 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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.

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

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

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

<RG> Agree to remove this sentence in the next revision.

<RG> It is not necessary to add SR encapsulate for sending test packets for links.
<RG> 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.”

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

<RG> 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.
<RG> We can update this in the next revision.

<RG> We are ok to update it in the next revision.

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

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

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

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

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

<RG> As described in Section 4.3 of [RFC8029], for IP address 127/8 case with using TTL=1, it is to ensure that the test packet does not get incorrectly IP routed to more than one IP hop and provide incorrect measurement.

<RG> Please see above.

<RG> Please see above.

<RG> Session-Sender has the knowledge about this mode. Session-Sender can set the Session-Sender Sequence Number to Sequence Number to avoid any confusion. We are ok to update it in the next revision.

<RG> RFC 6374 has good discussions on the two loss measurement modes. We are ok to update the text as follows to align with RFC 6374.

   This method can be used for inferred packet loss measurement,
   however, it provides only approximate view of the data packet loss.

<RG> Yes, we can add following text in the next update:

   Forwarding plane has various hashing functions available to forward
   packets on specific ECMP paths.  For SR-MPLS Policy, sweeping of
   entropy label [RFC6790] values can be used in Session-Sender test packets
   and Session-Reflector test packets
   to take advantage of the hashing function in forwarding
   plane to influence the ECMP path taken by them.

<RG> As specified in [draft-ietf-ippm-stamp-srpm-00], the Destination Node Address TLV is applicable to P2P SR Policy.
We can add the sentence in this draft as well in the next update.

Thanks,
Rakesh

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [email-masked]
www.zte.com.cn<http://www.zte.com.cn>
------------------Original Mail------------------
Sender: JamesGuichard
To: [email-masked];
CC: [email-masked];
Date: 2021/06/07 05:34
Subject: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

---

From: <[email-masked]>
Date: Fri, 18 Jun 2021 10:57:06 +0800 (CST)

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

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;[email-masked];
CC: [email-masked];[email-masked];
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

Hi Greg,
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?

GIM>> Thank you, looking forward to the next version.

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?
<RG> 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?
<RG> 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.
GIM>> I have to admit that I'm confused by your explanation. As I understand the loopback mode, a test packet is not decapsulated by the Session-Reflector. The Session-Reflector, I assume, acts as a segment end-point but the SR policy brings the test packet all the way back to the Session-Sender. If that is how the loopback mode is expected to perform, I believe that my original question stil stands.
<RG> We can update this in the next revision.

Can you point to the definition (or provide it) of the loopback mode?
<RG> In this (informational) draft, it is defined for SR networks in Section 4.2.3.
GIM>> What is observable by a Session-Reflector behavior when a Session-Sender uses the loopback mode? As I understand it, there's none. The Session-Reflector is not participating in a test in the loopback mode. If that is the case, there's no interworking, interoperability and, as a result, nothing to document.
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?
<RG> In this (informational) draft, it is defined for SR networks in Section 4.2.3.

GIM>> Could that be UDP port 862, as that is the one well-known port allocated for Session-Sender transmitted test packets?

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?
<RG> This informational draft explains various delay metrics in SR. It does not change RFC 8762.
GIM>> Informational drafts, to the best of my understanding, document how techniques defined in Standard-track RFCs can be used, can work together. This document does introduce something that does not exists, is not described in RFC 8762 or RFC 8962.

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.
<RG> As described in Section 4.3 of [RFC8029], for IP address 127/8 case with using TTL=1, it is to ensure that the test packet does not get incorrectly IP routed to more than one IP hop and provide incorrect measurement.
GIM>> I believe that the use of loopback as destination address from rouing IP packet. On the other hand, using TTL/Hop Count == 1 does not allow for GTSM being used and, at least in theory, creates an attack vector for DoS. The tunnel is a single hop for the encapsulated STAMP packet. Why not use GTSM?

<RG> As specified in [draft-ietf-ippm-stamp-srpm-00],  the Destination Node Address TLV is applicable to P2P SR Policy.
GIM>> Does that mean that any SR node can send STAMP test packet to the Session-Reflector without the Destination Address TLV and receive the reflected packet? Wouldn't that be a major security concern?
We can add the sentence in this draft as well in the next update.
Thanks,
Rakesh
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 that must be resolved before the adoption of this draft.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 18 Jun 2021 14:42:44 +0000

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

Sent: 07 June 2021 18:04

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 21 Jun 2021 07:50:12 +0000

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 <[email-masked]> On Behalf Of James Guichard
Sent: lunes, 7 de junio de 2021 14:34
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 21 Jun 2021 08:26:58 +0000

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

Thanks,
Cheng

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Jun 2021 10:53:30 +0200

Support.

Thx,
r.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 21 Jun 2021 19:44:19 +0000

Hi Greg,

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

From: [email-masked] <[email-masked]>
Date: Thursday, June 17, 2021 at 10:57 PM
To: Rakesh Gandhi (rgandhi) <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;[email-masked];
CC: [email-masked];[email-masked];
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

Hi Greg,

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

<RG2> The scope of this draft is IP/UDP header based STAMP test packets. We are planning to publish a new draft in MPLS WG to define a new ACH Type.

<RG2> Please see the reply at the top.

<RG2> Please see the reply at the top.

<RG2> Right, the Session-Reflector is not participating in the loopback mode test. This draft is defining the procedure on how to do loopback mode.

<RG2> This is the source port Session-Sender uses.

<RG2> So it looks like the document should be Standards-track.

<RG2> We are Ok to update in the next revision.

<RG2> This is addressed in Section 5, Security Section of [draft-ietf-ippm-stamp-srpm-00].  We are adding following in the next update:

“The Security Considerations specified in [I-D.ietf-ippm-stamp-srpm]
   are also equally applicable to the procedures defined in this document.”

Thanks,
Rakesh

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 21 Jun 2021 21:19:26 +0000

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 <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Wednesday, June 16, 2021 at 2:37 PM
To: James Guichard <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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 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.

>From a measurement and performance metics perspective for SR-MPLS as it reuses the MPLS data plane the preferred method would be to use the entropy label RFC 6790, RFC 8662 for in band native data traffic than using IPv4 as once the packet is labeled the packet is label switched so using a label would be in band and in line with the MPLS forwarding plane.

All of these questions as well as ones mentioned by Greg Mirsky should be addressed by the authors before this draft can be adopted.

Kind Regards

Gyan

On Mon, Jun 7, 2021 at 8:34 AM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG:

Thanks!

Jim, Joel & Bruno

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
--

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

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 21 Jun 2021 17:42:37 -0400

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) <ketant=
[email-masked]> 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?
>
> Sec 4.1.2.1 – isn’t it required that all SLs be monitored? So that would
> be a MUST monitor all SLs?
>
> *From:* spring <[email-masked]> *On Behalf Of *James Guichard
> *Sent:* 07 June 2021 18:04
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [spring] WG Adoption Call for
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 04:57:29 +0800 (CST)

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

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];
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

Hi Greg,
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;[email-masked];
CC: [email-masked];[email-masked];
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
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?

GIM2>> I think that it is helpful to explicitly state the scope of the document. What do you think?

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?
<RG2> Please see the reply at the top.
GIM2>> Thank you for clarifying this in your response. I'm looking forward to the updated version of the draft to clearly state that in the document.

GIM2>> I think that the draft does not define SR encapsulation, whether SR-MPLS or SRv6. Since the test packet is processed by the sender, there's no apparent need in describing how the sender manipulates the packet before transmitting or after receiving it. That is entirely implementation specific and not observable from an outside the system.

GIM2>> I think that is implentation-specific. For example, the Session-Sender might use a special UDP port for self-addressed packets. Would you agree? That is another reason, in my opinion, that there's no value in descrbing the loopback mode in the document.
GIM2>> Not at all. My point is quite clear - the loopback mode, as described in the draft, is not part of STAMP, does not change STAMP and is has no observable from the outside behavior. Thus, it must be removed from the document as not adding any value for a developer.
GIM2>> I am looking forward to reading the updated version.
GIM2>> I couldn't find the lack of the Destination Address TLV in the Session-Sender test packet discussed in the Security Conciderations section of  ietf-ippm-stamp-srpm. Section 3 of that draft that defines the TLV notes that it is optional. And that raises a valid question, if the Destination Address TLV is not present, how the Session-Reflector can verify that it is indeed the intended destination of the STAMP test packet?
Thanks,
Rakesh

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 23 Jun 2021 22:19:05 +0000

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

From: [email-masked] <[email-masked]>
Date: Wednesday, June 23, 2021 at 4:57 PM
To: Rakesh Gandhi (rgandhi) <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];
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

Hi Greg,
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;[email-masked];
CC: [email-masked];[email-masked];
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

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

<RG3> Ok to add.

<RG3> Please see reply above for BFD in loopback mode draft: draft-ietf-bfd-unaffiliated-echo-02.txt, which is a standards-track document.

<RG3> Following text is added in the revised draft, which should cover the case.
“The STAMP Session-Sender sets the Destination UDP port to the UDP port it uses to receive the reply STAMP test packets.”

<RG3> Please see reply above for BFD in loopback mode draft: draft-ietf-bfd-unaffiliated-echo-02.txt, which is a standards-track document.

<RG3> Ok to make the Destination TLV a MUST.

Thanks,
Rakesh

Thanks,
Rakesh

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 09:34:27 +0800 (CST)

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
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];
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

Hi Greg,
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;[email-masked];
CC: [email-masked];[email-masked];
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

Thanks,
Rakesh

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 24 Jun 2021 02:36:44 +0000

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

Date: Wednesday, June 23, 2021 at 9:34 PM

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];
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

Hi Greg,
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;[email-masked];
CC: [email-masked];[email-masked];
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

Thanks,
Rakesh

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Jun 2021 23:03:16 -0400

Thanks Rakesh!

I support WG adoption.

Kind Regards

Gyan

On Mon, Jun 21, 2021 at 5:19 PM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> 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 <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Wednesday, June 16, 2021 at 2:37 PM
> *To: *James Guichard <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *Re: [spring] WG Adoption Call for
> 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.
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Thu, 24 Jun 2021 23:42:13 +0800 (CST)

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
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];
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

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: [email-masked] <[email-masked]>
Date: Wednesday, June 23, 2021 at 9:34 PM
To: Rakesh Gandhi (rgandhi) <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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&D Institute/Wireline Product Operation Division
E: [email-masked]
www.zte.com.cn

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 24 Jun 2021 16:29:31 +0000

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

Regards,
Rakesh

Date: Thursday, June 24, 2021 at 11:42 AM

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];
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

Hi Greg,

Thanks,
Rakesh