Subject: RE: [seamoby] I-D ACTION:draft-ietf-seamoby-mm-problem-00.txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 22 Feb 2001 23:46:41 +0100

> Hesham Soliman  (ERA) writes:
>  > "The assumption is that a local protocol can address these goals
>  >    better by limiting its applicability to a smaller domain (such as an
>  >    intranet - e.g. warehouse, and not the entire internet as in the
>  >    case of Mobile IP) and reverting to Mobile IP for the general case
>  >    of internet mobility support."
>  > 
>  > => This already assumes that the mm protocol is not 
>  > based on MIP. I think it's premature to say so. Also I 
>  > don't see why limiting the applicability of a protocol
>  > to a local domain makes it "better". 
>  > BTW what is "better" ?
> 
>    Um, that's exactly what HMIP does, yet I don't
>    see you complaining about it.
> 
	=> HMIP IS MIP with very minor extensions. 
	I had two simple questions, why is it assumed
	that MIP is only good for inter-domain mobility
	and what is"better". "better" needs to be explained.

>  > "Moreover, a lightweight approach, customized to the exact
>  >    requirements of local mobility while interoperable with a more
>  >    general mobility  mechanism (e.g. Mobile-IP)"
>  > 
>  > => Again assuming that the mm solution is not MIP-based
> 
>    I think *you're* the one thinking it ought to
>    be MIP based. 
> 
	=> Where and when did I say that ?
	I'm tying to limit the assumptions at this 
	stage.

>  
>  > "While studying solutions for Seamless handoffs using the same
>  >   routable IP address handoff"
>  > 
>  > => Why does it have to be the same IP address ? Is this 
>  > a definition of mm ? If so why ?
> 
>    There is a lot to be said about keeping the
>    same IP address if it is at all possible. I,
>    like Phil, have a hard time seeing why that's
>    especially controversial since the entire
>    Internet as currently built makes exactly that
>    assumption. 
> 
	=> "Currently" there is no IP mobility.

> If you don't change IP addresses,
>    you get to ignore a tremendous number of
>    questions that MIP in its many forms beg.
> 
	=> Can we be a bit more specific ? and if your
	reasons are valid why can't they be explained 
	in the draft ? 

>  > => This makes it local mobility within a subnet doesn't it ?
>  > Or is the assumption here that MNs will have topologially 
>  > incorrect addresses ? At least for v6.
> 
>    "Topologically incorrect" doesn't have any meaning
>    in IP until you get up to the BGP level. 
> 
	=> Are you saying that every AR (or default router)
	will be a BGP router ? I hope not.

> Within an 
>    autonomous system, you can place subnets -- including
>    /32 or /128's anywhere you want. 
> 
	=> So to avoid inter-AR mobility we have one AR per 
	domain ?

>  > "4)   Configurability:    Plug & Play of routers/base stations not
>  >                               addressed - need to configure HA/FA/GFA's
>  >                               etc."
>  > => V6 ??
>    
>    If you end up with HMIP or FMIP, you end up
>    with things that are sort of like FA's, and
>    they all require configuration. Hardly an
>    optimal situation for the great unwashed
>    masses.
> 
	=> Again this is very vague. What do you need 
	to configure ?
>  
>  > "6)   QoS:                controversial; tunneling complicates QoS
>  >                               support"
>  > 
>  > => Does RSVP support mobility at all ? Maybe tunnelling 
>  > makes it slightly more difficult, but we have a bigger 
>  > problem if RSVP does not support mobility.
> 
>    RSVP certainly supports non-mobility. Not
>    changing IP addresses works as-is. The
>    questions that MIP raises are quite profound
>    and aren't going to be resolved very quickly.
> 
	=> Then it's a bit misleading to say that tunnelling
	is the big poblem here.  As you said above there are
	much bigger problems that need to be solved.

>  > "Mobile Network      controversial.
>  >           Support:"
>  > 
>  > => Why is it controversial ?
> 
>    Because it's not currently supported in MIP at
>    all? Not changing IP addresses works as-is.
> 
	=> Read HMIPv6 and draft-ernst-mobileip-v6-network.

>  > "3.1.1 Scalability Issues
>  > 
>  >    1)   There is a concern that A GFA/FA in every AR may not scale or
>  >         even be desirable in extremely inexpensive AR devices.
>  > 
>  > => V6 ? I'm not sure about "extremely expensive" Once
>  > you have an FA you can port it to different nodes.
> 
>    You've glossed over "desirable" and "scale". We
>    have to consider that these network will need
>    to be deployed real human beings too. Just because
>    a cellular folks can afford to spend scads of
>    money on network engineering to save every 
>    precious bit of air bandwidth, doesn't mean
>    that everybody else will or should. Indeed, 
>    the advent of cheap 802.11 provides tons of
>    motivation to sacrifice bandwidth inefficiency
>    for ease of deployment. 
> 
	=> I think you drifted very far from my simple question.
	GFA/FA are relevant to V4. What does that have to
	do with BW efficiency, cellular people and 802.11 ?
	The whole sentence is only relevant for v4.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Feb 2001 15:32:10 -0800 (PST)

> 	and what is"better". "better" needs to be explained.

    We're in the weeds here. 

    You said that it "already makes the assumption",
    but that's not what it says. It merely acknowledges
    that MIP is the macro solution. It says nothing
    about what the MM protocol should be.

 > 	=> "Currently" there is no IP mobility.

    Correct, and the more that you hide mobility,
    the fewer problems you're going to uncover.
    This is the exact same reason that MIP is
    preferable over application layer mobility
    awareness. Clearly, arbitrary host routes
    don't scale to the Internet, so MIP is
    clearly an important part of the global
    picture. However, there are plenty of
    applications which would probably be well
    served by mobility within a limited context. 

 > 	reasons are valid why can't they be explained 

   Well, I listed off probably a dozen or two in
   my RSVP draft. I have no reason to believe that
   other things which are involved in the routing,
   and treatment of traffic will not be likewise
   chellenging. It remains to be seen whether 
   those other things seemingly work as well as
   RSVP does by just moving routes around, but I
   think there is some reason for optimism.

 > 	will be a BGP router ? I hope not.

   Of course not. IS-IS and OSPF can move host
   routes around as-is if the router is so inclined.
   There is nothing "topologically incorrect"
   about that, especially if it correctly reflects
   the host's reachability.

 > 	=> So to avoid inter-AR mobility we have one AR per 

   I meant autonomous in the BGP sense.

 > 	=> Again this is very vague. What do you need 

   How do those routers know which BU's to accept?
   Maybe these things are all inevitable, but it
   would be nice to explore whether there are some
   local optimizations and simplifications -- ie
   ones which clearly cannot scale up to the scope
   of the Internet -- to simplify setup and deployment.
   
 > 	much bigger problems that need to be solved.

   Actually, I'm not convinced that there's anything
   in base level RSVP that needs to solved if you
   keep the same address. It's MIP that tickles
   the shared explicit problem, etc. There's still the
   authorization/authentication problem, but
   that's not strictly an RSVP problem -- you're
   not required to use it, after all.

 > 	=> Read HMIPv6 and draft-ernst-mobileip-v6-network.

   Let's just say that it's poorly understood. 
   Pekka Nikander is about to release a draft that
   outlines a lot of security issues, including
   the one that I outlined on the MIP list a few
   days ago. The Ernst draft fixes one obvious
   problem with MIP but falls into the same
   security trap that Pekka describes, and has
   even deeper implications IMO.

	       Mike