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

[Rob Enns <rpe@juniper.net>]

On Fri, May 16, 2003 at 12:29:15PM -0400, Larry Menten wrote:
> 
> Brendan Kelly wrote:
> 
> > 
> >
> >>-----Original Message-----
> >>From: Phil Shafer [mailto:phil@juniper.net]
> >>Sent: Friday, May 16, 2003 7:26 AM
> >>To: Juergen Schoenwaelder
> >>Cc: netconf@ops.ietf.org
> >>Subject: Re: Separation of configuration and control - good or bad?
> >>
> >>Juergen Schoenwaelder writes:
> >>   
> >>
> >>>It seems to work in other places, so why not here?
> >>>     
> >>>
> >>Not that it can't work, just a matter of ease. If I want to pull
> >>down a configuration, do some changes to it and hand it back to the
> >>device, it's nice to have the format I hand back to the device be
> >>the same as what the device gave me.  This allows simple transformations
> >>(ala xslt) in the pattern of:
> >>
> >>  $config = $jnx->get_configuration();
> >>  $new = transform($config, $stylesheet);
> >>  $jnx->load_configuration($new);
> >>
> >>   
> >>
> >
> >
> >Phil's approach also lends itself well to tools which provide deltas on 
> >xml
> >documents.
> ><configuration>
> >	<rip somenamespace:delta="add">
> >		<version>2</version>
> >		<redistribute>
> >			<connected/>
> >		</redistribute>
> >		<network>172.22.0.0</network>
> >	</rip>
> ></configuration>
> > 
> >
> 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.

In what distributed system, without locking, is there not a race
between get-foo and load-foo?

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

I think there's a misunderstanding here. IMHO the intent is to allow
identified objects to be deleted in an <edit-config> operation
using an attribute (op="delete" or whatever). It didn't make 
it into the -00 draft. If the only way to delete an element
from a set of N elements is to load a set of N-1 elements, well, 
that would be silly.

thanks,
 Rob
 
> > 
> >
> >>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/>
> >>   
> >>
> >
> > 
> >
> 
> -- 
> 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/>

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