Re: A few potential requirements

[john heasley <heas@shrubbery.net>]

Wed, Jun 27, 2001 at 03:31:45PM -0400, John Blake:
> 
>  The way around this is to use 2 acl's
>  say 5 and 6.
>  if 5 is currently deployed,
>  then make 6 with the new stuff,
>  then apply 6 to the interface.
>  Next time you need to edit the acl, edit 5 and then apply 5.
>  Of course, that assumes you have enough acl's per interface, per protocol,
> per customer.

GAG!

such ops need to be atomic.  ie: here's a file with the acl, load it,
parse it, make it so, where make it so is atomic via mutexes or whatever
the vendor wants to do inside.  while cmd-line is _now_, WRT cisco-like
config vs. juniper commit-style.  afaik, this is the way the cisco
performs 'copy rcp run' ops, or at least appears to.

>  John
> 
> 
> -----Original Message-----
> From: owner-ops-nm@ops.ietf.org [mailto:owner-ops-nm@ops.ietf.org]On
> Behalf Of Mike MacFaden
> Sent: Wednesday, June 27, 2001 3:02 PM
> To: ops-nm@ops.ietf.org
> Subject: Re: A few potential requirements
> 
> 
> At 06:35 PM 6/26/01 -0400, Wayne F. Tackabury wrote:
> >Started with:  access-list 5 deny 192.33.1.56
> >               access-list 5 permit any
> >
> >New config was: access-list 5 deny 177.12.19.47
> >                access-list 5 permit any
> >
> >The "update" config couldn't be derived from diff:
> >
> >                no access-list 5
> >                access-list 5 deny 177.12.19.47
> >                access-list 5 permit any
> >
> >In general, anything that requires *turning off* a prior association or
> clearing a construct requires an intelligent translator for most
> configuration formats (I could give a much much more difficult example with
> 802.1q VLAN activation).  This would be the challenge of the kind of
> built-in convertibility you propose, to somehow handle this in how it
> specifies absence or presence of configuration information.
> 
> The is subtle - a quality issue that can be either
> the equipment vendors problem or the configuration mgmt vendors problem.
> 
> If, in order to modify something, you have to negate it in its entireity,
> that
> can be pretty unusable operations wise especially if it causes instability
> in an area
> greater than say a given device. (bgp soft reconfig, not dropping LSDB's
> when
> adding a new OSPF interface, etc). The decision tends to be made by
> the engineer adding the new feature so most CLI's are not consistent
> within a given device/software version when it comes to making
> modifications.
> 
> But if an application just blows away rows in order to reload when the
> device
> supports being able to do precise changes, the application may not be
> usable.
> 
> Mike MacFaden
> 
> 
> 
>