> to some extent, I disagree - lets say you have 2 different router vendors
I am not sure I see the point of disagreement, which usually means
I spoke poorly.
> 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.
Generically, this problem you speak is called "semantic
distance". There are probably other names, but this is one I know.
The idea is that models may not map well onto one another.
Examples of issues in the area you cite include things like ios
reflective acls (no such concept in the pix last I knew), pix grouping
(expressable by expansion on ios, but no representation of the group
within ios), and no doubt many other concepts that don't translate
well. I don't have an ios & pix boxes in front of me to compare
today.
> 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
"Uber model" versus "use the vendors models and translate"
converge on one another, as you crank to infinity.
The math looks something like this:
When you write "translate from vendor a model to vendor b model", it
*looks* like you're writing one function, but you're really writing
two that happened to be smashed together.
When you write "translate from uber model to vendor a model", you're
writing one function.
What you're really doing when you write "translate from vendor a model
to vendor b model" is "translate from vendor a model to uber model to
vendor b model".
To jump back down to the concrete, by all means use the vendors model
-- if you don't, you'll just end up inventing something that looks
remarkably like the vendors model as part of what you need as you
require increasing specification. The end game gets hard to predict,
but let's worry about the basics first -- one of those basics is
establishing a basis of communication.
References:
|
|
