Earlier, David Williamson wrote: % Interesting idea, but not all critical traffic is TCP. My site, % for example, depends on UDP based applications. My customers % (generally Fortune 100 companies) aren't really interested in routing % scale problems, but just want the service I offer to work. That % requires me, in the current world, to multihome a whole pile of % PI allocations.
It would be helpful if one could write up an I-D describing one's operational practice and its objectives. That would help inform everyone of one's desires. % While my announcements are pretty efficient, I'm clearly one % of the problem sites you try to address, yet your solution is % inapplicable for the vast majority of traffic. There are multiple proposals on the table here. That one proposal might not be suitable for one's situation does not imply that all solutions are not suitable for one's situation. % A simple approach might be to try to stripe UDP traffic across % all available paths. I hope it is obvious why this is a bad idea % with real-time traffic. % % For me, at least, your solution is only a half-solution. Interesting, % but I think I agree with Geoff that this needs to get fixed in the % network layer. Again, one non-network-layer proposal not being suitable to some requirements does not imply that all non-network-layer proposals will not be suitable to requirements. Please let us be careful not to over generalise about possible solutions; each deserves individual evaluation and consideration. Cheers, Ran Atkinson [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
