Subject: RE: multi-interfaced vs multi-addressed [Re: [Mip6] Draft Agenda for WG meeting at IETF58]

From: Soliman Hesham <[email-masked]>
Date: Tue, 4 Nov 2003 03:22:13 -0500

> On Tue, 4 Nov 2003, Soliman Hesham wrote:
 > > => Yes and this is applicable to nemo as well. 
 > > This seems like an issue for IPv6 to handle: i.e.
 > > associating certain properties to a prefix. Either
 > > multi6 or IPv6 should handle this imo.
 > 
 > Carrying your statement a bit further, I must conclude that 
 > we should fix
 > the underlying issues proposed to be fixed in multi-interface MIPv6
 > extensions in multi6 or IPv6 as well?  

=> :) Is this a trick question ? ;) 

Multi6/ipv6 only need to be involved to solve the problem
of associating certain attributes to a prefix. MIPv6 needs
to allow for more than one coa to be associated with a single
hoa. Implementers need to put the pieces together and do
their own interface/coa selection algorithms. 

 > 
 > That might certainly make sense, as there is very little 
 > MIPv6-specific
 > with multiple interfaces which is not present with multiple 
 > addresses w/
 > one interface.

=> Yes, but both cases require MIPv6 to handle more than one
coa for a single hoa binding.

Hesham

 > 
 > <tongue-in-cheek>
 > Let's close shop, we're done!
 > </tongue-in-cheek>
 > 
 > -- 
 > Pekka Savola                 "You each name yourselves king, yet the
 > Netcore Oy                    kingdom bleeds."
 > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
 > 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Thomas Noel <[email-masked]>
Date: Tue, 04 Nov 2003 09:28:43 +0100

> their own interface/coa selection algorithms. 

That's exactly the issue :-))

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Nov 2003 12:31:53 +0200 (EET)

On Tue, 4 Nov 2003, Soliman Hesham wrote:
> of associating certain attributes to a prefix. 

Sure.. that might be useful work, but that does not eliminate the problem 
for a MN w/ 1 interface but 2 addresses.

> MIPv6 needs
> hoa. 

Correct as well.. (but see more below)

But you seem to be neglecting the case where a single interface, but
multi-addressed host would act as a Mobile Node.  It needs MIPv6
mechanisms as well.  Just using multi6/ipv6 for recognizing attributes of
a prefix is not enough!

> coa for a single hoa binding.

Exactly -- which is why solving the generic problem in MIPv6 (the coa-hoa
bindings) is probably necessary.  I'm not sure if we've spelled out 
whether it's absolutely necessary -- e.g., could it be possible to use 
different HoA's for different CoA's?

But I fail to see anything relating to interfaces in the actual problem
statement -- which was the point.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Nov 2003 12:48:16 +0100 (CET)

> their own interface/coa selection algorithms. 

I'm trying to understand different ways to factor this problem set.

One aspect is that between a single home agent and a single home address
one can envision multiple tunnels to different CoAs, and then effectively
do multipath routing across those. In addition to the establishment of
such tunnels one also need to have a mechanism to determine the liveness
of the alternative paths/tunnels. (Perhaps that is what you mean by 
interface/coa selection algorithms.)

Moving this to a correspondent is effectively just a way to propagate the
tunnel endpoints to a different place in the topology.

There is also the more traditional multihoming aspect of having multiple HoAs
assigned to the same node, which can provide additional resiliency and
perhaps load spreading when a mobile node has two relatively far apart
home agents. Presumably this is not mobility specific; a stationary node at
a homehomed household might want to benefit from this as well.

Somewhat separately, there is the desire to do packet classification
at the sender so that different types of traffic can use different
paths (in the general case) or "tunnels" in the mobile-ip case.
Is this something that would only apply to the one HoA/multiple CoA case?

Well, no. If there was such a capability why not be able to use it when there
are multiple HoAs as well? And be able to use if for multi-addressed nodes
that are not using Mobile IP.
One could also envision using such a classification mechanism as a way for
a node (mobile or not) at the end of a slow link to inform its access
router (at the other end of the slow link) which flows to prioritize 
across that slow link.

   Erik

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 04 Nov 2003 15:04:05 +0100

>statement -- which was the point.
Thanks for the remark.
In draft-montavont-pb, we tried to expose the problem statement of 
multihomed mobile nodes.
The definition we proposed (that is not fixed of course) says that a 
node is multihomed when it is multi-addressed.
In the taxonomy we proposed, we use three parameters: number of home 
addresses, number of care-of addresses and number of active interfaces. 
In this taxonomy, we consider the number of interfaces because it seemed 
to us useful to define the scenario (section 4.2).

Otherwise, from the point of view of the benefits, it is very 
interesting to consider how many interfaces are available (eg. to reach 
permanent connectivity). I don't say that any solution we could write 
will be different when the MN has a single interface and multiple 
addresses than when the MN has multiple interfaces, but at this point, I 
think it is important to keep the number of interfaces as a parameter of 
the taxonomy.

Nicolas

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Nov 2003 10:19:19 -0800

> their own interface/coa selection algorithms. 

And what would those attributes be?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Nov 2003 10:33:24 -0800

Yes, I agree. The other thing I have a hard time understanding is exactly
what information can be discovered at the IP layer to allow the home agent
or corresponding node to intelligently utilize multiple addresses tied to
one home address.

The only thing I can see is ICMP Destination Unknown. If the home agent is
utilizing one CoA and it receives this, it could switch to another, somewhat
like SCTP. Most of the other kinds of ways I can think of to utilize
multiple addresses involve decisions that might be better made at other
layers, or at least might require a decision to be made at other layers,
since the decision is not strictly about simple reachability.

But perhaps I am missing something.

            jak

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Soliman Hesham" <[email-masked]>
Cc: "'Pekka Savola'" <[email-masked]>; "Thomas Noel"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, November 04, 2003 3:48 AM
Subject: RE: multi-interfaced vs multi-addressed [Re: [Mip6] Draft Agenda
for WG meeting at IETF58]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Nov 2003 10:46:10 +0100 (CET)

> or corresponding node to intelligently utilize multiple addresses tied to

One could run a periodic "hello" protocol to detect liveness of
each tunnel and use that as an indication to switch from a failed tunnel/CoA
to a working one. Doing this periodically is a waste of resources, thus
if one is going to perform such liveness tests doing it only when data
is being sent and not as a constant background load would make sense.

This could be combined with other information like ICMP errors.

But I suspect that there isn't a shared understanding of what
multiple tunnels/CoAs for a single home address will bring to the table.
One is better availability of the connection by doing failover.
Another is combining it with some policy of what flows use which tunnel
to provide a knob to control performance vs. cost.
And perhaps there are other motivations.

I suspect the solutions might be quite different depending on which
of the possible problems people have in mind.

  Erik