On Mon, Apr 18, 2005 at 05:55:25PM -0400, Daniel Hagerty wrote:
> Making an actual rollback operation isn't that hard. As before,
> it's really a modeling problem. A good model trivially enables an
> oracle that can produce delta statements for the network pretty
> readily. As long as you can talk to the device, you can roll it back.
> You may in fact have to wipe the config to do it, but why do you care?
> Your relational database has to do much more evil things within itself
> to make rollback appear on its surface: the user is usually talking
> rows, but the database is talking blocks.
I tend to disagree with your view of the world.
a) Database rollbacks are simple because data objects (at least in the
pure relational world) just carry data and no side effects. Network
configuration changes however do impact devices and cause resources
to be allocated/deallocated. So it is not always trivial to rollback
from state B into state A since you have to take such side effects
into account. (And one not totally uncommon side effect is in fact
that you loose connectivity.)
b) Reloading whole device configurations because a network-wide
transaction failed would be a desaster in some environments.
Operators love stability and some devices actually take quite
some noticable time to load an old configuration and some even
loose dynamic state which you really like to keep.
c) SNMP, the turing machine of network management, requires oracles
to do anything useful and after more than 15 years of experience
we know that the lack of proper primitives does make it difficult
to write smart oracles since the costs of "trivially" coding
things such as rollback support seem to be non-trivial.
d) Several vendors seem to oppose the idea of making rollback
capabilities mandatory in NetConf. This is another indicator
that the simple programming exercise is not simple at all to
add if a box was not designed to support such rollbacks.
While in a pure abstract view an oracle can solve all these problems,
I believe that the proper devision of work requires that devices do
their share of work to support robust network wide configuration
transactions.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
Follow-Ups:
References:
|
|
