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@ogf.orghttp://www.ogf.org/mailman/listinfo/nml-wg