Re: [spring] [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. 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.

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

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

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

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

Regards,

On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <gregimirsky@gmail.com> 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) <
> rgandhi@cisco.com> 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 <gregimirsky@gmail.com>
>> *Date: *Friday, November 13, 2020 at 10:09 AM
>> *To: *Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
>> *Cc: *Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IPPM Chairs <
>> ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>,
>> IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
>> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm
>> and draft-gandhi-ippm-stamp-srpm
>>
>> Hi Rakesh,
>>
>> thank you for your response to my review. 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) <
>> rgandhi@cisco.com> 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 <ippm-bounces@ietf.org>
>> *Date: *Monday, November 9, 2020 at 11:48 AM
>> *To: *Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
>> *Cc: *IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <
>> spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
>> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm
>> and draft-gandhi-ippm-stamp-srpm
>>
>> Dear WG Chairs, Authors, and IPPM WG 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=
>> 40apple.com@dmarc.ietf.org> 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
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>