Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 27 July 2020 10:41 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023213A187F for <netmod@ietfa.amsl.com>; Mon, 27 Jul 2020 03:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 5_HUcBaTVP4J for <netmod@ietfa.amsl.com>; Mon, 27 Jul 2020 03:41:54 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130CC3A1854 for <netmod@ietf.org>; Mon, 27 Jul 2020 03:41:53 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 78BE46F4; Mon, 27 Jul 2020 12:41:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ko1BuOouhFv9; Mon, 27 Jul 2020 12:41:52 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 27 Jul 2020 12:41:52 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24FC520154; Mon, 27 Jul 2020 12:41:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 7gJwOjXsPcAd; Mon, 27 Jul 2020 12:41:51 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 9794B200E4; Mon, 27 Jul 2020 12:41:51 +0200 (CEST)
Date: Mon, 27 Jul 2020 12:41:51 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Qin Wu <bill.wu@huawei.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20200727104151.jwzrsfhgvccfajta@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Qin Wu <bill.wu@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABAAD89DBDD@dggeml511-mbs.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAAD89DBDD@dggeml511-mbs.china.huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/aqS3cvCQJrStzHeKzcMLiTPywHk>
Subject: Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 10:41:57 -0000

On Mon, Jul 27, 2020 at 10:13:43AM +0000, Qin Wu wrote:
> 
> On the technical side, it is not clear why a central list of tags providing meta information is preferrable over metadata annotations that can be shipped with the values.
> 
> 
> [Qin]: If we take metadata annotation approach, we need to define new module for each device level modules such as interface module, IP management module, BGP module, QoS module deployed in the device or revise these modules that has already been published and update devices with these new modules corresponding to deployed device level modules. Suppose the device level modules that has been deployed in the device is huge, such metadata annotation solution require update on each device for the new modules, the number of new modules is same as the number of existing deployed device level modules, which doesn't scale well.
> 

I do not think this answer is technically correct. For a counter
example, see the definition of md:annotation origin in RFC 8342.

> It does not seem harmful to adopt this work if people think this is needed and they are willing to work on this. The others can safely ignore this with. Personally, I am not convinced yet, but then I do not work on 'multiple dimensional network visibility analysis'.
> Perhaps a good convincing concrete example would help, the tables in Fig. 2 do not help me much.
>
> [Qin]: Suppose we can classify telemetry data from different angles, we can tag the telemetry data with various different data object tag, e.g., whether the data object is performance metric data, which category the performance metric data belong, if the data object
> Is performance metric data or KPI data, we can further classify KPI data from operation type, e.g., whether KPI data is average value, minimum value, maximum value, whether KPI data allow set threshold for it, if the KPI data can come from multiple source,
> We can indicate whether KPI data is aggregated data or not, so collector can use these telemetry data tag to subscribe targeted data object or these telemetry data tag associated with subscribed data can be further consumed by big data analytics platform/open observability platform such as InfluxDB/grafana and provide different outputs based on the telemetry tag or telemetry data classification that is selected.
> 
> The goal seems to add tags to node instances. I do not understand what they are called 'self-explanation-node-tags' and not simply 'node-tags'.

You assume that the device manufacturer implementing YANG modules can
predict what a management application wants to do with a certain piece
of information. I doubt this is generally true. And if you look at
basic counters, they often serve many different purposes. Even if the
WG believes this to be true, there likely needs an overwrite mechanism
in case the manufacturer predicted things wrongly.

> [Qin]: The reason to call it as 'self-explanation-node-tag' is to make it better reflect what it is really aimed for, if you have better name, I am happy to accept it.

Well, to me these look like node instance tags. If anything, I would
be interested in a generic solution and not something taylored to one
specific use case (telemetry) and this is why I would prefer to have
the specific semantics in the tags and not in the set of leafs
carrying the tags.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>