Re: [Netconf] netconf call home connection type

[Kent Watsen <[e-mail]>]

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

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? why would two device-->NMS connections not be as good?).
But, in my view, YP+SN is better served as a client: the publisher
connects and pushes content to the receiver.  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)
   - 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 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 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.


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


Kent // contributor