Re: [Netconf] netconf call home connection type

[Kent Watsen <[e-mail]>]

>> "periodic" is meant to cover on-demand also.
>
> But even if it allows on-demand, it will still do periodic connects.

Correct, that's the point of this configuration.  Maybe we need to
define another enum called "on-demand"?



> Well, I didn't suggest to make "periodic" default; I suggested to make
> an explcit "on-demand" as default.

Popping back to your previous comment on this, per your suggestion, I
replaced the default with "mandatory true".


> Also, I don't agree with the statement that periodic call home is not
> commonly supported.  With our proprietary "call home" protocol, it is
> always used.  And IIRC the TR-069 call home feature also relies on
> periodic call home.

Good points.


> In fact, I don't understand when "persistent" will be used.  As soon
> as you have a somewhat large set of devices to manage, you can't
> maintain persistent connections to all of them.

I have seen persistent connections used.  The "persistent" container's
description statement says:

    This connection type minimizes any NETCONF client
    to NETCONF server data-transfer delay, albeit at
    the expense of holding resources longer.";

and netconf-client-server-06 Section 5.6.4 says:

   Support both persistent and periodic connections

   NETCONF clients may vary greatly on how frequently they need to
   interact with a NETCONF server, how responsive interactions need to
   be, and how many simultaneous connections they can support.  Some
   clients may need a persistent connection to servers to optimize real-
   time interactions, while others prefer periodic interactions in order
   to minimize resource requirements.  Therefore, when it is necessary
   for server to initiate connections, it should be configurable if the
   connection is persistent or periodic.





>> This
>> is what is sometimes called a "linger-timeout".  The connection stays
>> open a little while longer in case the remote peer has a follow-up,
>> as they often do.  There would be no need for YANG-push to have this
>> concept, being primarily a one-way flow.
>
> Not really; it is not needed in YANG puch b/c the push parameters
> define *how often to poll*.  This is unrelated to the call home
> parameters.  For example, I can envision a situation where you want to
> poll say once an hour, but then call home once a day.  

I'm unsure what your point is, but I note that this use-case is satisfied
if YP (via SN and NN) ref-ed a netconf-server instance that had "periodic"
(which is intended to also support on-demand) with the periodicity of 24
hours.  And the concept of the idle-timeout (a linger timeout) is good.


> Also, you can have a dynamic subscription (w/o call home) with
> periodic YANG push.

Of course.


>> The client-server drafts have no equivalent to "anchor-time", some
>> point in the future after which connections begin.
>
> It is not a time in the future.

The description statement says before or after.  Maybe the description
statement is unclear in its intent.  In the context of the client-server
drafts, "before" makes no sense (there is no replay), so only "after"
remains, hence my "future" comment.


>> This looks complex with questionable value, worth keeping?
>
> If used in the server model, it can be used to handle a large number
> or devices to ensure that not all of them call home at the same time.

Programming the "periodic" connections on exact time boundaries 
might be over engineering it, but maybe not. Does it matter if 
a device  calls-home once a day vs exactly at 3am every day?

As currently defined, even if all devices were configured to do 
"periodic" at the exact same time, they eventually diverge as 
random delays skew  each device's counters.  A spread occurs 
over time and, besides, there are techniques for handling load.


> To be clear, I think we should have: (in the server model)
>
>           |        +--rw periodic!
>           |           +--rw idle-timeout?       uint16
>           |           +--rw period?             uint16
>           |           +--rw anchor-time?        yang:date-and-time

What if period is not set?  
What if anchor-time is not set?

In YP, "period" is mandatory but, still, the description statements
aren't clear.


Kent // contributor