> From: "Tony Li" <[EMAIL PROTECTED]>
>> Is the problem here with the basic MPLS specification (i.e. no
>> semantics for allowing a single label to refer to more than one
>> out-bound link, precisely to cleanly allow ECMP _at the switching
>> level_), or with the control plane (which doesn't allow multiple MPLS
>> paths to be created for ECMP use to a given destination)? Or both?
> Yes, this is a basic MPLS shortcoming. Not enough data visible at
> switching time to keep flows ordered and do ECMP.
Well, that's a different problem... But isn't out-of-order delivery a problem
_anytime_ you do multi-path, e.g. at the IP level? Surely the only way to
deliver in order is to do some re-ordering (hence buffering) at the far end
of the path split, where the packets come back together at one place?
Or is your point that if you're going to do ECMP, you need to not send
packets belong to a single 'connection' (for lack of a better word) down two
different parallel paths? In other words, my option i) is exactly what you
don't want (since it will inevitably scatter packets from a single
'connection' across multiple paths). Rather, it should be done with ii),
which allows the entity which allocates packets to the various parallel
labels to make sure to assign all packets from a given 'connection' to a
single path?
> we cannot reasonably expect to keep raising (WAN) link speeds. Thus, we
> will do more ECMP across more lambdas.
An interesting issue. Let me put it into the hopper and think about it.
What's interesting at an architectural level is that in some sense this is
back-push against the 'we need to be able to aggregate traffic' concept we've
had for several decades. For instance, in Nimrod I put a lot of thought into
working out how to join flows into aggregate flows, and do so recursively,
creating 'mega-flows', and then de-aggregate them at the far end (which turns
out not to be trivial if you want to minimize state needs at the
de-aggregation point), because the concept was that handling many smaller
flows was economically infeasible in the core. Now it seems we might not want
to push that too far!
Noel
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
