Subject: Re: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription

From: "Ren Gang" <[email-masked]>
Date: Sun, 6 Feb 2022 12:31:13 +0800

Hi, WG:

I think this work can be used in many data collection scenarios to make it more efficient and support the adoption call.

                                     Ren Gang

                                     Tsinghua University

----------------------------------------------------------------------------------------------
From: netconf [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Mahesh Jethanandani
Sent: Tuesday, January 11, 2022 6:07 AM
To: Netconf <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]> >>
Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]> >
Subject: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription

Hi WG,

The authors posted -08 version of the draft just before the new year, which addressed the comments they received in IETF 112.

 https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscription-08.txt

This starts a 2 week poll ending on January 24, to decide whether this document should be made a WG document or not. Please reply to this email whether or not you support adoption of this draft by the WG. Indications that the draft has been read will be also be appreciated. The Intended Status of the draft is Standards Track.

A separate IPR call will be issued on the draft.

Thanks.

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

---

From: 熊春山 <[email-masked]>
Date: Sun, 6 Feb 2022 14:56:52 +0000

Hi, WG,

I have read this draft, I think the draft is a good starting point, I am willing to review and contribute to this draft.

Chunshan Xiong

CICTMobile

To: Netconf <[email-masked]<mailto:&lt;[email-masked]> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]> >>

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

Hi WG,

Thanks.

Mahesh Jethanandani

---

From: Qin Wu <[email-masked]>
Date: Mon, 7 Feb 2022 04:44:52 +0000

Hi, Zixiong:
Thank for your interests in this work and valuable review, please reply inline below.
>发件人: netconf [mailto:[email-masked]] 代表 Zhixiong Niu
>发送时间: 2022年2月6日 14:24
>收件人: [email-masked]
>主题: Re: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription

>Hi, folks

>Thanks for writing this draft and providing an extension to YANG push RFC. If my understanding is correct, the current YANG Push mechanism only allows you to select a fixed sampling rate. You may set the sampling rate too high, which the
>device cannot afford, or you may set the sampling rate too slow, which cannot capture enough data.

>One alternative solution is to use on change subscription, which has already been defined in RFC8641. However, if my understanding is correct, on change subscription is not suitable for data that changes frequently and consumes a
>tremendous amount of CPU resources device cannot afford as well.

>So the idea of this draft is to choose one compromised, or optimized solution that allows the device to switch sampling rate dynamically, but this also require the devices to be configured explicitly with multiple sampling intervals.

>I think this idea is similar to Microsoft adaptive sampling mechanism, although it doesn’t use the YANG model to define such a mechanism. I think the concept is similar.
[Qin Wu] Yes, Microsoft adaptive sampling in Azure is related (https://mailarchive.ietf.org/arch/msg/netconf/whMFjU6i8idoF3Q3AOvshCQkYog/), thanks for pointing this out.
The common goal is to reduce I/O contention and resource while maintain a certain level accuracy when facing massive data collection, currently we focus on how the data is reported in which time interval, instead of how the data is measured or sampled.
Routers and switches function as embedded monitoring probes and do not have enough computing power to monitor network traffic on high-speed links.  If every packet was captured and its statistic recorded, too much CPU power, cache memory and network bandwidth would be consumed in order to record, store and export data to the collector. Optimal packet sampling is a method that effectively reduces the measurement overhead in context of device’s resource usage and bandwidth consumption but at the cost of sacrificing some data accuracy.
>Therefore, I think this draft is a good starting point and could benefit to use Microsoft adaptive sampling as input, e.g., I am wondering whether this draft support configuration on packet sampling, e.g., minimum sampling percentage or
>maximum sampling percentage?
[Qin Wu] It is a good question, in the current draft, we right now more focus on using per packet monitoring and capture all the packets. But we could also consider time based sampling or counter based sampling if there is interests to do so and a clear use case, e.g., Microsoft Azure adaptive sampling use case.

>Section 2.1 last two bullets:
>What is the relationship between watermark and xpath-external-eval? It looks to me, xpath-external-eval has to be represented using watermark parameters which is a constant value and datastore node. Maybe a watermark parameter is
>not needed.
[Qin Wu] You are right, watermark parameter is part of xpath-external-eval. Take thermostat as an example,
“
module thermostat {
…
leaf actual-temp {
type int32;
config false;
units “degrees Celsius”;
description “The measured temperature”;
}
}
”
You might need to measure actual temp and but you also want to control actual-temperature not greater than a preconfigured threshold, e.g, actual-temp<80,  in this case, 80 is the preconfigured threshold or watermarks.
If you want to control actual-temperature not less than a preconfigured threshold B, e.g., actual-temp>10, in this case, 10 is another watermarks or preconfigured threshold.
So you are right, the waterwark  taken out from xpath-external-eval, in some cases, it is not required.
>Nevertheless, I do not have a strong opinion about this.

>--
>Best,
>Zhixiong

发件人： Mahesh Jethanandani<[email-masked]<mailto:[email-masked]>>
收件人： Netconf<[email-masked]<mailto:[email-masked]>>
抄送： draft-wang-netconf-adaptive-subscription<[email-masked]<mailto:[email-masked]>>
主题： Re: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription
时间： 2022-01-25 06:19:39

We have received a tepid response to this adoption call, and are therefore extending this adoption call by another two weeks to February 7. At that time, and unless we receive any objections, we are going to go ahead and adopt this draft.

We are aware of least two implementations of YANG Push, and this draft is an extension of that work.

Cheers

On Jan 10, 2022, at 2:07 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

Hi WG,

 https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscription-08.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-netconf-adaptive-subscription-08.txt&data=04%7C01%7CZhixiong.Niu%40microsoft.com%7Cd2c1ad3002f6435db18f08d9e932f3df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797227984116232%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=COTDhD5eRLCOPwjBwKZqbsg6RPiR8ihr69QZ2sv5Q60%3D&reserved=0>

Thanks.

Mahesh and Kent (as co-chairs)

---

From: "maqiufang (A)" <[email-masked]>
Date: Mon, 7 Feb 2022 09:31:05 +0000

Hi, Yongbo,

Thanks for your support and comments, please see my reply inline.

From: 刘永博 [mailto:[email-masked]]
Sent: Wednesday, January 26, 2022 6:55 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:RE: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription

Hi, all
I ‘ve read this document and support the adoption of this work.

We are currently paying our attention to some work about how telemetry can help solving closed loop automation and the future intent based networking.
If there exists a mechanism to allow the server to adjust the period automatically, it makes it possible to quickly adapt to network condition changes and detects real-time network failure, while reduce resource consumption (e.g., network bandwidth, telemetry data processing, telemetry data storage).
I believe this work is definitely a useful piece.
[Qiufang Ma] Thanks for that! Hopefully you can keep contributing to this work.:-)
After reading the draft, I have the following comments:

•         Section 1 Introduction

o   " The periodic interval is set to zero value in the on-change subscription case. "

I am not sure this statement is accurate enough, as defined in RFC8641, for on-change notification, update trigger occurs whenever a change in the subscribed datastore nodes is detected. And YANG-PUSH also allows a subscriber to set a dampening-period, it may be zero but doesn’t have to be, right?
[Qiufang Ma] Good catch, we will remove this sentence in order to avoid confusion and ambiguity.

•         Section 2.1 Subscription Configuration

·         Is the parameter “watermark” necessary here? As your usage example shown in Appendix, the XPATH evaluation expression can already indicate the threshold value, so what’s the consideration to define a “watermark” data node?

[Qiufang Ma] A watermark value can be used if one object to be compared in the XPATH expression is a leaf instance, while others is a number data type. Watermark is used to define that threshold value of the targeted data object.

But this is an optional parameter, in some cases other than a threshold comparison, this parameter can be omitted.

•         Section 4 Adaptive Subscription YANG Module

·         Is there a need to define “centiseconds” and “seconds” in your YANG module? I haven’t seen you use the type “seconds” and “centiseconds” has already been defined in RFC8641. Since you import ietf-yang-push module, there is no such a need to define it again, right?
[Qiufang Ma] Yes, you are right. This will be removed in the next version, thanks!

•         Section 5 IANA Considerations

·         Both sec 5.1 and sec 5.2 states that this document registers two URIs/YANG modules, but there is only one URI and a single YANG module has been defined.

[Qiufang Ma] That might be a copy/paste error, I will also fix it in the next version, thanks!

Best Regards,

Qiufang Ma

Thanks,
Yongbo Liu

From: netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Tuesday, January 25, 2022 6:19 AM
To: Netconf <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription

Cheers

Hi WG,

Thanks.