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
