Great Circle Associates Network-Automation
(April 2005)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: available network automation tools
From: "Georg Magschok" <gio @ epygi . de>
Organization: Epygi Labs DE GmbH
Date: Tue, 12 Apr 2005 16:44:30 +0200
To: "'Kirby Files'" <ksfiles @ gmail . com>,"'Brent Chapman'" <Brent @ greatcircle . com>
Cc: "'Aaron Glenn'" <aaron . glenn @ gmail . com>,<network-automation @ greatcircle . com>
Importance: Normal
In-reply-to: <425BD965.5020306@gmail.com>

> > In other words, an interface that lets you do things like
> > 
> > - Add Device
> > - Add Card to Device
> > - Add Port to Card
> > - Add Network
> > - Describe connection from Port to Network
> Not only that, but also to define new types of devices and connections
> for the model itself.

To me that is very much what all management platform dinosaurs provide
(e.g. HP OpenView NNM), in most cases it takes far too much manual
interaction to define a model of that type.

> > At this point, we move beyond the model to the actual ability to deploy
> > configurations derived from the model.  In other words, I conceptually
> > separate the problem into two parts:
> > 
> > 1) What should the configs be for each device?
> > 2) How do I get those configs onto those devices?
> And (3) How can we tell if the config *can* be applied to the device
> (no conflicting assignments; preconditions met); and (4) How can we
> tell that the configuration was successfully applied, and how to we
> back out the configuration on all other affected devices if not?

What about a standard requiring that devices need to perform a
2 or 3 phase commit of automated configuration requests,
2 is sufficient for conflict-free local assignments,
3 is sufficient for network-wide conflict-free assignments.

> >> For us, the key has been to keeps the schema for the model defined not
> >> in the management software or static database tables, but a NetEng
> >> modifiable syntax that can be quickly changed to add new concepts,
> >> hardware, and services.
> > 
> > Yes, this is important; it's got to be extendable, because you aren't
> > going to think of everything up front.

> Yup, and in particular, it has to be easily extensible by
> non-programmer types. So I created a metadata syntax that Engineers
> can use to define the model, that is later compiled into an object
> model. At this point, more than half of the man-hours in the system
> have come not from the programmers, but from the work of NetEng
> modifying the network model to suit their needs. This allows rapid
> change outside of product delivery timelines.

This is a superb point.
So at least one view onto the model must be syntactically usable
for the NetEng.
A _very_ limited approach (just linux firewalling) to this can be
found in http://firehol.sourceforge.net/
Such a type of overall definition language (and be it XML-based) could
cope with the requirement you named. NetML does it in a more general
way. So we just need tools around that?

bye,
  Gio

Epygi Labs DE GmbH - Georg 'Gio' Magschok 



References:
Indexed By Date Previous: Re: available network automation tools
From: Kirby Files <ksfiles@gmail.com>
Next: Re: available network automation tools
From: Daniel Hagerty <hag@linnaean.org>
Indexed By Thread Previous: Re: available network automation tools
From: Kirby Files <ksfiles@gmail.com>
Next: Re: available network automation tools
From: Daniel Hagerty <hag@linnaean.org>

Google
 
Search Internet Search www.greatcircle.com