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

[Greg Mirsky <[e-mail]>]

Hi Tianran,
if you re-read the draft and the STAMP YANG model carefully, then you will
notice that the model is defining the Session-Sender (    |  +--rw
stamp-session-sender {session-sender}?) while the draft enables the
Session-Sender to control test packet reflection by the Session-Reflector.
I hope that clarifies things and resolves your concerns.

Regards,
Greg

On Wed, Apr 24, 2024 at 10:07 AM Tianran Zhou <[e-mail]>
wrote:

> Hi Greg,
>
>
>
> Below is the configuration on sender side.
>
>
>
>     |  +--rw stamp-session-sender {session-sender}?
>
>     |  |  +--rw sender-enable?   boolean
>
>     |  |  +--rw sender-test-session* [session-sender-ip
>
>     |  |        session-sender-udp-port session-reflector-ip
>
>     |  |        session-reflector-udp-port dscp-value]
>
>     |  |     +--rw test-session-enable?           boolean
>
>     |  |     +--rw number-of-packets?             union
>
>     |  |     +--rw interval?                      uint32
>
>     |  |     +--rw session-timeout?               uint32
>
>     |  |     +--rw measurement-interval?          uint32
>
>     |  |     +--rw repeat?                        union
>
>     |  |     +--rw repeat-interval?               uint32
>
>     |  |     +--rw dscp-value?                    inet:dscp
>
>     |  |     +--rw test-session-reflector-mode?
>
> Best,
>
> Tianran
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Wednesday, April 24, 2024 3:40 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,
>
> please find my notes and questions below tagged GIM3>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Apr 23, 2024 at 6:04 PM Tianran Zhou <[e-mail]>
> wrote:
>
> 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.
>
> GIM3>> Could you kindly quote that part of the STAMP YANG model from
> draft-ietf-ippm-stamp-yang that, in your opinion, lists any of these, and
> precisely these, three fields? After that I would entertain the rest of
> your questions.
>
>
>
> 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]>
> wrote:
>
> Hi Greg,
>
> Thanks for the reply.
> Please see inline.
>
> Best,
> Tianran
> ------------------------------
>
>
> Sent from WeLink
>
> *发件人： *Greg Mirsky<[e-mail]>
>
> *收件人： *Tianran Zhou<[e-mail]>
>
> *抄送： *Tommy Pauly<[e-mail]>;IETF IPPM WG (ippm<[e-mail]>;Zhukeyi(Kaiyin,Datacom
> Standard&Patent)<[e-mail]>
>
> *主题： *Re: [ippm] IPPM adoption call for
> draft-mirsky-ippm-asymmetrical-pkts
>
> *时间： *2024-04-23 20: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]> 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.”
>
> [image: 图片加载失败]
>
>
>
> 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]] *On Behalf Of *Tommy Pauly
> *Sent:* Wednesday, April 10, 2024 12 <%202024%2012>:28 AM
> *To:* IETF IPPM WG ([e-mail]) <[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]
> https://www.ietf.org/mailman/listinfo/ippm
>
>