[rbridge] PS issue #4

Gray, Eric Eric.Gray at marconi.com
Thu Dec 8 08:50:26 PST 2005


Harald,

 	See below...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Harald 
--> Tveit Alvestrand
--> Sent: Wednesday, December 07, 2005 3:37 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> 
--> 
--> --On onsdag, desember 07, 2005 12:12:14 -0800 Joe Touch 
--> <touch at ISI.EDU> 
--> wrote:
--> 
--> > Which requirement:
--> >
--> > a) that reordering is a transient possibility
--> >
--> > b) that persistent reordering is acceptable
--> >
--> > 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.

I disagree.

In point-to-point technologies, it is often the case that point-to-point
links are "bundled" - either to create an effectively larger "link", or 
to allow for efficient load sharing/distribution.

If multiple similar "cost" paths exist between an RBridge within a campus
(including the egress) and the egress RBridge for any given destination,
then using each of these multiple paths is very similar to (if not exactly
the same as) link-bundling.

This is a reasonably well understood technology.

--> .... I don't think there is an ordering requirement for packets between 
--> different source/destination pairs.

I agree, but would add that the same applies to both different sources and
different destinations, separately, as well.

--> 
--> I don't think that persistent reordering (that is, reordering when the 
--> network is not being perturbed) is acceptable - if severe, it 
--> *significantly*  degrades TCP performance, if nothing else.

I agree, but strongly suspect that this is not what was being suggested.

--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


More information about the rbridge mailing list