On 2007-12-22 07:32, Tony Li wrote:
On Dec 21, 2007, at 3:32 AM, Victor Grishchenko wrote:
RFC 3484 R. Draves Microsoft Research
"...Well-behaved applications SHOULD iterate through the list of
addresses returned from getaddrinfo() until they find a working
address...
...all else being equal prefer address pairs having the longest
possible common prefix..."
Seems good enough. In the bunch-to-the-host scenario
longest-common-prefix might be the best simple strategy.
In the context of an IP connection, keeping it open while a site
rehomes is hardly critical in the common case.
Unfortunately, that's exactly the critical case that's vital for
multi-homed sites. If our transport protocols were agile enough to
recover across the failure of any given address, then there would be far
less incentive to demand PI addressing. Shim6 is simply a lie to
preserve the delicate fiction that the transport protocols operate under.
Right, and there's also the issue that RFC 3484 doesn't handle
source address selection - but that is crucial to avoid ingress
filters when sending to an arbitrarily chosen transit ISP. This
is being discussed currently in IPv6-land.
Brian
Intuitively, an
ordinary topology change will affect just part of a bunch, so the rest
remains functional and applications may re-connect.
So, my point holds. Further sophistication is useful but it is hardly
mandatory. May always sell it as v2.0 / mobile extensions / pervasive
load balancing / etc
This trivializes the service interruption that comes with breaking a
connection. For those that are trying to provide reliable, robust
services and have revenue tied to it, losing a connection is nothing
short of lost revenue.
Tony
--
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
