[Infrastructures] using IA methodologies to build network element configuration

[Daniel Hagerty]

    I'll give you my short answer first, if only because my short
answer is often the one that's easier to derive information from :)

 > I wasn't disagreeing with you, merely pointing out that it isn't
 > always easy to tell that config info on two different devices is
 > (implicitly or explicitly) derived from a common root.

    Ah, I see your point.  You are correct.  It is beyond "not easy";
without signifigant help, it's intractable.  I argued from this
direction on lssconf last month;
http://lists.inf.ed.ac.uk/pipermail/lssconf-discuss/2005-March/000616.html
was one of the messages involved.  I could describe the issue better
now, but will defer.

 > The key thing is, these are two different references in two different
 > syntaxes to two different components (individual IP addresses for
 > either end) of the same object (the /30 network for the
 > point-to-point link).

    Yup, painfully familiar with this.  From a semantic standpoint,
you are beginning to grapple with the issues of denoted objects,
versus senses that express them, perhaps in oblique ways.  The objects
you speak of are denoted objects, these expressions of information
derived from them (the ip addresses, the /30 network) are senses.

    I'll reconstruct your particular network example in another
message.


 > What I need is a database that contains, in this trivial example, the
 > following items of information:
 >
 > 	Network "private-line-1" is a point-to-point link between
 > RtrA and RtrB,

    You have denoted objects, and are expressing relationships between
them (constructing a denotational world from these component objects).
You will no doubt keep your problem simple by limiting the kinds of
denoted objects, and how they can be related to one another.  As you
should; the less qualification their is on what can be denoted, the
harder the problem gets.

 >  From those facts (plus various other facts about RtrA and RtrB), I
 > should be able to run a Cisco-config-generator program that generates
 > the appropriate configuration for RtrA, and a Linux-config-generator
 > program that generates the appropriate configuration for RtrB.

    Yup...

 > "192.168.155.1 255.255.255.252".  I don't think the config-generator
 > programs need to be much more than template manipulators written in
 > Python or Perl or something similar.

    Strong agreement.  I was writing such template manipulators a few
years ago.  They accept an instance of a language, and create an
appropriate configuration file from it.  Still have the fallow code
lying around and am willing to share if asked.  I didn't pursue
polishing of the code because I knew it was going to run into
signifigant trouble with what I really wanted it to do -- the
underlying model was weak.


    These template manipulators are what I was calling an unparser in
a previous mail.  You can write it any language you like, as long as
you create a boundary language between the magic symbol manipulator
and the template program (the code I speak of above was a scheme
symbol manipulator, and perl template programs, connected by XML).
This symbol manipulator, if restricted to the domain of networks,
could be considered some kind of network ontology processor, if I
understand what a philospher would mean by the term.

 > I don't think that being able to convert between the two
 > configuration files is necessary, and it complicates things
 > significantly.  In particular, I don't think it's necessary to write
 > the "unparser" you describe, to convert from the targeted config file
 > back into the "uber language".  I think it's sufficiently useful just
 > to be able to _generate_ the targeted config files from the "uber
 > language".

    The argument you seek is that of "generative" versus
"proscriptive" configuration management, if I have the terms and
underlying concepts correct.  IIRC, Alva Couch coined the terms to
explain the difference between a configuration manager that is always
an authority (and generates all information) versus one that is
willing to take some amount of flexibility in believing end system
configuration.

    I believe that generative is a superior approach, and that ideas
like my above example of converting between configuration files aren't
really needed, but then, some people do believe they want this.  So I
make sure that I have a means of expressing it.

    In support of parsing, I've used it to great success in
understanding existing chaotic/unmanaged systems, but only as a tool
to produce generation.  Part of the "why" relates to issues like what
I speak of in my lssconf mail referenced above -- not only do you have
to parse the config file, you have somehow relate it back to what it
was really intended to mean, as opposed to what the config file
actually said.

 > Yes, obviously, although I'll point out that having a robust
 > out-of-band command-and-control network to all of your key devices

    I was purposely picking a case with no out of band management.
Given robust out of band management that you can't destroy, life is
obviously much simpler.  However, I will note that sooner or later,
you'll want to manipulate the out of band management network too.
Wouldn't it be nice if the same tools expressed both problems?

 > keeps you from getting "cut off" from any of the devices.  Such
 > networks are a good investment, in my opinion, and not all that
 > expensive as a fraction of the total cost of the networks that
 > they're used to manage.

    My paranoia in multi path out of band management has saved me much
pain on many ocassions.  I believe we are in agreement on the winnage
of such ideas.


    I agree with everything you say as to what you're trying to do,
how to go about it, and which approaches should work.  As you speak of
good out of band management, you should be able to avoid speaking of
reflection problems.


    I'll speak specifically of your subnet example on linux and a
cisco soon.  It's a very good example to work from.