[Nml-wg] Network and domain abstractions

[Freek Dijkstra]

John Vollbrecht wrote:

> I would like to pursue the concept of view or model.  My primary 
> interest is in terms of how the dynamic circuit path finding and path 
> creation will use a topology description.
> 
> 1. A "real" topology exists which describes real devices, interfaces, 
> and links.  It includes parameters like bw, latency, geographic 
> location, and capabilities like switchint  or adaptation (e.g. mapping 
> VLANS or doing GFP conversion between ethernet and SDH).
> 
> 4. On and from this real topology there are derived "views or models" 
> which are useful to different applications.  In my mind this ability to 
> have a common real topology from which different views are created is 
> very powerful.

I agree with your statement that it is useful to talk about an actual 
network, knowing that it really is that network and not some abstract view.

Could you define "real topology" for me? Is that a single network 
(controlled by a single domain), or is that all networks together?
If it is all together -- I like to emphasize that I prefer that there is 
a concept of a common real topology, but no-one has full knowledge of 
this real topology (likely they have a full knowledge on the local 
domain, and abstracted views of other domains).


> 2. The "real" topology includes information about control of 
> capabilities - the administrative owner(s), the operational owner(s), 
> and any device that can activate the capabilities.

Yes, and I would distinguish between the physical "network" class and 
the organisational "domain" class (which is the administrator of a network)

A few notes on terminology: after discussions a couple of years ago, I 
now distinguish between
- juridical owner
- economic owner
- administrator = operator

Where the administrator is the same as the operator: the entity that 
enforces policies, and the economic owner is the entity that decides on 
policies.


> 3. The real topology has groups - which might be called networks, or 
> domains or both.  It is not clear exactly how this will work.

You previously said that you want to have a "common" real topology. Does 
the grouping of this real topology in domains should also be common? 
Thus is it the same for everyone, or could device A be in domain 8 for 
me, while it is in domain 11 for you?

I hope there is such a common grouping of all network elements into 
networks, and everyone sees the same networks. However, I'm fine to have 
an additional "view" concept where other entities may see different views.

> DCN views
> 
[...]
> An internal topological view of a domain will include all the 
> capabilities that are in a domain and the devices that contain the 
> capabilites.  In the simple case this is all the nodes and links in the 
> domain.
> 
> An external topological view of a domain includes the links to external 
> domains and the internal device to which the link is connected.  It also 
> includes the capabilities of the domain to act on external links.

I do not see why it is necessary to know about the terminating device 
for links in the external view. It seems to me that all I need to know 
is the encoding of the link, the the capabilities of the domain 
('network' in my terminology) to act on this link.

> A DCN internal pathfinding view contains Nodes and links for a domain.  
> The nodes and links may correspond to the real topology or may be 
> virtual links that are created by combining connections between 
> locations into a single link (e.g. 4 GEs between sites are treated as a 
> single link for pathfinding purposes) or by splitting connections into 
> different links (e.g. STS-1-48= link1, STS-49-96 = link2).

Good. We need a discussion about links. But you seem to suggest that 
according to you a "link" is equal to a ITU-T G.805 "link connection" 
(that is, logical links). "Splitting" is not a word I would use though.

Your example is pretty complex. Do you also want to be able to (a) say 
that the STS-1-48 link is composed of 48 distinct STS channels? (b) do 
you want to be able to say that link1 and link2 are in fact transported 
over the same OC-192? If so, you need rather detailed multiplexing and 
adaptation classes to describe this.

> A DCN external pathfinding view contains domains and links between 
> domains.  There is some question as to whether a domain should be 
> abstracted to look like a node.  My view is that from a DCN operational 
> view they are different.

So do you propose that we have a distinct "domain" and a "node" class? 
Could you define them for me, so I know the difference between the two?

> routes inside domain are calculated between 
> nodes.  routes between domains are calculated between edges of domains.

I may do path finding in a completely different way (I may look at 
interfaces and the grouping in nodes/devices/domains altogether). I 
think such implementation details are firmly out of scope of the NML. 
What is in scope is that there is enough information for you to do the 
path finding.

> I am not sure if the elements in a path 
> request need to have a topological name.

How do you want to refer to an element? How other then it's name? (This 
is not a rethoric question! A valid answer may be "by it's properties".)


Finally, you wrote in your first sentence that you "like to pursue the 
concept of view or model". Good. However, you only defined "internal 
topological view" and "external topological view". I think that this 
distinction can already be handled by the "network" concept. A network 
has capabilities, external links, and a bunch of internal network 
elements. For the internal view, I list it all. For the external view, I 
only announce the capabilities and external links. I do not see the need 
to define another "view" class or "model" class to accomplish this.

I do like the "view" concept, but I have not really seen a convincing 
argument for it. The one that came close was Evangelos mail of March 4 
[1], where he had different views for monitoring and other services.
In the end, we always give a limited set of information to our 
neighbours. That is a view on our full topology knowledge of our own 
network. That is always possible. However, if we later want to *refer* 
to this specific set of information, then we want to name this "view".

Regards,
Freek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20080319/9eee880f/attachment.bin