John Vollbrecht wrote:
This is to contribute to the conversation about networks and abstraction. This is from the point of view of DCN and the need to do path computation at both the inter and intra network level.
In my view the elements in a (interdomain) topology are nodes, links and networks (or domains).
Nodes and links are pretty well understood, and are used for intradomain routing. Networks and links are used for interdomain routing, and it seems to me that often the attempt is to "abstract" networks as nodes so they use the same path finding as is used for nodes and links. There are problems with doing this, because networks are note nodes, and if abstracted to something other than what they are the abstract capabilities, with few exceptions, will be different than the real properties. For example if a network is abstracted as a single node, then there is no way to show different capacites between different edge points. If the network is abstracted as a mesh where every edge connect to every other edge, and there as a way to indicate bandwidth between edge points, then there is no way to show that some connections between edge points share the same internal path and so may block each other.
In my mind it is good to consider network as a basic topological element. When doing interdomain routing, it is done between networks. One can use fully qualified links between networks, and can get these by "lifting" the interdomain links from the topology of each network. Routing between networks may need more policy or hints than routing within a domain, so it may be necessary to share properties of networks when routing between networks.
I realize that this is very similar to creating an abstact view of a network, but I think it make it clearer what is being done, and it seems to me does is not harder and may be easier than creating abstract views.
I am interested in what others think about this. My idea on the node was simply to define it as such:
A node has interfaces to the outside world and can be comprised of elements underneath. With that defintion, network simply becomes a subclass of node. That's not to say that it won't be a proper subclass with its own set of attributes, but just that it's a type of node. Passing around node elements with no meaningful way to differentiate them would be silly, but keeping like concepts as similar as possible I think is a good thing. What we need to have is a clear definition of 'network', how it is going to be used, and why we used the generic term network to describe that concept. How are domain and network different and what is the differentiating factor? If we have the two level approach of a domain has networks but networks only contain nodes/links/ports, why not allow networks in networks? Also, why not allow nodes to be in multiple networks if an external set of interfaces at some level can be defined for that network (thinking in the overlay network perspective). Especially since 'network' is a general term, these kinds of questions need answers. Thoughts? Cheers, Aaron