[rbridge] Fwd: In-order delivery not an issue?
james.d.carlson at sun.com
Fri Oct 17 11:02:06 PDT 2008
Caitlin Bestler writes:
> 802.3ad requires that a given "conversation" (a sequence of frames
> for which ordering is desired) not be shifted from one link to
> another link without taking *some* mechanism to prevent re-ordering.
> Marker PDUs are defined as a standard method of achieving this goal,
> but it is explicitly not the *only* solution.
> Similarly, any specific ECMP strategy for RBridges would have to
> ensure that moving a conversation from one path to another path
> did not cause re-ordering.
Note that the same problem occurs when IS-IS recalculates a new path
for a given destination. It's not a special problem of ECMP -- though
we seem to be talking about it that way -- it's inherent to datagram
routing when there may be topology changes.
> Specific solutions can be documented
> in later specifications. There is no need to include them in the
> base protocol, simply not moving them except after a path becoming
> unavailable is sufficient with some simple timing heuristics.
> Anyone who wants more dynamic load balancing even within a
> single conversation can propose a specific algorithm in a
> later draft.
I agree ... and this also points towards a "quality of implementation"
issue rather than something that needs to be specified as part of the
> These are fundamentally the same, its just switching paths
> rather than switching links, and because paths are longer
> than links the timing is on a different scale. But the fact
> that so many link aggregating bridges do *not* use the Marker
> PDUs is a strong argument on why the TRILL base protocol does
> not need to specify their equivalent. The base protocol is
> already a large document, we should not force extra material
> into it that can be handled in supplemental specifications.
I don't want us to do anything like that, either. I pointed it out to
show that they drove well out of their way to address this problem,
while we are not.
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
More information about the rbridge