To add to this, RFC5522 makes the case for a route optimization solution for civil aviation and space exploration.
Fred [email protected] > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Templin, Fred L > Sent: Friday, August 20, 2010 12:24 PM > To: [email protected]; [email protected]; [email protected] > Cc: [email protected] > Subject: RE: Comments on Section 9.0 > (Mobility)-draft-ietf-6man-node-req-bis-05 > > 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 > [email protected] > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > [email protected] > > Sent: Friday, August 20, 2010 12:03 PM > > To: [email protected]; [email protected] > > Cc: [email protected] > > Subject: Re: Comments on Section 9.0 (Mobility) > > -draft-ietf-6man-node-req-bis-05 > > > > > > > > > > > > On 8/20/10 1:47 PM, "Thomas Narten" <[email protected]> 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. > > > > 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 > > > [email protected] > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
