Raj, IRON represents a new mobility architecture that has not been discussed here before, and it is different from MIP in many ways. IRON is currently in WGLC in the Routing Research Group, where it was developed with guidance from wg participants.
Fred [email protected] > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Friday, August 20, 2010 12:40 PM > To: Templin, Fred L; [email protected]; [email protected] > Cc: [email protected] > Subject: Re: Comments on Section 9.0 (Mobility) > -draft-ietf-6man-node-req-bis-05 > > > 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" <[email protected]> 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 > > [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 --------------------------------------------------------------------
