Aaron Glenn wrote on 04/11/2005 07:37 PM:
> On Apr 11, 2005 4:30 PM, Brent Chapman <Brent@greatcircle.com> wrote:
>
>>Yes, this is important; it's got to be extendable, because you aren't
>>going to think of everything up front.
>
> Can one model a network in such a way ontop of SQL, or is there a
> better (easier/more extensible/effecient) way?
Well, you can store the model in an RDBMS, but the model itself, as
Brent says, should not be constrained by SQL semantics. What I've done
here is define a set of primitives that can be expressed in relational
terms, and built a model on top of that, using our own high-level
schema language.
So, for example, some of the primitives are:
META_VERSION
TYPE (classification: router, port, interface)
ELEMENT (specific object: core router, 100BT port, T1)
\---> ELEMENT ATTRIBUTES
\---> ELEMENT TEMPLATES
\---> ELEMENT SCRIPTS
RELATIONSHIP (t1-1 child of card0; e0.rtr1, e1.sw2 parents of VLAN1)
SERVICES
\---> SERVICE RELATIONSHIPS
ASSEMBLY (how to arrange a number of ELEMENTS, ATTRIBUTEs,
RELATIONSHIPs, etc. to deploy a standard Alcatel SR-7 Provider Edge
(PE) Router for one-click deployment)
Then the Engineering team defines the TYPEs, ELEMENTs, RELATIONSHIPs
and important fields (ATTRIBUTEs) to track for each in the metadata
editor. When they're done, we have a custom model for *our* network.
If a different Engineering team used it, they'd end up with their own
custom model. THis is the part where no tool can just be bought and
dropped into a provider; there would always be lots of customization
to your specific needs.
My guidance to Engineers is: only define the minimal fields to
describe the unique characteristics of the configuration. This greatly
simplifies the design, use, and validation. By contrast, many COTS
software collects *all* possible attributes of the network, leading to
sloppy data entry, low accuracy, and debatable verifyability.
--kirby
References:
|
|
