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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
