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: netext-bounces at ietf.org [mailto:netext-bounces at ietf.org] On > Behalf Of Sri Gundavelli > Sent: Wednesday, October 28, 2009 5:35 AM > To: Jari Arkko > Cc: netext at ietf.org > 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 > netext at ietf.org > https://www.ietf.org/mailman/listinfo/netext
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.