Subject: [spring] Latest Updates to SR PM Drafts

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 21 May 2019 22:08:25 +0000

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)

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 23 May 2019 19:07:22 -0700

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) <[email-masked]>
wrote:

> 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:
>
>    - 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:
>
>    - 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:
>
>    - None
> Thank you everyone for your review comments and suggestions on these
> drafts. Welcome your additional feedbacks.
>
>
>
> Thanks,
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 27 May 2019 17:44:25 +0000

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 <[email-masked]>
Date: Thursday, May 23, 2019 at 10:07 PM
To: "=SMTP:rgandhi@cisco. com" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi WG,

Open Items:

  *   None
 <snipped to focus on the draft under discussion>

Thanks,

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm