Hi Sri, > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Thursday, June 19, 2014 1:32 PM > To: Templin, Fred L; Brian Haberman; [email protected] > Subject: Re: [DMM] draft charter text updates in github.. > > Hi Fred, > > Ack on the AERO capability.
OK. > I have come to the conclusion that I have to deal with IPv4 for the rest > of my career (assuming some left). Surely, some day in 2016 is not some > thing that I'm looking at. My point is to limit the solution scope and if > it happens that DMM solution is immensely successful, we can introduce > IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred [email protected] > Regards > Sri > > > > > > > > > > On 6/19/14 12:54 PM, "Templin, Fred L" <[email protected]> wrote: > > >Hi Sri, > > > >I will just repeat that AERO works equally well on IPv4-only, IPv6-only > >and dual-stacked access networks. This means that it can address real > >world use cases today that cannot be addressed by other mechanisms. > > > >As to schedule, who can truly say when IPv4 will be totally gone from > >all access networks? 2016 is just a date on a calendar; we have been > >waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT > >it still hasn't happened. > > > >Thanks - Fred > >[email protected] > > > >> -----Original Message----- > >> From: Sri Gundavelli (sgundave) [mailto:[email protected]] > >> Sent: Thursday, June 19, 2014 12:33 PM > >> To: Templin, Fred L; Brian Haberman; [email protected] > >> Subject: Re: [DMM] draft charter text updates in github.. > >> > >> Hi Fred, > >> > >> The DMM WG is still discussing PS and the related issues. By the time we > >> adopt a solution and complete the work, we will surely be in 2016. So, > >>is > >> it not safer to raise the bar and limit certain interfaces to IPv6-only > >>? > >> I'm not arguing against adding any support for IPv4, but IMO the bar > >> should be high. We can certainly support all possible types of networks, > >> IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, > >> looking at our current pace and doing some extrapolation, its safe to > >>say > >> we will bake this for a long time and so limiting the work scope IMO > >> helps. But, this is just my opinion/comment and personally don't care if > >> some one wants to do the work and the chairs/AD/WG agree with it. Also, > >>I > >> do not know yet how much of the solution work will really be IP-version > >> dependent. Mostly some network interfaces and there IPv6 possibly is a > >> safe assumption. > >> > >> > >> Regards > >> Sri > >> > >> > >> > >> > >> > >> > >> On 6/19/14 11:30 AM, "Templin, Fred L" <[email protected]> > >>wrote: > >> > >> >Hi Sri, > >> > > >> >> -----Original Message----- > >> >> From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli > >> >>(sgundave) > >> >> Sent: Thursday, June 19, 2014 11:20 AM > >> >> To: Brian Haberman; [email protected] > >> >> Subject: Re: [DMM] draft charter text updates in github.. > >> >> > >> >> Agree. We should ensure the base solution supports IPv6 transport and > >> >>user > >> >> sessions. Optionally, support for IPv4 can be allowed on certain > >> >> interfaces, but clearly should not deal with IPv4, NAT's or allow > >> >> IPv4-only solutions. > >> > > >> >I don't understand that. In my enterprise, I have IPv4-only wireless > >> >access points yet there are IPv6 services within the enterprise. When > >> >I switch over to 4G wireless, I again get IPv4-only access but again > >> >there are IPv6 services within the enterprise. > >> > > >> >If the mobility management mechanism supports IPv6 over IPv4 tunneling > >> >(possibly including NATs in the path), then the use case is satisfied; > >> >otherwise, the use case is not satisfied. > >> > > >> >Thanks - Fred > >> >[email protected] > >> > > >> >> Regards > >> >> Sri > >> >> > >> >> > >> >> > >> >> On 6/18/14 8:43 AM, "Brian Haberman" <[email protected]> > >>wrote: > >> >> > >> >> >Hi Fred, > >> >> > > >> >> >On 6/18/14 11:25 AM, Templin, Fred L wrote: > >> >> >> Hi Jouni, > >> >> >> > >> >> >>> -----Original Message----- > >> >> >>> From: Jouni Korhonen [mailto:[email protected]] > >> >> >>> Sent: Wednesday, June 18, 2014 3:00 AM > >> >> >>> To: Templin, Fred L; [email protected] > >> >> >>> Subject: Re: [DMM] draft charter text updates in github.. > >> >> >>> > >> >> >>> Fred, > >> >> >>> > >> >> >>> It is true IPv4 is there (and will be for a long time). Although > >>the > >> >> >>> charter does emphasize IPv6 as the base solution it does not > >> >>prohibit > >> >> >>> adding IPv4 support. It is just we can accept an IPv6-only > >>solution > >> >>as > >> >> >>>a > >> >> >>> valid & complete solution from DMM point of view. > >> >> >> > >> >> >> However, a solution that works equally well whether the access > >> >>networks > >> >> >> are IPv6-only, dual-stack, or IPv4-only has clear advantages in > >>terms > >> >> >> of near-term deployment in real networks. Therefore, I think the > >> >>charter > >> >> >> is currently saying _too much_. My new proposal is simply to > >>strike > >> >>the > >> >> >> following two sentences: > >> >> >> > >> >> >> "DMM solutions are primarily targeted at IPv6 deployments and > >> >> >> should not be required to support IPv4, specifically in > >>situations > >> >> >> where private IPv4 addresses and/or NATs are used. IPv6 is > >> >> >> assumed to be present in both the mobile host/router and the > >> >> >> access networks." > >> >> >> > >> >> > > >> >> >The above has been a part of the DMM charter for a long time. > >>Taking > >> >>it > >> >> >out would appear to be opening the door for IPv4-only solutions. My > >> >> >assessment of the winds within the community is that people are not > >> >> >interested in new protocols for IPv4. > >> >> > > >> >> >Just my opinion... > >> >> > > >> >> >Brian > >> >> > > >> >> > >> >> _______________________________________________ > >> >> dmm mailing list > >> >> [email protected] > >> >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
