Re: [MEXT] the future of the MEXT working group

[<[e-mail]>]

Thanks Jari. Sounds reasonable.
Will provide additional comments on the proposed charter separately.

-Basavaraj

On 10/31/11 3:44 PM, "ext Jari Arkko" <[e-mail]> wrote:

>Basavaraj,
>
>It is a recharter (and a rename). We are not considering taking on
>significant amount of new work (mostly just removing material from the
>charter), so I do not think a BOF is needed.
>
>There has been little need to do work on the other extensions, and slow
>progress with the specifications that do exist. I think we completed the
>work that was easy to do and had demand. I think we should leave the rest
>behind. As noted in the other e-mails, I can AD sponsors docs outside the
>WGs directly to RFC. If there's something big that requires WG
>discussion, we can always create new working groups later. For instance,
>if after some time the various security alternates get enough traction,
>we could consider creating a working group to standardize one.
>
>Jari
>
>On 31.10.2011 22:35, [e-mail] wrote:
>> Okay..
>> Then I would hope that the rechartering does not throw out "the baby
>>with the bathwater" and keep MIP6/DSMIP6 related extensions and features
>>still in scope.
>>
>> -Raj
>>
>> -----Original Message-----
>> From: ext Julien Laganier [mailto:[e-mail]]
>> Sent: Monday, October 31, 2011 3:33 PM
>> To: Patil Basavaraj (Nokia-CIC/Dallas)
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [MEXT] the future of the MEXT working group
>>
>> Hi Raj,
>>
>> This is a rechartering of the WG.
>>
>> --julien
>>
>> On Mon, Oct 31, 2011 at 7:47 AM,<[e-mail]>  wrote:
>>>
>>> Hi Jari,
>>>
>>>
>>>
>>> A couple of quick questions:
>>>
>>>
>>>
>>> 1.       Is this a recharter of the MEXT WG or the formation of a new
>>> WG to deal with DMM? If it is the latter I would be concerned that a
>>> WG is being formed without going through the IETF BoF process. I
>>> realize that DMM was in the scope of the MEXT WG. But proposed new
>>> charter pretty much throws everything else w.r.t MIP6/DSMIP6 out of
>>>this new WG.
>>>
>>> 2.       There needs to be a WG and home for continued work w.r.t
>>> improvements to MIP6/DSMIP6 protocol in terms of extensions,
>>> deployability improvements etc. The proposed charter does not consider
>>>this at all.
>>>
>>>
>>>
>>> -Basavaraj
>>>
>>>
>>>
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of ext Jari Arkko
>>> Sent: Friday, October 28, 2011 7:21 AM
>>> To: [e-mail]
>>> Subject: Re: [MEXT] the future of the MEXT working group
>>>
>>>
>>>
>>> And a follow-up on the charter. I'm describing a couple of different
>>> takes on what the new charter could be. Comments and alternative
>>> proposals are welcome. This is what the current charter says about DMM:
>>>
>>>
>>>    The working group will also work on operational considerations on
>>>    setting up Mobile IPv6 networks so that traffic is distributed
>>>    in an optimal way, for instance by using existing protocol
>>> mechanisms
>>>    to select the closest home agents for new clients.
>>>
>>>    Oct 2011 - Submit I-D 'Operational considerations for distributed
>>> use of Mobile IPv6' for publication as Informational.
>>>
>>> Which is admittedly a bit short, but is also very concrete and
>>> achievable, if we work on it. I got another proposal from Hui Deng
>>> that extended this a bit, including going beyond mere operational
>>>considerations.
>>>
>>>
>>> In the past decade a fair number of mobility protocols have been
>>> standardized. Although the protocols differ in terms of functions and
>>> associated message format, we can identify a few key common features:
>>> presence of a centralized mobility anchor providing global
>>> reachability and an always-on experience extensions to optimize
>>> handover performance while users roam across wireless cells extensions
>>> to enable the use of heterogeneous wireless interfaces for multi-mode
>>> terminals (e.g. cellular phones) The presence of the centralized
>>> mobility anchor allows a mobile device to be reachable when it is not
>>> connected to its home domain. The anchor, among other tasks, ensures
>>> forwarding of packets destined to or sent from the mobile device. As
>>> such, most of the deployed architectures today have a small number of
>>> centralized anchors managing the traffic of millions of mobile
>>> subscribers.
>>>
>>> To optimize handovers for mobile users, the base protocols have been
>>> extended to efficiently handle packet forwarding between the previous
>>> and new points of attachment. These extensions are necessary when
>>> applications impose stringent requirements in terms of delay. Notions
>>> of localization and distribution of local agents have been introduced
>>> to reduce signalling overhead. Unfortunately today we witness
>>> difficulties in getting such protocols deployed, often leading to
>>> sub-optimal choices. Moreover, all the availability of multi-mode
>>> devices and the possibility to use several network interfaces
>>> simultaneously have motivated the development of more new protocol
>>>extensions.
>>>
>>> Mobile users are, more than ever, consuming Internet content, and
>>> impose new requirements on mobile core networks for data traffic
>>> delivery. When this traffic demand exceeds available capacity, service
>>> providers need to implement new strategies such as selective traffic
>>> offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access
>>> networks (e.g. WLAN). Moreover, the localization of content providers
>>> closer to the Mobile/Fixed Internet Service Providers network requires
>>> taking into account local Content Delivery Networks (CDNs) while
>>>providing mobility services.
>>>
>>> As long as demand exceeds capacity, both offloading and CDN techniques
>>> could benefit from the development of more flat mobile architectures
>>> (i.e., fewer levels of routing hierarchy introduced into the data path
>>> by the mobility management system). This view is reinforced by the
>>> shift in users' traffic behaviour, aimed at increasing direct
>>> communications among peers in the same geographical area. The
>>> development of truly flat mobile architectures would result in
>>> anchoring the traffic closer to point of attachment of the user and
>>> overcoming the suboptimal routing issues of a centralized mobility
>>>scheme.
>>>
>>> While deploying today's mobile networks, service providers face new
>>> challenges. More often than not, mobile devices remain attached to the
>>> same point of attachment, in which case specific IP mobility
>>> management support is not required for applications that launch and
>>> complete while connected to the same point of attachment. However, the
>>> mobility support has been designed to be always on and to maintain the
>>> context for each mobile subscriber as long as they are connected to
>>> the network. This can result in a waste of resources and
>>>ever-increasing costs for the service provider.
>>> Infrequent mobility and intelligence of many applications suggest that
>>> mobility can be provided dynamically, thus simplifying the context
>>> maintained in the different nodes of the mobile network.
>>>
>>> The proposed charter will address two complementary aspects of
>>> mobility management procedures: the distribution of mobility anchors
>>> to achieve a more flat design and the dynamic activation/deactivation
>>> of mobility protocol support as an enabler to distributed mobility
>>> management. The former has the goal of positioning mobility anchors
>>> (HA, LMA) closer to the user; ideally, these mobility anchors could be
>>> collocated with the first hop router. The latter, facilitated by the
>>> distribution of mobility anchors, aims at identifying when mobility
>>> must be activated and identifying sessions that do not impose mobility
>>> management -- thus reducing the amount of state information to be
>>> maintained in the various mobility anchors of the mobile network. The
>>> key idea is that dynamic mobility management relaxes some constraints
>>> while also repositioning mobility anchors; it avoids the establishment
>>> of non optimal tunnels between two anchors topologically distant.
>>>
>>> Considering the above, the working group will:
>>>
>>> Define the problem statement and associated requirements for
>>> distributed mobility management. This work aims at defining the
>>> problem space and identifies the key functional requirements.
>>>
>>> Produce a gap analysis mapping the above requirements against existing
>>> solutions.
>>>
>>> Give best practices for the deployment of existing mobility protocols
>>> in a distributed mobility management and describe limitations of each
>>> such approach.
>>>
>>> Describe extensions, if needed, to current mobility protocols for
>>> their application in distributed mobility architectures
>>>
>>> Comments?
>>>
>>> Jari
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>>>
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>
>_______________________________________________
>MEXT mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mext