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