Subject: [Netconf] Managing multiple components through one server

From: Jonathan <[email-masked]>
Date: Tue, 07 Mar 2017 13:03:30 +0000

Hi,

We are in the process of architecting and designing a comms system and 
are currently considering using NETCONF as the default network 
management protocol despite out lack of experience with it to date. Our 
security gurus tell us it will have to run over TLS rather than SSH.

The current intent is to use NETCONF not just for devices but also for 
daemons and applications, with the choice of which device hosts specific 
daemons being flexible. We would like each device to host a NETCONF 
server for itself and the daemons and applications it hosts and are 
wondering how best to map between that server's data model and the 
individual data models of the daemons and applications. NETCONF over 
BEEP (RFC 4744) was considered briefly until it as pointed out that is 
now a Historic RFC. Schema mount may be an option, though the intent 
appears for it to be read-only at the moment. In order to avoid 
deviating from open specs (other than mandating TLS for NETCONF) we 
would like to just use standard ports and we would rather not give each 
daemon and application a separate IP address within the device.

Can anyone advise how best to approach this?

Thanks,

Jonathan

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 7 Mar 2017 09:54:26 -0800

Hi -

> Can anyone advise how best to approach this?

With extreme caution.  The application you describe is a classical
use of subagent protocols, and there's plenty of experience with
it using other management protocols.  However, NETCONF studiously
avoided addressing these questions from the outset, so there are
some gaping architectural holes.  A few items pop into mind:
    - subagent protocol definition (the tip of the iceberg)
    - authentication between subagents and master agents
    - schema (de-)acquisition by master agent / library module
    - schema version conflict resolution - in this use case, one
      expects to encounter processes supporting different versions of
      a particular schema, and processes come and go
    - where does access control "live"?
    - efficient evaluation of expressions requiring access
      to information held by different processes
    - locking / commit / rollback expectations under failure
    - behaviour under partition failure

I'm sure there is lots more that I've forgotten.  I think this
is an important and valuable use case, but Netconf was not
designed to handle it.  Perhaps someone will figure out how
to get Netconf to support this use case, but I doubt that the
resulting solution would be pretty, based on the anguish over
providing even the most circumscribed "mount" capabilities so far.

Randy

---

From: Douglas Hubler <[email-masked]>
Date: Thu, 09 Mar 2017 12:26:57 +0000

> > daemons and applications,

I very much see the same vision and have been looking at this for quite
some time, although I started with RESTCONF for "devices", but same idea.

> > we would rather not give each

Curious, in your system how would each daemon communicate to single netconf
service?  proprietary protocol over IPC?

As long as you do not have two daemons of the same module type, I believe
you can mix all of them together.

Example modules from single "device":
  ietf-yang-library (required)
  yourcompany-app1
  yourcompany-app2
  ...

Alternatively, I believe you can host the NETCONF support for each "device"
inside the daemon, but on a different port from other daemons.   If your
devices call home to your "NMS", then wouldn't the fact they are not on the
default port be a non-issue, practically speaking.

If moving to containers is in your future, then each daemon can use the
same port, but effectively this just moves to port mapping problem to the
container service, depending on what your end goal is.

On Tue, Mar 7, 2017 at 12:54 PM Randy Presuhn wrote:

> The application you describe is a classical
> use of subagent protocols,

and there's plenty of experience with
>     - behaviour under partition failure

I was thinking this "middleman/subagent" service's goal was to just "proxy"
calls, wouldn't it delegate all responsibilities you mentioned to either
the devices southbound or the NMS northbound?  Devices would see this
middleman as an NMS and authenticate as such. If a daemon dies and
middleman does not, then yes, i can see that being a challenge to proxy.

What I cannot figure out is how to mix two devices having the *same* module
on the same device.  Is this the "mount" concept?  If so, where could I
find more information about this?

The grand vision of having thousands of infrastructure components all
talking a standard management protocol is so powerful in my mind that it's
worth investing in solving the challenges north of the device and I would
very much welcome an opportunity to solve them.  The DevOps industry has
been thrashing on proprietary tools ATM to solve the same problems solved
in these specs.  IoT is next to discover this, we need to get to them
before they get too far with doing proprietary management solutions over
MQTT, which is the starting trend.