Subject: [Netconf] netconf call home connection type

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Aug 2018 14:19:23 +0200 (CEST)

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.  An example would be a periodic yang push
subscription.

I also suggest that the default connection strategy either is dropped,
or changed to "on-demand".

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 (I
would then suggest to use period + anchor-time in both, but use a type
in seconds rather than timeticks).

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Aug 2018 20:24:10 +0000

> trigger the call home.  

"periodic" is meant to cover on-demand also.   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.

> does it make sense to use similar parameters in these two cases?

The YANG Push parameters have no equivalent to "idle-timeout".  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.

The client-server drafts have no equivalent to "anchor-time", some
point in the future after which connections begin.  This looks
complex with questionable value, worth keeping?

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Aug 2018 21:41:27 +0000

> support periodic connections.  As such, I don't think it should

Adding onto this, we could drop the default, and make the parent
"choice" be mandatory true.

Actually, since we're adding a feature for "periodic", we might
want to also add a feature for "persistent".  This would be
similar to how we're having features for both keystore-supported
and local-keys-supported.  Thoughts?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 Aug 2018 10:45:17 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> "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

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.

> The YANG Push parameters have no equivalent to "idle-timeout".

Sure, this is quite obvious.

> This

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.

> point in the future after which connections begin.

It is not a time in the future.

> This looks

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 Aug 2018 10:58:58 +0200 (CEST)

> and local-keys-supported.  Thoughts?

I don't think that we need features for these mechanisms.  Both should
be quite trivial to implement.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Aug 2018 11:02:53 +0200

>            |           +--rw anchor-time?        yang:date-and-time

So who is going to configure suitable anchor-times on a large number
of devices? Is it not much easier to use a random offset instead to
avoid synchronization?  In LMAP, we used a random-spread in seconds,
which defines the size of the time interval from which random values
are taken. This has the nice benefit that the config can be the same
for a large number of devices and you still get a distribution over a
time interval.

Perhaps you want an anchor-time, a period, and a random offset:

anchor-time:  2018-08-22T00:00:00+00
period:       600 seconds (and yes timeticks seems overkill)
random-spread: 60 seconds

So you get events at 00:00:00+rs, 00:10:00+rs, 00:20:00+rs etc. and
with 1200 devices you get on average 20 requests per second and all
1200 devices have exactly the same config.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 Aug 2018 11:07:08 +0200 (CEST)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
> of devices?

Probably the client that will receive the call-home connections.

> Is it not much easier to use a random offset instead to

This looks very nice!

/martin

---

From: Kent Watsen <[email-masked]>
Date: Fri, 24 Aug 2018 21:40:59 +0000

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

Correct, that's the point of this configuration.  Maybe we need to
define another enum called "on-demand"?

> an explcit "on-demand" as default.

Popping back to your previous comment on this, per your suggestion, I
replaced the default with "mandatory true".

> always used.  And IIRC the TR-069 call home feature also relies on

Good points.

> maintain persistent connections to all of them.

I have seen persistent connections used.  The "persistent" container's
description statement says:

    This connection type minimizes any NETCONF client
    to NETCONF server data-transfer delay, albeit at
    the expense of holding resources longer.";

and netconf-client-server-06 Section 5.6.4 says:

   Support both persistent and periodic connections

   NETCONF clients may vary greatly on how frequently they need to
   interact with a NETCONF server, how responsive interactions need to
   be, and how many simultaneous connections they can support.  Some
   clients may need a persistent connection to servers to optimize real-
   time interactions, while others prefer periodic interactions in order
   to minimize resource requirements.  Therefore, when it is necessary
   for server to initiate connections, it should be configurable if the
   connection is persistent or periodic.

> poll say once an hour, but then call home once a day.  

I'm unsure what your point is, but I note that this use-case is satisfied
if YP (via SN and NN) ref-ed a netconf-server instance that had "periodic"
(which is intended to also support on-demand) with the periodicity of 24
hours.  And the concept of the idle-timeout (a linger timeout) is good.

> Also, you can have a dynamic subscription (w/o call home) with

Of course.

> It is not a time in the future.

The description statement says before or after.  Maybe the description
statement is unclear in its intent.  In the context of the client-server
drafts, "before" makes no sense (there is no replay), so only "after"
remains, hence my "future" comment.

>> This looks complex with questionable value, worth keeping?
>

Programming the "periodic" connections on exact time boundaries 
might be over engineering it, but maybe not. Does it matter if 
a device  calls-home once a day vs exactly at 3am every day?

As currently defined, even if all devices were configured to do 
"periodic" at the exact same time, they eventually diverge as 
random delays skew  each device's counters.  A spread occurs 
over time and, besides, there are techniques for handling load.

>           |           +--rw anchor-time?        yang:date-and-time

What if period is not set?  
What if anchor-time is not set?

In YP, "period" is mandatory but, still, the description statements
aren't clear.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Fri, 24 Aug 2018 21:50:58 +0000

> I don't think that we need features for these mechanisms.  Both
> should be quite trivial to implement.

Too bad you weren't at the meeting ;)

You won't get much of an argument from me.  After all, my slide said:

     Periodic connections are incredibly useful and, by not having a
  feature, we might nudge the industry into supporting them more.

And, if you think it's trivial, then why not, right?   Hmmm, well,
what if a device really only wants to support one type?  Is that
a likely scenario?

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Fri, 24 Aug 2018 21:52:59 +0000

>> 1200 devices have exactly the same config.

Good for YP too, right?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 25 Aug 2018 00:13:23 +0200

> >> 1200 devices have exactly the same config.

Yes.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 27 Aug 2018 10:22:59 +0200 (CEST)

> what if a device really only wants to support one type?  Is that

I would think that the operator wants the flexibility to decide this,
not the device programmer.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 27 Aug 2018 10:30:54 +0200 (CEST)

> define another enum called "on-demand"?

Yes, that was what I suggested in the first email in this thread.

> replaced the default with "mandatory true".

Ok.

> hours.  And the concept of the idle-timeout (a linger timeout) is good.

Yes I agree that such a leafref nicely solves this use case (and
others).

My point was that "idel-timeout" is not needed in YP.

> remains, hence my "future" comment.

In both cases (YP and client server) the exact time doesn't matter; it
can be in the future or in the past, it is just use to calculate at
which periodic times the poll happens or the server calls home.  Hence
the term "anchor-time" as opposed to "start-time".

> a device  calls-home once a day vs exactly at 3am every day?

I think it does in some scenarios, e.g. it might be useful to schedule
all call homes at night.

> What if period is not set?  

Sorry, period should be mandatory, by bad.

> What if anchor-time is not set?

See the definition in YP.  It will work like your proposed model in
this case.

> In YP, "period" is mandatory but, still, the description statements

Then they need to be clarified.  But that's a different email thread!

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 Aug 2018 00:39:57 +0000

> not the device programmer.

Yes, it would be better for the operator.  That seems like a good metric
here and in general.

Okay, so no features for "periodic" and "persistent".  Devices supporting
call-home (and NMSs that support NMS-initiated connections) must support
both.  If anyone objects, please say something now.

Kent // author

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 Aug 2018 02:16:44 +0000

> Yes, that was what I suggested in the first email in this thread.

Having an "on-demand" connection-type seems counter intuitive, as it is
providing configuration for a connection that is driven by some external
function, that may or may not be configuration.

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.

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?

>> >           |           +--rw anchor-time?        yang:date-and-time

Perhaps there's a third (or fourth, if you include "on-demand") 
connection-type called "scheduled", and it has anchor-time mandatory?

Periodic is intended to be more fluid, e.g, for a server that wants to
have contact with the device every hour.  If a device has a need to 
initiate an on-demand connection after 20 minutes, that constitutes
"contact" and the clock resets.

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

> Then they need to be clarified.  But that's a different email thread!

I hope Alex sees this.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Aug 2018 07:33:58 +0200

> function, that may or may not be configuration.

LMAP would likely call home on demand as well, i.e., triggered by
other stuff going on in an LMAP agent. Do we really want an
augmentation for all the different reasons why a device may want to
call home?

> seems rational to define, never materializes.

The demand part in the system you are describing is a call home
triggered by the event "I am running out of log buffer space" or "I
had a partial restart event" or "a hardware compomnent is dying" or
... There are probably a number of situations where a device may want
to call home out of schedule and I am not sure it is reasonable to
model them each one of them as augmentations.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 28 Aug 2018 09:18:32 +0200 (CEST)

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

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

> "contact" and the clock resets.

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)

> something like the need to push logs

Maybe we need both; "strictly periodic/scheduled" and
"periodic/scheduled + on-demand".

> but, as per the YP discussion,
> to the "monitoring" system.

*if* they are different systems.  It is not unreasonable to also send
 logs to the provisioning systems.

> If a device had configuration for a

Huh?  It would know this b/c of the leafref from netconf-notif to
call-home/netconf-client.  Maybe I misunderstood what you mean.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 Aug 2018 16:10:43 +0000

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

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

> both?  (note that in the YP model anchor-time is optional)

ACK

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

> logs to the provisioning systems.

Yes, both scenarios exist and need to be supported.

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

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 28 Aug 2018 21:17:49 +0200 (CEST)

> the behavior you're expecting in each case.  What transport protocol 

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.

> we've discussed for the notif drafts?

I think so.

> 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

> doesn't prevent orphaned config.

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

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Aug 2018 01:07:07 +0000

> put any limit on the number of sessions?  Probably not, imo.

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

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

>      (meanwhile notifs are queued), and once the session is started,

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 29 Aug 2018 09:12:30 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 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)
> 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

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.

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

> 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 

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

>             persistent or periodic connection

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

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

> connection for yang-push.

It is not just YP, but notifications in general.

> trigger-specific action to see if it was the reason why the 

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Aug 2018 21:08:19 +0000

> Duh.  Of course.  

Well, I have had to correct people before.

> Ok, but this doesn't really change anything, except

Yes.

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

> 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

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

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

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

> receiver a NETCONF server?

Yes.

>  But see below!  This should be discussed in another thread.
>
>

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.

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

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

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 30 Aug 2018 08:44:55 +0200 (CEST)

Hi,

>    determine the reason the server initiated the call-home

This sounds promising, and worth thinking about more.

Ok.

> is secondary to provisioning).

But notifs can be important in provisioning work flows as well, and
especially so for YP.

> home "on-demand").

Agreed.  If there is "something else" that would cause the device to
call home on demand, you can always create a notification that
represents this "something else", and we're back to SN.

One thing could be calling home after a reboot.

> There was a message I sent when you were sailing
> (bet you're missing it now where I said that we instead focus our

I think that dynamic subscriptions (over a client-initiated connection
or a call-home connection) are better suited than configured
subscriptions.

> connection type, why not instead configure a dedicated on-demand 

Well, this is the "periodic" that exists today.

> more so than for anything that we plan on doing now.

I agree that if we explicitly do not define configured subscriptions
for NETCONF / RESTCONF, then we just need "persistent" and
"strictly-periodic".   In that case there is no "on-demand" use case.

> conflation of purpose, each connection definition has a specific

So it would have to create a duplicate call-home/netconf-client entry
(with duplicate address and keys etc).  Ok, that would work.  But it
seems to me to be just a different syntax for the exact same thing.

> and so it reduces to just YP for me.

Maybe I want the device to call home on demand if an alarm with a
certain severity is raised.

Maybe I want the device to call home on demand if it detects new
hardware.

...

> is most definitely not the same as the normal purpose.

If call-home is explicitly not designed for any "on demand" use cases,
this should be clearly indicated in the document.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 30 Aug 2018 19:08:27 +0000

>> Maybe RFC 8071 can be updated to add:
>> 

Ideally, we don't have to update RFC 8071.  Do you think it could be
done?  What if we 1) defined the "ietf-call-home" module, 2) updated
the ietf-[net|rest]conf-server drafts's description of the "call-home"
container to encourage the use of it, and 3) require its use for
the "notif" drafts?

> But notifs can be important in provisioning work flows as well, and

Again, I'm generally okay, even support, using the same call-home
connections used for provisions, if it's possible without going out
of our way to make it happen.

> One thing could be calling home after a reboot.

Calling home after reboot sounds prudent, but it could be already
accounted for in that:

  1. a standard call-home (persistent or periodic) connection that
     has been configured will likely do this already.  Certainly a
     persistent connection would, for a periodic connection, the
     text doesn't say, but we could fix that.

  2. a YP-driven on-demand connection has been configured, and the
     reboot event generated a notification that (through QoS?)
     results in a notification being delivered.

> or a call-home connection) are better suited than configured

For many, perhaps most, use cases, I agree.  I think Eric first said, and
I agree, that 1) there is a window of time between reboot and when the
dynamic subscription is initiated that might be missed (yes, there is
"replay", but that might be lossy are otherwise not used) and 2) there
is the convenience factor.  

> Well, this is the "periodic" that exists today.

I know!  :sigh:  I've been trying to say in my last few responses that it
may be a mistake.  Just like you, I thought it would be goodness, but when
looking at how it would be implemented, it gets becomes murky.

Let's says it's a "persistent" connection that YP+SN is pointing to.  When
there is a notification to send, the call-home connection should be up
already (connecting previously w/ e.g., reason="persistent").  Okay, so
*how* does the notification get delivered?  If NETCONF, then we might be
able to claim some implied :interleave: ability, but that doesn't work
for RESTCONF.  If SSH, we might be able to define some mutli-channeling
mechanisms, but that work for TLS.

Now let's say it's a "periodic" connection that YP+SN is pointing to.  This
is same as the "persistent" case except that, sometimes, the underlying
connection won't be up and therefore must be brought up (with e.g., reason=
notifications).  This in itself isn't a problem in my view, the issues are
in how to deliver the notification when the connection is already up.

Answering my own question, maybe, perhaps the answer is that there is no
reuse of the underlying connection.  Having YP+SN point to the connection
definition does not mean "repurpose the TCP connection" so much as just
repurpose the configuration definition, but always initiate a new 
call-home connection, using all the same ports/credentials, etc., the
only difference being that it is with reason=notificiations.  What do
you think?

> "strictly-periodic".   In that case there is no "on-demand" use case.

I want to agree, but the wording has me unsure.  Here is where I think
we're at:

OPTION 1: (MORE FLEXIBLE)

  - defined call-home connection types:
      - persistent
      - periodic
      - one of:
        - on-demand (defined in the client/server drafts)
        - "notifications" (augmented in via a notif draft, my pref)
  - YP+SN can point to any or, alternatively, a regular *conf-client
    definition (not a call-home definition)
  - the "ietf-call-home" module with the "call-home-reason" RPC is implemented
  - when pointing to persistent or periodic call-home definition, it means:
     a) always initiate a new call-home connection (reason=notifications)
        [idea introduced above] and wait for the client to do some reason-
        specific TBD thing to e.g., collect the logs from the server.  By
        "always", I really mean, only if there isn't a reason-specific
        connection established already.
     b) do some magic to multiplex over the existing call-home connection
        [not sure how to do this yet]
  - when pointing to an on-demand or notifications connection, it means
    same as (a).
  - when pointing to a regular (not call-home) connection, always initiate
    a new connection (assuming there isn't a connection established already).
    No call-home "reason" is set, but we might state that the receiver
    (the NMS, which would be the protocol-level server), if NC/RC based,
    must advertise some capability.

OPTION 2:  (KIND OF STRICT)

  - defined call-home connection types:
      - persistent
      - periodic
      - "notifications" (augmented in via a notif draft)
  - YP+SN can only point to "notifications" type or, alternatively, a 
    regular *conf-client definition (not a call-home definition)
  - the "ietf-call-home" module with the "call-home-reason" RPC is implemented
  - when pointing to an on-demand connection, it means same as (a) above.
  - when pointing to a regular (not call-home) connection, always initiate
    a new connection (assuming there isn't a connection established already).
    No call-home "reason" is set, but we might state that the receiver
    (the NMS, which would be the protocol-level server), if NC/RC based,
    must advertise some capability.

> seems to me to be just a different syntax for the exact same thing.

Agreed.  Perhaps my newest proposal about just repurposing to connection
configuration (not the connection itself) gets us out of this morass...

> Maybe I want the device to call home on demand if it detects new

Sure, but wouldn't both of these be notifications too?  I'm trying to
think of something that wouldn't be a notification.

> this should be clearly indicated in the document.

Yes, if we go this route (OPTION-2 above), we most certainly will.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Aug 2018 12:26:05 -0700

> container to encourage the use of it, and 3) require its use for

Isn't this just an implementation detail?
I don't mind this new RPC, but not sure it is really needed.
The server knows which socket it opened to start the callhome TCP
connection.

If a callhome session is started for a configured subscription then this RPC
might help.  IMO it is better if the client issues an
<activate-configured-subscription>
RPC, and this is just a generalized version of that.

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Aug 2018 11:29:41 +0200 (CEST)

> container to encourage the use of it, and 3) require its use for

I think we need to work out the details first, to see if it works.

> able to claim some implied :interleave: ability

Yes.  But note that interleaving *is* in fact mandatory with the new SN
drafts.

> but that doesn't work
> for RESTCONF.

AFAIK there is no attempt to define a mapping for configured
subscriptions for RESTCONF.

> If SSH, we might be able to define some mutli-channeling

If it can be done for persistent then it can be done for an existing
periodic session.

> only difference being that it is with reason=notificiations.  What do

I think that as long as we mandate interleaving, we can as well send
them on the existing session.

>     must advertise some capability.

It seems you assume that we *are* (will be) doing configured subscriptions for
NETCONF?

> Sure, but wouldn't both of these be notifications too?

Yes, but you wrote "it reduces to just YP for me".  The notifs above
are not YP, but just notifs.

> I'm trying to

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Aug 2018 12:25:40 +0200

> I think we need to work out the details first, to see if it works.

I think it would in general be nice to have a way to find out why some
server did call home. If such a mechanism works for multiple protocols
in the same way, even nicer. The other alternative is to listen on
different transport endpoints and then to guess from the transport
endpoint used why a server did call home. Well, even if you deploy
things this way (may actually be falling out if you have separate
clients), it might still be nice for the client to be able to check
that it is actually being called for the right purpose.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 31 Aug 2018 20:32:08 +0000

Hi Andy,

> The server knows which socket it opened to start the callhome TCP connection.
>
> might help.  IMO it is better if the client issues an <activate-configured-subscription>

I agree that an RPC like <activate-configured-subscription> would be a
good way for a client to initiate the flow of notifications from a
call-home connection.

But I think what we're missing is that there may be other reasons why the
call-home connection was made, configured subscriptions being just one.
Thus, it's necessary for the client to first determine the reason and
then, if e.g., "configured-subscription", it issues then <activate-
configured-subscription> RPC.  For instance:

  C: ietf-call-home:get-call-home-reason
  S: configured-subscription
  C: ietf-subscribed-notifications:activate-configured-subscription
  S: <flow begins>

Makes sense?

Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Aug 2018 14:00:47 -0700

>   C: ietf-subscribed-notifications:activate-configured-subscription

yes -- this is better

---

From: Kent Watsen <[email-masked]>
Date: Fri, 31 Aug 2018 22:42:48 +0000

> that it is actually being called for the right purpose.

That makes four who think the idea is worth pursuing.

The definition of the "ietf-call-home[-reason]" module should 
be in its own I-D, perhaps an rfc8071bis.   Would somebody take 
the lead on this and ultimately submit an I-D for it?

Also, it seems that, if we want YP+SN to be able to use call-home 
for configured subscriptions, then we need to update the SN draft
to A) define the "activate-configured-subscription" RPC, and B)
define an identity off of the base "call-home-reason" identity
defined in the aforementioned I-D.  This is needed before any
notif draft can define support for "configured" subscriptions,
right?

Kent // chair