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

[Greg Mirsky <[e-mail]>]

 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.
      - 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.
   - 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>
      .
      - 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?
   - 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?
   - Section 3.1.4.2
      - same question as above.
   - Section 4
      - is the formula to calculate the packet loss using the direct-mode
      measurement is worth repeating in RFC?
   - 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.


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

Regards,

Greg