[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how mobile do we want to be
> May I suggest a compromise view here. Why don't we fix/focus on the
> multihoming problem. In the course of that work we should do nothing
> to hurt mobility as we must always think about security in the IETF
> work effort. If there is a mobility solution in our result it will be
> evident to all.
I agree with this to the condition it is written in the charter.
> I see better where your going from the mail below.
I hope that I succeeded into this.
> I just believe we must remain focused on the multihoming problem.
I agree on this too.
Thierry
> I am already
> extremely skeptical of shims first off as network experienced
> implementor and architect and one who ships products, if we try to
> solve mobility too I will probably go away. Not because its not
> interesting/important, but the engineer and leader part of my brain
> would be telling me this effort will not complete trying to solve both
> abstractions at the same time and consensus will not happen. Thus not
> a good use of my precious time, life, and my eyes that read so many
> IETF drafts etc.
>
> thanks
> /jim
>
> > -----Original Message-----
> > From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On
> > Behalf Of Thierry Ernst
> > Sent: Wednesday, March 16, 2005 11:46 PM
> > To: shim6@psg.com
> > Subject: Re: how mobile do we want to be
> >
> >
> > > 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.
> > > >
> > > >
> >
> >
--
Thierry Ernst, PhD
WIDE, Jun Murai Lab., Keio University, Japan
Nautilus6 Chair: http://www.nautilus6.org
Web: http://www.sfc.wide.ad.jp/~ernst/
T:+81-44-580-1600 F:+81-44-580-1437
--