Thanks Lou for valuable comments, please see reply inline below.
发件人: Lou Berger [mailto:[email protected]]
发送时间: 2020年8月30日 2:40
收件人: Kent Watsen <[email protected]>; [email protected];
[email protected]
主题: 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 protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
