Re: [Netconf] netconf call home connection type

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> >> > 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.
> 
> Yes, the issue exists in the current model too.  That is what my 
> previous email was lamenting.  I can't quite figure out how it 
> would work.
> 
> RFC 8071 says that the client starts the NETCONF-client protocol 
> (i.e., creates an SSH channel and starts the "netconf" subsystem).  
> In SSH, the SSH-client must open the channel, the SSH-server can't do
> it.

Duh.  Of course.  Ok, but this doesn't really change anything, except
if that if the server wants to start two sessions, it will use two TCP
connections.

> So, let's say that the client knows (because it configured it)
> that the server also pushes event notifications.  So, then what? 
> Does it send a special RPC (TBD in a future NN draft) or open 
> another SSH-channel to, perhaps, start an altogether different 
> protocol (coap?) to receive the logs?

As has been mentioned before, it would have been nice if the server
calling home had some way of informing the client of *why* it called
home.  This could possibly be done (in NETCONF) with a special
capability:

  urn:ietf:...:calling-home?have-notifications
  urn:ietf:...:calling-home?by-config
  urn:ietf:...:calling-home?have-alarms

> What if there are different
> "triggers" all pointing to the same netconf-server instance and
> all using "coap"; the server can't use the transport alone to
> know what to push to each.  It seems that the client has to send
> an RPC of some sort in each to bind the transport to a purpose.
> But then we're in the realm of dynamic subscriptions and questioning
> the value of on-demand connections.  [And then there's RESTCONF,
> do we assert that both the client and server run HTTP2?]

This is related to the question of when the server can send the
notifs, but I think that this also can be handled w/ capabilitites
rather than requiring an extra rpc; if the client adervtises the
capability "urn:ietf:...:call-home-notifications", then the server can
start to send the notifications immediately.


> All this trouble is because we want to repurpose a NC/RC call-home
> connection, so that there is only a single TCP connection (is this
> the goal?

No, I think the goal is to let the server and clients have the same
roles as they do in the normal case, using the same authentication and
authorization mechanisms.

> why would two device-->NMS connections not be as good?).

This is fine imo.

> But, in my view, YP+SN is better served as a client: the publisher
> connects and pushes content to the receiver.

Do you mean that the publisher would be a NETCONF client and the
receiver a NETCONF server?  But see below!  This should be discussed
in another thread.

> This resolves most 
> issues, and there is no need for an incompletely defined (in that
> it's description statement would say "for reasons not described 
> here") and possibly orphaned on-demand connection type.  The only
> problem I see is that it necessitates the use of another connection
> when the provisioning system and the monitoring system are in fact
> the same, but I don't see that as an important issue, from an 
> operator perspective and second device-->NMS connection is not
> an issue I'm aware of.
> 
> Back to the subject line, my suggestion (for this one issue) is:
> 
>    - persistent (unchanged)
>    - periodic   (unchanged, keep the on-demand language)

I think we have identified four possible connection types.  It would
be good to check with thee WG which of the four people think are
useful.  (probably start a fresh thread, not sure people follow
this...?)

  - persistent
  - on-demand
  - periodic-with-on-demand
  - strictly-periodic

>    - let the "notif" drafts, for configured subscriptions:
>       - use <protocol>-client connections (recommended)
>       - use <protocol>-server call-home connections (not recommended)
>           - augment in an "subscribed-notifications" call-home 
>             connection type and leafref that connection-type
>           - and/or resolve what it means to point to (repurpose) a 
>             persistent or periodic connection

I think we should move this discussion to another thread - if/when we
define protocol bindings for configured subscriptions.

> > 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").
> 
> I'm unsure if this is needed.  Either case, the standard call-home 
> interaction occurs, even for the unexpected "on-demand" connections 
> and, if the operator, in its config, leafref-ed a call-home connection
> for yang-push also, then they did it on purpose.  If the operator
> wants strictly-periodic, don't configure anything that might cause
> an on-demand connection. Right?

So how would an operator configure YP then, if the only connection
types available are "persistent" and "periodic-with-on-demand"?

> > 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
> 
> Maybe.  I'm not yet buying the need to repurpose a call-home 
> connection for yang-push.

It is not just YP, but notifications in general.


> > Aha, ok, I see.  Well, this is, as you say, just orphaned config.  I
> > think that is ok.
> 
> Yes, orphaned config is a small worry in all this.   
> 
> FYI, another niggle I'm getting is how all repurposed call-home 
> connections might be supported by generic server frameworks like 
> NCS.  Would NCS examine the device config, determine how many
> triggers might have caused this and then, how each, start the
> trigger-specific action to see if it was the reason why the 
> device called home?

Why do you call then "repurposed"?  This is a problem in general with
call-home; how does the client know what to do?  An indication of why
the server called home might help.


/martin