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

[Henrik Levkowetz <henrik@levkowetz.com>]

on 2004-11-23 10:18 am Pekka Savola said the following:
> On Sat, 20 Nov 2004, Henrik Levkowetz wrote:
>>> Yes, you can reuse or even leverage DHCP for the address assignment
>>> to the HA.  But how does HA signal the address to the MN?  What about
>>> the lifetime of the address -- are you assuming that the address is given
>>> to the MN for forever?  Then you need to refresh the binding as well...
>>>
>>> You either end up running DHCPv4 on top of the HA-MN tunnel link
>>> (that's OK), reinventing a subset of DHCPv4, or not dealing with the
>>> address lifetimes and the other tricky parts appropriately.
>>
>> You are trying to solve a problem which has already been solved.
>>
>> What's more, you're making it sound more complex than the solution
>> which has already been defined and fully implemented with several
>> different allocation strategies, for MIP4.
> 
> I've no doubt that it has already been solved.  I just have doubts 
> whether different people have different assumptions about whether this 
> solution is considered sufficient in the cases which it might be 
> applied to.

Right, well, let's look closer at that when we get there. 

>> Now,
>>
>>   1. This discussion doesn't belong here at all - we're way, way
>>      into solution space, on an issue which isn't too complex,
>>      and is already defined for parallel cases.
> 
> I agree that the discussion is too solution-centric, but the core of 
> it seems to belong to the solution framework document, IMHO, at least 
> in the current form because it already analyzes the solutions.  How 
> address assignment is done is pretty important piece of the solution. 
> To take a concrete example of a similar problem, when I was 
> introducing the v6tc draft justification/charter to Thomas Narten, and 
> it didn't mention how addresses were assigned, he didn't understand 
> the model we had in mind and wanted to see it covered.

In this case, dynamic address assignment of MIP Home Addresses aren't
part of the base MIP protocol in either case, so I don't think the
cases are comparable.

>>   2. To the nitty gritty details.
>>      This is how it works for MIP4.  Let's first be clear on that,
>>      then we can discuss the IPv6-in-MIP4 case, and then the
>>      MIP6 cases if we have to.
>>
>>     a. For MIP4 there is a mechanism for the MN to tell the HA
>> 	during initial registration that it needs an address.
>>
>>     b. This on purpose does not go into how the HA acquires an
>> 	address to give to the MN.  This is basically GOOD.
> [...]
>>     b2. Another possibility is that the HA contains a dhclient
>> 	 proxying for the MN, which gets an address allocated for
>> 	 the MN from a DHCP server.
> 
>>     c. MIP4 defines how to tell the MN what the address is. The
>> 	address is valid as long as the MN is registered with the
>> 	HA.
> 
> You don't address the case what happens if the DHCP lease runs out and 
> cannot be extended (in b2) before the HA registration with the address 
> runs out.
> 
> You don't address the case that the HA registration is semi-permanent, 
> e.g., is up for months at a time, and there would be a need to 
> renumber the MNs.

No, this is true, and there are a lot of other details which could
also be covered, but it's still not a particularly complex issue...

> Etc.
> 
> I'm not saying these *need* to be addressed, but these are issues 
> which will come up, and thus deserve to be brought up.  If folks want 
> to see a solution which is capable of dealing with more than the basic 
> case of address assignment, the solution could get to be rather 
> complex, in essence, re-inventing DHCP.
> 
>> Now if we talk IPv6-in-MIP4, we could do the same thing.  The
>> extensions needed to tell the HA that an IPv6 address is needed
>> and to tell the MN what address it has are trivial.
> 
> Yep, if the same assumptions still hold.  Plugging the same code to 
> MIPv6, though, where it does not exist a bit of more work, though 
> still nothing really fancy, again if the same assumptions still hold.
> 
>> Now, this in no way impacts hand-over characteristics, it only
>> impacts the initial registration.  *It doesn't belong here.*
>> Can we please let it go?
> 
> If you agree to write it out explicitly in your document as an issue 
> which needs to be considered ;-).

We can mention the issue, but will also point out that it doesn't
affect the handover capabilities or tunnelling overhead ;-)

	Henrik