Re: how mobile do we want to be

[Thierry Ernst <ernst@sfc.wide.ad.jp>]

Hi,


On Tue, 22 Mar 2005 21:05:07 +0100
Iljitsch van Beijnum <iljitsch@muada.com> wrote:

> > and the original discussions, a year or so
> > ago, had clear examples of interest, with mobile phones switcing 
> > between
> > cell phone linkage and 802.11 linkage being one of the more 
> > interesting.
> 
> You have to drill a bit deeper as mobile phones aren't an application 
> so it's impossible to determine whether they need layer 4 stability on
>  top of layer 3 mobility.

I'm afraid I don't understand the comment, but if it's what I think, I
would answer that to me it's pretty clear they need layer 4 stability.

> Let's for a moment assume that all we need for mobility is a mechanism
>  to add new addresses to existing sessions. Can you tell me what kind
>  of 
> architecture would allow this to happen in a way that is secure enough
>  that it isn't the weakest link in a mobile session over IPsec, but
>  also 
> allows for autoconfiguration and doesn't increase computational 
> requirements significantly over the current situation?
> 
> >>  We now have the situation that a group of people wants to do X. 
> >> Another
> >>  group of people wants to do X+Y. Does this mean the first group is
> > > now
> >>  obiligated to do (X+Y), even though (X+Y) is much harder to solve 
> >> than
> >>  (X)+(Y)?
> 
> > given the trauma caused by a shim-like change to the architecture
> > and  given
> > the very poor history of getting these sorts of changes adopted by
> > the Internet user community, the answer ought to be yes.
> 
> I can go along with that for a bit, because I wish I could have been 
> there when MIPv6 started and have told them that they were going down 
> the wrong path and should have included multihoming support.

This is what we want to do know, and there are have been quite a lot of
efforts in this direction overt the past 3 years (MCOA, MMI, etc ...).
Chairs and other people didn't want to add such a WG item but a large
number of people has constantly continued work on this and have actually
implemented (some of the) necessary mechanisms.

> The trouble is that the type of input you're providing right now comes
>  at the wrong time. Despite the fact that it's a BOF the shim effort
>  is 
> well underway, and starting from scratch would be a HUGE waste of
> time,  without any reason to believe that a new effort would result in
>  anything better, whatever "better" happens to be. The shim approach
>  has 
> enormous potential for synergy with lots of other stuff, so I'm sure 
> that we're going to revist lots of issues somewhere down the line. 
> There is also a lot of good oldfashioned engineering to do (protocol 
> messages, failure detection, path selection, ingress filtering, the 
> list goes on). Experience so far has shown that these areas can impose
>  unforseen restrictions, so it's very important to get them out of the
>  
> way before widening the scope.

I think that the discussion is about putting the right thing in the
charter, so I don't think it's coming at the wrong moment - rather at
the right time, before the WG is approved.

I very much agree with the last post from Jar Arkko.

Thierry