RE: Separation of protocol and information model

["Chen, Weijing" <Weijing_Chen@labs.sbc.com>]

> 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.
>
By looking at the above pseudo code, I have feeling that what you wants is
not really a network management protocol, but a XMLized nice file transport
protocol (a.l.a FTP/TFTP with basic transaction control).  If this is what
the NETCONF WG wants to do, then it should state this clearly to avoid
confusing network management folks.



--

Weijing Chen


> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Wednesday, September 03, 2003 4:24 PM
> To: Allen, Keith
> Cc: netconf@ops.ietf.org
> Subject: Re: Separation of protocol and information model
> 
> "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/>

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