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

Greg Mirsky <gregimirsky@gmail.com> Tue, 07 September 2021 20:42 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71AD3A1677; Tue, 7 Sep 2021 13:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMule2qWEMvJ; Tue, 7 Sep 2021 13:42:51 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C046E3A16B4; Tue, 7 Sep 2021 13:42:50 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id n11so15669276edv.11; Tue, 07 Sep 2021 13:42:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aQBDVPEI+ljk6OV1D5wyHp9gjLbaCmPRP481FAdhHvc=; b=MpoGgjaaOqOO5m09s98pZaa/JSxf5pN8unWitkE49sAldKOfHaG4ZHXXhTV+LjV1KQ GcgXSAgdLtkQTT9pXgMpfWQO+mS1eYM2yrdsygVsNjqiojl7bMofZuOx21rbNP4fm8fR koL7aHsSpauc0OMx4/Ft4h6C4KhJEzBvxjVve9hc6z7aSVcb+ERJT1CHdKMVuJD2Dqu2 9a93QN7BOVSnHaMeQDhMCvNQMD/9dq1lcXRm4cWFqj2vHqGyqSZ15lUtfWc3VnodiVrc +HBHEYLdViiX+nhEOfka3hFYiRsJFw/V06ITm+34aOpISh3Vplmf++fYrB3AS6JGgGOw 9WOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aQBDVPEI+ljk6OV1D5wyHp9gjLbaCmPRP481FAdhHvc=; b=tWegX+LkrBmLgdCCWm1IeExPnaqqOPCBqpqroQLxCR3sRS4idGvHiagEXc0a+xt0IE GcHVKeIfit/7pB9t1uQY6qae7/1WHMfJxs1DL1fJ0oEB88wdnNcs6RwBw2zdFuuiqla8 3ySgHQFbX9XWx3M8cm+45BJwCPoTN9539i3XYhTGkG5lo/whul5IOfj2X05ZIeE9qb1v 25ExybD7g0xr6ofkYSEDtNlEJneeGE3qs0Z+jFUXKcBcLANYTgkjwiEu/bgYJWPpm2XI 6/Xn/HITvgAlyBN7fhrh67fjAOwuAkO1VRJ3NGV6bivc9vqZpi7G4KSgyH5sAWfB6irw JpkQ==
X-Gm-Message-State: AOAM533ik6IaVuTp+rXfM9fxwxJmMsXwAFevMJ6krpgI2a8X0uXUnnIe etrmUfQwxQqEsbhAiOH6mo69sVQ2AHxyuYeFdBkbV9j7
X-Google-Smtp-Source: ABdhPJwyCUZe2jBNtqEJhC3GhJTaLi+bWmaX8ACpt65zEzzM14mFo7GPWjNXWlvqtIdkH0EkiPULK1uX06mZIns4+hY=
X-Received: by 2002:a50:9511:: with SMTP id u17mr148128eda.100.1631047368428; Tue, 07 Sep 2021 13:42:48 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmUuwLguLK-Jpo8eMnd6gwm3ekTs_pYvMNBwTVRXUwnWOQ@mail.gmail.com> <96c9b508ceca4addb5b8a64bbfe50e65@huawei.com>
In-Reply-To: <96c9b508ceca4addb5b8a64bbfe50e65@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 7 Sep 2021 13:42:37 -0700
Message-ID: <CA+RyBmXOrJPfOK5wB5n9TmN0mhtcF-nYa5Ke9SwZiuucWjUajw@mail.gmail.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>
Cc: "draft-ietf-teas-actn-pm-telemetry-autonomics@ietf.org" <draft-ietf-teas-actn-pm-telemetry-autonomics@ietf.org>, TEAS WG <teas@ietf.org>, Dhruv Dhody <dhruv.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000001ceae05cb6dcf0a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-isj4h_eDbr4pUQZAye8PqFl_lU>
Subject: Re: [Teas] Several questions draft-ietf-teas-actn-pm-telemetry-autonomics
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2021 20:43:05 -0000

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

> *Hi Greg, *
>
> *Thanks for your support! More inline…. *
>
>
>
> *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* 29 August 2021 02:15
> *To:* draft-ietf-teas-actn-pm-telemetry-autonomics@ietf.org; TEAS WG <
> teas@ietf.org>
> *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
>