Subject: Re: [netext] NETEXT2 BOF conclusion

From: "Alper Yegin" <[email-masked]>
Date: Tue, 3 Nov 2009 11:48:32 +0200

I agree.

Also, I don't quite understand how a L2-only solution would help with
inter-technology handovers between two distinct access technology. A
handover between IEEE 802.11b and 11a is one thing, between 11b and 16 is
another. So, I'm not sure if option 1 really solves the problem.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sri Gundavelli
> Sent: Wednesday, October 28, 2009 5:35 AM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [netext] NETEXT2 BOF conclusion
> 
> 
> Hi Jari,
> 
> Thanks for the mail presenting your views on how to move forward.
> Few comments below.
> 
> 
> >
> >   I also personally believe that #2 and #3 are functionally
> >   similar enough that there's no requirement that forces us to
> >   pick #3.
> >
> 
> This would certainly be a key point of debate. Its unfortunate
> that few folks who are in the client-mobility camp managed to
> make it appear option#2 and option#3 are almost the same and
> hence go for client-based mobility protocols. But, if we look at
> the details and place them side-by-side, however I look at it,
> to the point of hypnotising myself to be part of a client
> mobility camp, I cannot convince myself that option #2 and option
> #3 are equal. To me and having been involved in Mobile IPv6
> development and having some understanding of both the protocols,
> I'm not able equate the complexities involved in each of those
> appraoches.
> 
> 
> 
>      Option-2: focussing on MIPv6 stack requirements:
>      a.) Implementation of MIPv6, IKEv2, DSMIP6, MCOA specs and on
> million
>      platforms.
>      b.) Requires the host to be involved in mobility management,
> tunnel
>      management.
>      c.) Requires significant amount of system resources, CPU, Memory
> ..etc
>      d.) And we have one or two vendors who ship those stacks. With no
>      industry experience on the client stack, or with close to one or
> two
>      serious interoperability attempts and years back.
> 
> <vs>
> 
>      Option-3: identifying the minimal needed signaling giving the
> ability
>      for the stack to deliver certain handoff hints to the affect:
>      a.) a given attachment is a new interface attachment and these are
>      the interface properties
>      b.) a given attachment is due to a handoff between IF-1 and IF-2
>      c.) a given flow with the following flow parameters, should be
> moved
>      from IF-1 to IF-2.
> 
>      These minor data elements are the attachment preferences, gives
> the
>      network the ability to determine if the given attachment is due to
>      multi-homing or due to inter-technology handoff and to perform
>      flow management.
> 
> 
>      Jari, With Proxy Mobile IPv6, we practically built 90% of the
>      features that client-based mobility can offer and with zero
> changes
>      to the host. Its the basic design choice of client complexity that
> to
>      most part kept the Mobile IP technology as a failed protocol with
> no
>      deployments or commercial success. Proxy Mobile IPv6 atleast has a
> ray
>      of hope to be deployed. These two features flow mobility and
> inter-tech
>      handoffs (with client expressed preference), will give the
> protocol the
>      completeness and for the valid reasons that these attach
> preferences
>      have to come from the host and not from the network, we need the
> host
>      to deliver those hints. But, moving to client-based mobility for
> fixing
>      this gap wont help this protocol, but will certainly keep the
>      client-based mobility in business, the last hope.
> 
>      Now, focussing on option-1, building virtualized interface, hiding
>      the physical interface variants, does give the ability to perform
>      inter-tech handoffs and multi-homing, as supported by RFC5213.
> But,
>      it wont give the needed hints from the client and does not allow
> us
>      to build flow mobility support. But, either way, this requires us
>      to specify how host stack can achieve that and it certainly helps
>      if we can move that work forward while we are discussing this.
> 
>      Bottom line, I believe, there are enough folks who wants to use
>      network-based mobility technology and they should have the choice,
>      however difficult it may be for folks in the client-based mobility
>      camp. My humble 2c.
> 
> 
> Regards
> Sri
> 
> 
> ----- Original Message ----
> >   From: Jari Arkko <jari.arkko at piuha.net>
> >   To: netext at ietf.org
> >   Sent: Wed, October 21, 2009 4:29:00 PM
> >   Subject: [netext] NETEXT2 BOF conclusion
> >
> >   I have been trying to come up with a way forward on this, but its
> hard.
> >   To recap, there are a few different technical possibilities for
> >   multi-interface mobility:
> >
> >   1) Link layer hides interface variants behind one logical
> interface. For
> >   instance, an IP stack does not see the change from GSM to UMTS
> radio or
> >   802.11b to 802.11g; its handled as a part of the link layer. Such
> link
> >   layer operations need to be supported both by the host and the
> network.
> >   This approach has the minimum impacts on IP stack, but requires
> >   specification of the link layer mechanisms across the used
> interfaces.
> >
> >   2) Different interfaces are handled via existing host-based
> mobility
> >   mechanisms (Mobile IPv6, MOBIKE, HIP, application layer). Within
> one
> >   interface the link layer handles mobility, possibly using Proxy MIP
> >   internally. Both the host and the network need to support the host-
> based
> >   mobility mechanism, but the link layer does not have to aware of
> the
> >   other interfaces in any way.
> >
> >   3) We extend Proxy MIP with capabilities to handle cross-interface
> >   handovers. This is similar to approach #1, but the signaling
> messages
> >   are at the IP layer. The benefit is that this could be used across
> >   different types of link layers even if they do not support
> handovers.
> >   The downside is that just as with approach #2, the IP stack has to
> be
> >   capable of these operations.
> >
> >   The big argument we have been stuck with since San Francisco is
> between
> >   #2 and #3. One group believes that existing mechanisms are
> sufficient,
> >   and they are -- it is indeed possible to do this. Another group
> believes
> >   that they need a different solution based on Proxy MIP. Such a
> solution
> >   is also of course possible. But we've made very little headway in
> >   resolving the question on what should be done. In particular, we've
> not
> >   been able to describe very well why some technical reasons would
> dictate
> >   one or the other solution. I believe that is likely because they
> are
> >   really very similar solutions.
> >
> >   At this point I do not believe we have consensus to go forward. We
> left
> >   the BOF with the idea that requirements work would solve this
> issue. If
> >   I'm right the solutions really are very similar, this work may not
> be
> >   able to resolve the conflict, and it would take a long time. I
> think it
> >   would actually serve as better if we were to decide now, as opposed
> to
> >   pretending that more details will make the decision easier.
> >
> >   With this in mind, I have a proposal for a way forward. Given that
> I do
> >   not see consensus for approach #3, I do not think we can go ahead
> with
> >   that. I also personally believe that #2 and #3 are functionally
> similar
> >   enough that there's no requirement that forces us to pick #3. In
> >   addition, approach makes mobility end-to-end between the host and a
> >   network node; approach #3 ties the use of mobility to a particular
> link.
> >   If the router on that link does not support the mobility mechanism,
> >   mobility service is not possible. I think it would be
> architecturally
> >   better to separate access and mobility.
> >
> >   However, I would like to move forward with a different work item.
> The
> >   IETF has never really explored approach #1, even if it is commonly
> used.
> >   Of course, the IETF's role is not to design these link layer
> mechanisms,
> >   but I believe it would be valuable for the IETF to publish an
> >   informational document on considerations for building such
> mechanisms.
> >   This document would talk about the requirements that the mechanisms
> must
> >   fulfill in order for IP to work correctly, when such mechanisms are
> >   recommended and when not, what their advantages and downsides are,
> what
> >   happens if MTUs or routers differ, and so on. At the same time this
> >   document would describe the "virtual link" model that some people
> have
> >   been using in the context of Proxy MIP. The idea is to add this
> work
> >   to the NETEXT WG charter.
> >
> >   I realize this does not make everyone happy, but I'm not sure there
> >   is an outcome that does. What we lose by not doing solution 3 is
> >   a design that that simultaneously allows something to be done
> >   in a link-layer agnostic manner _and_ employs PMIP as a part of the
> >   solution.
> >
> >   Thoughts?
> >
> >   Jari
> 
> 
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext