[Nml-wg] About modelisation of the network description
Aaron Brown
aaron at internet2.edu
Tue Mar 4 11:42:01 CST 2008
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
More information about the nml-wg
mailing list