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

[Greg Mirsky <[e-mail]>]

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.

> 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)."

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

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

> 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: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
>