> Thus far I believe the discussion has been around device functionality
> necessary to deliver certain network behavior . Your question of what
> rollback really means is a good one. To me it means a return to a
> configured state prior to one or more configuration changes (see
> checkpoints ;-)
Databases need rollback explictly because there are external
factors that can not possibly be statically managed that will generate
a rollback. Databases are often made from disk drives that themselves
have no "commit" concept beyond "write this disk block thusly".
Nonetheless, the database can present "rollback".
The real question about rollback is one of defining when you do
and don't need it. We can return to what it really means in a moment.
Suppose we have a fully configured network in some state. We will
envision that this network was created with the help of some oracle
that helps us describe our overall network.
Further suppose that this oracle is actually working on "data" of
some sort, as opposed to being an inseperable whole. Imagine that we
can change the data that our oracle works with, and that this oracle
has a mode that produces configuration statements for our network one
at a time, until it we have exhausted the font of configuration --
when we have uttered all of these statements, we have achieved a
desired new state of the network as specified by the data we gave to
the oracle.
Suppose also that we have a boolean valued function. This
function will somehow examine the state of the network and determine
if we should rollback or not. We could call this function after we
uttered each configuration statement, and use it to decide if we
should start a rollback.
We will not worry about how to execute the rollback operation;
given an oracle of the power described above, "simple matter of
programming".
In what conditions will this rollback-needed predicate return
true? What information does the rollback predicate need from the
network that, in particular, is not actually derivable from our
oracle?
If all of the information that could ever possibly play into your
rollback-needed predicate is a result of your oracle, you do not need
a rollback operation. You can statically detect when you would
rollback before you got to the dynamic situation where you needed the
rollback. Don't speak what would cause you to need to rollback.
There probably are real problems in a typical network that will
require dynamic rollback. Here's one that is perhaps contrived; those
of you with more real networking needs can probably come up with
better ones:
Perhaps I assert as part of my configuration that my BGP filters
will have certain effects. One such predicate I could assert is that
post-filtered ASN1 will inject no less than some number N prefixes
into my RIB at each point where I peer with ASN1. If the number is
below this value, than "something is wrong with the configuration",
and a rollback should ensue. Sound reasonable enough?
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.
The model that Kirby was talking about a few days ago probably has
enough information for him to produce a rollback operation if he felt
he needed it.
James Dollar also mentions that his company does something to
produce a rollback concept.
This is all doable. If you want rollback, you're going to
discover that it starts to curve back on the modeling questions: how
do you explain the rollback capabilities of a juniper versus those of
a cisco, and how does we use these capabiltiies within a larger, more
platonic notion of rollback?
Follow-Ups:
References:
|
|
