[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: on the point of mobility & multihoming



Msataka-san,

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

> But, that's all.
> 
> Connection is a transport or application dependent concept, timing
> of which is transport or applicaiton dependent.

Agreed.
 
> OTOH, timing of mobility is governed by movemenet speed of mobile
> hosts and service area of access routers.

Agreed.

> > I second Dave's comment that trying to solve two
> > things at once can be never-ending.
> 
> When I tried it last time, it took about half a year to design,
> implement and install in the field. But as I think the
> design was too much mobility centric, I have modified it,
> part of which is the current 8plus8 proposal.

I don't doubt that you have solved this already, but do you think
having a rash of mobility drafts claming to solve multihoming would
be useful?  

> > Could we restrict ourselves to multihoming,
> > but perhaps the authors of the proposals add a section on 
> Mobility Considerations,
> > so we don't run into incompatiple solutions?
> 
> As long as proposals keep the IP layer connectionless, which is
> of course, even MIPv6 will work automatically (though with all
> the defects) that there is not much to worry about.
> 
> Lear already wrote in his draft
> 
> : 2.1.2.1 Does your solution address mobility?
> :
> :    If so, how are rendezvous handled?  Can your solution handle both
> :    locators changing at the same time?  If so, please explain. Should
> :    it?  If not, how will your solution interact with MOBILEIP-V6 [3]
> :    (MIPv6)
> 
> Is it enough?

It might be, but Dave's comments got me thinking about several other things,
so let me think a bit more to decide if my thoughts are baked or not.

John