Did someone say Route Optimization? Here is a new routing, addressing and mobility architecture that addresses it:
http://tools.ietf.org/html/draft-templin-iron-10 This is the Internet Routing Overlay Network (IRON). Route Optimization is only one feature among many that makes IRON a comprehensive solution for the Internet going forward. Fred fred.l.temp...@boeingl.com > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > basavaraj.pa...@nokia.com > Sent: Friday, August 20, 2010 12:03 PM > To: nar...@us.ibm.com; sgund...@cisco.com > Cc: ipv6@ietf.org > Subject: Re: Comments on Section 9.0 (Mobility) > -draft-ietf-6man-node-req-bis-05 > > > > > > On 8/20/10 1:47 PM, "Thomas Narten" <nar...@us.ibm.com> wrote: > > > Sri Gundavelli <sgund...@cisco.com> 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. > > 3GPP has specified the use of DSMIP6 on the S2c reference point in Rel8. And > there do exist some plans to deploy and use DSMIP6. (Note DSMIP6 and not > just MIP6). There do exist implementations and some unadvertised trials. > > > 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. > > I tend to agree with Thomas' comments here... At least the point about RO. > There is no experience with RO and there has not been an overarching demand > for RO. > Lack of RO and the fact that the MN is anchored at an HA (which could be > quite distant from the point of attachment) has resulted in other solutions > being developed, the most relevant one being the dynamic assignment of an > HA. The MN is assigned an HA based on its current point-of-attachment and > this alleviates some of the concerns that arise from being anchored. > > I am also of the opinion that MIP6 by itself is difficult to deploy given > the lack of IPv6 only networks. And what we see is that there will be IPv4, > IPv6 and dual-stack networks out there. Hence DSMIP6 is the only pragmatic > IP mobility solution since it works over any type of access. > > I would actually go so far as to recommend that the node-requirements > mobility section substitute the MIP6 RFCs with DSMIP6 (RFC5555). > > > > >> This is one feature of Mobile IPv6 that stands out. > > While the RO is a nice feature of MIP6, its usefulness and need is only as > good as implementations and people asking for it. That is not the case at > the present time. > > > > > 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. > > There are some applications that would benefit from MIP and we will probably > see the use-cases and need for it. It is possible to solve the mobility > problem at different layers. However the IP layer mobility solution enabled > by MIP is one of the better ways (YMMV). > > > > >> 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. > > I would agree with Thomas' comments and would support not-mandating RO in > every CN for now. > > As an FYI, we are implementing RO in our DSMIP6-TLS implementation and > possibly demoing it by IETF79. > > > > > 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. > > MIP6 lost its way during the development of IPv6 and hence is not an > integral part of the IPv6 stack today. That is just an unfortunate state > that we find ourselves today. But obviously the need for such functionality > has also been lacking. > > > > >> 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. > > Agree. > > -Raj > > > > > Thomas > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
