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

From: "[email-masked]" <[email-masked]>
Date: Thu, 30 Oct 2003 21:55:56 -0500

>> FWIW, I've been told in private about at least one 
>> vendor's plans to include both technologies in their 
>> products but I don't want to speak on anyone's behalf.
 
Hesham,

  I know of at least one carrier is looking to deploy 
  both as well.

  Carl

Original Message:
-----------------
From: Soliman Hesham [email-masked]
Date: Thu, 30 Oct 2003 20:06:40 -0500
To: [email-masked], [email-masked], [email-masked]
Subject: RE: On the NECESSITY of MIP for LMM (was Re: [Mipshop] WG Last
Call comments ...)

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

=> I meant that once MIPv6 is implemented, it is easy
to reuse its functions to implement HMIPv6 in a couple
of hundred lines (literally). I hope that the reason for
our work here in IETF is to allow people to develop interoperable
products. So that's why code reuse is important. If we 
think MIPv6 will not be implemented in products it 
should be moved to historic status. But if it has not been
released in a product yet that doesn't mean we can't 
assume that it will be, and design accordingly. 
FWIW, I've been told in private about at least one 
vendor's plans to include both technologies in their 
products but I don't want to speak on anyone's behalf. 

Hesham

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

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

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

---

From: "Carl Williams" <[email-masked]>
Date: Fri, 31 Oct 2003 10:59:47 -0800

LMM requirement analysis was conducted in the MIP working
group starting about Spring 2001.  Such analysis was focused
on analysis of MIP signaling.  The discussion also was (at
least) partially motivated by examination of existing LMM
solutions that had been proposed at that time. Little (if
any) discussion on LMM requirement analysis took into account
a framework not based on MIP.  The resulting requirements
evolved from these discussions.  Ref [1] in the requirement
document captures and expands (greatly) from the discussion
that the MIP group had on LMM requirements (it is also
based on a MIP based framework).  
 
At around this time as well discussion on micro-mobility
was happening in the seamoby working group. Documents
were drafted there as well.
 
While we can remove MIP specific language from the current
LMM (MIP) requirement document, I wonder if that would
result in a complete set of requirements that have been
well thought out to take into account local mobility management
schemes that are not based on MIP.
 
I presented a couple of times in the IRTF generic LMM problem
statement.  There are also many academic papers (Columbia 
University) that dig into this as well.  I talked with
Thomas back in IETF (SLC) about the need for IRTF review
of some of these issues and what was not happening in MIP
working group.  
 
My recommendation is similar to Gabriel's in that I think that
that the IRTF should do some work (at least scoping out the
issues) and then proceed to make a recommendation to the
IETF.  Such a recommendation may mean forming a new 
working group or re-chartering an existing working group(s)
to take on work that is being recommended (if that is the outcome).
The reason for taking this process is that I still have questions
if the IETF has something to be engineer in mipshop
other than what was already been worked on for past 3 (maybe
4 years). At that time LMM really was more experimental but
IRTF had no group working on it.  Thus, it was done in
the IETF MIP group. Also, micro-mobility was moved from MIP to 
seamoby to IRTF.  I think some initial recommendation from IRTF can 
happen in short order because much was done in the community 
already.