Re: [Netconf] netconf call home connection type

[Kent Watsen <[e-mail]>]

> Duh.  Of course.  

Well, I have had to correct people before.


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

Yes.


> 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

Perhaps.  We'd need a registry to enable mappings, etc.  I generally
like the idea and, if this can be solved, then a lot my objection goes
away.  The biggest issue is that it wouldn't work for RESTCONF.  Maybe
RFC 8071 can be updated to add:

 - the server MUST (SHOULD?) implement some "ietf-call-home" module 
   that defines an RPC called "call-home-reason" that returns an 
   identifier (a base identity) that indicates the reason for the
   call-home connection.

 - the client SHOULD (MUST?), as a first step, use said RPC to 
   determine the reason the server initiated the call-home
   connection.



>> 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.
>
> This is related to the question of when the server can send the
> notifs, 

No, my point is that, even before that, the client needs to know
the reason for the call home connection (foo, bar, baz) and, for
each trigger, there may be a different RPC needed to get the data.
How would the client know which RPC to send to collect each type
of data?



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

In keeping with foo, bar, baz, I suppose that the client would advertise
a capability for each, and the data sent must be self-typing, such that
even a binary coap session could distinguish between a foo and a bar 
being sent.

That might work for NETCONF.  I don't know what the RESTCONF equivalent
might be.  Maybe a NETCONF-only solution is okay, but I'd rather seek
solutions that work for both (hence the above suggestion for an RPC).



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

Yes, maintaining roles is goodness, but it's not so important when
configuring "push" flows, where it's okay to let the device be the
protocol-client because it's a secondary purpose (fault-monitoring
is secondary to provisioning).

BTW, while I enjoy the entertaining the idea, you should know that 
I don't support NC or RC based configured subscriptions (and I can
hardly think of another reason for why a device might want to call
home "on-demand").  There was a message I sent when you were sailing
(bet you're missing it now) where I said that we instead focus our
limited resources on defining 1) something easy (pushing XML/JSON 
over a device-initiated HTTP connection, where the device  is the 
HTTP-client), and/or 2) something fast (pushing binary over a 
device-initiated coap connection, where the device is the COAP-
client).



>> why would two device-->NMS connections not be as good?).
>
> This is fine imo.

Great.  Then let's take SSH channels off the table.  It difficult
to figure out, notwithstanding it muddies the "reason" for why 
the device called home.  E.g., it calls home for "persistent-
connection" reason but, then, in the middle of it, it opens an
SSH channel for reason=yang-push?  This seems to conflate too 
much.  Simpler is for the device to make a new on-demand
connection, for each on-demand connection it wants to make. 
The biggest downside is potentially some redundancy in the 
configuration data (e.g., same SSH-level credentials configured).



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

Yes.


>  But see below!  This should be discussed in another thread.
>
>
>> 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

yes.

>  - on-demand

maybe, but 1) many open issues, 2) a "notifications" connection-type
augmented in might be better (more meaningful, etc.), and 3) I think
client-initiated connections are generally better suited than call-home
for YP+SN.

>  - periodic-with-on-demand

I don't understand this.  I'm sure your thinking that it will call home
sometimes with reason=scheduled (or whatever) and then other times with
reason=yang-push (or whatever), but what happens when the YANG-push is
suppose to happen at the same time there is already a periodic connection?
Assuming this connection-type presumes the existence of the "on-demand"
connection type, why not instead configure a dedicated on-demand 
connection type?

>  - strictly-periodic

I generally like the idea of removing the "The NETCONF/RESTCONF server/client
MAY initiate additional connections to the NETCONF client/server if needed 
for reasons not described here." sentence from the various "periodic"
descriptions, but...

I'm okay (can live with) leaving it in, from a future-proofing perspective,
more so than for anything that we plan on doing now.



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

Sure, but I'm trying to give you a peek now so we can see how this might
play out.



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

I would have the corresponding notif draft augment in a new connection-
type (e.g. "notifications") and that the notif data model's leafref 
would only point to connections having that connection-type.  No 
conflation of purpose, each connection definition has a specific
purpose.



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

I know that this is the idea, but we have no other examples at hand,
and so it reduces to just YP for me.



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

yes, this a rehash of the "reason" topic above.  I'm using the 
word "repurpose" because, the primary-purpose is to establish a 
NC/RC session that the client can then do whatever it wants with
(including starting a dynamic subscription in a separate SSH
channel).  The "repurpose" part is having other triggers using
the same connection for their purposes, in which case the purpose
is most definitely not the same as the normal purpose.


Kent // contributor