Subject: RE: On the NECESSITY of MIP for LMM (was Re: [Mipshop] WG Last Ca ll comments ...)

From: Soliman Hesham <[email-masked]>
Date: Thu, 30 Oct 2003 07:03:20 -0500

> > => I'm not sure that this implies that it has nothing to
 > > do with MIP. 
 > 
 > Please read more carefully.  It does say that the solution does
 > not *necessarily* have anything to do with Mobile IP.  In other
 > words, that requirement makes it *possible* to create solutions
 > that have nothing to do with MIP.  (not necessarily A implies
 > possibly not A)
 > 
 > I did not say that it implies that it has nothing to do with
 > MIP; it only implies that there *exists* solutions that fulfil
 > the requirements but have nothing to do with MIP.
 > 
 > > It simply says that you should not modify
 > > the HA and CN. At least, from memory, that was the intention.
 > 
 > Right.  And that requirement implies that there *exists* solutions
 > that are compatible with the requirements but have nothing to do
 > with MIP.   (Am I repeating myself, aren't I? :-)

=> Yes you are ;). Let me put your mind at even more rest,
there are tons of solutions outside the MIP space to address
what we call LMM. There are concepts that are orthogonal
to any protocol and can be seen in other solutions. 
For example the concept of hierarchy (e.g. HMIPv6) is
definitely not new and you can easily repackage into
a different protocol as you've already done. Same goes
for FMIPv6. 
There are clear benefits in _reusing_ existing SW though.
And many years ago we went through this discussion and
the WG decided that it was more beneficial to solve this
exercise with MIP. It sounds like you disagree, right?
Frankly, given the current situation, I think this is a very
wise thing to do (reuse MIP). The benefits of repackaging
the same concepts into a different protocol are very far 
from being clear.

 > 
 > In other words, since HA and CN must not be modified, and since
 > if a protocol is modified then both communicating parties must be
 > modified, the requirement says that MIP must not be modified.
 > Consequently, if MIP must not be modified, there exist solutions
 > that have nothing to do with MIP.  I could make this argument
 > formal, but it would not be easy to read.

=> Of course! like I said above, we know that already.
But this WG is going to work on MIP solutions.

 > > => Of course. 
 > 
 > So you agree with me above.

=> I hope that's clear now. The point is we chose
a certain path and I haven't seen anything that
obsoletes that choice.

 >    WE SHOULD NOT RESTRICT OURSELVES to the Mobile IP blinders
 >    when we are dealing with LMM.
 > 
 > Now even the requirements draft says that MIP must not be modified
 > by the LMM solutions, therefore making strictly less reason to think
 > narrowly and look at MIP based solutions.

=> You never justified that argument IMO. 
The requirement says that we shouldn't modify the CN
or HA to make it easy to deploy the protocol. 
With current proposals it is trivial to extend the 
MN and HA functions to get an LMM solution. Again, 
from a SW reusability view point and simplicity of 
implementation, it's really good to be able to reuse
this stuff. UNLESS, you have a compelling argument for 
NOT doing this. 

It's all well and good to say "don't restrict solutions
to MIP" but we've already been through that and saw
that while that statement is true, it makes a lot of 
sense to reuse things. 

 > In other words:
 > 
 >    There is no whatsover *technical* ground to require that the
 >    IETF endorsed LMM solution MUST be MIP based.

=> IMHO SW reusability is a pretty strong technical argument
for anyone building products.

 > 
 > It MAY be MIP based, of course.  There are no technical reasons
 > that prevent that.  OTOH, if there are simpler solutions that
 > have nothing to do with MIP, why don't we use them?

=> Please list them! Anyway, I'm not sure how helpful
that will be, because we're already chartered to handle
2 solutions. 

 > 
 > (Note that I am not advocating HIP here.  HIP is most probably
 > too heavy for LMM.  As is IPsec and AAA, too.  What I have in
 > mind is much simpler, to hopefully appear as a paper soon.

=> Understood. I'm a bit of a skeptic until I see 
something that addresses the same problems. From my 
biased point of view (technical bias) I haven't seen 
anything simpler than HMIPv6 so far, but I'm willing
to be proven wrong. 

 > However, it would be waste of time to discuss it here unless
 > people get rid of their narrow-minded MIP-focused blinders.)

=> If it's in a paper then you're not bound by an IETF WG...

Hesham

 > --Pekka Nikander

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 30 Oct 2003 14:31:46 +0200

> exercise with MIP. It sounds like you disagree, right?

I would not like to make the same mistake some people are doing
in the IPv6 ML in repetitiously repeating themselves, but maybe
this ML can bare one more take on this.  :-)

Yes, I disagree with the chartering of this WG.  In my humble
(or not) opinion it is foolish to base LMM on MIP.

I don't disagree with the SW reuse argument, but I think that
people often use it even before they have implemented anything.
For example, the early drafts for HIP used the DNS encoding,
until it became clear that having a better encoding not only
reduced the total amount of code but also simplified the
solution.  (The reason for DNS encoding was claims about
software reuse -- claims that could not be realized.)

As I have umpteen times written, in my opinion MIPv6 is flawed.
MIPv4 had good reasons for its design, that is fine.  But
carrying over the exactly same design to IPv6 was a big technical
mistake.  Maybe I will write a paper about this sometime.

But leaving that aside, what I am seeing happening is a multitude
of (roughly) IP layer mobility mechanisms that could benefit from
LMM.  MIP and HIP are only two of those; others include the new
initiatives of including some mobility functions to IKEv2,
the work on multi6 group such as MAST, and the new approaches
on the research side like FARA, I^3, etc.

All of these would benefit from LMM.  Basing LMM unnecessarily
on MIP may, IMHO, may bring package that will not be needed.

What comes to the SW reuse benefits of reusing MIP for both
macro mobility and LMM, I will believe when I see complete
code, together with the required security solutions.  The fact
that we are still lacking proper security is, IMHO, a clear
indication that the current solutions may be far from optimal ones.

I am not really saying that the current proposals should not
be completed and published as Experimental.  Indeed, I think
that they definitely should.  (If for nothing else, just to
get them recorded and out of the way :-)  What I am worried
about are the requirements, as we apparently are producing those.

Unnecessarily tying requirements to something that is strictly
not needed is technically bad.  It may be politically right,
but given the very clear charter of this WG I don't see any
real dangers in making the requirements more broadly scoped.

--Pekka Nikander

---

From: "James Kempf" <[email-masked]>
Date: Thu, 30 Oct 2003 05:28:52 -0800

Hesham,

I don't want to take sides in this debate, but I do have one comment for
clarification on your note.

> the same concepts into a different protocol are very far

If you are speaking here about reusing MIP and HMIP, then I think what you
mean is reusing existing designs, not software. To my knowledge (which is
probably incomplete) nobody yet has a MIPv6 or HMIPv6 product, and nobody
yet has a deployed MIPv6 or HMIPv6 service. Reusing existing software would
be something like using DNS or VPNs. There is, of course, experimental
software in this area, but the argument for reusing experimental software is
less compelling from a business standpoint. There is also a good argument
for reusing existing designs, if they adequately satisfy the requirements of
a new application, as it enables the new application to more quickly be
designed, implemented, and deployed.

            jak