If there is a mobility solution in our result it will be evident
to all. I see better where your going from the mail below. I just
believe we must remain focused on the multihoming problem. 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.
> > >
> > >
>
>