Thanks Juergen for sharing your view on this draft, please see comments inline. -----邮件原件----- 发件人: netmod [mailto:[email protected]] 代表 Juergen Schoenwaelder 发送时间: 2020年7月27日 16:48 收件人: [email protected] 主题: Re: [netmod] The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state "Candidate for WG Adoption"
I do not understand the abstract of the document. The main sentence is this one: This YANG data node tagging method can be used to provide input, instruction, indication to selection filter and filter queries of operational state on a server during a "pub/sub" service for YANG datastore updates and provide multiple dimensional network visibility analysis when the state of all subscriptions of a particular Subscriber to be fetched is huge, so that the amount of data to be streamed out to the destination can be greatly reduced and only targeted to the characteristics data. I can follow up to 'multiple dimensional network visibility analysis' and then I am lost. [Qin]: The goal is to address the challenging for massive data collection and processing, provide better network visibility to the telemetry data that is stored in the operational datastore. The idea we proposed is telemetry data tagging and classification, which can help the client or subscriber to subscribe specific telemetry data that are interest to the client. 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. 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'. [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. It is also unclear why we need exactly those eight different tag types. How does this relate to YANG defined properties such as units? If there is a mismatch, what takes precedence? [Qin]:As I clarified, the essence of the idea is telemetry data classification, or telemetry data tagging, it is not mandatory to have all of them, but it is nice to have many of them, the idea is to provide consistent representation or reporting for different modules, whether it is standard module, or vendor specific module. If I define tags in a module using the extension statements, why do I also have to have these tags in the instance tree? [Qin]: Have these tag in the instance tree is optional, we can retrieve them from offline document that is published somewhere. The idea to have tag in the instance tree is to advertise telemetry data tagging capability to the client, so the client can know Which data object is tagged, which category the data object belong to. draft-ietf-netmod-module-tags defines module tags plus mechanisms to tweak them if needed. This document seems to define node instance tags but hidden in a very specific use case. [Qin]: Similar to draft-ietf-netmod-moule-tags, it is generic tag, the only difference is the tag proposed in the draft-ietf-netmod-moule-tags while the tag proposed in this draft is data node level tags. I think the WG should determine whether it wants to work on "YANG Node Instance Tags" along the "YANG Module Tags" work. I personally find the scope of the work behind the current document unclear. /js On Sun, Jul 26, 2020 at 06:56:17AM -0700, IETF Secretariat wrote: > > The NETMOD WG has placed draft-tao-netmod-yang-node-tags in state > Candidate for WG Adoption (entered by Lou Berger) > > The document is available at > https://datatracker.ietf.org/doc/draft-tao-netmod-yang-node-tags/ > > Comment: > IPR disclosures: > https://datatracker.ietf.org/ipr/4216/ > Mail poll: > https://mailarchive.ietf.org/arch/msg/netmod/pyk2fLkG8srCuZKg7dDI3ypzK > rQ/ > > Liang Geng: > https://mailarchive.ietf.org/arch/msg/netmod/rXb-ZeXzvCQAByu2fFJlbno6t > R4/ Du > Zongpeng: > https://mailarchive.ietf.org/arch/msg/netmod/PRfcKZjjttBO4l3hW2VwEKwXJ > mc/ Ran > Tao: > https://mailarchive.ietf.org/arch/msg/netmod/O54ihWu6g5dnZmkJGHVByX7hp > oo/ Qin > Wu: > https://mailarchive.ietf.org/arch/msg/netmod/7jdfrEj61mcF2ASE6dDP8zOHf > ps/ > Benoit Claise: > https://mailarchive.ietf.org/arch/msg/netmod/3C-K4JaAgLnpAoPqcQAn59DFH > Yw/ > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
