Re: [spring] Comments on draft-gandhi-spring-twamp-srpm

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Greg,

Many thanks for the pointers of the relevant work. We are happy to collaborate with you on SR PM.

Thanks,
Rakesh


From: Greg Mirsky <[e-mail]>
Date: Tuesday, March 5, 2019 at 10:24 PM
To: "=SMTP:rgandhi@cisco. com" <[e-mail]>
Cc: spring <[e-mail]>, IETF IPPM WG <[e-mail]>
Subject: Re: Comments on draft-gandhi-spring-twamp-srpm

Hi Rakesh,
the common understanding of the TWAMP and TWAMP Light by IPPM WG is reflected in draft-ietf-ippm-port-twamp-test<https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/> (soon to be published as RFC 8545). The work on STAMP is progressing and the base specification, draft-ietf-ippm-stamp<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/>, is in WG LC through March 15. Much appreciate your review and comments. Also, much interested in your comments on draft-mirsky-ippm-stamp-option-tlv<https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/>. I believe that there's a good reason for us to work together on STAMP extensions that address specific SR scenarios.

Regards,
Greg

On Sun, Mar 3, 2019 at 6:17 AM Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>> wrote:
Thank you Greg for the thorough review of the document and your comments.

Please see in line with <RG>…

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 28, 2019 at 7:05 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, spring <[e-mail]<mailto:[e-mail]>>, IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Subject: Comments on draft-gandhi-spring-twamp-srpm
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: "=SMTP:rgandhi@cisco. com" <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Thursday, February 28, 2019 at 7:05 PM

Dear Authors,
I've read the draft and would share my comments with SPRING and IPPM WGs:

  *   Section 3.1.1

     *   what is introduced in this section? Note, that in OWAMP 'O' stands for 'one-way', i.e., the receiver collects the measurement results. RFC 4656 defines Client Fetch command to retrieve, possibly by the Session-Sender, the measurement results.
<RG> Idea is that the user provisions the UDP port and the attributes (e.g. timestamp format, authentication mode/type, etc. associated with the UDP port) on both endpoints of SR paths. These configurations are used to interpret *WAMP(Light) payloads to provide delay and loss measurements. The motivation is to eliminate the control-channel signaling - the spirit of SR.

     *   note that RFCs 4656 and 5357 defined the use only of NTP format for timestamps. The use of PTP format was introduced by RFC 8186 for TWAMP only as optional, not as the default mode. The default format for TWAMP-Test is still NTP format. You may consider using the mechanism defined for TWAMP-Control to change the default to PTP format.
<RG> As mentioned above, the motivation of this work is to move away from the control-channel signaling to boot-strap PM sessions. So, we are not extending the control-channel signaling.

  *   Section 3.1.2

     *   a new format for Session-Sender's TWAMP-Test message introduced. Note, that the format for Session-Sender TWAMP-Test message is the same as defined in RFC 4656. If you want to define a new TWAMP-Test optional format it first must be negotiated through TWAMP-Control protocol as has been done for all TWAMP extensions.
     *   how the format you've proposed is different from the one proposed earlier in draft-xiao-ippm-twamp-ext-direct-loss<https://tools.ietf.org/html/draft-xiao-ippm-twamp-ext-direct-loss-01>.
     *   Your intention, if I understand correctly, is to support direct-mode loss measurement. draft-xiao-ippm-twamp-ext-direct-loss proposed that earlier and with proper TWAMP-Control extension. After the IPPM WG agreed to work on STAMP, authors of draft-xiao-ippm-twamp-ext-direct-loss and STAMP agreed to work together and now the direct-mode loss measurement is part of draft-mirsky-ippm-stamp-option-tlv<https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/?include_text=1>.
<RG> Your understanding is correct. Thank you for the background and pointing to the LM TLV. We can analyze to see if we can leverage the TLV. Again, we are not extending the control-channel signaling.

     *   the last bullet in the section refers to PSID but I couldn't find a PSID field in any of the displayed formats, authenticated or not. Is it for further versions?
<RG> Ok, we will add the definition/detail in the next revision.

  *   Section 3.1.4.1

     *   what is illustrated in this sub-section? That TWAMP-Test message with IP/UDP encapsulation can be carried over SR-MPLS tunnel?
<RG> It shows how the measurement packet is carried over SR-MPLS Policy.

  *   Section 3.1.4.2

     *   same question as above.
<RG> It shows how the measurement packet is carried over SRv6 Policy and what END function is used for timestamp and punting the packet.

  *   Section 4

     *   is the formula to calculate the packet loss using the direct-mode measurement is worth repeating in RFC?
<RG> It is good to have it at the early stage of the document. We can remove it later in the process.

  *   Section 5

     *   without the discussion of the impact on the Session-Sender that reflected test packets may have, I cannot agree with the assumption:
   The procedures for delay and loss measurement described in this
   document for Point-to-Point (P2P) SR-MPLS Policies are also equally
   applicable to the Point-to-Multipoint (P2MP) SR Policies.

<RG> Yes, we can elaborate it in the next revision. Idea it that the querier uses the source address of the responders (i.e. leafs) to identify the measurements to each leaf.

  *   Section 7

     *   OWAMP and TWAMP use HMAC-SHA1 for integrity protection. If your intent is to use HMAC-SHA-256 in the authenticated mode for OWAMP and/or TWAMP, then it may be supported as an optional extension with the proper extension in their respective control protocols. Should note that the use of HMAC-SHA-256 for STAMP was discussed at IPPM WG meeting in Bangkok and now is documented in the latest version of STAMP.
<RG> Thanks for sharing this information. We will update the draft accordingly. This is also a property of the UDP port configured and both methods can be used. As mentioned earlier, we are moving away from using the control-channel signaling.
Many thanks for the detailed review and feedbacks.
Rakesh

Regards,
Greg