[rbridge] PS issue #4

[Gray, Eric]

Joe,

	This would work, as long as you don't use the wording 
you suggest.

	It is one thing to say "use a technique that will ensure
that order is preserved within flows" and another to say "use
a technique that will ensure that order is preserved on a per
flow basis."

	One common technique is to use a simple hash function
where the number of hash-results is equal to the number of 
alternatives from which the path selection processor has to
select.  What goes into the hash function may include the
fields you mention - though it may also use other inputs and
other techniques.

	Which is by way of a segue into another snag in word
choices: you don't want to specify an exact algorithm.  Down
that path we will find IPR pit-falls.  

	Any specific path selection algorithm affects only the 
device making the path selection.  That means it comes under
the heading of "what I do in my box is my own business."

	What really needs to be said - particularly at a level
of "architecture" is that devices using multiple paths to
forward frames MUST use some path selection algorithm that 
will prevent persistent re-ordering of frames within flows.

	It may be worth-while to point out that some of the 
available path selection algorithms have built in sanity
checks that can be reasonably proficient in detecting cases
in which flow discrimination will not be effective (such as
in the encrypted case Harald refers to).  

	Also, it is worth noting that there is only one place 
that encryption of the inner Ethernet header may reasonably 
be expected to occur and that is at the ingress RBridge.  
Prior to that point, the un-encrypted header was required 
for forwarding.  As a result, it is certainly possible for
the ingress RBridge to make a path selection based on the
un-encrypted inner header information.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> Sent: Thursday, December 08, 2005 12:05 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Harald Tveit Alvestrand wrote:
--> > 
--> > --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
--> 
--> This is an easy position to adopt, but I'm wondering whether anyone
--> considers the result overly restrictive - esp. where addressing the
--> limitations of STPs (even MSTP) using Internet-style routing is the
--> issue (where Internet routing is still embracing multipath).
--> 
--> An alternative would be to allow multipath but limit it for a flow. 
--> Here a flow would be for a single source or destination ethernet 
--> address ('external' address). That would allow for multipath for 
--> internal destination addresses (multipath to destination) but retain 
--> ordering per 'flow' (in this case the internal addresses act as ports).
--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDmGeeE5f5cImnZrsRAsClAJ4krvsFpljd4/kF2+GtvLvJ51Th+ACdGkDb
--> J2cAghjITlOjYdkBBFm2/OI=
--> =8F9a
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->