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 <mach.c...@huawei.com> wrote: > 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) <rgandhi=40cisco....@dmarc.ietf.org>; Greg > Mirsky <gregimir...@gmail.com> > *Cc:* spring <spring@ietf.org>; IPPM Chairs <ippm-cha...@ietf.org>; > spring-cha...@ietf.org; Tommy Pauly <tpauly=40apple....@dmarc.ietf.org>; > IETF IPPM WG (i...@ietf.org) <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 <ZTR>. > > > > Cheers, > > Tianran > > > > *From:* spring [mailto:spring-boun...@ietf.org <spring-boun...@ietf.org>] *On > Behalf Of *Rakesh Gandhi (rgandhi) > *Sent:* Wednesday, November 18, 2020 7:41 AM > *To:* Greg Mirsky <gregimir...@gmail.com> > *Cc:* spring <spring@ietf.org>; IPPM Chairs <ippm-cha...@ietf.org>; > spring-cha...@ietf.org; Tommy Pauly <tpauly=40apple....@dmarc.ietf.org>; > IETF IPPM WG (i...@ietf.org) <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 <RG>.. > > > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Tuesday, November 17, 2020 at 5:27 PM > *To: *Rakesh Gandhi (rgandhi) <rgan...@cisco.com> > *Cc: *Tommy Pauly <tpauly=40apple....@dmarc.ietf.org>, IPPM Chairs < > ippm-cha...@ietf.org>, spring-cha...@ietf.org <spring-cha...@ietf.org>, > IETF IPPM WG (i...@ietf.org) <i...@ietf.org>, spring <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. > > > > <RG> 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. > > > > <RG> 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. > > > > <ZTR> 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. > GIM>> You've brought a very good question on how the return path, in case required by the Sender Control Code, introduced in draft-gandhi-ippm-twamp-srpm, is specified? As you've pointed out, RFC 5357 does not use TLV extensions. Should I assume that the return path, if required, provisioned through the management plane? I think that that requires clarification. > > > [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 the > sender and reflector. The current direct loss measurement TLV may just > apply to the scenario without packet out-ordering. > GIM>> I agree with your observation on the purpose of the Block Number field in both TWAMP-Light and STAMP documents. In my understanding, the new protocol may be also used to collect counters generated by methods other than Alternate Marking. In that case, I assume, the value of Block Number may not convey any information. > > > [Mach] In addition, whether to keep it as current design or to define a > new TLV for direct loss measurement can be debatable. > GIM>> I agree with you. And that what I am proposing - review the requirements, agree on requirements, and review the proposed solution based on these requirements. > > > 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. > > > > <RG> 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. > > > > <RG> 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. > > > > <RG> Per session basis between different sender nodes and this reflector > node, some senders will request the replies in-band (e.g. for two-way > mode). Sessions are provisioned on the Sender nodes and reflector simply > reflects based on the received test-packet (e.g. for a bidirectional SR > path). This is also similar to as described Section 3.1 in RFC 6374, top of > page 22. There is no need to create a such state for each session on the > reflector node and create a scale limitation. Recall that we are trying to > avoid the scale limitation by eliminating the Control protocol signaling. > > > > <ZTR> I find some value to include the path TLV in wire. As Rakesh > mentioned, this can reduce the reflector configuration. But I am not > convinced to introduce the sender control code field. It seems to me, the > presence of path TLV indicates the bidirectional congruent path. Vise > versa. > > > > [Mach] Regarding how to specify the return path, the draft defines two > ways to achieve that, one is to use control code to direct whether the > reflected Test should be along the reverse path of a bidirectional path, > this applies to both TWAMP (no TLV mechanisms) and STAMP. At the same time, > in the case of STAMP, it also defines the return path TLV to explicitly > specify the return path, which bring more options to specify the return > path. Therefore, I see benefit of the two ways. > GIM>> I think you've pointed to some vagueness in the definition of a mechanism used to define the return path. My understanding is that if a response required, the Return Path TLV must be present in a test packet. But, if TLVs are not used for TWAMP-like direct loss measurement, why not use the same method to control the return path? I believe that consistency is a good quality of a protocol (yes, I see *-twamp-srpm and *-stmp-srpm as a single protocol only presented as different entities). > > > > > Best regards, > > Mach > > > > What is the relationship between the *-srpm drafts and BFD? > > Some text in the *-srpm drafts suggest that the proposed method can be > used to monitor for the loss of a path continuity. That may be viewed as an > alternative to the BFD protocol method for the detection of a network > failure. If the discussion of Loopback mode and monitoring of liveness > remain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs > be made aware of the proposals. I didn't take the liberty of adding BFD WG > or its Chairs. I believe that decision to be made by the Chairs of IPPM And > SPRING WGs. > > > > <RG> As mentioned in previous replies, STAMP/TWAMP test messages are also > used today for *synthetic* packet loss measurement which can be also used > to detect/monitor connection loss (performance metric). The draft simply > highlights this obvious metric. This is also very similar to what is > described in ITU Y.1731, Section 7.1. > > > > Thanks, > > Rakesh > > > > Regards, > > > > > > On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <gregimir...@gmail.com> > wrote: > > Hi Rakesh, > > thank you for your prompt response, much appreciated. I'll carefully read > your responses. Looking forward to the continued discussion. > > > > Regards, > > Greg > > > > On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) < > rgan...@cisco.com> wrote: > > Hi Greg, > > > > Thank you for your review comments. As mentioned in the IPPM session > today, the email response was sent as attachments, see archive blow: > > https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ > > > > I am attaching them in word documents for the convenience. We can address > your comments below in the next revision of the document. > > > > Thanks, > > Rakesh > > > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Friday, November 13, 2020 at 10:09 AM > *To: *Rakesh Gandhi (rgandhi) <rgan...@cisco.com> > *Cc: *Tommy Pauly <tpauly=40apple....@dmarc.ietf.org>, IPPM Chairs < > ippm-cha...@ietf.org>, spring-cha...@ietf.org <spring-cha...@ietf.org>, > IETF IPPM WG (i...@ietf.org) <i...@ietf.org> > *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > Hi Rakesh, > > thank you for your response to my review. Please find my follow-up notes > in-lined below under the GIM>> tag. > > I hope you've found more detailed comments in the attachments (re-attached > for your convenience). I'm looking forward to reading your responses to the > detailed comments of all four drafts. > > > > Regards, > > Greg > > > > On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <rgan...@cisco.com> > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. Attached please find the email replies to your > review sent earlier. The replies are copied inline below for convenience, > tagged with <RG00>. > > > > > > *From: *ippm <ippm-boun...@ietf.org> > *Date: *Monday, November 9, 2020 at 11:48 AM > *To: *Tommy Pauly <tpauly=40apple....@dmarc.ietf.org> > *Cc: *IPPM Chairs <ippm-cha...@ietf.org>, spring-cha...@ietf.org < > spring-cha...@ietf.org>, IETF IPPM WG (i...@ietf.org) <i...@ietf.org> > *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and > draft-gandhi-ippm-stamp-srpm > > Dear WG Chairs, Authors, and IPPM WG community, > > I've reviewed these drafts and have some comments to share. Below, please > find my thoughts on whether these drafts can be adopted. More specific > comments on each pair of drafts (TWAMP-related and STAMP-related draft and > its accompanying draft targetted to the SPRING WG) are in the attached > documents. > > > > 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 > > I've got surprised that the drafts don't use the terminology from RFCs > 4656/5357 and RFC 8762, 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 and reasonably well-written. > > > > <RG00> We can change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > > GIM>> I believe that the consistency in terminology between the core RFC > 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. > > <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 listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't think > that 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 tunnel from A to F that traverses the network as > A-B-C-D-E-F. 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", path A-B-G-H-E-F is > congruent to the SR tunnel. But a packet of an active OAM intended to > monitor a flow over the SR tunnel is out-of-band and will not produce any > meaningful measurement. Of course, for the case of the extensions in > drafts, direct loss measurement can be performed, as information collected > from node F. So, this example, in my opinion, illustrates two of my > concerns: > > - using a congruent path for an active OAM protocol may produce > information that does not reflect the condition experienced by the > monitored flow. It seems that the terminology should reflect the > fundamental requirement for using active OAM to maintain the test packets > in-band with the monitored flow. > - there are no technical requirements to justify using in-band active > OAM protocol for direct packet loss measurement. 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. > > > > · Does the document solve a real problem? > > No, it appears that both TWAMP and STAMP drafts define a new > performance measurement protocol for the purpose of combining OWAMP/TWAMP > and STAMP functionality in the respective drafts, and adding the ability to > collect counters of "in-profile" packets. I couldn't find sufficient > technical arguments for using a PM protocol instead of, for example, > extending the existing OAM mechanisms like ICMP multi-part message > extension per RFC 4884. > > > > <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>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > <https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03> has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP/STAMP for exclusive direct > packet loss measurement. > > > > · Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocols on network security, to comprehensively evaluate the > proposed solutions. > > > > <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 or TWAMP Light. Other than this, I > did not find any other security related issue in your review. > > 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. > > > > Thanks, > > Rakesh > > > > > > Regards, > > Greg > > > > > > > > > > On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly= > 40apple....@dmarc.ietf.org> wrote: > > 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 > > _______________________________________________ > 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