Re: how mobile do we want to be

[Thierry Ernst <ernst@sfc.wide.ad.jp>]

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

The motiviations behind mobility and multihoming are distinct (i.e. the
intention is orthogonal) but the solutions MAY be similar / could
apply to one another / could be the same (i.e. the result may not be
orthogonal).

> 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

I'm not sure it's the intention. I would better take this as a "concern"
(deploying an architectural change which doesn't solve the mobility
problem is at best a loss of opportunity and at worse a lack of
planning) . I personaly have no intention to integrate mobility issues
or problems into the Shim6 WG as long as the output are **experimental
RFCs**.  However, it may be useful if a twin IRTF is set up to
investigate the relation between mobility and multihoming using a shim
(or compatible with a shim) so that, in the end, we can output - in a
few years and in other WGs - RFCs in the standard track category which
bring an answer to both mobility and 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.

The existing mobiliy WGs are not chartered to discuss this.

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