Separation of configuration and control - good or bad?

[Larry Menten <lmenten@lucent.com>]

Short form:

In additions to the other issues I have expressed with the Enns spec,
the model of configuration proposed in the Enns document
separates configuration from control, resulting in:

- more code in both the manager and agent
- more processing expense for both the manager and agent
- less robust management
- less functionality
- less intelligible transactions

Long form:

The specification proposed in the Enns document reflects a particular model
for device management.  The idea presented is that the configuration 
operations
be modeled as direct modifications to a tree of configuration information.
One acquires a subtree, locking the target configuration if robustness 
is desired,
modifies the subtree to express the desired operation as a replacement, 
merging,
or overlay of the target subtree and presents the resulting transaction 
to the target
system.  Examination of the contents of the transaction is not 
sufficient to understand
what operations are to take place, but only what the target end-state of 
some aspect of
the configuration is to be.  Since the transaction operations are 
limited to replace, merge,
and overlay, it is necessary to acquire the current state before 
expressing the operation
and to lock the state of the target configuration between when the state 
is acquired and the
modification performed.  Also, since the representation of an operation 
such as delete depends
upon the preceeding state of the subtree, the deletion of an element, 
such as an interface,
will be expressed differently each time it is performed, reflecting the 
state of the tree before the
operation.

My own experiments with this model suggest that the easiest way to 
implement this approach is
to modify the target tree, validate the result using a DTD or XML-Schema 
and a validating parser,
and then present the result to the system, or target subsystems as a 
configuration file that is to be
read and validated as a proposed replacement configuration by the target 
system/subsystem.  If the
validation succeeds, then the set is performed.  The statement in the 
proposed guidelines that
recommends that elements for which more than one sibling instance can 
appear should be collected
in an element representing the array suggests to me that they might be 
using an object serialization/restoration
design pattern to construct the candidate configuration data structures 
from the configuration file.

This explains the objection to including operation commands within the 
tree representing the transaction.
To my mind, the part of the tree leading up to the operation code 
represented the identification of the target,
and the children of the element containing the operation code 
represented a subtree to be added
or inserted as a replacement for the named target.  The tree, in my 
model represents a specification of
one or more operations on the target configuration.  In the Enns model,  
the entire contents of the tree
become part of the replacement configuration tree and persist as a 
configuration file.


I have already brought up a number of issues with this approach and 
issues, in particular, with the
operations of overlay, merge, and replace.   To my mind this makes the 
management operation
complicated and error prone.  It is more complicated to create the 
transaction contents,  and it is
necessary to know what the existing contents are to do a simple 
operation such as delete.  Futhermore,
locking is required if the operation is to be robust and concurrent 
management operations not lost.

Another consequence of this approach is the separation of control 
operations from configuration
modifications.  Is this a virtue or a fault?  To my mind, it is a 
fault.  In  my opinion, it is desireable
to be able to request control operations with configuration steps.  For 
example, request that an
LSA database be purged or not purged or that an OSPF adjacency be 
dropped or not dropped
when the configuration operation is performed.  In the Enns model, this 
cannot be intelligibly expressed
as a component of an atomic operation.  Furthermore, the separation of 
the processing of the control
operations from the configuration operations requires more code and 
requires the duplication of the
object hierarchy in different code within the target system.

Again, the result is
- more code
- more processing expense
- less robust management
- less functionality
- less intelligible transactions


Larry


Andy Bierman wrote:

> At 11:04 AM 5/14/2003, Larry Menten wrote:
>  
> > Keith,
> >
> > I also made the point that the transaction representation
> > proposed in Enns does not support the expression of 
> > setting multiple variables in a single atomic transaction
> > unless they happen to reside in the same target subtree.
> >    
> This is not the intent.  The contents of a <config> subtree
> can be multiple subtrees from multiple namespaces.  The examples
> are kept simple and only show one, but the protocol is
> not limited to one.
>
> BTW, I agree with the comment below that precise (and consistent)
> naming is an important aspect of the data model design.  It's
> probably out of scope for the netconf WG though.
>
>
>  
> > This, too, impacts the protocol.
> >
> > Larry
> >    
> Andy
>
>
>
>
>  
> > Allen, Keith wrote:
> >    
> > > Larry Menten writes:
> > >
> > >
> > >
> > >      
> > > > In my opinion, there is a very big flaw in a representation that
> > > > does not provide for precise naming of the target of the operation.
> > > >        
> > > I agree.  In fact, I brought this issue up a few weeks ago.  It's a tough one, though.  Having been involved in network management standards work before, I would estimate that 50% of the time of a network management standards group gets spent on naming-related issues.  I think this group was hoping to put those issues in the hands of the information model developers.  I'm concerned, though, that it impacts the protocol and needs to be addressed here. 
> > >
> > >
> > >
> > >
> > > Keith Allen
> > >
> > > SBC Technology Resources
> > >
> > > 9505 Arboretum Blvd.
> > >
> > > Austin,TX 78759
> > >
> > > (512) 372-5741
> > >
> > > <mailto:kallen@tri.sbc.com>kallen@tri.sbc.com
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Larry Menten [<mailto:lmenten@lucent.com>mailto:lmenten@lucent.com] 
> > > Sent: Wednesday, May 14, 2003 9:23 AM
> > > To: netconf
> > > Subject: Re: Is DOM vs SAX a red herring?
> > >
> > >
> > >
> > > Keith,
> > >
> > > In my opinion, there is a very big flaw in a representation that
> > > does not provide for precise naming of the target of the operation.
> > > You cannot, for example, request that a particular interface instance
> > > be deleted.  Instead, you must request the replacement of the parent
> > > element with a new configuration that omits the child.  This requires that
> > > you acquire the complete config of the parent element and requires that
> > > you include that complete config, without mistake, in the transaction request.
> > > So what happens if someone has created an interface between when you
> > > acquired the config of the area and formulated your request to replace the
> > > config?   You wipe out the interface config without even knowing that you did
> > > so.  That, to my mind is a serious flaw.
> > >
> > > Another flaw, to my mind, is that it is not clear what is being requested.  Is it the
> > > creation of an OSFP instance and an OSPF area and an interface and an MD5 key?  Or is it
> > > just the creation of just the key?  If you make a mistake in providing the ID of the OSPF instance
> > > you will accidentally create an instance that you did not intend to create.  It is far
> > > to easy to make a serious configuration mistake.
> > >
> > > In my opinion, the XPath spec of the target, or the nested elements that
> > > lead up to the op="delete", specify the target and are not part of the target
> > > configuration data.  The transaction that operates on the device configuration
> > > should be distinguished from what you will get from a request to serialize
> > > the configuration state.  (get-config)   Doing configuration by merging
> > > or overlaying config trees seems simple on the surface.  But it is a bad model for
> > > device configuration.  If you cannot safely request that, for example, an interface be deleted
> > > without risking the silent destruction of someone else's configuration changes, the
> > > design is flawed.
> > >
> > > Larry
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Larry Menten               Lucent Technologies/Bell Laboratories
> > >
> > > Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA 
> > >      
> > --
> > Larry Menten               Lucent Technologies/Bell Laboratories
> > Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA 
> >    
>  
--
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA 


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