Re: [Netconf] netconf call home connection type

[Martin Bjorklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> 
> 
> > Hi,
> >
> > In draft-ietf-netconf-netconf-client-server-06, each "netconf-client"
> > in the "call-home" list has a list of endpoints and a
> > "connection-type".  The connection type defaults to "persistent".
> 
> > I suggest we add a new connection type case "on-demand" or something
> > similar, which can be used e.g. when there is something external to
> > trigger the call home.  
> 
> "periodic" is meant to cover on-demand also.

But even if it allows on-demand, it will still do periodic connects.

> Very early slides on all
> this used to call it "periodic + on-demand".  The "reconnect-timeout" 
> description statement says: 
>  
>   In ietf-netconf-client:
>     The NETCONF client may initiate a
>     connection before this time if desired
>     (e.g., to set configuration).";
> 
>   In ietf-netconf-server:
>     The NETCONF server may initiate a connection before
>     this time if desired (e.g., to deliver an event
>     notification message).";
> 
> 
> > An example would be a periodic yang push subscription.
> 
> Right, "to deliver an event notification message".
> 
> 
> > I also suggest that the default connection strategy either is 
> > dropped, or changed to "on-demand".
> 
> This was discussed at the IETF 102 meeting (see attached slide and
> lines 329-335 in the minutes).  Essentially, folks want to add a
> "periodic" feature enabling the initiating peer to optionally
> support periodic connections.  As such, I don't think it should
> be the default.

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

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.

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'm ok with removing the default and making the choice mandatory.


> > Also, looking at the "periodic" case, when have in ietf-netconf-server:
> >
> >           |        +--rw periodic!
> >           |           +--rw idle-timeout?        uint16
> >           |           +--rw reconnect-timeout?   uint16
> >
> > In YANG Push, we have:
> >
> >           |  +--rw yp:periodic!
> >           |     +--rw yp:period         yang:timeticks
> >           |     +--rw yp:anchor-time?   yang:date-and-time
> >
> >
> > does it make sense to use similar parameters in these two cases?
> 
> The YANG Push parameters have no equivalent to "idle-timeout".

Sure, this is quite obvious.

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

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


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

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

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



/martin