At 6:31 AM -0800 2/15/08, Jari Arkko wrote: >Ted, > >Responding to your scope question. > >Actually, we are walking a fine line with the scope. At the time that >this work got chartered, we did not have a good understanding of all the >issues. Jari, the charter explicitly rules out some of the work in this document. I don't have a problem with the current scope, but it isn't a fine line: "The protocol will not attempt to hide handover between two separate interfaces on the mobile node." is actually one of the clearer charter statements we've ever written. > After two years of development and analysis there are some parts >of the problem space that we understand better. One of these issues >relates to being able to provide a Netlmm service without breaking >existing hosts. In 2007 it became apparent that we actually have to >understand the semantics of the host's attachment in order to not cause >a problem in situations like having two interface cards in the same host >both connected to the same Netlmm domain. Fortunately, this information >is available in certain major use cases of Netlmm. For instance, in >cellular networks the link layer actually knows what is happening when a >host moves around and can distinguish new vs. moved attachments. At least as I understand it, this required work from folks like 3gpp; they had to define a solution that let the network know whether a mobile supported PMIP or not. I very much appreciate the clarity now in the document that strongly indicates that in the absence of clear indicators that an inter-technology attachment is a handoff, it MUST be treated as multi-homing. Without that clarity, we would be in a far worse place. > The >support for multihoming/cross-access handovers in the document is >actually very limited, merely building on this. Its a side effect of >having to prevent a problem. As I have required that the WG not cause a >problem I also have to accept the implications. I think avoiding the >problem is more important. > >(By the way, the multiple interfaces question is not the only scope >issue in the WG; they also want to work on IPv4 support. A rechartering >process is in progress for this and possibly some other extensions.) > >With regards to host modifications for handling multihoming and all >types of cross-technology handovers: the current document supports >limited forms of this, and requires support from link layer to do this. >As I mentioned above such support exists in the networks that are prime >customers for this work. However, I think there is interest for an L3 >solution, and I think it would be interesting work. From the perspective >of the current document that would merely be an additional source of >information. But at the same time I think it would be beneficial to look >at other issues around the multiple interfaces/handovers question. I >would support adding something along these lines to the new charter, and >have the WG produce extensions for this. I appreciate your willingness to have this work go forward. As you recognize, there are currently "prime customers" for this work who have a sense of the system changes they will require to deploy inter-technology PMIP (e.g. terminals capable of using a virtual interface over multiple physical interfaces; handoff indicators at multiple link-layers, and so on). Without an L3 interface that allows the terminal to support PMIP, those will be difficult deployments. They seem to have the engineering resources to succeed, but both that crop of networks and some not in our current crop of customers will find this much easier going with at least the option of using a standard L3-or-above mechanism to signal their support of PMIP and to provide handoff indicators. >However, this should be seen as an option for relatively limited class >of networks that can actually assume host changes. For instance, >networks with purpose built handsets. I still believe in the current >charter's core idea that unmodified hosts must be able to plug into >Netlmm domains and work at least as well as they would without Netlmm. >In fact, I would go as far as stating that requiring host modifications >would be a complete non-starter for most of the applications of Netlmm >that I am aware of. For Netllmm systems within a single technology, this is not required. It is not even required for multi-technology hosts in a network capable of providing inter-technology hand-off, providing the network does not try to do inter-technology hand-off to unmodified hosts. But inter-technology hand-off requires hosts that understand that an IP address they got on interface0 may show up on interface1; pretty generally that involves a modification to allow for a virtual interface that covers both. >As a result, I am against extending mn-ar-if with >new functionality and making its support a requirement for mobile nodes, >if that's what you meant. > >I am on the other hand supportive of such extension. I'm even supportive >of it eventually becoming even mandatory to implement on the network >side. Perhaps this is actually what you wanted? Note that there is >really no interoperability issue with making such an extension from day >one vs. later. Hosts do not know Netlmm is running in the network, and >obviously they cannot assume they will only visit Netlmm-based networks. >As a result, whatever additional service they wish to get from the >network would have to be negotiated anyway. Hosts that do no know NETLMM is running in an inter-technology handoff network do not get handoff when changing technologies. They get multi-homing. That's fine, but we need to be as clear in discussion as the draft is that this is the case. In the current networks, they may well signal their support and handoff at layers below IP; for the current customers that may, indeed, work well enough. But I believe that a standardized solution to the more general problem is a necessary part of this solution, and we should strongly indicate where it will fit in the toolkit as soon as possible. For those who wonder how often the multi-interface case will arise, the laptop I am using has 5 physical interfaces that can run IP (ethernet, bluetooth, 802.11, firewire, evdo), and the phone sitting next to it 3 (802.11, bluetooth, cellular). Thanks for your response and clarifications, Ted >Hope this clarifies, > >Jari > > >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >http://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf