[Nsi-wg] [Nml-wg] Conversation about ITU concepts with Ciena folks

John Vollbrecht jrv at internet2.edu
Tue Sep 8 10:15:50 CDT 2009


Some notes below - this is a good conversation.  I also have questions  
about how stitching works when making requests that cross multi-layer  
networks.  I have taken it as a good descriptive device, but I am  
trying to understand how it works as a path making element.

On Sep 7, 2009, at 3:33 PM, Freek Dijkstra wrote:

> Jeroen van der Ham wrote:
>
>> I agree that George's multi-layer pathfinding seems very similar to  
>> the
>> AutoBAHN approach.
>>
>> Freek in his thesis argues that this approach can work, but does not
>> have a way to handle incompatibilities. Freek uses an example where
>> there are two ways to map Ethernet onto SONET, and the source and
>> destination use different mappings.
>> A path through the network will have to do a remapping along the way,
>> otherwise it can't work.
>>
>> I do not see how a collapsed topology can ever solve such a problem.
>> Perhaps it can, but it will have to specifically supported by the
>> stitching framework.
>
> The approach that must be taken for collapsing is:
> - have a path find agent find multiple paths
> - let the stitching framework try each path in order till a valid path
> is found.
>
> The consequence is that in rare situations no valid path may be found,
> even though one might be available.
How is it possible to try every path and not find a valid one, if a  
valid one exists?
>
> If these situations are sufficiently rare, the simplification that  
> this
> approach brings may outweigh the disadvantage of false negatives.
> So I think this may be a viable approach, even though it is different
> than what I have pursued so far.
>
>
> This is not to say I have no concerns about topology collapsing and
> stitching approaches. I have two concerns about the stitching  
> framework,
> and one about topology collapsing.
>
> For stitching, I like to make sure there is no implicit assumption of
> order in network layers, or worse, that the number of network layers  
> is
> fixed (e.g. as in layer 1-7 in the OSI model), or that a layer may  
> only
> occur once in an adaptation stack.

I  don't think this is a problem, but I leave that for Victor.  I am  
not sure what an adaptation stack is.  Is it something you see over a  
complete path?  I don't think it happens in a single device does it?

> - layers come and go. We got rid of the ATM layer, and some people try
> to get rid of the SONET layer(s). However, just the same, we add
> (sub)layers for Ethernet and OTN.
> - The order can not be fixed: it is getting common to see network
> tunnels, e.g. Ethernet over IP over Ethernet, or simply Ethernet over
> Ethernet (think Q-in-Q).
I am wondering if layers are different if they are Q-in-Q or Ethernet  
over IP.  Seems there needs to be an adaptation between these, but the  
client info stays the same.  It seems to me that collapsing layers  
where the client info stays the same and only the characteristic info  
changes can be useful.

Where adaptations do not exist between specific layers it seems silly  
(at least to me) to flatten the topology.
Where adaptations are not possible between layers  - one cannot adapt  
a VLAN portion of a fiber, at least not without another adaptation  
(e.g. SONET) between them.
>
> My concern about layer collapsing is how it handles multiplexing and
> inverse multiplexing. A SONET circuit in the GLIF community may carry
> multiple Ethernet connections. At my work, we have an immediate  
> problem
> that we must describe the relations between these connections -- if  
> the
> SONET circuit goes does, so will the Ethernet circuits, and our  
> software
> must know this relations or we will not inform the correct customers.
> Therefor, we need a network description that is able to describe this
> relation. I have doubts that this can still work for collapsed  
> topologies.
>
I think this is probably a valid concern.  However I don't completely  
understand it.  Is this the case where lower layers are carrying  
multiplexed upper layer connections and one needs to know which upper  
layer connections are being carried at the lower layer so that if it  
fails the upper layer can be notified?

If so it seems that the lower layer is a Link which carries segments  
of the upper layer and if it goes down the upper layer link goes  
down.  It is then the upper layer's job to notify its users that the  
link is down.

> Regards,
> Freek
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nml-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20090908/7c9fbc08/attachment.html 


More information about the nsi-wg mailing list