Re: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts

[Tianran Zhou <[e-mail]>]

Hi Greg,

Please let me try to rephrase the question.
I am trying to understand the value.
My major concern is about the three fields in control tlv, say “Length of the Reflected Packet”, “Number of the Reflected Packets”, “Interval Between the Reflected Packets”.
This is already in draft-ietf-ippm-stamp-yang. And using Netconf to configure the STAMP typically follows the STAMP reference model in RFC8762.
Then what’s the scenario and the value of this control tlv?
If there is a controller, it could be configured using draft-ietf-ippm-stamp-yang. It could be some other protocols whatever it’s centralized control. But in this case I think there is no need for the control tlv.
So I think you want to use the control tlv when there is no controller.
And you want to create a *simple*  and *distributed* control plane.
Right?

Tianran



From: Greg Mirsky [mailto:[e-mail]]
Sent: Tuesday, April 23, 2024 10:54 PM
To: Tianran Zhou <[e-mail]>
Cc: Tommy Pauly <[e-mail]>; IETF IPPM WG (ippm <[e-mail]>; Zhukeyi(Kaiyin,Datacom Standard&Patent) <[e-mail]>
Subject: Re: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts

Hi Tianran,
thank you for sharing your concerns. Please find my notes below tagged GIM2>>.

Regards,
Greg

On Tue, Apr 23, 2024 at 4:11 PM Tianran Zhou <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Thanks for the reply.
Please see inline.

Best,
Tianran
________________________________

Sent from WeLink
发件人： Greg Mirsky<[e-mail]<mailto:[e-mail]>>
收件人： Tianran Zhou<[e-mail]<mailto:[e-mail]>>
抄送： Tommy Pauly<[e-mail]<mailto:[e-mail]>>;IETF IPPM WG (ippm<[e-mail]<mailto:[e-mail]>>;Zhukeyi(Kaiyin,Datacom Standard&Patent)<[e-mail]<mailto:[e-mail]>>
主题： Re: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts
时间： 2024-04-23 20<tel:2024-04-23%2020>:58:25

Hi Tianran,
thank you for your consideration of the proposal and questions. Please find my notes below tagged GIM>>.

Regards,
Greg

On Tue, Apr 23, 2024 at 9:10 AM Tianran Zhou <zhoutianran=[e-mail]<mailto:[e-mail]>> wrote:
Hi Tommy, Greg and WG,

During the discussions in the mailing list several month ago. We find some interesting use cases.
My question is can we use a controller to configure different nodes instead of using this Control TLV?
GIM>> An interesting point, thank you. In general, any control action, in my opinion, may be achieved through configuration. For example, leaves of multicast distribution tree could be configured to not reflect STAMP test packets of a specific STAMP test session (or not to reflect any STAMP packet). Similarly, SR ergress node could be configured with the path to transmit reflected STAMP packets to achieve the same behavior as using the STAMP extensions defined in RFC 9503. In my personal opinion, one does not preclude another.

ZTR> I actually meant to ask what’s the benefit to do so.
And on your examples, it seems no need for the body of control tlv, but only a not to reflect instruction.
GIM2>> I'd note that there are several use cases for the new TLV:

  *   rate measurement that requires control of number and rate of reflecting STAMP test packets
  *   performance measurement in a multicast network (p2mp).
It seems that you consider only one smaller part of the applicability of Reflected Test Packet Control TLV.
Or is this document want to introduce a way to eliminate the controller?
GIM>> I am not sure what in this draft can be interpretted in that way. The draft proposes an optional extension, not a mandatory one. Also, the use of a controller is optional. A STAMP implementation may be configured and managed by means other than a controller (as noted in the quote below)."

ZTR> What’s the scenario for this control tlv? No controller? Or still with a controller? Again what’s the benefit?
GIM2>> The new TLV does not preclude the use of a Controller but it could be complimentary if the Controller does not support control of some test scenarios. For example, RFC 8972 defined Class of Service TLV that allow to monitor and control DSCP in upstream and downstream directions. Similarly, RFC 9503 defined optional STAMP extension to control the path of a reflected STAMP test packet. I imagine that these functions could be realized through a Controller. AFAICS, these optional extensions are in no way contradicting RFC 8762:
   The configuration and management of the STAMP
   Session-Sender, Session-Reflector, and sessions are outside the scope
   of this document and can be achieved through various means.  A few
   examples are Command Line Interface, telecommunication services'
   Operational Support System (OSS) / Business Support System (BSS),
   SNMP, and NETCONF/YANG-based Software-Defined Networking (SDN)
   controllers.
I will stress that, unlike TWAMP, STAMP does not require any particular method of configuration and management. Do you agree?
Looking at RFC8762, one motivation of STAMP is:
“At the same time, there has been noticeable interest in using a more straightforward mechanism for active performance monitoring that can provide deterministic behavior and inherent separation of control (vendor-specific configuration or orchestration) and test functions.”
And in the reference model below,
“The configuration and management of the STAMP Session-Sender, Session-Reflector, and sessions are outside the scope of this document and can be achieved through various means. A few examples are Command Line Interface, telecommunication services' Operational Support System (OSS) / Business Support System (BSS), SNMP, and NETCONF/YANG-based Software-Defined Networking (SDN) controllers.”
[图片加载失败]

So I am thinking whether this proposal want to go back to TWAMP?
GIM>> Can you point to the text in the document that states that or lead you to that conclusion? Clearly, the authors have no intention to re-create a separate mandatory STAMP control plane like exists in TWAMP.

ZTR > My understanding of your reply is you want to create an optional control plane. Right?
GIM2>> No. Could you please point out what lead you to that conclusion?
This may introduce many issues that TWAMP control session solved.
GIM>> Do you see benefits of establishing a mechanism in STAMP analogous to TWAMP Control plane? What these could be?

ZTR > No I don’t think so. So I want to understand what‘s the difference to TWAMP control plane.
GIM2>> I got confused by your attepmt to draw a parallel between this optional STAMP extension and TWAMP Control protocol. Could you point to aspects of this TLV, as well as other STAMP extensions in RFC 8972 and RFC 9503 that control the behavior of a Session-Reflector, that you find analogous with the TWAMP control protocol?
I see many people have raised the security issue.
GIM>> The authors appreciate the comments and suggestions we received from Tal and  Sebastian, and we'll work on addressing their concerns in the next revisions of the draft.

Best,
Tianran

From: ippm [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Tommy Pauly
Sent: Wednesday, April 10, 2024 12<tel:%202024%2012>:28 AM
To: IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts

Hello IPPM,

This email starts an adoption call for draft-mirsky-ippm-asymmetrical-pkts. This is a document we’ve discussed several times, and is a normative dependency for another document we discussed adopting at IETF 119, draft-gandhi-ippm-stamp-ext-hdr.

You can find the draft here:
https://datatracker.ietf.org/doc/draft-mirsky-ippm-asymmetrical-pkts/
https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-04.html#name-reflected-test-packet-control

Please review the draft and respond to this email to indicate if you think IPPM should adopt this document as a working group item.

This call will last for 3 weeks. Please reply by Tuesday, April 30.

Best,
Tommy & Marcus
_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm