Brent Chapman wrote on 04/11/2005 07:30 PM:
> At 11:01 AM -0400 4/10/05, Kirby Files wrote:
>> * An interface for defining this model in network engineering terms
>
> 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.
>> * definition of services in terms of component devices and logical path
>
> I think I know what Kirby is talking about here, but I can't think of a
> simple example.
Well, as an example, we offer a VPLS service, which in our network
topology consists of a VPLS switching domain described by a VPLS
Connection Record; some number of VPLS terminations on Provider Edge
(PE) routers, including both a set of ports in the local switching
domain, traffic shaping policies, and Forwarding Database (FDB)
policies; and a mapping to the Provider (P) router core LSP mesh. The
metadata that describes to collection of objects, attributes and
relation is the services model for VPLS.
> 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?
>> 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.
--kirby
Follow-Ups:
References:
|
|
