Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
Gyan Mishra <hayabusagsm@gmail.com> Sat, 05 December 2020 19:23 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E223A0AC1; Sat, 5 Dec 2020 11:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gsxzP-VB1aVQ; Sat, 5 Dec 2020 11:23:08 -0800 (PST)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C4B3A0ABE; Sat, 5 Dec 2020 11:23:08 -0800 (PST)
Received: by mail-pg1-x531.google.com with SMTP id f17so5690138pge.6; Sat, 05 Dec 2020 11:23:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DfHTkuCXMb1EwH9YP+h9aoyAU1S3jBx0c/vN2vy8LS8=; b=u1ZzoO1/qJ/Rt/nfevXA2g9Hx7bsunMWCWQyftB9J+Mj6zHjkO2GvCOYi8xEQOLNdz bcwjvvSDdYR+5+/dvdHcik9rfMwSeoJjcnMOI8LGfBpFrrEl74HusEnQUgYV1QhzN3oX NXHYqO4VZnpKyhwV4+j/X/aLhlUbRGpyyw3EDPbZLzZeiXL+uNksWbZvFGiDhG4pGxJ7 EkPrkxZb2Wbl57E1b1FWaLfkR1m7mVTKKFkGaHz4FSguHuhQFqS04IxGAd3c2uk+ZFYB 1uVVU4qSHjSmqIut3AQTVF+GhP4/cn46Q7amcCDDbi+XUBrqF1uarjTxM9K/qzDnkrLj +Tug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DfHTkuCXMb1EwH9YP+h9aoyAU1S3jBx0c/vN2vy8LS8=; b=oqgu27gWbWI12LCn/Gfyxbnz/Ev5phl2T9Zz6sj4HZUceCxpwr5uTy9xC0wC8tQl2y N1+wtxWvssUTDRVQV/6wrJCTKeS3lVx8nzoCAvquEysSopayIhN8b6kPG8fskufwCVGj ffWGkfBm8tizBPbewX0P0iPmq7+ww0awwWTPco8OY0KDWd4HZEU4bZD7J2UeZPIaWnwz o8nhFHpB2PiPETqX9HyVXKJhgOzMfCx/bng8s4R26TLvYlzOri076iSjiNobYe8YHZH1 k4cjk3yfkld3wErtpC8u9eB5uxJhLyQ4ZfAHwDAY5aLes6A049O05aqbPfxSnm/jHG7t t37A==
X-Gm-Message-State: AOAM5320gWavV4aKtxB+SQLX5pwlg2BBDDR6kkWNCX0HxkoOpbo2Q9fA 6Ff6B+m+KfubJpiDlzJqRYNOqIIf7vyUQ2YEfko=
X-Google-Smtp-Source: ABdhPJzSoneayfQfuWpUrfQsvxfRvZarw1wCmQsyGIXrqnbuu6fCBU0cyaY3QT9iuHhfIvBxXQ1qkRsklEFkUz0GVoA=
X-Received: by 2002:a65:5ac4:: with SMTP id d4mr3407642pgt.50.1607196187043; Sat, 05 Dec 2020 11:23:07 -0800 (PST)
MIME-Version: 1.0
References: <DM6PR13MB3066F695F1ABFC22C52CEA3BD21D0@DM6PR13MB3066.namprd13.prod.outlook.com> <CA+RyBmWROaXBChBht9hCq3S6r5EASc47Qny1mr3u6kyuuiTXfQ@mail.gmail.com> <DM6PR11MB3115E21076C99CDE5D0B4B25BFE90@DM6PR11MB3115.namprd11.prod.outlook.com> <CA+RyBmVMX4HsmFQ8r5LfTj_DrZmF+ME8BLT8Lgzvyyk70=nzfw@mail.gmail.com> <CABNhwV1gKYvnyV-7_1JQ5h_2299epNDxxuuKm5_86FQdziSA6g@mail.gmail.com> <DM6PR11MB3115E8AAC89CECAA553E8191BFF90@DM6PR11MB3115.namprd11.prod.outlook.com> <CA+RyBmVcf5HGH05rkgwFhysG7EqE6cXnYjAzH-GrPgkStR4NyQ@mail.gmail.com> <DM6PR11MB31156BE924B8DF1F37E159BEBFF30@DM6PR11MB3115.namprd11.prod.outlook.com> <CA+RyBmWmd_RXefMksyTEWoH7xyiLkY-EhcQCs1APoWVpcqDoqg@mail.gmail.com> <CABNhwV3wGHejsRdnD6ppTBhOz+aaVkOBCJkQSOc+rTB6HbiNtA@mail.gmail.com> <DM6PR11MB3115AA86AEB65611AFE973A4BFF00@DM6PR11MB3115.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB3115AA86AEB65611AFE973A4BFF00@DM6PR11MB3115.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 05 Dec 2020 14:22:55 -0500
Message-ID: <CABNhwV3wp=86zvm1JJPDQB4xZ=R=QUoCa_2QcLwnmVSvdNzJBA@mail.gmail.com>
To: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, Greg Mirsky <gregory.mirsky@ztetx.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d02cca05b5bc855d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Ri71wuMqrFAcyuKVyKMeeZBoD4k>
Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2020 19:23:17 -0000
Hi Rakesh Please see in-line On Sat, Dec 5, 2020 at 10:32 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote: > Hi Gyan, > > > > Thanks for your review comments. Please see inline with <RG4>… > > > > *From: *Gyan Mishra <hayabusagsm@gmail.com> > *Date: *Saturday, December 5, 2020 at 1:16 AM > *To: *Greg Mirsky <gregimirsky@gmail.com> > *Cc: *Greg Mirsky <gregory.mirsky@ztetx.com>, IETF IPPM WG <ippm@ietf.org>, > James Guichard <james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com>, ippm-chairs@ietf.org <ippm-chairs@ietf.org>, > spring-chairs@ietf.org <spring-chairs@ietf.org>, spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh > > > > Had a general question. > > > > I read through the draft again and a question came to mind as this draft > is Standards Track, what new is being introduced other then a procedure of > how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane > and SRv6 which used the IPv6 data plane. I don’t believe there exists a > Standards track draft procedure for how to use STAMP over IP network or > MPLS network as an example. > > > > Section 4.1.4 describes SR-MPLS use case and SRv6 use case. As there > appears to be nothing new introduced such as a new IANA TLV or code point > or even a special SID code point for TWAMP, all basic vanilla SR, that > without this draft you could run STAMP, TWAMP, OWAMP over SR which has > existed for a while now. > > > > What is the new invention here? > > > > <RG4> SPRING drafts define the procedure for using TWAMP Light and STAMP > test-messages for SR path and links. The corresponding IPPM drafts define > the extensions needed for them. The SPRING drafts also use the extensions > for them defined in the corresponding IPPM drafts. The extensions are > needed for (1) in-band response request e.g. for two-way mode for links and > SR path, (2) Return path for SR e.g. when using bidirectional SR Path, and > (3) for collecting TX and RX traffic counters in-band for direct-mode loss > measurement. > > Gyan> Understood. Just to see if a precedence has already been set if > you point me another case where Spring or any other WG RFC Standards Track > that has defined procedures to use IPPM extensions. If this is the first > and may also set a new precedent, I think it’s a valid WG discussion. > > Sorry but I may have missed something. > > > > My thoughts are at most this be a BCP or I am thinking informational draft > would be appropriate. > > > > <RG4> Given above context, if WG thinks that any of the drafts should be > BCP or Informational or Experimental, we can update the draft accordingly. > > Gyan> Agreed. Thank you > > Thoughts? > > > > Gyan > > > > On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > > Hi Rakesh, > > thank you for the continued discussion. You can find my follow-up notes > in-line below under GIM3>> tag. I felt that one comment is at the root of > our different views on what is considered to be a problem that drafts > solve. You've said: > > <RG3> As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > But draft-ietf-ippm-stamp-option-tlv > <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>, > currently in Submitted to IESG for Publication WG state according to IETF > datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in > the section: > > The Direct Measurement TLV enables collection of the number of in- > profile packets, i.e., packets that form a specific data flow, that > had been transmitted and received by the Session-Sender and Session- > Reflector, respectively. The definition of "in-profile packet" is > outside the scope of this document and is left to the test operators > to determine. > > > > <RG4> > > Hi Greg, > > The motivation has been there in the draft-gandhi-ippm-stamp-srpm, Section > 1. Copied below for the convenience. > > > > The STAMP message with a TLV for "direct measurement" can be used for > > combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv > <https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00#ref-I-D.ietf-ippm-stamp-option-tlv> > ]. > > 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). Furthermore, for hardware-based counter collection > > for direct-mode loss measurement, the optional TLV based processing > > adds unnecessary overhead (as counters are not at well-known > > locations). > > > > Thus I cannot see any technical need for the introduction of yet another > way of direct loss measurement in STAMP. As for the case of TWAMP Light, I > believe that there's no sufficient evidence that the proposed direct > loss-measurement measurement method benefits existing implementations of > TWAMP Light. Also, historically, all extensions applicable to TWAMP Light > have been introduced through extending TWAMP proper, i.e., extending > TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presented > in the drafts we are discussing is, in my opinion, in violation of RFC 5357. > > > > <RG4> The IPPM WG Informational draft on TWAMP Light direct-mode loss > measurement, defines the message format and corresponding SPRING draft > defines the procedure for using that. It is not clear to me how providing > an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357. > > > > Thanks, > > Rakesh > > > > > > More notes can be found below. > > > > Regards, > > Greg > > > > > > On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> > wrote: > > Thank you Greg for your further reply and the discussions. > > *Good to know that you do see a need for the extensions for the > direct-mode packet loss detection and the authors are actively working on > an alternate methods using BFD (as you mentioned below).* > > GIM3>> As you've recognized, in draft-mirmin-bfd-extended > <https://www.ietf.org/archive/id/draft-mirmin-bfd-extended-03.txt> we > build an integrated OAM based on the lightweight Fault Management protocol > with optional Performance Monitoring, based on RFC 6374. RFC 6374, in turn, > provides a rich set of performance measurement methods, including direct > loss measurement. > > Please see replies inline with <RG3>…. > > *From: *Greg Mirsky <gregimirsky@gmail.com> > *Date: *Monday, November 30, 2020 at 11:30 AM > *To: *Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> > *Cc: *Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, > James Guichard <james.n.guichard@futurewei.com>, ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, > spring@ietf.org <spring@ietf.org>, Greg Mirsky <gregory.mirsky@ztetx.com> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh, > > thank you for the continued discussion. I appreciate your responses. I am > still not convinced of the value these documents add. Please find my > follow-up notes in-line below under the GIM2>> tag. > > Regards, > > Greg > > On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> > wrote: > > Thank you Gyan and Greg for your review comments and discussions. Please > see inline replies with <RG2>… > > *From: *Gyan Mishra <hayabusagsm@gmail.com> > *Date: *Wednesday, November 25, 2020 at 12:34 PM > *To: *Greg Mirsky <gregimirsky@gmail.com> > *Cc: *IETF IPPM WG <ippm@ietf.org>, James Guichard < > james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com>, ippm-chairs@ietf.org <ippm-chairs@ietf.org>, > spring-chairs@ietf.org <spring-chairs@ietf.org>, spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh > > I have been following this thread and to help progress the discussion I > would like to provide some comments in-line Gyan> > > Thanks > > Gyan > > On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > > 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 7:33 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. > > Please see replies inline with <RG>… > > *From: *ippm <ippm-bounces@ietf.org> > *Date: *Friday, November 6, 2020 at 11:18 AM > *To: *James Guichard <james.n.guichard@futurewei.com> > *Cc: *spring@ietf.org <spring@ietf.org>, ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, > IETF IPPM WG <ippm@ietf.org> > *Subject: *Re: [ippm] [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > 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 > > I've got surprised that the drafts don't use the terminology from RFC 4656 > and 5357 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. > > <RG> We are ok to 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. But I > don't think that switching the terminology will fix the fundamental issue > with the proposal. The operation that is required from the remote entity, > whether it is referred to as responder or Session-Reflector, is not defined > in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, > the behavior required, as described in the draft, cannot be characterized > as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely > new protocol that, if there's a need in the new PM OAM protocol, must be > properly defined. > > Gyan> I am in complete agreement with Greg about terminology and > consistency. The problem with inconsistency is that that you are not > following well known normative references required to understand the > specification leading to confusion and misunderstanding of the > specification. The goal should be clear and concise in terminology and > verbiage. > > <RG2> Agree. Will address the terms from RFC 5357 in the next revision. > > <RG> 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. 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. > > > - Does the document solve a real problem? > > No, it appears that these drafts define a new performance measurement > protocol for the purpose of combining OWAMP and TWAMP functionality 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. > > Gyan> This may sound basic but is a very critical subject going down the > same lines of clarity in verbiage so their is no misunderstanding. > “Congruent” by definition means shape of an object and if you super > imposed two objects on top of each other they fit perfectly and the edges > coincide identically. The problem with congruent is that it is based on > the shape and that shape could be a mirror image or reflection which may > not be exact. So when referring to a SR-TE path taken this could lead to > confusion as to path taken if it’s the same path or congruent which is > vague as to “exactly” which path is taken where here there is criticality > as to the path being referenced in terms of in-band versus out-of-band. I > agree that for direct in band packet loss measurement can be done via > existing OAM mechanisme via ICMP. > > <RG2> Ok, we will find an appropriate term for “sending packets on the > same path as data traffic”. > > <RG2> Extending ICMP for direct-mode loss measurement is outside the scope > of this draft. But good to see the agreement for the direct in band packet > loss measurement to be done (albeit by some other means). > > GIM2>> I feel that you misunderstand my position in regard to the use case > these four documents try to solve. I don't recall that I've stated that > "direct in-band packet loss measurement" requires any additional > standardization work. The Direct Measurement TLV has solved that for STAMP > and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I > cannot find any valid technical reason to re-open this and measure the > direct packet loss in a slightly different way. I must point out that a > claim that using fixed positions for the direct packet loss optimizes > performance does not stand for cases (Section 4.2.1 and 4.2.2 of > draft-gandhi-spring-stamp-srpm) when the return path is specified in the > Return Path TLV and, as I understand it, in some cases even the second TLV, > Node Address TLV, is used. Thus, it is clear that the proposed new method > of direct packet loss measurement does not offer any significant benefits > comparing to the STAMP's Direct Measurement TLV and appears nothing but > superfluous. > > <RG3> The direct-mode packet loss use-case is typically for the forward > direction packet loss. And this does not use the return path TLV. We can > clarify that in the draft. > > GIM3>> Clarification would be very helpful as your latest note might be > interpreted that the proposed mechanisms are not applicable in the case of > a bi-directional SR tunnel. > > <RG> 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 for exclusive direct packet > loss measurement. > > Gyan> Agreed > > <RG2> There is definitely a need to do direct-mode loss measurement in > IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that > there was an attempt to extend BFD for direct-mode loss measurement for > this purpose using RFC 6374 loss measurement message (see > draft-mirmin-bfd-extended-03). > > GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended > <https://www.ietf.org/archive/id/draft-mirmin-bfd-extended-03.txt> in the > past tense. The work and discussion of the proposal continues and the new > version will be published soon. > > *<RG3> Ok, so you do see a need for the extensions for the direct-mode > packet loss detection and the authors are actively working on an alternate > methods using BFD. * > > > - 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. > > <RG> 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 TWAMP. 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. > > Gyan> Agreed 0 UDP MIMA security threats and that you need to > thorough vetting of RFC 6936. > > <RG2> Yes, will add in the next revision. Hope we can work together on > needed text. > > To summarize my review of these two drafts: > > - these propose a new protocol, not an update or enhancement of the > TWAMP-like protocol; > > <RG> The probe and response messages defined in [RFC 5357] are used for > delay measurement and synthetic packet loss. The direct-mode packet loss > messages are defined in draft-gandhi-ippm-twamp-srpm > <https://datatracker.ietf.org/doc/draft-gandhi-ippm-twamp-srpm/> that > match these delay measurement messages. As stated, > draft-gandhi-ippm-twamp-srpm > <https://datatracker.ietf.org/doc/draft-gandhi-ippm-twamp-srpm/> defines > “extensions” for TWAMP Light. > > GIM>> I cannot find where RFC 5357 defines "the probe and response > messages". Could you give a more specific reference or provide the text > that, in your opinion, defines such messages? But I'm more concerned with > the direction of "extending" non-protocol referred to as "TWAMP Light". As > a contributor to BBF's TR-390, I'm have learned how different are existing > implementations of TWAMP Light. And that is also noted in EANTC > Multi-Vendor Interoperability 2019 white paper > <https://mail.google.com/mail/u/0/?q=draft-ietf-ippm-stamp-option-tlv#inbox?compose=CqMvqmRLZZrxJQtbnmkKJVzZBZszkgxPgsfzWBLMWntdzDFXDrjLTQtqrhmDFgdNbzkHXhJNrKg>. > The status of TWAMP Light is explained in RFC 8545 and I cannot see that it > can be used as a foundation of any standard. > > Gyan> I don’t see the probe a d response messages in TWAMP RFC 5357 > > <RG2> Agree to use term test-packet from RFC 5357. > > · several parts of the proposed protocol, e.g., Zero UDP checksum > in IPv6, require detailed security analysis, which is currently absent; > > Gyan> Agreed > > <RG2> Please see previous reply. > > <RG> This is specified in RFC 6936 Security Section. 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 TWAMP. > > GIM>> I've noted above that a simple reference does not sufficiently > explains why the use of zero UDP checksum in IPv6 header is not > decremental, does not create a security risk for the protocol. I believe > that the proposal to use zero UDP header checksum requires extensive > analysis, using the analysis provided in RFC 6936. > > Gyan> Completely Agree > > <RG2> Please see previous reply. > > > - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on > the Informational track even though it is essential to the new protocol as > it defines its key elements > > <RG> This was to address your previous comment quoted as: > > “- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Informational > > track is more appropriate for this specification.” > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > <RG> Having said that, we are ok to change to PS. > > GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. > If anyone is interested in standardizing an "extension", I'd expect that > they first define the base specification to which the extension applies. I > might have missed the definition of TWAMP Light protocol in the draft. Could > you point to the definition, for example, of the Authenticated mode in > TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? > > Gyan> Agreed > > <RG2> The Appendix I of RFC 5357 does have information on the > Authentication mode. As specified there, this is based on user configured > parameters. > > · I believe that draft-gandhi-spring-twamp-srpm should be > anchored at IPPM WG as it does introduce the new PM protocol. > > <RG> The TWAMP Light extension draft-gandhi-ippm-twamp-srpm > <https://datatracker.ietf.org/doc/draft-gandhi-ippm-twamp-srpm/> is > already in IPPM WG. The SPRING draft only defines SR PM procedures. > > Below, please find my detailed comments, questions on these drafts: > > - draft-gandhi-spring-twamp-srpm > > I have several questions about the relationships between this draft and > Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has > been mentioned. The nature of the TWAMP Light and what is required to make > it a standard is well-explained in Section 4 of RFC 8545 > <https://datatracker.ietf.org/doc/rfc8545/> (apologies for the long > quote): > > "TWAMP Light" is an idea described in Appendix I ("TWAMP Light > (Informative)") of [RFC5357]; TWAMP Light includes an unspecified > control protocol combined with the TWAMP-Test protocol. In > [RFC5357], the TWAMP Light idea was relegated to Appendix I because > TWAMP Light failed to meet the requirements for IETF protocols (there > are no specifications for negotiating this form of operation and no > specifications for mandatory-to-implement security features), as > described in Appendix A of this memo. See also [LarsAD] and > [TimDISCUSS]. > > Since the idea of TWAMP Light clearly includes the TWAMP-Test > component of TWAMP, it is considered reasonable for future systems to > use the TWAMP-Test well-known UDP port (whose reallocated assignment > is specified in this document). Clearly, the TWAMP Light idea > envisions many components and communication capabilities beyond > TWAMP-Test (implementing the security requirements, for example); > otherwise, Appendix I of [RFC5357] would be one sentence long > (equating TWAMP Light with TWAMP-Test only). > > Since we don't have an IETF document that addressed these open questions, > I don't think we can have a draft that proposes extensions to a > non-standard mechanism (Appendix is for Informational material, as I > understand it) on the Standard track. > > Gyan> Agreed > > <RG2> The procedure for using the RFC 5357 defined messages in TWAMP Light > configuration mode is defined in the corresponding spring drafts. It also > describes the provisioning model. > > GIM2>> If a return path can be provisioned for TWAMP Light, why the same > method of controlling a test session cannot be used for STAMP? > > <RG3> It is not expected that all STAMP TLV extensions need to be > supported for TWAMP Light using provisioning. > > <RG> This was to address your previous comment quoted as > > “- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Informational > > track is more appropriate for this specification.” > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > <RG> Having said that, we are ok to change to PS as you mentioned above. > > <RG> BTW, despite only difference of fixed vs. variable length payload in > STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it > uses the same approach of provisioning as defined in this draft). Hence, > security considerations for STAMP and TWAMP Light are not different. Note > that both STAMP and TWAMP Light have authenticated messages defined for > Security purpose. > > GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the > light, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot > find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode > of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the > discussion of "extension" to TWAMP Light. > > <RG2> The Authentication information is user-configured as shown in > Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in > Appendix I of RFC 5357. > > Now a number of more specific questions. > > draft-gandhi-spring-twamp-srpm: > > - In the Introduction it is stated that: > > The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides > simplified mechanisms for active performance measurement in Customer > IP networks by provisioning UDP paths and eliminates the need for > control-channel signaling. > > I can not find where, either Appendix I or TR-390, "eliminated the need > for control-channel signaling". Also, could you point where the referenced > documents describe "provisioning UDP paths"? > > <RG> The Appendix I of RFC 5357 has following text. We can reword and match the exact text if you prefer. > > > > “This example eliminates the need for the TWAMP-Control protocol, and > > assumes that the Session-Reflector is configured” > > GIM>> I think that the text you're proposing is even more confusing. It is > not clear which example the sentence is referring to. Also, what is the > basis for such an assumption? > > <RG2> This is the exact text from RFC 5357 Appendix I. Please go through > the entire Section in that RFC 5357 to avoid “out of context” discussion. > > > - It appears that the last paragraph in the Introduction describes the > relationship with Appendix I of RFC 5357: > > The procedure uses the mechanisms defined in [RFC5357] > (TWAMP Light) and its extensions for Performance Measurement. > > I think that the reference must be to Appendix I, not RFC 5357. Also, > could you please specify which extensions of TWAMP Light have been used in > this draft? > > <RG> We can add the Appendix I as reference in the next revision. > Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this > reference. > > GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a > normative reference while it is, by its nature, an Informational document. > > <RG2> If approved, it is fine to have informational draft/RFC in a > normative reference. But RFC 5357 is PS. > > > - In Section 2.3 describing the reference model is noted: > > The probe response message is typically sent to the sender node R1. > > In which scenarios the reflector acts differently? How such behavior is > related to the behavior of a TWAMP Session-Reflector, as defined in RFC > 5357? > > <RG> Do you prefer we remove “typically” from the sentence? > > GIM>> If that fits into the operational model of the new protocol you're > defining. > > > - Also in Section 2.3 a Link is mentioned as an element directly > connecting nodes in the presented reference model. Could you clarify what > is a Link? Is it always a physical connection between two systems or a > virtual? > > <RG> Both, please see Section 4.1.3. “Link” is well known term used in > many existing RFCs (please see RFC 5613, 5340, 8330). > > GIM>> Thank you for the references. I couldn't find a definition of an > object "Link" (capitalized) but only "link" (lower case). Hence, since the > draft consistently uses the capitalized form, I consider it to be something > else, something different from a link. > > <RG2> Ok, we can change Link to link in the next revision to avoid > confusion. > > > - In Section 3 behavior of the reflector described as > > ... no PM state for delay or loss measurement need to be created on the > reflector node R5. > > That is in contradiction to the behavior of a TWAMP Session-Reflector as > defined in RFC 5357. Could you provide a reference to an IETF standard > where this behavior is defined? Also, how, without creating a state at the > Session-Reflector, to achieve one-way delay and synthetic loss measurement > on a bidirectional SR tunnel? > > Gyan> Valid point > > <RG2> Bidirectional SR tunnel may have an SR state but the statement above > is that no PM (i.e. TWAMP Light) protocol session state is created for it. > We can clarify in the next revision. > > GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one > option. I am well-familiar with the implementation that uses the stateful > mode. > > <RG3> What information stateful PM need to maintain in the state on the > reflector? Doesn’t that cause scale issues. We can add in the draft you if > there is anything specifically needed in the spec. > > GIM3>> RFCs 5357 and 8762 are clear about what information must be > maintained by a Session-Reflector. The Session-Reflector must have > knowledge of the test session state and count reflected test packets. The > value of such a counter must be copied in the Sequence Number field of the > reflected packet. Thus the method enables the measurement of the one-way > packet loss metric. > > <RG> Quoting the text from Appendix I in RFC 5357. We can quote the text > as is. > > “In the case of TWAMP Light, the Session-Reflector does not necessarily have knowledge of the session state. “ > > GIM>> By the informational nature of Appendix I, the text is not > normative. I am familiar with the implementation of TWAMP Light which does > maintain the session state and thus supports one-way packet loss > measurement. If you require that the remote node does not maintain the > state, the draft must define that as part of the specifying the behavior of > the protocol. > > <RG2> Ok, we can discuss what information is to be maintained in that > state on the reflector for synthetic packet loss. We can add appropriate > text if you can help please. > > GIM2>> I don't see any reason to do that as that already defined in RFC > 8762 and draft-ietf-ippm-stamp-yang > <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/> > > <RG3> Ok. > > · Further, in Section 3 the selection of UDP port explained as > the following: > > As specified in [RFC8545], the reflector > supports the destination UDP port 862 for delay measurement probe > messages by default. This UDP port however, is not used for loss > measurement probe messages. > > To the best of my understanding, as one of the contributors and Editors of > RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector > without excluding any type of measurement. Besides, in TWAMP delay and > packet loss are measured in the same test session, using the same flow of > TWAMP-Test packets. > > Gyan> Agreed > > <RG2> Yes, we can use port 862 for both delay and synthetic packet loss – > they are using the same test packet. There is no change proposed in the > draft. > > GIM2>> Packet delay and synthetic packet loss measurements are already > supported in RFC 8762. Are you proposing a new protocol to duplicate the > STAMP functionalities? > > <RG3> As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > <RG> The packet loss in existing RFC 5357 refers to synthetic loss as > there is no support for direct-mode loss in RFC 5357. We can change the > text to clarify as “This UDP port however, is not used for direct-mode loss > measurement probe messages.” > > GIM>> I've found that there's some misconception in the draft. RFC 8545 > re-assigned UDP port 862 not for "delay measurement probe messages" but for > TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, > packet loss, reordering (RFC 4737 defines packet reordering metric), and > packet duplication measurement. > > > - Then the draft states that > > The sender uses the UDP port number following the guidelines specified in > Section 6 in [RFC6335]. > > Could you point to the guidelines that a user can use when selecting a UDP > port number of a test session? > > Gyan> Good point > > <RG> Please see section 6 in [RFC6335]. We can cite the range which will > be the same as used in [RFC8762]. This was also discussed earlier. > > https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ > > GIM>> I've looked through Section 6 but I don't find anything specifically > applicable to this draft we're discussing. If the protocol to use UDP port > numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it > seems that stating that explicitly would be the best way. > > <RG2> This would be, User Ports and Dynamic Ports ranges, which are defined in [RFC6335 <https://tools.ietf.org/html/rfc6335>]. Yes, we can add this text. > > > - At the closing of the paragraph, we read that > > The number of UDP ports with PM functionality needs to be minimized due > to limited hardware resources. > > Does a UDP port number pose PM functionality? How it is assigned to the > port number? > > <RG> UDP ports are user configured for delay and direct-mode loss PM as > described in Section 3.1. > > GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss > measurement uses port number different from the one used by a TWAMP-Test > packet, in my opinion, is another indication that this is the definition of > a different from TWAMP Light PM OAM protocol. > > <RG2> If we add a field in the packet then UDP port 862 may be used along > with the new field. But it will require extra processing in hardware. It is > better to use a different UDP port for processing efficiency in hardware. > > > - Following the above-quoted text, in Section 3 is noted: > > For Performance Measurement, probe query and response messages are > sent as following: > > Could you clarify if the listed further procedures deviate from > OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for > Session-Sender and Session-Reflector respectively? > > <RG> Probe messages follow the same procedure as defined in RFC 4656 and > RFC 5357. > > GIM>> All messages, i.e., TWAMP-Test packets as well as the defined > in draft-gandhi-ippm-twamp-srpm? > > <RG2> Yes, unless otherwise specified in the > draft-gandhi-ippm-twamp-srpm. > > > - for both delay and loss measurements draft requires test packet be > transmitted on a congruent path: > > the probe messages are sent on the > congruent path of the data traffic by the sender node > > It is not clear what "the congruent path" means. The definition > of congruency in geometry tells us that an object B is congruent to object > A if it has the same shape and size, but is allowed to flip, slide or turn. > How a path can be congruent to another path? > > Gyan> Agreed. The use of congruent in the context of pathing is > confusing as the path being addressed may not be reflected accurately by > the term congruent. > > <RG2> As replied above. > > <RG> 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 cannot assume what was the context of these RFCs. I've sketched a > network diagram above to illustrate that a "congruent path" may well lead > to out-of-band path. Is that the intention of the authors of the draft to > use this protocol out-of-band? > > <RG2> As replied above. > > > - The last paragraph in Section 3 refers to work on iOAM: > > The In-Situ Operations, Administration, and Maintenance (IOAM) > mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for > SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM > information such as timestamp in-band as part of the data packets, > and are outside the scope of this document. > > Is iOAM in the scope of this specification? What are the relationships > between iOAM and draft-gandhi-spring-twamp-srpm? > > <RG> As mentioned in the draft, IOAM is outside the scope. > > GIM>> Yes, but it appears that references to the two IOAM-related drafts > have some purpose. What is it? How are these drafts related > to draft-gandhi-spring-twamp-srpm? > > <RG2> We can remove them if it is confusing. It is informational text (was > added to address a review comment). > > > - Section 3.1 presents an example of the provisioning model but puts > the definition of the provisioning model outside the scope. Is there an > accompanying specification that defines the provisioning model that can be > used in multi-vendor deployment? Could that be YANG data model? What is the > relationship with draft-ietf-ippm-twamp-yang > <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13>? Would the > TWAMP YANG data model be augmented? > > <RG> Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yang > <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> and add any > missing items in a separate draft. We can also add a reference in this > draft. > > GIM>> I think that theremust be some discussion on how the new protocol is > configured. If TWAMP YANG data model can be augmented, I'd expect that > being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything > about the configuration of the protocol. > > <RG2> The Yang model extensions are not in the scope of this draft > > > - Section 4.1 states that a new message is introduced to perform the > Loss Measurement in this protocol Why the capability of TWAMP to measure > the loss in one-way and two-way is not sufficient? > > <RG> Existing TWAMP messages do not support “direct-mode” loss > measurement. We can add “direct-mode” in the text to clarify. > > GIM>> True, direct loss measurement, in fact, is not active measurement > and thus is outside the scope of Two-Way Active Measurement Protocol > (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, > passive measurement method and fetching counters can be done using numerous > methods, e.g., SNMP, Netconf > > <RG2> RFC 7799 does not say using Test-packets to collect counters for > direct-mod loss measurement is passive. > > GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic > of an active measurement method. Using out-of-band transport, e.g., SNMP > queries, would be an example of a passive measurement method. > > <RG3> Ok, so you answered your own question that the direct-mode packet > loss extension defined is “active measurement” method. > > > - Section 4.1.1 requires that > > The Destination UDP port cannot be used as Source port, since > the message does not have any indication to distinguish between the > query and response message. > > Does that imply that the Destination UDP port used for the Delay > measurement is unique throughout the particular domain? > > Gyan> Good question > > <RG2> Yes, it is unique in the domain. > > <RG> This is user-defined and is up to the user what UDP port to provision > in a domain. > > GIM>> So, can user configure a port number from the User Ports range? Or, > can the same port number be used on the same system for a number of test > sessions? I find the use of UDP port numbers being underspecified. > > > - Section 4.1.2 of RFC 5357 does not define "the delay measurement > message" but refers to the definition of the Session-Sender's test packet > in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test > packet format to perform both delay and packet loss measurement. > > <RG> Ok, we can update the text in the next revision to indicate exact > name from the RFC 4656. We can also add text to include synthetic packet > loss. > > GIM>> I think that making it explicit would help. Also, that will > highlight what is being introduced by *twamp-srpm drafts is, in fact, a new > protocol to perform synthetic packet loss measurement. > > <RG2> No, it does not change anything for synthetic packet loss. > > > - Can you explain how "the DM probe query message contains the payload > format defined in Section 4.2.1 of [RFC5357]" when the referenced section > of RFC 5357 defines the format of a Session-Reflector's test packet? > > <RG> We can update the text in the next revision to indicate query format > name from RFC 5357. > > GIM>> I cannot find any reference to a query format in RFCs 4656/5357. > Could you please quote from any of these documents? > > <RG2> It is test-packet, we will use RFC 5357 term. > > > - Can clarify the applicability of RFC 6038 and the symmetrical packet > size? Is it required? Can it be non-symmetrical? > > <RG> Yes. Please see section 4.1.1 and quoted below: > > “For symmetrical size query and response messages as defined in [RFC6038],” > > GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the > symmetrical test packets. Since *-twamp-srpm proposals do not use > TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about > that either (in part because RFC 6038 came later), I don't see that there's > any certainty in what is the sze of a test packet used in the direct-loss > measurement. > > <RG2> The test-packets as defined in these existing RFCs are used for > delay and synthetic packet loss. The direct-mode test-packets are defined > in this draft. > > GIM2>> This draft defines only a new packet format for the direct packet > loss measurement. For STAMP such a mechanism is clearly superfluous given > the Direct Measurement TLV is already defined. > > <RG3> As replied earlier. > > > - Can you clarify the use of the timestamp format, NTP or PTPv2? It is > not clear which is the default, mandatory or optional. > > <RG> This is same as TWAMP. There is no change. > > GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for > *-twamp-srpm? > > <RG2> No change in existing in what is there in RFC 5357 and RFC 8186. > > > - Also, is "hardware support in Segment Routing networks" of the PTPv2 > format required, guaranteed, or something else? > > <RG> Hardware timestamps are recommended for SR use-cases. We can change > the sentence. > > GIM>> Perhaps you can propose some text, that would be helpful. > > <RG2> Ack. > > > - 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. > > Can that be interpreted that there could be concurrent authenticated and > unauthenticated test sessions using this protocol? Would different > authentication methods require using unique destination UDP port numbers? > > <RG> Yes, and Yes, and these are based on provisioning. > > GIM>> But that requirement is far outside the TWAMP, as defined in RFC > 5357. > > <RG2> Some Session-Sender can use authenticated and some not. It is part > of RFC 5357. > > > - Section 4.1.2 by introducing the dedicated Loss measurement packet > format, effectively modifies the behavior defined in RFC 5357 for > Session-Sender and Session-Reflector. But the document does not state that. > Can you clarify whether this specification changes the behavior of a > Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 5357 > respectively for the support of packet loss measurement? > > <RG> The direct-mode loss defines new procedure for sender/reflector to > collect traffic counters, as opposed to timestamp. The rest is the same as > RFC 4656 and 5357. > > GIM>> I cannot agree with your statement " The rest is the same as RFC > 4656 and 5357" because the sender's direct-loss format does not have Error > Estimate field, Thus, a reflected packet does not have Sender's Error > Estimate, nor Error Estimate of the reflector. And that, in my opinion, is > another clear indication that *twamp-srpm drafts define a new protocol, > separate from OWAMP/TWAMP. > > <RG2> That field is specific to timestamps and would not apply to > counters for direct-mode loss measurement. > > > - And a similar question about the use of the separate UDP port number > for the authenticated of the packet loss measurement. > - A couple of question to the following text in Section 4.1.3: > > The local and remote IP > addresses of the link are used as Source and Destination Addresses. > They can also be IPv6 link local address as probe messages are pre- > routed. > > - What are the addresses of a link? > > <RG> I am assuming this well-known (e.g. RFC 2328). > > GIM>> I am not familiar with the term "pre-routed". What does it mean? > > <RG2> Ensure that packets are routed over the link. > > > - In which scenarios an IPv6 LLA can be used? > > <RG> I am assuming this is well-known (e.g. RFC 5613). > > GIM>> So, LLA may be used as the source and destination addresses when > testing an SR tunnel? > > <RG2> As mentioned this is for links. > > > - Also, could the use of a routable destination IP address be used as > a DDOS attack vector? Consider the scenario when an attacker generates > SR-encapsulated packets with the destination IP address other than any of > the SR-terminating nodes. Such a packet will be routed, correct? That does > appear as a security threat, would you agree? > > <RG> Absolutely do not agree. It is no different than IP routed TWAMP > packet as defined in [RFC5357]. > > GIM>> You don't agree that the processing described cannot happen because > of laws of physics or it wouldn't happen because no one will think of that? > If the latter, I think that that is security threat. > > <RG2> There is no new threat like you have mentioned. > > GIM2>> Hmmm, but how the integrity of TLVs proposed > in draft-gandhi-ippm-stamp-srpm can be protected? These are not protected > by HMAC as presented in figures 3 and > 5. > > > <RG3> The extensions do not change the processing of these existing TLVs > defined for HMAC. We can add text to indicate this. > > > - Section 4.1.4.2 references Figure 5 that, as I understand it, > displays the format of a probe query message. In figure two references to > RFC 5357 are provided - a section that references RFC 4656 OWAMP definition > of the Session-Sender test packet, and a section that defines the > Session-Reflector's reflected packet. Which of the two is used for the > delay measurement in the proposed protocol? > > <RG> The probe query packet in the Session-Sender text packet. We can > update the name. > > - Section 4.2.1 states that > > In one-way measurement mode, the probe response message as defined in > Figure 6 is sent back out-of-band to the sender node ... > > Could you clarify how the responder controls that the response packet is > sent not in-band but out-of-band? > > <RG> Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This is > existing behaviour for out-of-band. > > GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines > another new protocol OWAMP Light. And it is not clear what you reference as > "this is existing behavior". Is it to reference behavior of TWAMP test > packet? But the behavior of the TWAMP-Test protocol by itself is neither > in-band, nor out-of-band. It is the encapsulation of the TWAMP test packet > that makes it either in-band or out-of-band. > > <RG2> Right. > > > - 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? > > <RG> There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403. > > GIM>> So, you believe that proposing to use the > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- Re: [ippm] [spring] WG Adoption Call for https://… Greg Mirsky
- Re: [ippm] [spring] WG Adoption Call for https://… Rakesh Gandhi (rgandhi)
- Re: [ippm] [spring] WG Adoption Call for https://… Greg Mirsky
- Re: [ippm] [spring] WG Adoption Call for https://… Gyan Mishra
- Re: [ippm] [spring] WG Adoption Call for https://… Rakesh Gandhi (rgandhi)
- Re: [ippm] [spring] WG Adoption Call for https://… Greg Mirsky
- Re: [ippm] [spring] WG Adoption Call for https://… Rakesh Gandhi (rgandhi)
- Re: [ippm] [spring] WG Adoption Call for https://… Greg Mirsky
- Re: [ippm] [spring] WG Adoption Call for https://… Gyan Mishra
- Re: [ippm] [spring] WG Adoption Call for https://… Rakesh Gandhi (rgandhi)
- Re: [ippm] [spring] WG Adoption Call for https://… Gyan Mishra