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

[Greg Mirsky <[e-mail]>]

Hi Rakesh,
thank you for the response to my comments. Please find my follow-up notes
in-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Nov 10, 2020 at 8:01 AM Rakesh Gandhi (rgandhi) <[e-mail]>
wrote:

> Thank you Greg for taking time for thoroughly reviewing the documents and
> providing the comments. Note that many of the comments here on STAMP draft
> are repeated from the previous comments on the TWAMP Light draft. Please
> see replies inline with <RG>. The repeated comments are tagged with <RG00>
> to avoid duplicated discussions.
>
>
>
> *From: *ippm <[e-mail]>
> *Date: *Friday, November 6, 2020 at 11:18 AM
> *To: *James Guichard <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> IETF IPPM WG <[e-mail]>
> *Subject: *Re: [ippm] [spring] WG Adoption Call for
> https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03
>
> 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.
>
>
>
> <RG00> We can change Sender to Session-Sender and Reflector to
> Session-Reflector if it helps.
>
GIM>> I believe that the consistency in terminology between the core RFC
8762 and what is intended as its extension is not only helpful to a reader
but, to the best of my understanding, is required for IETF specifications.
But I don't think that switching the terminology will fix the fundamental
issue with *stamp-srpm drafts. The operation that is required from the
remote entity, whether it is referred to as responder or Session-Reflector,
is not defined in RFC 8762, nor even in draft-ietf-ippm-stamp-option-tlv.
In my opinion, the behavior required, as described in the *stamp-srpm
drafts, cannot be characterized as an extension of STAMP but presents a
completely new protocol that, if there's a need in the new PM OAM protocol,
must be properly defined.

> <RG00> There are many existing RFCs that use term Link (e.g. RFC 5613,
> 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without
> defining them. I suspect it is because these are well-known terms. Having
> said that, we can add a reference for them if it helps.
>
GIM>> Thank you for the references to these RFCs. I think I need to clarify
my questions. I don't think that a reference to any RFC will address my
concern. In reviewed documents, "Link" is capitalized while referenced RFCs
used the lower case form for the term "link". Can these be used
interchangeably? Do they refer to the same network object?
Now I'll try to illustrate my concern with using the term "congruent path"
in these drafts (using ASCII-art):
                       C---------D
                     /                 \
            A----B                   E-----F
                     \                  /
                     G------------H
Consider an SR domain that includes all the nodes shown in the network
diagram. An SR tunnel from A to F that traverses the network as
A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of
"congruent" as "two figures or objects are congruent if they have the same
shape and size, or if one has the same shape and size as the mirror image
of the other", it looks as the path A-B-G-H-E-F is congruent to that SR
tunnel. But a packet of an active OAM intended to monitor a flow over the
SR tunnel is out-of-band relative to that flow and will not produce any
meaningful measurement. Of course, for the case of the extensions in drafts
*-twamp-srpm, direct loss measurement can be performed, as information
collected from node F and packets that collect the counters are not
required to be in-band with the monitored flow. So, this example, in my
opinion, illustrates two of my concerns:

   - using a congruent path for active performance measurement, e.g., TWAMP
   or TWAMP Light, may produce information that does not reflect the condition
   experienced by the monitored flow. It seems that the terminology should
   reflect the fundamental requirement of ensuring that active OAM test
   packets are in-band with the monitored flow.
   - there are no technical requirements to justify using in-band test
   packets for direct packet loss measurement. In fact, using the in-band
   method for collecting in-profile counters leads to a waste of bandwidth,
   which may have a negative impact on services that require low-latency
   and/or low packet loss. As demonstrated in this example, direct packet loss
   can be performed using an out-of-band mechanism, e.g., SNMP queries,
   Netconf notifications based on YANG data model.



>
>    - 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.
>
>
>
> <RG00> There is a requirement to measure performance delay as well as
> synthetic and direct-mode packet loss in segment-routing networks. OWAMP
> and TWAMP protocols are widely deployed for performance delay and synthetic
> packet loss measurement today. I am not sure extending ICMP for LM is a
> good option here.
>
 GIM>> While I agree with the generic requirements you've listed I'm a bit
confused about how the deployment of OWAMP and TWAMP protocols can be
related to the proposed in *-stamp-srpm extensions. STAMP, similar to OWAMP
and TWAMP, is the active measurement protocol, per the definition of RFC
7799. The direct loss measurement method is clearly a passive method and,
in my opinion, it is decremental to the network to use in-band active
method collecting in-profile counters when there is no technical
requirement to use such an intrusive method.

>
>

>    - 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.
>
> <RG00> About your comment on zero checksum, this is described in Security
> section in RFC 6936. We will add reference to this RFC in our Security
> Section as well. This is only specific to the UDP port locally provisioned
> in the domain by the operator for STAMP. Other than this, I did not find
> any other security related issue in your review below.
>
 GIM>> I don't think that a mere reference sufficiently explains why the
use of zero UDP checksum in IPv6 header is not decremental, does not create
a security risk for the protocol.


> draft-gandhi-spring-stamp-srpm
>
>    - Can you define a Link and how it is different from an SR Path?
>
> <RG00> There are many existing RFCs that use term “Link” (e.g. RFC 5613,
> 5340, 8330, etc.). Similarly term “SR Path” has been used in existing RFCs
> (e.g. 8664). I suspect these are well-known terms.
>
GIM>> I believe that every well-known term has been defined somewhere.
Since the document differentiates between the two, I hope that it would not
be too difficult to explain or illustrate what is the difference.

>
>    - It is not clear how the destination UDP port numbers are selected.
>    Does the draft change procedure defined in Section 4.1 RFC 8762?
>
> <RG> There is no change.
>
GIM>> Thank you for clarifying that. I'd note that the current text is not
clear about that.

>
>    - 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?
>
> <RG00> There are many existing RFCs that use term “Congruent Path” (e.g.
> RFC 5921, 6669) without defining them. I suspect it is because it is
> well-known term. Having said that, we can add a reference for it if it
> helps reader.
>
GIM>> I've clarified my question about the term "congruent path" above. I
hope that the diagram makes it clearer.

>
>    - 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?
>
> <RG00> Yes, this can be Yang model. We can review
> draft-ietf-ippm-stamp-yang
> <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>and add any
> missing items in a separate draft. We can also add a reference in this
> draft.
>
GIM>> Management of a protocol, configuration is an integral part of the
protocol specification. I've expected that *-stamp-srpm drafts include more
substantial text about the management than "out of the scope". In my
opinion, a section on the management is required and if the authors decide
to augment STAMP Yang data model, it should include the new YANG module.

>
>    - 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.
>
>
>
> <RG> This is explained in the third paragraph of Section 1.
>
GIM>> I cannot find any technical explanation for the introduction of the
new PM protocol to collect in-profile counters and not use the Direct
Measurement TLV defined in draft-ietf-ippm-stamp-option-tlv
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>
(already cleared IESG review). Could you help me by pointing to the
explanatory test in the paragraph you're referring to:
   This document specifies procedures for sending and processing probe
   query and response messages for Performance Measurement in SR
   networks.  The procedure uses the mechanisms defined in [RFC8762]
   (STAMP) and its TLV extensions [I-D.ietf-ippm-stamp-option-tlv] for
   Performance Measurement.  The procedure specified is applicable to
   SR-MPLS and SRv6 data planes and is used for both Links and end-to-
   end SR Paths including SR Policies and Flex-Algo IGP Paths.  Unless
   otherwise specified, the mechanisms defined in [RFC8762] and
   [I-D.ietf-ippm-stamp-option-tlv] are not modified by this document.

>
>    - 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.
>
>
>
> <RG> Does RFC 8762 support simultaneous sessions for authenticated and
> non-authenticated modes? If yes, can you please point to the procedure in
> the RFC 8762 and we can simply refer to it? I am not sure  how both packet
> formats be distinguished by a reflector node when using the same UDP port.
>
GIM>> Whether STAMP test session is in authenticated or unauthenticated
mode is the matter of configuration (as it is for TWAMP). You can
check the STAMP
YANG data model draft
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/> and TWAMP
YANG data model
<https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/> (the latter
could be useful for *-twamp-srpm drafts).
As for distinguished of two concurrent sessions between a pair of nodes, in
STAMP one can take advantage of the STAMP Session Identifier (SSID) that is
defined in Section 3 of draft-ietf-ippm-stamp-option-tlv. If there is only
one session, then, in my view, the configuration of the STAMP session's
mode should suffice. Would you agree?

>
>    - 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?
>
> <RG00> Out-of-band is the current behaviour and there is no change in the
> existing behaviour. We can clarify in the next revision.
>
GIM>> I'm confused. An active measurement protocol cannot be out-of-band,
otherwise, the measured metrics are meaningless. Thus, an implementation of
STAMP must ensure that the test packet is in-band with the monitored flow.
So, when you're saying "there is no change in the existing behavior" are
you referring to the behavior of STAMP or to something else? If your
intention to use the new protocol out-of-band, that clearly will be a
change of STAMP behavior.

>
>    - 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?
>
>
>
> <RG> No. Existence of Path Segment ID does not mean in-band reply. It may
> be needed for RX counter for direct-mode loss measurement.
>
GIM>> Can you please clarify the use case for using the Path Segment SID in
the test packet? The text, as quoted, gives the impression that it is
needed for "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 cannot find any
text that explains how the Segment Path SID in the test packet may be used
by "RX counter for direct-mode loss measurement".

>
>    - 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?
>
> <RG00> There is no mention of Loopback mode or STAMP / TWAMP / RFC 5357 /
> RFC 8762 in RFC 8403.
>
GIM>> Yes, RFC 8403 doesn't mention these RFCs, nor refers to RFC 8762. In
my opinion, it was demonstrated in RFC 8403 how SR, SR-MPLS in the case
discussed, can be used to circle the test packet through the SR domain. By
using that method, an operator may not only detect the failure in the
network but, by correlating failure reports from the intersecting traces,
automate the failure localization. What is the use case for the Loopback
mode? Roundtrip delay and roundtrip packet loss measurement? What requires
standardization?

Is the "liveness monitoring" functionally identical to path continuity
> monitoring provided by BFD?
>
> <RG00> STAMP  probe messages are used for synthetic packet loss which can
> be used to detect connection loss. The draft simply highlights this obvious
> metric.
>
GIM>> I cannot agree that STAMP can efficiently be used to detect the path
continuity loss. Perhaps even stronger, I would not advise and strongly
discourage the use of STAMP for path continuity monitoring. BFD (RFC 5880)
is intentionally lightweight and is capable of detecting a failure within
10 msec. Do you believe that STAMP test packets should be transmitted with
3.3 msec interval?

>
>    - 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?
>
> <RG> We can update the sentence in the first paragraph as following:
>
> The TTL field in the IPv4 and MPLS headers of the probe query messages is
> set to 255 *[RFC5357] except following two cases*.
>
GIM>> Can please you quote the text in RFC 5357 that requires setting
TTL/Hop Limit to 255?


>
> <RG> The IPv6 address ::1/128 is mentioned in the draft at couple of places. We can update the above text.
>
>
>    - 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.
>
> <RG00> This is described in RFC 6936. It will be very specific to the UDP
> port provisioned for STAMP. We will add reference to RFC 6936 in Security
> Section.
>
GIM>> RFC 6936 provides us with an exceptionally detailed analysis of that
question. I don't think that a reference can explain why using zero UDP
checksum is an acceptable practice. I recall that concern about the IPv6
security was the reason why RFC 7820 is applicable only to IPv4 and
includes the following text in regard to IPv6:
   UDP over IPv6, as defined in [IPv6], does not allow a zero checksum,
   except in specific cases [ZeroChecksum].  As discussed in
   [ZeroChecksum], the use of a zero checksum is generally not
   recommended and should be avoided to the extent possible.
And if the authors believe that they have an exceptional case, the case
must be stated.

>
>    - 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?
>
> <RG00> STAMP  probe messages are used for synthetic packet loss which can
> be used to detect connection loss (performance metric). The draft simply
> highlights this obvious metric.
>
GIM>> What could be the detection interval when using STAMP? How that is
compared with 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.
>
> <RG> Ok, we can update the text to indicate *synthetic* loss.
>
>    - 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.
>
> <RG> We can update text to : (*which requires clock synchronization for
> one-way delay measurement).*
>
>    - 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>.
>
> <RG00> As mentioned earlier, I am not sure extending ICMP to do PM is a
> good option here.
>
GIM>> I think that we can have a single mechanism instead of two defined in
*twamp-srpm nd *stamp-srpm. Would be interesting to hear from SPRING and
IPPM WGs.

>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> 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
>
>
>