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 <zhoutianran@huawei.com> wrote:

> Hi Greg,
>
> Thanks for the reply.
> Please see inline.
>
> Best,
> Tianran
>
> ------------------------------
>
> Sent from WeLink
> *发件人： *Greg Mirsky<gregimirsky@gmail.com>
> *收件人： *Tianran Zhou<zhoutianran@huawei.com>
> *抄送： *Tommy Pauly<tpauly@apple.com>;IETF IPPM WG (ippm<ippm@ietf.org>;Zhukeyi(Kaiyin,Datacom
> Standard&Patent)<zhukeyi@huawei.com>
> *主题： *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=
> 40huawei.com@dmarc.ietf.org> 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:ippm-bounces@ietf.org] *On Behalf Of *Tommy Pauly
>> *Sent:* Wednesday, April 10, 2024 12 <%202024%2012>:28 AM
>> *To:* IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
>> *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
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>

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

Attachment: image003.jpg