Subject: Re: [netmod] how YANG and NETCONF support the long running command (e.g ping)

From: Randy Presuhn <[email-masked]>
Date: Sat, 15 Nov 2014 12:22:24 -0800 (GMT-08:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: Nov 15, 2014 10:20 AM
>To: Randy Presuhn <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] how YANG and NETCONF support the long running command (e.g ping)
>
>On Fri, Nov 14, 2014 at 7:38 PM, Randy Presuhn
><[email-masked]> wrote:
>> Hi -
>>
>>>From: Kent Watsen <[email-masked]>
>>>Sent: Nov 14, 2014 7:17 PM
>> ...
>>>Regarding the "persistent", "fragmentation" and "datastore-push" drafts,
>>>and related ideas floating around, I believe that there are the following
>>>use-cases:
>>>
>>>
>>>1) request for an unbounded number of periodic responses sent relatively
>>>frequently (ping)
>> ...
>>>4) request for an action that takes a long time to perform (network link
>>>performance validation)
>>
>> I think the analysis neglects an important dimension of (1) and (4).
>> Particularly for management applications, there may be multiple
>> consumers of the (intermediate and final) results of these operations.
>> An RPC-centric approach scales poorly for these.  If I have three
>> management systems in different control centers interested in the
>> latency of a particular link, they shouldn't need to be running
>> three separate ongoing tests concurrently.
>>
>
>
>Are you suggesting an alternate solution path?

I'm suggesting that (at least) it should be modeled differently.
As I see it, setting up long-running operations is really
no different from configuring an application, and should
not be modeled any differently from how one would configure
any other long-running application.

Whether a configuration management protocol is the correct
choice for gathering intermediate and final results from
a long-running application is a separate question.

>Multiple consumers sounds like a pub/sub model, and perhaps
>some multicast transport. IMO, we need that more than
>"CLI-over-NETCONF".

While I wouldn't go so far as to suggest multicast transport,
I very much agree that "CLI-over-NETCONF" can lead to some
choices that don't make much sense to me.

>Another problem that seems to be ignored here (except by Martin)
>is the resources required in the server to buffer unlimited events
>while the client is blocked (at TCP level).  The server is expected
>to concurrently invoke the periodic commands and independently
>buffer the output for each client to accept at their leisure.

This is another strong argument in favor of decoupling the
configuration of long-running applications from the gathering
up of their outputs.

>The NETCONF replay buffer is not unbounded.
>Long running commands like "ping" need to account for
>limited resources on the server.

This, too, is an argument in favor of decoupling the
mechanism used to configure the application from the
mechanisms used to gather results.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 15 Nov 2014 13:57:44 -0800

> mechanisms used to gather results.

Hmmm, sounds familiar... something like the usrHistoryTable I wrote
for RFC 2021?

Setting up periodic collections of data nodes in buckets is not
much different than collections of periodic "action results".

I think long-lived non-periodic actions would need a different
solution anyway (e.g, OK if <install-image> is RPC-based).

> Randy

Andy

>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod