Fred, We are discussing IPv6 node-requirements and considering specifications that are standards-track RFCs. There is no point in throwing out specs that are individual I-Ds at this time (at least in the context of this discussion).
-Raj On 8/20/10 2:23 PM, "ext Templin, Fred L" <fred.l.temp...@boeing.com> wrote: > 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 --------------------------------------------------------------------
