RE: Comments on Section 9.0 (Mobility)-draft-ietf-6man-node-req-bis-05

["Templin, Fred L" <[e-mail]>]

To add to this, RFC5522 makes the case for a route optimization
solution for civil aviation and space exploration.

Fred
[e-mail]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Templin, Fred L
> Sent: Friday, August 20, 2010 12:24 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
> > Sent: Friday, August 20, 2010 12:03 PM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: Comments on Section 9.0 (Mobility) -draft-ietf-6man-node-req-bis-05
> >
> >
> >
> >
> >
> > On 8/20/10 1:47 PM, "Thomas Narten" <[e-mail]> wrote:
> >
> > > Sri Gundavelli <[e-mail]> 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
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------