[Nml-wg] Network and domain abstractions

[John Vollbrecht]

On Mar 19, 2008, at 1:51 PM, Freek Dijkstra wrote:
> 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).
>
for me a "real topology" is one that matches physical devices as  
understood by operational engineers - stuff that has to be installed  
somewhere.  real topology can be a single domain, a partial domain,  
all the devices in the world -  the real part is kind of  "not virtual"
>
>> 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.

These all seem good to me

>
>
>> 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?
Here is where "real"  topology and views may be different.  In a DCN  
view domains are the same for everyone.  If it is domain 8 for me, it  
is domain 8 for you.  but that is just the view

>
> 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.

I think it is necessary because capabilities of the network may be  
different at different edges.  Also as Jeroen points out it is  
necessary to be able to make connections.

>
>> 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.

could be - I am not familiar with G.805, but this sounds right.
>
> 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.
yes - but from a DCN pathfinding view I don't care how this is done.
>
>> 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?
A domain is a network of nodes.  The main difference from a DCN   
point of view is that nodes are internal and routing within a domain  
uses nodes, routing outside the domain uses domains (or perhaps  
networks would be better name).  This is basically hierarchical  
routing, and has to do with the DCN view
>
>> 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.
well I think DCN uses a specific grouping and this needs to be  
included in its "view"
>
>> 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".)
good question.  right now we have domains, nodes, ports and links.   
these are all potential elements
>
>
> 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.
but the real topology may not  for example reflect the view of  
certain physical connections being multiple links.  and it may  
include a lot more information that is not needed by DCN like  
physical location or administrative owner.
>
> 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".
I think this is a good starting place.  be sure that all the info of  
the "real" network is in the topology but give views of it to  
different applications.  Then applications can define what they need  
and be sure it is there.  And the topology is maintained in a single  
place.

John

>
> Regards,
> Freek
>

John Vollbrecht, Senior Network Engineer
Internet2
office +1-734-352-4960 | mobile +1-734-395-7890