Dear all,
I attended half the BOF, but couldn't stay until the end as I had to
take my flight, so, sorry if I raise issues which was discussed in the
BOF.
First, I agree with what Avri said during the BOF - that there is an
opportunity window and that we may be losing a good opportunity to solve
once for all the mobility problem if we don't investigate it further.
However, I'm not sure it should be the purpose of the Shim6 WG as my
understanding is that it would produce Experimental RFCs,
so I would
find myself satisfied in this situation, provied mobility is
investigated at the IETF.
Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 14-mrt-05, at 16:41, avri@psg.com wrote:
I think the question is more a recognition that the network is now a
network in motion: systems move and networks move. And while it
is
true that some part so the network, doesn't move, or moves very
slowly, an overwhelming amount of the edge is in motion. And I think
it is important to realize that a large number of sessions should
remain viable despite this continuous motion.
Could you provide some examples of applications where a
disconnect/reconnect is sufficiently problematic that MIPv6 or
something similar is warranted?
So far the only stuff I can think of is remote login and streaming
audio/video.
First, I've a question for Avri. What do you mean by "network in
motion", is this the mobile networks that we are supporting in the NEMO
WG, or something else ? (I would say yes, but since you didn't mention
NEMO, I cannot be sure).
If NEMO scenarios are in mind, I would second Avri in saying that a
significant part of the Internet nodes would be "mobile" (either that
change their point of attachment [i.e. mobile host or mobile routers] or
they are located in a network which "gateway" is mobile).
Basically, MIP6 bring a solution to the former, and NEMO BS to the
latter (thought NEMO BS is not providing routing optimization). That's
not the point. The point is that if Shinm6 is looking into a solution
which would require a major architectural change, then, yes, it would
make sense that this major architectural change takes mobility
explicitly into consideration. Here, I do agree with Avri.
A conclusion might be that Shim6 is a little bit immature to be set up
at the IETF, whereas a IRFT WG on that (taking mobility into
consideration) might make more sense.
In other words I think the question is not, "how mobile do we want
to be", but how mobile are we and how mobile will we be by the time
a shim6 solution is implemented and widely deployed.
My prediction: not very. 99% of all traffic today is either sessions
that go away within seconds, or can be easily reestablished after a
forced disconnect. I don't see how the other 1% is going to take over
the world any time soon.
Hold on, if we only have 1% of mobile nodes today, it may be because the
Internet is not tuned for mobility, and that IPv6 is not yet deployed.
IPv6 is a change to deploy neew usages, and most of these new usages
will be mobile (see my comment about who is mobile ealier in my mail).
Every human will have a mobile phone, and possibly, many millions of
them will carry a PAN (ako NEMO). All cars will have an embedded network
(and that could be NEMO too). That's a few hundred millions cars.
This will happen by the time the Shim6 solution is deployed (if it can
be deployed, which I'm not sure it would if mobility is not considered).
It is for these reasons that I am arguing so insistently that we
must include systems and networks in motion (if we want to reserve
the term mobility for MIP4/6 to avoid confusion) as part of the
problem space shim6 must take into account.
I don't think this is a good idea. Let's focus on the basic shim
functionality, and when we have something useful there, we can sync up
with other efforts and see what we need to do to avoid duplication of
effort and to gain synergy.
Why this had to be done at the IETF ? (I'm just asking, not opposing,
and, in summary, my concern is that mobility should be investigated one
place or another if a Shim6 solution is ever expected to be deployed).
Thierry.