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

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 2 Dec 2020 20:18:35 +0000

Thank you Greg for your further reply and the discussions.
Good to know that you do see a need for the extensions for the direct-mode packet loss detection and the authors are actively working on an alternate methods using BFD (as you mentioned below).
Please see replies inline with <RG3>….

From: Greg Mirsky <[email-masked]>
Date: Monday, November 30, 2020 at 11:30 AM
To: Rakesh Gandhi (rgandhi) <[email-masked]>
Cc: Gyan Mishra <[email-masked]>, IETF IPPM WG <[email-masked]>, James Guichard <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Greg Mirsky <[email-masked]>
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
Hi Rakesh,
thank you for the continued discussion. I appreciate your responses. I am still not convinced of the value these documents add. Please find my follow-up notes in-line below under the GIM2>> tag.

Regards,
Greg

On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Gyan and Greg for your review comments and discussions. Please see inline replies with <RG2>…
From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 25, 2020 at 12:34 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: IETF IPPM WG <[email-masked]<mailto:[email-masked]>>, James Guichard <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
 Hi Rakesh
I have been following this thread and to help progress the discussion I would like to provide some comments in-line Gyan>
Thanks
Gyan
On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
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 7:33 AM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Greg for taking time for thoroughly reviewing the documents and providing the comments.
Please see replies inline with <RG>…
From: ippm <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
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.

GIM>> I believe that the consistency in terminology between the core RFC 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 the proposal. The operation that is required from the remote entity, whether it is referred to as responder or Session-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely new protocol that, if there's a need in the new PM OAM protocol, must be properly defined.
   Gyan> I am in complete agreement with Greg about terminology and consistency.  The problem with inconsistency is that that you are not following well known normative references required to understand the specification leading to confusion and misunderstanding of the specification.  The goal should be clear and concise in terminology and verbiage.
<RG2> Agree. Will address the terms from RFC 5357 in the next revision.
<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.
GIM>> Thank you for listing these RFCs. I think I need to clarify my questions. While a reference to any of RFCs you've mentioned, I don't think that 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 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 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.
 Gyan>  This may sound basic but is a very critical subject going down the same lines of clarity in verbiage so their is no misunderstanding.  “Congruent” by definition means shape of an object and if you super imposed two objects on top of each other they fit perfectly and the edges coincide identically.  The problem with congruent is that it is based on the shape and that shape could be a mirror image or reflection which may not be exact.  So when referring to a SR-TE path taken this could lead to confusion as to path taken if it’s the same path or congruent which is vague as to “exactly” which path is taken where here there is criticality as to the path being referenced in terms of in-band versus out-of-band.  I agree that for direct in band packet loss measurement can be done via existing OAM mechanisme via ICMP.
<RG2> Ok, we will find an appropriate term for “sending packets on the same path as data traffic”.
<RG2> Extending ICMP for direct-mode loss measurement is outside the scope of this draft. But good to see the agreement for the direct in band packet loss measurement to be done (albeit by some other means).
GIM2>> I feel that you misunderstand my position in regard to the use case these four documents try to solve. I don't recall that I've stated that "direct in-band packet loss measurement" requires any additional standardization work. The Direct Measurement TLV has solved that for STAMP and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I cannot find any valid technical reason to re-open this and measure the direct packet loss in a slightly different way. I must point out that a claim that using fixed positions for the direct packet loss optimizes performance does not stand for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm) when the return path is specified in the Return Path TLV and, as I understand it, in some cases even the second TLV, Node Address TLV, is used. Thus, it is clear that the proposed new method of direct packet loss measurement does not offer any significant benefits comparing to the STAMP's Direct Measurement TLV and appears nothing but superfluous.

<RG3> The direct-mode packet loss use-case is typically for the forward direction packet loss. And this does not use the return path TLV. We can clarify that in the draft.
<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.
GIM>> I agree with the requirements you've listed (though the SPRING WG OAM requirements document<https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03> has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason to use OWAMP/TWAMP for exclusive direct packet loss measurement.
    Gyan> Agreed

<RG2> There is definitely a need to do direct-mode loss measurement in IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that there was an attempt to extend BFD for direct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03).
GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended<https://www.ietf.org/archive/id/draft-mirmin-bfd-extended-03.txt> in the past tense. The work and discussion of the proposal continues and the new version will be published soon.

<RG3> Ok, so you do see a need for the extensions for the direct-mode packet loss detection and the authors are actively working on an alternate methods using BFD.

  *   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.
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.
     Gyan> Agreed 0 UDP MIMA security threats and that you need to thorough vetting of RFC 6936.
 <RG2> Yes, will add in the next revision. Hope we can work together on needed text.
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.
GIM>> I cannot find where RFC 5357 defines "the probe and response messages". Could you give a more specific reference or provide the text that, in your opinion, defines such messages? But I'm more concerned with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's TR-390, I'm have learned how different are existing implementations of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper<https://mail.google.com/mail/u/0/?q=draft-ietf-ippm-stamp-option-tlv#inbox?compose=CqMvqmRLZZrxJQtbnmkKJVzZBZszkgxPgsfzWBLMWntdzDFXDrjLTQtqrhmDFgdNbzkHXhJNrKg>. The status of TWAMP Light is explained in RFC 8545 and I cannot see that it can be used as a foundation of any standard.
  Gyan> I don’t see the probe a d response messages in TWAMP RFC 5357
<RG2> Agree to use term test-packet from RFC 5357.
·         several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, require detailed security analysis, which is currently absent;
     Gyan> Agreed
<RG2> Please see previous reply.
<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.
GIM>>  I've noted above that a simple reference does not sufficiently explains why the use of zero UDP checksum in IPv6 header is not decremental, does not create a security risk for the protocol. I believe that the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.
    Gyan> Completely Agree
 <RG2> Please see previous reply.

  *   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.
GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. If anyone is interested in standardizing an "extension", I'd expect that they first define the base specification to which the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you point to the definition, for example, of the Authenticated mode in TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357?
     Gyan> Agreed
<RG2> The Appendix I of RFC 5357 does have information on the Authentication mode. As specified there, this is based on user configured parameters.
·         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.
 Gyan> Agreed
<RG2> The procedure for using the RFC 5357 defined messages in TWAMP Light configuration mode is defined in the corresponding spring drafts. It also describes the provisioning model.
GIM2>> If a return path can be provisioned for TWAMP Light, why the same method of controlling a test session cannot be used for STAMP?

<RG3> It is not expected that all STAMP TLV extensions need to be supported for TWAMP Light using provisioning.
 <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.
GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the light, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the discussion of "extension" to TWAMP Light.
<RG2> The Authentication information is user-configured as shown in Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in Appendix I of RFC 5357.
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”
GIM>> I think that the text you're proposing is even more confusing. It is not clear which example the sentence is referring to. Also, what is the basis for such an assumption?
<RG2> This is the exact text from RFC 5357 Appendix I. Please go through the entire Section in that RFC 5357 to avoid “out of context” discussion.

  *   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.
GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a normative reference while it is, by its nature, an Informational document.
<RG2> If approved, it is fine to have informational draft/RFC in a normative reference. But RFC 5357 is PS.

  *   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?
GIM>> If that fits into the operational model of the new protocol you're defining.

  *   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).
GIM>> Thank you for the references. I couldn't find a definition of an object "Link" (capitalized) but only "link" (lower case). Hence, since the draft consistently uses the capitalized form, I consider it to be something else, something different from a link.
<RG2> Ok, we can change Link to link in the next revision to avoid confusion.

  *   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?
 Gyan> Valid point
<RG2> Bidirectional SR tunnel may have an SR state but the statement above is that no PM (i.e. TWAMP Light) protocol session state is created for it. We can clarify in the next revision.
GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one option. I am well-familiar with the implementation that uses the stateful mode.

<RG3> What information stateful PM need to maintain in the state on the reflector? Doesn’t that cause scale issues. We can add in the draft you if there is anything specifically needed in the spec.
 <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. “
GIM>> By the informational nature of Appendix I, the text is not normative. I am familiar with the implementation of TWAMP Light which does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does not maintain the state, the draft must define that as part of the specifying the behavior of the protocol.
 <RG2> Ok, we can discuss what information is to be maintained in that state on the reflector for synthetic packet loss. We can add appropriate text if you can help please.
GIM2>> I don't see any reason to do that as that already defined in RFC 8762 and draft-ietf-ippm-stamp-yang <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>

<RG3> Ok.
·         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.
 Gyan> Agreed
<RG2> Yes, we can use port 862 for both delay and synthetic packet loss – they are using the same test packet. There is no change proposed in the draft.
GIM2>> Packet delay and synthetic packet loss measurements are already supported in RFC 8762. Are you proposing a new protocol to duplicate the STAMP functionalities?

<RG3> As mentioned, the extensions defined are for the direct-mode packet loss measurement for TWAMP Light and STAMP.
<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.”
GIM>> I've found that there's some misconception in the draft. RFC 8545 re-assigned UDP port 862 not for "delay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, packet loss, reordering (RFC 4737 defines packet reordering metric), and packet duplication measurement.

  *   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?
Gyan> Good point
<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/
GIM>> I've looked through Section 6 but I don't find anything specifically applicable to this draft we're discussing. If the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that explicitly would be the best way.

<RG2> This would be, User Ports and Dynamic Ports ranges, which are defined in [RFC6335<https://tools.ietf.org/html/rfc6335>]. Yes, we can add this text.

  *   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.
GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss measurement uses port number different from the one used by a TWAMP-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protocol.
<RG2> If we add a field in the packet then UDP port 862 may be used along with the new field. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.

  *   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.
GIM>> All messages, i.e., TWAMP-Test packets as well as the defined in draft-gandhi-ippm-twamp-srpm?
 <RG2> Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm.

  *   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?
       Gyan> Agreed.  The use of congruent in the context of pathing is confusing as the path being addressed may not be reflected accurately by the term congruent.
<RG2> As replied above.
<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.
GIM>> I cannot assume what was the context of these RFCs. I've sketched a network diagram above to illustrate that a "congruent path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band?
<RG2> As replied above.

  *   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.
GIM>> Yes, but it appears that references to the two IOAM-related drafts have some purpose. What is it? How are these drafts related to draft-gandhi-spring-twamp-srpm?
<RG2> We can remove them if it is confusing. It is informational text (was added to address a review comment).

  *   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.
GIM>> I think that theremust be some discussion on how the new protocol is configured. If TWAMP YANG data model can be augmented, I'd expect that being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything about the configuration of the protocol.
<RG2> The Yang model extensions are not in the scope of 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.
GIM>> True, direct loss measurement, in fact, is not active measurement and thus is outside the scope of Two-Way Active Measurement Protocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching counters can be done using numerous methods, e.g., SNMP, Netconf
<RG2> RFC 7799 does not say using Test-packets to collect counters for direct-mod loss measurement is passive.
GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic of an active measurement method. Using out-of-band transport, e.g., SNMP queries, would be an example of a passive measurement method.

<RG3> Ok, so you answered your own question that the direct-mode packet loss extension defined is “active measurement” method.

  *   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?
       Gyan> Good question
<RG2> Yes, it is unique in the domain.
<RG> This is user-defined and is up to the user what UDP port to provision in a domain.
GIM>> So, can user configure a port number from the User Ports range? Or, can the same port number be used on the same system for a number of test sessions? I find the use of UDP port numbers being underspecified.

  *   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.
GIM>> I think that making it explicit would help. Also, that will highlight what is being introduced by *twamp-srpm drafts is, in fact, a new protocol to perform synthetic packet loss measurement.
 <RG2> No, it does not change anything for 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.
GIM>> I cannot find any reference to a query format in RFCs 4656/5357. Could you please quote from any of these documents?
 <RG2> It is test-packet, we will use RFC 5357 term.

  *   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],”
GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm proposals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came later), I don't see that there's any certainty in what is the sze of a test packet used in the direct-loss measurement.
 <RG2> The test-packets as defined in these existing RFCs are used for delay and synthetic packet loss. The direct-mode test-packets are defined in this draft.
GIM2>> This draft defines only a new packet format for the direct packet loss measurement. For STAMP such a mechanism is clearly superfluous given the Direct Measurement TLV is already defined.

<RG3> As replied earlier.

  *   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.
GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for *-twamp-srpm?
 <RG2> No change in existing in what is there in RFC 5357 and RFC 8186.

  *   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.
GIM>> Perhaps you can propose some text, that would be helpful.
 <RG2> Ack.

  *   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.
GIM>> But that requirement is far outside the TWAMP, as defined in RFC 5357.
 <RG2> Some Session-Sender can use authenticated and some not. It is part of RFC 5357.

  *   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.
GIM>> I cannot agree with your statement " The rest is the same as RFC 4656 and 5357" because the sender's direct-loss format does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of the reflector. And that, in my opinion, is another clear indication that *twamp-srpm drafts define a new protocol, separate from OWAMP/TWAMP.
 <RG2> That field is specific to timestamps and would not apply to counters for direct-mode loss measurement.

  *   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).
GIM>> I am not familiar with the term "pre-routed". What does it mean?
 <RG2> Ensure that packets are routed over the link.

     *   In which scenarios an IPv6 LLA can be used?
<RG> I am assuming this is well-known (e.g. RFC 5613).
GIM>> So, LLA may be used as the source and destination addresses when testing an SR tunnel?
 <RG2> As mentioned this is for links.

     *   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].
GIM>> You don't agree that the processing described cannot happen because of laws of physics or it wouldn't happen because no one will think of that? If the latter, I think that that is security threat.
 <RG2> There is no new threat like you have mentioned.
GIM2>> Hmmm, but how the integrity of TLVs proposed in draft-gandhi-ippm-stamp-srpm can be protected? These are not protected by HMAC as presented in figures 3 and 5.

<RG3> The extensions do not change the processing of these existing TLVs defined for HMAC. We can add text to indicate this.

  *   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.
GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines another new protocol OWAMP Light. And it is not clear what you reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-Test protocol by itself is neither in-band, nor out-of-band. It is the encapsulation of the TWAMP test packet that makes it either in-band or out-of-band.
 <RG2> Right.

  *   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.
GIM>> So, you believe that proposing to use the method described in RFC 8403 for the TWAMP packet is innovation? And what are the benefits of using the TWAMP test packet format in the Loopback mode?
 <RG2> Please see the draft.

  *   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).
GIM>> I believe you've misunderstood the text in RFC 5357. This bullet specifies the behavior of a Session-Reflector. It is to try to read TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Session-Reflector cannot access the TTL field, it MUST write 255 in the Sender TTL field. So, I think that my questions still remains.
 <RG2> Please see Section 4.2.1 of RFC 5357.

  *   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.
GIM>> I don't think that the reference is sufficient for the Securit Consideration. I'd expect some extended discussion on why using zero UDP header checksum is not a security threat for *twamp-srpm  protocol.
 <RG2> Please see reply above.

  *   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.
GIM>> Can you point to a document that has defined "TWAMP  probe messages are used today for synthetic packet loss"? Also, which document defines loss of connectivity as a performance metric? Does *twamp-srpm proposes to use the new protocol to detect the loss of path continuity?
 <RG2> For example Y.1731 has such notion of connection loss. TWAMP is used widely for synthetic packet loss and is well-known. There is no change in protocol. This is reported metric.
GIM2>> What are packet transmission frequencies authors envisioned for that mode? A single-digit millisecond?

<RG3> It depends on the implementation.

  *   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).
GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The use of source IP addresses, as mentioned above, appears to be another security risk introduced by *-twamp-srpm drafts.
 <RG2> There is no mention of Source IP address above.

  *   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?
 <RG2> Yes, they need to be in-band with the flow, to collect the counter from the right forwarding paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.
GIM2>> I think that the assumption "they need to be in-band with the flow, to collect the counter from the right forwarding paths for the flow" is technically inaccurate. Otherwise, how SNMP queries could work for decades of networking history?

<RG3> The scope of this draft is orthogonal to the out of band schemes those may exist.

Thanks,
Rakesh

<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.
GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend RFC 4656 OWAMP as well? Also, what you see as the connection between using active measurement methods to measure packet delay and packet loss, on one hand, and collecting packet counters?

<RG2> The Session-Sender test-packet is defined in OWAMP RFC and not TWAMP RFC. Other than timestamp and its format vs. counter and its format, the messages and processing are the same.

Thanks,
Rakesh

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

          Gyan

On Thu, Oct 22, 2020 at 5:51 AM James Guichard <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Dec 2020 09:51:39 -0800

Hi Rakesh,
thank you for the continued discussion. You can find my follow-up notes
in-line below under GIM3>> tag. I felt that one comment is at the root of
our different views on what is considered to be a problem that drafts
solve. You've said:

<RG3> As mentioned, the extensions defined are for the direct-mode packet
loss measurement for TWAMP Light and STAMP.

But draft-ietf-ippm-stamp-option-tlv
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>,
currently in  Submitted to IESG for Publication WG state according to IETF
datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in
the section:
   The Direct Measurement TLV enables collection of the number of in-
   profile packets, i.e., packets that form a specific data flow, that
   had been transmitted and received by the Session-Sender and Session-
   Reflector, respectively.  The definition of "in-profile packet" is
   outside the scope of this document and is left to the test operators
   to determine.
Thus I cannot see any technical need for the introduction of yet another
way of direct loss measurement in STAMP. As for the case of TWAMP Light, I
believe that there's no sufficient evidence that the proposed direct
loss-measurement measurement method benefits existing implementations of
TWAMP Light. Also, historically, all extensions applicable to TWAMP Light
have been introduced through extending TWAMP proper, i.e., extending
TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presented
in the drafts we are discussing is, in my opinion, in violation of RFC 5357.

More notes can be found below.

Regards,
Greg

On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> *Good to know that you do see a need for the extensions for the
> direct-mode packet loss detection and the authors are actively working on
> an alternate methods using BFD (as you mentioned below).*
>
GIM3>> As you've recognized, in draft-mirmin-bfd-extended
<https://www.ietf.org/archive/id/draft-mirmin-bfd-extended-03.txt> we build
an integrated OAM based on the lightweight Fault Management protocol with
optional Performance Monitoring, based on RFC 6374. RFC 6374, in turn,
provides a rich set of performance measurement methods, including direct
loss measurement.

>
>
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Monday, November 30, 2020 at 11:30 AM
> *To: *Rakesh Gandhi (rgandhi) <[email-masked]>
> *Cc: *Gyan Mishra <[email-masked]>, IETF IPPM WG <[email-masked]>,
> James Guichard <[email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>,
> [email-masked] <[email-masked]>, Greg Mirsky <[email-masked]>
> *Subject: *Re: [spring] [ippm] WG Adoption Call for
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
>
> Hi Rakesh,
>
> thank you for the continued discussion. I appreciate your responses. I am
> still not convinced of the value these documents add. Please find my
> follow-up notes in-line below under the GIM2>> tag.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) <[email-masked]>
> wrote:
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Wednesday, November 25, 2020 at 12:34 PM
> *To: *Greg Mirsky <[email-masked]>
> *Cc: *IETF IPPM WG <[email-masked]>, James Guichard <
> [email-masked]>, Rakesh Gandhi (rgandhi) <
> [email-masked]>, [email-masked] <[email-masked]>,
> [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *Re: [spring] [ippm] WG Adoption Call for
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
>
>  Hi Rakesh
>
> I have been following this thread and to help progress the discussion I
> would like to provide some comments in-line Gyan>
>
> Thanks
>
> Gyan
>
> On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Rakesh,
>
> On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) <[email-masked]>
> wrote:
>
> *From: *ippm <[email-masked]>
> *Date: *Friday, November 6, 2020 at 11:18 AM
> *To: *James Guichard <[email-masked]>
> *Cc: [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>,
> IETF IPPM WG <[email-masked]>
> *Subject: *Re: [ippm] [spring] WG Adoption Call for
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
>
> 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.
>
>    - 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.
>
> GIM>> I believe that the consistency in terminology between the core RFC
> 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 the proposal. The operation that is required from the remote entity,
> whether it is referred to as responder or Session-Reflector, is not defined
> in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion,
> the behavior required, as described in the draft, cannot be characterized
> as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely
> new protocol that, if there's a need in the new PM OAM protocol, must be
> properly defined.
>
>    Gyan> I am in complete agreement with Greg about terminology and
> consistency.  The problem with inconsistency is that that you are not
> following well known normative references required to understand the
> specification leading to confusion and misunderstanding of the
> specification.  The goal should be clear and concise in terminology and
> verbiage.
>
> <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.
>
> GIM>> Thank you for listing these RFCs. I think I need to clarify my
> questions. While a reference to any of RFCs you've mentioned, I don't think
> that 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?
>
> Consider 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 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.
>
>  Gyan>  This may sound basic but is a very critical subject going down the
> same lines of clarity in verbiage so their is no misunderstanding.
>  “Congruent” by definition means shape of an object and if you super
> imposed two objects on top of each other they fit perfectly and the edges
> coincide identically.  The problem with congruent is that it is based on
> the shape and that shape could be a mirror image or reflection which may
> not be exact.  So when referring to a SR-TE path taken this could lead to
> confusion as to path taken if it’s the same path or congruent which is
> vague as to “exactly” which path is taken where here there is criticality
> as to the path being referenced in terms of in-band versus out-of-band.  I
> agree that for direct in band packet loss measurement can be done via
> existing OAM mechanisme via ICMP.
>
> <RG2> Extending ICMP for direct-mode loss measurement is outside the scope
> of this draft. But good to see the agreement for the direct in band packet
> loss measurement to be done (albeit by some other means).
>
> GIM2>> I feel that you misunderstand my position in regard to the use case
> these four documents try to solve. I don't recall that I've stated that
> "direct in-band packet loss measurement" requires any additional
> standardization work. The Direct Measurement TLV has solved that for STAMP
> and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I
> cannot find any valid technical reason to re-open this and measure the
> direct packet loss in a slightly different way. I must point out that a
> claim that using fixed positions for the direct packet loss optimizes
> performance does not stand for cases (Section 4.2.1 and 4.2.2 of
> draft-gandhi-spring-stamp-srpm) when the return path is specified in the
> Return Path TLV and, as I understand it, in some cases even the second TLV,
> Node Address TLV, is used. Thus, it is clear that the proposed new method
> of direct packet loss measurement does not offer any significant benefits
> comparing to the STAMP's Direct Measurement TLV and appears nothing but
> superfluous.
>
>
>
> <RG3> The direct-mode packet loss use-case is typically for the forward
> direction packet loss. And this does not use the return path TLV. We can
> clarify that in the draft.
>
GIM3>> Clarification would be very helpful as your latest note might be
interpreted that the proposed mechanisms are not applicable in the case of
a bi-directional SR tunnel.

> <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.
>
> GIM>> I agree with the requirements you've listed (though the SPRING WG
> OAM requirements document
> <https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03> has
> been abandoned and expired 3+ years ago). I believe that there's no
> sufficient technical reason to use OWAMP/TWAMP for exclusive direct packet
> loss measurement.
>
>     Gyan> Agreed
>
> <RG2> There is definitely a need to do direct-mode loss measurement in
> IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that
> there was an attempt to extend BFD for direct-mode loss measurement for
> this purpose using RFC 6374 loss measurement message (see
> draft-mirmin-bfd-extended-03).
>
> GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended
> <https://www.ietf.org/archive/id/draft-mirmin-bfd-extended-03.txt> in the
> past tense. The work and discussion of the proposal continues and the new
> version will be published soon.
>
>
>
> *<RG3> Ok, so you do see a need for the extensions for the direct-mode
> packet loss detection and the authors are actively working on an alternate
> methods using BFD. *
>
>
>    - 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.
>
> 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.
>
>    - 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.
>
> GIM>> I cannot find where RFC 5357 defines "the probe and response
> messages". Could you give a more specific reference or provide the text
> that, in your opinion, defines such messages? But I'm more concerned with
> the direction of "extending" non-protocol referred to as "TWAMP Light". As
> a contributor to BBF's TR-390, I'm have learned how different are existing
> implementations of TWAMP Light. And that is also noted in EANTC
> Multi-Vendor Interoperability 2019 white paper
> <https://mail.google.com/mail/u/0/?q=draft-ietf-ippm-stamp-option-tlv#inbox?compose=CqMvqmRLZZrxJQtbnmkKJVzZBZszkgxPgsfzWBLMWntdzDFXDrjLTQtqrhmDFgdNbzkHXhJNrKg>.
> The status of TWAMP Light is explained in RFC 8545 and I cannot see that it
> can be used as a foundation of any standard.
>
> ·         several parts of the proposed protocol, e.g., Zero UDP checksum
> in IPv6, require detailed security analysis, which is currently absent;
>
>      Gyan> Agreed
>
> <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.
>
> GIM>>  I've noted above that a simple reference does not sufficiently
> explains why the use of zero UDP checksum in IPv6 header is not
> decremental, does not create a security risk for the protocol. I believe
> that the proposal to use zero UDP header checksum requires extensive
> analysis, using the analysis provided in RFC 6936.
>
>     Gyan> Completely Agree
>
>    - 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
>
> GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol.
> If anyone is interested in standardizing an "extension", I'd expect that
> they first define the base specification to which the extension applies. I
> might have missed the definition of TWAMP Light protocol in the draft. Could
> you point to the definition, for example, of the Authenticated mode in
> TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357?
>
>      Gyan> Agreed
>
> <RG2> The Appendix I of RFC 5357 does have information on the
> Authentication mode. As specified there, this is based on user configured
> parameters.
>
> ·         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.
>
>    - 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):
>
>  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.
>
>  Gyan> Agreed
>
> <RG2> The procedure for using the RFC 5357 defined messages in TWAMP Light
> configuration mode is defined in the corresponding spring drafts. It also
> describes the provisioning model.
>
> GIM2>> If a return path can be provisioned for TWAMP Light, why the same
> method of controlling a test session cannot be used for STAMP?
>
>
>
> <RG3> It is not expected that all STAMP TLV extensions need to be
> supported for TWAMP Light using provisioning.
>
> <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.
>
> GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the
> light, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot
> find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode
> of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the
> discussion of "extension" to TWAMP Light.
>
> <RG2> The Authentication information is user-configured as shown in
> Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in
> Appendix I of RFC 5357.
>
>    - In the Introduction it is stated that:
>
> 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"?
>
> GIM>> I think that the text you're proposing is even more confusing. It is
> not clear which example the sentence is referring to. Also, what is the
> basis for such an assumption?
>
> <RG2> This is the exact text from RFC 5357 Appendix I. Please go through
> the entire Section in that RFC 5357 to avoid “out of context” discussion.
>
>
>    - It appears that the last paragraph in the Introduction describes the
>    relationship with Appendix I of RFC 5357:
>
> 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.
>
> GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a
> normative reference while it is, by its nature, an Informational document.
>
>    - In Section 2.3 describing the reference model is noted:
>
> 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?
>
>    - 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).
>
> GIM>> Thank you for the references. I couldn't find a definition of an
> object "Link" (capitalized) but only "link" (lower case). Hence, since the
> draft consistently uses the capitalized form, I consider it to be something
> else, something different from a link.
>
>    - In Section 3 behavior of the reflector described as
>
> 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?
>
>  Gyan> Valid point
>
> <RG2> Bidirectional SR tunnel may have an SR state but the statement above
> is that no PM (i.e. TWAMP Light) protocol session state is created for it.
> We can clarify in the next revision.
>
> GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one
> option. I am well-familiar with the implementation that uses the stateful
> mode.
>
>
>
> <RG3> What information stateful PM need to maintain in the state on the
> reflector? Doesn’t that cause scale issues. We can add in the draft you if
> there is anything specifically needed in the spec.
>
GIM3>> RFCs 5357 and 8762 are clear about what information must be
maintained by a Session-Reflector. The Session-Reflector must have
knowledge of the test session state and count reflected test packets. The
value of such a counter must be copied in the Sequence Number field of the
reflected packet. Thus the method enables the measurement of the one-way
packet loss metric.

> GIM>> By the informational nature of Appendix I, the text is not
> normative. I am familiar with the implementation of TWAMP Light which does
> maintain the session state and thus supports one-way packet loss
> measurement. If you require that the remote node does not maintain the
> state, the draft must define that as part of the specifying the behavior of
> the protocol.
>
>  <RG2> Ok, we can discuss what information is to be maintained in that
> state on the reflector for synthetic packet loss. We can add appropriate
> text if you can help please.
>
> GIM2>> I don't see any reason to do that as that already defined in RFC
> 8762 and draft-ietf-ippm-stamp-yang
> <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>
>
>
>
> <RG3> Ok.
>
> 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.
>
>  Gyan> Agreed
>
> <RG2> Yes, we can use port 862 for both delay and synthetic packet loss –
> they are using the same test packet. There is no change proposed in the
> draft.
>
> GIM2>> Packet delay and synthetic packet loss measurements are already
> supported in RFC 8762. Are you proposing a new protocol to duplicate the
> STAMP functionalities?
>
>
>
> <RG3> As mentioned, the extensions defined are for the direct-mode packet
> loss measurement for TWAMP Light and STAMP.
>
> <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.”
>
> GIM>> I've found that there's some misconception in the draft. RFC 8545
> re-assigned UDP port 862 not for "delay measurement probe messages" but for
> TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay,
> packet loss, reordering (RFC 4737 defines packet reordering metric), and
> packet duplication measurement.
>
>
>    - Then the draft states that
>
> <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.
>
> GIM>> I've looked through Section 6 but I don't find anything specifically
> applicable to this draft we're discussing. If the protocol to use UDP port
> numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it
> seems that stating that explicitly would be the best way.
>
> <RG2> This would be, User Ports and Dynamic Ports ranges, which are defined in [RFC6335 <https://tools.ietf.org/html/rfc6335>]. Yes, we can add this text.
>
>
>    - At the closing of the paragraph, we read that
>
> GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss
> measurement uses port number different from the one used by a TWAMP-Test
> packet, in my opinion, is another indication that this is the definition of
> a different from TWAMP Light PM OAM protocol.
>
> <RG2> If we add a field in the packet then UDP port 862 may be used along
> with the new field. But it will require extra processing in hardware. It is
> better to use a different UDP port for processing efficiency in hardware.
>
>
>    - Following the above-quoted text, in Section 3 is noted:
>
> 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?
>
>    - for both delay and loss measurements draft requires test packet be
>    transmitted on a congruent path:
>
> 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?
>
>        Gyan> Agreed.  The use of congruent in the context of pathing is
> confusing as the path being addressed may not be reflected accurately by
> the term congruent.
>
> <RG2> As replied above.
>
> <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.
>
> GIM>> I cannot assume what was the context of these RFCs. I've sketched a
> network diagram above to illustrate that a "congruent path" may well lead
> to out-of-band path. Is that the intention of the authors of the draft to
> use this protocol out-of-band?
>
> <RG2> As replied above.
>
>
>    - The last paragraph in Section 3 refers to work on iOAM:
>
> Is iOAM in the scope of this specification? What are the relationships
> between iOAM and draft-gandhi-spring-twamp-srpm?
>
> GIM>> Yes, but it appears that references to the two IOAM-related drafts
> have some purpose. What is it? How are these drafts related
> to draft-gandhi-spring-twamp-srpm?
>
>    - 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.
>
> GIM>> I think that theremust be some discussion on how the new protocol is
> configured. If TWAMP YANG data model can be augmented, I'd expect that
> being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything
> about the configuration of the protocol.
>
>    - 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.
>
> GIM>> True, direct loss measurement, in fact, is not active measurement
> and thus is outside the scope of Two-Way Active Measurement Protocol
> (TWAMP). The direct-loss measurement is, by the definition of RFC 7799,
> passive measurement method and fetching counters can be done using numerous
> methods, e.g., SNMP, Netconf
>
> GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic
> of an active measurement method. Using out-of-band transport, e.g., SNMP
> queries, would be an example of a passive measurement method.
>
>
>
> <RG3> Ok, so you answered your own question that the direct-mode packet
> loss extension defined is “active measurement” method.
>
>
>    - Section 4.1.1 requires that
>
> Does that imply that the Destination UDP port used for the Delay
> measurement is unique throughout the particular domain?
>
>        Gyan> Good question
>
> GIM>> So, can user configure a port number from the User Ports range? Or,
> can the same port number be used on the same system for a number of test
> sessions? I find the use of UDP port numbers being underspecified.
>
>
>    - 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.
>
> GIM>> I think that making it explicit would help. Also, that will
> highlight what is being introduced by *twamp-srpm drafts is, in fact, a new
> protocol to perform synthetic packet loss measurement.
>
>    - 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?
>
> GIM>> I cannot find any reference to a query format in RFCs 4656/5357.
> Could you please quote from any of these documents?
>
>    - Can clarify the applicability of RFC 6038 and the symmetrical packet
>    size? Is it required? Can it be non-symmetrical?
>
> GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the
> symmetrical test packets. Since *-twamp-srpm proposals do not use
> TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about
> that either (in part because RFC 6038 came later), I don't see that there's
> any certainty in what is the sze of a test packet used in the direct-loss
> measurement.
>
>  <RG2> The test-packets as defined in these existing RFCs are used for
> delay and synthetic packet loss. The direct-mode test-packets are defined
> in this draft.
>
> GIM2>> This draft defines only a new packet format for the direct packet
> loss measurement. For STAMP such a mechanism is clearly superfluous given
> the Direct Measurement TLV is already defined.
>
>
>
>    - Can you clarify the use of the timestamp format, NTP or PTPv2? It is
>    not clear which is the default, mandatory or optional.
>
>    - Also, is "hardware support in Segment Routing networks" of the PTPv2
>    format required, guaranteed, or something else?
>
>    - Section 4.1.1.1 stated that
>
> 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?
>
>    - 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.
>
> GIM>> I cannot agree with your statement " The rest is the same as RFC
> 4656 and 5357" because the sender's direct-loss format does not have Error
> Estimate field, Thus, a reflected packet does not have Sender's Error
> Estimate, nor Error Estimate of the reflector. And that, in my opinion, is
> another clear indication that *twamp-srpm drafts define a new protocol,
> separate from OWAMP/TWAMP.
>
>  <RG2> That field is specific to timestamps and would not apply to
> counters for direct-mode loss measurement.
>
>
>    - 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
>    - What are the addresses of a link?
>
>    - In which scenarios an IPv6 LLA can be used?
>
>    - 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?
>
> GIM>> You don't agree that the processing described cannot happen because
> of laws of physics or it wouldn't happen because no one will think of that?
> If the latter, I think that that is security threat.
>
> GIM2>> Hmmm, but how the integrity of TLVs proposed
> in draft-gandhi-ippm-stamp-srpm can be protected? These are not protected
> by HMAC as presented in figures 3 and
> 5.
>
>
>
>
> <RG3> The extensions do not change the processing of these existing TLVs
> defined for HMAC. We can add text to indicate this.
>
>
>    - 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?
>
>    - Section 4.2.1 states that
>
> GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines
> another new protocol OWAMP Light. And it is not clear what you reference as
> "this is existing behavior". Is it to reference behavior of TWAMP test
> packet? But the behavior of the TWAMP-Test protocol by itself is neither
> in-band, nor out-of-band. It is the encapsulation of the TWAMP test packet
> that makes it either in-band or out-of-band.
>
>  <RG2> Right.
>
>
>    - 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?
>
> GIM>> So, you believe that proposing to use the method described in RFC
> 8403 for the TWAMP packet is innovation? And what are the benefits of using
> the TWAMP test packet format in the Loopback mode?
>
>    - What is the rationale for setting TTL/Hop Limit fields always to 255
>    for IPv4, MPLS, and IPv6 (per Section 4.3.1)?
>
> GIM>> I believe you've misunderstood the text in RFC 5357. This bullet
> specifies the behavior of a Session-Reflector. It is to try to read TTL
> value of the received TWAMP test packet and copy the value in Sender TTL
> field of the reflected packet. If the Session-Reflector cannot access the
> TTL field, it MUST write 255 in the Sender TTL field. So, I think that my
> questions still remains.
>
>    - 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.
>
> GIM>> I don't think that the reference is sufficient for the
> Securit Consideration. I'd expect some extended discussion on why using
> zero UDP header checksum is not a security threat for *twamp-srpm  protocol.
>
>    - 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.
>
> GIM>> Can you point to a document that has defined "TWAMP  probe messages
> are used today for synthetic packet loss"? Also, which document defines
> loss of connectivity as a performance metric? Does *twamp-srpm proposes to
> use the new protocol to detect the loss of path continuity?
>
>  <RG2> For example Y.1731 has such notion of connection loss. TWAMP is
> used widely for synthetic packet loss and is well-known. There is no change
> in protocol. This is reported 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).
>
> GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The use
> of source IP addresses, as mentioned above, appears to be another security
> risk introduced by *-twamp-srpm drafts.
>
>    - 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?
>
>  <RG2> Yes, they need to be in-band with the flow, to collect the counter
> from the right forwarding paths for the flow. Discussion of using ICMP for
> direct-mode loss measurement is outside the scope of this draft.
>
> GIM2>> I think that the assumption "they need to be in-band with the flow,
> to collect the counter from the right forwarding paths for the flow" is
> technically inaccurate. Otherwise, how SNMP queries could work for decades
> of networking history?
>
>
>
> <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.
>
> GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend
> RFC 4656 OWAMP as well? Also, what you see as the connection between using
> active measurement methods to measure packet delay and packet loss, on one
> hand, and collecting packet counters?
>
>
>
> <RG2> The Session-Sender test-packet is defined in OWAMP RFC and not TWAMP
> RFC. Other than timestamp and its format vs. counter and its format, the
> messages and processing are the same.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
>
>    - 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
>
>  Thanks
>
>
>
>           Gyan
>
>
>
> On Thu, Oct 22, 2020 at 5:51 AM James Guichard <
> [email-masked]> 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.
>
>
>
> [email-masked]
> [email-masked]
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 5 Dec 2020 01:15:20 -0500

Hi Rakesh

Had a general question.

I read through the draft again and a question came to mind as this draft is
Standards Track, what new is being introduced other then a procedure of how
to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane and
SRv6 which used the IPv6 data plane.  I don’t believe there exists  a
Standards track draft procedure for how to use STAMP over IP network or
MPLS network as an example.

Section 4.1.4 describes SR-MPLS use case and SRv6 use case.  As there
appears to be nothing new introduced such as a new IANA TLV or code point
or even a special SID code point  for TWAMP, all basic vanilla SR, that
without this draft you could run STAMP, TWAMP, OWAMP over SR which has
existed for a while now.

What is the new invention here?

Sorry but I may have missed something.

My thoughts are at most this be a BCP or I am thinking informational draft
would be appropriate.

Thoughts?

Gyan

On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky <[email-masked]> wrote:

> <https://www.ietf.org/archive/id/draft-mirmin-bfd-extended-03.txt> we
> build an integrated OAM based on the lightweight Fault Management protocol
> with optional Performance Monitoring, based on RFC 6374. RFC 6374, in turn,
>> On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) <
>> [email-masked]> wrote:
>>
>> On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) <
>> [email-masked]> wrote:
>>
>> 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
>>  Gyan>  This may sound basic but is a very critical subject going down
>> the same lines of clarity in verbiage so their is no misunderstanding.
>> <RG2> Extending ICMP for direct-mode loss measurement is outside the
>> scope of this draft. But good to see the agreement for the direct in band
>> packet loss measurement to be done (albeit by some other means).
>>
>> GIM2>> I feel that you misunderstand my position in regard to the use
>> case these four documents try to solve. I don't recall that I've stated
>> that "direct in-band packet loss measurement" requires any additional
>> <https://www.ietf.org/archive/id/draft-mirmin-bfd-extended-03.txt> in
>> the past tense. The work and discussion of the proposal continues and the
>> new version will be published soon.
>>
>>
>>
>> ·         several parts of the proposed protocol, e.g., Zero UDP
>> checksum in IPv6, require detailed security analysis, which is currently
>> absent;
>>
>>      Gyan> Agreed
>>
>> <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.
>>
>>  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
>> <RG2> The procedure for using the RFC 5357 defined messages in TWAMP
>> Light configuration mode is defined in the corresponding spring drafts. It
>> also describes the provisioning model.
>>
>> GIM>> I think that the text you're proposing is even more confusing. It
>> is not clear which example the sentence is referring to. Also, what is the
>>    - It appears that the last paragraph in the Introduction describes
>>    the relationship with Appendix I of RFC 5357:
>>
>> <RG2> Bidirectional SR tunnel may have an SR state but the statement
>> above is that no PM (i.e. TWAMP Light) protocol session state is created
>> for it. We can clarify in the next revision.
>>
>> 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.
>>
>>  Gyan> Agreed
>>
>> GIM>> I've looked through Section 6 but I don't find anything
>> specifically applicable to this draft we're discussing. If the protocol to
>> use UDP port numbers from the Dynamic ports range, a.k.a., Private or
>> Ephemeral, then it seems that stating that explicitly would be the best
>> way.
>>
>>    <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13>? Would
>>    the TWAMP YANG data model be augmented?
>>
>> GIM>> I think that theremust be some discussion on how the new protocol
>> is configured. If TWAMP YANG data model can be augmented, I'd expect that
>>    - 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?
>>
>>    - Can clarify the applicability of RFC 6038 and the symmetrical
>>    packet size? Is it required? Can it be non-symmetrical?
>>
>>    - Can you clarify the use of the timestamp format, NTP or PTPv2? It
>>    is not clear which is the default, mandatory or optional.
>>
>>    - Also, is "hardware support in Segment Routing networks" of the
>>    PTPv2 format required, guaranteed, or something else?
>>
>>    - And a similar question about the use of the separate UDP port
>>    number for the authenticated of the packet loss measurement.
>>    - What is the rationale for setting TTL/Hop Limit fields always to
>>    255 for IPv4, MPLS, and IPv6 (per Section 4.3.1)?
>>
>> <RG> Other than referring RFC 6936 for zero checksum what else is
>> missing? Otherwise it is no different than RFC 8762 (STAMP).
>>
>> GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The
>> use of source IP addresses, as mentioned above, appears to be another
>> security risk introduced by *-twamp-srpm drafts.
>>
>> GIM2>> I think that the assumption "they need to be in-band with the
>> flow, to collect the counter from the right forwarding paths for the flow"
>> is technically inaccurate. Otherwise, how SNMP queries could work for
>> decades of networking history?
>>
>>
>>
>> --

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 5 Dec 2020 15:32:17 +0000

Hi Gyan,

Thanks for your review comments. Please see inline with <RG4>…

From: Gyan Mishra <[email-masked]>
Date: Saturday, December 5, 2020 at 1:16 AM
To: Greg Mirsky <[email-masked]>
Cc: Greg Mirsky <[email-masked]>, IETF IPPM WG <[email-masked]>, James Guichard <[email-masked]>, Rakesh Gandhi (rgandhi) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
Hi Rakesh

Had a general question.

I read through the draft again and a question came to mind as this draft is Standards Track, what new is being introduced other then a procedure of how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane and SRv6 which used the IPv6 data plane.  I don’t believe there exists  a Standards track draft procedure for how to use STAMP over IP network or MPLS network as an example.

Section 4.1.4 describes SR-MPLS use case and SRv6 use case.  As there appears to be nothing new introduced such as a new IANA TLV or code point or even a special SID code point  for TWAMP, all basic vanilla SR, that without this draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a while now.

<RG4> SPRING drafts define the procedure for using TWAMP Light and STAMP test-messages for SR path and links. The corresponding IPPM drafts define the extensions needed for them. The SPRING drafts also use the extensions for them defined in the corresponding IPPM drafts. The extensions are needed for (1) in-band response request e.g. for two-way mode for links and SR path, (2) Return path for SR e.g. when using bidirectional SR Path, and (3) for collecting TX and RX traffic counters in-band for direct-mode loss measurement.

My thoughts are at most this be a BCP or I am thinking informational draft would be appropriate.

<RG4> Given above context, if WG thinks that any of the drafts should be BCP or Informational or Experimental, we can update the draft accordingly.

Thoughts?

Gyan

On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,
thank you for the continued discussion. You can find my follow-up notes in-line below under GIM3>> tag. I felt that one comment is at the root of our different views on what is considered to be a problem that drafts solve. You've said:
<RG3> As mentioned, the extensions defined are for the direct-mode packet loss measurement for TWAMP Light and STAMP.
But draft-ietf-ippm-stamp-option-tlv<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>, currently in  Submitted to IESG for Publication WG state according to IETF datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in the section:
   The Direct Measurement TLV enables collection of the number of in-
   profile packets, i.e., packets that form a specific data flow, that
   had been transmitted and received by the Session-Sender and Session-
   Reflector, respectively.  The definition of "in-profile packet" is
   outside the scope of this document and is left to the test operators
   to determine.

<RG4>
Hi Greg,
The motivation has been there in the draft-gandhi-ippm-stamp-srpm, Section 1. Copied below for the convenience.

   The STAMP message with a TLV for "direct measurement" can be used for
   combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv<https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00#ref-I-D.ietf-ippm-stamp-option-tlv>].
   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).  Furthermore, for hardware-based counter collection
   for direct-mode loss measurement, the optional TLV based processing
   adds unnecessary overhead (as counters are not at well-known
   locations).

Thus I cannot see any technical need for the introduction of yet another way of direct loss measurement in STAMP. As for the case of TWAMP Light, I believe that there's no sufficient evidence that the proposed direct loss-measurement measurement method benefits existing implementations of TWAMP Light. Also, historically, all extensions applicable to TWAMP Light have been introduced through extending TWAMP proper, i.e., extending TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presented in the drafts we are discussing is, in my opinion, in violation of RFC 5357.

<RG4> The IPPM WG Informational draft on TWAMP Light direct-mode loss measurement, defines the message format and corresponding SPRING draft defines the procedure for using that. It is not clear to me how providing an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357.

Thanks,
Rakesh

Regards,
Greg

On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
GIM3>> As you've recognized, in draft-mirmin-bfd-extended<https://www.ietf.org/archive/id/draft-mirmin-bfd-extended-03.txt> we build an integrated OAM based on the lightweight Fault Management protocol with optional Performance Monitoring, based on RFC 6374. RFC 6374, in turn, provides a rich set of performance measurement methods, including direct loss measurement.
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
To: Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>>
Cc: Gyan Mishra <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG <[email-masked]<mailto:[email-masked]>>, James Guichard <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>

GIM3>> Clarification would be very helpful as your latest note might be interpreted that the proposed mechanisms are not applicable in the case of a bi-directional SR tunnel.

•         several parts of the proposed protocol, e.g., Zero UDP checksum in IPv6, require detailed security analysis, which is currently absent;

•         I believe that draft-gandhi-spring-twamp-srpm should be anchored at IPPM WG as it does introduce the new PM protocol.

GIM3>> RFCs 5357 and 8762 are clear about what information must be maintained by a Session-Reflector. The Session-Reflector must have knowledge of the test session state and count reflected test packets. The value of such a counter must be copied in the Sequence Number field of the reflected packet. Thus the method enables the measurement of the one-way packet loss metric.

•         Further, in Section 3 the selection of UDP port explained as the following:

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 5 Dec 2020 14:22:55 -0500

Hi Rakesh

Please see in-line

On Sat, Dec 5, 2020 at 10:32 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> *Date: *Saturday, December 5, 2020 at 1:16 AM
> *Cc: *Greg Mirsky <[email-masked]>, IETF IPPM WG <[email-masked]>,
> James Guichard <[email-masked]>, Rakesh Gandhi (rgandhi) <
> I read through the draft again and a question came to mind as this draft
> is Standards Track, what new is being introduced other then a procedure of
> how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane
> and SRv6 which used the IPv6 data plane.  I don’t believe there exists  a
> <RG4> SPRING drafts define the procedure for using TWAMP Light and STAMP
> test-messages for SR path and links. The corresponding IPPM drafts define
> the extensions needed for them. The SPRING drafts also use the extensions
> for them defined in the corresponding IPPM drafts. The extensions are
> needed for (1) in-band response request e.g. for two-way mode for links and
> SR path, (2) Return path for SR e.g. when using bidirectional SR Path, and
> (3) for collecting TX and RX traffic counters in-band for direct-mode loss
> measurement.
>
>  Gyan> Understood.  Just to see if a precedence has already been set if
> you point me another case where Spring or any other WG RFC Standards Track
> that  has defined procedures to use IPPM extensions.  If this is the first
> and may also set a new precedent,  I think it’s a valid WG discussion.
>
> <RG4> Given above context, if WG thinks that any of the drafts should be
> BCP or Informational or Experimental, we can update the draft accordingly.
>
> Gyan> Agreed.  Thank you
>
> Thoughts?
>
>
>
> Gyan
>
>
>
>    combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv
> <https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00#ref-I-D.ietf-ippm-stamp-option-tlv>
> ].
>
> <RG4> The IPPM WG Informational draft on TWAMP Light direct-mode loss
> measurement, defines the message format and corresponding SPRING draft
> defines the procedure for using that. It is not clear to me how providing
> an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> GIM>> So, you believe that proposing to use the
>
> --

*Gyan Mishra*