Subject: [rbridge] PS issue #4

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 8 Dec 2005 14:34:55 -0500

Harald,

	I agree with your concerns about layer violations - particularly
to the IP/TCP level.  However, if a source destination pair is defined
by RBridge ingress/egress MAC addresses, then it may be very reasonable
to allow use of any VLAN id as a "flow distinguisher".

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Harald 
--> Tveit Alvestrand
--> Sent: Thursday, December 08, 2005 1:45 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> 
--> 
--> --On onsdag, desember 07, 2005 12:45:19 -0800 Joe Touch 
--> <touch at ISI.EDU> 
--> wrote:
--> 
--> >>> The latter affects whether multipath forwarding is 
--> supported inside the
--> >>> rbridge and whether it also requires reordering 
--> facilities at the
--> >>> egress.
--> >>
--> >> multipath between a single source/destination pair may 
--> be troublesome
--> >> enough that we should not attempt it.....
--> >
--> > Isn't that one of the opportunities we wanted to support, though?
--> >
--> > It's already supported by the Internet protocols we're considering
--> > (e.g., IS-IS - see RFC2991). As per below, do we want to 
--> prohibit it
--> > outright, or assert that IF equal-cost multipath is used 
--> then reordering
--> > mitigation (and perhaps latency smoothing) needs to occur?
--> 
--> from RFC 2991:
--> 
-->    All of the problems outlined in the previous section arise when
-->    packets in the same unicast or multicast "flow" are split among
-->    multiple paths.  The natural solution is therefore to ensure that
-->    packets for the same flow always use the same path.
--> 
--> I think it makes sense to say:
--> 
--> - we don't require that multipath for one 
--> source-destination pair be 
--> supported
--> - IF multipath for one source-destination pair is 
--> available, and can cause 
--> persistent reordering, we need reordering mitigation in order to be 
--> consistent with the Ethernet service model
--> 
--> I'm troubled by the implicit layer violation in the 
--> multipath algorithm 
--> trying to detect "flows" at a higher level such as TCP sessions.
--> (for extra complexity, add IPSec or encryption at Ethernet 
--> layer.... both 
--> would make most flow-detection algorithms go haywire....)
--> 
-->                    Harald
--> 
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->