Re: A few potential requirements

["Wayne F. Tackabury" <wayne@goldwiretech.com>]

At 01:51 PM 6/26/2001 -0700, Bill Woodcock wrote:
>Randy brought up a good suggestion, which is that it would be nice to be
>able to diff configurations and get out a result which was itself a valid
>partial config for converting one of the input configs to the other.

That is a good idea, it's a big selling point of our own configuration 
management product.  However, the ability to do this comprehensively would 
need to be designed into any configuration "scripting" notions, and 
possibly into the very process of "diff", assuming the "partial" config for 
conversion is to be sent to a box without clearing its flash (forcing 
interface resets, etc) first.

It gets tricky here in the nature of "converting" as a matter of update, 
with some services.  Let me give an example drawing from the cisco IOS 
configuration format.  Let's take the construction of an access list as a 
simple example.  It's one thing to talk about just adding new clauses to an 
access list--that can clearly derive from a "diff" in the classical format:

Started with:  access-list 5 deny 192.33.1.56
                access-list 5 permit any

New config was: access-list 5 deny 192.33.1.56
                 access-list 5 deny 193.1.74.241
                 access-list 5 permit any

Diff is:    access-list 5 deny 193.1.74.241
applied to running config

However, in the case like:

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.

Regards,
Wayne