On Nov 13, 2011, at 11:30 AM, liu dapeng wrote: > 2011/11/7, jouni korhonen <[email protected]>: >> >> On Nov 4, 2011, at 6:18 PM, Behcet Sarikaya wrote: >> >>> Hi all, >>> >>> I am confused about all these very high level, intelligent looking >>> comments, and I must say I am fed up with them :-). >>> >>> Non-tunneled communications is already there in DMM. You connect to the >>> nearest HA and all new communications is non-tunneled. >>> >>> Do we agree that we should differentiate client-based and network based >>> protocols and discuss them in different places? or even there is no issue >>> for one. >> >> >> IMHO I see no reason to focus only on client-based or network-based >> solutions. FWIW the DMM solution space: >> >> o is incremental to an existing IETF mobility protocol, be that client-, >> network- or even transport-based. >> o or alternatively may not depend on a specific mobility protocol at all >> i.e. non-anchored solution is also in scope. >> o solution is backward compatible in a sense that if a host or a network >> does not support DMM, nothing breaks. >> o focuses on IPv6 because anything IPv4 is just NAT-games. > > I have concern about only focuse on IPv6. IPv4 is still widely used > today, we have to consider that.
I understand this. However, the day any DMM solution hits the market can we assume that IPv4 is the protocol those new subscribers & mobiles are then mainly using? Given the minimum 2-3 year window anything penetrates the mass market we manage to define here, I hope IPv6 will have more significant role, for example, in cellular systems. - Jouni > > regards, > Dapeng > >> - Jouni >> >>> >>> I think this is what we should decide now. >>> >>> Regards, >>> >>> Behcet >>> >>> On Fri, Nov 4, 2011 at 3:19 AM, jouni korhonen <[email protected]> >>> wrote: >>> Pete, >>> >>> On Nov 4, 2011, at 3:16 AM, Pete McCann wrote: >>> >>>> A good architecture is made not only from deciding what to standardize >>>> but >>>> also from what not to standardize. >>> >>> Exactly. >>> >>> [snip] >>> >>>> >>>> Perhaps IETF could take LIPA as a starting point to design a cleaner >>>> mobility management solution. >>> >>> What came out from a certain SDO as a "Local IP Access" did not turn out >>> as the most elegant solution :) But I do agree that from the idea & >>> initial use case point of view, it definitely is something to look at.. >>> even as a basis for a cleaner design. >>> >>>> It isn't clear to me that we should even start with tunnels as a basic >>>> building >>>> block. >>> >>> I am along the same lines. See my earlier mail on the charter >>> http://www.ietf.org/mail-archive/web/mext/current/msg04905.html >>> >>> - Jouni >>> >>> >>> >>>> >>>> -Pete >>>> >>>> On Thu, Nov 3, 2011 at 8:43 PM, Hesham Soliman >>>> <[email protected]> wrote: >>>>> Hi Charlie, >>>>> >>>>> I agree completely with you on the problems with the current interfaces >>>>> in >>>>> LTE, and in 3G before that. >>>>> I don't know what the best way to go about it would be. I say this >>>>> because >>>>> many people on this list are aware of what's happening in LTE and >>>>> presumably have similar opinions about the complexity of their >>>>> solutions, >>>>> but it's still there. >>>>> >>>>> Hesham >>>>> >>>>> -----Original Message----- >>>>> From: "Charles E. Perkins" <[email protected]> >>>>> Organization: Wichorus Inc. >>>>> Date: Thu, 03 Nov 2011 10:49:21 -0700 >>>>> To: Jari Arkko <[email protected]> >>>>> Cc: <[email protected]>, <[email protected]> >>>>> Subject: Re: [MEXT] the future of the MEXT working group >>>>> >>>>>> Hello folks, >>>>>> >>>>>> For several years now, I have been studying 4G wireless >>> >>> [snap] >>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> _______________________________________________ >> MEXT mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/mext >> > > > -- > > ------ > Best Regards, > Dapeng Liu _______________________________________________ MEXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/mext
