<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
