[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: on the point of mobility & multihoming
> >>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.
> > My opinion, for what it's worth, is that we're not out to solve the
> > mobility issue in Multi6. I don't think we want to advertise that
> > we will work on mobility, as mobility has out of scope. If we are
> > clever, the solution for multihoming will be useful for mobility.
> > However, I would not like multi6 to get a storm of drafts about
> > mobility when we are chartered to solve multihoming.
> I fully agree with you.
> Proposals from those who half understand the relationships
> will be really annoying.
> Thus, in my proposal, details of possible mobility solution is
> dropped, though minimal explanation on why a bit is reserved is
> Masataka Ohta
In my opinion, you just hit an important issue of multi6 architecture, which
this WG is supposed to work on first. If we take Dave Croker's scenario
(suggested by Geoff Huston) and generalize it, the problem space is the same
as depicted in Geoff's slide (page 3) of "An Architectural View of Multi6
proposals" except that the solid line (wired fixed connection) between the
exit route and ISP is replace by dotted lines (wireless dynamic
In this architecture, mobility is just a special case of "dynamic ad hoc
multihoming", which has timing restriction on updates and discovery. (You
don't have to call it mobility if that is more IETF political correct). In
Dave's scenario, from IP network's point of view, there is no difference
between a laptop sitting on a bench switching among ISPs because of
interference and a laptop sitting in a car that is moving back and forth
Should multi6 architecture encompass wireless connections between the exit
router and IPS? Or, Dave Croker's scenario is too far away in the future to
be included in multi6 architecture, which has been focusing on traditional
IP multihoming with fixed connections only? It is up to the WG to decide.
But the architecture document should spell out the rational choice. The
"uncomfortable" wireless issues won't goes away if we just choose to ignore
them or call it something else.