[bind10-dev] Using NETCONF for a low-bandwidth API

[Michael Graff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shane, Jelte, and I spoke yesterday about using NETCONF for our
configuration stuff as well as the command channel API layers.  We were
asked to write up a few things about how this might work.


When doing this sort of feasibility analysis, I always like to know what
we're needing.  This might be written down elsewhere, but I couldn't
find it.

The high level questions of "How will we use a configuration database?"
and "How will we use a Command Channel API?" are what I'm focusing on here.


(A) Configuration

In a system with multiple cooperating processes we need to distribute
system configuration down to each process.  This involves several steps:

(1)  Initial configuration.  This is only enough data to get started,
and contact the global configuration database.

(2)  Load configuration from the global database and make it real.

(3)  Receive periodic configuration changes and make them real.



(B) Events

However, we don't just need configuration data; we often need other
information which is more transient.  For example, one configuration
step may be "listen on all interfaces."  An event would be "a new IPv4
address was added" which may be temporary; the next time the machine
reboots it may not have it, but the "listen on all interfaces"
configuration would still be in effect.  These are pure events to me:
they may need to be acted upon, but are not exactly changes to
configuration, just changes to running state.  Also, these events are
asynchronous in nature, and are sent from some centralized event
distribution to those who have subscribed.

I believe the needs we have here are:

(1)  The ability to subscribe to events.

(2)  The ability to perform basic server-side and client-side filtering
of events.

(3)  The ability to unsubscribe from events.

(4)  One to one events and one to many events.


(C) State (statistics)

We will want to collect statistics, performance, and other run-time
data.  We need a way to get this in one location or to query for it as
needed.  I tend to believe periodic updates of a central repository of
status data is the right way to go, with an API to make this easy.

(1)  Periodic updates from a module to a central collection point.

(2)  External consumers of this data will poll only the collection point.

(3)  Collection data should expire from the central location if a module
stops reporting.

(4)  Some long-term data will need to be recorded; for instance, we may
record overall query counts as collected from all the data sources.
These numbers should not change as data source come and go, but should
change as their reported data changes.

(5)  Statistics should be very light weight all around.


(D) State (data)

We also have zone data.  This is not EXACTLY configuration nor is it
EXACTLY state.  It persists, but it is also the most changing element of
our system.  We also have DHCP lease state which is also persistent
across reboots.  These imply a database of some sort, and perhaps this
makes how to manage this data outside the scope of this discussion.


I will post some observations about NETCONF in a bit.  This is not a
trivial thing to read up on :)

- --Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqn0BcACgkQ+NNi0s9NRJ0AjgCfWJMfV8PpeYyxxmw3MVZBQool
omIAoKjqrjrWx94wgBRZmqqk3i6Jk69m
=oWz1
-----END PGP SIGNATURE-----