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)
So how would a network in this context be meaningfully different than a node? A node is some entity with a set of interfaces to the outside world. With this definition, a node could correspond to a domain, a network element, some arbitrary group of network elements, etc. Basically, as long as it's a thing or group of things with a set of interfaces to the outside world, it can be reasonably described as a node. The major benefit of the node model is that there's no real difference between specifically described elements and summarized elements. They look like nodes with interfaces and links in both cases which on some level is true. No matter how specified you've gotten, you're going to be summarizing something (e.g. in a router, you'd have a number of logical node-entities interconnected with a bunch of logical links, all of which is abstracted away behind a 'node'). It also analogizes to how the links are summarized. A high-level link is made up of a bunch of lower level elements underneath in the same way that a high-level 'node' is made up of a bunch of lowel level elements. 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 think the view model is a great idea for getting a specified slice of a set of elements(what are the elements I need to monitor? what does a layer3 view of the network look like?). I'm just not sure it's the best as a summarization technique. i.e. why should it be materially different for me to do pathfinding if i have a full network topology information (nodes + ports + links for everyone) vs. summarized network information (my nodes + ports + links and views for everyone else's topologies). What are people's thoughts on this? Cheers, Aaron