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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> wrote:

> *Hi Greg, *
>
> *Thanks for your support! More inline…. *
>
>
>
> *From:* Teas [mailto:[e-mail]] *On Behalf Of *Greg Mirsky
> *Sent:* 29 August 2021 02:15
> *To:* [e-mail]; TEAS WG <
> [e-mail]>
> *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*
>
>
>
> Regards,
>
> Greg
>