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