Subject: Re: [Teas] Several questions draft-ietf-teas-actn-pm-telemetry-autonomics

From: Dhruv Dhody <[email-masked]>
Date: Thu, 2 Sep 2021 07:46:09 +0000

Hi Greg,
Thanks for your support! More inline….

From: Teas [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 29 August 2021 02:15
To: [email-masked]; TEAS WG <[email-masked]>
Subject: [Teas] Several questions draft-ietf-teas-actn-pm-telemetry-autonomics

Dear Authors,
thank you for writing this document, developing these data models. I wholeheartedly agree with you that up-to-date telemetry information is essential in closing the control circuit ensuring autonomous self-healing networking. I've read the document and have several questions; much appreciate your help in clarifying them:

  *   in listing the benefits of performance monitoring, as it interpreted in the draft, you've mentioned "proactive re-optimization". As I understand it, telemetry information reflects network conditions that already happen and by the time a subscriber to performance monitoring notifications receives the next update, it is probably closer to near-real-time process. If then an application triggers corrective actions, e.g., scaling out, how that is proactive? I imagine that to trigger scaling out, a particular parameter or a group of parameters had crossed the predefined threshold and the state has been stable for threshold-time. Hence, the system is reactive, not proactive.
[[DD]] That is a good observation. But since the threshold could be set to value much before the real disaster, I considered that to still mean proactive in that sense that we are re-optimizing before the Tunnel/VN has gone down. I can add some text to explain why we consider this proactive. Or avoid using the word.

  *   you've included a number of performance parameters in data models. I couldn't find a discussion of the selection process. i.e., why these parameters were selected, and why others are not included? I hope you can point me to where I can find that discussion.
[[DD]] We have included the grouping from RFC 8776 (te-types:performance-metrics-attributes) and thus considered that to be settled matter for now.

  *   how do you see your work in relation to draft-ietf-opsawg-yang-vpn-service-pm<https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/>? Some of the performance metrics reported through the draft-ietf-opsawg-yang-vpn-service-pm are part of the STAMP YANG data model<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>.
[[DD]] It is a good idea to add a sentence on this in the draft. I do consider these two models to be independent but could be used together to understand the performance issues at the VPN service and the underlying TE.
Thanks!
Dhruv

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Sep 2021 13:42:37 -0700

Hi Dhruv,
many thanks for your kind and thoughtful consideration of my notes. Please
find more in-lined below under the GIM>> tag.

Regards,
Greg

On Thu, Sep 2, 2021 at 12:46 AM Dhruv Dhody <[email-masked]> wrote:

> *Hi Greg, *
>
> *Thanks for your support! More inline…. *
>
>
>
> *From:* Teas [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* 29 August 2021 02:15
> *To:* [email-masked]; TEAS WG <
> [email-masked]>
> *Subject:* [Teas] Several questions
> draft-ietf-teas-actn-pm-telemetry-autonomics
>
>
>
> Dear Authors,
>
> thank you for writing this document, developing these data models. I
> wholeheartedly agree with you that up-to-date telemetry information is
> essential in closing the control circuit ensuring autonomous self-healing
> networking. I've read the document and have several questions; much
> appreciate your help in clarifying them:
>
>    - in listing the benefits of performance monitoring, as it interpreted
>    in the draft, you've mentioned "proactive re-optimization". As I understand
>    it, telemetry information reflects network conditions that already happen
>    and by the time a subscriber to performance monitoring notifications
>    receives the next update, it is probably closer to near-real-time process.
>    If then an application triggers corrective actions, e.g., scaling out, how
>    that is proactive? I imagine that to trigger scaling out, a particular
>    parameter or a group of parameters had crossed the predefined threshold and
>    the state has been stable for threshold-time. Hence, the system is
>    reactive, not proactive.
>
> *[[DD]] That is a good observation. But since the threshold could be set
> to value much before the real disaster, I considered that to still mean
> proactive in that sense that we are re-optimizing before the Tunnel/VN has
> gone down. I can add some text to explain why we consider this proactive.
> Or avoid using the word.*
>
GIM>> I think that if we avoid the discussion of what behavior is proactive
or reactive, that will not damage the value of the document. What do you
think?

>
>    - you've included a number of performance parameters in data models. I
>    couldn't find a discussion of the selection process. i.e., why these
>    parameters were selected, and why others are not included? I hope you can
>    point me to where I can find that discussion.
>
> *[[DD]] We have included the grouping from RFC 8776
> (te-types:performance-metrics-attributes) and thus considered that to be
> settled matter for now.  *
>
GIM>> Thank you for pointing that out to me, I've missed that. I agree,
that  settles it.

>
>    - how do you see your work in relation to
>    draft-ietf-opsawg-yang-vpn-service-pm
>    <https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/>?
>    Some of the performance metrics reported through
>    the draft-ietf-opsawg-yang-vpn-service-pm are part of the STAMP YANG
>    data model
>    <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>.
>
> *[[DD]] It is a good idea to add a sentence on this in the draft. I do
> consider these two models to be independent but could be used together to
> understand the performance issues at the VPN service and the underlying TE.*
>
GIM>> Thank you for your consideration. References certainly will be useful
to a reader.

> *Thanks! *
> *Dhruv*