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 <ippm-boun...@ietf.org> Date: Friday, November 6, 2020 at 11:18 AM To: James Guichard <james.n.guich...@futurewei.com> Cc: spring@ietf.org <spring@ietf.org>, ippm-cha...@ietf.org <ippm-cha...@ietf.org>, spring-cha...@ietf.org <spring-cha...@ietf.org>, IETF IPPM WG <i...@ietf.org> 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 <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>> wrote: 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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
