to some extent, I disagree - lets say you have 2 different router vendors
and want to manage acls across the network, for both vendors combined.
You want to know that a given access list (based on content) is
implemented regardless of the vendor. Both vendors provide you with a
model (in some fashion, it may be implied rather than they hand you uml or
an xml schema or something). Those 2 models are different. If you apply
those models to your database, each vendors acls are stored in different
tables - the attributes are named differently, some exist in one model
but not the other, maybe relationships exist in one that don't exist in
the other. This makes doing comparative analysis Hard. Not impossible,
but more difficult and time consuming than if they were in the same model.
Like cisco's acl manager doesn't cover Pix access lists, only IOS - they
would have to change the data model to handle the pix differences, or
handle the pix separately, both of which were non-trivial after the fact,
apparently. And that's pix vs IOS access lists which are not all that
different, compared to some other vendors.
So, I like the idea of using each vendors model for that vendors
equipment. You definitely have a cleaner data implementation that's more
comprehensible to the user. But it doesn't eliminate the problem in a
multivendor environment, it shifts it around. Maybe its a more
manageable problem in an already-modeled state though? Meaning, its
better to write the translation between a (say) pix acl model and an
IOS acl model than to create one model to rule them all. <-- gratuitous
tolkien reference
On Wed, 13 Apr 2005, Daniel Hagerty wrote:
> > I'd like to see an extensible model that can be partially implemented,
> > based on your choice. So maybe syslog (for example) is a
> [...]
> >
> > So, one other thing that I'm trying to absorb from other posts - what are
> > the pros and cons for (1) let the network elements/devices specify the
> > model - which would be different for different devices/vendors, or (2)
> > make a general model into which all devices/vendors can be fit. I think
>
> The "extensible model" that you really want makes the difference
> between 1 and 2 irrelevent. A "good extensible model" is a sufficient
> tool to relate models to one another. If your vendor gives you a
> model, cool! They just make your job much easier.
>
> In general, a good extensible model encourages you to produce a
> lightweight "your version of theirs" if the vendor doen't give you
> anything reasonable. This is easier than trying to smash something
> with too much irrelevant information directly into the correct form.
>
> If the vendor gives you something reasonable, assimilate it.
>
Follow-Ups:
References:
|
|
