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

[Gyan Mishra <[e-mail]>]

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 <[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.
> 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) <[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 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?
>>
>>
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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