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

[Larry Menten <lmenten@lucent.com>]

Rob Enns wrote:

> 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?
>  
There are already enough race conditions without creating new ones.
Transactions conforming to your spec introduce unnecessary new race
conditions and have the additional problem that collisions that should
be detectable are not.  This is a consequence of the replace/overwrite/merge
model.  The model might work fine for a single user modifying a local,
private document.  It is dangerous when it is applied to managing a
remote device supporting multiple simultaneous management sessions.

>  
> > 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.
>  
There was all of this talk about avoiding expressing such operations within
the element hierarchy when I proposed the scheme, providing examples of how
we apply it in our own management approach.


One solution might be to modify your representation as follows:

<edit-config>
 <target>
  <running>
    <ospf name=135.104.58.1">  // keys that uniquely name object are attrs.
      <area name="0">
        <interface name="135.104.59.3"/>   // object to be deleted.
    </ospf>
  </running>
 </target>
 <write-option>delete</write-option>
 <config/>
 ...


In other words,  use the target to name the target of the operation as well
as the config set/file.  For a delete operation, the config element is 
either
empty or left out.  For an "add" operation, it provides the child 
element(s).

Thanks,

Larry

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