Subject: [Netconf] comments on draft-kwatsen-netconf-server-00

From: Martin Bjorklund <[email-masked]>
Date: Sun, 16 Feb 2014 10:47:46 +0100 (CET)

Hi,

I have some high-level comments on this draft.  I hope that this will
become a WG document soon.

o  Section 2.5.1 starts to use the term "Application".  This is a
   pretty overloaded term, and it is not defined in this document.

   "management application"
   "network manager" (used once in 6241)

   I think the only purpose this term serves, is to group a set of
   endpoints to call home to.

o  Section 2.5.2 talks about applications w/ multiple "servers".  I'm
   not sure you mean "NETCONF client" either...

o  2.5.5.

   IMO, the only way call home changes anything should be in setting
   up the transport.  From there on, the responsibilities should be
   just as for normal connections.  So I think the responsibility for
   keeping a connection alive, or closing it, should be on the NETCONF
   client.

   Hmm, now I realize that I don't understand what kind of keep alives
   you are talking about.  Is this for the case that the transport
   provides a keep-alive feature?  Or some (new) NETCONF keep-alice
   feature?

o  Data model structure

   Currently you have

    netconf
    +-- ssh
    |   +-- call-home
    |       +-- applications
    |           +-- application   
    +-- tls
        +-- call-home
            +-- applications
                +-- application   
     
   Did you consider

    netconf
    +-- call-home
        +-- applications
            +-- application
                +-- ssh
                +-- tls

   This feels more natural to me.

o   You define two types of connections, "persistent" and "periodic".

    Here are some situations that I can think of, that I think should
    work with call-home:

      -  the device starts up the first time
      -  the device's ip address changed
      -  the device has something to send
      -  scheduled (e.g., once a day, preferrably during a time window
         at night)

    Note that in some use cases, call home will be used only to set up
    the initial connection (or if the ip address changes), but once
    that is done, the "management application" will initiate
    connections as normal.

    I am not sure any of these are handled by the current types.

    Also, what is the use case for a persistent connection?  If the
    "management application" decides to close the session, why should
    the device reconnect immediately?

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Feb 2014 00:31:20 +0000

Hi Martin,

Thank you for your comments.  Below are my inlined responses.

Thanks,
Kent

>   endpoints to call home to.

Are you recommending to replace "Application" with "Management
Application" everywhere?

One key thing to note is that the netconf-server YANG module has a list of
"applications", which seems natural from a device configuration
perspective...

>   not sure you mean "NETCONF client" either...

I am talking about the NETCONF client - that it could be composed of a
cluster of systems (e.g., for HA reasons) and  hence the device needs to
have a list of call-home IP addresses for each configured "application",
as it's called in the YANG module.  From the NMS's POV, each system in its
cluster is a "server", hence the term.   Perhaps the term is not ideal, do
you have a suggestion?

>   provides a keep-alive feature?  Or some (new) NETCONF keep-alice

Generally speaking, for persistent connections, keep-alives can be sent
from either the connection-initiator or the connection-acceptor.  A
connection-initiator sends keep-alives so it can proactively initiate a
reconnection.  A connection-acceptor can send keep-alives too, but the
most it can do is throw an alarm.

In the case of normal-SSH, the NMS would be the connection-initiator.  If
the NMS chooses to have long-lived NETCONF sessions with devices, then the
NMS (as the initiator) would send keep-alives.  However, for reverse-SSH,
the device is the initiator and so it is the device that needs to send the
keep-alives.  Makes sense?

>   This feels more natural to me.

At first blush I'm inclined to agree, but I now want to see the whole
module converted before committing to it..

>    I am not sure any of these are handled by the current types.

The term "periodic" is a bit imprecise - it should be "on-demand/periodic"
or perhaps just "on-demand".  In any case, the description in the current
draft indicates that this setting means the device will connect-on-demand
as well as periodically due to a reoccurring timeout expiration.

Most of what you list falls into the "on-demand" case.  The last item
(scheduled) is questionable - at least I would think the NMS would prefer
the device call-home periodically, even if it's just a no-op 99% of the
time, as the NMS never knows if it might need to send something to the
device sooner...

>    the device reconnect immediately?

It's not the management application closing the connection so much as
maybe the machine it was running on crashed or the network broke.  A
device reconnection may be steered by a load-balancer to a "live" machine
or, if another IP address, the connection may go to a "failover
data-center"

Thanks again,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Feb 2014 08:17:30 +0100 (CET)

> Are you recommending to replace "Application" with "Management

"management application" is better than "application", but maybe
there's some other better term.

> "applications", which seems natural from a device configuration

Yes.

> cluster is a "server", hence the term.   Perhaps the term is not ideal, do

In the data model, maybe you can simply use "endpoint"; the management
application has a set of endpoints that the NETCONF server can connect
to.

In the text maybe you can say that one logical management application
is made up of a set of management application instances.

> keep-alives.  Makes sense?

Well, I still don't know if you are talking about TCP keep alives, TLS
heartbeats / SSH keep alives or NETCONF-layer keep alive (whatever
that is).  I think you mean TLS/SSH but it needs to be spelled out.
And as for SSH, is there even a standard for keep alives?

> as well as periodically due to a reoccurring timeout expiration.

I didn't the the "ondemand" part.

> time, as the NMS never knows if it might need to send something to the

It all depends on the type and scale of the network...

> or, if another IP address, the connection may go to a "failover

Ok, but then what happens if the management application properly
closes the connection?

/martin

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 24 Feb 2014 16:21:05 +0000

On Feb 19, 2014, at 2:17 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:

You can configure SSH server and client to keep the sessions open. There are two config options
ServerAliveInterval
and
ClientAliveInterval

It sends (or doesn't send if disabled) periodically null packets. If you enable it on the server, it will do it for all clients.

So you could use SSH for keep alive, but it would be good to be precise which keep alive are to be used.

Dean

---

From: Kent Watsen <[email-masked]>
Date: Mon, 24 Feb 2014 18:49:35 +0000

Hi Martin,

>>   This feels more natural to me.

A more complete view if the current tree is this:

   +--rw netconf
      +--rw ssh {ssh}?
      |  +--rw listen {inbound-ssh}?
      |  |  ...
      |  +--rw call-home {outbound-ssh}?
      |     +--rw applications
      |        +--rw application* [name]
      |           ...

      +--rw tls {tls}?
         +--rw listen {inbound-tls}?
         |  ...
         +--rw call-home {outbound-tls}?
         |  +--rw applications
         |     +--rw application* [name]

         |        ...
         +--rw cert-maps {tls-map-certificates}?

         |  ...
         +--rw psk-maps {tls-map-pre-shared-keys}?
            ...

Reworking it to your suggestion, it looks like this:

   +--rw netconf
      +--rw listen
      |  +-- rw ssh {inbound-ssh}?
      |  |   ...
      |  +-- rw tls {inbound-tls}?
      |      ...
      +--rw call-home
      |  +--rw applications

      |     +--rw application* [name]
      |        +--rw ssh {outbound-ssh}?
      |        +--rw tls {outbound-tls}?
      +--rw tls {tls}?

         +--rw cert-maps {tls-map-certificates}?
         |  ...
         +--rw psk-maps {tls-map-pre-shared-keys}?
            ...

I agree that this seems more natural - thanks for the suggestion!

Now I need to updated the YANG module, but I'm glad to stabilize the
config sooner rather than later...

Thanks again,
Kent