Aaron Brown wrote:
Freek Dijkstra wrote:
Evangelos Chaniotakis wrote:
I'm on the fence as to whether we need a separate "network" concept. We might need to model administrative domains that run multiple independent networks.
You totally convinced me. So:
DOMAIN = administrative domain = an organisational entity that is responsible for the operational control of resources (including network resources)
NETWORK = a collection of network elements that behaves as a single resource (it is possible to describe the functionality without exposing the internal implementation or detailed internal limitations)
<snip> In this view, you might have elements like so to describe the nodes in a certain pop connecting esnet, geant and canarie:
<domain name="Internet2">
<!-- the definition of the physical elements --> <node name="ciena1"> <port name="eth0"> <link name="link_to_ciena2" /> </port>
<port name="eth1"> <link name="link_to_ciena3" /> </port>
<port name="eth2"> <link name="link_to_esnet" /> </port> </node>
<node name="ciena2"> <port name="eth0"> <link name="link_to_ciena1" /> </port>
<port name="eth1"> <link name="link_to_ciena3" /> </port>
<port name="eth2"> <link name="link_to_canarie" /> </port> </node>
<node name="ciena3"> <port name="eth0"> <link name="link_to_ciena1" /> </port>
<port name="eth1"> <link name="link_to_ciena2" /> </port>
<port name="eth2"> <link name="link_to_geant" /> </port> </node>
<!-- the definition of a pop --> <node name="pop1"> <port name="virtual_eth0"> <link name="virtual_link_to_canarie" /> </port>
<port name="virtual_eth1"> <link name="virtual_link_to_canarie" /> </port>
<port name="virtual_eth2"> <link name="virtual_link_to_geant" /> </port> </node> </domain>
Then, you pass around pop1 to the interested parties as well as give it attributes the same way you might give a node attributes (who is the administrator for this pop, etc), and if they so desire, they can look up the elements that actually make up the pop (those pointers would be included in each of the elements, but they're left out of the example for brevity). The virtual ports could also include as much information as the physical ports that make them up so that they could easily be used for path finding or whatever.
I agree, but I say: formalize that pop1 is the "abstracted" view and the rest are the "detailed" view. If we did that, a network information DB could hand out that single document and applications would select the view that's most appropriate for their demands and capabilities. In the snippet above, there is no way to tell if pop1 is a real node or a "virtual" node. (and, if you start labeling things, you end up doing something quite similar to views) And as far as treating domains and networks as generic Nodes with interfaces poking out: No problem, and I don't see it conflicting with the domain / view / network model. They could (and probably should) all have the NetworkNode aspect.