On 4/12/05, Georg Magschok <gio@epygi.de> wrote:
> > >Are you all interested in starting an open source project around this?
> > I don't know about anybody else, but I certainly am. I think that
> > such a "network database" would then become a platform upon which
> > much else could and would be built; like you said, though, it's
> > currently the core missing piece.
>
> Coming from network management development for ATM switches and VoIP
> boxes, I'd like to share an idea that I'm going to implement sooner or
> later and would like to see approved as "not wrong":
>
> "The semantics of a network model should be defined by the network elements!"
>
> The reason is rather simple:
> Either a network management system needs an awful amount of information
> about a network that it should work on (and this would either need to
> be standardized into the last little detail or manually entered by
> admins), or the network must be able to provide information about itself.
I think the 'answer' lies somewhere in the middle - if you
can't/won't/don't-need-to produce an uber-model, then you need to
'trust' the devices to some extent.
A common point I've noticed in recent replies to this thread is "yeah
so maybe we don't need to store/manage every last minute detail
centrally. But, we need to know enough to _configure the network_".
And that's the important point. We have to be able to configure it
this time, configure it from scratch should we need to port the entire
configuration to a new device (perhaps your stored copy in RANCID/etc
is sufficient, but what happens after restore?), and it has to do the
same thing to the device every time we ask for it, no matter the
existing device state (i.e., pre-requisites and halting problems need
to be considered). Actually the last statement there is really a
general form of the first two...
Personally, I don't trust device configuration, but I do trust devices
to maintain shared state, like IGP tables. Thus, I'd still like to
manage 'the entire configuration' centrally.
-andrew
Follow-Ups:
References:
|
|
