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 < 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 > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
