From nobody Wed Nov 18 23:41:38 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5238E3A111A; Wed, 18 Nov 2020 23:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhKHBTIRTSEc; Wed, 18 Nov 2020 23:41:27 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF033A1116; Wed, 18 Nov 2020 23:41:27 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CcBQX4RxRz67FD8; Thu, 19 Nov 2020 15:39:32 +0800 (CST) Received: from fraeml709-chm.china.huawei.com (10.206.15.37) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 19 Nov 2020 08:41:24 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 19 Nov 2020 08:41:24 +0100 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.200]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Thu, 19 Nov 2020 15:41:12 +0800 From: Mach Chen To: Tianran Zhou , "Rakesh Gandhi (rgandhi)" , Greg Mirsky CC: spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutxTJVi9zzpG0iVJvrFDESlT6m/jAuAgAGIKYCABKWmAIAEH64AgAAA6ACAAqNCgIAAFHgAgAH03ICAAKEOYA== Date: Thu, 19 Nov 2020 07:41:11 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FCCAD2dggeml530mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 07:41:32 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FCCAD2dggeml530mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tianran, Rakesh and Greg, Please see some responses inline with [Mach]... From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Thursday, November 19, 2020 1:33 PM To: Rakesh Gandhi (rgandhi) ; Greg Mi= rsky Cc: spring ; IPPM Chairs ; spring-ch= airs@ietf.org; Tommy Pauly ; IETF IPPM= WG (ippm@ietf.org) Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-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-bounces@ietf.org] On Behalf Of Rakesh Gandhi (r= gandhi) Sent: Wednesday, November 18, 2020 7:41 AM To: Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srp= m and draft-gandhi-ippm-stamp-srpm Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove 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-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.o= rg) >, spring > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-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 ad= ding 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-k= nown terms "Links", "Congruent Paths", "SR Path". If you prefer, we can def= ine 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 wo= rk 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 technic= al solution to the task of direct loss measurement. Please find my reasonin= g 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 dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and I= TU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX an= d RX counters for direct-mode loss measurement. TWAMP/STAMP messages define= d in the drafts are equivalent of them that take advantage of the widely de= ployed TWAMP protocol and as well this same protocol can be deployed in IPv= 4/IPv6/MPLS/SRv6/EVPN/etc. networks. I think RFC6374 for MPLS and Y.1731 make some noise here. The point i= s if we need a new direct packet loss measurement for STAMP, when STAMP alr= eady defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/dra= ft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fu= lfill 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-sta= mp-srpm assumes that marking-based solution (which can address the packet o= ut-ordering issue) is used, hence the block number is introduced. The block= number is used to correlate the counters from the sender and reflector. Th= e current direct loss measurement TLV may just apply to the scenario withou= t packet out-ordering. [Mach] In addition, whether to keep it as current design or to define a new= TLV for direct loss measurement can be debatable. 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 L= ight, 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 s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re 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 th= at 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 an= d direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e 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 network= s, 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 tha= t 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 YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, 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. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. I find some value to include the path TLV in wire. As Rakesh mentione= d, this can reduce the reflector configuration. But I am not convinced to i= ntroduce the sender control code field. It seems to me, the presence of pat= h 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 reflecte= d Test should be along the reverse path of a bidirectional path, this appli= es to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the ca= se 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. 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 alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also u= sed today for synthetic packet loss measurement which can be also used to d= etect/monitor connection loss (performance metric). The draft simply highli= ghts 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 > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > 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 y= our comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-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) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-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 f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying 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", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d 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. 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 definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. 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 congrue= nt if they have the same shape and size, or if one has the same shape and s= ize 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 t= he 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 measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or 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 O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, 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 fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive 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 propose= d solutions. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP or TWAMP Light. Other than this, I did n= ot 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 > wrote: Hello IPPM, For the past few meetings, we've had updates on the work in the SPRING WG t= hat was using STAMP and TWAMP. Since those documents ended up making extens= ions to the base protocols, the chairs of SPRING and IPPM decided that it w= ould be best to split the documents and track the IPPM extension work in th= e 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 y= ou believe the IPPM WG should adopt this work by replying to this email. Pl= ease provide your feedback by the start of the IETF 109 meeting week, on Mo= nday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FCCAD2dggeml530mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tianran, Rakesh and Greg,

 

Please see some responses inline with [Mach]…

 

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

 

Hi Rake= sh and Greg,

&n= bsp;

I may n= ot very clear about the context. Please allow me to jump in.

It seem= s both of you make some valid point.

Please = see in line with <ZTR>.

&n= bsp;

Cheers,=

Tianran=

&n= bsp;

From: spring [mailto:sprin= g-bounces@ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky <gregimi= rsky@gmail.com>
Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@= ietf.org>; spring-chairs@ietf.org; Tommy= Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.o= rg>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

 

Hi Greg= ,

&n= bsp;

Thank y= ou for your review and discussions on the drafts. This will help improve th= e work on this important work.

Please = see replies inline with <RG>..

&n= bsp;

 

From: Greg= Mirsky <gregimirsky@gmail.com<= /a>>
Date: Tuesday, November 17, 2020 at 5:27 PM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, IET= F IPPM WG (ippm@ietf.org) <ippm@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,<= o:p>

I've read the responses to my d= etailed comments. I don't think that only adding references will solve the = problems with the documents. If authors are interested in addressing my com= ments, we can start working on solving them one by one.

 

<RG&= gt; As mentioned in previous replies, we can add references for the well-kn= own terms “Links”, “Congruent Paths”, “SR Pat= h”. 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 tex= t for it. Will be happy to work with you to address these.

&n= bsp;

But I am very much concerned wi= th the technical value of these drafts. And here's why I feel that the prop= osed documents don't provide a sound technical solution to the task of dire= ct 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. No= te, that RFC 6374 includes a method for direct loss measurement in MPLS net= works that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension t= o RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct pack= et loss measurement. STAMP and all its extensions are applicable in IPv6 ne= tworks and, thus, can be used in the SRv6 domain.

 

<RG&= gt; As mentioned in previous replies, both RFC 6374 (in Section 4.2) and IT= U 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 tak= e advantage of the widely deployed TWAMP protocol and as well this same pro= tocol 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 Mea= surement TLV (https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-opt= ion-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 d= iscussions are mainly about draft*-stamp-srpm.

 

[Mach] In the case of direct packet loss measurement, draft-gandh= i-ippm-stamp-srpm assumes that marking-based solution (which can address th= e packet out-ordering issue) is used, hence the block number is introduced. The block number is used to correlat= e the counters from the sender and reflector. The current direct loss measu= rement TLV may just apply to the scenario without packet out-ordering.

 

[Mach] In addition, whether to keep it as current design or to de= fine a new TLV for direct loss measurement can be debatable.  

 

How the proposed method of dire= ct packet loss is related to TWAMP light and STAMP?

There's no apparent technical r= elationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm drafts an= d STAMP. Drafts do not extend or re-use the basic mechanisms defined for&nb= sp; TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mo= de and new formats of test packets that are decisively different from the f= ormats 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 responde= r. And that is another clear indication that the proposed mechanism represe= nts a new protocol, neither extends TWAMP Light and/or STAMP nor updates th= eir specifications.

 

<RG&= gt; As mentioned in previous replies, other than timestamp vs. counter and = it’s format, the messages and processing of them are the same for del= ay and direct-mode loss measurement.

  • Is there any advantage in introducing a dedicated pack= et format for the direct packet loss in STAMP comparing to using the Direct= Measurement TLV extension?

Though it appears the using a d= edicated 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 t= he new packet with TLVs is unlikely to be more efficient and reduce the pro= cessing delay, than if using the Direct Measurement TLV as defined in draft= -ietf-ippm-stamp-option-tlv.

 

<RG&= gt; As mentioned in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm. = For link loss measurement (direct-mode), there is no TLV required for examp= le. 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 Cont= rol Code?

Using the Sender Control Code m= ay require the use of the additional TLV that carries the return path infor= mation, Path TLV. If the ability to control the return path is required tha= t can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including t= he Path TLV in each test packet. Hence, there seem no technical requirement= s to introduce the Sender Control Code field in the Base STAMP format defin= ed in RFC 8762.

 

<RG&= gt; Per session basis between different sender nodes and this reflector nod= e, some senders will request the replies in-band (e.g. for two-way mode). S= essions 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 ea= ch session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scal= e limitation by eliminating the Control protocol signaling.

 

<ZTR> I find some value t= o include the path TLV in wire. As Rakesh mentioned, this can reduce the re= flector configuration. But I am not convinced to introduce the sender contr= ol code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa. <= /o:p>

 

[Mach] Regarding how to specify the return path, the draft define= s two ways to achieve that, one is to use control code to direct whether th= e reflected Test should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanism= s) and STAMP. At the same time, in the case of STAMP, it also defines the r= eturn path TLV to explicitly specify the return path, which bring more opti= ons to specify the return path. Therefore, I see benefit of the two ways.

 

 

Best regards,

Mach

 

What is the relationship betwee= n the *-srpm drafts and BFD?

Some text in the *-srpm drafts = suggest that the proposed method can be used to monitor for the loss o= f a path continuity. That may be viewed as an alternative to the BFD protoc= ol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness rem= ain 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&= gt; As mentioned in previous replies, STAMP/TWAMP test messages are also us= ed today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

&n= bsp;

Thanks,=

Rakesh<= o:p>

=  

= Regards,

 

 

On Sun, Nov 15, 2020 at 10:10 P= M Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Rakesh,

thank you for your prompt respo= nse, much appreciated. I'll carefully read your responses. Looking for= ward to the continued discussion.

 

Regards,

Greg

 

On Sun, Nov 15, 2020 at 10:07 P= M Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:

Hi Greg,

 

Thank you for your review comments. As mentio= ned in the IPPM session today, the email response was sent as attachments, = see archive blow:

https://mailarchiv= e.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 th= e document.

 

Thanks,

Rakesh

 

 

From: Greg= Mirsky <greg= imirsky@gmail.com>
Date: Friday, November 13, 2020 at 10:09 AM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@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. Ple= ase find my follow-up notes in-lined below under the GIM>> tag.<= /o:p>

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) <rgand= hi@cisco.com> wrote:

Thank you Greg for ta= king 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-bounce= s@ietf.org>
Date: Monday, November 9, 2020 at 11:48 AM
To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@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 communit= y,

I've reviewed these drafts and have some comm= ents to share. Below, please find my thoughts on whether these drafts can b= e 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 th= e 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 read= able and reasonably well-written.

 

<RG00> We can c= hange Sender to Session-Sender and Reflector to Session-Reflector if it hel= ps. 

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 ar= e many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) a= nd 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 y= ou've mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while r= eferenced 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 us= ing the term "congruent path" in these drafts (using ASCII-art):<= o:p>

            &nb= sp;          C---------D

            &nb= sp;        /            &= nbsp;    \

            A--= --B                   E--= ---F

            &nb= sp;        \            &= nbsp;     /

            &nb= sp;        G------------H

Consider an SR tunnel from A to F that traver= ses 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 t= unnel. 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 d= rafts, direct loss measurement can be performed, as information collected f= rom 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 fundamenta= l requirement for using active OAM to maintain the test packets in-band with the monitored flow.
  • there are no technical requirements to justify using i= n-band active OAM protocol for direct packet loss measurement. As demonstra= ted in this example, direct packet loss can be performed using an out-of-ba= nd 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 abil= ity 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 sy= nthetic packet loss measurement today. I am not sure extending ICMP for LM = is a good option here.

GIM>> I agree with the requirement= s you've listed (though the SPRING WG OAM requirements document has been abandoned and expired 3= 3; years ago). I believe that there's no sufficient technical reason t= o use OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. =

 

·=   Is the proposed solution technically viable?

There are too many unaddressed aspects, particu= larly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

 

<RG00> About yo= ur comment on zero checksum, this is described in Security section in RFC 6= 936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally pr= ovisioned in the domain by the operator for STAMP or TWAMP Light. Other tha= n this, I did not find any other security related issue in your review.

GIM>> I don't think that a mere referen= ce 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=3D40apple.com@dmarc.ietf.org> wrote:

Hello IPPM,

 

For the past few meetings, we’ve had up= dates on the work in the SPRING WG that was using STAMP and TWAMP. Since th= ose 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-s= tamp-srpm.

 

Please provide your feedback on these documen= ts, 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, Nov= ember 16.

 

Best,

Tommy & Ian

_____________________________________________= __
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297FCCAD2dggeml530mbschi_--