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

Dhruv Dhody <> Thu, 02 September 2021 07:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1776E3A11BD; Thu, 2 Sep 2021 00:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1vzQ7PGQF7ki; Thu, 2 Sep 2021 00:46:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C29E3A11C2; Thu, 2 Sep 2021 00:46:15 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4H0Xxm3MxVz67YMc; Thu, 2 Sep 2021 15:44:28 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 2 Sep 2021 09:46:12 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 2 Sep 2021 13:16:09 +0530
Received: from ([]) by ([]) with mapi id 15.01.2308.008; Thu, 2 Sep 2021 13:16:09 +0530
From: Dhruv Dhody <>
To: Greg Mirsky <>, "" <>, TEAS WG <>
CC: Dhruv Dhody <>
Thread-Topic: [Teas] Several questions draft-ietf-teas-actn-pm-telemetry-autonomics
Thread-Index: AQHXnE23C3dZ9zRS1EiSNtk1olOZB6uQXPVg
Date: Thu, 2 Sep 2021 07:46:09 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_96c9b508ceca4addb5b8a64bbfe50e65huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Teas] Several questions draft-ietf-teas-actn-pm-telemetry-autonomics
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Sep 2021 07:46:20 -0000

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

From: Teas [] On Behalf Of Greg Mirsky
Sent: 29 August 2021 02:15
To:; TEAS WG <>
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<>? Some of the performance metrics reported through the draft-ietf-opsawg-yang-vpn-service-pm are part of the STAMP YANG data model<>g/>.
[[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.