Re: [ippm] Latest Updates to SR PM Drafts

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

Hi Greg,
Appreciate for taking time to review draft-gandhi-spring-twamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/> and providing comments and suggestions. Please see replies inline with <RG>…

From: Greg Mirsky <[e-mail]>
Date: Thursday, May 23, 2019 at 10:07 PM
To: "=SMTP:rgandhi@cisco. com" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [ippm] Latest Updates to SR PM Drafts

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

<RG> The draft uses the DM message formats defined for TWAMP-Test in RFC 5357 for Segment Routing. We can use the text similar to the one used in draft-ietf-ippm-stamp-05 in Section 4 if it helps clarify: “Unauthenticated STAMP test packets are compatible on the wire with unauthenticated TWAMP-Test [RFC5357<https://tools.ietf.org/html/rfc5357>] packet formats.”

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



<RG> The reference was based on the following text from draft-ietf-ippm-stamp-05 in Section 4.4, to use a dynamic destination port:  “Thus STAMP Session-Sender MUST be able to send test packets to destination UDP port number from the Dynamic and/or Private Ports range 49152-65535, test management system should find port number that both devices can use.”


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

<RG> The approach proposed is similar to draft-ietf-ippm-stamp-05 in Section 4.1.1, where user is expected to provision matching timestamp formats for a given UDP destination port on both endpoints as: “ The STAMP Session-Sender and Session-Reflector MAY use, not use, or set value of the Z field in accordance with the timestamp format in use.  This optional field is to enhance operations, but local configuration or defaults could be used in its place.”

  *   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

<RG> As defined in Section 4.1.2<https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-01#section-4.1.2> of OWAMP [RFC4656<https://tools.ietf.org/html/rfc4656>].

     *   what is the format of the authenticated (and unauthenticated as well) response message

<RG> As defined in Section 4.2.1 of TWAMP [RFC5357].

     *   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?
<RG> Yes, DM message formats are same as in [RFC5357]. The draft only has couple of lines in Section 3.1.1 anyways 😊

  *   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?
<RG> Both the querier and responder need to be provisioned to enable the LM message defined in this document and UDP destination port for it.

     *   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?
<RG> As above.

  *   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?
<RG>  The DM message format on the wire can be OWAMP/TWAMP/STAMP as long as the matching message format and UDP destination port are provisioned on both sides. We can discuss and see if the TLV belongs to this document or some other document.

  *   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.
<RG> Yes, this is direct loss measurement. Thanks for pointing to the draft. We will review the suggested draft and refer to that work as appropriate.
Much appreciate your consideration of my comments and questions. I am looking forward to our discussion on email and in Montreal.

<RG> Great, thanks,
Rakesh


Regards,
Greg

On Tue, May 21, 2019 at 3:08 PM Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[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
 <snipped to focus on the draft under discussion>

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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm