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

[Caitlin Bestler]

> From: Venkatsubramaniyan G, TLS-Chennai <venkatg at hcl.in>
> Date: Mon, Oct 6, 2008 at 7:21 PM
> Subject: RE: [rbridge] In-order delivery not an issue?
> To: rbridge at postel.org, Radia Perlman <Radia.Perlman at sun.com>
> Cc: gvsm <g.venkatasubramaniyan at gmail.com>
> 
> 
> 
> Radia,
> 
> Assuming a traffic flow (of given SRC, DST and QoS) happens through
> multiple equal cost paths in Rbridge cloud, I think TRILL cannot not
> offer guarantees that the frames at egress are in the same order as in
> ingress in Layer-2.  The individual paths can have different traffic
> conditions and reaction mechanisms which may not give in-order
> behavior, which could largely vary.
> 
> At present it is assumed this is left for ES ('s higher layer) to
> handle out-of-order packets.
> 

I do not believe that is an accurate characterization of Appendix C.
There it states that the mechanism(s) used to ensure that conversations
are not mis-ordered by ECMP is "out of scope".

   When multipathing is used, frames that follow different paths will be
   subject to different delays and may be re-ordered.  While some
   traffic may be order/delay insensitive, typically most traffic
   consists of flows of frames such the re-ordering within a flow is
   damaging. How to determine flows or what granularity flows should
   have is beyond the scope of this document but, as an example, under
   many circumstances it would be safe to consider all the frames
   flowing between a particular pair of end station ports to be a flow.

It might be useful to explicitly state that any flow considered to be 
a "conversation" for 802.3ad purposes SHOULD be similarly treated by
any RBRidge implementing multi-pathing. But such a statement is only
making explicit what I think is already clearly the intent.