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

[Greg Mirsky <[e-mail]>]

Hi Tianran,
thank you for sharing your perspective on the *-SRPM drafts and the
discussion, it is very refreshing and thought-provoking. I believe that
you've hit the nail on the head by pointing to what is missing from the
discussion - the agreed by the WGs set of the requirements. I absolutely
agree with you, without a clear understanding of the requirements documents
appear as a solution that is looking for a problem to be solved. Instead of
discussing issues with the proposed new protocol, it may be helpful to take
a step back and discuss requirements. For example, how to evaluate the
efficiency of different methods of direct packet loss measurement. Or, as
you've pointed out, compare the pros and cons of configuring metadata for
the duration of a test session vs. carrying metadata in each test packet.
And, as was noted by other reviewers of the drafts, the requirements are
likely to be applicable not only to a Segment Routing but to a network in
general.

Regards,
Greg

On Wed, Nov 18, 2020 at 9:33 PM Tianran Zhou <[e-mail]> wrote:

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