Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

From: "Richard Vallee (rvallee)" <[email-masked]>
Date: Mon, 9 Nov 2020 13:57:31 +0000

I support the adoption of these documents

Thanks
Richard

From: ippm <[email-masked]> on behalf of Tommy Pauly <tpauly=[email-masked]>
Date: Friday, October 30, 2020 at 2:35 PM
To: "IETF IPPM WG ([email-masked])" <[email-masked]>
Cc: IPPM Chairs <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

Hello IPPM,

For the past few meetings, we’ve had updates on the work in the SPRING WG that was using STAMP and TWAMP. Since those documents ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be best to split the documents and track the IPPM extension work in the IPPM WG.

As such, we are starting a Working Group call for adoption for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.

The documents are here:

https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00
https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00

The related SPRING documents are here:

https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Please provide your feedback on these documents, and state whether or not you believe the IPPM WG should adopt this work by replying to this email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.

Best,
Tommy & Ian

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 17 Nov 2020 14:27:25 -0800

Hi Rakesh, WG Chairs, and All,
I've read the responses to my detailed comments. I don't think that only
adding references will solve the problems with the documents. If authors
are interested in addressing my comments, we can start working on
solving them one by one. But I am very much concerned with the technical
value of these drafts. And here's why I feel that the proposed documents
don't provide a sound technical solution to the task of direct loss
measurement. Please find my reasoning explaining my opinion of the
*-twamp-srpm and *-stamp-srpm:

   - What is being proposed in these drafts?

Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support
direct packet loss measurements. Note, that RFC 6374 includes a method for
direct loss measurement in MPLS networks that is applicable to the SR-MPLS
environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to
RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct packet
loss measurement. STAMP and all its extensions are applicable in IPv6
networks and, thus, can be used in the SRv6 domain.

   - How the proposed method of direct packet loss is related to TWAMP
   light and STAMP?

There's no apparent technical relationship between *-twamp-srpm and TWAMP
Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the
basic mechanisms defined for  TWAMP-Test and/or STAMP in their respective
specifications. Rather than that, drafts introduce a new query-response
mode and new formats of test packets that are decisively different from the
formats defined in respective specifications. As a result, the new
protocols are required to use different from used by TWAMP Light tr STAMP
test session UDP port numbers on the responder. And that is another clear
indication that the proposed mechanism represents a new protocol, neither
extends TWAMP Light and/or STAMP nor updates their specifications.

   - Is there any advantage in introducing a dedicated packet format for
   the direct packet loss in STAMP comparing to using the Direct Measurement
   TLV extension?

Though it appears the using a dedicated packet format instead of TLV is
more efficient, but the dedicated for the direct loss measurement format is
likely to precede one or even two TLVs, Node Address TLV and Path TLV,
defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new
packet with TLVs is unlikely to be more efficient and reduce the processing
delay, than if using the Direct Measurement TLV as defined in
draft-ietf-ippm-stamp-option-tlv.

   - What are the potential benefits of specifying the return path in the
   new test packet's Sender Control Code?

Using the Sender Control Code may require the use of the additional TLV
that carries the return path information, Path TLV. If the ability to
control the return path is required that can be achieved by augmenting the
STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including
the Path TLV in each test packet. Hence, there seem no technical
requirements to introduce the Sender Control Code field in the Base STAMP
format defined in RFC 8762.

   - What is the relationship between the *-srpm drafts and BFD?

Some text in the *-srpm drafts suggest that the proposed method can be
used to monitor for the loss of a path continuity. That may be viewed as an
alternative to the BFD protocol method for the detection of a network
failure. If the discussion of Loopback mode and monitoring of liveness
remain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs
be made aware of the proposals. I didn't take the liberty of adding BFD WG
or its Chairs. I believe that decision to be made by the Chairs of IPPM And
SPRING WGs.

Regards,

On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <[email-masked]> wrote:

> Hi Rakesh,
> thank you for your prompt response, much appreciated. I'll carefully read
> your responses. Looking forward to the continued discussion.
>
> Regards,
> Greg
>
> On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) <
> [email-masked]> wrote:
>
>> Hi Greg,
>>
>>
>>
>> Thank you for your review comments. As mentioned in the IPPM session
>> today, the email response was sent as attachments, see archive blow:
>>
>> https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/
>>
>>
>>
>> I am attaching them in word documents for the convenience. We can address
>> your comments below in the next revision of the document.
>>
>>
>>
>> Thanks,
>>
>> Rakesh
>>
>>
>>
>>
>>
>> *From: *Greg Mirsky <[email-masked]>
>> *Date: *Friday, November 13, 2020 at 10:09 AM
>> *To: *Rakesh Gandhi (rgandhi) <[email-masked]>
>> *Cc: *Tommy Pauly <tpauly=[email-masked]>, IPPM Chairs <
>> [email-masked]>, [email-masked] <[email-masked]>,
>> IETF IPPM WG ([email-masked]) <[email-masked]>
>> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm
>> and draft-gandhi-ippm-stamp-srpm
>>
>> Hi Rakesh,
>>
>> thank you for your response to my review. Please find my follow-up notes
>> in-lined below under the GIM>> tag.
>>
>> I hope you've found more detailed comments in the attachments
>> (re-attached for your convenience). I'm looking forward to reading your
>> responses to the detailed comments of all four drafts.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <
>> [email-masked]> wrote:
>>
>> Thank you Greg for taking time for thoroughly reviewing the documents and
>> providing the comments.  Attached please find the email replies to your
>> review sent earlier.  The replies are copied inline below for convenience,
>> tagged with <RG00>.
>>
>>
>>
>>
>>
>> *From: *ippm <[email-masked]>
>> *Date: *Monday, November 9, 2020 at 11:48 AM
>> *To: *Tommy Pauly <tpauly=[email-masked]>
>> *Cc: *IPPM Chairs <[email-masked]>, [email-masked] <
>> [email-masked]>, IETF IPPM WG ([email-masked]) <[email-masked]>
>> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm
>> and draft-gandhi-ippm-stamp-srpm
>>
>> Dear WG Chairs, Authors, and IPPM WG community,
>>
>> I've reviewed these drafts and have some comments to share. Below, please
>> find my thoughts on whether these drafts can be adopted. More specific
>> comments on each pair of drafts (TWAMP-related and STAMP-related draft and
>> its accompanying draft targetted to the SPRING WG) are in the attached
>> documents.
>>
>>
>>
>> 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 RFCs
>> 4656/5357 and RFC 8762, 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.
>>
>>
>>
>> <RG00> We can change Sender to Session-Sender and Reflector to
>> Session-Reflector if it helps.
>>
>> GIM>> I believe that the consistency in terminology between the core RFC
>> 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.
>>
>> <RG00> There are many existing RFCs that use term Link (e.g. RFC 5613,
>> 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without
>> defining them. I suspect it is because these are well-known terms. Having
>> said that, we can add a reference for them if it helps.
>>
>> GIM>> Thank you for 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. 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", path A-B-G-H-E-F is
>> congruent to the SR tunnel. But a packet of an active OAM intended to
>> monitor a flow over the SR tunnel is out-of-band and will not produce any
>> meaningful measurement. Of course, for the case of the extensions in
>> drafts, direct loss measurement can be performed, as information collected
>> from node F. So, this example, in my opinion, illustrates two of my
>> concerns:
>>
>>    - using a congruent path for an active OAM protocol may produce
>>    information that does not reflect the condition experienced by the
>>    monitored flow. It seems that the terminology should reflect the
>>    fundamental requirement for using active OAM to maintain the test packets
>>    in-band with the monitored flow.
>>    - there are no technical requirements to justify using in-band active
>>    OAM protocol for direct packet loss measurement. 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  both TWAMP and STAMP drafts  define a new
>> performance measurement protocol for the purpose of combining OWAMP/TWAMP
>> and STAMP functionality in the respective drafts, 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 multi-part message
>> extension per RFC 4884.
>>
>>
>>
>> <RG00> There is a requirement to measure performance delay as well as
>> synthetic and direct-mode packet loss in segment-routing networks. OWAMP
>> and TWAMP protocols are widely deployed for performance delay and synthetic
>> packet loss measurement today. I am not sure extending ICMP for LM is a
>> good option here.
>>
>> GIM>> 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/STAMP for exclusive direct
>> packet loss measurement.
>>
>>
>>
>> ·  Is the proposed solution technically viable?
>>
>> There are too many unaddressed aspects, particularly the risk introduced
>> by the protocols on network security, to comprehensively evaluate the
>> proposed solutions.
>>
>>
>>
>> <RG00> About your comment on zero checksum, this is described in Security
>> section in RFC 6936. We will add reference to this RFC in our Security
>> Section as well. This is only specific to the UDP port locally provisioned
>> in the domain by the operator for STAMP or TWAMP Light. Other than this, I
>> did not find any other security related issue in your review.
>>
>> 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.
>>
>>
>>
>> Thanks,
>>
>> Rakesh
>>
>>
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly=
>> [email-masked]> wrote:
>>
>> Hello IPPM,
>>
>>
>>
>> For the past few meetings, we’ve had updates on the work in the SPRING WG
>> that was using STAMP and TWAMP. Since those documents ended up making
>> extensions to the base protocols, the chairs of SPRING and IPPM decided
>> that it would be best to split the documents and track the IPPM extension
>> work in the IPPM WG.
>>
>>
>>
>> As such, we are starting a Working Group call for adoption
>> for draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.
>>
>>
>>
>> The documents are here:
>>
>> Please provide your feedback on these documents, and state whether or not
>> you believe the IPPM WG should adopt this work by replying to this email.
>> Please provide your feedback by the start of the IETF 109 meeting week, on *Monday,
>> November 16*.
>>
>>
>>
>> Best,
>>
>> Tommy & Ian
>>
>> _______________________________________________
>> ippm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 17 Nov 2020 23:40:40 +0000

Hi Greg,

Thank you for your review and discussions on the drafts. This will help improve the work on this important work.
Please see replies inline with <RG>..

From: Greg Mirsky <[email-masked]>
Date: Tuesday, November 17, 2020 at 5:27 PM
To: Rakesh Gandhi (rgandhi) <[email-masked]>
Cc: Tommy Pauly <tpauly=[email-masked]>, IPPM Chairs <[email-masked]>, [email-masked] <[email-masked]>, IETF IPPM WG ([email-masked]) <[email-masked]>, spring <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Rakesh, WG Chairs, and All,
I've read the responses to my detailed comments. I don't think that only adding references will solve the problems with the documents. If authors are interested in addressing my comments, we can start working on solving them one by one.

<RG> As mentioned in previous replies, we can add references for the well-known terms “Links”, “Congruent Paths”, “SR Path”. If you prefer, we can define them here. For Zero checksum field, we can add a reference for the RFC 6936 in Security section and also add some text for it. Will be happy to work with you to address these.

But I am very much concerned with the technical value of these drafts. And here's why I feel that the proposed documents don't provide a sound technical solution to the task of direct loss measurement. Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

  *   What is being proposed in these drafts?
Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support direct packet loss measurements. Note, that RFC 6374 includes a method for direct loss measurement in MPLS networks that is applicable to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, the Direct Measurement TLV, that supports the direct packet loss measurement. STAMP and all its extensions are applicable in IPv6 networks and, thus, can be used in the SRv6 domain.

<RG> As mentioned in previous replies, both RFC 6374 (in Section 4.2) and ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX and RX counters for direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that take advantage of the widely deployed TWAMP protocol and as well this same protocol can be deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.

  *   How the proposed method of direct packet loss is related to TWAMP light and STAMP?
There's no apparent technical relationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the basic mechanisms defined for  TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mode and new formats of test packets that are decisively different from the formats defined in respective specifications. As a result, the new protocols are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responder. And that is another clear indication that the proposed mechanism represents a new protocol, neither extends TWAMP Light and/or STAMP nor updates their specifications.

<RG> As mentioned in previous replies, other than timestamp vs. counter and it’s format, the messages and processing of them are the same for delay and direct-mode loss measurement.

  *   Is there any advantage in introducing a dedicated packet format for the direct packet loss in STAMP comparing to using the Direct Measurement TLV extension?
Though it appears the using a dedicated packet format instead of TLV is more efficient, but the dedicated for the direct loss measurement format is likely to precede one or even two TLVs, Node Address TLV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with TLVs is unlikely to be more efficient and reduce the processing delay, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-stamp-option-tlv.

<RG> As mentioned in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/>. For link loss measurement (direct-mode), there is no TLV required for example. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss measurement (and not bidirectional).

  *   What are the potential benefits of specifying the return path in the new test packet's Sender Control Code?
Using the Sender Control Code may require the use of the additional TLV that carries the return path information, Path TLV. If the ability to control the return path is required that can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each test packet. Hence, there seem no technical requirements to introduce the Sender Control Code field in the Base STAMP format defined in RFC 8762.

<RG> Per session basis between different sender nodes and this reflector node, some senders will request the replies in-band (e.g. for two-way mode). Sessions are provisioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for a bidirectional SR path). This is also similar to as described Section 3.1 in RFC 6374, top of page 22. There is no need to create a such state for each session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scale limitation by eliminating the Control protocol signaling.

  *   What is the relationship between the *-srpm drafts and BFD?
Some text in the *-srpm drafts suggest that the proposed method can be used to monitor for the loss of a path continuity. That may be viewed as an alternative to the BFD protocol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness remain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs be made aware of the proposals. I didn't take the liberty of adding BFD WG or its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs.

<RG> As mentioned in previous replies, STAMP/TWAMP test messages are also used today for synthetic packet loss measurement which can be also used to detect/monitor connection loss (performance metric). The draft simply highlights this obvious metric. This is also very similar to what is described in ITU Y.1731, Section 7.1.

Thanks,
Rakesh

Regards,

On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,
thank you for your prompt response, much appreciated. I'll carefully read your responses. Looking forward to the continued discussion.

Regards,
Greg

On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thank you for your review comments. As mentioned in the IPPM session today, the email response was sent as attachments, see archive blow:
https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/

I am attaching them in word documents for the convenience. We can address your comments below in the next revision of the document.

Thanks,
Rakesh

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 13, 2020 at 10:09 AM
To: Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>>
Cc: Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>>, IPPM Chairs <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Rakesh,
thank you for your response to my review. Please find my follow-up notes in-lined below under the GIM>> tag.
I hope you've found more detailed comments in the attachments (re-attached for your convenience). I'm looking forward to reading your responses to the detailed comments of all four drafts.

Regards,
Greg

On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Greg for taking time for thoroughly reviewing the documents and providing the comments.  Attached please find the email replies to your review sent earlier.  The replies are copied inline below for convenience, tagged with <RG00>.

From: ippm <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 9, 2020 at 11:48 AM
To: Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>>
Cc: IPPM Chairs <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Dear WG Chairs, Authors, and IPPM WG community,
I've reviewed these drafts and have some comments to share. Below, please find my thoughts on whether these drafts can be adopted. More specific comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying draft targetted to the SPRING WG) are in the attached documents.

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 RFCs 4656/5357 and RFC 8762, 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.

<RG00> We can change Sender to Session-Sender and Reflector to Session-Reflector if it helps.
GIM>> I believe that the consistency in terminology between the core RFC 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.
<RG00> There are many existing RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we can add a reference for them if it helps.
GIM>> Thank you for 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. 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", path A-B-G-H-E-F is congruent to the SR tunnel. But a packet of an active OAM intended to monitor a flow over the SR tunnel is out-of-band and will not produce any meaningful measurement. Of course, for the case of the extensions in drafts, direct loss measurement can be performed, as information collected from node F. So, this example, in my opinion, illustrates two of my concerns:

  *   using a congruent path for an active OAM protocol may produce information that does not reflect the condition experienced by the monitored flow. It seems that the terminology should reflect the fundamental requirement for using active OAM to maintain the test packets in-band with the monitored flow.
  *   there are no technical requirements to justify using in-band active OAM protocol for direct packet loss measurement. 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  both TWAMP and STAMP drafts  define a new performance measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP functionality in the respective drafts, 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 multi-part message extension per RFC 4884.

<RG00> There is a requirement to measure performance delay as well as synthetic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measurement today. I am not sure extending ICMP for LM is a good option here.
GIM>> 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/STAMP for exclusive direct packet loss measurement.

•  Is the proposed solution technically viable?
There are too many unaddressed aspects, particularly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

<RG00> About your comment on zero checksum, this is described in Security section in RFC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for STAMP or TWAMP Light. Other than this, I did not find any other security related issue in your review.
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.

Thanks,
Rakesh

Regards,
Greg

On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> wrote:
Hello IPPM,

The documents are here:

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 19 Nov 2020 05:33:19 +0000

Hi Rakesh and Greg,

I may not very clear about the context. Please allow me to jump in.
It seems both of you make some valid point.
Please see in line with <ZTR>.

Cheers,
Tianran

From: spring [mailto:[email-masked]] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky <[email-masked]>
Cc: spring <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

Hi Greg,

Cc: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>, IPPM Chairs <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>

<RG> As mentioned in previous replies, we can add references for the well-known terms "Links", "Congruent Paths", "SR Path". If you prefer, we can define them here. For Zero checksum field, we can add a reference for the RFC 6936 in Security section and also add some text for it. Will be happy to work with you to address these.

<ZTR> I think RFC6374 for MPLS and Y.1731 make some noise here. The point is if we need a new direct packet loss measurement for STAMP, when STAMP already defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement, then how about proposing a new TLV.

<RG> As mentioned in previous replies, other than timestamp vs. counter and it's format, the messages and processing of them are the same for delay and direct-mode loss measurement.

<ZTR> I find some value to include the path TLV in wire. As Rakesh mentioned, this can reduce the reflector configuration. But I am not convinced to introduce the sender control code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa.

Thanks,
Rakesh

Regards,

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

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 RFCs 4656/5357 and RFC 8762, 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.

*  Does the document solve a real problem?
No, it appears that  both TWAMP and STAMP drafts  define a new performance measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP functionality in the respective drafts, 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 multi-part message extension per RFC 4884.

*  Is the proposed solution technically viable?
There are too many unaddressed aspects, particularly the risk introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

Thanks,
Rakesh

Regards,
Greg

For the past few meetings, we've had updates on the work in the SPRING WG that was using STAMP and TWAMP. Since those documents ended up making extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be best to split the documents and track the IPPM extension work in the IPPM WG.

The documents are here:

Best,
Tommy & Ian

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Nov 2020 21:53:24 -0800

Hi Tianran,
thank you for sharing your perspective on the *-SRPM drafts and the
discussion, it is very refreshing and thought-provoking. I believe that
you've hit the nail on the head by pointing to what is missing from the
discussion - the agreed by the WGs set of the requirements. I absolutely
agree with you, without a clear understanding of the requirements documents
appear as a solution that is looking for a problem to be solved. Instead of
discussing issues with the proposed new protocol, it may be helpful to take
a step back and discuss requirements. For example, how to evaluate the
efficiency of different methods of direct packet loss measurement. Or, as
you've pointed out, compare the pros and cons of configuring metadata for
the duration of a test session vs. carrying metadata in each test packet.
And, as was noted by other reviewers of the drafts, the requirements are
likely to be applicable not only to a Segment Routing but to a network in
general.

Regards,
Greg

On Wed, Nov 18, 2020 at 9:33 PM Tianran Zhou <[email-masked]> wrote:

> *From:* spring [mailto:[email-masked]] *On Behalf Of *Rakesh
> Gandhi (rgandhi)
> *Sent:* Wednesday, November 18, 2020 7:41 AM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* spring <[email-masked]>; IPPM Chairs <[email-masked]>;
> [email-masked]; Tommy Pauly <tpauly=[email-masked]>;
> *Subject:* Re: [spring] [ippm] Call for adoption:
> draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
>
>
>
> Hi Greg,
>
>
>
> *Date: *Tuesday, November 17, 2020 at 5:27 PM
> IETF IPPM WG ([email-masked]) <[email-masked]>, spring <[email-masked]>
> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and
> draft-gandhi-ippm-stamp-srpm
>
> solving them one by one.
> <RG> As mentioned in previous replies, we can add references for the
> well-known terms “Links”, “Congruent Paths”, “SR Path”. If you prefer, we
> can define them here. For Zero checksum field, we can add a reference for
> the RFC 6936 in Security section and also add some text for it. Will be
> happy to work with you to address these.
>
>
>
> But I am very much concerned with the technical value of these drafts. And
> here's why I feel that the proposed documents don't provide a sound
> technical solution to the task of direct loss measurement. Please find my
> reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:
>
> <RG> As mentioned in previous replies, both RFC 6374 (in Section 4.2) and
> ITU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX
> and RX counters for direct-mode loss measurement. TWAMP/STAMP messages
> defined in the drafts are equivalent of them that take advantage of the
> widely deployed TWAMP protocol and as well this same protocol can be
> deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.
>
>
>
> <ZTR> I think RFC6374 for MPLS and Y.1731 make some noise here. The point
> is if we need a new direct packet loss measurement for STAMP, when STAMP
> already defined a Direct Measurement TLV (
> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If
> current Direct Measurement TLV cannot fulfill some use case requirement,
> then how about proposing a new TLV.
>
> <RG> As mentioned in previous replies, other than timestamp vs. counter
> and it’s format, the messages and processing of them are the same for delay
> and direct-mode loss measurement.
>
> <RG> As mentioned in previous replies, this is explained in Section 1 of
> the draft-gandhi-spring-stamp-srpm
> <https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/>. For
> link loss measurement (direct-mode), there is no TLV required for example.
> For direct-mode loss measurement in SR networks, it would *typically* be
> forward direction packet loss measurement (and not bidirectional).
>
>
>
>
>
> ·         What are the potential benefits of specifying the return path
> in the new test packet's Sender Control Code?
>
> <RG> Per session basis between different sender nodes and this reflector
> node, some senders will request the replies in-band (e.g. for two-way
> mode). Sessions are provisioned on the Sender nodes and reflector simply
> reflects based on the received test-packet (e.g. for a bidirectional SR
> path). This is also similar to as described Section 3.1 in RFC 6374, top of
> page 22. There is no need to create a such state for each session on the
> reflector node and create a scale limitation. Recall that we are trying to
> avoid the scale limitation by eliminating the Control protocol signaling.
>
>
>
> <ZTR> I find some value to include the path TLV in wire. As Rakesh
> mentioned, this can reduce the reflector configuration. But I am not
> convinced to introduce the sender control code field. It seems to me, the
> presence of path TLV indicates the bidirectional congruent path. Vise
> versa.
>
> <RG> As mentioned in previous replies, STAMP/TWAMP test messages are also
> used today for *synthetic* packet loss measurement which can be also used
> to detect/monitor connection loss (performance metric). The draft simply
> highlights this obvious metric. This is also very similar to what is
> described in ITU Y.1731, Section 7.1.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
> Regards,
>
>
>
>
>
> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and
> draft-gandhi-ippm-stamp-srpm
>
> Hi Rakesh,
>
> I hope you've found more detailed comments in the attachments (re-attached
> for your convenience). I'm looking forward to reading your responses to the
> detailed comments of all four drafts.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <[email-masked]>
> wrote:
>
> *Subject: *Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and
> draft-gandhi-ippm-stamp-srpm
>
> <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

---

From: Mach Chen <[email-masked]>
Date: Thu, 19 Nov 2020 07:41:11 +0000

Hi Tianran, Rakesh and Greg,

Please see some responses inline with [Mach]...

From: ippm [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Thursday, November 19, 2020 1:33 PM
To: Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]>; Greg Mirsky <[email-masked]>
Cc: spring <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

Hi Rakesh and Greg,

Cheers,
Tianran

From: spring [mailto:[email-masked]] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: spring <[email-masked]<mailto:[email-masked]>>; IPPM Chairs <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

Hi Greg,

[Mach] Given that TWAMP does not support TLV, I assume that the discussions are mainly about draft*-stamp-srpm.

[Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-stamp-srpm assumes that marking-based solution (which can address the packet out-ordering issue) is used, hence the block number is introduced. The block number is used to correlate the counters from the sender and reflector. The current direct loss measurement TLV may just apply to the scenario without packet out-ordering.

[Mach] In addition, whether to keep it as current design or to define a new TLV for direct loss measurement can be debatable.

How the proposed method of direct packet loss is related to TWAMP light and STAMP?
There's no apparent technical relationship between *-twamp-srpm and TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the basic mechanisms defined for  TWAMP-Test and/or STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mode and new formats of test packets that are decisively different from the formats defined in respective specifications. As a result, the new protocols are required to use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responder. And that is another clear indication that the proposed mechanism represents a new protocol, neither extends TWAMP Light and/or STAMP nor updates their specifications.

[Mach] Regarding how to specify the return path, the draft defines two ways to achieve that, one is to use control code to direct whether the reflected Test should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the case of STAMP, it also defines the return path TLV to explicitly specify the return path, which bring more options to specify the return path. Therefore, I see benefit of the two ways.

Best regards,
Mach

What is the relationship between the *-srpm drafts and BFD?
Some text in the *-srpm drafts suggest that the proposed method can be used to monitor for the loss of a path continuity. That may be viewed as an alternative to the BFD protocol method for the detection of a network failure. If the discussion of Loopback mode and monitoring of liveness remain in the drafts, it seems logical that the BFD WG and BFD WG's Chairs be made aware of the proposals. I didn't take the liberty of adding BFD WG or its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs.

Thanks,
Rakesh

Regards,

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

The documents are here:

Best,
Tommy & Ian

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 19 Nov 2020 15:15:26 +0000

Thank you Mach and Tianran for your review comments.
Please see inline reply with <RG2>…

From: Mach Chen <[email-masked]>
Date: Thursday, November 19, 2020 at 2:41 AM
To: Tianran Zhou <[email-masked]>, Rakesh Gandhi (rgandhi) <[email-masked]>, Greg Mirsky <[email-masked]>
Cc: spring <[email-masked]>, IPPM Chairs <[email-masked]>, [email-masked] <[email-masked]>, Tommy Pauly <[email-masked]>, IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Tianran, Rakesh and Greg,

Please see some responses inline with [Mach]…

Hi Rakesh and Greg,

Cheers,
Tianran

Hi Greg,

<RG2> To further add to this,  as TWAMP Light does not have a TLV, we need to define a stand-alone message for direct-mode LM. STAMP is just the same message but fixed length, so this way both can interoperate and also we can leverage the message for both of these protocols.

For STAMP direct-mode LM TLV approach, some technical details are in the draft as well:

   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 for one-way delay).  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).

<RG2> To further add to this, the IPPM draft simply defines protocol extensions. The use-cases are there in the corresponding spring drafts. For example, for links, no return Path TLV is used, etc. In other words, the use-cases are different for the two, and there is no TLV in TWAMP anyways.

Thanks,
Rakesh

Best regards,
Mach

Thanks,
Rakesh

Regards,

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

The documents are here:

Best,
Tommy & Ian

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Nov 2020 09:27:11 -0800

Hi Mach,
thank you for your email. I've added my understanding of what has been
proposed in-line tagged GIM>>.

Regards,
Greg

On Wed, Nov 18, 2020 at 11:41 PM Mach Chen <[email-masked]> wrote:

> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Tianran Zhou
> *Sent:* Thursday, November 19, 2020 1:33 PM
> *To:* Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]>; Greg
> Mirsky <[email-masked]>
> *Subject:* Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and
> *From:* spring [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Rakesh Gandhi (rgandhi)
> [Mach] Given that TWAMP does not support TLV, I assume that the
> discussions are mainly about draft*-stamp-srpm.
>
GIM>> You've brought a very good question on how the return path, in case
required by the Sender Control Code, introduced
in draft-gandhi-ippm-twamp-srpm, is specified? As you've pointed out, RFC
5357 does not use TLV extensions. Should I assume that the return path, if
required, provisioned through the management plane? I think that that
requires clarification.

>
>
> [Mach] In the case of direct packet loss measurement,
> draft-gandhi-ippm-stamp-srpm assumes that marking-based solution (which can
> address the packet out-ordering issue) is used, hence the block number is
> introduced. The block number is used to correlate the counters from the
> sender and reflector. The current direct loss measurement TLV may just
> apply to the scenario without packet out-ordering.
>
GIM>> I agree with your observation on the purpose of the Block Number
field in both TWAMP-Light and STAMP documents. In my understanding, the new
protocol may be also used to collect counters generated by methods other
than Alternate Marking. In that case, I assume, the value of Block Number
may not convey any information.

>
>
> [Mach] In addition, whether to keep it as current design or to define a
> new TLV for direct loss measurement can be debatable.
>
GIM>> I agree with you. And that what I am proposing - review the
requirements, agree on requirements, and review the proposed solution based
on these requirements.

> [Mach] Regarding how to specify the return path, the draft defines two
> ways to achieve that, one is to use control code to direct whether the
> reflected Test should be along the reverse path of a bidirectional path,
> this applies to both TWAMP (no TLV mechanisms) and STAMP. At the same time,
> in the case of STAMP, it also defines the return path TLV to explicitly
> specify the return path, which bring more options to specify the return
> path. Therefore, I see benefit of the two ways.
>
GIM>> I think you've pointed to some vagueness in the definition of a
mechanism used to define the return path. My understanding is that if a
response required, the Return Path TLV must be present in a test packet.
But, if TLVs are not used for TWAMP-like direct loss measurement, why not
use the same method to control the return path? I believe that consistency
is a good quality of a protocol (yes, I see *-twamp-srpm and *-stmp-srpm as
a single protocol only presented as different entities).

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 20 Nov 2020 01:28:00 +0000

Hi Mach and Rakesh,

Thanks for your reply. I am now much more clear.
But I really think the draft should add more text on the motivation and use case.  It would be very helpful for the audience to understand.
For example, one of my question about the new direct measurement.
There is rare word on how to use it, how it's different from existing stamp direct measurement tlv.
Anyway, I find some valuable extensions in these two drafts. I would like to support the adoption and help to improve this document.

Best,
Tianran

From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
Sent: Thursday, November 19, 2020 11:15 PM
To: Mach Chen <[email-masked]>; Tianran Zhou <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: spring <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; Tommy Pauly <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

Thank you Mach and Tianran for your review comments.
Please see inline reply with <RG2>...

From: Mach Chen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 19, 2020 at 2:41 AM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: spring <[email-masked]<mailto:[email-masked]>>, IPPM Chairs <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Tommy Pauly <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Tianran, Rakesh and Greg,

To: Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]<mailto:rgandhi=[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>

Hi Rakesh and Greg,

Cheers,
Tianran

Hi Greg,

Thanks,
Rakesh

Best regards,
Mach

Thanks,
Rakesh

Regards,

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

The documents are here:

Best,
Tommy & Ian

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 20 Nov 2020 06:13:18 +0000

Thanks Tianran for the review comments. We will address the comment in the next revision of the document.

Thanks,
Rakesh

From: Tianran Zhou <[email-masked]>
Date: Thursday, November 19, 2020 at 8:28 PM
To: Rakesh Gandhi (rgandhi) <[email-masked]>, Mach Chen <[email-masked]>, Greg Mirsky <[email-masked]>
Cc: spring <[email-masked]>, IPPM Chairs <[email-masked]>, [email-masked] <[email-masked]>, Tommy Pauly <[email-masked]>, IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Mach and Rakesh,

There is rare word on how to use it, how it’s different from existing stamp direct measurement tlv.

Best,
Tianran

Hi Rakesh and Greg,

Cheers,
Tianran

Hi Greg,

Thanks,
Rakesh

Best regards,
Mach

Thanks,
Rakesh

Regards,

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

The documents are here:

Best,
Tommy & Ian

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 26 Nov 2020 14:15:11 +0000

Thanks Greg for your comments. Please see inline, I have added some replies below inline with <RG3>…

From: Greg Mirsky <[email-masked]>
Date: Thursday, November 19, 2020 at 12:28 PM
To: Mach Chen <[email-masked]>
Cc: Tianran Zhou <[email-masked]>, Rakesh Gandhi (rgandhi) <[email-masked]>, spring <[email-masked]>, IPPM Chairs <[email-masked]>, [email-masked] <[email-masked]>, Tommy Pauly <[email-masked]>, IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
Hi Mach,
thank you for your email. I've added my understanding of what has been proposed in-line tagged GIM>>.

Regards,
Greg

On Wed, Nov 18, 2020 at 11:41 PM Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tianran, Rakesh and Greg,
 Please see some responses inline with [Mach]…
From: ippm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tianran Zhou
Sent: Thursday, November 19, 2020 1:33 PM
To: Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: spring <[email-masked]<mailto:[email-masked]>>; IPPM Chairs <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
 Hi Rakesh and Greg,
I may not very clear about the context. Please allow me to jump in.
It seems both of you make some valid point.
Please see in line with <ZTR>.
Cheers,
Tianran
From: spring [mailto:[email-masked]] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: spring <[email-masked]<mailto:[email-masked]>>; IPPM Chairs <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm
 Hi Greg,
Thank you for your review and discussions on the drafts. This will help improve the work on this important work.
Please see replies inline with <RG>..

GIM>> You've brought a very good question on how the return path, in case required by the Sender Control Code, introduced in draft-gandhi-ippm-twamp-srpm, is specified? As you've pointed out, RFC 5357 does not use TLV extensions. Should I assume that the return path, if required, provisioned through the management plane? I think that that requires clarification.

<RG3> Here the return SR path may be dynamic and can often change (when ingress nodes re-compute SR paths). Using controller based signaling/provisioning for it defeats the purpose of overcoming scale limitations and using TWAMP Light.
 [Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-stamp-srpm assumes that marking-based solution (which can address the packet out-ordering issue) is used, hence the block number is introduced. The block number is used to correlate the counters from the sender and reflector. The current direct loss measurement TLV may just apply to the scenario without packet out-ordering.
GIM>> I agree with your observation on the purpose of the Block Number field in both TWAMP-Light and STAMP documents. In my understanding, the new protocol may be also used to collect counters generated by methods other than Alternate Marking. In that case, I assume, the value of Block Number may not convey any information.

<RG3> When TX and RX counters are collected by the TWAMP Light and STAMP based probe message defined in this draft, it’s block number carried in the message provides the context for the counters to be able to correlate the TX and RX counters to measure the traffic loss “at the Sender when the response is received”.
 [Mach] In addition, whether to keep it as current design or to define a new TLV for direct loss measurement can be debatable.
GIM>> I agree with you. And that what I am proposing - review the requirements, agree on requirements, and review the proposed solution based on these requirements.

<RG3> Please see the previous reply sent:
As TWAMP Light does not have a TLV, we need to define a stand-alone message for direct-mode LM. STAMP is just the same message but fixed length, so this way both can interoperate and also we can leverage the message for both of these protocols.

  *   Is there any advantage in introducing a dedicated packet format for the direct packet loss in STAMP comparing to using the Direct Measurement TLV extension?
Though it appears the using a dedicated packet format instead of TLV is more efficient, but the dedicated for the direct loss measurement format is likely to precede one or even two TLVs, Node Address TLV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with TLVs is unlikely to be more efficient and reduce the processing delay, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-stamp-option-tlv.
<RG> As mentioned in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/>. For link loss measurement (direct-mode), there is no TLV required for example. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss measurement (and not bidirectional).
•         What are the potential benefits of specifying the return path in the new test packet's Sender Control Code?
Using the Sender Control Code may require the use of the additional TLV that carries the return path information, Path TLV. If the ability to control the return path is required that can be achieved by augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each test packet. Hence, there seem no technical requirements to introduce the Sender Control Code field in the Base STAMP format defined in RFC 8762.
<RG> Per session basis between different sender nodes and this reflector node, some senders will request the replies in-band (e.g. for two-way mode). Sessions are provisioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for a bidirectional SR path). This is also similar to as described Section 3.1 in RFC 6374, top of page 22. There is no need to create a such state for each session on the reflector node and create a scale limitation. Recall that we are trying to avoid the scale limitation by eliminating the Control protocol signaling.
<ZTR> I find some value to include the path TLV in wire. As Rakesh mentioned, this can reduce the reflector configuration. But I am not convinced to introduce the sender control code field. It seems to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa.
[Mach] Regarding how to specify the return path, the draft defines two ways to achieve that, one is to use control code to direct whether the reflected Test should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the case of STAMP, it also defines the return path TLV to explicitly specify the return path, which bring more options to specify the return path. Therefore, I see benefit of the two ways.
GIM>> I think you've pointed to some vagueness in the definition of a mechanism used to define the return path. My understanding is that if a response required, the Return Path TLV must be present in a test packet. But, if TLVs are not used for TWAMP-like direct loss measurement, why not use the same method to control the return path? I believe that consistency is a good quality of a protocol (yes, I see *-twamp-srpm and *-stmp-srpm as a single protocol only presented as different entities).

<RG3> Yes, it is the intention to be consistent between the two drafts. TWAMP Light and STAMP are using the same method using the “Sender control code”. Obviously STAMP provides additional capability to specify Return Path via TLV. Both drafts explain the methods used.

Thanks,
Rakesh

 Best regards,
Mach