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

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

Thank you Greg for taking time for thoroughly reviewing the documents and providing the comments.
Please see replies inline with <RG>…

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-twamp-srpm-11
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
I've got surprised that the drafts don't use the terminology from RFC 4656 and 5357 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 and reasonably well-written.

<RG> We are ok to change Sender to Session-Sender and Reflector to Session-Reflector if it helps.
<RG> 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.

  *   Does the document solve a real problem?
No, it appears that these drafts define a new performance measurement protocol for the purpose of combining OWAMP and TWAMP functionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms like ICMP.

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

  *   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.
<RG> 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 TWAMP. Other than this, I did not find any other security related issue in your review below.
To summarize my review of these two drafts:

  *   these propose a new protocol, not an update or enhancement of the TWAMP-like protocol;
<RG> The probe and response messages defined in [RFC 5357] are used for delay measurement and synthetic packet loss. The direct-mode packet loss messages are defined in draft-gandhi-ippm-twamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-ippm-twamp-srpm/> that match these delay measurement messages. As stated, draft-gandhi-ippm-twamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-ippm-twamp-srpm/> defines “extensions” for TWAMP Light.

  *   several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, require detailed security analysis, which is currently absent;
<RG> This is specified in RFC 6936 Security Section. 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 TWAMP.

  *   I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on the Informational track even though it is essential to the new protocol as it defines its key elements

<RG> This was to address your previous comment quoted as:

 “- as I understand, the draft is applicable to TWAMP Light mode,
   mentioned in the informational Appendix I in RFC 5357, not the TWAMP
   protocol itself. Since TWAMP Light is not a standard but its idea is
   described in the informational text only, I think that the Informational
  track is more appropriate for this specification.”
https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/
<RG> Having said that, we are ok to change to PS.

  *   I believe that draft-gandhi-spring-twamp-srpm should be anchored at IPPM WG as it does introduce the new PM protocol.
<RG> The TWAMP Light extension draft-gandhi-ippm-twamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-ippm-twamp-srpm/> is already in IPPM WG. The SPRING draft only defines SR PM procedures.

Below, please find my detailed comments, questions on these drafts:

  *   draft-gandhi-spring-twamp-srpm
I have several questions about the relationships between this draft and Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained in Section 4 of RFC 8545<https://datatracker.ietf.org/doc/rfc8545/> (apologies for the long quote):
   "TWAMP Light" is an idea described in Appendix I ("TWAMP Light
   (Informative)") of [RFC5357]; TWAMP Light includes an unspecified
   control protocol combined with the TWAMP-Test protocol.  In
   [RFC5357], the TWAMP Light idea was relegated to Appendix I because
   TWAMP Light failed to meet the requirements for IETF protocols (there
   are no specifications for negotiating this form of operation and no
   specifications for mandatory-to-implement security features), as
   described in Appendix A of this memo.  See also [LarsAD] and
   [TimDISCUSS].

   Since the idea of TWAMP Light clearly includes the TWAMP-Test
   component of TWAMP, it is considered reasonable for future systems to
   use the TWAMP-Test well-known UDP port (whose reallocated assignment
   is specified in this document).  Clearly, the TWAMP Light idea
   envisions many components and communication capabilities beyond
   TWAMP-Test (implementing the security requirements, for example);
   otherwise, Appendix I of [RFC5357] would be one sentence long
   (equating TWAMP Light with TWAMP-Test only).

Since we don't have an IETF document that addressed these open questions, I don't think we can have a draft that proposes extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.


<RG> This was to address your previous comment quoted as

 “- as I understand, the draft is applicable to TWAMP Light mode,
   mentioned in the informational Appendix I in RFC 5357, not the TWAMP
   protocol itself. Since TWAMP Light is not a standard but its idea is
   described in the informational text only, I think that the Informational
   track is more appropriate for this specification.”
https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/
<RG> Having said that, we are ok to change to PS as you mentioned above.
<RG> BTW, despite only difference of fixed vs. variable length payload in STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning  as defined in this draft). Hence, security considerations for STAMP and TWAMP Light are not different. Note that both STAMP and TWAMP Light have authenticated messages defined for Security purpose.
Now a number of more specific questions.
draft-gandhi-spring-twamp-srpm:

  *   In the Introduction it is stated that:
  The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides
   simplified mechanisms for active performance measurement in Customer
   IP networks by provisioning UDP paths and eliminates the need for
   control-channel signaling.
I can not find where, either Appendix I or TR-390, "eliminated the need for control-channel signaling". Also, could you point where the referenced documents describe "provisioning UDP paths"?


<RG> The Appendix I of RFC 5357 has following text. We can reword and match the exact text if you prefer.



“This example eliminates the need for the TWAMP-Control protocol, and

   assumes that the Session-Reflector is configured”

  *   It appears that the last paragraph in the Introduction describes the relationship with Appendix I of RFC 5357:
   The procedure uses the mechanisms defined in [RFC5357]
   (TWAMP Light) and its extensions for Performance Measurement.
I think that the reference must be to Appendix I, not RFC 5357. Also, could you please specify which extensions of TWAMP Light have been used in this draft?
<RG> We can add the Appendix I as reference in the next revision. Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this reference.

  *   In Section 2.3 describing the reference model is noted:
   The probe response message is typically sent to the sender node R1.
In which scenarios the reflector acts differently? How such behavior is related to the behavior of a TWAMP Session-Reflector, as defined in RFC 5357?
<RG> Do you prefer we remove “typically” from the sentence?

  *   Also in Section 2.3 a Link is mentioned as an element directly connecting nodes in the presented reference model. Could you clarify what is a Link? Is it always a physical connection between two systems or a virtual?
<RG> Both, please see Section 4.1.3. “Link” is well known term used in many existing RFCs (please see RFC 5613, 5340, 8330).

  *   In Section 3 behavior of the reflector described as
   ... no PM state for delay or loss measurement need to be created on the
   reflector node R5.
That is in contradiction to the behavior of a TWAMP Session-Reflector as defined in RFC 5357. Could you provide a reference to an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way delay and synthetic loss measurement on a bidirectional SR tunnel?

<RG> Quoting the text from Appendix I in RFC 5357. We can quote the text as is.

“In the case of TWAMP Light, the Session-Reflector does not necessarily have knowledge of the session state. “


  *   Further, in Section 3 the selection of UDP port explained as the following:
   As specified in [RFC8545], the reflector
   supports the destination UDP port 862 for delay measurement probe
   messages by default.  This UDP port however, is not used for loss
   measurement probe messages.
To the best of my understanding, as one of the contributors and Editors of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in the same test session, using the same flow of TWAMP-Test packets.

<RG> The packet loss in existing RFC 5357 refers to synthetic loss as there is no support for direct-mode loss in RFC 5357. We can change the text to clarify as “This UDP port however, is not used for direct-mode loss measurement probe messages.”

  *   Then the draft states that
The sender uses the UDP port number following the guidelines specified in Section 6 in [RFC6335].
Could you point to the guidelines that a user can use when selecting a UDP port number of a test session?

<RG> Please see section 6 in [RFC6335]. We can cite the range which will be the same as used in [RFC8762]. This was also discussed earlier.
https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/


  *   At the closing of the paragraph, we read that
  The number of UDP ports with PM functionality needs to be minimized due
   to limited hardware resources.
Does a UDP port number pose PM functionality? How it is assigned to the port number?
<RG> UDP ports are user configured for delay and direct-mode loss PM as described in Section 3.1.

  *   Following the above-quoted text, in Section 3 is noted:
   For Performance Measurement, probe query and response messages are
   sent as following:
Could you clarify if the listed further procedures deviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for Session-Sender and Session-Reflector respectively?
<RG> Probe messages follow the same procedure as defined in RFC 4656 and RFC 5357.

  *   for both delay and loss measurements draft requires test packet be transmitted on a congruent path:
      the probe messages are sent on the
      congruent path of the data traffic by the sender node
It is not clear what "the congruent path" means. The definition of congruency in geometry tells us that an object B is congruent to object A if it has the same shape and size, but is allowed to flip, slide or turn. How a path can be congruent to another path?
<RG> 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.

  *   The last paragraph in Section 3 refers to work on iOAM:
   The In-Situ Operations, Administration, and Maintenance (IOAM)
   mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for
   SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM
   information such as timestamp in-band as part of the data packets,
   and are outside the scope of this document.
Is iOAM in the scope of this specification? What are the relationships between iOAM and draft-gandhi-spring-twamp-srpm?
<RG> As mentioned in the draft, IOAM is outside the scope.

  *   Section 3.1 presents an example of the provisioning model but puts the definition of the provisioning model outside the scope. Is there an accompanying specification that defines the provisioning model that can be used in multi-vendor deployment? Could that be YANG data model? What is the relationship with draft-ietf-ippm-twamp-yang<https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13>? Would the TWAMP YANG data model be augmented?
<RG> Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yang<https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> and add any missing items in a separate draft. We can also add a reference in this draft.

  *   Section 4.1 states that a new message is introduced to perform the Loss Measurement in this protocol Why the capability of TWAMP to measure the loss in one-way and two-way is not sufficient?
<RG> Existing TWAMP messages do not support “direct-mode” loss measurement. We can add “direct-mode” in the text to clarify.

  *   Section 4.1.1 requires that
  The Destination UDP port cannot be used as Source port, since
   the message does not have any indication to distinguish between the
   query and response message.
Does that imply that the Destination UDP port used for the Delay measurement is unique throughout the particular domain?
<RG> This is user-defined and is up to the user what UDP port to provision in a domain.

  *   Section 4.1.2 of RFC 5357 does not define "the delay measurement message" but refers to the definition of the Session-Sender's test packet in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet format to perform both delay and packet loss measurement.
<RG> Ok, we can update the text in the next revision to indicate exact name from the RFC 4656. We can also add text to include synthetic packet loss.

  *   Can you explain how "the DM probe query message contains the payload format defined in Section 4.2.1 of [RFC5357]" when the referenced section of RFC 5357 defines the format of a Session-Reflector's test packet?
<RG> We can update the text in the next revision to indicate query format name from RFC 5357.

  *   Can clarify the applicability of RFC 6038 and the symmetrical packet size? Is it required? Can it be non-symmetrical?

<RG> Yes. Please see section 4.1.1 and quoted below:

“For symmetrical size query and response messages as defined in [RFC6038],”

  *   Can you clarify the use of the timestamp format, NTP or PTPv2? It is not clear which is the default, mandatory or optional.
<RG> This is same as TWAMP. There is no change.

  *   Also, is "hardware support in Segment Routing networks" of the PTPv2 format required, guaranteed, or something else?
<RG> Hardware timestamps are recommended for SR use-cases. We can change the sentence.

  *   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.
Can that be interpreted that there could be concurrent authenticated and unauthenticated test sessions using this protocol? Would different authentication methods require using unique destination UDP port numbers?

<RG> Yes, and Yes, and these are based on provisioning.

  *   Section 4.1.2 by introducing the dedicated Loss measurement packet format, effectively modifies the behavior defined in RFC 5357 for Session-Sender and Session-Reflector. But the document does not state that. Can you clarify whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 5357 respectively for the support of packet loss measurement?
<RG> The direct-mode loss defines new procedure for sender/reflector to collect traffic counters, as opposed to timestamp. The rest is the same as RFC 4656 and 5357.

  *   And a similar question about the use of the separate UDP port number for the authenticated of the packet loss measurement.
  *   A couple of question to the following text in Section 4.1.3:
   The local and remote IP
   addresses of the link are used as Source and Destination Addresses.
   They can also be IPv6 link local address as probe messages are pre-
   routed.

     *   What are the addresses of a link?
<RG> I am assuming this well-known (e.g. RFC 2328).

     *   In which scenarios an IPv6 LLA can be used?
<RG> I am assuming this is well-known (e.g. RFC 5613).

     *   Also, could the use of a routable destination IP address be used as a DDOS attack vector? Consider the scenario when an attacker generates SR-encapsulated packets with the destination IP address other than any of the SR-terminating nodes. Such a packet will be routed, correct? That does appear as a security threat, would you agree?
<RG> Absolutely do not agree. It is no different than IP routed TWAMP packet as defined in [RFC5357].

  *   Section 4.1.4.2 references Figure 5 that, as I understand it, displays the format of a probe query message. In figure two references to RFC 5357 are provided - a section that references RFC 4656 OWAMP definition of the Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the two is used for the delay measurement in the proposed protocol?
<RG> The probe query packet in the Session-Sender text packet. We can update the name.

  *   Section 4.2.1 states that
   In one-way measurement mode, the probe response message as defined in
   Figure 6 is sent back out-of-band to the sender node ...
Could you clarify how the responder controls that the response packet is sent not in-band but out-of-band?

<RG> Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm.  This is existing behaviour for out-of-band.

  *   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?
<RG> There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403.

  *   What is the rationale for setting TTL/Hop Limit fields always to 255 for IPv4, MPLS, and IPv6 (per Section 4.3.1)?
<RG> This is as defined in Section 4.2 of RFC 5357 (Bullet 4).

  *   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.
<RG> This is described in RFC 6936. It will be very specific to the UDP port provisioned for TWAMP. We will add reference to RFC 6936 in Security Section.

  *   Section 8 refers to "liveness monitoring of Links and SR Paths". This appears as the replication of functionality provided by BFD/S-BFD protocols. Is such comparison accurate? If it is, shouldn't the proposal be also reviewed by the BFD WG?
<RG> TWAMP  probe messages are used today for synthetic packet loss which can also be used to detect connection loss (performance metric). The section simply highlights this obvious metric.

  *   I found the Security Section of the proposed protocol inadequately terse and missing very important threats that this protocol introduces in the network.
<RG> Other than referring RFC 6936 for zero checksum what else is missing? Otherwise it is no different than RFC 8762 (STAMP).

  *   draft-gandhi-ippm-twamp-srpm
As I understand it, the motivation for the Loss Measurement mode defined in this specification is to collect "in-profile" counters. Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled? In your opinion, how using an out-of-band method of collecting these counters, e.g., by using ICMP multi-part message extension per RFC 4884, could affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messages are in-band with the profiled flow?

<RG> As mentioned earlier, I am not sure extending ICMP to do PM is a good option here. Both TWAMP and OWAMP are widely deployed today for delay and synthetic loss measurement.

  *   Section 3.1 introduces the new field, Sender Control Code. The format of the packet, as I understand it, is presented in Figure 1. When comparing with the format of Session-Sender's test packet defined in RFC 4656 OWAMP in Section 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?
<RG> It shows the partial message that has new field. We can update it to show the full message to avoid such confusion.

  *   Also, it appears that the Sequence Number field in TWAMP Session-Sender's test packet is absent in Figure 1. Is that intentional?
<RG> It shows the partial message that has new field. We can update it to show the full message to avoid such confusion.
Thanks,
Rakesh

Regards,
Greg


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

This message starts a 3 week WG adoption call for document https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Please note that this document has several changes from v-10 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-twamp-srpm-10. 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 TWAMP Light Messages, Loss Measurement Query Message Extensions, and Loss Measurement Response Message Extensions were included in https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and should be removed from the SPRING document.
  *   The TWAMP extensions included in https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 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-twamp-srpm-10 the result of which is the publication of the following two documents:


  *   https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The subject of this WG adoption call.
  *   https://tools.ietf.org/html/draft-gandhi-ippm-twamp-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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring