Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

[Greg Mirsky <[e-mail]>]

Hi Mach,
thank you for your email. I've added my understanding of what has been
proposed in-line tagged GIM>>.

Regards,
Greg

On Wed, Nov 18, 2020 at 11:41 PM Mach Chen <[e-mail]> wrote:

> Hi Tianran, Rakesh and Greg,
>
>
>
> Please see some responses inline with [Mach]…
>
>
>
> *From:* ippm [mailto:[e-mail]] *On Behalf Of *Tianran Zhou
> *Sent:* Thursday, November 19, 2020 1:33 PM
> *To:* Rakesh Gandhi (rgandhi) <rgandhi=[e-mail]>; Greg
> Mirsky <[e-mail]>
> *Cc:* spring <[e-mail]>; IPPM Chairs <[e-mail]>;
> [e-mail]; Tommy Pauly <tpauly=[e-mail]>;
> IETF IPPM WG ([e-mail]) <[e-mail]>
> *Subject:* Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and
> draft-gandhi-ippm-stamp-srpm
>
>
>
> Hi Rakesh and Greg,
>
>
>
> I may not very clear about the context. Please allow me to jump in.
>
> It seems both of you make some valid point.
>
> Please see in line with <ZTR>.
>
>
>
> Cheers,
>
> Tianran
>
>
>
> *From:* spring [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Rakesh Gandhi (rgandhi)
> *Sent:* Wednesday, November 18, 2020 7:41 AM
> *To:* Greg Mirsky <[e-mail]>
> *Cc:* spring <[e-mail]>; IPPM Chairs <[e-mail]>;
> [e-mail]; Tommy Pauly <tpauly=[e-mail]>;
> IETF IPPM WG ([e-mail]) <[e-mail]>
> *Subject:* Re: [spring] [ippm] Call for adoption:
> draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
>
>
>
> Hi Greg,
>
>
>
> Thank you for your review and discussions on the drafts. This will help
> improve the work on this important work.
>
> Please see replies inline with <RG>..
>
>
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Tuesday, November 17, 2020 at 5:27 PM
> *To: *Rakesh Gandhi (rgandhi) <[e-mail]>
> *Cc: *Tommy Pauly <tpauly=[e-mail]>, IPPM Chairs <
> [e-mail]>, [e-mail] <[e-mail]>,
> IETF IPPM WG ([e-mail]) <[e-mail]>, spring <[e-mail]>
> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and
> draft-gandhi-ippm-stamp-srpm
>
> Hi Rakesh, WG Chairs, and All,
>
> I've read the responses to my detailed comments. I don't think that only
> adding references will solve the problems with the documents. If authors
> are interested in addressing my comments, we can start working on
> solving them one by one.
>
>
>
> <RG> As mentioned in previous replies, we can add references for the
> well-known terms “Links”, “Congruent Paths”, “SR Path”. If you prefer, we
> can define them here. For Zero checksum field, we can add a reference for
> the RFC 6936 in Security section and also add some text for it. Will be
> happy to work with you to address these.
>
>
>
> But I am very much concerned with the technical value of these drafts. And
> here's why I feel that the proposed documents don't provide a sound
> technical solution to the task of direct loss measurement. Please find my
> reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:
>
>    - What is being proposed in these drafts?
>
> Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support
> direct packet loss measurements. Note, that RFC 6374 includes a method for
> direct loss measurement in MPLS networks that is applicable to the SR-MPLS
> environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to
> RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct packet
> loss measurement. STAMP and all its extensions are applicable in IPv6
> networks and, thus, can be used in the SRv6 domain.
>
>
>
> <RG> As mentioned in previous replies, both RFC 6374 (in Section 4.2) and
> ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX
> and RX counters for direct-mode loss measurement. TWAMP/STAMP messages
> defined in the drafts are equivalent of them that take advantage of the
> widely deployed TWAMP protocol and as well this same protocol can be
> deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.
>
>
>
> <ZTR> I think RFC6374 for MPLS and Y.1731 make some noise here. The point
> is if we need a new direct packet loss measurement for STAMP, when STAMP
> already defined a Direct Measurement TLV (
> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If
> current Direct Measurement TLV cannot fulfill some use case requirement,
> then how about proposing a new TLV.
>
>
>
> [Mach] Given that TWAMP does not support TLV, I assume that the
> discussions are mainly about draft*-stamp-srpm.
>
GIM>> You've brought a very good question on how the return path, in case
required by the Sender Control Code, introduced
in draft-gandhi-ippm-twamp-srpm, is specified? As you've pointed out, RFC
5357 does not use TLV extensions. Should I assume that the return path, if
required, provisioned through the management plane? I think that that
requires clarification.

>
>
> [Mach] In the case of direct packet loss measurement,
> draft-gandhi-ippm-stamp-srpm assumes that marking-based solution (which can
> address the packet out-ordering issue) is used, hence the block number is
> introduced. The block number is used to correlate the counters from the
> sender and reflector. The current direct loss measurement TLV may just
> apply to the scenario without packet out-ordering.
>
GIM>> I agree with your observation on the purpose of the Block Number
field in both TWAMP-Light and STAMP documents. In my understanding, the new
protocol may be also used to collect counters generated by methods other
than Alternate Marking. In that case, I assume, the value of Block Number
may not convey any information.

>
>
> [Mach] In addition, whether to keep it as current design or to define a
> new TLV for direct loss measurement can be debatable.
>
GIM>> I agree with you. And that what I am proposing - review the
requirements, agree on requirements, and review the proposed solution based
on these requirements.

>
>
> How the proposed method of direct packet loss is related to TWAMP light
> and STAMP?
>
> There's no apparent technical relationship between *-twamp-srpm and TWAMP
> Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the
> basic mechanisms defined for  TWAMP-Test and/or STAMP in their respective
> specifications. Rather than that, drafts introduce a new query-response
> mode and new formats of test packets that are decisively different from the
> formats defined in respective specifications. As a result, the new
> protocols are required to use different from used by TWAMP Light tr STAMP
> test session UDP port numbers on the responder. And that is another clear
> indication that the proposed mechanism represents a new protocol, neither
> extends TWAMP Light and/or STAMP nor updates their specifications.
>
>
>
> <RG> As mentioned in previous replies, other than timestamp vs. counter
> and it’s format, the messages and processing of them are the same for delay
> and direct-mode loss measurement.
>
>    - Is there any advantage in introducing a dedicated packet format for
>    the direct packet loss in STAMP comparing to using the Direct Measurement
>    TLV extension?
>
> Though it appears the using a dedicated packet format instead of TLV is
> more efficient, but the dedicated for the direct loss measurement format is
> likely to precede one or even two TLVs, Node Address TLV and Path TLV,
> defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new
> packet with TLVs is unlikely to be more efficient and reduce the processing
> delay, than if using the Direct Measurement TLV as defined in
> draft-ietf-ippm-stamp-option-tlv.
>
>
>
> <RG> As mentioned in previous replies, this is explained in Section 1 of
> the draft-gandhi-spring-stamp-srpm
> <https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/>. For
> link loss measurement (direct-mode), there is no TLV required for example.
> For direct-mode loss measurement in SR networks, it would *typically* be
> forward direction packet loss measurement (and not bidirectional).
>
>
>
>
>
> ·         What are the potential benefits of specifying the return path
> in the new test packet's Sender Control Code?
>
> Using the Sender Control Code may require the use of the additional TLV
> that carries the return path information, Path TLV. If the ability to
> control the return path is required that can be achieved by augmenting the
> STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including
> the Path TLV in each test packet. Hence, there seem no technical
> requirements to introduce the Sender Control Code field in the Base STAMP
> format defined in RFC 8762.
>
>
>
> <RG> Per session basis between different sender nodes and this reflector
> node, some senders will request the replies in-band (e.g. for two-way
> mode). Sessions are provisioned on the Sender nodes and reflector simply
> reflects based on the received test-packet (e.g. for a bidirectional SR
> path). This is also similar to as described Section 3.1 in RFC 6374, top of
> page 22. There is no need to create a such state for each session on the
> reflector node and create a scale limitation. Recall that we are trying to
> avoid the scale limitation by eliminating the Control protocol signaling.
>
>
>
> <ZTR> I find some value to include the path TLV in wire. As Rakesh
> mentioned, this can reduce the reflector configuration. But I am not
> convinced to introduce the sender control code field. It seems to me, the
> presence of path TLV indicates the bidirectional congruent path. Vise
> versa.
>
>
>
> [Mach] Regarding how to specify the return path, the draft defines two
> ways to achieve that, one is to use control code to direct whether the
> reflected Test should be along the reverse path of a bidirectional path,
> this applies to both TWAMP (no TLV mechanisms) and STAMP. At the same time,
> in the case of STAMP, it also defines the return path TLV to explicitly
> specify the return path, which bring more options to specify the return
> path. Therefore, I see benefit of the two ways.
>
GIM>> I think you've pointed to some vagueness in the definition of a
mechanism used to define the return path. My understanding is that if a
response required, the Return Path TLV must be present in a test packet.
But, if TLVs are not used for TWAMP-like direct loss measurement, why not
use the same method to control the return path? I believe that consistency
is a good quality of a protocol (yes, I see *-twamp-srpm and *-stmp-srpm as
a single protocol only presented as different entities).

>
>
>
>
> Best regards,
>
> Mach
>
>
>
> What is the relationship between the *-srpm drafts and BFD?
>
> Some text in the *-srpm drafts suggest that the proposed method can be
> used to monitor for the loss of a path continuity. That may be viewed as an
> alternative to the BFD protocol method for the detection of a network
> failure. If the discussion of Loopback mode and monitoring of liveness
> remain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs
> be made aware of the proposals. I didn't take the liberty of adding BFD WG
> or its Chairs. I believe that decision to be made by the Chairs of IPPM And
> SPRING WGs.
>
>
>
> <RG> As mentioned in previous replies, STAMP/TWAMP test messages are also
> used today for *synthetic* packet loss measurement which can be also used
> to detect/monitor connection loss (performance metric). The draft simply
> highlights this obvious metric. This is also very similar to what is
> described in ITU Y.1731, Section 7.1.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
> Regards,
>
>
>
>
>
> On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <[e-mail]>
> wrote:
>
> Hi Rakesh,
>
> thank you for your prompt response, much appreciated. I'll carefully read
> your responses. Looking forward to the continued discussion.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) <
> [e-mail]> wrote:
>
> Hi Greg,
>
>
>
> Thank you for your review comments. As mentioned in the IPPM session
> today, the email response was sent as attachments, see archive blow:
>
> https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/
>
>
>
> I am attaching them in word documents for the convenience. We can address
> your comments below in the next revision of the document.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Friday, November 13, 2020 at 10:09 AM
> *To: *Rakesh Gandhi (rgandhi) <[e-mail]>
> *Cc: *Tommy Pauly <tpauly=[e-mail]>, IPPM Chairs <
> [e-mail]>, [e-mail] <[e-mail]>,
> IETF IPPM WG ([e-mail]) <[e-mail]>
> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and
> draft-gandhi-ippm-stamp-srpm
>
> Hi Rakesh,
>
> thank you for your response to my review. Please find my follow-up notes
> in-lined below under the GIM>> tag.
>
> I hope you've found more detailed comments in the attachments (re-attached
> for your convenience). I'm looking forward to reading your responses to the
> detailed comments of all four drafts.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <[e-mail]>
> wrote:
>
> Thank you Greg for taking time for thoroughly reviewing the documents and
> providing the comments.  Attached please find the email replies to your
> review sent earlier.  The replies are copied inline below for convenience,
> tagged with <RG00>.
>
>
>
>
>
> *From: *ippm <[e-mail]>
> *Date: *Monday, November 9, 2020 at 11:48 AM
> *To: *Tommy Pauly <tpauly=[e-mail]>
> *Cc: *IPPM Chairs <[e-mail]>, [e-mail] <
> [e-mail]>, IETF IPPM WG ([e-mail]) <[e-mail]>
> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and
> draft-gandhi-ippm-stamp-srpm
>
> Dear WG Chairs, Authors, and IPPM WG community,
>
> I've reviewed these drafts and have some comments to share. Below, please
> find my thoughts on whether these drafts can be adopted. More specific
> comments on each pair of drafts (TWAMP-related and STAMP-related draft and
> its accompanying draft targetted to the SPRING WG) are in the attached
> documents.
>
>
>
> Usually, the bar for the adoption of a document can be evaluated by
> answers to these three questions:
>
> ·  Is the document(s) reasonably well-written
>
> I've got surprised that the drafts don't use the terminology from RFCs
> 4656/5357 and RFC 8762, and introduce their own terminology for
> Session-Sender and Session-Reflector. Also, many terms, e.g., Links,
> "congruent paths", are used in the documents without proper definitions.
> Other than that both drafts are readable and reasonably well-written.
>
>
>
> <RG00> We can change Sender to Session-Sender and Reflector to
> Session-Reflector if it helps.
>
> GIM>> I believe that the consistency in terminology between the core RFC
> and what is intended as its extension is not only helpful to a reader but,
> to the best of my understanding, is required for IETF specifications.
>
> <RG00> There are many existing RFCs that use term Link (e.g. RFC 5613,
> 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without
> defining them. I suspect it is because these are well-known terms. Having
> said that, we can add a reference for them if it helps.
>
> GIM>> Thank you for listing these RFCs. I think I need to clarify my
> questions. While a reference to any of RFCs you've mentioned, I don't think
> that will address my concern. In reviewed documents, "Link" is capitalized
> while referenced RFCs used the lower case form for the term "link". Can
> these be used interchangeably? Do they refer to the same network object?
>
> Now I'll try to illustrate my concern with using the term "congruent path"
> in these drafts (using ASCII-art):
>
>                        C---------D
>
>                      /                 \
>
>             A----B                   E-----F
>
>                      \                  /
>
>                      G------------H
>
> Consider an SR tunnel from A to F that traverses the network as
> A-B-C-D-E-F. From the definition of "congruent" as "two figures or objects
> are congruent if they have the same shape and size, or if one has the same
> shape and size as the mirror image of the other", path A-B-G-H-E-F is
> congruent to the SR tunnel. But a packet of an active OAM intended to
> monitor a flow over the SR tunnel is out-of-band and will not produce any
> meaningful measurement. Of course, for the case of the extensions in
> drafts, direct loss measurement can be performed, as information collected
> from node F. So, this example, in my opinion, illustrates two of my
> concerns:
>
>    - using a congruent path for an active OAM protocol may produce
>    information that does not reflect the condition experienced by the
>    monitored flow. It seems that the terminology should reflect the
>    fundamental requirement for using active OAM to maintain the test packets
>    in-band with the monitored flow.
>    - there are no technical requirements to justify using in-band active
>    OAM protocol for direct packet loss measurement. As demonstrated in this
>    example, direct packet loss can be performed using an out-of-band
>    mechanism, e.g., SNMP queries, Netconf notifications based on YANG data
>    model.
>
>
>
> ·  Does the document solve a real problem?
>
> No, it appears that  both TWAMP and STAMP drafts  define a new
> performance measurement protocol for the purpose of combining OWAMP/TWAMP
> and STAMP functionality in the respective drafts, and adding the ability to
> collect counters of "in-profile" packets. I couldn't find sufficient
> technical arguments for using a PM protocol instead of, for example,
> extending the existing OAM mechanisms like ICMP multi-part message
> extension per RFC 4884.
>
>
>
> <RG00> There is a requirement to measure performance delay as well as
> synthetic and direct-mode packet loss in segment-routing networks. OWAMP
> and TWAMP protocols are widely deployed for performance delay and synthetic
> packet loss measurement today. I am not sure extending ICMP for LM is a
> good option here.
>
> GIM>> I agree with the requirements you've listed (though the SPRING WG
> OAM requirements document
> <https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03> has
> been abandoned and expired 3+ years ago). I believe that there's no
> sufficient technical reason to use OWAMP/TWAMP/STAMP for exclusive direct
> packet loss measurement.
>
>
>
> ·  Is the proposed solution technically viable?
>
> There are too many unaddressed aspects, particularly the risk introduced
> by the protocols on network security, to comprehensively evaluate the
> proposed solutions.
>
>
>
> <RG00> About your comment on zero checksum, this is described in Security
> section in RFC 6936. We will add reference to this RFC in our Security
> Section as well. This is only specific to the UDP port locally provisioned
> in the domain by the operator for STAMP or TWAMP Light. Other than this, I
> did not find any other security related issue in your review.
>
> GIM>> I don't think that a mere reference sufficiently explains why the
> use of zero UDP checksum in IPv6 header is not decremental, does not create
> a security risk for the protocol.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
>
>
>
>
> On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly=
> [e-mail]> wrote:
>
> Hello IPPM,
>
>
>
> For the past few meetings, we’ve had updates on the work in the SPRING WG
> that was using STAMP and TWAMP. Since those documents ended up making
> extensions to the base protocols, the chairs of SPRING and IPPM decided
> that it would be best to split the documents and track the IPPM extension
> work in the IPPM WG.
>
>
>
> As such, we are starting a Working Group call for adoption
> for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.
>
>
>
> The documents are here:
>
> https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00
>
> https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00
>
>
> The related SPRING documents are here:
>
> https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03
>
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
>
>
>
> Please provide your feedback on these documents, and state whether or not
> you believe the IPPM WG should adopt this work by replying to this email.
> Please provide your feedback by the start of the IETF 109 meeting week, on *Monday,
> November 16*.
>
>
>
> Best,
>
> Tommy & Ian
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>
>