Subject: Re: Fwd: Minutes / Notes

From: "J. Noel Chiappa" <[email-masked]>
Date: Sat, 19 Jul 2003 13:15:29 -0400

> From: Brian E Carpenter <[email-masked]>

    > 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 19 Jul 2003 20:16:59 +0200

On zaterdag, jul 19, 2003, at 19:15 Europe/Amsterdam, J. Noel Chiappa 

> by picking one of N addresses, with no capability to change it).

I agree that having two or more mechanisms is undesirable in the long 
run.

On the other hand, solving the source address / ingress filtering issue 
(which we almost certainly need to do for loc/id anyway) would make it 
possible to achieve many multihoming benefits by only slightly 
modifiying applications, i.e., let them cycle through all possible 
addresses. This is of course not nearly as good as a full solution, but 
it is much better than what we have now.

I'm not a big fan of bringing mobility in the picture, though. I 
haven't seen any figures on the implementation status of MIPv6 in our 
collective favorite OSes, but it hardly seems omnipresent. When also 
considering the complexity of MIPv6 and the fact that MIP assumptions 
fail badly for multihoming I don't see much value in a MIP approach to 
multihoming.

(If I could I would even like to go further by scrapping MIPv6 
wholesale and starting fresh with loc/id for both multihoming and 
mobility.)

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 20 Jul 2003 17:41:57 +0200

Hi Iljitsch,

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Iljitsch van Beijnum
> Enviado el: sabado, 19 de julio de 2003 20:17
> Para: J. Noel Chiappa
> CC: [email-masked]
> Asunto: Re: Minutes / Notes
>
>
I guess i agree with most of your comments, however i think that you are
missing an important issue which is timing.
MIPv6 is already an RFC and it is being deployed now, so soon CN
functionality can be on most implementations.
So we could do a whole new stuff (and i think we need to do it) but
meanwhile we should benefit from this mipv6 capabilities which will be
available on nodes.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 20 Jul 2003 17:41:55 +0200

Hi Noel,

> nombre de J. Noel Chiappa
> Enviado el: sábado, 19 de julio de 2003 19:15
> Para: [email-masked]
> CC: [email-masked]
> Asunto: Re: Fwd: Minutes / Notes
>
>

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

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 11:17:28 +0859 ()

Noel;

> all packets are as efficient as the less-capable case.

By definition, lower 8 bytes of 8+8 address is ID that 8+8 carries
the identity 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.

It means not all the locators are carried in every packet, which is
of course even with mobility based ones or 16+16.

							Masataka Ohta