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

From: "Per Andersson (perander)" <[email-masked]>
Date: Thu, 3 Feb 2022 09:29:08 +0000

Hi!

Mahesh Jethanandani wrote:
> 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 <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.

After a discussion with collegeous we concluded the following
objections.

(This mostly reiterates Andy's comments.)

1. Difficult to grasp the problem this draft aims to solve. Currently
   the client can control a YANG-Push subscription at will with e.g.
   modify-subscription. In what situation would a server need to control
   this for the client? Put another way, why/when should the decision
   for the subscription change be moved from the client to the server?

2. Heavy arbitrary XPath evaluation at every event seems expensive.

3. Solution seems to be very limited in application. Case in point,
   only uint32 leaf values for watermark is supported. What about use
   cases with other types, e.g. enums or, even,  booleans describing
   watermark level.

--
Per Andersson
[email-masked]

---

From: Zhixiong Niu <[email-masked]>
Date: Sun, 6 Feb 2022 06:23:57 +0000

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.

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?

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.

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>

A separate IPR call will be issued on the draft.

Thanks.

Mahesh and Kent (as co-chairs)

---

From: "maqiufang (A)" <[email-masked]>
Date: Mon, 7 Feb 2022 14:06:45 +0000

Hi, Per,
Thanks for your comments, please see my reply inline.

-----Original Message-----
From: Per Andersson (perander) [mailto:[email-masked]] 
Sent: Thursday, February 3, 2022 5:29 PM
To: Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>
Cc: [email-masked]
Subject: RE: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription

Hi!

Mahesh Jethanandani wrote:
> https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscripti
> on-08.txt 
> <https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscript
> ion-08.txt>
> 

After a discussion with collegeous we concluded the following objections.

1. Difficult to grasp the problem this draft aims to solve. Currently
   the client can control a YANG-Push subscription at will with e.g.
   modify-subscription. In what situation would a server need to control
   this for the client? Put another way, why/when should the decision
   for the subscription change be moved from the client to the server?
[Qiufang] The motivation is to reduce CPU, I/O and memory resource consumption in the device and network bandwidth consumption in the management interface when facing massive data collection.
YANG Push modify-subscription relies on centralized management system to increase update interval and anchor time which has slow response to network change. 
The idea to preconfigure the device with multiple update intervals and subscription policy, which allows the device or server to switch update interval automatically. Please also see 
https://mailarchive.ietf.org/arch/msg/netconf/tmxBLa3W2kCZqeCy_2rgty-LD3o/ 
https://mailarchive.ietf.org/arch/msg/netconf/Bqq9HDEMP26Zpjk9MKE9zW3iPBk/

2. Heavy arbitrary XPath evaluation at every event seems expensive.
[Qiufang] See the "Sec.3 Arbitrary XPath Complexity Evaluation" for clarification(https://datatracker.ietf.org/doc/html/draft-wang-netconf-adaptive-subscription-08.txt#section-3), 
we have never advocated the server to support heavy arbitrary xpath evaluations at every event. 
 It is close to periodical subscription, we evaluate xpath expression at each interval. Several design principles are given to reduce the complexities,
 one of which is to allow a server to only support a minimal set of data objects be selected as an xpath evaluation.
 If a server receives an xpath expression which is too complicated for it to parse, an RPC error with "xpath-evaluation-unsupported" is also defined.

3. Solution seems to be very limited in application. Case in point,
   only uint32 leaf values for watermark is supported. What about use
   cases with other types, e.g. enums or, even,  booleans describing
   watermark level.
 [Qiufang] I sort of agree to set watermark as unit32 data type is restrictive, actually the watermark can be scalar vairiable of any data type,
it is part of xpath-external-eval expression. 
The datatype of watermark can be set to union which should be consistent with targeted data object in the xpath-external-eval. I think we either remove watermark parameter or set watermark into union type.

Best Regards,
Qiufang Ma

--
Per Andersson
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Mon, 7 Feb 2022 22:35:22 +0000

The chairs see an increase in adoption-call responses - thank you all!

Some concerns have been raised, which means that we cannot adopt the draft at this time.  We encourage discussions to continue about the concerns raised.  To those claiming implementations, please consider providing performance data that may help alleviate the concerns raised.

Thank you,
Kent (and Mahesh)

> On Jan 24, 2022, at 5:19 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
>> On Jan 10, 2022, at 2:07 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi WG,
>> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf