Re: Fwd: Minutes / Notes

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: Brian E Carpenter <brian@hursley.ibm.com>

    > this is one of the many "shoulds" in our agreed list of goals. Whether
    > we can achieve this "should" simultaneously with enough of the others
    > is very much an open question .. it's one of the reasons why we may end
    > up with more than one solution. In some scenarios, this may be a
    > dominant goal; in other scenarios, it may be unimportant.

I don't think it's realistic to propose the addition of two separate
mechanisms to do multi-homing, with slightly different capability sets - one
able to keep conections open, and one not (I assume that this latter is done
by picking one of N addresses, with no capability to change it).

Look, for a multi-homing mechanism to really be really useful, it has to be
basically ubiquitously deployed; i.e. if you're multi-homed for reliability,
you want *all* your correspondents to be able to get to you when one of your
links is offline, not just the limited` subset that implement multi-homing
type 17.

Once you have the most capable multi-homing mechanism ubiquitously deployed,
as far as I can see there is almost no use at all for the less capable
versions. There simply isn't that much difference in the operational overhead
to make it worth having a second mechanism available, one that's less capable
as well.


E.g. suppose you go with something that looks like MobileIPv6, where you have
location/identity overload in the initial case (you pick one of N addresses,
and use that when you open the connection), and then use an additional
routing header to keep an existing connection open when the primary link it
was using fails. So? The initial case is as efficient as the less-capable
version, and if the "link has failed, connection continues" mode of the
more-capable version is less efficient, so what? It does something the other
can't do.

Or suppose you go with 8+8, or a solution where the identity is not carried
in every packet. If you want to change the location, there are a couple of
packets of negotiation to change the binding and then you're done. Basically
all packets are as efficient as the less-capable case.

If you go with 16+16, then all the packets have to have an additional header,
it's true. But in this design, all connections have to run in this mode all
the time, or they lose the capability to survive a link failure.


If you have two separate multi-homing mechanisms, then the cost, in system
complexity, implementation size, amount of protocol specification work
needed, etc, etc just seems to me out of all proportion to the benefit. Talk
about second-system disease! Pick one.

	Noel