Re: comments on draft-larsson-v6ops-mip-scenarios-00.txt

[Henrik Levkowetz <henrik@levkowetz.com>]

on 2004-11-19 7:39 pm Pekka Savola said the following:
> On Fri, 19 Nov 2004, Henrik Levkowetz wrote:
...
>> 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).

True. The thing is, those 15 are a selection out of hundreds? of 
possible one, and I think no individual author has a good grasp
of even a majority of them.

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

We could give samples, but in truth, I'm not sure it would ultimately
be more helpful than it might be misleading.

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

They would be there to help people get the big picture when taken
together with individual problem statements.

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

That's your privilege :-)

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

Agreed.

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

As said separately also, because this is an essential point:

Bulls eye.  In the discussions around George's and Hesham's
drafts, there has been no such understanding in general by many
of those who have commented, neither of what is addressed or what
the drafts don't address.  This is what I think we need to have in
place before it even makes sense to sensibly discuss individual
problem statements, and see where they overlap and what might be
missing.

[snip]
>>> 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 :).

I understand that.  But we're not omniscient, and I think that would
also make the document *far* to long...

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

Well, I think that is needed - because the problem statements need to
come from people which really *have* the problems - otherwise they
will be just theoretical exercises, without contact with the real
world.

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

In both the case of MIP4 and MIP6 it is not part of the base spec,
and I don't think it should be made part of the base here. Sorry.

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


No, I think that brought a bad tone to this.  Please don't do that.


Anyway, I believe you're mistaken in trying to place this into
the base scenarios.

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

But it still doesn't belong in the base scenario here any more than it
does for MIP4 or MIP6.

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

A non-natted global v4 home address is the base scenario for MIP4...

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

Eh?  I don't see this.  I see the base scenario as a static IP4
home address and a static IP6 home address, and the mechanisms to
tell the Home Agent what is the new tunnel endpoint for those
addresses.

If you need to assign a dynamic IPv6 home address within MIP4, that's
an extension that parallels the dynamic IPv4 home address assignment
extension, and conversely for MIP6.  These are pretty
orthogonal to everything else, I think, and doesn't impact complexity
much, and in particular not the handover scenarios, as the dynamic
address assignment is done during initial registration, not during
handover re-registration.

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

Yes, with you so far, but if there are 5 possible reasonable tunnel
solutions, in addition to adapting MIP4 to carry IPv6, should we
discuss all of those?  And accordingly for IPv4 in MIP6 ?

	Henrik