Re: Separation of protocol and information model

[Phil Shafer <phil@juniper.net>]

"Allen, Keith" writes:
>We feel that the way a device should make its native capabilities known is
>through its information model description.

I think there's a division between what the configuration can contain
and how it can be manipulated.  What I'd like to see is a protocol that
can take a chunk of opaque configuration and load it only a router, with
the maximum degree of reliability, recoverability, and transactionality
available in the device's software.

My thinking is that the piece of code that generates a configuration
dataset or delta is typically far removed from the piece of code that
places that config onto the device, tests and commits it, something
like:

    foreach impacted device
        make the config delta for that device;
    foreach impacted device
        lock the device;
    foreach impacted device
        upload the delta;
    foreach impacted device
        load the config into the running config;
    foreach impacted device
        test the new configuration;
    foreach impacted device {
        make the change permanent;
        unlock the device;
    }

The capabilities affect what each stage of this pipeline does, but
not the nature of the work being performed. The content of the delta
may affect the desired test, but not the rest of the logic.

>I think, though, that Phil's comments are probably getting close to a tough
>question at the heart of this issue.  How much do we assume that management
>applications know about each device's information model?

I guess I'd divide the model into the configuration content (the
syntax of the data itself) and the configuration management (how the
content is manipulated to get a delta permanently into the device's
configuration).

The content is the device's data model, which netconf is avoiding.
The management is what we're trying to solve.  I can make fairly
simple xslt scripts to turn a generic definition of what I want a vpn
to look like into a set of configurations for each involved device
(and to make it vendor/product/release specific).  I just need
a simple and robust mechanism for loading those deltas onto devices.

At the same time, I want an extensible mechanism so that applications
can take advantage of features like candidate configuration, rollback,
locking, named configurations, etc.  And I want something open to
future extensions so that the Next Great Idea (tm) can be added
incrementally to both devices and applications.  When my
time-travel-based pre-corrective measure project comes to fruition, I
want to be able to see it get used without having to travel back to
now and add it to this spec. ;^)

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>