[Nml-wg] About modelisation of the network description

[Aaron Brown]

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