Subject: on the point of mobility & multihoming

From: <[email-masked]>
Date: Wed, 3 Mar 2004 04:35:57 +0200

From today's session, Dave & Geoff discussed multihoming vs. mobility.  In
a working group I chair, we've had similar discussions and from a transport
layer, maintaining a session during a multihoming change and a mobility change
can be quite similar.  I second Dave's comment that trying to solve two
things at once can be never-ending. He also mentioned that solving two
problems seperately can lead to incompatible or extremely complex solutions
that don't interoperate well.  Could we restrict ourselves to multihoming,
but perhaps the authors of the proposals add a section on Mobility Considerations,
so we don't run into incompatiple solutions?

thanks,
John

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 3 Mar 2004 06:00:19 +0100

(chair hat off)
	John,

I would argue the same. I think that it's to early on in the process in 
order to try and think of overlaps or additional usage for the 
proposals. I would like to argue that we solve this step by step and 
concentrate on the multihoming approach. The mobility aspect is a "nice 
to have", but let's look at that later on.

Best regards,

- - kurtis -

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2004 17:15:55 +0900

john,

jlnc> that don't interoperate well.  Could we restrict ourselves to multihoming,
jlnc> but perhaps the authors of the proposals add a section on Mobility Considerations,
jlnc> so we don't run into incompatiple solutions?

 The reasons that -- for this topic -- I think it is quite important
 to look at mobility and multihoming together are:

 1.  My own perusal is convincing me that they have more in common
 than they have different

 2.  Focusing only on one leads to assumptions that can be overly
 restrictive.  For example, one might think of multhoming addresses as
 being too stable.  Or one might think of mobility as only a trade
 from one address to another.

In his typically frustrating style, of raising really good, basic
points, Geoff pointed out that one can be mobile AND multihomed.

If we focus on one and not the other, we are not likely to deal with
this breadth and overlap adequately.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Mar 2004 22:02:34 +0100

On 3-mrt-04, at 3:35, <[email-masked]> wrote:

> layer, maintaining a session during a multihoming change and a 
> mobility change can be quite similar.  I second Dave's comment that 
> trying to solve two things at once can be never-ending. He also 
> mentioned that solving two
> that don't interoperate well.

Multiaddress mulithoming and mobility solutions must incorporate the 
following mechanisms:

1. multiplexing in the presence of more than one address pair
2. adding/removing addresses
3. for multihoming: failover
4. for mobility: rendezvous

It would be stupid to have two sets of mechanisms for 1. and 2., as the 
complexity of having to implement them both such that they can work 
reliably in the presence of the other is sure to be much worse than 
simply sharing them between mobility and multihoming. Unfortunately the 
ways in which current MIPv6 does these are sub-par, so we need to have 
something better. The logical conclusion is that the MIP people will 
have to throw their stuff out and use the new mechanisms, but I don't 
think we're ready to have that fight quite yet.

---

From: "Kanchei Loa" <[email-masked]>
Date: Wed, 3 Mar 2004 18:30:53 -0700

If a multihoming host is assigned an unstructured identity tokens
(opportunistic tokens), then it needs rendezvous. If a mobile host keeps
more than one locator for redundancy, then it needs failover. So, what is
the difference between multihoming and mobility except the time scale of the
updating rate ?

--------
Kanchei Loa
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Iljitsch van Beijnum
Sent: Wednesday, March 03, 2004 2:03 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: on the point of mobility & multihoming - comparsion between
mutihome and moblity

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 4 Mar 2004 10:50:10 +0900

Hi Iljitsch,

> 2. adding/removing addresses

Well, there is a difference in the requirements in this point in mobility
and multihoming.
Both needs a handover mechanism, to stop using a locator and start using an
alternative one, but strictly speaking, the locator set involved in a
multihoming solution can be fixed, becuase it is known a priori, for
instance consider noid. In mobility, this is not so, because you don't know
which will be your future locators.

Regards, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Mar 2004 13:18:10 +0900

Folks,,

KL> If a multihoming host is assigned an unstructured identity tokens
KL> (opportunistic tokens), then it needs rendezvous. If a mobile host keeps
KL> more than one locator for redundancy, then it needs failover. So, what is
KL> the difference between multihoming and mobility except the time scale of the
KL> updating rate ?

exactly.

Last week, Geoff Huston suggested an interesting scenario:

You take your laptop to the park.  Nearby is a very strong, high-speed
link at a coffee shop.  Some distance away is a much weaker/slower
link.

Traffic driving by disconnects constantly changes your preferred
access point.

This is mobile multihoming.  Although a park venue might not be the
norm, it strikes me as a pretty typical scenario for quite a few
likely situations.

d/

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2004 14:28:02 +0900

[email-masked] wrote:

> can be quite similar.

Not quite.

They have certain similarity that if we are going to solve mobility
issue in a way different from MIPv6, which is hopeless, minor details
of M6 design will be affected.

But, that's all.

Connection is a transport or application dependent concept, timing
of which is transport or applicaiton dependent.

OTOH, timing of mobility is governed by movemenet speed of mobile
hosts and service area of access routers.

> I second Dave's comment that trying to solve two
> things at once can be never-ending.

When I tried it last time, it took about half a year to design,
implement and install in the field. But as I think the
design was too much mobility centric, I have modified it,
part of which is the current 8plus8 proposal.

> Could we restrict ourselves to multihoming,

As long as proposals keep the IP layer connectionless, which is
of course, even MIPv6 will work automatically (though with all
the defects) that there is not much to worry about.

Lear already wrote in his draft

: 2.1.2.1 Does your solution address mobility?
:
:    If so, how are rendezvous handled?  Can your solution handle both
:    locators changing at the same time?  If so, please explain. Should
:    it?  If not, how will your solution interact with MOBILEIP-V6 [3]
:    (MIPv6)

Is it enough?
						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2004 14:33:49 +0900

Dave Crocker;

> This is mobile multihoming.

That is not a type of multihoming M6 should address. Instead,
it is purely a mobility issue and is useful for smooth handover.

With mobility, M6 should address multihomed base stations,
multihomed home agents, and multiple home agents at different
subnets (MIPv6 does allow for multiple home agents but only
in a subnet, which is mostly useless), all of which was, in
my experience, handled automatically.

						Masataka Ohta

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Mar 2004 09:26:16 +0200

I would find it unfortunate that if I was using some
IETF mobility protocol on a site and it stopped working
because the admins turned multihoming on.

So I see at least some requirements here.

--Jari

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 4 Mar 2004 16:47:10 +0900

I misunderstood the original post, but let me ask the question that I
> > You take your laptop to the park.  Nearby is a very strong,
high-speed

"You take your laptop to the park, and sit quietly on a bench, without
moving one iota. Nearby ..."

> > This is mobile multihoming.

With my change above, would THIS be a type of multihoming that multi6
would worry about?

Spencer

---

From: "Kanchei Loa" <[email-masked]>
Date: Thu, 4 Mar 2004 10:32:12 -0700

> which will be your future locators.

That might not be the case in non-mobile dynamic ad hoc connection for exit
routers as specified in Dave Croker's scenario, whose locator set is not
fixed and known priori. The dynamic comes from the nature of the network
topology (wireless), not from mobility. If the line between exit router and
ISP is changed to dotted lines (wireless) instead of one solid line (wired)
in Geoff's "An Architectural View of Multi6 proposals" presentation, then
the difference between mobility and multihoming is almost null.

---------
Kanchei Loa
[email-masked]