Re: [spring] [ippm] Latest Updates to SR PM Drafts

[Greg Mirsky <[e-mail]>]

Hi Rakesh, and Authors,
thank you for bringing the updates to the draft for the discussion. Please
find my comments and questions below:

   - General. The draft title states that the underlying mechanism it uses
   is TWAMP. But the TWAMP, according to RFC 8545, is the union of
   TWAMP-Control and TWAMP-Test. Since the draft does not propose extensions
   to TWAMP-Control in support the new functionality, I believe it cannot be
   referred to RFC 5357 as its principal source. It might be referred to the
   Appendix I in RFC 5357 that describes the mode also referred to as
   TWAMP-Light. But because the Appendix has only Informational value,
   interoperability among the existing implementations of TWAMP Light, the one
   supporting this specification requires detailed analysis. (More on this
   issue further down.)
   - in Section 3.1 when describing the mechanism to demultiplex PM probes
   (use user-configured destination port numbers), you've noted

"This approach is similar to the one defined in STAMP protocol
[I-D.ippm-stamp]."

Can you elaborate further in what part the STAMP specification uses
user-configured
destination port numbers at the Session-Reflector to demultiplex
extensions. As I've suggested in the beginning of the discussion of this
proposal, STAMP uses TLVs to extend the functionality of its base
specification. As for the use of the destination port number at
Session-Reflector, STAMP takes advantage by using UDP port 862 [RFC8545] as
the default value. Thus STAMP Session-Reflector minimizes required
provisioning.


   - Section 3.1.1 recommends the use of PTP time stamp format following
   the procedures defined in RFC 8186. Please note, that for OWAMP, RFC 8186
   defines an extension to OWAMP-Control protocol that allows negotiating the
   timestamp format. Without the use of the OWAMP-Control, the
   Session-Receiver that does not support RFC 8186 would assume that the
   format in the received DM Probe Query message is NTP and will miscalculate
   the metrics.
   - On the use of the Authenticated mode in DM. Note that RFC 4656
   requires the support only of HMAC-SHA1. Also, what is the size of the block
   for the authentication of the message?
   - More on Authentication of DM:
      - What is the format of the authenticated query
      - what is the format of the authenticated (and unauthenticated as
      well) response message
      - what is the difference between the proposed DM query/response and
      RFC 5357 Session-Sender and Session-Reflector packets? From
reading Section
      3.2, it appears that the DM Response message format is as defined for the
      Session-Reflector in RFC 5357. Can that be expressed in one-liner without
      the unnecessary complication of introducing DM query, that is
the duplicate
      of what already defined in RFC 5357?
   - Section 3.1.2 has, what I believe, significant interoperability with
   TWAMP-Light issues:
      - The format is not backward compatible and, without the use of
      TWAMP-Control, the Session-Sender is not aware of the set of functions
      supported by the remote implementation of TWAMP-Light. The use of the
      explicitly configured UDP port number on a Session-Reflector is very
      standard on TWAMP-Light implementations in the field. How do you
propose to
      discover the set of functions that the targetted
Session-Reflector supports?
      - Another question. Assuming that the Session-Reflector that does not
      support this specification validates the LM query packet and
responds with
      the reflected packet but formatted according to RFC 5357 (and possible
      extensions like described in RFC 6038 and/or RFC 7750), How the
      Session-Sender that receives such test packet be able to validate, parse,
      and use the information?
   - I'm puzzled how the proposed in Section 3.2.2.1 the new extension to
   STAMP is related to the rest of the document that, as I read it, is based
   on OWAMP/TWAMP, but not STAMP specifications. How the new TLV, registered
   in STAMP-related registry, will be used in, for example, DM Query message,
   which is the same as OWAMP Session-Sender Test packet?
   - The LM measurement mode, please correct me if I'm mistaken, uses what
   is usually called Direct Loss Measurement. It is well-known from, for
   example, ETH-LM in G.8013/Y.1731.
   Also, draft-xiao-ippm-twamp-ext-direct-loss described the full set of
   extensions to TWAMP (TWAMP-Control and TWAMP-Test) in support of the Direct
   Loss Measurements. But I couldn't find any reference to that work that
   preceded this draft.

Much appreciate your consideration of my comments and questions. I am
looking forward to our discussion on email and in Montreal.

Regards,
Greg

On Tue, May 21, 2019 at 3:08 PM Rakesh Gandhi (rgandhi) <[e-mail]>
wrote:

> Hi WG,
>
>
>
> We have posted following updates to SR PM drafts to address various review
> comments and suggestions.
>
>
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> draft-gandhi-spring-twamp-srpm
> <https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/>
>
>
>
> This draft defines SR PM using TWAMP RFC 5357, as well as new message for
> direct-mode loss measurement. The latest version of the draft has been
> updated with:
>
>    1. Mach Chen joined as a co-author.
>    2. Remove term In-band probes and add as “probes sent on congruent
>    path with data traffic” in Section 2.2.
>    3. Add packet counter format flags in LM message in Section 3.
>    4. Add Checksum complement in Section 3.
>    5. Define Return Path TLV for two-way measurement mode in Section
>    3.2.2.1.
>    6. Add Loopback measurement mode in Section 3.2.3.
>    7. Add Path Segment ID in Figure 3.
>    8. Add details for P2MP SR Policy in Section 4.
>    9. Include OWAMP and TWAMP use HMAC-SHA1 for integrity protection in
>    Section 7.
>    10. Cleanup/editorial changes.
>
>
>
> Open Items:
>
>    - None
>
>
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> draft-gandhi-spring-rfc6374-srpm-udp
> <https://datatracker.ietf.org/doc/draft-gandhi-spring-rfc6374-srpm-udp/>
>
>
>
> This draft defines SR PM using IP/UDP encap for RFC 6374. The latest
> version of the draft has been updated with:
>
> 1.      Remove term In-band probes and add as “probes sent on congruent
> path with data traffic” in Section 2.2.
>
> 2.      Add loopback measurement mode in Section 3.2.3.
>
> 3.      Add Checksum complement in Section 3.3.
>
> 4.      Add Path Segment ID in Figure 3.
>
> 5.      Add details for P2MP SR Policy in Section 4.
>
> 6.      Cleanup/editorial changes.
>
>
>
> Open Items:
>
>    - None
>
>
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> draft-gandhi-spring-rfc6374-srpm-mpls
> <https://datatracker.ietf.org/doc/draft-gandhi-spring-rfc6374-srpm-mpls/>
>
>
>
> This informational draft reviews SR PM for MPLS data plane using RFC 6374.
> The latest version of the draft has been updated with:
>
>    1. Remove term In-band probes and add as “probes sent on congruent
>    path with data traffic” in Section 2.2.
>    2. Add Return Path TLV for two-way measurement mode in Section 3.3.2.1.
>    3. Add loopback measurement mode in Section 3.3.3.
>    4. Add Path Segment ID in Figure 4.
>    5. Add block number TLV in Section 5.1.1.
>    6. Add details for P2MP SR Policy in Section 6.
>    7. Add details for ECMP in Section 7.
>    8. Cleanup/editorial changes.
>
>
>
> Open Items:
>
>    - None
>
>
>
>
>
> Thank you everyone for your review comments and suggestions on these
> drafts. Welcome your additional feedbacks.
>
>
>
> Thanks,
>
> Rakesh (on behalf of co-authors and contributors)
>
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>