Subject: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

From: Qin Wu <[email-masked]>
Date: Tue, 18 Aug 2020 07:24:22 +0000

Juergen:
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2020年8月18日 12:53
收件人: Kent Watsen <[email-masked]>
抄送: [email-masked]
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

On Mon, Aug 17, 2020 at 10:05:27PM +0000, Kent Watsen wrote:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-05
> 
> Please voice your support or objections on list before August 31.  
> 
> Notes:
>    1)  -03 was presented during the 108 session, hence the I-D has been updated twice since then.
>    2) Please be aware that IPR has been filed for this I-D:
>          https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tags <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tags>.
> 

I am against adoption. I am against introducing a collection of standards-track extension statements without answering the question who controls, enforces and reviews the usage of these extension statements (when and how are they used). 

[Qin]: As clarified earlier, these extension statements will be used in the same way as module tag does which is defined in draft-ietf-netmod-module-tags-10, the difference is module tag is at module level while data object tag is at data node level which provide fine granularity of tag management. draft-ietf-netmod-module-tags-10 clearly clarify who controls, enforces usages of the extension statements.
"
   Tags may be defined and associated at module design time, at
   implementation time, or via user administrative control.  As the main
   consumer of tags are users, users may also remove any tag, no matter
   how the tag became associated with a module.
"
So does this draft.
Some statements and tags are either addressing issues caused by underspecified YANG modules or they overlap with the deviation mechanism that we have in place since day one of YANG. 
[Qin]: Data object tag is not tag everything, instead it will only tag performance related data, context related tag is motivated by ETSI Context Information Management (CIM) effort.
Others are very vaguely specified, it is unclear how they will lead to interoperable behavior. 
[Qin]: The mechanism defined here is targeted generic mechanism, can be applicable to not only standard model, but also vendor specific model or user specific models, the big value is to increase interoperability since it can be used multi-vendor environment, and provide consistent reporting and representation.
One of example, is two vendors deploy different vendor specific QoS model for the same functionality, data object tag can point to different data object name with same functionality, which provide interoperable behavior.

If module authors are too lazy to use existing YANG mechanisms properly, does it make sense to add more mechanism to the YANG eco system? I doubt it.
[Qin]: It is not about lazy, similar to module tag defined in draft-ietf-netmod-module-tags-10, it provides operation and management data classification and help you quickly capture KPI data and further provide data object correlation by using context information.
/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-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Qin Wu <[email-masked]>
Date: Wed, 19 Aug 2020 01:34:03 +0000

Hi, Andy:
发件人: netmod [mailto:[email-masked]] 代表 Andy Bierman
发送时间: 2020年8月19日 3:10
收件人: Juergen Schoenwaelder <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

Hi,

On Mon, Aug 17, 2020 at 9:53 PM Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
>          https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tags <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tags>.

I am against adoption. I am against introducing a collection of
standards-track extension statements without answering the question
who controls, enforces and reviews the usage of these extension
statements (when and how are they used). Some statements and tags are
either addressing issues caused by underspecified YANG modules or they
overlap with the deviation mechanism that we have in place since day
one of YANG. Others are very vaguely specified, it is unclear how they
will lead to interoperable behavior. If module authors are too lazy
to use existing YANG mechanisms properly, does it make sense to add
more mechanism to the YANG eco system? I doubt it.

I am also against adoption.
This module introduces 9 extension-stmts that represent a huge administrative burden for
module developers without any proven value.

[Qin]: Not all 9 extension stmts needs to be mandatory supported at the same time,  the key value of these tags is to capture performance metric data or KPI data.
If the number of extension-stmts is the concern, we could reduce down to two or three performance metric related extension stmts, opm tag focuses on telemetry data
Classification and operational type which identify statistics operations such as sum, avg,min.
It is not even clear that such specific metadata
is even applicable to all instances of the tagged data node.
[Qin]:
OPM tag and operation type are not targeted to apply to all instance of the tagged data node, instead, it aims at sorting out characteristics data, KPI data within the module,
such as counter, statistics, performance metrics.
For context information related tag, e.g., service tag, data source tag can be applicable to all instance of the tagged data nodes since it provide another angle operation and management data classification.
IMO it is not likely that a single
metric will apply to all instances, all all times, in any possible deployment scenario.
[Qin]:You might misunderstand, it is not our goal to make a single metric apply to all instance, instead, these tags will be used to sort out all performance metric related data node or data objects.
There are no standard operations or mechanisms to use module tags.
They have not demonstrated any standards value so far.
[Qin]: Understand, IETF focus on developing many generic building blocks, they can used by developer and operator to build a complete solution.
demonstrating standard value or deploying all of them always need to step by step and will take time. It apply to all other newly published building blocks in OPS area, not limited to module tags.

/js

Andy

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Chang Liu(联通集团中国联通研究院-本部) <[email-masked]>
Date: Wed, 19 Aug 2020 07:42:21 +0000

Hi all,

I support adoption, since this solution can capture metric from the network and doesn’t require big changes to all existing modules.

Best Regrads

________________________________
Liu Chang
China Unicom
Email: [email-masked]<mailto:[email-masked]>
Phone: +8618601102572
Tel: 010-68799999-7294

---Original---
From: "Kent Watsen"<[email-masked]><mailto:Watsen&quot;&lt;[email-masked]&gt;>
Date: Tue, Aug 18, 2020 06:05 AM
To: "[email-masked]"<[email-masked]>;
Subject: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
         https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tagstags.
Netmod Chairs

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Qin Wu <[email-masked]>
Date: Mon, 31 Aug 2020 11:39:13 +0000

Good, thanks Jurgen for clarification.

-Qin
-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2020年8月30日 18:52
收件人: Qin Wu <[email-masked]>
抄送: Lou Berger <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

On Sun, Aug 30, 2020 at 10:40:36AM +0000, Qin Wu wrote:
> 
> Wrong. The semantics of the counter types provided by ietf-yang-types are well defined.
> 
> [Qin]: I agree counter types in ietf-yang-types are well defined. 
> If counter types can help distinguish avg value from min, max, sum 
> value, current value, I am happy to adopt it, however I fail to see 
> ietf-yang-types can do that and I don't think distinguishing avg from min,max etc is the job of ietf-yang-types. It add complexity if going with that direction, in my understanding.

You miss my point: The specification of a leaf needs to be clear what it is. If it is not clear, then the specification is buggy.

/js

---

From: Qin Wu <[email-masked]>
Date: Tue, 1 Sep 2020 02:30:44 +0000

Thanks, Lou, you are correct, metric type such as metric scale, metric precision have a little overlapping with unit, range statement defined in RFC7950, I will take them out.
For operation type, I understand Jurgen’s point, it will be great to define it as part of module definition. I will take it out as well for now unless it can be well specified later.
Thanks.

-Qin
发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2020年8月31日 21:28
收件人: Qin Wu <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]; [email-masked]
主题: RE: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

Qin,

Thank you for your reply.I think you have two points below (a) tags to define metric type and (b) object-specific tags

For me, I believe I agree with Juergen's comments, i.e.,  that metric type definition is not metadata and belongs in the module definition.

On the other topic (b) object-specific tags is an interesting idea and may provide general utility.  (as contributor) once separated from the metrics discussion, this seems like an idea worth discussing in the WG to see if there is interest in this added capability.

Lou

On August 30, 2020 5:01:28 AM Qin Wu <[email-masked]><mailto:[email-masked]> wrote:
Thanks Lou for valuable comments, please see reply inline below.
发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2020年8月30日 2:40
收件人: Kent Watsen <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

Hi,

A couple of comments:

- As a co-author or YANG Module Tags, I'm thrilled to see it being used/augmented by this document, but I'm not clear on how the metric and operation type tags are to be used.  To me these seem to be best defined by the modules themselves, e.g., does a value represent an average /sum/min/max value or the scale of the value, and not as tag meta data.

[Qin]:Just to clarify, defining metric and operation type by modules themselves may cause revising all the existing published modules we expect to tag, or creating the same number of new modules (augment from the existing published modules) as the number of targeted existing modules, which is not scalable and desirable. So we abandon this option in our implementation design.

The data object tags like metric and operation type tag don't introduce any new data nodes into existing modules and can tag any performance metric related data object within published modules, standard modules, native modules without module name change. The data object tag can not be used to tag any one of targeted modules (ietf-geo-location defined in draft-ietf-netmod-geo-location or ietf-ip in RFC8344) which doesn't include performance metric related data node.

Regarding operation type tag, take ietf-interfaces in RFC8343 as an example, ietf-interfaces include interface statistics data object which can be seen as performance metric related data objects,

           +--ro statistics

              +--ro discontinuity-time    yang:date-and-time

              +--ro in-octets?            yang:counter64

              +--ro in-unicast-pkts?      yang:counter64

              +--ro in-broadcast-pkts?    yang:counter64

              +--ro in-multicast-pkts?    yang:counter64

              +--ro in-discards?          yang:counter32

              +--ro in-errors?            yang:counter32

              +--ro in-unknown-protos?    yang:counter32

              +--ro out-octets?           yang:counter64

              +--ro out-unicast-pkts?     yang:counter64

              +--ro out-broadcast-pkts?   yang:counter64

              +--ro out-multicast-pkts?   yang:counter64

              +--ro out-discards?         yang:counter32

              +--ro out-errors?           yang:counter32

however these statistics doesn't tell you whether in-errors is current value or average value or total value, so does count related data objects defined in ietf-dhcpv6-server of draft-ietf-dhc-dhcpv6-yang

            +--ro solicit-count?               uint32

            +--ro advertise-count?             uint32

            +--ro request-count?               uint32

            +--ro confirm-count?               uint32

            +--ro renew-count?                 uint32

            +--ro rebind-count?                uint32

            +--ro reply-count?                 uint32

            +--rw release-count?               uint32

            +--ro decline-count?               uint32

            +--ro reconfigure-count?           uint32

            +--ro information-request-count?   uint32

The operation type tag is introduced to help the network device who is responsible for collecting these statistics data with specific operation type, tell the collectors the statistic related data object reporting current value or average value.

For the scale of the value, talking with Benoit earlier, we think metric scale may be overlapping with the range statement, the idea is to provide consistent reporting and representation for some of statistics data we want to tag. But if this adds complexity, we are happy to take it out, so does metric precision.

Similarly, the type of vpn supported by a tunnel also seems like module data and not tag meta data, as this is a per tunnel instance value.

[Qin] See above, data object tag is *not used to replace module data*, instead, it is used to label these module data as our interested subscribed objects. The label value or tag value is fixed upon it is defined.

Secondly, the precondition to use vpn service tag is the vpn service has already been decomposed into a set of configuration data object of device modules. The idea is used the service tag as context information tag to correlate data objects from different location of the same module or different module together, the service tag is help glue different data objects together, These context information tag can be analogous to context trace defined in https://www.w3.org/2018/distributed-tracing/.

Also if module tag can be repurposed at the data node level, I am happy to reuse module tag defined in draft-ietf-netmod-module-tags-10. So vpn related tag is not needed in this draft. Anyway I am open about these tags.

While the work was previously presented to the WG, I know you didn't have the time we all hoped for to discuss this at the last session, so I (personally, not as chair) would like to ask you to explain this on the list prior to adoption.  I'm hoping I'm just missing something, but from the discussion with Juergen an Andy I suspect not.

[Qin]: See above clarification, we did have discussion with Jurgen regarding these issues on the list and have already made new version to address Jurgen's early raised points.

One typical case for metric and operation-type tag is: these data object tags can be advertised to the subscribers together with data object xpath *before* a "pub/sub" service for YANG datastore updates and tell subscribers to specify selection filter targeted to specific category data objects, e.g., performance metric related data object, which help reduce massive data collection and processing and avoid multiple steps subscription.

In addition, when operation type tag is carried together with the metric tag, operation type will further classify the same performance metric data objects based on different operation types, make sure the same operation type data object can be aggregated together, aggregate average value data object with min value data object doesn't make sense.

Another case is: Suppose fetch all subscribed objects in all the relevant device modules to the subscribers in  one time is not issues, these data object objects tags can also help subscriber to process the subscribed untagged data objects and hit characteristics data or KPI data objects within the retrieved subscribed objects.

- Since this work is derived from work that I contributed to, I'd be interested in hearing what new mechanism(s) is/are covered by the IPR disclosure prior to supporting WG adoption.  I'm not asking in order to debate this, as that is something for other venues, I'm merely asking that you state for the record what new mechanism is covered.

[Qin] Thanks for asking, different from module level tag defined in draft-ietf-netmod-module-tags , this work provide data node level tag definition, use these data node level tag definition to provide hint or indication to selection filter in the YANG push and tell the collector or subscriber which specific category data objects needs to fetched.

Thank you

Lou

(as WG contributor and co-author of draft-ietf-netmod-module-tags)

On 8/17/2020 6:05 PM, Kent Watsen wrote:
This email begins a 2-week adoption poll for:

Notes:
   1)  -03 was presented during the 108 session, hence the I-D has been updated twice since then.
   2) Please be aware that IPR has been filed for this I-D:
         https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tags.

Netmod Chairs

netmod mailing list