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
