Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

[Greg Mirsky <[e-mail]>]

Dear Chairs of the SPRING and IPPM WGs, Authors, et al.,
I've found myself in the situation when two related drafts are in the WG
APs in the SPRING and IPPM WG (with the possibility that expertise from the
third WG, BFD WG, might be desirable to review the "liveness monitoring").
Because these drafts are closely related, I've decided to combine my
questions and comments in a single thread. I hope that would be acceptable
and considered by the SPRING WG as well as IPPM WG.
Usually, the bar for the adoption of a document can be evaluated by answers
to these three questions:

   - Is the document(s) reasonably well-written

It was a surprise finding out that both drafts don't use the terminology
from RFC 8762 STAMP and introduce their own terminology for Session-Sender
and Session-Reflector. Also, many terms, e.g., Links, "congruent paths",
are used in the documents without proper definitions. Other than that, both
drafts are readable.


   - Does the document solve a real problem?

No, it appears that the changes described in these drafts are only to
achieve in-band collection of counters of "in-profile" packets. Firstly,
drafts don't provide any arguments about why such collection should be
performed using the in-band method rather than using the out-of-band
collection approach. Secondly, even if there are any benefits of in-band
collection, that can be more easily achieved by extending other OAM, e.g.,
ICMP, tools.


   - Is the proposed solution technically viable?

There are too many unaddressed aspects, particularly the risk introduced by
the protocol on network security, to comprehensively evaluate the proposed
solution.

draft-gandhi-spring-stamp-srpm

   - Can you define a Link and how it is different from an SR Path?
   - It is not clear how the destination UDP port numbers are selected.
   Does the draft change procedure defined in Section 4.1 RFC 8762?
   - It is not clear what "the congruent path" means. The definition of the
   congruent in geometry tells that a congruent object has the same shape and
   size, but is allowed to flip, slide or turn. How a path can be congruent to
   another path?
   - An example of the provisional model is Section 3.1 seems well-suited
   for a YANG data model. What changes to the STAMP YANG data model defined in
   draft-ietf-ippm-stamp-yang
   <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/> proposed
   in these drafts?
   - In Section 4.1 noted that

   The probe messages defined in [RFC8762] are used for delay
   measurement for Links and end-to-end SR Paths including SR Policies.
   For loss measurement, the probe messages defined in [I-D.gandhi-ippm-
   stamp-srpm] are used.

It necessary to point that RFC 8762 support packet delay and packet loss
measurements in the same test session using test packets defined in the
STAMP base specification. I believe that the need yet for another method to
perform the loss measurement is not sufficiently demonstrated and does
appear as duplication of functionality already available in STAMP.


   - Could you expand on the reasoning why in Section 4.1.1.1 stated that

   A separate user-configured
   destination UDP port is used for the delay measurement in
   authentication mode due to the different probe message format.

I cannot find similar requirement in RFC 8762 and would appreciate a
technical explanation of the choice made in this specification.


   - Section 4.2.1 refers to Sender Control Code (though it is defined
   in draft-gandhi-ippm-stamp-srpm. Could you explain why it is important to
   inform the Session-Reflector that the reflected test packet be sent
   out-of-band? What if only in-band return path is available? Would the
   Session-Reflector discard test packets in such situation?
   - I got confused by the following in Section 4.2.2

   In two-way measurement mode, when using a bidirectional path, the
   probe response message as defined in Figure 6 is sent back to the
   sender node on the congruent path of the data traffic on the same
   reverse direction Link or associated reverse SR Policy
   [I-D.ietf-pce-sr-bidir-path].

If a Path Segment SID associated with the test session, there seems no need
to require the Session-Reflector look for in-band path. Would you agree?


   - How's the method described in Section 4.2.3 is different from the
   method described in RFC 8403 <https://tools.ietf.org/html/rfc8403>? What
   is distinctly unique about the loopback mode proposed in the section?  Is
   the "liveness monitoring" functionally identical to path continuity
   monitoring provided by BFD?
   - It appears that second and third paragraphs on Section 4.3.1
   contradict with the first paragraph. Need to point that RFC 8762 does not
   specify the value set in TTL/Hop Limit field, thus reference in the first
   paragraph seems misleading. I couldn't find ::FFFF:127/104 range being
   mentioned in the draft. Could you clarify when it is used?
   - Section 4.3.3 states that a zero-value UDP checksum may be used in
   some scenarios. RFC 8085 allows that but in very specific cases that are
   documented in detail in Section 3.4.1. Do you believe that the case of this
   protocol checks all the requirements for allowing the use of Zero UDP
   checksum as specified in RFC 8085? Also, I believe that allowing the use of
   Zero UDP checksum in some scenarios, this protocol introduces a security
   threat that must be thoroughly analyzed in the Security Considerations
   section.
   - Section 7, as I understand it, suggests that performance measurement
   can be combined with "liveness monitoring", i.e.path continuity monitoring.
   How fast path failure detection you expect in such combination? How it is
   comparable to the the failure detection time guaranteed using BFD?


draft-gandhi-ippm-stamp-srpm

   - Introduction states that

  The STAMP message with a TLV for "direct measurement" can be used for
   combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv].

In fact, that is not accurate. RFC 8762 which provides the base
specification of the STAMP protocol already supports packet delay and
packet loss (a.k.a. synthetic packet loss) measurement.


   - Further, the draft concludes that

   However, in order to use only for loss measurement purpose, it
   requires the node to support the delay measurement messages and
   support timestamp for these messages (which may also require clock
   synchronization).

I disagree that the the clock synchronization is required for STAMP. It is
recommended for one-way delay measurement but even without the clock
synchronization STAMP supports the round-trip delay measurement and one-way
delay variation can be calculated.


   - The conclusion on Introduction is, in my view, misleading as the
   proposed solution is not an extension of STAMP but update of RFC 8762. And
   since this is changes the foundation of RFC 8762 that specifies active
   two-way performance measurement protocol, another method for collecting
   counters and/or other telemetry information should be sought. For example,
   ICMP using multi-part message extensions, as defined in RFC 4884
   <https://tools.ietf.org/html/rfc4884>.


Regards,
Greg



On Thu, Oct 22, 2020 at 5:52 AM James Guichard <
[e-mail]> wrote:

> Dear WG:
>
>
>
> This message starts a 3 week WG adoption call for
> https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03, ending
> November 12th 2020. Please note that this document has several changes
> from v-02 that were requested by the SPRING and IPPM chairs. For this
> reason, the chairs have extended the adoption call for an additional week
> to allow the WG enough time to review these changes before deciding on WG
> adoption.
>
>
>
> Some background:
>
>
>
> Several review comments were received previously for document
> https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02. The SPRING
> and IPPM chairs considered those comments, and upon review of this version
> of the document, determined the following:
>
>
>
>    - The SPRING document should describe only the procedures relevant to
>    SPRING with pointers to non-SPRING document/s that define any extensions.
>    Several extensions including* Control Code Field Extension for STAMP
>    Messages*, *Loss Measurement Query Message Extensions*, *Loss
>    Measurement Response Message Extensions*, *Node Address TLV Extensions*,
>    and *Return Path TLV Extensions* were included in
>    https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 and
>    should be removed from the SPRING document.
>    - The STAMP extensions included in
>    https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 should
>    be described in a new document published in the IPPM WG.
>
>
>
> These conclusions were discussed with the authors of
> https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02 the result
> of which is the publication of the following two documents:
>
>
>
>    - https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. The
>    subject of this WG adoption call.
>    - https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00. This
>    document will be progressed (if determined by the WG) within the IPPM WG.
>
>
>
> After review of the SPRING document please indicate support (or not) for
> WG adoption to the mailing list. Please also provide comments/reasons for
> that support (or lack thereof) as silence will not be considered as consent.
>
>
>
> Finally, the chairs would like to thank the authors for their efforts in
> this matter.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno, & Joel
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>