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 <bill...@huawei.com> wrote:
Thanks Lou for valuable comments, please see reply inline below.
*发件人:*Lou Berger [mailto:lber...@labn.net]
*发送时间:*2020年8月30日2:40
*收件人:*Kent Watsen <kent+i...@watsen.net>; netmod@ietf.org;
draft-tao-netmod-yang-node-t...@ietf.org
*主题:*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/
<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
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
