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

From: Johnson Zhu <[email-masked]>
Date: Fri, 14 Nov 2014 00:30:09 +0000

Hi,

We am trying to understand how YANG and NETCONF support the long running command (e.g ping)

It seems that rpc statement of YANG only contains one-time return value, it is impossible to feedback  each ping ack message to netconf client side. so I check if it is discussed in  the WG.
  Here is the summary:
   One post propose an approach [1] to support long running command which can notify ping result via notification channel of yang, but it seems it is rejected by [2]
   and there is a similar mechanism [3] in NETCONF WG,  but the proposal is not work group draft yet.

 [1] - http://www.ietf.org/mail-archive/web/netmod/current/msg09785.html
 [2] - http://www.ietf.org/mail-archive/web/netmod/current/msg10038.html
 [3] - http://tools.ietf.org/html/draft-mahesh-netconf-persistent-00

So any recommendation how to proceed/define the long running command?

Thanks
/Johnson

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 17 Nov 2014 19:15:10 -0800 (GMT-08:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: Nov 17, 2014 5:33 PM
>To: Kent Watsen <[email-masked]>
>Cc: Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] how YANG and NETCONF support the long running command (e.g ping)
>
>On Mon, Nov 17, 2014 at 5:27 PM, Kent Watsen <[email-masked]> wrote:
>>
>>>No, the problems are different.  ZWP closes the window.  The
>>>concern here is that the client may read events at a slower rate
>>>than the server generates them.   The client's window would
>>>more-or-less alternately open and close, but the server queue
>>>would grow without bound.
>>
>> Without bound?  The local send-buffer should become full and then
>> pending/subsequent write requests would either 1) block until all the data
>> is sent (for a blocking socket) or 2) return EAGAIN or EWOULDBLOCK (for a
>> non-blocking socket)
>>
>
>I think Randy is suggesting (or I am) that a solution that models the results
>in a ring buffer (like the notification replay buffer or usrHistoryTable)
>will lose results in a predictable way. Gaps in sequence IDs can identify
>what was lost.

My immediate point was that the analogy to ZWP didn't apply.
The secondary point was that using a configuration management
channel to convey the output of a more-or-less arbitrary application
doesn't make sense, particularly if an application's output might
exceed either the capacity of the communication channel or
the consuming application(s).  Andy's proposal is one way
of working around the problem; whether it is optimal depends
on the nature of the managed application and its output.
There's more to life than ping.

>IMO we should not expect the server to execute operations and
>collect results forever.  We should not specify implementation
>details either, like the select loop that must be used.

Agreed.  However, I'm really bothered by the implication that
the Netconf server application is what's *executing* the operations.
I think that's a huge mistake in modeling, and would reflect a
problematic implementation strategy.  This discussion has already
illustrated some of the pitfalls.  Consider:  How is starting up
a long-running "ping" any different from initiating a management
script which awk/perls multiple tail -f commands? Where does it end?

Randy