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

From: Qin Wu <[email-masked]>
Date: Sun, 30 Aug 2020 09:00:46 +0000

Thanks Lou for valuable comments, please see reply inline below.
发件人: Lou Berger [mailto:[email-masked]]
发送时间: 2020年8月30日 2:40
收件人: Kent Watsen <[email-masked]>; [email-masked]; [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:

    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.

Netmod Chairs

_______________________________________________

netmod mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 30 Aug 2020 12:04:38 +0200

On Sun, Aug 30, 2020 at 09:00:46AM +0000, Qin Wu wrote:
> 
> 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,

[...]

> however these statistics doesn't tell you whether in-errors is
> current value or average value or total value,

Wrong. The semantics of the counter types provided by ietf-yang-types
are well defined.

> so does count related data objects defined in ietf-dhcpv6-server of
> draft-ietf-dhc-dhcpv6-yang

[...]

These leafs are poorly defined and I expact that this will be fixed
before publication. (Standards for counters are relatively useless if
everybody implements different counters.)

/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/>

---

From: Lou Berger <[email-masked]>
Date: Mon, 31 Aug 2020 09:27:55 -0400

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]> wrote:

> *发件人:*Lou Berger [mailto:[email-masked]]
> *发送时间:*2020年8月30日2:40
> *收件人:*Kent Watsen <[email-masked]>; [email-masked]; 
> [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.
>
> 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
>
> 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/ 
> <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
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Yingzhen Qu <[email-masked]>
Date: Mon, 31 Aug 2020 20:35:28 +0000

Hi,

Here is my understanding of the node-tag draft. Please correct me if there is any misunderstanding.

This draft is an idea extension of the module-tag draft. Module-tag is to tag or categorize modules, for example, tag “ietf:routing” can be used to “group” together modules like ietf-routing, ietf-ospf etc, so users know easily that these modules are from the same category, and using this tag, they can further find all “ietf:routing” modules as ietf-isis etc. A tag is not meant to add or change functionalities of existing modules. Similarly, node-tag is to add tags at node level, like Lou’s point (b), it may provide some general functions.

I support the WG to adopt this idea and continue to work on it. Of course the draft needs some clarifications and good examples.

Thanks,
Yingzhen
From: netmod <[email-masked]> on behalf of Lou Berger <[email-masked]>
Date: Monday, August 31, 2020 at 6:29 AM
To: Qin Wu <[email-masked]>, Kent Watsen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
Resent-From: <[email-masked]>

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:

           +--ro statistics

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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2Fdistributed-tracing%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cd226c803dfa04411602c08d84db1d8bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637344773543517497&sdata=0YKLYMh59du2OkNyBDYblcutjnJz17WhvW98QwedW7c%3D&reserved=0>.

Thank you

Lou

    https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-tao-netmod-yang-node-tags-05&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cd226c803dfa04411602c08d84db1d8bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637344773543517497&sdata=imgMyvQNzXTix3PzfAsXxGY5KitQFlWzW6KQkn0bYCM%3D&reserved=0>
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2Fsearch%2F%3Fsubmit%3Ddraft%26id%3Ddraft-tao-netmod-yang-node-tags&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cd226c803dfa04411602c08d84db1d8bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637344773543527483&sdata=vp2UIwC5ZvcxUPEW3TlprfVUkjpcb%2BrFrlqQo9%2F8BiY%3D&reserved=0>.

Netmod Chairs

netmod mailing list

https://www.ietf.org/mailman/listinfo/netmod<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cd226c803dfa04411602c08d84db1d8bd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637344773543527483&sdata=7Clx5eavqA253RFMhrxHIbgHZes8%2Brn87ZLdEJedat4%3D&reserved=0>

---

From: 刘 鹏 <[email-masked]>
Date: Tue, 1 Sep 2020 02:00:36 +0000

Hi all,

I have the same understanding as Yingzhen，and support the adoption of this draft.

Regards,
Peng Liu

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105
email:  [email-masked]
________________________________
发件人: netmod <[email-masked]> 代表 Yingzhen Qu <[email-masked]>
发送时间: 2020年9月1日 4:35
收件人: Lou Berger <[email-masked]>; Qin Wu <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

Hi,

Thanks,

Yingzhen

Qin,

Lou

Hi,

A couple of comments:

           +--ro statistics

Thank you

Lou

Notes:

Netmod Chairs

netmod mailing list

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 1 Sep 2020 10:51:17 +0800

Hi all

    I support the adoption of the idea. It is a more convenient way to transfer information.

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Yingzhen Qu
Date: 2020-09-01 04:35
To: Lou Berger; Qin Wu; Kent Watsen; [email-masked]; [email-masked]
Subject: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
Hi,

 
 
Thanks,
Yingzhen
 
Qin,

Hi,
A couple of comments:

 
Notes:
 
Netmod Chairs

_______________________________________________netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod