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

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[e-mail]] 
发送时间: 2020年7月27日 20:54
收件人: Qin Wu <[e-mail]>
抄送: [e-mail]
主题: Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"

On Mon, Jul 27, 2020 at 12:33:39PM +0000, Qin Wu wrote:
> -----邮件原件-----
> 发件人: Juergen Schoenwaelder 
> [mailto:[e-mail]]
> 发送时间: 2020年7月27日 18:42
> 收件人: Qin Wu <[e-mail]>
> 抄送: [e-mail]
> 主题: Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"
> 
> 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.
> 
> [Qin]:umm, have a second thought, I think this is the design choice we made, we did investigate metadata annotation approach, but the essence of metadata annotation is to add attribute to the model, we think adding attributes still have limitation, since you can not add too many attributes one time to the same xml element.
> Secondly, we need to know which data is the characteristics data or telemetry data category the client want to subscribe before sending subscription request to the server. If we take metadata annotation approach, we need to have at least two times subscriptions before finding targeted data objects, or first retrieve telemetry data tag from the server and then subscribe targeted data object. It is hard to automate subscription with metadata annotation approach.

I do not think there is a restriction of the number XML attributes.
You can simply send a get operation. You will need a get operation as well for your central list of tags.

[Qin]: This is what I clarified above, it is not automated approach, you need to have two steps before finding the target data object, first send get operation request, second subscribe based on the tag indication.
 
> > 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]: no, it is not always necessary for device manufacturer to do such prediction, it can be put into offline document together with module schema for NMS to retrieve. In addition, it allows the device adding or removing tag in the same as module tag does. These tag changes can be advertised Using server capability defined in draft-ietf-netconf-notification-capabilities to inform the client about it.

I must have missed that in the draft.

> > [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.
> 
> [Qin]:We did target generic solution, telemetry is not specific case, but it is the main case. If you think there are other cases, we are happy to cover it. The semantics for each node tag has been defined within the module, semantics can be polished step by step.
> Leaf carrying the tag helps data consumer such as influxdb/grafana to further classify the telemetry data and provide better network visbility.
> Leaf carrying the tag approach has been widely used by many IETF work such as draft-ietf-netmod-module-tags, draft-ietf-netmod-yang-module-versioning-01.
> For other reasons, please see the clarification mentioned above.

draft-ietf-netmod-module-tags:

       module: ietf-module-tags
         +--rw module-tags
            +--rw module* [name]
               +--rw name          yang:yang-identifier
               +--rw tag*          tag
               +--rw masked-tag*   tag

Its a single leaf-list of tags, the semantics what the tags mean are in the tags. This is different from what you are proposing where some of the semantics of what the tag means are in the leaf a tag appears in - and there are likely also invalid situations or situations where things are unclear at least. For example, what does metric-scale with that tag ietf:minus-three mean? I do not really get the idea why you need 8 leafs each holding exactly one tag. This is inflexible, whenever an application likes to use an additional tag, you have to revise the YANG module.
[Qin]: Thanks Jurgen for clarification, get your point, happy to take this approach if it works. I think this is about tag management, similar to module tag module, tag defined under self-explanation-node can be used to convey various different tags.

Anyway, time for others to comment. I think I said what I had to say.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>