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

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 2 Nov 2020 04:18:32 +0000

Hello All,

I support the adoption of this work for performance monitoring in SR networks that leverages STAMP encoding.

Thanks,
Ketan

From: spring <[email-masked]> On Behalf Of James Guichard
Sent: 22 October 2020 18:22
To: [email-masked]
Cc: [email-masked]; [email-masked]
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

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 2 Nov 2020 17:25:27 +0800

I support the adoption.

发件人: spring [mailto:[email-masked]] 代表 James Guichard
发送时间: 2020年10月22日 20:52
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: [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

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Mon, 2 Nov 2020 14:12:52 +0000

I support the adoption of this document.

Thanks,
Mike.

From: spring <[email-masked]> On Behalf Of James Guichard
Sent: Thursday, October 22, 2020 8:52 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

Dear WG:

Some background:

Thanks!

Jim, Bruno, & Joel

---

From: Lizhenbin <[email-masked]>
Date: Tue, 3 Nov 2020 09:22:23 +0000

Hi All,

I support the adoption of the draft.

Best Regards,

Zhenbin (Robin)

--------------------------------------------------
李振斌 Li Zhenbin
Mobile: +86-13651017745<tel:+86-13651017745>/+968-91797068
Email: [email-masked]<mailto:[email-masked]>

发件人：James Guichard <[email-masked]>
收件人：spring <[email-masked]>
抄 送：ippm-chairs <[email-masked]>;spring-chairs <[email-masked]>
时 间：2020-10-22 20:53:25
主 题：[spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

Dear WG:

Some background:

Thanks!

Jim, Bruno, & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 6 Nov 2020 08:17:29 -0800

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.

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

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

draft-gandhi-spring-stamp-srpm

   - Can you define a Link and how it is different from an SR Path?
   - It is not clear how the destination UDP port numbers are selected.
   Does the draft change procedure defined in Section 4.1 RFC 8762?
   - 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?
   - 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
   <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/> proposed
   in these drafts?
   - 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 RFC 8762 support packet delay and packet loss
measurements in the same test session using test packets defined in the
STAMP base specification. I believe that the need yet for another method to
perform the loss measurement is not sufficiently demonstrated and does
appear as duplication of functionality already available in STAMP.

   - Could you expand on the reasoning why in Section 4.1.1.1 stated that

   A separate user-configured
   destination UDP port is used for the delay measurement in
   authentication mode due to the different probe message format.

I cannot find similar requirement in RFC 8762 and would appreciate a
technical explanation of the choice made in this specification.

   - Section 4.2.1 refers to Sender Control Code (though it is defined
   in draft-gandhi-ippm-stamp-srpm. Could you explain why it is important to
   inform the Session-Reflector that the reflected test packet be sent
   out-of-band? What if only in-band return path is available? Would the
   Session-Reflector discard test packets in such situation?
   - I got confused by the following in Section 4.2.2

   In two-way measurement mode, when using a bidirectional path, the
   probe response message as defined in Figure 6 is sent back to the
   sender node on the congruent path of the data traffic on the same
   reverse direction Link or associated reverse SR Policy
   [I-D.ietf-pce-sr-bidir-path].

If a Path Segment SID associated with the test session, there seems no need
to require the Session-Reflector look for in-band path. Would you agree?

   - How's the method described in Section 4.2.3 is different from the
   method described in RFC 8403 <https://tools.ietf.org/html/rfc8403>? What
   is distinctly unique about the loopback mode proposed in the section?  Is
   the "liveness monitoring" functionally identical to path continuity
   monitoring provided by BFD?
   - It appears that second and third paragraphs on Section 4.3.1
   contradict with the first paragraph. Need to point that RFC 8762 does not
   specify the value set in TTL/Hop Limit field, thus reference in the first
   paragraph seems misleading. I couldn't find ::FFFF:127/104 range being
   mentioned in the draft. Could you clarify when it is used?
   - Section 4.3.3 states that a zero-value UDP checksum may be used in
   some scenarios. RFC 8085 allows that but in very specific cases that are
   documented in detail in Section 3.4.1. Do you believe that the case of this
   protocol checks all the requirements for allowing the use of Zero UDP
   checksum as specified in RFC 8085? Also, I believe that allowing the use of
   Zero UDP checksum in some scenarios, this protocol introduces a security
   threat that must be thoroughly analyzed in the Security Considerations
   section.
   - Section 7, as I understand it, suggests that performance measurement
   can be combined with "liveness monitoring", i.e.path continuity monitoring.
   How fast path failure detection you expect in such combination? How it is
   comparable to the the failure detection time guaranteed using BFD?

draft-gandhi-ippm-stamp-srpm

   - Introduction states that

  The STAMP message with a TLV for "direct measurement" can be used for
   combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv].

In fact, that is not accurate. RFC 8762 which provides the base
specification of the STAMP protocol already supports packet delay and
packet loss (a.k.a. synthetic packet loss) measurement.

   - Further, the draft concludes that

   However, in order to use only for loss measurement purpose, it
   requires the node to support the delay measurement messages and
   support timestamp for these messages (which may also require clock
   synchronization).

I disagree that the the clock synchronization is required for STAMP. It is
recommended for one-way delay measurement but even without the clock
synchronization STAMP supports the round-trip delay measurement and one-way
delay variation can be calculated.

   - The conclusion on Introduction is, in my view, misleading as the
   proposed solution is not an extension of STAMP but update of RFC 8762. And
   since this is changes the foundation of RFC 8762 that specifies active
   two-way performance measurement protocol, another method for collecting
   counters and/or other telemetry information should be sought. For example,
   ICMP using multi-part message extensions, as defined in RFC 4884
   <https://tools.ietf.org/html/rfc4884>.

Regards,
Greg

On Thu, Oct 22, 2020 at 5:52 AM James Guichard <
[email-masked]> wrote:

> 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
>    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.
>
>
>
> 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
>    - https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This
> 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.
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 10 Nov 2020 16:01:02 +0000

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 <RG>. The repeated comments are tagged with <RG00> to avoid duplicated discussions.

From: ippm <[email-masked]>
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, IETF IPPM WG <[email-masked]>
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.

<RG00> We can change Sender to Session-Sender and Reflector to Session-Reflector if it helps.
<RG00> 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.

<RG00> 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.
<RG00> 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?
<RG00> 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?
<RG> 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?
<RG00> 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 <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>  proposed in these drafts?
<RG00> Yes, this can be Yang model. We can review draft-ietf-ippm-stamp-yang <https://datatracker.ietf.org/doc/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 RFC 8762 support packet delay and packet loss measurements in the same test session using test packets defined in the STAMP base specification. I believe that the need yet for another method to perform the loss measurement is not sufficiently demonstrated and does appear as duplication of functionality already available in STAMP.

<RG> This is explained in the third paragraph of Section 1.

  *   Could you expand on the reasoning why in Section 4.1.1.1 stated that
   A separate user-configured
   destination UDP port is used for the delay measurement in
   authentication mode due to the different probe message format.
I cannot find similar requirement in RFC 8762 and would appreciate a technical explanation of the choice made in this specification.

<RG> Does RFC 8762 support simultaneous sessions for authenticated and non-authenticated modes? If yes, can you please point to the procedure in the RFC 8762 and we can simply refer to it? I am not sure  how both packet formats be distinguished by a reflector node when using the same UDP port.

  *   Section 4.2.1 refers to Sender Control Code (though it is defined in draft-gandhi-ippm-stamp-srpm. Could you explain why it is important to inform the Session-Reflector that the reflected test packet be sent out-of-band? What if only in-band return path is available? Would the Session-Reflector discard test packets in such situation?
<RG00> Out-of-band is the current behaviour and there is no change in the existing behaviour. We can clarify in the next revision.

  *   I got confused by the following in Section 4.2.2
   In two-way measurement mode, when using a bidirectional path, the
   probe response message as defined in Figure 6 is sent back to the
   sender node on the congruent path of the data traffic on the same
   reverse direction Link or associated reverse SR Policy
   [I-D.ietf-pce-sr-bidir-path].
If a Path Segment SID associated with the test session, there seems no need to require the Session-Reflector look for in-band path. Would you agree?

<RG> No. Existence of Path Segment ID does not mean in-band reply. It may be needed for RX counter for direct-mode loss measurement.

  *   How's the method described in Section 4.2.3 is different from the method described in RFC 8403<https://tools.ietf.org/html/rfc8403>? What is distinctly unique about the loopback mode proposed in the section?
<RG00> There is no mention of Loopback mode or STAMP / TWAMP / RFC 5357 / RFC 8762 in RFC 8403.
Is the "liveness monitoring" functionally identical to path continuity monitoring provided by BFD?
<RG00> STAMP  probe messages are used for synthetic packet loss which can be used to detect connection loss. The draft simply highlights this obvious metric.

  *   It appears that second and third paragraphs on Section 4.3.1 contradict with the first paragraph. Need to point that RFC 8762 does not specify the value set in TTL/Hop Limit field, thus reference in the first paragraph seems misleading. I couldn't find ::FFFF:127/104 range being mentioned in the draft. Could you clarify when it is used?
<RG> We can update the sentence in the first paragraph as following:
The TTL field in the IPv4 and MPLS headers of the probe query messages is set to 255 [RFC5357] except following two cases.

<RG> The IPv6 address ::1/128 is mentioned in the draft at couple of places. We can update the above text.

  *   Section 4.3.3 states that a zero-value UDP checksum may be used in some scenarios. RFC 8085 allows that but in very specific cases that are documented in detail in Section 3.4.1. Do you believe that the case of this protocol checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I believe that allowing the use of Zero UDP checksum in some scenarios, this protocol introduces a security threat that must be thoroughly analyzed in the Security Considerations section.
<RG00> This is described in RFC 6936. It will be very specific to the UDP port provisioned for STAMP. We will add reference to RFC 6936 in Security Section.

  *   Section 7, as I understand it, suggests that performance measurement can be combined with "liveness monitoring", i.e.path continuity monitoring. How fast path failure detection you expect in such combination? How it is comparable to the the failure detection time guaranteed using BFD?
<RG00> STAMP  probe messages are used for synthetic packet loss which can be used to detect connection loss (performance metric). The draft simply highlights this obvious metric.
draft-gandhi-ippm-stamp-srpm

  *   Introduction states that
  The STAMP message with a TLV for "direct measurement" can be used for
   combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv].
In fact, that is not accurate. RFC 8762 which provides the base specification of the STAMP protocol already supports packet delay and packet loss (a.k.a. synthetic packet loss) measurement.
<RG> Ok, we can update the text to indicate synthetic loss.

  *   Further, the draft concludes that
   However, in order to use only for loss measurement purpose, it
   requires the node to support the delay measurement messages and
   support timestamp for these messages (which may also require clock
   synchronization).
I disagree that the the clock synchronization is required for STAMP. It is recommended for one-way delay measurement but even without the clock synchronization STAMP supports the round-trip delay measurement and one-way delay variation can be calculated.
<RG> We can update text to : (which requires clock synchronization for one-way delay measurement).

  *   The conclusion on Introduction is, in my view, misleading as the proposed solution is not an extension of STAMP but update of RFC 8762. And since this is changes the foundation of RFC 8762 that specifies active two-way performance measurement protocol, another method for collecting counters and/or other telemetry information should be sought. For example, ICMP using multi-part message extensions, as defined in RFC 4884<https://tools.ietf.org/html/rfc4884>.
<RG00> As mentioned earlier, I am not sure extending ICMP to do PM is a good option here.

Thanks,
Rakesh

Regards,
Greg

On Thu, Oct 22, 2020 at 5:52 AM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG:

Some background:

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

---

From: Satoru Matsushima <[email-masked]>
Date: Sat, 14 Nov 2020 13:04:58 +0900

Support this adoption.

Cheers,
--satoru

> 2020/10/22 21:51、James Guichard <[email-masked]>のメール:
> 
> Dear WG:
>  
> This message starts a 3 week WG adoption call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 <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 <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 <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 <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 <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 <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 <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.
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 15 Nov 2020 16:07:28 -0800

Hi Rakesh,
thank you for the response to my comments. Please find my follow-up notes
in-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Nov 10, 2020 at 8:01 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> 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 <RG>. The repeated comments are tagged with <RG00>
> to avoid duplicated discussions.
>
>
>
> *From: *ippm <[email-masked]>
> *Date: *Friday, November 6, 2020 at 11:18 AM
> *To: *James Guichard <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>,
> IETF IPPM WG <[email-masked]>
> *Subject: *Re: [ippm] [spring] WG Adoption Call for
GIM>> I believe that the consistency in terminology between the core RFC
8762 and what is intended as its extension is not only helpful to a reader
but, to the best of my understanding, is required for IETF specifications.
But I don't think that switching the terminology will fix the fundamental
issue with *stamp-srpm drafts. The operation that is required from the
remote entity, whether it is referred to as responder or Session-Reflector,
is not defined in RFC 8762, nor even in draft-ietf-ippm-stamp-option-tlv.
In my opinion, the behavior required, as described in the *stamp-srpm
drafts, cannot be characterized as an extension of STAMP but presents a
completely new protocol that, if there's a need in the new PM OAM protocol,
must be properly defined.

> <RG00> 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.
>
GIM>> Thank you for the references to these RFCs. I think I need to clarify
my questions. I don't think that a reference to any RFC will address my
concern. In reviewed documents, "Link" is capitalized while referenced RFCs
used the lower case form for the term "link". Can these be used
interchangeably? Do they refer to the same network object?
Now I'll try to illustrate my concern with using the term "congruent path"
in these drafts (using ASCII-art):
                       C---------D
                     /                 \
            A----B                   E-----F
                     \                  /
                     G------------H
Consider an SR domain that includes all the nodes shown in the network
diagram. An SR tunnel from A to F that traverses the network as
A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of
"congruent" as "two figures or objects are congruent if they have the same
shape and size, or if one has the same shape and size as the mirror image
of the other", it looks as the path A-B-G-H-E-F is congruent to that SR
tunnel. But a packet of an active OAM intended to monitor a flow over the
SR tunnel is out-of-band relative to that flow and will not produce any
meaningful measurement. Of course, for the case of the extensions in drafts
*-twamp-srpm, direct loss measurement can be performed, as information
collected from node F and packets that collect the counters are not
required to be in-band with the monitored flow. So, this example, in my
opinion, illustrates two of my concerns:

   - using a congruent path for active performance measurement, e.g., TWAMP
   or TWAMP Light, may produce information that does not reflect the condition
   experienced by the monitored flow. It seems that the terminology should
   reflect the fundamental requirement of ensuring that active OAM test
   packets are in-band with the monitored flow.
   - there are no technical requirements to justify using in-band test
   packets for direct packet loss measurement. In fact, using the in-band
   method for collecting in-profile counters leads to a waste of bandwidth,
   which may have a negative impact on services that require low-latency
   and/or low packet loss. As demonstrated in this example, direct packet loss
   can be performed using an out-of-band mechanism, e.g., SNMP queries,
   Netconf notifications based on YANG data model.

> <RG00> 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.
>
 GIM>> While I agree with the generic requirements you've listed I'm a bit
confused about how the deployment of OWAMP and TWAMP protocols can be
related to the proposed in *-stamp-srpm extensions. STAMP, similar to OWAMP
and TWAMP, is the active measurement protocol, per the definition of RFC
7799. The direct loss measurement method is clearly a passive method and,
in my opinion, it is decremental to the network to use in-band active
method collecting in-profile counters when there is no technical
requirement to use such an intrusive method.

> There are too many unaddressed aspects, particularly the risk introduced
> by the protocol on network security, to comprehensively evaluate the
> proposed solution.
>
> <RG00> 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.
>
 GIM>> I don't think that a mere reference sufficiently explains why the
use of zero UDP checksum in IPv6 header is not decremental, does not create
a security risk for the protocol.

> <RG00> 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.
>
GIM>> I believe that every well-known term has been defined somewhere.
Since the document differentiates between the two, I hope that it would not
be too difficult to explain or illustrate what is the difference.

>    Does the draft change procedure defined in Section 4.1 RFC 8762?
GIM>> Thank you for clarifying that. I'd note that the current text is not
clear about that.

>
>    - 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?
>
> <RG00> 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.
>
GIM>> I've clarified my question about the term "congruent path" above. I
hope that the diagram makes it clearer.

> <RG00> Yes, this can be Yang model. We can review
> <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>and add any
> missing items in a separate draft. We can also add a reference in this
> draft.
>
GIM>> Management of a protocol, configuration is an integral part of the
protocol specification. I've expected that *-stamp-srpm drafts include more
substantial text about the management than "out of the scope". In my
opinion, a section on the management is required and if the authors decide
to augment STAMP Yang data model, it should include the new YANG module.

> <RG> This is explained in the third paragraph of Section 1.
GIM>> I cannot find any technical explanation for the introduction of the
new PM protocol to collect in-profile counters and not use the Direct
Measurement TLV defined in draft-ietf-ippm-stamp-option-tlv
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>
(already cleared IESG review). Could you help me by pointing to the
explanatory test in the paragraph you're referring to:
   This document specifies procedures for sending and processing probe
   query and response messages for Performance Measurement in SR
   networks.  The procedure uses the mechanisms defined in [RFC8762]
   (STAMP) and its TLV extensions [I-D.ietf-ippm-stamp-option-tlv] for
   Performance Measurement.  The procedure specified is applicable to
   SR-MPLS and SRv6 data planes and is used for both Links and end-to-
   end SR Paths including SR Policies and Flex-Algo IGP Paths.  Unless
   otherwise specified, the mechanisms defined in [RFC8762] and
   [I-D.ietf-ippm-stamp-option-tlv] are not modified by this document.

> <RG> Does RFC 8762 support simultaneous sessions for authenticated and
> non-authenticated modes? If yes, can you please point to the procedure in
> the RFC 8762 and we can simply refer to it? I am not sure  how both packet
> formats be distinguished by a reflector node when using the same UDP port.
>
GIM>> Whether STAMP test session is in authenticated or unauthenticated
mode is the matter of configuration (as it is for TWAMP). You can
check the STAMP
YANG data model draft
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/> and TWAMP
YANG data model
<https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/> (the latter
could be useful for *-twamp-srpm drafts).
As for distinguished of two concurrent sessions between a pair of nodes, in
STAMP one can take advantage of the STAMP Session Identifier (SSID) that is
defined in Section 3 of draft-ietf-ippm-stamp-option-tlv. If there is only
one session, then, in my view, the configuration of the STAMP session's
mode should suffice. Would you agree?

> <RG00> Out-of-band is the current behaviour and there is no change in the
> existing behaviour. We can clarify in the next revision.
>
GIM>> I'm confused. An active measurement protocol cannot be out-of-band,
otherwise, the measured metrics are meaningless. Thus, an implementation of
STAMP must ensure that the test packet is in-band with the monitored flow.
So, when you're saying "there is no change in the existing behavior" are
you referring to the behavior of STAMP or to something else? If your
intention to use the new protocol out-of-band, that clearly will be a
change of STAMP behavior.

> If a Path Segment SID associated with the test session, there seems no
> need to require the Session-Reflector look for in-band path. Would you
> agree?
>
>
>
> <RG> No. Existence of Path Segment ID does not mean in-band reply. It may
> be needed for RX counter for direct-mode loss measurement.
>
GIM>> Can you please clarify the use case for using the Path Segment SID in
the test packet? The text, as quoted, gives the impression that it is
needed for "the probe response message as defined in Figure 6 is sent back
to the sender node on the congruent path of the data traffic on the same
reverse direction Link or associated reverse SR Policy." I cannot find any
text that explains how the Segment Path SID in the test packet may be used
by "RX counter for direct-mode loss measurement".

>    method described in RFC 8403 <https://tools.ietf.org/html/rfc8403>?
>    What is distinctly unique about the loopback mode proposed in the section?
>
GIM>> Yes, RFC 8403 doesn't mention these RFCs, nor refers to RFC 8762. In
my opinion, it was demonstrated in RFC 8403 how SR, SR-MPLS in the case
discussed, can be used to circle the test packet through the SR domain. By
using that method, an operator may not only detect the failure in the
network but, by correlating failure reports from the intersecting traces,
automate the failure localization. What is the use case for the Loopback
mode? Roundtrip delay and roundtrip packet loss measurement? What requires
standardization?

Is the "liveness monitoring" functionally identical to path continuity
> <RG00> STAMP  probe messages are used for synthetic packet loss which can
> be used to detect connection loss. The draft simply highlights this obvious
> metric.
>
GIM>> I cannot agree that STAMP can efficiently be used to detect the path
continuity loss. Perhaps even stronger, I would not advise and strongly
discourage the use of STAMP for path continuity monitoring. BFD (RFC 5880)
is intentionally lightweight and is capable of detecting a failure within
10 msec. Do you believe that STAMP test packets should be transmitted with
3.3 msec interval?

> The TTL field in the IPv4 and MPLS headers of the probe query messages is
> set to 255 *[RFC5357] except following two cases*.
>
GIM>> Can please you quote the text in RFC 5357 that requires setting
TTL/Hop Limit to 255?

> <RG00> This is described in RFC 6936. It will be very specific to the UDP
> port provisioned for STAMP. We will add reference to RFC 6936 in Security
> Section.
>
GIM>> RFC 6936 provides us with an exceptionally detailed analysis of that
question. I don't think that a reference can explain why using zero UDP
checksum is an acceptable practice. I recall that concern about the IPv6
security was the reason why RFC 7820 is applicable only to IPv4 and
includes the following text in regard to IPv6:
   UDP over IPv6, as defined in [IPv6], does not allow a zero checksum,
   except in specific cases [ZeroChecksum].  As discussed in
   [ZeroChecksum], the use of a zero checksum is generally not
   recommended and should be avoided to the extent possible.
And if the authors believe that they have an exceptional case, the case
must be stated.

> <RG00> STAMP  probe messages are used for synthetic packet loss which can
> be used to detect connection loss (performance metric). The draft simply
> highlights this obvious metric.
>
GIM>> What could be the detection interval when using STAMP? How that is
compared with BFD?

> <RG> Ok, we can update the text to indicate *synthetic* loss.
>
> <RG> We can update text to : (*which requires clock synchronization for
> one-way delay measurement).*
>
GIM>> I think that we can have a single mechanism instead of two defined in
*twamp-srpm nd *stamp-srpm. Would be interesting to hear from SPRING and
IPPM WGs.