Re: Draft of updated WG charter

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 9-jan-04, at 23:30, Jay Ford wrote:

> Path selection is only part of the multi-homing problem, & perhaps the 
> easier one.  In my realm of experience, most end systems have only a 
> single path out, so there is no path selection required.

> The nastier problem is source & destination address selection.  In the 
> case
> of multiple addresses per host, the host is forced to make the 
> selection but
> the implications have to be handled in the rest of the network 
> (anti-spoof
> filtering, routing policy...).

I'm not sure what you mean by "path" if you say that a host only has 
one. I think for the purpose of discussing multiaddress multihoming, a 
good definition of a path would be a combination of source and 
destination addresses.

The good part is that as soon as we implement mechanisms that allow 
transport sessions to jump addresses, the address selection problem 
isn't really a huge deal anymore: if you find yourself using 
unfortunate addresses, you simply jump to something more suitable.

> I'm not claiming that end systems should be completely stupid & the 
> network
> should do everything.  We might just disagree on where the 
> functionality
> dividing line should be.  I think address selection & path selection
> shouldn't be on the end system side of the line, so an architecture 
> which
> causes every end system in every multi-homed network to do those jobs 
> seems
> broken to me.

So what about having special boxes that sit between the hosts and the 
routers and handle multihoming? Obviously anything that can be 
implemented in an external box can also be integrated into a host when 
desired, so unless the drawbacks of allowing this functionality to be 
implemented in an external box are huge, this shouldn't take anything 
away from the people who actually like their hosts to handle this 
autonomously.