Hi Thomas/Ed: (I was not really expecting Thomas to respond to this thread, I want support from folks :), now they are gone).
1. We don't have any experience with MIPv6 RO, I agree. But, if we don't enable this function in every IPv6 node, we will never ever have the opportunity to turn this feature on. Mobile IPv6 is the only global mobility protocol, that we have standardized in IETF, ignoring PMIPv6 which is a local mobility protocol. When MIPv6 was designed (when you were the AD), it was always viewed a base feature of IPv6. The choice of MH, as supposed to using a transport layer ports, or the support for RO, was inline with that thinking. 2. When Mobile IPv4 was specified in 90's and even after CDMA adopted the protocol, there was always a comment on the lack of RO support. This is a protocol that suffered from "triangular routing", at least the perception, if anchoring is the right model and if operators liked it, is another topic. But, we never had the capability to support that feature in IPv4, we can specify a solution for MIPv4 RO, but any solution that requires a change in every IPv4 node in the internet, implies the feature is useless. We have an opportunity here to make that change here. 3. I can understand that we have to be careful what we mandate in the node requirements document. If feature-x makes sense, useful, easy to implement, inline with Internet architectural direction. This protocol is specified, analyzed, implemented and studied in universities for number of years . Most Linux/BSD kernels have support Type-II RH, I remember some Linux distributions have included the RO feature by default. Its not a whole lot of code, or complexity that one needs to deal with. Its matter of including that package in all distributions. Making that mandatory. 4. On the comments related to deployments, the specs are referenced in various SDO interfaces. There are implementations (I cant speak for a vendor), but from what I believe, .Ex: Qualcomm LTE chipsets will have the MIPv6 stack. My point is that we have a good opportunity to make this a requirement of every IPv6 node (if we believe in the feature), else, even if we get all the experience with the RO approach, we can't do any thing 5 years from now, once there is massive roll out of IPv6 nodes. I really hope we can add bit more text here to encourage, or include that feature. I don't know how this work will be tied to the, Federal IPv6 Requirements spec, on all the different classifications and where this fits. I'm only hoping to see a better classification than the current "Optional". "No experience", type coloring. Regards Sri On Aug 20, 2010, at 11:47 AM, Thomas Narten wrote: > Sri Gundavelli <[email protected]> writes: > >> Couple of comments on Section 9.0 (Mobility): >> draft-ietf-6man-node-req-bis-05 > >> 1.) When Mobile IPv6 was designed, one important feature that made >> into the protocol is the support for Route Optimization. The >> ability for a mobile node to provide the information on the direct >> (non-anchor or non-triangular) path to a Correspondent Node. This >> was not possible in Mobile IPv4, as any change requirement to IPv4 >> did not make much sense. > > Actually, this explanation is not consistent with history. RO was not > added to MIP4 because there was no customer for the work. MIP has been > implemented and deployed in IPv4. But those using it had no need for > and didn't seem to have a business case for RO. There was an ID for RO > for MIP4 at one time, but the WG abandoned the draft when it became > clear no one had interest in actually deploying it. > > I think this point is very much worth noting. We can jump up and down > all day and say some feature is really cool and beneficial, but what > really matters is whether someone will actually deploy and use it, > based on the value they see. > > Also, deploying MIP is much more complicated than deploying other IPv6 > protocol features. You need an HA and associated AAA > infrastucture. This is just for base MIP, without even getting to RO. > > To date, I am not aware of any plans to deploy MIPv6. Sure, one can > argue that we have to get IPv6 deployed first, and then folk will use > MIPv6 as well, but I think that is also simplistic thinking. I believe > deploying and using MIPv6 (and the RO functionality specifically) is > still something we lack significant experience with. > >> This is one feature of Mobile IPv6 that stands out. > > Yes. But only for those who think MIPv6 is something they want to > use. > > I think the IPv4 experience with MIPv4 suggests that there are target > scenarios where MIP technology is quite useful, but at the same time, > there is no broad general need for MIP. The vast majority of the > Internet seems to be doing Just Fine without using MIP. > >> The semantics of RO, say Type-II RH, is part of the basic IPv6 >> feature. Most IPv6 stacks have support for these options and in most >> cases the RO procedure as well. Given this, It is very important >> that the IPv6 Correspondent Node functionality is mandated on every >> IPv6 node. However, the Home Agent functionality on IPv6 routers, or >> the Mobile Node stack on a IPv6 node, can be optional, that is >> fine. But, its important that the end-points has natural RO support. > > I'm strongly opposed to mandating CN support for RO on general purpose > nodes (clients and servers) until: > > a) we have significant experience with the technology showing that it > works in practice (i.e, in significant operational deployments), and > > b) there is a more realistic sense that the technology would actually > get used, if it were available. > > MIP appears to (possibly) be a "nice to have" feature. But it is not a > critical part of IPv6. It is not the job of the IETF to broadly > mandate functionality that is not clearly necessary. > >> 2.) I'd additionally remove the comments around lack of deployment >> experience around the protocol. This comment applies to practically >> every IPv6 feature, SEND or other extensions. In fact with Mobile >> IPv4 being a core mobility protocol in CDMA, we probably have bit >> more related experience on the node requirements from IPv6 node >> perspective. > > We do not have experience with the RO part of MIP. that is new not > only to IPv6, but to IP overall. > > SEND is also (IMO) not something we can recommend. We need more real > deployment/usage experience with it before it is appropriate to > mandate it. > > Indeed, per previous discussions on this list, SEND is listed only as > a MAY in the current node requirements ID. > > Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
