Subject: RE: on the point of mobility & multihoming

From: <[email-masked]>
Date: Thu, 4 Mar 2004 09:33:54 +0200

Jari,

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

So a requirement that a multi6 solution must not break
mobility (MIPv6?) would be sufficient?

John

---

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

> mobility (MIPv6?) would be sufficient?

That could be a starting point.

I am, however, willing to make it softer if necessary. Say,
if HIP folks believe they can solve both problems, that should
also be allowed, assuming HIP is otherwise accepted as the MULTI6
solution.

Also, I kind of agree with the comments on the list that
mobility and multihoming are part of the same thing. Like
someone told me a couple of days ago, becoming multi-homed
is half a handoff, because you move to another place but
don't move away from the previous one ;-) So I think the
ability to do mobility too is a desirable feature, though
perhaps not a mandatory requirement.

--Jari

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Mar 2004 21:16:25 +0900

john,

jlnc> So a requirement that a multi6 solution must not break
jlnc> mobility (MIPv6?) would be sufficient?

as for my own perspective, no, this would not be enough.

the infrastructure approach that is the basis for mipv6 has some
serious deployment and use challenges.

more directly, it looks quite reasonable to use a single, rather
small, set of mechanisms and solve substantial portions of both
problem spaces.

it is by no means sure that this will actually work.  the problem is
that the possibility that it _will_) work is not very much part of the
discussion, yet it should be.  the potential benefits of a common
mechanism are too large to ignore.

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

---

From: Eliot Lear <[email-masked]>
Date: Sat, 06 Mar 2004 11:40:06 -0800

I like the idea of having a "mobility considerations" section in 
peoples' drafts.  While I agree with John that if we focus on trying to 
kill two birds with one stone, sometimes the other bird just happens to 
get killed by being in the right place at the right time.  To stretch 
this analogy past the bounds of taste for a moment, if we sufficiently 
wound the second bird and it only requires a small amount of thinking to 
knock him off entirely, we're better off.

That having been said, Geoff's (and Dave's) clear message is that we 
could create a nightmare of overhead and complexity if we are not 
careful.  Consider a case where we are using some sort of shim layer 
solution that sits atop MIPv6.  The cases we have to deal with look like 
this:

--  what happens when a provider goes down?
Will the correspondent node attempt to send packets to the home agent?

-- what if the home agent is behind the same provider?  will the home 
agent be using a multihoming mechanism, and how will it impact the 
correspondent node?

-- suppose the mobile node reseats itself back to its home network in 
the midst of all of this?

Messy messy.  In the meantime, is what we would really have from an 
architectural standpoint one form of transport isolation running atop 
another (I hesitate to use the word "tunnels" because it's not quite 
correct, but we're in the same ball park).

BTW...

Excellent presentation, Geoff!

My apologies to bird lovers everywhere...

Eliot