Shuai, Thanks and I am correcting it in the next version.
H Anthony Chan -----Original Message----- From: Shuai Gao [mailto:[email protected]] Sent: Sunday, July 01, 2012 10:13 PM To: h chan Cc: [email protected] Subject: Re: Re: [DMM] draft requirement discussions Hi Anthony, There is a little typo in page 11. "opti-in or opt-out" ---> "opt-in or opt-out" Shuai ======= 2012-06-15 17:05:10 您在来信中写道：======= ><co-chair mode> > >Thanks Anthony. The discussion around the requirements have >stabilized quite a bit, which is good. This I-D is a good >basis & candidate for the requirement document we have in our >milestones. > >I encourage folks to start looking at gaps to existing (and >deployed) technologies based on these requirements. We will >spend time on those during the WG meeting anyway. > >- Jouni > > > >On Jun 15, 2012, at 5:14 AM, h chan wrote: > >> The draft has been updated with the recommended changes. >> http://www.ietf.org/id/draft-chan-dmm-requirements-02.txt >> >> H Anthony Chan >> >> -----Original Message----- >> From: jouni korhonen [mailto:[email protected]] >> Sent: Monday, June 11, 2012 8:49 AM >> To: h chan >> Cc: [email protected] >> Subject: Re: [DMM] draft requirement discussions >> >> >> Anthony, >> >> Thanks for the update. While the requirements start shaping up >> nicely I have few documentation related issues. First, Section 1 >> does not need to repeat DMM WG charter and milestones. Second, >> Section 4 does not belong to this requirement document. The draft >> already has rather lengthy intro, which is more than enough as a >> background information. >> >> - Jouni >> >> On Jun 8, 2012, at 8:59 AM, h chan wrote: >> >>> A draft of the requirement capturing all the requirements so far together >>> with the problem statements has been uploaded: >>> >>> http://www.ietf.org/id/draft-chan-dmm-requirements-01.txt >>> >>> The following is an explanation of how it is structured. >>> >>> Out of the large number of problem statements, Session 4 on problem >>> statement listed 5 of them as relevant problems. >>> >>> In Session 5 on requirements, the first 2 requirements address all the >>> relevant problems. They distinguish dmm from the existing centralized >>> deployments. So I think they are the key requirements. They both use "SHALL" >>> >>> The remaining requirements are not owing to problem statements with >>> existing centralized deployments. So I suggest to use the "SHALL" very >>> sparingly. Else we may not be able to call even some existing mobility >>> protocols a mobility management solution lest they meet all the "SHALL" >>> requirements. >>> >>> H Anthony Chan >>> >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Charles E. Perkins >>> Sent: Thursday, June 07, 2012 4:52 PM >>> To: Peter McCann >>> Cc: [email protected]; Behcet Sarikaya >>> Subject: Re: [DMM] draft requirement discussions >>> >>> >>> Hello Pete, >>> >>> Yes, I am fine with that revision and the new proposed text. >>> >>> I was more worried about the seeming suggestion that the DMM >>> requirement was to interwork with any arbitrary security >>> mechanism. But, as I mentioned, I think we are pretty close. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 6/7/2012 1:53 PM, Peter McCann wrote: >>>> I thought the new text from Anthony was an attempt to answer your >>>> comment, Charles. For instance, he removed the text that said, >>>> "should not be considered the default." Are you ok with his new >>>> proposed text? If not, can you propose text that you would like? >>>> >>>> -Pete >>>> >>>> Charles E. Perkins wrote: >>>>> Hello folks, >>>>> >>>>> It seems to me that we may be perhaps arriving at a good point for a >>>>> new draft. >>>>> However, there are still some points of discussion that are perhaps >>>>> worthy to be resolved (for example, in my email earlier this week). >>>>> >>>>> Maybe we should fire up the issue tracker...? >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> On 6/7/2012 12:04 PM, Behcet Sarikaya wrote: >>>>> >>>>> Hi Jouni, >>>>> >>>>> What are the plans on DMM requirements? I see lots of mails and never >>>>> ending discussions. >>>>> >>>>> Isn't it the time to get the draft out, thank Anthony for his hard >>>>> work and move on? >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> >>>>> On Wed, Jun 6, 2012 at 11:32 AM, h chan <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> Yes, the second and third sentences are not additional >>>>> requirements, >>>>> but rather explanations of the requirement in the first sentence. Does >>>>> the rewrite sound better now: >>>>> >>>>> >>>>> >>>>> REQ-2: Transparency to Upper Layers >>>>> >>>>> The DMM solutions SHALL provide transparency above the IP layer >>>>> when >>>>> needed. Such transparency is needed, when the mobile hosts or entire >>>>> mobile networks change their point of attachment to the Internet, for >>>>> the application flows that cannot cope with a change of IP address. >>>>> Otherwise the support to maintain a stable home IP address or prefix >>>>> during handover may be declined. >>>>> >>>>> >>>>> >>>>> H Anthony Chan >>>>> >>>>> >>>>> >>>>> From: [email protected] [mailto:[email protected]] >>>>> Sent: Wednesday, June 06, 2012 12:56 AM >>>>> To: h chan >>>>> Cc: [email protected]; [email protected]; jouni korhonen; Peter >>>>> McCann >>>>> Subject: 答复: Re: [DMM] draft requirement REQ-2: >>>>> Transparency to Upper Layers >>>>> >>>>> >>>>> >>>>> >>>>> Hi Anthony: >>>>> >>>>> The last part of the sentence (i.e. but the need to maintain a >>>>> stable home IP address or prefix SHOULD NOT be taken as >>>>> default.) seems a littel strange to me. REQ-2 just describes under >>>>> what circumstances the transparency is needed (i.e. when the mobile >>>>> hosts or entire mobile networks change their point of attachment to >>>>> the Internet, for the application flows that cannot cope with a change >>>>> of IP address), that means automatically, otherwise the transparency >>>>> is not needed. So why bother to write the last part of the sentence？ >>>>> >>>>> Besides, when mobile node attaches to its home network, it will >>>>> obviously get a home IP address/prefix from its home network. The IP >>>>> address/prefix can be considered as stable IP, as long as the mobile >>>>> does not change its point of attachment. The last part of the sentence >>>>> will just exclude this scenario. >>>>> >>>>> If I make any mistake, please correct me. >>>>> >>>>> Thanks >>>>> Luowen >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> h chan <[email protected]> >>>>> 发 件人: [email protected] >>>>> >>>>> 2012/06/06 01:12 >>>>> >>>>> 收件人 >>>>> >>>>> "[email protected]" <[email protected]>, Peter McCann <[email protected]>, >>>>> jouni korhonen <[email protected]> >>>>> >>>>> 抄送 >>>>> >>>>> >>>>> >>>>> 主题 >>>>> >>>>> Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Revise as follows: >>>>> >>>>> REQ-2: Transparency to Upper Layers >>>>> The DMM solutions SHALL provide transparency above the IP layer >>>>> when >>>>> needed. Such transparency is needed, when the mobile hosts or entire >>>>> mobile networks change their point of attachment to the Internet, for >>>>> the application flows that cannot cope with a change of IP address, >>>>> but the need to maintain a stable home IP address or prefix SHOULD NOT >>>>> be taken as default. >>>>> REQ-2M (Motivation for REQ-2) >>>>> The goal of this requirement is to enable more efficient use of >>>>> network resources and more efficient routing by not maintaining a >>>>> stable IP home IP address when there is no such need. >>>>> >>>>> H Anthony Chan >>>>> >>>>> >>>>> -----Original Message----- From: >>>>> [email protected] >>>>> [mailto:[email protected]] On Behalf Of h chan Sent: >>>>> Wednesday, May >>>>> 23, 2012 7:51 PM To: Peter McCann; jouni korhonen >>>>> Cc: [email protected] >>>>> Subject: Re: [DMM] draft requirement REQ-2: Transparency to >>>>> Upper >>>>> Layers >>>>> >>>>> An attempt to clean up the text so far: >>>>> >>>>> REQ-2: Transparency to Upper Layers >>>>> The DMM solutions SHALL provide transparency above the IP layer >>>>> when >>>>> needed. Such transparency is needed, when the mobile hosts or entire >>>>> mobile networks change their point of attachment to the Internet, for >>>>> the application flows that cannot cope with a change of IP address, >>>>> but SHOULD NOT be taken as the default behavior. >>>>> >>>>> REQ-2M (Motivation for REQ-2) >>>>> The goal of this requirement is to enable more efficient use of >>>>> network resources and more efficient routing when mobility support is >>>>> implemented by not invoking it for the application flows and nodes >>>>> that do not need it. >>>>> >>>>> RELEVANT problem: PS5: Wasting resources to >>>>> support mobile nodes not >>>>> needing mobility support IP mobility support is not always >>>>> required. >>>>> For example, some applications do not need a stable IP address during >>>>> handover, i.e. IP session continuity. Sometimes, the entire >>>>> application session runs while the terminal does not change the point of >>>>> attachment. >>>>> In these situations that do not require IP mobility support, network >>>>> resources are wasted when including additional info to the mobility >>>>> context to support the change the point of attachment. Network >>>>> resources are also wasted when the via routes are set up for many MNs >>>>> that do not >>>>> require IP mobility support. OTHER related problem >>>>> O-PS1: Mobility >>>>> signaling overhead with peer-to-peer communication While >>>>> mobility >>>>> management enables a mobile host to be reachable, the hosts may then >>>>> communicate directly so that the mobility support is no longer needed. >>>>> Taking the need of mobility support as the default behavior will waste >>>>> network resources. O-PS2: Lack of user-centricity >>>>> Centralized >>>>> deployment compared with distributed mobility management may be less >>>>> capable to support user-centricity. Example in the lack of >>>>> user-centricity is to provide mobility support to all mobile nodes by >>>>> default regardless of whether the user needs it or not. >>>>> >>>>> H Anthony Chan >>>>> >>>>> -----Original Message----- From: Peter McCann >>>>> Sent: Friday, May >>>>> 18, 2012 9:35 AM To: jouni korhonen; h chan Cc: >>>>> [email protected] >>>>> Subject: RE: [DMM] draft requirement REQ-2: Transparency to >>>>> Upper >>>>> Layers >>>>> >>>>> Hi, Jouni, >>>>> >>>>> jouni korhonen wrote: > > Few >>>>> comments/questions here: > > On >>>>> May 7, 2012, at 8:58 PM, h chan wrote: > >> >>>>> REQ-2: Transparency to >>>>> Upper Layers >> The DMM solutions SHALL enable transparency >>>>> above the >>>>> IP layer. Such >> transparency is needed for the application >>>>> flows >>>>> that cannot cope with >> a change of IP address and when >>>>> mobile hosts >>>>> or entire mobile networks >> change their point of >>>>> attachment to the >>>>> Internet, but SHOULD NOT be >> taken as the default >>>>> behavior. > > >>>>> "SHALL enable" but "SHOULD NOT be taken as the default behavior" seem >>>>> > to conflict. So, what is really meant here? Does this mean >>>>> something >>>>> > like "MUST implement, SHOULD use" type of solution? Or can >>>>> one leave >>>>> > transparency completely away if the applications/hosts just >>>>> don't >>>>> care > whether IP changes or not? >>>>> >>>>> I think the latter. If the applications don't care about >>>>> transparency, then we don't need to pay for it with state and >>>>> signaling in the network. >>>>> >>>>> However, we know that some applications do care, so it SHALL be >>>>> possible to provide it. >>>>> >>>>> >> REQ-2M (Motivation for REQ-2) >> The goal of >>>>> this requirement is >>>>> to >> enable more efficient use of network resources and >>>>> more >>>>> efficient >> routing by not invoking mobility support >>>>> when there is no >>>>> such need. > > Does this still mean the >>>>> mobility support must be >>>>> implement even if it > is not used? >>>>> >>>>> We need some strategy for keeping an IP address through some >>>>> amount of >>>>> mobility. However, we needn't optimize the network for this >>>>> case as >>>>> it might be rather uncommon to keep an address for a very >>>>> long period >>>>> of time. >>>>> >>>>> >> RELEVANT problem: >> PS5: Wasting resources to >>>>> support mobile >>>>> nodes not needing mobility >> support IP mobility support >>>>> is not >>>>> always required. For example, >> some >> >>>>> applications do not need a >>>>> stable IP address during handover, i.e. IP >> session >>>>> continuity. >>>>> Sometimes, the entire application session runs >> while the >>>>> terminal >>>>> does not change the point of attachment. In these >> >>>>> situations that >>>>> do not require IP mobility support, network resources >> are >>>>> wasted >>>>> when mobility context is set up. Network resources are also >>>>> >> wasted >>>>> when the via routes are set up for many MNs that do not require >>>>> >> IP >>>>> mobility support. >> >> OTHER related >>>>> problem >> O-PS1: Mobility >>>>> signaling overhead with peer-to-peer communication >> >>>>> While mobility >>>>> management enables a mobile host to be reachable, the >> >>>>> hosts may >>>>> then communicate directly so that the mobility support is no >>>>> >> longer >>>>> needed. Taking the need of mobility support as the default >>>>> >> behavior >>>>> will waste network resources. >> O-PS2: Lack of >>>>> user-centricity >> >>>>> Centralized deployment compared with distributed mobility management >>>>> >> may be less capable to support user-centricity. Example in >>>>> the lack >>>>> of >> user-centricity is to provide mobility support to >>>>> all mobile >>>>> nodes by >> default regardless of whether the user needs it or >>>>> not. >>>>> > > I have issues to parse O-PS2.. the motivation >>>>> makes sense though >>>>> but > the title "lack of user-centricity" is somewhat >>>>> confusing.. what >>>>> does > forced/always-on mobility support has to do with user >>>>> centricity? >>>>> >>>>> I think Anthony just meant that we should tailor the mobility >>>>> management to the needs of the user. I wouldn't mind >>>>> seeing this >>>>> explanatory text re-worded. >>>>> >>>>> -Pete >>>>> >>>>> > > - Jouni > > >>>>> >> >> (The above has been drafted with >>>>> contributions, inputs and discussions >> from various people. >>>>> Additional contributions and comments are most >> welcome.) >>>>> >> >> >>>>> H Anthony Chan >> >> >> >>>>> _______________________________________________ >> dmm mailing >>>>> list >>>>> >> [email protected] >> >>>>> https://www.ietf.org/mailman/listinfo/dmm > > >>>>> _______________________________________________ > dmm mailing >>>>> list > >>>>> [email protected] > https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmm >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmm >> > >_______________________________________________ >dmm mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dmm = = = = = = = = = = = = = = = = = = = = 致 礼！ Shuai Gao National Engineering Lab for Next Generation Internet Interconnection Devices Beijing Jiaotong University Beijing, China, 100044 [email protected] 2012-07-02 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
