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

[James Carlson]

Caitlin Bestler writes:
> The extent to which TRILL should address is this is with the context
> of Appendeix C. *If* an RBRidge is using ECMP (or any form of
> multipathing) then it SHOULD avoid splitting any single 802.3ad
> conversation over two paths.

That's obvious enough that it ought not need to be said.  In other
words, I think that if you don't know at least that much, then you're
going to have trouble all over the place; ECMP is probably the least
of your worries.  The RFC should be a protocol spec, not a tutorial on
networking.

However, that's not sufficient in comparison to 802.3ad, because you
*can* get reordering within a single conversation without ever
splitting it across two paths.  This case can occur if you move
(forced or otherwise) a given conversation from one path to another:
the packets sent on the 'old' and 'new' paths race each other to the
destination, and you may have some trivial reordering as a result
until steady state returns.  (Max delay across the network)

Of course, the same thing happens if you don't have ECMP and you have
a change in the IS-IS layer that causes you to choose a different path
for an entire destination.

In 802.3ad, they use a Marker PDU to fix this problem (since the
underlying links may have some buffering that ends up behaving the
same way as delays in those separate ECMP paths), but we don't have
that.  We're stuck with trivial cases (all relating to link and
RBridge state transitions) that can introduce modest amounts of
reordering in some cases.

But so what?

> That is something that anyone implementing multipathing probably
> would have done anyway, but the standard would be more complete
> if this was stated.

Maybe ... though I think stating the obvious tends to bloat the
document and introduce other risks.  (Such as a mistaken belief that
the RFC is "all" that you would ever need to know in order to
implement.)

> If someone wanted to provide multipathing within the context of
> a single conversation, whether it involved multiple 802.1 clouds
> or not, they would need to create a protocol that provided the
> intended sequence information for a reassembly function at the
> destination. That protocol could certainly be a TRILL extension,
> but there is no real need to discuss such a possible extension
> in the base protocol.

Agreed; a sequencing mechanism is a mistake we can certainly make
later.  ;-}

-- 
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