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

On Mon, Aug 10, 2020 at 7:09 PM Qin Wu <bill.wu@huawei.com> wrote:

> *发件人:* netconf [mailto:netconf-bounces@ietf.org] *代表 *Andy Bierman
> *发送时间:* 2020年8月11日 3:39
> *收件人:* Kent Watsen <kent+ietf@watsen.net>
> *抄送:* netconf@ietf.org
> *主题:* 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.

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.

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??

     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.";
      }

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 <kent+ietf@watsen.net
> <kent%2Bietf@watsen..net>> wrote:
>
>
>
> 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
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>