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

[Tianran Zhou <[e-mail]>]

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