RE: Fwd: Minutes / Notes

["marcelo bagnulo" <marcelo@it.uc3m.es>]

Hi Noel,

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de J. Noel Chiappa
> Enviado el: sábado, 19 de julio de 2003 19:15
> Para: multi6@ops.ietf.org
> CC: jnc@ginger.lcs.mit.edu
> Asunto: Re: Fwd: Minutes / Notes
>
>
>     > 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.
>

I think that what Brian means is that different sites can internally adopt
different solutions, which in turn will provide them different benefits.
Clearly, a solution should not depend on special features on nodes outside
the multi-homed site.
(However, it is posible to think that given solutions would benefit from
optimizations on nodes outside the multi-homed sites)

Regards, marcelo

> 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
>