Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities

From: "Wubo (lana)" <[email-masked]>
Date: Tue, 11 Aug 2020 11:10:21 +0000

Hi all,

1) is the problem important for the NETCONF WG to solve?

Yes, I think the extended per-node notification capability in this draft, including timer-based-trigger and threshold-based trigger,
could complement RFC8641 existing generic trigger mechanism.
And I believe that the NETCONF WG is the appropriate WG for this work, since these capability extends from notification capability model
defined in draft-ietf-netconf-notification-capabilities, which provides a good basis for server capabilities advertisement.

2) is the draft a suitable basis for the work?

I have reviewed the draft and it provides a good basis. If this work gets adopted, I am happy to review any version of this work
and contribute to any discussion and help move this work forward.

Best regards,
Bo

发件人: netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2020年8月6日 6:18
收件人: [email-masked]
主题: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:

   Title: Telemetry Data Export capability
   Link: https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities
   Abstract:
      This document proposes a YANG module for telemetry data export
      capability which augments system Capabilities model and provides
      additional telemetry data export attributes associated with system
      capability for transport dependent capability negotiation.

In particular, please discuss adoption-suitability as it regards to the following questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?

PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.

NETCONF Chairs

---

From: Qin Wu <[email-masked]>
Date: Wed, 12 Aug 2020 04:10:28 +0000

发件人: Andy Bierman [mailto:[email-masked]]
发送时间: 2020年8月12日 2:10
收件人: Qin Wu <[email-masked]>
抄送: Kent Watsen <[email-masked]>; [email-masked]
主题: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities

On Mon, Aug 10, 2020 at 7:09 PM Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
发件人: netconf [mailto:[email-masked]<mailto:[email-masked]>] 代表 Andy Bierman
发送时间: 2020年8月11日 3:39
收件人: Kent Watsen <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities

Hi,

I am trying to understand the problem this draft is attempting to solve.
The premise seems to be that the error handling and "hints" mechanism
in RFC 8639 and RFC 8641 do not work
[Qin]: The data export capabilities is not designed to replace error handling and is positioned as capability negotiation and used before netconf connection to be setup,  they are complementary,
error handling will be the last resort
When dynamic subscription request is declined or rejected. Error handling is only applicable to dynamic subscription
based on section 3.2 of RFC8641.

Our argument is why not prevent the problem to happen in the first place instead of waiting for the server making mistake and remedy it.
One of principle set by RFC8641 is:
minimize the number of subscription iterations between subscriber and publisher, discourage Random guessing of different parameters by a subscriber.

The solution being provided is generic, targeted to address this challenge, not only applicable to dynamic subscription, but also configured subscription.

IMO the solution approach does not scale well.
There is very little value for too much complexity.

[Qin]: I respectfully disagree, ;-),error handling doesn’t provide the client any hint about which transport protocol, which security schemes you should use.
We see draft-ietf-netconf-notification-capabilities-13 provides server capability advertisement which serve as a good basis for this draft and can be used not only at implementation time but also run time.
We also see draft-ietf-netconf-https-notif-04 provides Receiver Capabilities learning.

I also remember notification capability model defined in draft-ietf-netconf-notification-capabilities-13 has been refactored to make it more generic motivated by some new capability drafts and therefore can be used to accommodate
Other capabilities extension. This helps provide telemetry automation solution.

A set of capabilities for every possible data node that can be used with YANG Push
will be very large. Any yet, that is still mostly useless, since it is very likely that
the particular instances of the data node affect the push capabilities.
The filter used in the subscription will have a huge impact on the capabilities.

Take the most obvious entry -- for the "interface" list.  It is very likely that the
type of interface, or firmware revision of the line card, or any of a 1000 proprietary
details could change the push parameters supported for that interface.

[Qin]: In reality, we can not assume all data objects defined in the YANG data models support threshold handling capability
e.g., only integer built-in type data object support threshold handling,
another examples, we may need to suppress redundant data value reporting, so we may indicate to the client which set of data object has redundant suppress capability.
For some data object, they may support timer based trigger, we also need to indicate them to the client.

There are also very vendor-specific capabilities that impose an implementation design.
This is way out of scope. Example below: Does this mean all vendors need to change their server code
so it has a set limit per update, based on some new concept you made up called sensor groups??

[Qin]: These two parameters are debatable, Similar to max-nodes-per-update defined in draft-ietf-netconf-notification-capabilities-13:
max-nodes-per-sensor-group and max-sensor-group-per-update are two optional parameters. The reason to introduce these two parameters is
to align with gNMI implementation, which has sensor group concept, we think it is useful, that’s why we add them.
But they can be taken out if they introduce complexity.

     leaf max-nodes-per-sensor-group {

        type uint32 {

          range "1..max";

        }

        description

          "Maximum number of selected data nodes that can be sent

           per sensor group.";

      }

      leaf max-sensor-group-per-update {

        type uint32 {

          range "1..max";

        }

        description

          "Maximum number of sensor groups that can be sent

           in an update.";

      }

[Qin]:What do we define for max-nodes-per-sensor-group and max-sensor-group-per-update, is per system capability, not per node capability. You don’t need to expect each node to support such capability.

For per node capability, we only define three parameters, counter threshold support, timer based trigger support and suppress redundant support.
Which help you design appropriate subscription policy and send it through subscription request.

Andy

and the client needs to retrieve
extensive monitoring info to determine how to setup notifications on the server.

In theory this data could be used to prevent an <rpc-error> to be returned
for <establish_subscription> or <edit-config>

IMO the current approach is much better than this proposed approach.
The server can provide the hints based on the exact request from the client.
[Qin]: It may be late, still require multiple subscription iterations between subscriber and publisher. But data export has no intention to replace it. Error handling have its value in many different cases.
The static "per-node" monitoring data can be quite large, and yet not provide
the correct answer for a specific combination of subscription parameters..

[Qin]: It is server capability exposure, check early implantation time information of the capability what the server support (e.g., GRPC transport, TCP support, UDP transport support),
not targeted to keep track of dynamic change data.
These capabilities seldom change. In addition, to allow the client compose various different subscription policy (e.g., adaptive subscription), we require the server to indicate whether specific data object supports
Thresholds handling.
This is missing pieces to support event based telemetry solution.

Andy

On Wed, Aug 5, 2020 at 3:17 PM Kent Watsen <[email-masked]<mailto:kent%2Bietf@watsen..net>> wrote:

NETCONF WG,

NETCONF Chairs
_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 19 Aug 2020 00:23:20 +0800

Dear all,

I read the draft, regarding the two questions, the comments are as follows:

1. Is the problem important for the NETCONF WG to solve?
I believe that it is important to minimize the number of subscription iterations between subscriber and publisher on which transport protocol, encoding, security parameters, compression schemes are supported, what kind of subscription policy can be composed and Random guessing of different parameters by a subscriber is not desirable according to RFC8641. Data export aim at addressing these issues. I believe that the NETCONF WG is the appropriate WG for this work. Service capability notification defined in draft-ietf-netconf-notification-capabilities has been re-factored to be more generic and provides a good basis.

2. Is the draft a suitable basis for the work?
I think this draft has been mature enough and provide a solid basis for being moved forward. If this work gets adopted, I will be glad to review any update of this draft and contribute to relate discussion.

I believe it should move forward. If the draft gets adopted, I am willing to contribute to it.

Best regards,

Yuan ZHANG 张园 

China Telecom Research Institute 中国电信研究院
Tel: +86-18918588990
Email: [email-masked]