[Nml-wg] Topology Model and Pathfinding

[John Vollbrecht]

Hi Jeroen --

thanks  for including NML-- I think we should also include NSI, but I  
think for the short term the folks that are most interested are also  
in NML.

I added to your pics and included below.  Your bottom picture is  
correct (second in the revised doc). The top picture has a link  
outside a network which doesn't fit my model, but I think is the way  
you think about it.    I add a third pic to show that a network might  
terminate at the end of a link.

What do you think?

John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Port-point.jpg
Type: image/jpeg
Size: 20134 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20100210/ce29afdc/attachment-0001.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Port-point.jrv.graffle
Type: application/octet-stream
Size: 307346 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20100210/ce29afdc/attachment-0001.obj 
-------------- next part --------------


On Feb 10, 2010, at 2:10 PM, Jeroen van der Ham wrote:

> Hello John,
>
> I'm replying to the NML list, because I strongly believe that this  
> issue must be discussed there.
>
> I think I understand your point now, I've created a diagram  
> (attached) that I think describes the situation.
>
> The top view shows the physical topology, there are two networks,  
> connected by an inter-domain link, which is owned by a third party.
>
> At the bottom I've tried to capture the way that you would like to  
> describe this situation. Is that correct? I've attached the graffle  
> file too so that you can correct it if I'm wrong.
>
> Jeroen.
>
>
>
> On 10/02/2010 09:51, John Vollbrecht wrote:
>> Hi Jeroen --
>>
>> I cc some others in case they have comments.
>>
>> The issue is what I was discussing with you at JTs. I will try to
>> describe it better over the next few days. I certainly agree (as I  
>> said
>> when we discussed this) we should talk about it at OGF or before.
>>
>> Let me try a bit to describe the issue now - comments will be  
>> helpful in
>> getting a good description.
>>
>> I think the basic thing is that the atomic element in NSI is the  
>> set of
>> resources that is controlled by a NRM (network resource manager).  
>> Those
>> resources include switches/nodes a links in your terminology. For  
>> sake
>> of argument call such a set of resources a network.
>>
>> I think network could be covered in NML by calling such a set of
>> resources a group or a network group. For NSI (as I understand it)  
>> edge
>> of a network is a port, where a port may be on either a link or  
>> node in
>> NML terminology. This is where NML topology is missing a terrm - the
>> concept of a port at the end of a link. If that were there we could  
>> have
>> a simple mapping between NML and NSI concepts.
>>
>> Networks interconnect by joining ports together at a point. A point
>> might be considered to be where a male and female connector join -
>> either physically or logically. This is essentially the ASON (ITU
>> G.8080) model for interconnection of subnetworks. If NML has the  
>> concept
>> networks connecting at ports then I think there would be good mapping
>> between NML, NSI and ASON.
>>
>> If we use this model, then the NSI topology is of a set of networks
>> interconnected at points (or by connecting ports). By definition  
>> network
>> can (potentially) make a connection between any two points - so  
>> from a
>> graph point of view, a network is a vertex and a point or joined  
>> ports
>> are edges.
>>
>> Some conversation --
>> To help resolve this and help possible conversation about it, I  
>> offer my
>> understanding of the NML issue with this. Please correct me if I  
>> have it
>> wrong. From a topology point of view NML assumes both ends of a  
>> Link are
>> the same and can be identified by the node to which they connect.  
>> Adding
>> ports to the end of links increases the number of items that must be
>> defined in a topology which makes definition of a topology longer and
>> longer. Further, since topology is well defined as between node and  
>> link
>> it is not clear why treating networks as supernodes with links  
>> between
>> them doesn't work.
>>
>> There may be some way to combine these that I haven't thought of or
>> understood yet. The problem I see from a inter-network (NSI/ ASON)  
>> point
>> of view is that links are resources that are part of one or another
>> network, not something outside them. From a reservation and  
>> provisioning
>> point of view each network must make a connection between its ports.
>> Ports from two networks are connected in a topology so when  
>> connections
>> across the networks are provisioned, the concatenated connection  
>> across
>> both networks is provisioned.
>>
>> Perhaps there is a way that topology and resources can be separated  
>> so
>> that links don't have to have names and are implied. From a  
>> provisioning
>> and monitoring view the control is certainly in a node, and so  
>> there may
>> be a difference between what is the resource termination point and  
>> the
>> control points.
>>
>> The one problem that having implied names doesn't seem to be able to
>> handle is when a link is a resource independent of nodes at either  
>> end.
>> In this case the link is a network which must be included in the
>> topology for resource reservation and scheduling even though it is  
>> not
>> included in the control topology.
>>
>> ---
>> I am interested in comments and suggestions - of course. I think  
>> this is
>> a very important concept to work through between groups.
>>
>> John
>>
>>
>>
>> On Feb 10, 2010, at 11:07 AM, Jeroen van der Ham wrote:
>>
>>> Hi John,
>>>
>>> The NML set out to create a topology model that is sufficient to do
>>> pathfinding, at least on the topological level. I understand from  
>>> the
>>> discussion with you that you feel that NML is currently not  
>>> providing
>>> enough terminology to fulfill the needs of NSI pathfinding.
>>> I think it is important that this is discussed in the NML group.
>>> However I don't feel I have enough understanding of your problem to
>>> make a good case for it. Would you mind explaining your problem to  
>>> the
>>> NML mailinglist?
>>>
>>> Thanks,
>>> Jeroen.
>>
>>
>>
>
> <Port-point.graffle><Port-point.pdf>