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
