Freek Dijkstra wrote:
(My opinion: I like to see at least an (admin)domain object, and possibly a "view" object. I don't yet see a need for a "network" object different from a "domain" object. Nevertheless, Aaron presented exactly those two, and I love to hear that argument). The reasoning behind the network object was to have a way of describing non administrative-domain groups. So, if you had a VPN network, it could be described using a network object. I think the 'group' element that we talked about at OGF would work fine for the reason we had network around. In fact, I think the 'group' element encapsulates this view/model element. Aurélien Cedeyn wrote:
For me, the "Model" object groups objects which have relation between each other, they are "connected". Moreover, this group represent the network itself with a particular point of view. I think that with this concept we will be able to view cloud or a black-box as a network. Because whatever how deeply you describe your network, some information will be masked.
I think that a "domain" object (with each device only part of one domain) can already have this black-box abstraction. However, the "view" object is more flexible, and allows either a more detailed view (a network domain with some more details described) or a more abstract view (two or three domains abstracted as a single cloud) -- I am not sure how that would work in practice though, so suggestions are welcome. So, there seem to be two independent pieces being talked about here:
1. i want to look at a layer3 view of this network. Thus, give me all the nodes, ports and links that are at layer3. 2. i don't care what the contents of the network are, i just want a blackbox view of it. I think the model/view object handles case 1 just fine. It really the same concept as the group element we discussed. For the second canse, I don't think it does. In that case, all I want is the external view toward the world of the network, element(s) or whatever. In this case, i think that a black box view can be handled by using abstract elements and the 'composed-of' relation of the element. Something that is black boxed could be an abstract node with abstract ports describing the external interfaces for that boxed element. This element could (but would not need to) include a "composed of" relation containing pointers to or definitions of the abstracted set of nodes/ports/links/domains/etc that comprise it so that users could look into the box if they want to, but can still view it as an abstraction. Then, you can hand off that element, include it in paths, etc. without it being a special case. As an example, with this model, you can do path finding from node to node and not care how the path finding 'inside' the node is accomplished. If the node represents a full domain, it could do its own path-finding. If the node represented a router, it wouldn't be doing any pathfinding. Essentially, it'd be viewed as a circuit comes in to this node and a circuit goes out from this node, and i don't care how it does it in the middle. Using the abstract node concept, you could also produce more detailed versions of summarized data. For example, instead of having one node for a domain, you could have an abstract node for each externally-facing node and then provided a summarized description (bandwidth, latency, loss-rates, whatever) of how the externally-facing nodes are connected by simply including abstract links between them. Cheers, Aaron