[Infrastructures] using IA methodologies to build network
element configuration
Daniel Hagerty
Daniel Hagerty <hag@linnaean.org>
Tue, 5 Apr 2005 17:09:55 -0400
So, I will speaking of the example that this message's
"In-Reply-To" header should reference. Your universe may vary, should
you be unable to find the named referrent. The example was
approximately that of configuring a linux machine and a cisco box to
share a t1.
To Keep It Simple Stupid, I will subset the problem into two, and
immediately mostly ignore one of these sets.
The set I will ignore is the information about "knowledge
representation". This is actually an important problem, but I'm
avoiding dealing with it on purpose -- our knowledge representation
issues are mostly driven by the needs of our semantic issues.
As I've alluded to, the other set of problems that I will focus on
are the semantic issues.
Concretely, consider nothing but the expression of the ip address
and subnet of our two computers. They have other issues, but this
example is smaller than the entire configuration fragment, and yet
represents many of the issues we want to attack.
So, what we have on hand is the desire to somehow go from the
facts Brent spoke of, to a configuration file fragment.
Considering the cisco fragment, we have two values we care about to
express the address and subnet:
"192.168.155.1" and "255.255.255.252".
Obviously, there's other goop around these values. This goop is also
important (otherwise, how do we frame the meaning of these terms?),
but less so for the argument at hand.
In the case of the linux fragment, we actually have choices. To make
the choice interesting (as there's a very uninteresting choice as
well), let's say that the values we care about for linux are
"192.168.155.2" and "0xfffffffc"
(as in "ifconfig eth0 192.168.155.2 netmask 0xfffffffc" as opposed to
an equivelent "ifconfig eth0 192.168.155.2 netmask 255.255.255.252")
So we know the values that we need to produce. How do we produce
them? Remember, I want to avoid the knowledge representation issues
as much as possible. Nonethless, we must touch upon them in order to
move forward; this is where semantics and knowledge representation
begin to inform one another in our problem.
So, to start producing the knowledge we need to sovle our problem, the
first object is the subnet base address. We could write something
like 192.168.155.0/30 as the name of the address. Note that we're
really speaking of a parser when we write such a form: our program
doesn't work on strings, it works on abstractions formed from them.
That IP addresses have a concrete representation as a string isn't
important to our math, but it's important to us humans.
This parser produces a pair of abstract ip addresses; this is the
knowledge we need to represent a concrete subnet (whereas knowing that
we need these two values, but not knowing concrete expression of these
values would be an abstraction).
Any place you see a "concrete thing", it helps to think "function":
this is what you actually need. There is a conspiracy in the universe
that prevents you from writing down the actual functions, but forces
you to write down values computed from them instead.
Thinking in this form is on purpose. If you squint your eyes enough,
you should be able to see that the function that returns our subnet
base address has another, more famous mathematical name. It's the
zero function for our new numerical space.
With a definition of "zero", we can move onto writing the so called
"successor" function of our numbers.
If our domain was actually numbers, the zero function would return the
number zero in some fashion or another. The successor function is a
function that consumes our number domain, and returns the number plus
one. Therefore, the successor of zero is one. The successor of the
successor of zero is two. Ad nauseum.
However, our domain *isn't* numbers, so boredom does not ensue.
Successor in this domain computes the next ip address on a subnet.
Avoiding issues of "how are addresses like zero and broadcast
special?", there's no magic here.
Given our zero (for example, 192.168.155.0/30), we want a function
successor that will return 192.168.155.1/30 (abstractly, not
concretely). Sound difficult? Right.
The only complicating factor in here is that of running out of
addresses in the subnet. Sooner or later, we ask for too many
successors, and the subnet has no more addresses. However, by now it
looks like a standard programming/error handling problem of static
detection versus dynamic detection, and what to do when the whole of
what the sysadmin says is nonsense (semantically, the idea of saying
"nonsense" could be called "speaking a top expression" or some such --
top expressions contain so much information that the information is
self contradicting).
All you need now are unparsers that deal with these numbers, and can
cope with "in the context of linux, say this, and in the context of
cisco, say this".
With all this in hand, see how the knowledge representation issues
become more clear?
You *want* to be able to name the address on the cisco as the
successor of the local zero subnet, but you can't actually say it as a
function value. You have to write down the output of the function.
One way you could say this (mangling the term from Vernor Vinge) is
that "192.168.155.1" is not a true name of the interface on the cisco,
but this idea that it is the successor of blah is. One of these will
always help us find the cisco in any universe, the other only works in
one (I came here from the problem of staging software, so I will often
speak of multiple universes that have the same denoted structure, but
all the variable values are different).
That you are writing down the output of the function, rather than the
function doesn't mean that the function doesn't exist. In particular,
if your system is any kind of "well managed", these functions almost
certainly do exist, and it's simply a matter of missing glue to be
able to express them all together in one place.
Please ask me to clarify this example if I am saying something
poorly. I very much want to see you understand what I'm saying.