We got a charter item for what Rajeev is asking for
Aug 2012 - Submit I-D 'Practices and Gap Analysis' as a working
group document. To be Informational RFC.
What is though in my head (in Finnish we have saying with pun
intended that translates as "I was thinking while being drunk" ;)
is that we need a set of requirements that folks has and then
project them into a gap analysis which should be exactly what
Rajeev is asking for, right? So, we could have a set of requirements
documented and then gap analysis concluding there is nothing
what (H|F|DS)MIP6 would do with a tweak or two or none.
- Jouni
On May 18, 2012, at 5:36 PM, Peter McCann wrote:
> Hi,
>
> I think MIP6 and derivatives could very well be a part of the solution.
> However, we need to place them into scenarios where the anchors are
> allocated dynamically on an as-needed basis and garbage collected when
> they are no longer needed. This may introduce some new requirements.
>
> -Pete
>
> Rajeev Koodli wrote:
>>
>> Hi Jouni, All,
>>
>> Sorry if this has been captured before..
>>
>> Shouldn't there be a very basic requirement that should first outline
>> why MIP6 and derivatives could not be deployed in scenarios suitable for
>> DMM? I reckon this assumes a clear description of what DMM is exists.
>>
>> Thanks.
>>
>> -Rajeev
>>
>>
>>
>> On 5/17/12 4:56 PM, "jouni korhonen" <[email protected]> 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?
>>>
>>>>
>>>> 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?
>>>
>>>>
>>>> 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?
>>>
>>> - 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
