Re: [Netconf] netconf call home connection type

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> 
> >> Your goal appears to be to support periodic YANG-push subscription.
> >> Presumably configured subscriptions (since dynamic subscriptions are
> >> effectively "persistent" connections).  I assume that you're thinking
> >> that the e.g., coap-notif augments in a leafref to a coap-server that
> >> is "on-demand", and that the "demand" is from YP periodic trigger.
> >
> > I think the leafref can point to a client with any kind of connection;
> > on-demand, periodic or persistent.
> 
> Are you implying connection sharing, multi-channeling?   Please define
> the behavior you're expecting in each case.  What transport protocol 
> requirements are there?

Good point.  This issue exists also in the current model, since
"periodic" also covers on-demand.  Anyway, I think that limiting to a
single session is too restrictive.  So it seems ok to allow the server
to start multiple sessions (note that w/ ssh, a session *may* be just
another channel).  If we agree that multiple sessions are ok, do we
put any limit on the number of sessions?  Probably not, imo.
Implementation detail.

> >> Perhaps, rather than defining a seemingly incomplete "on-demand" 
> >> connection type, the "notif" drafts could augment in an "subscription-
> >> driven" connection type into the appropriate ietf-foo-server model?
> >> Thus giving the "demand" some meaning?
> >
> > I agree w/ Juergen here.  "demand" gets meaning from populating the
> > leafref in the <protocol>-notif model.  There is no reason to have one
> > connection type per "trigger"; in fact that would be problematic, it
> > is not unreasonable to have multiple such "triggers" pointing to the
> > same "call-home/netconf-client."
> 
> Agreed.  Assuming you count all of YP+SN (really the notif drafts) as 
> just one trigger.  The "subscribed-notifications" connection-type would
> be once per transport type, not transport instance.  Any other "trigger"
> examples?  Are they always configured with something like the leafref 
> we've discussed for the notif drafts?

I think so.

> > I think the difference between "scheduled" (with anchor-time) and
> > "periodic" (without anchor-time) is quite subtle.  Do we really need
> > both?  (note that in the YP model anchor-time is optional)
> 
> ACK
> 
> 
> > I'm disturbed by the "on-demand" part of the periodic/scheduled 
> > definition.  The original idea was that the "demand" part would be
> > something like the need to push logs
> 
> > Maybe we need both; "strictly periodic/scheduled" and
> > "periodic/scheduled + on-demand".
> 
> Confused.  Not sure how this helps, and above you said that you'd 
> want to point to any connection type, including persistent.

I meant that in some cases it might be useful to let the *operator*
define a connection type to be "strictly periodic", i.e., the server
will NOT create any sessions on demand.   In some other cases maybe
the operator want periodic connections, but it is ok with on demand
connections as well (this is the current "periodic").

So for netconf-notif, I envision a leafref to a "client", with text
that explains that if the connection type is:

  o persistent then the notif is sent "immediately" (if possible,
    otherwise queued).

  o "strictly periodic" then the notifs are queued until the next
     period starts (implementation-specific qlen)

  o  "periodic" or "on-demand" then a new session is started
     (meanwhile notifs are queued), and once the session is started,
     the notifs can be sent


> >> but, as per the YP discussion,
> >> there might be a whole other connection for that purpose.  In a
> >> multi-manager scenario, it makes sense to periodically call-home
> >> to the "provisioning" system while separately send logs on-demand
> >> to the "monitoring" system.
> >
> > *if* they are different systems.  It is not unreasonable to also send
> > logs to the provisioning systems.
> 
> Yes, both scenarios exist and need to be supported.
> 
> 
> >> If a device had configuration for a
> >> periodic or scheduled (or even persistent), it still wouldn't know
> >> to use that connection for the logs; the "demand" part, which 
> >> seems rational to define, never materializes.
> >
> > Huh?  It would know this b/c of the leafref from netconf-notif to
> > call-home/netconf-client.  Maybe I misunderstood what you mean.
> 
> 
> Sorry, I was unclear.  Yes, holistically, the configuration resolves
> where the demand comes from, assuming that there is indeed a configured
> subscription having a leafref to an "on-demand" connection type.  But
> that's my point, the configuration isn't assured.  The "on-demand"
> connection could be configured and no one points to it.  There is no
> back-pointer.  There's nothing that says at least one leafref must
> point to it.  s/on-demand/configured-subscription/ provides clue, but
> doesn't prevent orphaned config.

Aha, ok, I see.  Well, this is, as you say, just orphaned config.  I
think that is ok.


/martin