[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how mobile do we want to be
On Tue, 22 Mar 2005 21:05:07 +0100
Iljitsch van Beijnum <firstname.lastname@example.org> 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
> 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
> 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
> 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
> 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.