Subject: RE: [seamoby] Comments on draft-ietf-seamoby-mm-problem-00.txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 21 Feb 2001 20:32:04 +0100

Hello, 

After reading the draft, I agree with James. The draft does not 
define an accurate problem statement to motivate the need 
for a new mm protocol. 
The draft also in some parts implicitly refers to IPv4 specific
problems which may not be relevant for IPv6. 

I agree that this is not a good problem statement that should
be sent to the IESG. There must be some clear disadvantages
shown in MIP before this can be accepted.

Regards,
Hesham

PS: A minor comment, the reference to the IPv6 handover 
draft is not correct.

> -----Original Message-----
> From:	James Kempf [SMTP:[email-masked]]
> Sent:	Thursday, 22 February 2001 4:12
> To:	[email-masked]
> Subject:	[seamoby] Comments on draft-ietf-seamoby-mm-problem-00.txt
> 
> At the risk of being accused of flaming, IMHO this draft is very disappointing.
> 
> Much of it reads like a marketing presentation for wireless rather
> than a technical analysis of an existing problem and a statement of
> how Seamoby should go about solving it. In particular, Section 2.1
> reads like a laundry list of Good Attributes For A Wireless IP Mobility
> Management Protocol, and Section 4.0 looks like it was lifted from
> the Powerpoint slides of a 3G marketing person. There seems to be
> an implicit assumption that not changing the IP address is somehow
> "good", and that there is really no need to justify why.
> 
> The heart of the draft seems to be Section 3.1, in which a comparison
> with mobile IP is attempted. But the comparision is merely a list
> of desirable features and a few words on whether and how mobile
> IP is attempting to solve them. The interesting thing is that on
> each issue, the draft seems to imply that work is underway in the mobile
> IP group, AAA group, or the Seamoby group (re. paging and context transfer) to
> address the shortcomings, yet despite this, the draft concludes
> that work is needed on a micromobility protocol!
> 
> What I would have liked to see is a technical analysis of the shortcomings
> of mobile IP's tunneled approach and how a routing update based approach
> would do better. From this analysis, I would expect to see recommendations
> about whether or not there needs to be work on a routing update based
> micromobility management protocol. Naturally, the recommendation should take
> into account the existing mobile IP deployment base (in particular
> 3GPP2's IOS 4.0) but the recommendation really should be based on specific
> technical drawbacks of mobile IP and how a routing update based approach
> would solve them. Alternatively, the recommendation could be for a
> "next generation" micromobility protocol.
> 
> I'm sure the design team members and authors of the draft worked really
> hard on this and I respect their technical judgement, but I can't see
> sending this statement to the IESG in its current form. There is
> really no solid technical justification for the recommendation.
> 
> 		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 21 Feb 2001 20:10:58 +0100

Hello, 

Regards,
Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 21 Feb 2001 20:32:52 +0100

Hello, 

Regards,
Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 21 Feb 2001 20:31:57 +0100

Hello, 

Regards,
Hesham

---

From: Roberts Philip-qa3445 <[email-masked]>
Date: Wed, 21 Feb 2001 15:22:09 -0600

Hi Pat,

> I agree that it would have been nice to have charter recommendations, but it
> wasn't explicitely requested from the design teams, perhaps by error, but I
> agre that the problem statement should be clear enough that one can derive
> what the charter items would be.
> 
Makes sense.

> As Luca stated, the design team was explicitely told to work on defining the
> actual problem. What you are asking would have required the team to start
> looking at options. Doing so would have detracted them from forming the
> problem statement.
> 
Also makes sense.

> So the ADs specifically requested that we inform them of any conflicts with
> the SeaMoby work and the Mobile IP work. We know that there have been many
> proposed Micro-Mobility protocols in the Mobile IP WG, and SeaMoby was formed,
> in part, to handle these protocols. 
> 
> So here is a proposal: Now that we have a problem statement (which may require
> additional work), in order to satisfy the IESG request to state how the work
> does not conflict with MIP, we need to list how Mobile IP does, or does not,
> match against the problem statement. This will require an evaluation of Mobile
> IP work items, and the problem statement. 
> 
> Do people feel this is the right approach?? Any other suggestions?
> 
I like this approach.

The problem statement troubles me still.  It seems to be saying host routing has to be part of the solution to the problem and the considerations include the following list:

"While studying solutions for Seamless handoffs using the same
   routable IP address handoff, the SEAMOBY Working Group should
   include the following considerations:

    *  Handoff between heterogeneous networks.  For example, 802.11,
       Bluetooth and 3G cellular.
    *  How to discover a new Access Link and the Access Router serving
       the new Access Link.
    *  How to discover the bandwidth, cost, error rate (and other
       properties) of candidate Access Links.
    *  Involving QoS characteristics as part of the handoff process.
    *  Optimize the path for mobile-to-mobile communications.
    *  Enable plug and play capabilities for Mobile Devices, Access
       Routers/Access Links.
    *  Support for mobility of mobile hosts and mobile networks"

The ADs may ask something like,  "Sounds like host routing is the solution now what's the problem?"  Having said that I'd be happy to volunteer some cycles to help identify overlap with MIP.  Taking this list as a starting point, the 2nd, 3rd, and 6th seem specific items the MIP WG has seen nothing to help it address.

> > One last comment.  I was hoping to find a definition of micromobility in the
> > definitions section.  Is it possible to add that?
> 
> At a minimum, this would be required. However, I know that the use of the term
> micromobility was frowned upon during the conference calls, in favor for other
> terms, and that be the reason for its absence.
> 
I admit to being bad when I asked that question.

> > Phil (not that one, the other one)
> 
> PatC (Yeah, that one)
> 
> 
Phil

---

From: [email-masked]
Date: Wed, 21 Feb 2001 14:54:32 -0600

OK, These comments seem like broad generalizations to me.  Can you James and you
Hesham please be more specific?  I will address your comments below.

Hello,

pdn>BZZZT.  This WAS and anti-goal.  We did not want to BASH
pdn>MIP or any other solution.  We did not want to promote
pdn>any solution either.

> how Seamoby should go about solving it. In particular, Section 2.1

pdn>Well, wouldn't you expect that of a problem statement?  A
pdn>problem statment shouldn't desribe how to solve anything
pdn>sheesh James I though we had been over this a dozen times.

> "good", and that there is really no need to justify why.

pdn>Come on, there were lots of reasons sited, like security associations,
pdn>context transfers between ARs etc.

> that work is needed on a micromobility protocol!

Yes, and if its not done, handovers in pico femto net systems will generally
suck.  Why pay the overhead of MIP when you don't change COA?

> would do better. From this analysis, I would expect to see recommendations

pdn>BZZZZTTT.  SOlution space...

> really no solid technical justification for the recommendation.
Its a problem statement James nothing more.  Its not a recommended solution.  It
does not provide an
answer for anything only an open book.  Keep that in mind.

Thanks,

Phil

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 21 Feb 2001 17:39:40 -0500

I agree.  I wish for a routing update based approach as well, after
recieving the IESG's authorization to do so.

> From: Luca Salgarelli [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 3:09 PM
> To: James Kempf
> Cc: [email-masked]
> Subject: Re: [seamoby] Comments on 
> draft-ietf-seamoby-mm-problem-00.txt
> 
> 
> James,
> 
> I think this is a chicken-egg problem. I think that what you 
> would have
> liked to see ("a technical analysis of the shortcomings of mobile IP's
> tunneled approach and how a routing update based approach 
> would do better")
> would go into solution space, and we were not allowed to do 
> that in this
> draft.
> 
> My understanding is that we are still in a phase in which we 
> would like the
> blessing of the IESG before *working* on the technical 
> analysis that you
> are suggesting, which by the way I would like to see also, 
> and work on as
> well.
> 
> I hope that this draft will get us that blessing.
> 
> Luca
> 
> 
> On Wed, Feb 21, 2001 at 09:12:29AM -0800, James Kempf wrote:

---

From: [email-masked]
Date: Wed, 21 Feb 2001 16:20:28 -0600

Hi Phil,

I don't have many comments on this.  Since the point of the document is to
make the case that micromobility should be part of seamoby going forward
would it be possible to have a short section up front entitled
recommendations for the seamoby charter with the rest of the draft as
explanation?

pdn>I suppose.  However, micro-mobility exploring micro-mobility is
pdn>currently in the charter and this is what this draft does.

The first concrete recommendation I see is this:
Seamless handoffs, while maintaining the same routable IP address of
   a Mobile
Node or Mobile Network should be a work item for the
   SEAMOBY Working Group.

While this seems to be a very concrete item for the working group it's
difficult to see the problem statement in the rest of the document for which
this work would apply.  It appears to be a solution without a problem.
Specifically one might want to state a problem and then why a combination of
mobile ip fast handovers and regional registrations wouldn't suffice to
solve it.

pdn>Early on, I had a single sentence problem statement that b*tched about
pdn>how slow mobile IP would be if/when used in a tangle of pico cells
pdn>and how completely unnecessary it is in these scenarios.  It got yanked.
pdn>I still believe we need a single statement that does complain about
pdn>how MIP is intended for macro not micro-mobility.

<stuff snipped>

On the list of 10 goals in the comparison with Mobile IP it seems that 1-3
are already covered by Mobile IP as mentioned.  Are you suggesting 4 and 5
(FA/GFA/HA Configurability and Reliability) ought to be covered by a working
group other than Mobile IP?  Mobile IP has 6 in its charter but we haven't
seen a lot of drafts yet attempting to tackle the issue.

pdn>Who knows what will happen with future charter bashing?

There are a few other interesting items in the document.  I was intrigued by
the idea of discovery of new access link and new access router, and
characteristics of those.  Fast handover is a fairly large problem with lots
of aspects.  Mobile IP solves one part of it.  There are other pieces that
need to be solved on the router side of it in routed networks.

pdn>I am not sure what you mean here Phil.  Given that MIP is in the router
pdn>work area of the IETF wouldn't this be more work for MIP?

pdn>Whoops.  Probably should define macro-mobility too!

Phil (not the original email author, that one)

---

From: Roberts Philip-qa3445 <[email-masked]>
Date: Wed, 21 Feb 2001 16:48:27 -0600

> ----------
> From: 	[email-masked]
> Sent: 	Wednesday, February 21, 2001 4:20 PM
> To: 	Roberts Philip-qa3445
> Cc: 	[email-masked]
> Subject: 	Re: [seamoby] comments on draft-ietf-seamoby-mm-problem-00.txt
> 
> 
> 
> Hi Phil,
> 
Hi Phil,

> pdn>how MIP is intended for macro not micro-mobility.
I'm not sure about the history of intent, or the meaning of macro or micro-mobility, but perhaps a useful item to suggest would be a performance analysis?
> pdn>work area of the IETF wouldn't this be more work for MIP?
All I meant was that discovery of new access routers and their characteristics was an interesting problem to be investigated.

> Phil (not the original email author, that one)
Phil (figuring out which one is left as an exercise for the reader)

---

From: [email-masked]
Date: Thu, 22 Feb 2001 09:08:23 +0200

Hi Hesham,

> problems which may not be relevant for IPv6. 

I guess this should be stated clearer in the draft.  The solution
for MM should be compatible for IPv4 & v6.

However, as you say 'may not be relevant for IPv6' - does this
mean that it is not relevant for IPv6 or is it something that
we should study?

> shown in MIP before this can be accepted.

The intention of the draft was not to show that MIP has disadvantages.
I believe some participants in the design team feel that some
form of MIP may be the solution needed.  Others feel that
other protocols may be needed.  

Do you feel that issues raised in the draft should not be 
investigated further?  If not, then I think SeaMoby should
be alloed to study this issue further.

best regards,
John

---

From: [email-masked]
Date: Thu, 22 Feb 2001 09:30:09 +0200

Hi Phil & Phil,

> > pdn>I am not sure what you mean here Phil.  Given that MIP 
> > pdn>is in the router
> All I meant was that discovery of new access routers and 
> their characteristics was an interesting problem to be investigated.

Could a possible way forward be for us to state our needs
better & then if the work is done in another WG, that should
be OK - I imagine that most of the email addresses would
still be the same.

br,
John

---

From: [email-masked]
Date: Thu, 22 Feb 2001 09:26:50 +0200

Hi Phil,

> The problem statement troubles me still.  It seems to be 
> saying host routing has to be part of the solution to the 
> problem and the considerations include the following list:

We should see how to finese this.  I attempted (perhaps
not so successfully) to identify a number of areas
that should be investigated.  We would need requirements,
and than some analysis of the possible solutions.  Host 
routing is one of the solutions, but not the only one.

Thinking more about this issue (& the various mails on
this subject), my feeling is that there are a lot of
partial solutions out there to the problem statement.
Some may be applicable more than others, some may meet
the (to be decided) requirements better than others.

This would be the next steps
	1) Make requirements for Seamless Handovers
	2) Analyze applicability of mobility solutions to MM.
	3) Make recommendation on the solution(s).

I think that if this was in the current draft, things might
be clearer.  I did feel that this was out of scope of the 
draft, but if the WG feels that this would be useful to
add, then I shall.

br,
John

---

From: [email-masked]
Date: Thu, 22 Feb 2001 09:04:11 +0200

Hi James,

> "good", and that there is really no need to justify why.

Section 4 was meant to be 'light' reading, a place to give examples
of why the design team thought micromobility was useful/needed. 
 
> each issue, the draft seems to imply that work is underway in 
> the mobile IP group, AAA group, or the Seamoby group (re. paging 
> and context transfer) to address the shortcomings, yet despite this, 
> the draft concludes that work is needed on a micromobility protocol!

I believe the point was to crosscheck what the design team thought
were needed features and if any work was being ongoing.  The point
is not to re-invent the wheel, especially if it is out there.  
 
> What I would have liked to see is a technical analysis of the 
> shortcomings of mobile IP's tunneled approach and how a routing 
> update based approach would do better. From this analysis, I would 
> expect to see recommendations about whether or not there needs to be 
> work on a routing update based micromobility management protocol. 
> Naturally, the  recommendation should take
> 3GPP2's IOS 4.0) but the recommendation really should be 
> based on specific technical drawbacks of mobile IP and how a routing 
> update based approach would solve them. Alternatively, the recommendation 
> could be for a "next generation" micromobility protocol.

As the editor of the document, I'll step-up to this point.  My 
assumption was that this would be the first item on an updated
SeaMoby charter.  The points you request do not seem like they belong
in the problem statement, in my opinion.

As you know, there is a lot of work going on in Mobile IP on MIPv4,
MIPv6, Fast Handovers for MIP, Hierarchical MIP, etc.  What is not
clear to me is the applicability of these protocols & how they 
interact.  I think it would be really important to analyze all of
these, along with other micromobility protocols.  This should
be in another draft.

br,
John

---

From: [email-masked]
Date: Thu, 22 Feb 2001 09:19:57 +0200

Pat,

> So here is a proposal: Now that we have a problem statement 
> (which may require additional work), in order to satisfy the IESG 
> request to state how the work does not conflict with MIP, we need 
> to list how Mobile IP does, or does not, match against the problem 
> statement. This will require an evaluation of Mobile

I think so.  My feeling is that this would best placed in
a seperate draft.  How should we procede?

best regards,
John

---

From: [email-masked]
Date: Thu, 22 Feb 2001 09:18:02 +0200

Hi Philip,

> I don't have many comments on this.  Since the point of the 
> document is to make the case that micromobility should be part 
> of seamoby going forward would it be possible to have a short 
> section up front entitled recommendations for the seamoby charter 
> with the rest of the draft as explanation?

That is a good point.  I can add a short section on that.  Originally,
I did not feel that would be part of the problem statement. I guess
I could add a section titled 'Next Steps' with the following:

 * draft on technical comparison of MIP solutions & MM protocols
   against the problem statement
 * requirements on Seamless Handovers
 * selection of a protocol for micromobility

Again, I don't see that the issues is SeaMoby vs MIP.  If 
the WG feels that MIP is a candidate for MM, then I think
the end result would be for us to produce an information
draft on how to apply/use MIP for micromobility.  Does this
conflict with work that is ongoing in MIP?

>    a Mobile Node or Mobile Network should be a work item for the
>    SEAMOBY Working Group.
> 
> difficult to see the problem statement in the rest of the 
> document for which this work would apply.  It appears to be a solution 
> without a problem. Specifically one might want to state a problem and then

> why a combination of mobile ip fast handovers and regional registrations 
> wouldn't suffice to solve it.

That, IMO, would be the next step, not part of the problem statement.

> In the goals section there is mention of intertechnology 
> handoff (while still being intradomain is implied I believe).  
> Some of the discussion in the fast handoff design teams has been 
> around whether there is a situation in which one could have 
> intertechnology handoffs without easily accomodating
> a make-before-break scheme.  I was wondering if there were 
> examples of that? Don't think this needs to be in the draft just 
> trying to be thorough.  

Members of the design team felt this is an important point.  If there
isn't an example, then perhaps we should add one.
 
> seen a lot of drafts yet attempting to tackle the issue.

Again, I want to stress that this isn't SeaMoby vs MIP.
Would you be opposed to SeaMoby producing information 
RFCs on some issues & then doing the work in MIP?

> need to be solved on the router side of it in routed networks.

This is something that is important work, if it isn't highlighted
in the document, I will try make it more clear.

> definitions section.  Is it possible to add that?

MM has negative connotations to many folks.  We used a lot
of bandwidth on this issues.  There was, at some point,
a statement saying that, For this draft, local mobility
is used in place of MM.

thanks for the comments,
John

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 22 Feb 2001 00:53:01 +0100

Hello Phil,

	I'll just respond to your comment in this mail and address
	the draft in a more specific mail in a separate one.

> pdn>MIP or any other solution.  We did not want to promote
	=> No, no bashing is required. Let me explain it a bit better. 
	To state a problem statement, you need to mention why
	an existing solution does not solve this problem. 
	It is not possible to justify a new protocol to solve problem
	"x" unless you explain to people why problem "x" is not 
	addressed with the exisiting solutions. This is NOT getting 
	into solution space by any means. It is an essential part
	of the problem statement. There is no need to promote
	any solutions, but simply state where the exisiting ones 
	fail. Otherwise this would like like a duplication of the 
	solution.
	Is this clearer ?

	Regards,
	Hesham

---

From: James Kempf <[email-masked]>
Date: Thu, 22 Feb 2001 08:53:41 -0800 (PST)

Hi John,

>be alloed to study this issue further.

The issue in my mind is that the draft is technically much lighter
weight than the context transfer and paging drafts. My impression
is that the micromobility design team didn't have enough time
to study the issues and accumulate enough data to show where
MIP was inadequate in fufilling the requirements. "Intuitive" arguments
aren't enough, to paraphrase Tom Cruise: "Show me the data!" 

Rather than falling back on the kind of light reading that was
ultimately put into the draft, it would have been much better to just
come out and state that the team feels there is a problem that
can be solved by a protocol which doesn't change the IP address
but they did not have enough time to thoroughly analyze it and
therefore they think the item should be put into the Seamoby
charter.

However, I think it should be clear that the evidence for a micromobility
protocol isn't there yet, unlike the context transfer and paging
cases. Both these areas have accumulated some solid cases and data
that illustrate protocol enhancement is needed, I don't feel that
the case has yet been made for micromobility.

	jak

---

From: Roberts Philip-qa3445 <[email-masked]>
Date: Thu, 22 Feb 2001 11:48:07 -0600

>  * selection of a protocol for micromobility
OK.

> conflict with work that is ongoing in MIP?
Agreed.  Same group of interested people will be involved whether it's discussed on seamoby or mobileip and we'll all be subscribed to both no doubt.  There will probably be some joint discussions between the chairs and ADs about who does what.

> RFCs on some issues & then doing the work in MIP?
Not opposed at all.  Just anticipating that the question will be raised as to why improving MIP should be a part of the micromobility problem statement.

---

From: Roberts Philip-qa3445 <[email-masked]>
Date: Thu, 22 Feb 2001 12:10:01 -0600

> ----------
> From: 	[email-masked]
> Sent: 	Thursday, February 22, 2001 1:26 AM
> To: 	phil.roberts; [email-masked]
> Cc: 	[email-masked]
> Subject: 	RE: [seamoby] comments on draft-ietf-seamoby-mm-problem-00.txt
> 
> Hi Phil,
> 
The areas that should be investigated are fine.  If host routing is a possible solution, perhaps it would be better to couch the problem statement without it?

> draft, but if the WG feels that this would be useful to
I don't have a strong opinion either way, but I'm still concerned about the problem statement.  See below.

> John
Here's part of the problem statement I cut out of the draft.

A local mobility mechanism, which localizes processing and
   signaling, thus enabling for a shorter latency, should allow better
   scalability, performance and reliability resulting in seamless
   handoffs. Moreover, a lightweight approach, customized to the exact
   requirements of local mobility while interoperable with a more
   general mobility  mechanism (e.g. Mobile-IP), would allow an easier
   deployment in situations  where local mobility is sufficient, or
   several general mobility mechanisms are involved

PRR> sorry, not sure what happened to my email editor but it's misbehaving.  Is there a more tangible way to say this?  I don't see any real way to state the problem like this without saying there is some suspicion that the solutions within Mobile IP (fast handover, regional registrations) aren't going to cut it for certain kinds of applications.  This is fine with me.  Michael Thomas raised the issue that he's concerned that the interactions between Mobile IP and RSVP will not work fast enough.  Phil also suggested concerns about how quickly MIP updates could be made with devices moving rapidly through clouds of small networks.  One might describe this as networks with multiple layer 3 access points with very unreliable connectivity between the mobile and those access points. Why not couch the problem statement this way with the implied charter items to be to specify the requirements for this local mobility, identify the shortcomings of Mobile IP, and investigate alternate !
ap!
!
proaches?

---

From: "Hongyi Li" <[email-masked]>
Date: Thu, 22 Feb 2001 14:07:21 -0500

Hi James,

My comments are in lines.

-Hongyi

> "good", and that there is really no need to justify why.

The third paragraph in the introduction section gives the reasons
for restricting local mobility solution in the scope of MH routable
IP addresses don't change. 

> the mobile

As we were not supposed to push any solution in the problem definition
phase, there is nothing to compare with. When we select a solution
for MM, we will certainly compare the MM solution with Mobile IP and other
solutions (e.g, SIP mobility) using the criteria in section 3.1.

> shortcomings
> based on specific

We don't want to put the routed and tunneled solutions into the opposite
sides. The local mobility solution will have the options for network
operators to deploy in routers or selected nodes that are connected
by tunnels. 

[%Snip]

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 22 Feb 2001 22:11:11 -0500

I have to agree with Phil N on this one, where did anyone get the 
idea that the purpose of the design teams was to revise the
Seamoby charter? 

It is my recollection that the Seamoby charter was set, and not
open for discussion (I know, I asked). The mandate of the design
teams was to try to work within the charter and compose problem
statements concerning the three topics. We were specifically told
not to look at solutions either.

So why is everyone now asking for solutions, charter changes, etc?
If you have questions or comments on the *problem* definition, fine.
If you want to change the charter, don't attempt to do it through
the problem statements.

If you really believe that the design teams were created to 
recommend charter changes, please post the portion of the minutes
from IETF 49 where this was discussed.

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 5:20 PM
> document is to
*snip*

---

From: [email-masked]
Date: Fri, 23 Feb 2001 09:37:49 +0200

Hi Hesham,

> 	fail. Otherwise this would like like a duplication of the 

The problem statement should address that there are partial solutions
to be problem, but not a complete solution for seamless handovers.

I'm updating the document, and I'll diagram what the document will
try to state:

1 Introduction	3
-> define loosely why seamless handovers are our friends.

1.1 Scope	3
-> discuss what local/mm mobility is and scope it somewhat.

1.2 Problem Statement	3
-> the problem

2 Overview	7
-> discuss some key points to address (I'll add more details)

3 Interaction / Comparison With Other Protocols	7
-> state what some solutions are (MIP mainly) and discuss
   where they fall short.

4 Scenarios	9
-> high level scenarios, to support some of our 'visions'
   (or hallucinations!!)

5 Next Steps
-> talk about what we should do next ...

Hopefully, this all will simply clarify the document.

br,
John

---

From: [email-masked]
Date: Fri, 23 Feb 2001 09:41:49 +0200

James,

> MIP was inadequate in fufilling the requirements. "Intuitive" 
> arguments aren't enough, to paraphrase Tom Cruise: "Show me the 
> data!" 

It would be helpful to be a bit more 'diplomatic' in your mails
then.  If you felt that there was not enough details on certain
points, a request for clarification in the document would 
suffice.

> therefore they think the item should be put into the Seamoby

I will state things much clearer.
 
> the case has yet been made for micromobility.

Paging & Context transfer do not have the competing interests
that MM has.  I believe both documents will have an easier time
getting consensus.  MM has a number of competing solutions.
Therefore, I imagine that a protocol analysis/comparison is needed
(similar to what was done in the AAA WG).  This has been
my understanding from IETF 49.  

best regards,
John

---

From: [email-masked]
Date: Fri, 23 Feb 2001 09:45:13 +0200

Hi Phil (R),

> Agreed.  Same group of interested people will be involved 
> whether it's discussed on seamoby or mobileip and we'll all 
> be subscribed to both no doubt.  There will probably be some 
> joint discussions between the chairs and ADs about who does what.

I would think that this is a good way forward.

> Not opposed at all.  Just anticipating that the question will 
> be raised as to why improving MIP should be a part of the 
> micromobility problem statement.

OK, I think I mentioned this before, but let me say again 
(and add to the draft) that we don't feel that there is
a complete solution to the problem of MM & Seamless 
handovers.  I'll address this point in a revision.
 
br,
John

---

From: [email-masked]
Date: Fri, 23 Feb 2001 14:41:59 +0200

Hi Phil R,

> The areas that should be investigated are fine.  If host 
> routing is a possible solution, perhaps it would be better to 
> couch the problem statement without it?

Agreed.
> PRR> sorry, not sure what happened to my email editor but 
> it's misbehaving.  Is there a more tangible way to say this?  
> I don't see any real way to state the problem like this 
> without saying there is some suspicion that the solutions 
> within Mobile IP (fast handover, regional registrations) 
> aren't going to cut it for certain kinds of applications.  
> This is fine with me.  Michael Thomas raised the issue that 
> he's concerned that the interactions between Mobile IP and 
> RSVP will not work fast enough.  Phil also suggested concerns 
> about how quickly MIP updates could be made with devices 
> moving rapidly through clouds of small networks.  One might 
> describe this as networks with multiple layer 3 access points 
> with very unreliable connectivity between the mobile and 
> those access points. Why not couch the problem statement this 
> way with the implied charter items to be to specify the 
> requirements for this local mobility, identify the 
> shortcomings of Mobile IP, and investigate alternate approaches?

These are all good points.  I will try to address them in the updated 
document.

thanks,
John

---

From: Roberts Philip-qa3445 <[email-masked]>
Date: Tue, 27 Feb 2001 09:28:23 -0600

> We might not to work on stating the problem in a better way.  I'll try to
> make an attempt.
> 
> Problem Statment:
> The internet works with clients, servers, and peers using the same IP
> address
> while connected to the internet.   The internet works by addressing
> devices at the edge of the
> network not in the middle of the network.  Mobile clients, servers, and
> peers should operate
> the same way.  How can the internet support mobile clients, servers, and
> peers while
> keeping the same routable IP address ?
> 
I like this approach.  Perhaps you might want to change "The internet
works..." to "The internet scales so well...."   Maybe the last sentence
could be "How can the internet support mobile clients, servers, and peers
while maintaining the same scalability allowed by the current internet
architecture?"

> Dana