Subject: Re: [netext] NETEXT2 BOF conclusion

From: Sri Gundavelli <[email-masked]>
Date: Tue, 27 Oct 2009 20:34:38 -0700 (PDT)

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