[rbridge] Fwd: In-order delivery not an issue?

[James Carlson]

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.

True.

> 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
base protocol.

> 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