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

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

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.

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.

  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.

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

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings