[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt
> > => Why not? Let's take a simple example:
> > A dual stack node that wants to be reachable on IPv4
> > and IPv6 addresses. It gets one v4 and one v6 home
> > address. If it uses both MIP versions, every time
> > it moves it will send two separate messages to its
> > HA. Even worse, if we try to get a decent handover performance
> > then another two messages will need to be sent to
> > routers in the local network.
>
> You gave a description of a case where there seems to be unnecessary
> signalling that one could try to optimize away (using some means). My
^^^^^^^^^^^^^^^^^^
> feeling is that there are workarounds (operational ones, i.e. no
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> extensions for mobility management protocols) for this non-optimized
> signalling problem so the actual problem does not seem particularly
> attractive.
=> if you can solve this problem operationally please elaborate.
It will be enlightning for me to see how. I.e. please elaborate on
the underlined points above. Otherwise, I woulodn't be able to
follow your conclusion.
>
> Here, however, my point was not that: but rather, whether
> the two mobility
> management protocols are similar enough so that their
> signalling would be
> interchangeable or reasonably well doable with the other
> protocol (without
> significant drawbacks).
=> And my answer is that they certainly have commonalities
but not everything done in v6 can be done in V4. So we cannot
get every feature if MIPv4 is used.
My feeling is that this is not
> worth the effort.
=> I don't understand how you reach this feeling.
But then again, feelings don't have to be logical :)
> > => We're not trying to get the full advantage of each
> > one, this is a transition mechanism. Just like any
> > tunnelling mechanism will make you lose some of IPv6's
> > feature. This mechanism is not a goal, it's a mean to short
> > term deployment for mobile nodes.
>
> Transition to *WHAT*? IPv6-only mobility management and
> IPv6 being run on
> every subnet where a mobile node might roam to? I suspect both; the
> latter could take a very long while..
=> Of course it will take time.
>
> Wouldn't then it be just so much simpler to require the
> IPv6-capable node
> to always use IPv6?
=> Huh? How does this help with the problem we're trying to
solve? It's not about "using v6", it's about using it
while you're moving.
> > > Already happens if you enable e.g. 6to4 to gain IPv6
> > > connectivity. If you
> > > had IPv6 connectivity in the past, but move somewhere where
> > > there is none,
> > > I think surviving the connections is not your biggest worry.
> >
> > => What is your biggest worry then?
>
> When IPv6-capable node uses IPv6 but moves to a subnet where
> IPv6 is not
> supported, and IPv6 services are required for some purpose,
> it's first and
> primary problem is re-establishing IPv6 support in that
> subnet, in any
> means necessary.
=> I'm really confused. This is the problem we are trying to
solve! I thought you said it's not the biggest worry. How can
you get IPv6 services when you don't have an IPv6 address and you're
mobile...?
>
> > I can't imagine a wireless
> > operator deploying a service that works sometimes. This is
> > a key problem to address.
>
> I'm not sure of the context you're referring to, so I can't
> comment on
> whether I would see this as a problem or not. What kind of
> devices are we
> talking about here?
=> Doesn't matter, any host as defined in 2460.
And what kind of networks?
=> Wireless IP networks.
Would the network
> terminal devices be smart enough to be used (and expected to
> work) in the
> Internet by themselves (e.g. laptop with a WLAN)
=> This is not the only example of a device, but yes this is one example.
> In transition, it's good to try to figure out questions like:
> - transition to _where_,
> - transition _how_, and
=> Agreed.
> - transition for _how long_?
=> Not sure why this question is relevant. I think trying to
answer this is an exercise in futility. At least we never
had an answer for it so far. Why is this needed?
> (for example).
>
> With IPv6 (ngtrans/v6ops) we haven't always been too successful in
> figuring that out though
(and I'm not saying we're
> necessarily enlightened
> at the moment either :-).. :-/
=> I thought the scenarios docs were going to enlighten everyone ;)
Hesham