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

[Greg Mirsky <[e-mail]>]

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
>
>