RE: how mobile do we want to be

["Bound, Jim" <jim.bound@hp.com>]

I will take it further.  Margaret is correct and I will be stronger and
replace the word tangential with orthogonal.  Mobility and Multihoming
are completely two separate technology efforts and functions related to
building a multihome archictecture, a network operations model for an
enterprise, or a shim solution within an IP stack.  Another example is
Mobile IPv6 et al (multiple working groups on mobility) is completely
orthogonal to MANETs problem of routing or autoconfiguratin on the link.


In my opinion I have seen some views expressed to try to integrate
Mobility issues-problems-opportunities into the work of multihoming and
I believe to circumvent the IETF direction in the respective mobility
WGs, as end-run as opposed to going to those IETF WGs and defending
their need technically with that IETF center of expertise.

/jim 

> -----Original Message-----
> From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> Behalf Of Thierry Ernst
> Sent: Wednesday, March 16, 2005 10:35 PM
> To: shim6@psg.com
> Subject: Re: how mobile do we want to be
> 
> 
> I'm not sure that Margaret definitions are right. See below.
> 
> On Mon, 14 Mar 2005 14:43:31 -0500
> Margaret Wasserman <margaret@thingmagic.com> wrote: 
> > Personally, I consider the subjects of mobility and renumbering to 
> > both be somewhat tangential to the subject of multihoming. 
> > Certainly, they are all related in some ways, but they are not the 
> > same problem and may not have the same solution.
> 
> There are diffrent topics when we do think about the motivations /
> needs, but that may be similar when thinking about mobility. Mobility
> solutions could serve as a means to renumber/multihome and multihoming
> solutions could serve as a means to solve mobility ... So, it's not
> orthogonal as it depends from which perspective you look at 
> the picture.
> 
> > To my way of thinking, the following definitions apply:
> > 
> > Mobility:  Changing a node's point of attachment to the Internet 
> > without losing L3 sessions. Depending on the mechanism employed, 
> > mobility may or may not involve changing the topological 
> location of 
> > the node within the Internet (i.e. the IP address prefix of 
> the node).
> 
> "IP-layer mobility" means changing the L3 point of attachment and
> "mobility support" is the abilitiy to do this without losing the
> sessions. Such mobility necessarily means that the 
> topological location
> of the node would be changed (if not, I don't understand the 
> scenario),
> and, in such a case, that the IP address would be changed (an 
> interface
> must obtain an address on the link it is attached to, right 
> ?). However,
> depending on the solution to support this, upper layers may 
> not see the
> change of IP address (e.g. mobility).
> 
> > There are two subtypes of mobility:  mobility within a 
> campus (under 
> > a single administrative domain) and mobility across the Internet. 
> 
> This is called Macro/Global mobility and Micro/Local mobility (see RFC
> 3753).
> 
> > Mobility within a campus is most often handled by layer 2 
> protocols, 
> > such as dynamic VLANs, that require no change to the node's 
> > topological location (IP prefixes or addresses).  Mobility 
> across the 
> > Internet does require some change to the topological 
> information, at 
> > least at some level, and is handled by MIP (v4 or v6).
> 
> You can move into a campus and do a L3 handoff between 2 subnets (i.e.
> L3). If the service provider is different, this is "global 
> mobility", if
> it's the same provider (2 WLAN, with no L2-bridging) this is "local
> mobility".
> 
> L3 mobility can be handled my MIP4/6 if it's a host (or using other
> proprietary management protocols, e.g. LIN6), or by NEMO Basic Support
> if it's a router, or other standardized/not standardized mechanisms.
>  
> > Renumbering:  Changing a node's topological location within the 
> > Internet.  A node that previously had one topological location (IP 
> > address prefix) is reconfigured to have a new topological location.
> 
> Renumbering to me means adversiting a new prefix, with the result that
> the node would have a new IP address. So, I wouldn't say "changing the
> topological location" as the word "changing" bring a sense of 
> "proactive
> behavior" of the node, whereas it is indeed "reactive behavior".
> 
> During the process of renumbering, the nodes may be 
> "multihomed" during
> a transient period of time.
> 
> > Multihoming:  Allowing a node that has more than one topological 
> > location within     the Internet to use its redundant paths for 
> > efficient or reliable Internet connectivity. Note that multihoming 
> > _does not_ involve changing the node's point(s) of 
> attachment to the 
> > Internet and/or changing the node's topological locations 
> within the 
> > Internet; the node has more than one topological location on an 
> > ongoing basis.
> 
> Agree on this.
>  
> > Now, clearly the above definitions are related, particularly if you 
> > view renumbering and mobility as the process of adding a new 
> > topological location and removing an old one (perhaps very 
> quickly in 
> > some situations).  However, there is a very important difference:
> > 
> > *** In shim6, two nodes can exchange their full set of topological 
> > locations at the beginning of the session and they are not expected 
> > to change during the lifetime of the session. ***
> > 
> > The shim6 mechanism might be a useful tool to soften the blow of 
> > renumbering.  A new address prefix (topological location) could be 
> > added, and hosts could be multihomed for a while during which 
> > longer-lived connections and associations could be migrated to the 
> > new topological location (manually, or using some other solution). 
> > Then, the old topological information could be deprecated 
> and removed 
> > on a schedule that allows the completion of shorter lived 
> > connections.  So, shim6 is not a renumbering solution, but it might 
> > be usefully applied to the problem of renumbering.
> > 
> > It is not easy to see how shim6 (as defined) could apply 
> directly to 
> > mobility, as described above.  Using shim6 as a mobility mechanism 
> > would (at minimum) involve adding new topological information in 
> > mid-session and might involve adding new topological 
> information at a 
> > time when the node is unreachable using the old topological 
> > information.  This creates a universe of protocol issues 
> and security 
> > concerns that are not present in the simpler multihoming 
> case, and I 
> > would prefer that we don't try to solve this problem right now as 
> > part of the shim6 solution.
> 
> I agree that it's not straight forward to see shim6 applying for
> mobility, but I think that what Avri was trying to say is 
> that it would
> be a shame if such an important change wouldn't at the same time bring
> an answer to the mobility issue (particularly given the fact that an
> important proportion of nodes would be mobile).
> 
> So, playing an evil game, mobility-concerned people may wonder what is
> the benefit of such an architectural changes if the mobility problem
> remain unchanged ? (does it worth the effort ?).
> 
> Thierry.
> 
> 
> > Personally, I respect all of the work that has gone into the Mobile 
> > IP solutions, and I think that we would be underestimating the 
> > difficulty and subtlety of that problem space if we assume that it 
> > can be solved by a simple variant of the shim6 approach.  I 
> do think 
> > it is important for shim6 to co-exist peacefully with MIPv4 and v6, 
> > and I think that is sufficient, at least for our first step.
> 
>