[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-larsson-v6ops-mip-scenarios-00.txt
On Fri, 19 Nov 2004, Henrik Levkowetz wrote:
So, you're saying this is kind of a "framework" for all the possible
scenarios and solutions.
I'm not sure how sensible that is, because we don't have those
specific problem statements/scenario documents. Further, such a
framework document might be a wrong place to have lengthy discussion
of solutions.
Well, the thing is, it seems every separate person who makes comments
in this area are looking at only part of the field we have tried to
describe here, and have different requirements, different access
technologies, different trade offs.
Right..
I believe it would be very counterproductive to even approach
problem statements in this draft. Problem statements need to be
focused, and need to lay out the conditions and trade-offs which
exist in each individual case. But if we don't have a map of the
whole field, it is much more difficult to come together and gain
consensus on a few fairly optimal mechanisms, rather than having
15 different approaches which only works for limited cases.
Yeah, but my argument here is that if we don't understand those 15
different scenarios and how they map to the framework well enough,
it'll be difficult to gain understanding and seek a common solution
(for parts of them at least).
Maybe to those who have written the combinations it's more obvious and
clear what those 12 different scenarios and the consequent hand-off
scenarios mean, but even for a framework document, it would seem that
it would be useful to offer a bit more than that .. like trying to
describe each scerario very briefly, in a manner that a reader could
easily grasp the differences between the scenarios.
I fear that if the different scenarios are just lines in a matrix,
sufficiently many people can never understand the big picture -- i.e.,
how those map together.
I certainly sympathize with you that this document should not be place
to have length discussions of each scenario and the problem statement
behind each scenario -- but what I did prefer to see was around a
paragraph or two of text per each scenario, trying to describe it
somehow, and state if that's a deployed/planned scenario (and where?),
etc. -- just something minor for the readers to get a feel which
scenarios are most urgent deployment/planning wise.
Well, to make that complete would take input from ?? hundreds, and
still not be complete - we don't know now what kind of combinations
and deployments we'll see in only a year. What we _do_ know is how
the combinatorics of the different base technologies works, and this
is a good platform on which to build individual problem descriptions.
I'm thinking that we might complement this document with one other
document, with a problem description which would be of particular
interest to some of us, in order to take another step forward.
Maybe that would be one way to demonstrate how the model could work,
yes. For now, I'll have to remain a skeptic :).
Generic comments:
- you raise a number of (potentials) scenarios by enumerating the
possibilities. I think it would be useful to try to describe, e.g., using
a
paragraph or two each, the practical use case for each scenario if one
exists, deployments which are planned or exist, etc. -- just as a means for
us to try to identify which are the *MOST* relevant scenarios which must be
addressed.
See above. More deployment-specific problem statements can be made later, but
that's not really within the scope of this draft.
I think that diminishes the value of the draft, especially as it tries
to analyze the solutions -- which doesn't seem to make sense unless we
have some agreement about which scenarios are actually the useful
ones?
As indicated above, I think that there are too many possible problem
statements to make it reasonable to even attempt them in this draft.
If people can't agree on the problem, it's going to be difficult to
get them to agree on the solution, or whether there is a need for
one.... :)
This needs to be done somewhere, I think. If two most prominent cases
(for example) are dealt with in separate documents, we couldn't use
the framework document to figure out what to do with the rest of the
scenarios, because the framework document didn't include sufficient
detail to gain common understanding on the scenarios -- so it would be
questionable what use the framework document would serve (except as a
point to be referred to say, "we are addressing scenario X").
Right.. but I think the fundamental assumption is not that the
signalling roundtrips are too costly (too many bits sent), but rather
because signalling with many roundtrips just takes way too much time
(due to the access technology), thus the need to minimize the number
of roundtrips.
Basically true, but the roundtrip may vary between few ms to few seconds,
depending on access technology, and depending on the application that
may matter greatly or not too much at all.
Sure. But if the roundtrip was a few ms, I think folks would agree
that the number of roundtrips was not a real problem, right?
OK. An in a dual-stack network...?
Maybe the problem statement for deployment case III, then, is that
it's OK to have to implement both MIP protocols on the hosts and HAs,
but it's not OK to have to perform dual signalling either on v4-only,
dual-stack or v6-only network?
Again, this depends on your deployment scenario :-) Describe one, and
we have the start of a problem statement building on the playing field
we have attempted to describe :-)
I'd prefer this document to try to figure out those scenarios :).
In order to understand them, they need to be written down to be
discussed _somewhere_. It doesn't seem to make sense to write about
12 different documents in addition to this one...?
It may not be in scope of the draft as such, but it is certainly in
scope of the solutions you're discussing in the draft. MIPv4 or MIPv6
extensions (at least under certain scenarios) seem to require an
address assignment mechanism, which has not been addressed in the
solutions, and hence is a short-coming in the solutions.
No, this I don't see. There is one address assignment which we have
(consistently, I believe) not covered, which is getting a local address,
and this should be the same cost for all solutions. In the Mip 4/6
cases the Home address is already assigned and fixed, no need to
do that on the fly - well, it's even (mostly) a silly idea in the
context of mobile ip [although there are provisions for dynamic address
assignment within at least MIP4 - don't know about MIP6 and I'm not
sure it's even a good idea to go there :-)]
As far as I know, while MIPv4 includes dynamic address assignment,
MIPv6 does not. But to make some of those scenarios work using
MIP-based solution, MIPv4 will have to have [dynamic] address
assignment for at least v6 (depending on how its done with v4), and
MIPv6 will need to have it for v4 (and MIPv6 doesn't have any
assignment for v6). So, this is a non-trivial part of the MIP-based
problem space which should be explicitly mentioned.
(Also to Hesham.)
Hesham was stating that this stuff already exists, MIPv4 is doing it
already.
BUT REMEMBER, YOU'RE PLUGGING THAT FUNCTIONALITY TO MIPV6 NOW!
Clear enough? :) Sorry for yelling.
So, in addition to being to register an IPv4 care-of address using
MIPv6, you'll need to allocate an IPv4 home-address *using MIPv6*.
While this may have been done in MIPv4, this is a new functionality
for MIPv6. The most tricky part here is that you'll need to deal with
assigning addresses from another IP protocol, one you would rather not
go too deep in, and that in v6, there has been a strong desire to
avoid address assignment techniques like this. So, that seems like a
non-trivial extenstion to MIPv6. Doable? -- Sure, but non-trivial
nonetheless.
For example, if you have a dual-stack node in a v6-only network and
using MIPv6, and you want to run v4-only apps on that node, you'll
need somehow to assign the v4 address on the node. Using transition
mechanisms provides you an address; using MIPv6 would require that
MIPv6 extension would also include a DHCP-like mechanism for the hosts
to obtain a v4 address. The same applies to MIPv4 for v6 addresses.
In this case you want MIP6 to carry both your IP4 and IP6 traffic,
so you need a Home Address for both. But this would not (normally)
be dynamically assigned, that would loose you a lot of the inherent
benefits of MIP.
It might be possible to assume that the home address for the "primary
MIP version" is configured manually or w/ out-of-band mechanisms, but
I think for the rarer case you may need an automatic mechanism (esp.
you want to publish a non-natted global v4 home address address).
Yes, sure, the assignment of a MIP4 home address
has to be described in a solutions draft, but I don't see it belonging
here as it doesn't affect the handover dynamics.
It affects the complexity of the MIP-based solutions in a very
fundamental way because they'll have to deal with a lot more than just
registering one kind of address as a tunnel endpoint, hence it might
affect the decision which way is the best to go.
One could, for example, add a tunnel to the stable home address; this
would cause additional encapsulation. Not sure if that would be OK,
but at least it's an option.
For example, when in v4-only environment and using MIPv4, one could
build a v4-in-v6 tunnel (if FA is co-located) to the v4 home address,
also addressing the IPv6 address stability problems without any need
for signalling etc.
I think you mean a v6-in-v4 tunnel here, and that is one way of doing
it.
Sorry, yes, that was what I meant.
It would give more transport overhead, of course, and as MIP is
already basically a traffic tunnelling proposition, it makes not a lot
of sense to me personally ,:-) But yes, this could be done - now we
have to wonder if it is sensible enough that we should increase our
matrices with another dimension and include this in the draft :-)
I'm not sure if the matrix needs to be expanded; I took this to be
just another solution approach to the case:
2 IPv6 MIPv4 IPv4 IPv4 "IPv6 in MIPv4"
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings