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

[Greg Mirsky <[e-mail]>]

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