Re: Separation of configuration and control - good or bad?

[Larry Menten <lmenten@lucent.com>]

Randy Presuhn wrote:

> Hi -
>
>  
> > From: "Larry Menten" <lmenten@lucent.com>
> > To: "netconf" <netconf@ops.ietf.org>
> > Sent: Friday, May 16, 2003 9:29 AM
> > Subject: Re: Separation of configuration and control - good or bad?
> >    
>
> ...
>  
> > I'd say that that captures the difference.  The Enns model is one in which
> > configuration is expressed as the transformation of a document.  This is why
> > you must lock the document before you operate on it.  There is a race
> > condition
> > between the get_configuration and the load_configuration.
> >
> > I prefer a model in which you explicitly name the target of the
> > operation and
> > you provide only that data relevant to the operation.  The Enns document
> > uses
> > "replace" to delete an element, requiring that all of the siblings of
> > the deleted
> > element must be provided in the transaction even though the intention is
> > not to
> > modify them.  Futhermore, you must now verify that those sibling trees
> > to not also
> > express a configuration change. More unneccessary processing in the agent.
> >
> > Seems to me that that is a very indirect way to manage a device.
> >    
> ...
>
> This leads back to the question of whether the "definitive" configuration
> is what's in the device at the moment.  The document-oriented model
> makes more sense if one thinks of the desired ("definitive") configuration
> data as not necessarily residing on the device, and which is delivered /
> applied to the device as needed.  (Push and pull both work.)   The protocol
> will have a big impact on how much work it is to identify and inform the device
> about the relevant deltas.   It may make sense to distinguish manipulation of
> configurations (as documents) from the process of delivering or applying
> them to a device even more than we're already doing (perhaps not consciously).
>
> Randy
>  
To my mind, it would be a shame to force configuration to take place 
through an
element manager that hosts a complete master copy of the config.  That 
doesn't
work for small device management where the master copy is considered to 
be the
copy in the device.  It also makes management fragile in environments 
where the
cli will occasionally be used to modify the device configuration.

In my opinion, the protocol should accommodate both models well.  The
overlay/merge/replace document operation model does not.

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