Re: [spring] [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

[Rakesh Gandhi (rgandhi)]

Hi WG, Chairs,

I support the WG adoption of this draft. It is a well written draft that 
describes an important use-case of circuit-style SRTE.

Thanks,
Rakesh



From: IETF Secretariat 
Date: Tuesday, May 16, 2023 at 10:04 AM
To: draft-schmutzer-spring-cs-sr-pol...@ietf.org 
, spring-cha...@ietf.org 
, spring@ietf.org 
Subject: [**EXTERNAL**] The SPRING WG has placed 
draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state
Candidate for WG Adoption (entered by Joel Halpern)

The document is available at
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-schmutzer-spring-cs-sr-policy/__;!!OSsGDw!PrF5MLj2VoK47BuWO76oeewImBaGMafe294qNONXqhmq7i57ixXHdL_zK2azlh1DsID1fgczKQ2sDmGvgCW8AZU$
 [datatracker[.]ietf[.]org]

Comment:
This starts a two week adoption call for the subject draft.  Please speak up
if you support or object to WG adoption.  Two notes: 1) WG adoption is the
start of the process.  The basic question is whether you agree that the
subject is worth the working group time to work on, and whether this
represents a good starting point for the work. 2) Please include explanation
for your view.  Yes or no are not very helpful answers, as this is not a vote
but an evaluation of support and concerns. Thank you, Joel (for the WG Chairs)

We expect to close this call at the end of May, 2023.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Rakesh Gandhi (rgandhi)]

Hi Chairs, WG,



Network programming model [RFC8986] defines multiple flavors of End, End.X, and 
End.T SIDs. CSID draft builds on it with next and replace flavors for these 
SIDs. The draft reports multivendor interop was done to show co-existence of 
next and replace flavors. This is evidence that these flavors work seamless 
using SRH based single data plane.



I strongly support the adoption call.

Thanks,
Rakesh


Da: spring  James Guichard
Inviato: venerdì 1 ottobre 2021 16:05
A: SPRING WG 
Cc: spring-cha...@ietf.org
Oggetto: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


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

Re: [spring] New Version Notification for draft-gandhi-spring-enhanced-srpm-00.txt

[Rakesh Gandhi (rgandhi)]

Hi WG,

We have published a new draft on SRPM enhancements using “Simple TWAMP”.  It is 
extension of the SRPM defined in draft-ietf-spring-stamp-srpm.

Welcome your review comments and suggestions.

Thanks,
Rakesh (for authors)
P.S. This draft replaces and builds on the previous work in 
draft-gandhi-spring-sr-enhanced-plm that was using custom packets.


From: internet-dra...@ietf.org 
Date: Tuesday, August 24, 2021 at 5:47 PM

Subject: New Version Notification for draft-gandhi-spring-enhanced-srpm-00.txt

A new version of I-D, draft-gandhi-spring-enhanced-srpm-00.txt
has been successfully submitted by Rakesh Gandhi and posted to the
IETF repository.

Name:   draft-gandhi-spring-enhanced-srpm
Revision:   00
Title:  Enhanced Performance Measurement Using Simple TWAMP in Segment 
Routing Networks
Document date:  2021-08-24
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/archive/id/draft-gandhi-spring-enhanced-srpm-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-gandhi-spring-enhanced-srpm/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gandhi-spring-enhanced-srpm


Abstract:
   Segment Routing (SR) leverages the source routing paradigm.  SR is
   applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
   (SRv6) data planes.  This document defines procedure for Enhanced
   Performance Measurement of end-to-end SR paths including SR Policies
   for both SR-MPLS and SRv6 data planes using Simple Two-Way Active
   Measurement Protocol (STAMP) defined in RFC 8762.  The procedure
   reduces the deployment and operational complexities in a network.




The IETF Secretariat

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

Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

[Rakesh Gandhi (rgandhi)]

Hi WG,
As a co-author, I have read the latest version of the draft and I believe it is 
ready for publication.

I am not aware of any undisclosed IPR related to this document.

Thanks,
Rakesh


From: spring  on behalf of James Guichard 

Date: Wednesday, July 7, 2021 at 11:49 AM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WGLC for 
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-mpls-path-segment [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than July 21st 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributor please response to indicate whether 
you know of any undisclosed IPR related to this document.

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/




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

Re: [spring] WG adoption call completion for https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/

[Rakesh Gandhi (rgandhi)]

Thank you WG for your review and support for this document. Welcome your 
further review comments and suggestions.

I am not aware of any undisclosed IPR related to this document.

Thanks,
Rakesh


From: spring  on behalf of James Guichard 

Date: Tuesday, July 6, 2021 at 11:08 AM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WG adoption call completion for 
https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/
Dear WG:

This email ends the WG adoption call for 
https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/. Thank you for 
your feedback and comments.

Having reviewed the mailing list responses, the chairs believe that there is 
enough support for adoption of this document into the WG. Therefore authors 
please resubmit the document as draft-spring-stamp-srpm-00.

Note: there were several comments received during the adoption call that appear 
to have been addressed by the authors in v07 (just posted). However, if any 
comments/concerns are still outstanding then we expect to see those resolved as 
part of the WG process and ask that the authors of this document please work 
with the people that commented to resolve any open issues.

Finally, authors please indicate on the mailing list whether you are aware of 
any undisclosed IPR relevant to this document.

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

[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

[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

[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

[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
 as a WG document. In a previous communication (December 16th 2020), the SPRING 
chairs decided not to adopt 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt into the 
WG until its companion document was accepted by the IPPM WG. This has now 
happened and therefore we feel it is now time to revisit the WG adoption of the 
SPRING document.

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

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

Thanks!

Jim, Joel & Bruno



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

[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

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

[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

[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. But 

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

[spring] FW: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

[Rakesh Gandhi (rgandhi)]

Thanks Greg for your comments. Please see inline, I have added some replies 
below inline with …

From: Greg Mirsky 
Date: Thursday, November 19, 2020 at 12:28 PM
To: Mach Chen 
Cc: Tianran Zhou , Rakesh Gandhi (rgandhi) 
, spring , IPPM Chairs 
, spring-cha...@ietf.org , Tommy 
Pauly , IETF IPPM WG (i...@ietf.org) 
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
Hi Mach,
thank you for your email. I've added my understanding of what has been proposed 
in-line tagged GIM>>.

Regards,
Greg

On Wed, Nov 18, 2020 at 11:41 PM Mach Chen 
mailto:mach.c...@huawei.com>> wrote:
Hi Tianran, Rakesh and Greg,
 Please see some responses inline with [Mach]…
From: ippm [mailto:ippm-boun...@ietf.org<mailto:ippm-boun...@ietf.org>] On 
Behalf Of Tianran Zhou
Sent: Thursday, November 19, 2020 1:33 PM
To: Rakesh Gandhi (rgandhi) 
mailto:40cisco@dmarc.ietf.org>>; Greg 
Mirsky mailto:gregimir...@gmail.com>>
Cc: spring mailto:spring@ietf.org>>; IPPM Chairs 
mailto:ippm-cha...@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; Tommy Pauly 
mailto:40apple@dmarc.ietf.org>>; IETF 
IPPM WG (i...@ietf.org<mailto:i...@ietf.org>) 
mailto:i...@ietf.org>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
 Hi Rakesh and Greg,
I may not very clear about the context. Please allow me to jump in.
It seems both of you make some valid point.
Please see in line with .
Cheers,
Tianran
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rakesh Gandhi 
(rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky mailto:gregimir...@gmail.com>>
Cc: spring mailto:spring@ietf.org>>; IPPM Chairs 
mailto:ippm-cha...@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; Tommy Pauly 
mailto:tpauly=40apple@dmarc.ietf.org>>; 
IETF IPPM WG (i...@ietf.org<mailto:i...@ietf.org>) 
mailto:i...@ietf.org>>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm 
and draft-gandhi-ippm-stamp-srpm
 Hi Greg,
Thank you for your review and discussions on the drafts. This will help improve 
the work on this important work.
Please see replies inline with ..

 From: Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Tuesday, November 17, 2020 at 5:27 PM
To: Rakesh Gandhi (rgandhi) mailto:rgan...@cisco.com>>
Cc: Tommy Pauly 
mailto:tpauly=40apple@dmarc.ietf.org>>, 
IPPM Chairs mailto:ippm-cha...@ietf.org>>, 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>, IETF IPPM WG 
(i...@ietf.org<mailto:i...@ietf.org>) mailto:i...@ietf.org>>, 
spring mailto:spring@ietf.org>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
Hi Rakesh, WG Chairs, and All,
I've read the responses to my detailed comments. I don't think that only adding 
references will solve the problems with the documents. If authors are 
interested in addressing my comments, we can start working on solving them one 
by one.
  As mentioned in previous replies, we can add references for the 
well-known terms “Links”, “Congruent Paths”, “SR Path”. If you prefer, we can 
define them here. For Zero checksum field, we can add a reference for the RFC 
6936 in Security section and also add some text for it. Will be happy to work 
with you to address these.
 But I am very much concerned with the technical value of these drafts. And 
here's why I feel that the proposed documents don't provide a sound technical 
solution to the task of direct loss measurement. Please find my reasoning 
explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

  *   What is being proposed in these drafts?
Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support direct 
packet loss measurements. Note, that RFC 6374 includes a method for direct loss 
measurement in MPLS networks that is applicable to the SR-MPLS environment. 
Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, 
the Direct Measurement TLV, that supports the direct packet loss measurement. 
STAMP and all its extensions are applicable in IPv6 networks and, thus, can be 
used in the SRv6 domain.
  As mentioned in previous replies, both RFC 6374 (in Section 4.2) and ITU 
Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and RX 
counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the 
drafts are equivalent of them that take advantage of the widely deployed TWAMP 
protocol and as well this same protocol can be deployed in 
IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.
  I think RFC6374 for MPLS and Y.1731 make some noise here. The point is 
if we need a new direct packet loss measurement for STAMP, when STAMP already 
defined a Direct Measurement TLV 
(https://datatracker.ietf.o

Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

[Rakesh Gandhi (rgandhi)]

Thanks Tianran for the review comments. We will address the comment in the next 
revision of the document.

Thanks,
Rakesh


From: Tianran Zhou 
Date: Thursday, November 19, 2020 at 8:28 PM
To: Rakesh Gandhi (rgandhi) , Mach Chen 
, Greg Mirsky 
Cc: spring , IPPM Chairs , 
spring-cha...@ietf.org , Tommy Pauly 
, IETF IPPM WG (i...@ietf.org) 
Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
Hi Mach and Rakesh,

Thanks for your reply. I am now much more clear.
But I really think the draft should add more text on the motivation and use 
case.  It would be very helpful for the audience to understand.
For example, one of my question about the new direct measurement.
There is rare word on how to use it, how it’s different from existing stamp 
direct measurement tlv.
Anyway, I find some valuable extensions in these two drafts. I would like to 
support the adoption and help to improve this document.

Best,
Tianran


From: Rakesh Gandhi (rgandhi) [mailto:rgan...@cisco.com]
Sent: Thursday, November 19, 2020 11:15 PM
To: Mach Chen ; Tianran Zhou ; 
Greg Mirsky 
Cc: spring ; IPPM Chairs ; 
spring-cha...@ietf.org; Tommy Pauly ; IETF IPPM WG 
(i...@ietf.org) 
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm

Thank you Mach and Tianran for your review comments.
Please see inline reply with …

From: Mach Chen mailto:mach.c...@huawei.com>>
Date: Thursday, November 19, 2020 at 2:41 AM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>, 
Rakesh Gandhi (rgandhi) mailto:rgan...@cisco.com>>, Greg 
Mirsky mailto:gregimir...@gmail.com>>
Cc: spring mailto:spring@ietf.org>>, IPPM Chairs 
mailto:ippm-cha...@ietf.org>>, 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>, Tommy Pauly 
mailto:tpa...@apple.com>>, IETF IPPM WG 
(i...@ietf.org<mailto:i...@ietf.org>) mailto:i...@ietf.org>>
Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
Hi Tianran, Rakesh and Greg,

Please see some responses inline with [Mach]…

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, November 19, 2020 1:33 PM
To: Rakesh Gandhi (rgandhi) 
mailto:rgandhi=40cisco@dmarc.ietf.org>>;
 Greg Mirsky mailto:gregimir...@gmail.com>>
Cc: spring mailto:spring@ietf.org>>; IPPM Chairs 
mailto:ippm-cha...@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; Tommy Pauly 
mailto:tpauly=40apple@dmarc.ietf.org>>; 
IETF IPPM WG (i...@ietf.org<mailto:i...@ietf.org>) 
mailto:i...@ietf.org>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm

Hi Rakesh and Greg,

I may not very clear about the context. Please allow me to jump in.
It seems both of you make some valid point.
Please see in line with .

Cheers,
Tianran

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rakesh Gandhi 
(rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky mailto:gregimir...@gmail.com>>
Cc: spring mailto:spring@ietf.org>>; IPPM Chairs 
mailto:ippm-cha...@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; Tommy Pauly 
mailto:tpauly=40apple@dmarc.ietf.org>>; 
IETF IPPM WG (i...@ietf.org<mailto:i...@ietf.org>) 
mailto:i...@ietf.org>>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm 
and draft-gandhi-ippm-stamp-srpm

Hi Greg,

Thank you for your review and discussions on the drafts. This will help improve 
the work on this important work.
Please see replies inline with ..


From: Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Tuesday, November 17, 2020 at 5:27 PM
To: Rakesh Gandhi (rgandhi) mailto:rgan...@cisco.com>>
Cc: Tommy Pauly 
mailto:tpauly=40apple@dmarc.ietf.org>>, 
IPPM Chairs mailto:ippm-cha...@ietf.org>>, 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>, IETF IPPM WG 
(i...@ietf.org<mailto:i...@ietf.org>) mailto:i...@ietf.org>>, 
spring mailto:spring@ietf.org>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
Hi Rakesh, WG Chairs, and All,
I've read the responses to my detailed comments. I don't think that only adding 
references will solve the problems with the documents. If authors are 
interested in addressing my comments, we can start working on solving them one 
by one.

 As mentioned in previous replies, we can add references for the well-known 
terms “Links”, “Congruent Paths”, “SR Path”. If you prefer, we can define them 
here. For Zero checksum field, we can add a reference for the RFC 6936 in 
Security section and also add some text for it. Will be happy to work with you 
to address these.

But I am very much concerned w

Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

[Rakesh Gandhi (rgandhi)]

Thank you Mach and Tianran for your review comments.
Please see inline reply with …

From: Mach Chen 
Date: Thursday, November 19, 2020 at 2:41 AM
To: Tianran Zhou , Rakesh Gandhi (rgandhi) 
, Greg Mirsky 
Cc: spring , IPPM Chairs , 
spring-cha...@ietf.org , Tommy Pauly 
, IETF IPPM WG (i...@ietf.org) 
Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
Hi Tianran, Rakesh and Greg,

Please see some responses inline with [Mach]…

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, November 19, 2020 1:33 PM
To: Rakesh Gandhi (rgandhi) ; Greg Mirsky 

Cc: spring ; IPPM Chairs ; 
spring-cha...@ietf.org; Tommy Pauly ; IETF 
IPPM WG (i...@ietf.org) 
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm

Hi Rakesh and Greg,

I may not very clear about the context. Please allow me to jump in.
It seems both of you make some valid point.
Please see in line with .

Cheers,
Tianran

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rakesh Gandhi 
(rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky mailto:gregimir...@gmail.com>>
Cc: spring mailto:spring@ietf.org>>; IPPM Chairs 
mailto:ippm-cha...@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; Tommy Pauly 
mailto:tpauly=40apple@dmarc.ietf.org>>; 
IETF IPPM WG (i...@ietf.org<mailto:i...@ietf.org>) 
mailto:i...@ietf.org>>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm 
and draft-gandhi-ippm-stamp-srpm

Hi Greg,

Thank you for your review and discussions on the drafts. This will help improve 
the work on this important work.
Please see replies inline with ..


From: Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Tuesday, November 17, 2020 at 5:27 PM
To: Rakesh Gandhi (rgandhi) mailto:rgan...@cisco.com>>
Cc: Tommy Pauly 
mailto:tpauly=40apple@dmarc.ietf.org>>, 
IPPM Chairs mailto:ippm-cha...@ietf.org>>, 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>, IETF IPPM WG 
(i...@ietf.org<mailto:i...@ietf.org>) mailto:i...@ietf.org>>, 
spring mailto:spring@ietf.org>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
Hi Rakesh, WG Chairs, and All,
I've read the responses to my detailed comments. I don't think that only adding 
references will solve the problems with the documents. If authors are 
interested in addressing my comments, we can start working on solving them one 
by one.

 As mentioned in previous replies, we can add references for the well-known 
terms “Links”, “Congruent Paths”, “SR Path”. If you prefer, we can define them 
here. For Zero checksum field, we can add a reference for the RFC 6936 in 
Security section and also add some text for it. Will be happy to work with you 
to address these.

But I am very much concerned with the technical value of these drafts. And 
here's why I feel that the proposed documents don't provide a sound technical 
solution to the task of direct loss measurement. Please find my reasoning 
explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

  *   What is being proposed in these drafts?
Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support direct 
packet loss measurements. Note, that RFC 6374 includes a method for direct loss 
measurement in MPLS networks that is applicable to the SR-MPLS environment. 
Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, 
the Direct Measurement TLV, that supports the direct packet loss measurement. 
STAMP and all its extensions are applicable in IPv6 networks and, thus, can be 
used in the SRv6 domain.

 As mentioned in previous replies, both RFC 6374 (in Section 4.2) and ITU 
Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and RX 
counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the 
drafts are equivalent of them that take advantage of the widely deployed TWAMP 
protocol and as well this same protocol can be deployed in 
IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.

 I think RFC6374 for MPLS and Y.1731 make some noise here. The point is if 
we need a new direct packet loss measurement for STAMP, when STAMP already 
defined a Direct Measurement TLV 
(https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If current 
Direct Measurement TLV cannot fulfill some use case requirement, then how about 
proposing a new TLV.

[Mach] Given that TWAMP does not support TLV, I assume that the discussions are 
mainly about draft*-stamp-srpm.

[Mach] In the case of direct packet loss measurement, 
draft-gandhi-ippm-stamp-srpm assumes that marking-based solution (which can 
address the packet out-ordering issue) is used, hence the block number is 
introduced. The block number is used to correlate the counters from th

Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

[Rakesh Gandhi (rgandhi)]

Hi Greg,

Thank you for your review and discussions on the drafts. This will help improve 
the work on this important work.
Please see replies inline with ..


From: Greg Mirsky 
Date: Tuesday, November 17, 2020 at 5:27 PM
To: Rakesh Gandhi (rgandhi) 
Cc: Tommy Pauly , IPPM Chairs 
, spring-cha...@ietf.org , IETF 
IPPM WG (i...@ietf.org) , spring 
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm
Hi Rakesh, WG Chairs, and All,
I've read the responses to my detailed comments. I don't think that only adding 
references will solve the problems with the documents. If authors are 
interested in addressing my comments, we can start working on solving them one 
by one.

 As mentioned in previous replies, we can add references for the well-known 
terms “Links”, “Congruent Paths”, “SR Path”. If you prefer, we can define them 
here. For Zero checksum field, we can add a reference for the RFC 6936 in 
Security section and also add some text for it. Will be happy to work with you 
to address these.

But I am very much concerned with the technical value of these drafts. And 
here's why I feel that the proposed documents don't provide a sound technical 
solution to the task of direct loss measurement. Please find my reasoning 
explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

  *   What is being proposed in these drafts?
Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support direct 
packet loss measurements. Note, that RFC 6374 includes a method for direct loss 
measurement in MPLS networks that is applicable to the SR-MPLS environment. 
Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, 
the Direct Measurement TLV, that supports the direct packet loss measurement. 
STAMP and all its extensions are applicable in IPv6 networks and, thus, can be 
used in the SRv6 domain.

 As mentioned in previous replies, both RFC 6374 (in Section 4.2) and ITU 
Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and RX 
counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the 
drafts are equivalent of them that take advantage of the widely deployed TWAMP 
protocol and as well this same protocol can be deployed in 
IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.


  *   How the proposed method of direct packet loss is related to TWAMP light 
and STAMP?
There's no apparent technical relationship between *-twamp-srpm and TWAMP 
Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the 
basic mechanisms defined for  TWAMP-Test and/or STAMP in their respective 
specifications. Rather than that, drafts introduce a new query-response mode 
and new formats of test packets that are decisively different from the formats 
defined in respective specifications. As a result, the new protocols are 
required to use different from used by TWAMP Light tr STAMP test session UDP 
port numbers on the responder. And that is another clear indication that the 
proposed mechanism represents a new protocol, neither extends TWAMP Light 
and/or STAMP nor updates their specifications.

 As mentioned in previous replies, other than timestamp vs. counter and 
it’s format, the messages and processing of them are the same for delay and 
direct-mode loss measurement.

  *   Is there any advantage in introducing a dedicated packet format for the 
direct packet loss in STAMP comparing to using the Direct Measurement TLV 
extension?
Though it appears the using a dedicated packet format instead of TLV is more 
efficient, but the dedicated for the direct loss measurement format is likely 
to precede one or even two TLVs, Node Address TLV and Path TLV, defined in 
draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with 
TLVs is unlikely to be more efficient and reduce the processing delay, than if 
using the Direct Measurement TLV as defined in draft-ietf-ippm-stamp-option-tlv.

 As mentioned in previous replies, this is explained in Section 1 of the 
draft-gandhi-spring-stamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/>.
 For link loss measurement (direct-mode), there is no TLV required for example. 
For direct-mode loss measurement in SR networks, it would typically be forward 
direction packet loss measurement (and not bidirectional).



  *   What are the potential benefits of specifying the return path in the new 
test packet's Sender Control Code?
Using the Sender Control Code may require the use of the additional TLV that 
carries the return path information, Path TLV. If the ability to control the 
return path is required that can be achieved by augmenting the STAMP YANG data 
model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each 
test packet. Hence, there seem no technical requirements to introduce the 
Sender Control Code field in the Base STAMP format defined in RFC 8762.

 Per session basis between different sender nodes and this ref

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

[Rakesh Gandhi (rgandhi)]

Hi Jingrong,
Many thanks for your review comments. We will address them in the next updates 
of the document.

Thanks,
Rakesh


From: spring 
Date: Monday, November 2, 2020 at 2:04 AM
To: James Guichard , spring@ietf.org 

Cc: ippm-cha...@ietf.org , spring-cha...@ietf.org 

Subject: Re: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
Hi working-group:

I support the adoption, and I have the following questions:

1. Section 4.1.4.2 and 4.2.2.2 depict the packet format with word “as needed” 
for inner IP Header.  Can authors please clarify in which case(s) it is needed 
and in which it is not.
2. Section 4.3.1 “Destination ipv6 address from the :::127/104 range”, and 
Section 4.1.4 “the loopback address ::1/128 for IPv6”, are they different cases 
or same case ?

Thanks
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Thursday, October 22, 2020 8:52 PM
To: spring@ietf.org
Cc: ippm-cha...@ietf.org; spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Dear WG:

This message starts a 3 week WG adoption call for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 
12th 2020. Please note that this document has several changes from v-10 that 
were requested by the SPRING and IPPM chairs. For this reason, the chairs have 
extended the adoption call for an additional week to allow the WG enough time 
to review these changes before deciding on WG adoption.

Some background:

Several review comments were received previously for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and 
IPPM chairs considered those comments, and upon review of this version of the 
document, determined the following:


  *   The SPRING document should describe only the procedures relevant to 
SPRING with pointers to non-SPRING document/s that define any extensions. 
Several extensions including Control Code Field Extension for TWAMP Light 
Messages, Loss Measurement Query Message Extensions, and Loss Measurement 
Response Message Extensions were included in 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and should be 
removed from the SPRING document.
  *   The TWAMP extensions included in 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should be 
described in a new document published in the IPPM WG.

These conclusions were discussed with the authors of  
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result of 
which is the publication of the following two documents:


  *   https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The 
subject of this WG adoption call.
  *   https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This 
document will be progressed (if determined by the WG) within the IPPM WG.

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.

Finally, the chairs would like to thank the authors for their efforts in this 
matter.

Thanks!

Jim, Bruno, & Joel





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

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

[Rakesh Gandhi (rgandhi)]

Thanks Loa,
We will add the expansion of the abbreviation in the next update.

Thanks,
Rakesh

From: spring 
Date: Friday, October 30, 2020 at 12:31 AM
To: Chengli (Cheng Li) , James Guichard 
, spring@ietf.org 
Cc: ippm-cha...@ietf.org , spring-cha...@ietf.org 

Subject: Re: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
Working Group,

I support adopting this document.

However I have one question; if it leads to (very small) changes in the
document, this can be done after the adoption.

I'm looking at

HMAC-SHA: Consists of two parts
HMAC: Hashed Message Authentication Code (expanded in the document).
SHA: Secure Hash Algorithm (not expanded, but on the other hand it an
 well-known abbreviation)

When we combine two abbreviations what rules apply, is it enough that
eachpart is expanded "somewhere" even if the parts are found at
different places. Or does the rule "expand at first occurrence apply?

I guess that in part this depends on whether we view HMAC-SHA as one
unit or two separate parts? And how familiar we believe our readers are
with the abbreviations.

I don't have a strong opinion on this, but would suggest that we place
HMAC-SHA in the "Abbreviations" in section 2.2 and expamnd it fully.

On 30/10/2020 10:01, Chengli (Cheng Li) wrote:
> Hi WG,
>
> Support. However, there are some encoding format changes among versions,
> hope the encoding format can be stable in the following revision ASAP.
>
> Many thanks for the authors’ contribution!
>
> Thanks,
>
> Cheng
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *James
> Guichard
> *Sent:* Thursday, October 22, 2020 8:52 PM
> *To:* spring@ietf.org
> *Cc:* ippm-cha...@ietf.org; spring-cha...@ietf.org
> *Subject:* [spring] WG Adoption Call for
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
>
> Dear WG:
>
> This message starts a 3 week WG adoption call for document
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending
> November 12^th 2020. Please note that this document has several changes
> from v-10 that were requested by the SPRING and IPPM chairs. For this
> reason, the chairs have extended the adoption call for an additional
> week to allow the WG enough time to review these changes before deciding
> on WG adoption.
>
> Some background:
>
> Several review comments were received previously for document
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The
> SPRING and IPPM chairs considered those comments, and upon review of
> this version of the document, determined the following:
>
>   * The SPRING document should describe only the procedures relevant to
> SPRING with pointers to non-SPRING document/s that define any
> extensions. Several extensions including*Control Code Field
> Extension for TWAMP Light Messages*, *Loss Measurement Query Message
> Extensions*, and *Loss Measurement Response Message Extensions *were
> included in
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and
> should be removed from the SPRING document.
>   * The TWAMP extensions included in
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should
> be described in a new document published in the IPPM WG.
>
> These conclusions were discussed with the authors of
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result
> of which is the publication of the following two documents:
>
>   * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The
> subject of this WG adoption call.
>   * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This
> document will be progressed (if determined by the WG) within the
> IPPM WG.
>
> 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.
>
> Finally, the chairs would like to thank the authors for their efforts in
> this matter.
>
> Thanks!
>
> Jim, Bruno, & Joel
>
> //
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>

--

Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

___
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] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

[Rakesh Gandhi (rgandhi)]

Thank you Greg for taking time for thoroughly reviewing the documents and 
providing the comments. Note that many of the comments here on STAMP draft are 
repeated from the previous comments on the TWAMP Light draft. Please see 
replies inline with . The repeated comments are tagged with  to avoid 
duplicated discussions.

From: ippm 
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard 
Cc: spring@ietf.org , ippm-cha...@ietf.org 
, spring-cha...@ietf.org , IETF 
IPPM WG 
Subject: Re: [ippm] [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03
Dear Chairs of the SPRING and IPPM WGs, Authors, et al.,
I've found myself in the situation when two related drafts are in the WG APs in 
the SPRING and IPPM WG (with the possibility that expertise from the third WG, 
BFD WG, might be desirable to review the "liveness monitoring"). Because these 
drafts are closely related, I've decided to combine my questions and comments 
in a single thread. I hope that would be acceptable and considered by the 
SPRING WG as well as IPPM WG.
Usually, the bar for the adoption of a document can be evaluated by answers to 
these three questions:

  *   Is the document(s) reasonably well-written
It was a surprise finding out that both drafts don't use the terminology from 
RFC 8762 STAMP and introduce their own terminology for Session-Sender and 
Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used 
in the documents without proper definitions. Other than that, both drafts are 
readable.

 We can change Sender to Session-Sender and Reflector to 
Session-Reflector if it helps.
 There are many existing RFCs that use term Link (e.g. RFC 5613, 5340, 
8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without defining 
them. I suspect it is because these are well-known terms. Having said that, we 
can add a reference for them if it helps.

  *   Does the document solve a real problem?
No, it appears that the changes described in these drafts are only to achieve 
in-band collection of counters of "in-profile" packets. Firstly, drafts don't 
provide any arguments about why such collection should be performed using the 
in-band method rather than using the out-of-band collection approach. Secondly, 
even if there are any benefits of in-band collection, that can be more easily 
achieved by extending other OAM, e.g., ICMP, tools.

 There is a requirement to measure performance delay as well as synthetic 
and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP 
protocols are widely deployed for performance delay and synthetic packet loss 
measurement today. I am not sure extending ICMP for LM is a good option here.

  *   Is the proposed solution technically viable?
There are too many unaddressed aspects, particularly the risk introduced by the 
protocol on network security, to comprehensively evaluate the proposed solution.
 About your comment on zero checksum, this is described in Security 
section in RFC 6936. We will add reference to this RFC in our Security Section 
as well. This is only specific to the UDP port locally provisioned in the 
domain by the operator for STAMP. Other than this, I did not find any other 
security related issue in your review below.
draft-gandhi-spring-stamp-srpm

  *   Can you define a Link and how it is different from an SR Path?
 There are many existing RFCs that use term “Link” (e.g. RFC 5613, 5340, 
8330, etc.). Similarly term “SR Path” has been used in existing RFCs (e.g. 
8664). I suspect these are well-known terms.

  *   It is not clear how the destination UDP port numbers are selected. Does 
the draft change procedure defined in Section 4.1 RFC 8762?
 There is no change.

  *   It is not clear what "the congruent path" means. The definition of the 
congruent in geometry tells that a congruent object has the same shape and 
size, but is allowed to flip, slide or turn. How a path can be congruent to 
another path?
 There are many existing RFCs that use term “Congruent Path” (e.g. RFC 
5921, 6669) without defining them. I suspect it is because it is well-known 
term. Having said that, we can add a reference for it if it helps reader.

  *   An example of the provisional model is Section 3.1 seems well-suited for 
a YANG data model. What changes to the STAMP YANG data model defined in 
draft-ietf-ippm-stamp-yang 
  proposed in 
these drafts?
 Yes, this can be Yang model. We can review draft-ietf-ippm-stamp-yang 
 and add any 
missing items in a separate draft. We can also add a reference in this draft.

  *   In Section 4.1 noted that
   The probe messages defined in [RFC8762] are used for delay
   measurement for Links and end-to-end SR Paths including SR Policies.
   For loss measurement, the probe messages defined in [I-D.gandhi-ippm-
   stamp-srpm] are used.
It necessary to point that 

Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

[Rakesh Gandhi (rgandhi)]

Hi IPPM WG,
I support the WG adoption of the following two IPPM drafts (as a co-author).

https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00
https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00

Keeping SPRING WG in the loop as well for this adoption request for the 
necessary protocol extensions drafts progressing in IPPM WG.

Thanks,
Rakesh



From: ippm  on behalf of Tommy Pauly 

Date: Friday, October 30, 2020 at 2:35 PM
To: "IETF IPPM WG (i...@ietf.org)" 
Cc: IPPM Chairs , "spring-cha...@ietf.org" 

Subject: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and 
draft-gandhi-ippm-stamp-srpm

Hello IPPM,

For the past few meetings, we’ve had updates on the work in the SPRING WG that 
was using STAMP and TWAMP. Since those documents ended up making extensions to 
the base protocols, the chairs of SPRING and IPPM decided that it would be best 
to split the documents and track the IPPM extension work in the IPPM WG.

As such, we are starting a Working Group call for adoption for 
draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.

The documents are here:

https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00
https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00

The related SPRING documents are here:

https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Please provide your feedback on these documents, and state whether or not you 
believe the IPPM WG should adopt this work by replying to this email. Please 
provide your feedback by the start of the IETF 109 meeting week, on Monday, 
November 16.

Best,
Tommy & Ian
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

[Rakesh Gandhi (rgandhi)]

Hi WG,

The STAMP SRPM draft defines procedures for performance delay and loss 
measurement in SR-MPLS and SRv6 networks. I support the WG adoption of the 
draft (as a co-author).

Thanks,
Rakesh


From: spring  on behalf of James Guichard 

Date: Thursday, October 22, 2020 at 8:52 AM
To: "spring@ietf.org" 
Cc: "ippm-cha...@ietf.org" , "spring-cha...@ietf.org" 

Subject: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

Dear WG:

This message starts a 3 week WG adoption call for 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending November 
12th 2020. Please note that this document has several changes from v-02 that 
were requested by the SPRING and IPPM chairs. For this reason, the chairs have 
extended the adoption call for an additional week to allow the WG enough time 
to review these changes before deciding on WG adoption.

Some background:

Several review comments were received previously for document 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING and 
IPPM chairs considered those comments, and upon review of this version of the 
document, determined the following:


  *   The SPRING document should describe only the procedures relevant to 
SPRING with pointers to non-SPRING document/s that define any extensions. 
Several extensions including Control Code Field Extension for STAMP Messages, 
Loss Measurement Query Message Extensions, Loss Measurement Response Message 
Extensions, Node Address TLV Extensions, and Return Path TLV Extensions were 
included in https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and 
should be removed from the SPRING document.
  *   The STAMP extensions included in 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 should be 
described in a new document published in the IPPM WG.

These conclusions were discussed with the authors of 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the result of 
which is the publication of the following two documents:


  *   https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The 
subject of this WG adoption call.
  *   https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This 
document will be progressed (if determined by the WG) within the IPPM WG.

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.

Finally, the chairs would like to thank the authors for their efforts in this 
matter.

Thanks!

Jim, Bruno, & Joel
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

[Rakesh Gandhi (rgandhi)]

Hi WG,

The TWAMP draft for SRPM defines procedures for performance delay and loss 
measurement in SR-MPLS and SRv6 networks. I support the WG adoption of the 
draft (as a co-author).

Thanks,
Rakesh


From: spring  on behalf of James Guichard 

Date: Thursday, October 22, 2020 at 8:52 AM
To: "spring@ietf.org" 
Cc: "ippm-cha...@ietf.org" , "spring-cha...@ietf.org" 

Subject: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Dear WG:

This message starts a 3 week WG adoption call for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 
12th 2020. Please note that this document has several changes from v-10 that 
were requested by the SPRING and IPPM chairs. For this reason, the chairs have 
extended the adoption call for an additional week to allow the WG enough time 
to review these changes before deciding on WG adoption.

Some background:

Several review comments were received previously for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and 
IPPM chairs considered those comments, and upon review of this version of the 
document, determined the following:


  *   The SPRING document should describe only the procedures relevant to 
SPRING with pointers to non-SPRING document/s that define any extensions. 
Several extensions including Control Code Field Extension for TWAMP Light 
Messages, Loss Measurement Query Message Extensions, and Loss Measurement 
Response Message Extensions were included in 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and should be 
removed from the SPRING document.
  *   The TWAMP extensions included in 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should be 
described in a new document published in the IPPM WG.

These conclusions were discussed with the authors of  
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result of 
which is the publication of the following two documents:


  *   https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The 
subject of this WG adoption call.
  *   https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This 
document will be progressed (if determined by the WG) within the IPPM WG.

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.

Finally, the chairs would like to thank the authors for their efforts in this 
matter.

Thanks!

Jim, Bruno, & Joel




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

Re: [spring] draft-gandhi-spring-sr-enhanced-plm / draft-gandhi-spring-stamp-srpm

[Rakesh Gandhi (rgandhi)]

Hi Thomas,

Please see replies inline with …

From: 
Date: Monday, July 27, 2020 at 8:49 AM
To: "=SMTP:rgandhi@cisco. com" 
Cc: 
Subject: draft-gandhi-spring-sr-enhanced-plm / draft-gandhi-spring-stamp-srpm


Hi Rakesh,



Thanks for the presentations at spring wg.



For clarification, I assume that the controller will be able to orchestrate and 
collect the results of the STAMP probes with netconf-yang/yang push based on 
draft-ietf-ippm-stamp-yang. Correct?



 draft-ietf-ippm-stamp-yang supports Netconf/Yang using a STAMP session ID. 
Controller can use the STAMP session ID of an SR Path for this purpose.



If yes, I assume that the STAMP extensions described in 
draft-gandhi-spring-stamp-srpm will be integrated into 
draft-ietf-ippm-stamp-yang?



 Some SR specific extension may be needed for draft-ietf-ippm-stamp-yang in 
future.



 Is there a open source implementation, proof of code I could look at?



 I am not aware of it.  Adding IPPM WG in case there exists one.



Thanks,

Rakesh





Best Wishes

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

[spring] Updated draft-gandhi-spring-twamp-srpm-04.txt

[Rakesh Gandhi (rgandhi)]

Hi WG,
We have posted a new revision that now includes support for STAMP 
[draft-ietf-ippm-stamp] for SR. Welcome your review comments and suggestions.

Thanks,
Rakesh (for authors)


On 2019-11-04, 4:16 PM, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-gandhi-spring-twamp-srpm-04.txt
has been successfully submitted by Rakesh Gandhi and posted to the
IETF repository.

Name:   draft-gandhi-spring-twamp-srpm
Revision:   04
Title:  Performance Measurement Using TWAMP Light for Segment 
Routing Networks
Document date:  2019-11-04
Group:  Individual Submission
Pages:  28
URL:
https://www.ietf.org/internet-drafts/draft-gandhi-spring-twamp-srpm-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/
Htmlized:   
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gandhi-spring-twamp-srpm
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-gandhi-spring-twamp-srpm-04

Abstract:
   Segment Routing (SR) leverages the source routing paradigm.  SR is
   applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
   (SRv6) data planes.  This document specifies procedure for sending
   and processing probe query and response messages for Performance
   Measurement (PM) in Segment Routing networks.  The procedure uses the
   mechanisms defined in RFC 5357 (Two-Way Active Measurement Protocol
   (TWAMP) Light) and Simple Two-Way Active Measurement Protocol (STAMP)
   for Delay Measurement, and also uses the mechanisms defined in this
   document for Loss Measurement.  The procedure specified is applicable
   to SR-MPLS and SRv6 data planes and are used for both links and
   end-to-end SR Policies.



  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

Re: [spring] [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]

[Rakesh Gandhi (rgandhi)]

Hi WG,

These drafts extend the Path Segment defined in the WG documents 
draft-ietf-pce-sr-path-segment and draft-ietf-spring-mpls-path-segment.


I agree with comments from Ketan.

I support the WG adoption of these two drafts.

Thanks,
Rakesh


From: spring  on behalf of "Ketan Talaulikar (ketant)" 

Date: Friday, October 18, 2019 at 3:30 AM
To: "Chengli (Cheng Li)" , Susan Hares , 
'idr wg' , 'SPRING WG List' 
Subject: Re: [spring] [Idr] Adoption: 
draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and 
draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 10/21/2019]

Hi Cheng,

Thanks for your quick responses and acknowledgement of the changes suggested. 
Based on your responses, I have no strong views on the parts which can (or need 
to) be incorporated before adoption and which can be done post adoption.

We can continue to discuss and address the outstanding topics as suggested by 
you.

Thanks,
Ketan

From: Chengli (Cheng Li) 
Sent: 18 October 2019 12:35
To: Ketan Talaulikar (ketant) ; Susan Hares 
; 'idr wg' ; 'SPRING WG List' 
Subject: RE: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt 
and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 
10/21/2019]

Hi Katen,

Many thanks for your valuable comments, will update the drafts to address them 
ASAP. Please see my rely inline.

Thank you again!
Cheng


From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, October 18, 2019 1:51 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 'idr wg' 
mailto:i...@ietf.org>>; 'SPRING WG List' 
mailto:spring@ietf.org>>
Subject: Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt 
and draft-li-sr-policy-path-segment-01.txt - 1 week extension [10/14 to 
10/21/2019]

Hi Sue,


  1.  Should this SR Policy technology be included in BGP for SR-MPLS



Yes. The path segment for MPLS has been defined in Spring and we need the 
corresponding work in BGP to build the solutions based on path segments.


  1.  Is this technology a good way to implement the required

Features in BGP?



Yes and do refer to some of the issues pointed in the comments below.



  1.  Is this technology ready for adoption?



I have listed down the issues/concerns below. I believe we need to hear the 
responses from the authors on them. The WG/chairs can decide whether to require 
these changes before or after adoption.



  1.  Do you have any concerns about adopting this technology?



No (subject to clarifications on the comments below).



My apologies for the delay in review and sharing these comments:

https://datatracker.ietf...org/doc/draft-li-idr-sr-policy-path-segment/


  1.  Sec 3 has the following statement which is incorrect. First the Path 
Segment does not identify the SR Policy and the identifiers of SR Policy are 
specified in draft-ietf-spring-segment-routing-policy.. What the path segment 
does is identify the specific “SR Path(s)” at the tail-end – this is as per 
draft-ietf-spring-mpls-path-segment. So I think the statement below needs to be 
revised.


Also,

   it can be used for identifying an SR candidate path or an SR Policy

   in some use cases if needed.



[Cheng] You are correct! Will address it later.


  1.  The draft proposes to have the ability to encode the Path Segment at both 
the Segment List and Candidate path level. I can understand the signalling at 
the Segment List level, but not sure why we need it also at the CP level? If 
the same Path Segment needs to be shared across Segment Lists then it can be 
specified for each of them?

[Cheng] We aim to provide the capabilities, but your suggestion is right. They 
can be specified for each of them. Let’s discuss which one is better later.


  1.  Sec 3.1. Both the SR-MPLS and SRv6 path segments are being combined here 
and I am not sure that is appropriate. Since only the SR-MPLS path segment 
document is adopted in WG, we need SPRING WG to evaluate the SRv6 path segment. 
I would suggest to call this “MPLS Path Segment” so that work can proceed 
independently. Down the line, we can introduce another TLV for SRv6 Path 
Segment.



[Cheng] You are right. Do we have any SRv6 related text in the drafts? I 
remember I have removed it. Will check again.



  1.  I would also propose to use the TLV encoding that is similar to 
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-07#section-2.4.3.2.1
 for the MPLS path segment.
[Cheng] Agree. We designed the TLV format to 
draft-ietf-idr-segment-routing-te-policy at the first day. Will update to align 
again.



  1.  Sec 4.1. The proposed Bidirectional Path sub-TLV is at the CP level. So 
does it indicate a single reverse path SL for all the forward path SLs or can 
it have multiple SLs? Why not also do this on the per SL level so that the 
reverse path matches the forward path where necessary? Otherwise it 

[spring] Updates to draft-gandhi-spring-rfc6374-srpm-mpls-02.txt

[Rakesh Gandhi (rgandhi)]

Hi WG,
We have updated the draft to address various review comments and suggestions 
received as following:
O.  Added text for flooding TE metrics for L2 links.
O.  Added Return Path TLV for MPLS.
O.  Added Block Number TLV for Loss measurement.
O.  Intended status is standards track due to IANA action.
O.  Editorial changes.

Welcome your further review comments and suggestions.

Thanks,
Rakesh


On 2019-10-04, 3:29 PM, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-gandhi-spring-rfc6374-srpm-mpls-02.txt
has been successfully submitted by Rakesh Gandhi and posted to the
IETF repository.

Name:   draft-gandhi-spring-rfc6374-srpm-mpls
Revision:   02
Title:  Performance Measurement for Segment Routing Networks 
with MPLS Data Plane
Document date:  2019-10-04
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/internet-drafts/draft-gandhi-spring-rfc6374-srpm-mpls-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-gandhi-spring-rfc6374-srpm-mpls/
Htmlized:   
https://tools.ietf.org/html/draft-gandhi-spring-rfc6374-srpm-mpls-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gandhi-spring-rfc6374-srpm-mpls
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-gandhi-spring-rfc6374-srpm-mpls-02

Abstract:
   Segment Routing (SR) leverages the source routing paradigm.  RFC 6374
   specifies protocol mechanisms to enable the efficient and accurate
   measurement of packet loss, one-way and two-way delay, as well as
   related metrics such as delay variation in MPLS networks using probe
   messages.  This document utilizes these mechanisms for Performance
   Delay and Loss Measurements in Segment Routing (SR) networks with
   MPLS data plane (SR-MPLS), for both SR links and end-to-end SR
   Policies.  In addition, this document defines Return Path TLV for
   two-way performance measurement and Block Number TLV for loss
   measurement.



  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

[spring] Updated draft-gandhi-spring-twamp-srpm-02.txt

[Rakesh Gandhi (rgandhi)]

Hi WG,
We have updated the draft to address various comments received since the last 
IETF meeting. Updates are as following:

O.  Elaborate on the processing rules in Section 7 (for TTL, UDP checksum, 
Router Alert).
O.  Add a section on provisioning model.
O.  Align the loss measurement message format with the delay measurement 
message format.
O.  Add STAMP applicability section 3.2.
O.  Welcome Bart as new co-author.
O.  Various editorial changes.

Welcome your review comments and suggestions.

Thanks,
Rakesh


On 2019-08-30, 10:20 AM, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-gandhi-spring-twamp-srpm-02.txt
has been successfully submitted by Rakesh Gandhi and posted to the
IETF repository.

Name:   draft-gandhi-spring-twamp-srpm
Revision:   02
Title:  Performance Measurement Using TWAMP Light for Segment 
Routing Networks
Document date:  2019-08-30
Group:  Individual Submission
Pages:  25
URL:
https://www.ietf.org/internet-drafts/draft-gandhi-spring-twamp-srpm-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/
Htmlized:   
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gandhi-spring-twamp-srpm
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-gandhi-spring-twamp-srpm-02

Abstract:
   Segment Routing (SR) leverages the source routing paradigm.  SR is
   applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
   (SRv6) data planes.  This document specifies procedure for sending
   and processing synthetic probe query and response messages for
   Performance Measurement (PM) in Segment Routing networks.  The
   procedure uses the mechanisms defined in RFC 5357 (Two-Way Active
   Measurement Protocol (TWAMP) Light) for Delay Measurement, and also
   uses the mechanisms defined in this document for Loss Measurement.
   The procedure specified is applicable to SR-MPLS and SRv6 data planes
   and are used for both links and end-to-end SR Policies.



  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

Re: [spring] 答复: Questions about the life span of Path Segment

[Rakesh Gandhi (rgandhi)]

Hi Sasha,
Yes, path segment is used for counters for loss measurement for a path. 
However, for every path invalidation on ingress node, getting a new path 
segment ID from egress node using PCE might not be scalable.

Thanks,
Rakesh


From: Alexander Vainshtein 
Date: Thursday, August 1, 2019 at 11:21 AM
To: "=SMTP:rgandhi@cisco. com" , "Chengli (Cheng Li)" 

Cc: "spring@ietf.org" , 
"draft-ietf-spring-mpls-path-segment.auth...@ietf.org" 
, 
"draft-ietf-spring-mpls-path-segment.auth...@ietf.org" 

Subject: RE: 答复: Questions about the life span of Path Segment

Dear all,
Lots of thanks for your responses and apologies for my much delayed reaction.

I did not mention it in my original email, but the scenario when a Path Segment 
is used by the DP to collect some kind of statistics (e.g., packet loss) for 
the SR policy for which it has been allocated has been the major drive for 
raising my questions.

In this scenario when the path becomes invalid the Path Segment allocated for 
it should be detached from whatever statistics have been collected using it to 
prevent the situation when collected statistics for the now invalidated path 
and for some new one (e.g., the recomputed one between the same two nodes) are 
mixed.

I think that this is roughly what Rakesh has said in his response. And I think 
this should not be left for the implementation to decide but, rather, 
explicitly required in the draft.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Rakesh Gandhi (rgandhi) 
Sent: Thursday, August 1, 2019 3:11 PM
To: Chengli (Cheng Li) ; Alexander Vainshtein 
; 
draft-ietf-spring-mpls-path-segment.auth...@ietf.org
Cc: spring@ietf.org
Subject: Re: 答复: Questions about the life span of Path Segment

Hi Sasha,
For PM loss measurement use-case, the same path segment ID can be used during 
the life span of SR Policy.

Thanks,
Rakesh


From: "Chengli (Cheng Li)" mailto:chengl...@huawei.com>>
Date: Friday, July 26, 2019 at 11:43 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>, 
"draft-ietf-spring-mpls-path-segment.auth...@ietf.org<mailto:draft-ietf-spring-mpls-path-segment.auth...@ietf.org>"
 
mailto:draft-ietf-spring-mpls-path-segment.auth...@ietf.org>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>
Subject: 答复: Questions about the life span of Path Segment
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: 
mailto:chengweiqi...@chinamobile.com>>, 
mailto:li...@chinamobile.com>>, 
mailto:mach.c...@huawei.com>>, "=SMTP:rgandhi@cisco. com" 
mailto:rgan...@cisco.com>>, 
mailto:royi.zig...@broadcom.com>>
Resent-Date: Friday, July 26, 2019 at 11:43 AM

Hi Sasha,

Many thanks for you comments and sorry for my delay. Please see my reply inline.

Cheng


发件人: spring [spring-boun...@ietf.org] 代表 Alexander Vainshtein 
[alexander.vainsht...@ecitele.com]
发送时间: 2019年7月24日 23:27
收件人: 
draft-ietf-spring-mpls-path-segment.auth...@ietf.org<mailto:draft-ietf-spring-mpls-path-segment.auth...@ietf.org>
抄送: spring@ietf.org<mailto:spring@ietf.org>
主题: [spring] Questions about the life span of Path Segment
Dear colleagues,
I have a couple of questions about the life span of the Path Segment.

Suppose that some entity has computed and instantiated an SR LP that follows a 
specific path from the ingress node to the  egress node across a single IGP 
domain. This path is expressed as a sequence of valid IGP Segments (e.g., Node 
and/or Adjacency segments) .
Suppose also that a Path Segment has been allocated by the egress node for this 
path, and the ingress node is aware of this and inserts the label acting as the 
SID for the Path segments immediately after the last SID of the path.

Now my questions:

1.   What happens to the Path Segment when one of the IGP segments defining 
the original path fails?

a.   To the best of my understanding the path itself becomes invalid

[Cheng] Agree. But IMO, the path segment has the same life circle with the 
associated LSP. so it MAY not be invalid in FRR since the egress, ingress even 
the controller does not know that until the Reroute is triggered, then it 
should be treated as invalid.



b.   Will the Path Segment that identifies the now invalid path be retained 
indefinitely, or would it be invalidated as well and the label acting as its 
SID released?

[Cheng] Honestly, I think it depends on implementation. The the LSP fails, then 
the related Path Segment is invalid. But when the Rerouted LSP is installed, 
the path segment should be allocated, and we don't make any assumption of the 
value of the path segment. It CAN be the same value as the previous one.



2.   Suppose that the entity that has computed and instantiated the 
original path re-computes

Re: [spring] 答复: Questions about the life span of Path Segment

[Rakesh Gandhi (rgandhi)]

Hi Sasha,
For PM loss measurement use-case, the same path segment ID can be used during 
the life span of SR Policy.

Thanks,
Rakesh


From: "Chengli (Cheng Li)" 
Date: Friday, July 26, 2019 at 11:43 AM
To: Alexander Vainshtein , 
"draft-ietf-spring-mpls-path-segment.auth...@ietf.org" 

Cc: "spring@ietf.org" 
Subject: 答复: Questions about the life span of Path Segment
Resent-From: 
Resent-To: , , 
, "=SMTP:rgandhi@cisco. com" , 

Resent-Date: Friday, July 26, 2019 at 11:43 AM

Hi Sasha,

Many thanks for you comments and sorry for my delay. Please see my reply inline.

Cheng


发件人: spring [spring-boun...@ietf.org] 代表 Alexander Vainshtein 
[alexander.vainsht...@ecitele.com]
发送时间: 2019年7月24日 23:27
收件人: draft-ietf-spring-mpls-path-segment.auth...@ietf.org
抄送: spring@ietf.org
主题: [spring] Questions about the life span of Path Segment
Dear colleagues,
I have a couple of questions about the life span of the Path Segment.

Suppose that some entity has computed and instantiated an SR LP that follows a 
specific path from the ingress node to the  egress node across a single IGP 
domain. This path is expressed as a sequence of valid IGP Segments (e.g., Node 
and/or Adjacency segments) .
Suppose also that a Path Segment has been allocated by the egress node for this 
path, and the ingress node is aware of this and inserts the label acting as the 
SID for the Path segments immediately after the last SID of the path.

Now my questions:

1.   What happens to the Path Segment when one of the IGP segments defining 
the original path fails?

a.   To the best of my understanding the path itself becomes invalid

[Cheng] Agree. But IMO, the path segment has the same life circle with the 
associated LSP. so it MAY not be invalid in FRR since the egress, ingress even 
the controller does not know that until the Reroute is triggered, then it 
should be treated as invalid.



b.   Will the Path Segment that identifies the now invalid path be retained 
indefinitely, or would it be invalidated as well and the label acting as its 
SID released?

[Cheng] Honestly, I think it depends on implementation. The the LSP fails, then 
the related Path Segment is invalid. But when the Rerouted LSP is installed, 
the path segment should be allocated, and we don't make any assumption of the 
value of the path segment. It CAN be the same value as the previous one.



2.   Suppose that the entity that has computed and instantiated the 
original path re-computes it and instantiate a new valid path.

a.   Should the new path (that replaces the invalidated original one) be 
allocated with the same Path Segment as the original path, or should a new Path 
Segment be allocated for it?

[Cheng] Same as above. As long as the information is synchronized between the 
controller and the data plane, any value is OK. But the same path segment 
should be recommended.



b.   If the Path Segment allocated for the invalidated path is released 
(see (1b) above), can the label that identified it be re-used as the Path 
Segment ID immediately, or only after some delay?

[Cheng] It depends on the implementation. Just to make sure that the path 
segment can be available.



From my POV the answers to these questions do not depend on the actual method 
by which the Path Segments are allocated and propagated from the egress node to 
the ingress one.
And while my questions explicitly mention IGP Segments that define the SR LSP 
for which the Path Segment is allocated, the desired behavior should not depend 
on the type of segments used in the definition of the path.
[Cheng] Sure.

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
[Cheng] Thank you as well for valuable comments.
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [ippm] Latest Updates to SR PM Drafts

[Rakesh Gandhi (rgandhi)]

 of the set of functions 
supported by the remote implementation of TWAMP-Light. The use of the 
explicitly configured UDP port number on a Session-Reflector is very standard 
on TWAMP-Light implementations in the field. How do you propose to discover the 
set of functions that the targetted Session-Reflector supports?
 Both the querier and responder need to be provisioned to enable the LM 
message defined in this document and UDP destination port for it.

 *   Another question. Assuming that the Session-Reflector that does not 
support this specification validates the LM query packet and responds with the 
reflected packet but formatted according to RFC 5357 (and possible extensions 
like described in RFC 6038 and/or RFC 7750), How the Session-Sender that 
receives such test packet be able to validate, parse, and use the information?
 As above.

  *   I'm puzzled how the proposed in Section 3.2.2.1 the new extension to 
STAMP is related to the rest of the document that, as I read it, is based on 
OWAMP/TWAMP, but not STAMP specifications. How the new TLV, registered in 
STAMP-related registry, will be used in, for example, DM Query message, which 
is the same as OWAMP Session-Sender Test packet?
  The DM message format on the wire can be OWAMP/TWAMP/STAMP as long as the 
matching message format and UDP destination port are provisioned on both sides. 
We can discuss and see if the TLV belongs to this document or some other 
document.

  *   The LM measurement mode, please correct me if I'm mistaken, uses what is 
usually called Direct Loss Measurement. It is well-known from, for example, 
ETH-LM in G.8013/Y.1731. Also, draft-xiao-ippm-twamp-ext-direct-loss described 
the full set of extensions to TWAMP (TWAMP-Control and TWAMP-Test) in support 
of the Direct Loss Measurements. But I couldn't find any reference to that work 
that preceded this draft.
 Yes, this is direct loss measurement. Thanks for pointing to the draft. We 
will review the suggested draft and refer to that work as appropriate.
Much appreciate your consideration of my comments and questions. I am looking 
forward to our discussion on email and in Montreal.

 Great, thanks,
Rakesh


Regards,
Greg

On Tue, May 21, 2019 at 3:08 PM Rakesh Gandhi (rgandhi) 
mailto:rgan...@cisco.com>> wrote:
Hi WG,

We have posted following updates to SR PM drafts to address various review 
comments and suggestions.

-

draft-gandhi-spring-twamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/>

This draft defines SR PM using TWAMP RFC 5357, as well as new message for 
direct-mode loss measurement. The latest version of the draft has been updated 
with:

  1.  Mach Chen joined as a co-author.
  2.  Remove term In-band probes and add as “probes sent on congruent path with 
data traffic” in Section 2.2.
  3.  Add packet counter format flags in LM message in Section 3.
  4.  Add Checksum complement in Section 3.
  5.  Define Return Path TLV for two-way measurement mode in Section 3.2.2.1.
  6.  Add Loopback measurement mode in Section 3.2.3.
  7.  Add Path Segment ID in Figure 3.
  8.  Add details for P2MP SR Policy in Section 4.
  9.  Include OWAMP and TWAMP use HMAC-SHA1 for integrity protection in Section 
7.
  10. Cleanup/editorial changes.

Open Items:

  *   None
 

Thank you everyone for your review comments and suggestions on these drafts. 
Welcome your additional feedbacks.


Thanks,

Rakesh (on behalf of co-authors and contributors)

___
ippm mailing list
i...@ietf.org<mailto:i...@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updates to draft-gandhi-spring-ioam-sr-mpls

[Rakesh Gandhi (rgandhi)]

Hi Loa,

Thank you for the review comments. Please see inline with ...

On 2019-05-22, 2:40 AM, "Loa Andersson"  wrote:


Rakesh,

A couple of thoughts and questions.

- is it necessary to have three different ways to establish the
   IOAM Indicator Label?

 There are three options possible, but after some discussions with the WGs, 
we can pick one or more.

- if it is necessary to use a Special Purpose Label, could you use
   a eSPL instead of a bSPL (for terminology see draft-andersson-mpls-
   spl-terminology)?

 We can use eSL (e.g. label value 18).

- will the label serving as as IOAM Indicator always be a the bottom
   of the stack and have the s-bit set?

 That may be easier, need to see if there is any complication that can come 
with it though.

- allocating SPL's is a decision that I would want the MPLS working
   group to take, this could be done in one of two ways, either we
   progress in the mpls wg or you split out the IANA allocation in a
   separate document and progress that in the mpls wg.

 Ok. At this time, we can keep both WGs in the loop with one document.

Thanks,
Rakesh


/Loa

On 2019-05-22 06:49, Rakesh Gandhi (rgandhi) wrote:
> Hi WG,
> 
> We have published an update to the following draft:
> 
> https://datatracker.ietf.org/doc/draft-gandhi-spring-ioam-sr-mpls/
> 
> /draft-gandhi-spring-ioam-sr-mpls/ defines how IOAM data fields are 
> transported with SR-MPLS encapsulation. The draft has been updated as 
> following://
> 
>  1. Add different methods of IOAM Indicator Label in Section 4.1.
>  2. Add Hashing function in Section 4.2.
>  3. Add Node capability in Section 4.3.
>  4. Cleanup/editorial changes
> 
> Welcome your review comments and suggestions.
> 
> Thanks,
> 
> Rakesh (on behalf of co-authors and contributors)
> 
> 
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64


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

[spring] Updates to draft-gandhi-spring-ioam-sr-mpls

[Rakesh Gandhi (rgandhi)]

Hi WG,

We have published an update to the following draft:
https://datatracker.ietf.org/doc/draft-gandhi-spring-ioam-sr-mpls/
draft-gandhi-spring-ioam-sr-mpls defines how IOAM data fields are transported 
with SR-MPLS encapsulation. The draft has been updated as following:

  1.  Add different methods of IOAM Indicator Label in Section 4.1.
  2.  Add Hashing function in Section 4.2.
  3.  Add Node capability in Section 4.3.
  4.  Cleanup/editorial changes

Welcome your review comments and suggestions.

Thanks,
Rakesh (on behalf of co-authors and contributors)

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

[spring] Latest Updates to SR PM Drafts

[Rakesh Gandhi (rgandhi)]

Hi WG,

We have posted following updates to SR PM drafts to address various review 
comments and suggestions.

-

draft-gandhi-spring-twamp-srpm

This draft defines SR PM using TWAMP RFC 5357, as well as new message for 
direct-mode loss measurement. The latest version of the draft has been updated 
with:

  1.  Mach Chen joined as a co-author.
  2.  Remove term In-band probes and add as “probes sent on congruent path with 
data traffic” in Section 2.2.
  3.  Add packet counter format flags in LM message in Section 3.
  4.  Add Checksum complement in Section 3.
  5.  Define Return Path TLV for two-way measurement mode in Section 3.2.2.1.
  6.  Add Loopback measurement mode in Section 3.2.3.
  7.  Add Path Segment ID in Figure 3.
  8.  Add details for P2MP SR Policy in Section 4.
  9.  Include OWAMP and TWAMP use HMAC-SHA1 for integrity protection in Section 
7.
  10. Cleanup/editorial changes.

Open Items:

  *   None

-

draft-gandhi-spring-rfc6374-srpm-udp

This draft defines SR PM using IP/UDP encap for RFC 6374. The latest version of 
the draft has been updated with:

1.  Remove term In-band probes and add as “probes sent on congruent path 
with data traffic” in Section 2.2.

2.  Add loopback measurement mode in Section 3.2.3.

3.  Add Checksum complement in Section 3.3.

4.  Add Path Segment ID in Figure 3.

5.  Add details for P2MP SR Policy in Section 4.

6.  Cleanup/editorial changes.

Open Items:

  *   None

-

draft-gandhi-spring-rfc6374-srpm-mpls

This informational draft reviews SR PM for MPLS data plane using RFC 6374. The 
latest version of the draft has been updated with:

  1.  Remove term In-band probes and add as “probes sent on congruent path with 
data traffic” in Section 2.2.
  2.  Add Return Path TLV for two-way measurement mode in Section 3.3.2.1.
  3.  Add loopback measurement mode in Section 3.3.3.
  4.  Add Path Segment ID in Figure 4.
  5.  Add block number TLV in Section 5.1.1.
  6.  Add details for P2MP SR Policy in Section 6.
  7.  Add details for ECMP in Section 7.
  8.  Cleanup/editorial changes.

Open Items:

  *   None


Thank you everyone for your review comments and suggestions on these drafts. 
Welcome your additional feedbacks.


Thanks,

Rakesh (on behalf of co-authors and contributors)

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

Re: [spring] [ippm] draft-gandhi-spring-twamp-srpm - comment

[Rakesh Gandhi (rgandhi)]

Hi Rajiv,

Many thanks for your comments. We will incorporate the suggestion in the next 
revision of the document along the lines of “synthetic probes messages 
congruent to the data traffic”.

Thanks,
Rakesh


On 2019-03-28, 3:17 PM, "ippm on behalf of Rajiv Asati (rajiva)" 
 wrote:

Hi Rakesh,

It is a useful draft. Simplifies TWAMP usage in SR networks. 

Given that the draft defines dedicated probes and response messages to 
measure PM/DM/LM, please consider not using the term Inband, as it would mean 
mucking up the user packets like specified in IOAM. 

Cheers,
Rajiv  

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


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

Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

[Rakesh Gandhi (rgandhi)]

Hi Chairs, WG,

I support the WG adoption of this draft.

Thanks,
Rakesh


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, March 14, 2019 2:50 AM
To: SPRING WG 
Cc: draft-filsfils-spring-srv6-network-programm...@ietf.org
Subject: [spring] Working Group Adoption Call for 
draft-filsfils-spring-srv6-network-programming


Hi SPRING WG,



This email initiates a three week call for working group adoption for 
draft-filsfils-spring-srv6-network-programming. (Three weeks to account for the 
IETF week)



Please indicate your support, comments, or objection, for adopting this draft 
as a working group item by April, 3rd, 2019 (aka 2019-04-03)

We are particularly interested in hearing from working group members that are 
not co-authors of this draft.



We are also looking for volunteers who would be ready to perform a technical 
review of this work at some later stage, such as before or during WG the last 
call.



In parallel to this adoption call, I will send an IPR call for this document. 
We will need all authors and contributors to confirm their IPR position on this 
document.

There is currently 1 IPR filled (2)



(1)  
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07

(2)  
https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-network-programming=draft





Thank you,

--Bruno & Rob.


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [spring] Comments on draft-gandhi-spring-twamp-srpm

[Rakesh Gandhi (rgandhi)]

Hi Greg,

Many thanks for the pointers of the relevant work. We are happy to collaborate 
with you on SR PM.

Thanks,
Rakesh


From: Greg Mirsky 
Date: Tuesday, March 5, 2019 at 10:24 PM
To: "=SMTP:rgandhi@cisco. com" 
Cc: spring , IETF IPPM WG 
Subject: Re: Comments on draft-gandhi-spring-twamp-srpm

Hi Rakesh,
the common understanding of the TWAMP and TWAMP Light by IPPM WG is reflected 
in 
draft-ietf-ippm-port-twamp-test<https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/>
 (soon to be published as RFC 8545). The work on STAMP is progressing and the 
base specification, 
draft-ietf-ippm-stamp<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/>, 
is in WG LC through March 15. Much appreciate your review and comments. Also, 
much interested in your comments on 
draft-mirsky-ippm-stamp-option-tlv<https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/>.
 I believe that there's a good reason for us to work together on STAMP 
extensions that address specific SR scenarios.

Regards,
Greg

On Sun, Mar 3, 2019 at 6:17 AM Rakesh Gandhi (rgandhi) 
mailto:rgan...@cisco.com>> wrote:
Thank you Greg for the thorough review of the document and your comments.

Please see in line with …

From: Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Thursday, February 28, 2019 at 7:05 PM
To: 
"draft-gandhi-spring-twamp-s...@ietf.org<mailto:draft-gandhi-spring-twamp-s...@ietf.org>"
 
mailto:draft-gandhi-spring-twamp-s...@ietf.org>>,
 spring mailto:spring@ietf.org>>, IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: Comments on draft-gandhi-spring-twamp-srpm
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: "=SMTP:rgandhi@cisco. com" 
mailto:rgan...@cisco.com>>, 
mailto:cfils...@cisco.com>>, 
mailto:daniel.vo...@bell.ca>>
Resent-Date: Thursday, February 28, 2019 at 7:05 PM

Dear Authors,
I've read the draft and would share my comments with SPRING and IPPM WGs:

  *   Section 3.1.1

 *   what is introduced in this section? Note, that in OWAMP 'O' stands for 
'one-way', i.e., the receiver collects the measurement results. RFC 4656 
defines Client Fetch command to retrieve, possibly by the Session-Sender, the 
measurement results.
 Idea is that the user provisions the UDP port and the attributes (e.g. 
timestamp format, authentication mode/type, etc. associated with the UDP port) 
on both endpoints of SR paths. These configurations are used to interpret 
*WAMP(Light) payloads to provide delay and loss measurements. The motivation is 
to eliminate the control-channel signaling - the spirit of SR.

 *   note that RFCs 4656 and 5357 defined the use only of NTP format for 
timestamps. The use of PTP format was introduced by RFC 8186 for TWAMP only as 
optional, not as the default mode. The default format for TWAMP-Test is still 
NTP format. You may consider using the mechanism defined for TWAMP-Control to 
change the default to PTP format.
 As mentioned above, the motivation of this work is to move away from the 
control-channel signaling to boot-strap PM sessions. So, we are not extending 
the control-channel signaling.

  *   Section 3.1.2

 *   a new format for Session-Sender's TWAMP-Test message introduced. Note, 
that the format for Session-Sender TWAMP-Test message is the same as defined in 
RFC 4656. If you want to define a new TWAMP-Test optional format it first must 
be negotiated through TWAMP-Control protocol as has been done for all TWAMP 
extensions.
 *   how the format you've proposed is different from the one proposed 
earlier in 
draft-xiao-ippm-twamp-ext-direct-loss<https://tools.ietf.org/html/draft-xiao-ippm-twamp-ext-direct-loss-01>.
 *   Your intention, if I understand correctly, is to support direct-mode 
loss measurement. draft-xiao-ippm-twamp-ext-direct-loss proposed that earlier 
and with proper TWAMP-Control extension. After the IPPM WG agreed to work on 
STAMP, authors of draft-xiao-ippm-twamp-ext-direct-loss and STAMP agreed to 
work together and now the direct-mode loss measurement is part of 
draft-mirsky-ippm-stamp-option-tlv<https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/?include_text=1>.
 Your understanding is correct. Thank you for the background and pointing 
to the LM TLV. We can analyze to see if we can leverage the TLV. Again, we are 
not extending the control-channel signaling.

 *   the last bullet in the section refers to PSID but I couldn't find a 
PSID field in any of the displayed formats, authenticated or not. Is it for 
further versions?
 Ok, we will add the definition/detail in the next revision.

  *   Section 3.1.4.1

 *   what is illustrated in this sub-section? That TWAMP-Test message with 
IP/UDP encapsulation can be carried over SR-MPLS tunnel?
 It shows how the measurement packet is carried over SR-MPLS Policy.

  *   Section 3.1.4.2

 *   same question as above.
 It shows ho

Re: [spring] Comments on draft-gandhi-spring-twamp-srpm

[Rakesh Gandhi (rgandhi)]

Thank you Greg for the thorough review of the document and your comments.

Please see in line with …

From: Greg Mirsky 
Date: Thursday, February 28, 2019 at 7:05 PM
To: "draft-gandhi-spring-twamp-s...@ietf.org" 
, spring , IETF IPPM 
WG 
Subject: Comments on draft-gandhi-spring-twamp-srpm
Resent-From: 
Resent-To: "=SMTP:rgandhi@cisco. com" , 
, 
Resent-Date: Thursday, February 28, 2019 at 7:05 PM

Dear Authors,
I've read the draft and would share my comments with SPRING and IPPM WGs:

  *   Section 3.1.1

 *   what is introduced in this section? Note, that in OWAMP 'O' stands for 
'one-way', i.e., the receiver collects the measurement results. RFC 4656 
defines Client Fetch command to retrieve, possibly by the Session-Sender, the 
measurement results.
 Idea is that the user provisions the UDP port and the attributes (e.g. 
timestamp format, authentication mode/type, etc. associated with the UDP port) 
on both endpoints of SR paths. These configurations are used to interpret 
*WAMP(Light) payloads to provide delay and loss measurements. The motivation is 
to eliminate the control-channel signaling - the spirit of SR.

 *   note that RFCs 4656 and 5357 defined the use only of NTP format for 
timestamps. The use of PTP format was introduced by RFC 8186 for TWAMP only as 
optional, not as the default mode. The default format for TWAMP-Test is still 
NTP format. You may consider using the mechanism defined for TWAMP-Control to 
change the default to PTP format.
 As mentioned above, the motivation of this work is to move away from the 
control-channel signaling to boot-strap PM sessions. So, we are not extending 
the control-channel signaling.

  *   Section 3.1.2

 *   a new format for Session-Sender's TWAMP-Test message introduced. Note, 
that the format for Session-Sender TWAMP-Test message is the same as defined in 
RFC 4656. If you want to define a new TWAMP-Test optional format it first must 
be negotiated through TWAMP-Control protocol as has been done for all TWAMP 
extensions.
 *   how the format you've proposed is different from the one proposed 
earlier in 
draft-xiao-ippm-twamp-ext-direct-loss.
 *   Your intention, if I understand correctly, is to support direct-mode 
loss measurement. draft-xiao-ippm-twamp-ext-direct-loss proposed that earlier 
and with proper TWAMP-Control extension. After the IPPM WG agreed to work on 
STAMP, authors of draft-xiao-ippm-twamp-ext-direct-loss and STAMP agreed to 
work together and now the direct-mode loss measurement is part of 
draft-mirsky-ippm-stamp-option-tlv.
 Your understanding is correct. Thank you for the background and pointing 
to the LM TLV. We can analyze to see if we can leverage the TLV. Again, we are 
not extending the control-channel signaling.

 *   the last bullet in the section refers to PSID but I couldn't find a 
PSID field in any of the displayed formats, authenticated or not. Is it for 
further versions?
 Ok, we will add the definition/detail in the next revision.

  *   Section 3.1.4.1

 *   what is illustrated in this sub-section? That TWAMP-Test message with 
IP/UDP encapsulation can be carried over SR-MPLS tunnel?
 It shows how the measurement packet is carried over SR-MPLS Policy.

  *   Section 3.1.4.2

 *   same question as above.
 It shows how the measurement packet is carried over SRv6 Policy and what 
END function is used for timestamp and punting the packet.

  *   Section 4

 *   is the formula to calculate the packet loss using the direct-mode 
measurement is worth repeating in RFC?
 It is good to have it at the early stage of the document. We can remove it 
later in the process.

  *   Section 5

 *   without the discussion of the impact on the Session-Sender that 
reflected test packets may have, I cannot agree with the assumption:
   The procedures for delay and loss measurement described in this
   document for Point-to-Point (P2P) SR-MPLS Policies are also equally
   applicable to the Point-to-Multipoint (P2MP) SR Policies.

 Yes, we can elaborate it in the next revision. Idea it that the querier 
uses the source address of the responders (i.e. leafs) to identify the 
measurements to each leaf.

  *   Section 7

 *   OWAMP and TWAMP use HMAC-SHA1 for integrity protection. If your intent 
is to use HMAC-SHA-256 in the authenticated mode for OWAMP and/or TWAMP, then 
it may be supported as an optional extension with the proper extension in their 
respective control protocols. Should note that the use of HMAC-SHA-256 for 
STAMP was discussed at IPPM WG meeting in Bangkok and now is documented in the 
latest version of STAMP.
 Thanks for sharing this information. We will update the draft accordingly. 
This is also a property of the UDP port configured and both methods can be 
used. As mentioned earlier, we are moving away from using 

Re: [spring] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

[Rakesh Gandhi (rgandhi)]

Hi WG,

Yes, support WG adoption of this draft.

Thanks,
Rakesh (as a co-author)

On 2019-02-20, 4:01 AM, "bruno.decra...@orange.com"  
wrote:

Hi SPRING WG,

This email initiates a two week call for working group adoption for 
draft-cheng-spring-mpls-path-segment.

Please indicate your support, comments, or objection, for adopting this 
draft as a working group item by March 6th 2019.
We are particularly interested in hearing from working group members that 
are not co-authors of this draft.
We are also looking for volunteers who would be ready to perform a 
technical review of this work at some later stage, such as before or during WG 
the last call.

Additionally, there are currently 7 authors listed on this document. Please 
trim this to <= 5 front-page authors, utilising a "Contributors" section if 
required for the others. An approach to achieving this would be to list ~2 
editors as the front-page authors.

In parallel to this adoption call, I will send an IPR call for this 
document. We will need all authors and contributors to confirm their IPR 
position on this document.

(1) https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment

Thanks,
--Bruno & Rob.



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



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

Re: [spring] IPR Poll for draft-cheng-spring-mpls-path-segment

[Rakesh Gandhi (rgandhi)]

Hi WG,
I am not aware of any IPR that applies to this draft.

Thanks,
Rakesh


On 2019-02-20, 4:01 AM, "bruno.decra...@orange.com"  
wrote:

Hi Jeff, authors, SPRING WG,

In parallel to the call for adoption for 
draft-cheng-spring-mpls-path-segment (1), we would like to poll for IPR.

If you are aware of IPR that applies to 
draft-cheng-spring-mpls-path-segment please respond to this email.
If you are aware of IPR, please indicate whether it has been disclosed in 
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more 
details).

If you are an *author or contributor* please respond to this email 
regardless of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if 
you are aware of IPR that has not yet been disclosed.

During IETF 103, Jeff said that Ericsson owns an IPR on this. Jeff, do you 
want to provide more details on this? Do you want to fill a third party IPR 
disclosure?

This document will not advance into the working group until IPR 
confirmations have been received from all authors and contributors.

Thanks,

(1) https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment

--Bruno & Rob.



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



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

[spring] Updates to SR PM Drafts

[Rakesh Gandhi (rgandhi)]

Hi WG,

We have posted following 3 IETF drafts on SR Performance Monitoring:


1.  https://tools.ietf.org/html/draft-gandhi-spring-rfc6374-srpm-udp-00

2.  https://tools.ietf.org/html/draft-gandhi-spring-rfc6374-srpm-mpls-00

3.  https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-00

The first draft spring-rfc6374-srpm-udp was renamed from spring-udp-pm to 
better reflect the scope of RFC 6374.
Following updates were made to address various comments received during the 
last IETF meeting:

1)  Clarify In-band probe message scope in Section 2.4

2)  Clarify Sequence Number TLV usage wrt existing Seq # in RFC 6374 in 
Section 6

3)  Update Security Section 7

4)  Add Authentication Mode TLV in Section 6.2

5)  Add text for Anycast SID in Section 5

6)  Rework Return Path TLV structure in Section 3.2.3.1

7)  Use dynamic UDP port allocation approach similar to TWAMP-Light (and 
move away from fixed port due to difficulty in getting reserved UDP ports)

8)  Various editorial changes
Open Items:

· None


The second draft spring-rfc6374-srpm-mpls was renamed from spring-sr-mpls-pm to 
better reflect the scope of RFC 6374.
Following updates were made to address various comments received during the 
last IETF meeting:

1)  Clarify In-band probe message scope

2)  Add text on ECMP.

3)  Various editorial changes.
Open Item:

· Add text on Return Path (based on comment from Stewart Bryant).


We have introduced a third draft spring-twamp-srpm for using TWAMP-Light for 
SR-MPLS/SRV6 which has some similarity with RFC 6374 UDP-based approach. It 
also defines a new message for direct-mode loss measurement. We plan to update 
the draft next to add, a) Return Path TLV, and b) UDP checksum correction field 
for LM message.

Thank you everyone for your review comments and suggestions at the last meeting.
Please let us know your further feedbacks on this important area.

Thanks,
Rakesh (on behalf of co-authors and contributors)

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

Re: [spring] draft-gandhi-spring-rfc6374-srpm-mpls return path

[Rakesh Gandhi (rgandhi)]

Hi Stewart,

Thanks for your comments.

There is a companion draft where this TLV is defined. We can add reference/text 
to indicate this.
https://tools.ietf.org/html/draft-gandhi-spring-rfc6374-srpm-udp-00#section-3.2.3.1

Hope this answers your question.

Thanks,
Rakesh


On 2019-02-14, 9:43 AM, "spring on behalf of Stewart Bryant" 
 wrote:


I am not quite sure what it means to do a two way path measurement in 
MPLS SR since MPLS SR defines a per packet unidirectional path. However, 
assuming that this makes sense,  I don't see how the return path 
information is carried in the RFC6374 message. The draft does not ask 
IANA for any new types. Now it has been a long time since we wrote 
RFC6374, but I don't remember the design having the capability you require.

Please could clarify how the return path operates in an MPLS SR environment?

Best Regards

- Stewart

___
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] New Draft draft-gandhi-spring-udp-pm

[Rakesh Gandhi (rgandhi)]

Thanks Mach for the comments. We will add following TLV in the next revision of 
the draft.


3.1.2.1.  Block Number TLV

   The Loss Measurement using Alternate-Marking method defined in
   [RFC8321] requires to identify the Block Number (colour) of the
   traffic counters carried by the probe query and response messages.
   Probe query and response messages specified in [RFC6374] for Loss
   Measurement do not define any means to carry the Block Number.

   [RFC6374] defines probe query and response messages that can include
   one or more optional TLVs.  New TLV Type (value TBA8) is defined in
   this document to carry Block Number (32-bit) for the traffic counters
   in the probe query and response messages for loss measurement.  The
   format of the Block Number TLV is shown in Figure 11:

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type TBA7   |Length |  Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Block Number|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: Block Number TLV

   The Block Number TLV is optional.  The PM querier node SHOULD only
   insert one Block Number TLV in the probe query message and the
   responder node in the probe response message SHOULD return the first
   Block Number TLV from the probe query messages and ignore other Block
   Number TLVs if present.  In probe query and response messages, the
   counters MUST belong to the same Block Number.


Thanks,
Rakesh



From: Mach Chen 
Date: Monday, July 23, 2018 at 11:31 PM
To: "=SMTP:rgandhi@cisco. com" 
Cc: "i...@ietf.org" , spring 
Subject: RE: New Draft draft-gandhi-spring-udp-pm

Hi Authors,

The draft-gandhi-spring-udp-pm-01 defines a new C flag as following:

3.1.2.1.  Loss Measurement Flags

   An LM message carries Data Format Flags (DFlags) as defined in
   [RFC6374].  New Flag is defined in this document for Color (C) in the
   DFlags field as follows.

  +-+-+-+-+
  |X|B|C|0|
  +-+-+-+-+

  Data Format Flags

   The Flag C indicates the Color of the counters in the LM probe
   message [RFC6374] when using Alternate-Marking method defined in
   [RFC8321].
-

As defined in Section 4.2 of [RFC8321], could you consider to define more than 
one flag or a TLV to carry Block number instead?

Best regards,
Mach

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Tuesday, July 17, 2018 9:57 PM
To: i...@ietf.org
Subject: [ippm] New Draft draft-gandhi-spring-udp-pm

Hi WG,

We like to introduce following new draft that was presented to SPRING WG 
yesterday.

This draft defines IP/UDP path for sending probe query messages for delay and 
loss measurement that is agnostics to data plane (SR-MPLS/SRv6/IP) and does not 
require to bootstrap PM session.


https://datatracker.ietf.org/doc/draft-gandhi-spring-udp-pm/

You may find presentation in the following package (it is the second draft).

https://datatracker.ietf.org/meeting/102/materials/slides-102-spring-13-performance-measurement-in-sr-networks-00

We welcome your comments and suggestions.

Thanks,
Rakesh (On behalf of authors and contributors)

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

[spring] Request to review

[Rakesh Gandhi (rgandhi)]

Hi WG,

This draft was presented in SPRING WG session yesterday, but we did not have 
sufficient time.

This informational draft reviews the procedures from RFC6374 (defined for 
MPLS-TP), RFC7876 (UDP return path), RFC7471/RFC7810 (Extended TE Link Metric 
TLVs) for SR Links and SR Policies with MPLS data plane.


https://datatracker.ietf.org/doc/draft-gandhi-spring-sr-mpls-pm/

You may find the presentation in the following package (it is the first draft).

https://datatracker.ietf.org/meeting/102/materials/slides-102-spring-13-performance-measurement-in-sr-networks-00

We welcome your review comments and suggestions.

Thanks,
Rakesh (On behalf of authors and contributors)


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

[spring] Request to review

[Rakesh Gandhi (rgandhi)]

Hi WG,

Following draft was presented to the SPRING WG session yesterday, but we did 
not have sufficient time.

This draft defines IP/UDP path for sending probe query messages for delay and 
loss measurement that is agnostics to data plane (SR-MPLS/SRv6/IP) and does not 
require to bootstrap PM session.


https://datatracker.ietf.org/doc/draft-gandhi-spring-udp-pm/

You may find presentation in the following package (it is the second draft).

https://datatracker.ietf.org/meeting/102/materials/slides-102-spring-13-performance-measurement-in-sr-networks-00

We welcome your review comments and suggestions.

Thanks,
Rakesh (On behalf of authors and contributors)


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

[spring] New draft on SR Performance Measurement

[Rakesh Gandhi (rgandhi)]

Hi WG,

We like to bring to your attention following new IETF draft on Performance 
Measurement Probe messages for Segment Routing using UDP path.

https://tools.ietf.org/html/draft-gandhi-spring-udp-pm-00

We welcome your feedbacks and suggestions.

Thanks,
Rakesh (for authors)

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