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

[Gyan Mishra <[e-mail]>]

Hi Rakesh

Please see in-line

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

> Hi Gyan,
>
>
>
> Thanks for your review comments. Please see inline with <RG4>…
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Saturday, December 5, 2020 at 1:16 AM
> *To: *Greg Mirsky <[e-mail]>
> *Cc: *Greg Mirsky <[e-mail]>, IETF IPPM WG <[e-mail]>,
> James Guichard <[e-mail]>, Rakesh Gandhi (rgandhi) <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> *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.
>
>
>
> What is the new invention here?
>
>
>
> <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.
>
> 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.
>
>
>
> <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
>
>
>
> On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky <[e-mail]> 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
>
>
>
>
>
> More notes can be found below.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) <[e-mail]>
> wrote:
>
> 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).*
>
> 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.
>
> Please see replies inline with <RG3>….
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Monday, November 30, 2020 at 11:30 AM
> *To: *Rakesh Gandhi (rgandhi) <[e-mail]>
> *Cc: *Gyan Mishra <[e-mail]>, IETF IPPM WG <[e-mail]>,
> James Guichard <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, Greg Mirsky <[e-mail]>
> *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) <[e-mail]>
> wrote:
>
> Thank you Gyan and Greg for your review comments and discussions. Please
> see inline replies with <RG2>…
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Wednesday, November 25, 2020 at 12:34 PM
> *To: *Greg Mirsky <[e-mail]>
> *Cc: *IETF IPPM WG <[e-mail]>, James Guichard <
> [e-mail]>, Rakesh Gandhi (rgandhi) <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> *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 <[e-mail]> 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) <[e-mail]>
> wrote:
>
> Thank you Greg for taking time for thoroughly reviewing the documents and
> providing the comments.
>
> Please see replies inline with <RG>…
>
> *From: *ippm <[e-mail]>
> *Date: *Friday, November 6, 2020 at 11:18 AM
> *To: *James Guichard <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> IETF IPPM WG <[e-mail]>
> *Subject: *Re: [ippm] [spring] WG Adoption Call for
> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11
>
> Dear Chairs of the SPRING and IPPM WGs, Authors, et al.,
>
> I've found myself in the situation when two related drafts are in the WG
> APs in the SPRING and IPPM WG (with the possibility that expertise from the
> third WG, BFD WG, might be desirable to review the "liveness monitoring").
> Because these drafts are closely related, I've decided to combine my
> questions and comments in a single thread. I hope that would be acceptable
> and considered by the SPRING WG as well as IPPM WG.
>
> Usually, the bar for the adoption of a document can be evaluated by
> answers to these three questions:
>
>    - Is the document(s) reasonably well-written
>
> I've got surprised that the drafts don't use the terminology from RFC 4656
> and 5357 and introduce their own terminology for Session-Sender and
> Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are
> used in the documents without proper definitions. Other than that both
> drafts are readable and reasonably well-written.
>
> <RG> We are ok to change Sender to Session-Sender and Reflector to
> Session-Reflector if it helps.
>
>
>
> 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.
>
> 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.
>
>      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.
>
> 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.
>
>  <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
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



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