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

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Oct 2011 15:08:42 +0300

All,

We are making some changes to the working group. While we have successfully published a large number of specifications in recent years, recently it has been difficult to make progress in the group. The chairs and ADs have looked at the situation and we believe we need a new focus and a bit of new organization as well. We are terminating the working group and moving the one remaining active work item to a new working group, the "DMM" working group. Here's what is going to happen:

o  Jouni Korhonen and Julien Laganier will become the chairs of the group.

o  The group will meet in Taipei (there is a MEXT slot in the agenda).

o  The charter of the group will be changed to focus only on the distributed mobility effort. We should discuss the details of this charter change both on the list and in the meeting. The meeting agenda should reserve some time both for technical discussions as well as the charter discussion.

o  Once the discussion on the list and in the meeting has finished, we will rename the group to "DMM" and put the new charter in effect.

o  If there are any other specifications that people would like to publish beyond the distributed mobility work, we can offer to AD sponsor them to RFCs outside the new working group. If there is some significant new activity, we can create new working groups for that.

Comments and feedback and/or alternate suggestions on this plan are welcome.

We would like to thank Marcelo for your many years of service in MEXT. We could not have completed all the work we did without your energy and push for high quality results. We would also like to thank Jouni for taking on this new challenge, and Julien for continuing the work in this space.

Jari and Ralph

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Oct 2011 15:21:08 +0300

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 28 Oct 2011 11:08:49 -0500

Hi Jari,
  My comments inline.

Regards,

Behcet
On Fri, Oct 28, 2011 at 7:21 AM, Jari Arkko <[email-masked]> wrote:

>  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
>   in an optimal way, for instance by using existing protocol mechanisms
>   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.
>

Agreed. I may suggest adding a requirements draft charter item in order to
scope the work better.

> 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.
>
> 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
>
>
> This proposal has some nice features like PS and requirements. I believe
gap analysis is more like an SDO work and not done much in IETF. Also my
main concern is the existing mobility protocols. Since there are many of
these protocols, I believe such a scope is too wide for esp. a new WG.

---

From: Hui Deng <[email-masked]>
Date: Sat, 29 Oct 2011 01:51:38 +0800

I just want to mention that the proposal coming from DMM Interesting group
which is orginally organized by Dapeng Liu and other contributors all
together.

-Hui

2011/10/28 Jari Arkko <[email-masked]>

> if we work on it. I got another proposal from Hui Deng that extended this a
> bit, including going beyond mere operational considerations.
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 30 Oct 2011 13:23:10 +1100

Hi Jari, All,

Some comments inline.

>    that extended this a bit, including going beyond mere operational

=> I think that's clear, with the exception of some possible aesthetic
improvements.

>      centralized anchors managing the traffic of millions of mobile

=> This really sounds like a lot of ambiguity, can't we just say that
[flow mobility], [HMIPv6] and [FMIPv6] were introduced to optimise
mobility? This paragraph can be written in two sentences.

>      of delay. 

=> I don't think this style is needed for a charter. The last sentence is
incorrect anyway. TCP suffers from mobility disruptions.

>Notions of localization and distribution of local agents
>      often leading to sub-optimal choices.

=> What is the point of this part? Seems like it has no effect on the work
unless we have a consensus on why it is difficult to introduce those
protocols. Bear in mind that IPv6 is still not widely used and MIPv4 was
hardly used outside one mobile network in the US. Isn't the real reason
for not deploying IP mobility that the 3G networks were designed to not
need IP mobility? If so, then one can't come to a conclusion that those
protocols like FMIP, HMIP, flow mobility..etc are too difficult to deploy
because they were not seriously tried and that's because they were not
seriously needed. I.e. in the 3G architecture, nothing is "broken" without
them. 

>Moreover, all the
>      is reinforced by the shift in users¹ traffic behaviour, aimed at
>      While deploying today¹s mobile networks, service providers face

=> So reading this last paragraph tells me that Mobile IPv6 is actually
not needed (regardless of whether one agrees with that or not). So why
would any work item take place in MEXT? The overheads described are not
quantified or proven to be substantial for an operator. What are the
overheads? Storing a binding? If the mobile node doesn't move, there is no
signalling so what's the cost?
  
>      to distributed mobility management.

=> But this sounds like introducing more complexity while maintaining the
same overheads? MEaning, if you're still keeping anchors, then you still
have the overheads you complain about, but then you add complexity by
trying to over-optimise the turning on and off of mobility management.
Sounds like extra work for no benefit.

>The former has the goal of

=> Yes but that was only one of the complaints about the current mobility
management. The other was overheads of anchors. So having the anchor
closer doesn't solve that problem.

>      their application in distributed mobility architectures

=> Yes a few comments:
- As a stylistic matter, the text should just say what it needs done
quickly and concisely.
- Substantively, the text lists two key problems: 1) being able to
allocate anchors close to the MN so that content caches can be allocated
based on the MN's location and 2) Anchors introduce overheads.
Seems to me that 2) makes 1) irrelevant because if you remove the anchors
then you no longer need to worry about efficient allocation.

1) is something that someone who read the protocol and is a good systems
engineer can fix by making sure that the anchors are allocated and
advertised correctly to the MN (using HMIP as an example here). I can see
that people might want to have different mechanisms for allocating anchors
but then just say that clearly and describe why.

I think if the work item is:
- Develop best practices and mechanisms to efficiently allocate mobility
anchors to mobile nodes in a manner that is optimised for the mobile
node's geo-location.

Then that's clear and fine as an item, but I think the long version above
goes around in circles and I don't see a clear consequential problem to be
solved other than the bullet above.

Hesham

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 14:47:01 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Jari Arkko
Sent: Friday, October 28, 2011 7:21 AM
To: [email-masked]
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:

  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.

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

---

From: Hui Deng <[email-masked]>
Date: Tue, 1 Nov 2011 00:00:08 +0800

Hi Raj,

>From my reading of the AD's email,
1. DMM has been already in mext charter before, I don't see why we need BOF
process, it is just about rechartering.
2. AD has already said that other left work could be sponsored by AD, so it
doesn't kick out any extension of MIP6/DSMIP6 if there is.

Thanks

-Hui

2011/10/31 <[email-masked]>

>  ** **
>
> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Jari Arkko
> *Sent:* Friday, October 28, 2011 7:21 AM
> *To:* [email-masked]
> *Subject:* Re: [MEXT] the future of the MEXT working group****
>
> ** **
>
> ****
> Mobile IPv6' for publication as Informational.****
>
>
> ****
> impose stringent requirements in terms of delay. Notions of localization
> and distribution of local agents have been introduced to reduce signalling
> network interfaces simultaneously have motivated the development of more
> new protocol extensions.
>
> 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.
>
> is not required for applications that launch and complete while connected
> to the same point of attachment. However, the mobility support has been
> 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.
>
> application in distributed mobility architectures ****
>
>
> Comments?
>
> Jari****
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 31 Oct 2011 10:08:44 -0700

Jari

Thanks for this update.  I want to clarify plan of the existing activity, HA reliability doc,  in MEXT. 
This document completed WGLC and went nowhere after all. 
It supposes to be proposed standard RFC.
Do you want to finish this work with AD sponsor? or just trash it?

thanks
ryuji

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 17:24:31 +0000

Hi Hui,

I will let Jari respond and explain his intent. I recognize that DMM was part of the charter of MEXT as I mentioned in my email. The new charter is basically nothing but DMM and IMO it is more than just rechartering the WG.
AD sponsorship of currently ongoing work is one option. But I believe a better option is for the scope of MEXT to be continued and not completely shutdown.

-Raj

From: ext Hui Deng <[email-masked]<mailto:[email-masked]>>
Date: Tue, 1 Nov 2011 00:00:08 +0800
To: Basavaraj Patil <[email-masked]<mailto:[email-masked]>>
Cc: ext Arkko <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MEXT] the future of the MEXT working group

Hi Raj,

>From my reading of the AD's email,
1. DMM has been already in mext charter before, I don't see why we need BOF process, it is just about rechartering.
2. AD has already said that other left work could be sponsored by AD, so it doesn't kick out any extension of MIP6/DSMIP6 if there is.

Thanks

-Hui

2011/10/31 <[email-masked]<mailto:[email-masked]>>

Hi Jari,

-Basavaraj

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Jari Arkko
Sent: Friday, October 28, 2011 7:21 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MEXT] the future of the MEXT working group

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.

Comments?

Jari

_______________________________________________
MEXT mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mext

---

From: Jari Arkko <[email-masked]>
Date: Mon, 31 Oct 2011 21:58:59 +0200

Did it successfully complete WGLC? With sufficient support for taking the document forward? If yes, the chairs can either send it immediately to me as a WG output.

Or I can AD sponsor it later. The offer to AD sponsor is also valid for other documents. They need to be in reasonable shape, naturally.

Jari

---

From: Julien Laganier <[email-masked]>
Date: Mon, 31 Oct 2011 13:33:06 -0700

Hi Raj,

This is a rechartering of the WG.

--julien

On Mon, Oct 31, 2011 at 7:47 AM,  <[email-masked]> wrote:
> 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 etc. The proposed charter does not consider this at all.
>
>
>
> -Basavaraj
>
>
>
> 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
> 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
> 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.
>

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 20:35:11 +0000

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:[email-masked]] 
Sent: Monday, October 31, 2011 3:33 PM
To: Patil Basavaraj (Nokia-CIC/Dallas)
Cc: [email-masked]; [email-masked]
Subject: Re: [MEXT] the future of the MEXT working group

Hi Raj,

--julien

On Mon, Oct 31, 2011 at 7:47 AM,  <[email-masked]> wrote:
> 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.
>
> improvements to MIP6/DSMIP6 protocol in terms of extensions, 
> deployability improvements etc. The proposed charter does not consider this at all.
>
>
>
> -Basavaraj
>
>
>
> proposals are welcome. This is what the current charter says about DMM:
>
>
>   Oct 2011 - Submit I-D 'Operational considerations for distributed 
> use of Mobile IPv6' for publication as Informational.
>
> that extended this a bit, including going beyond mere operational considerations.
>
>
> 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 
> 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.
>
> 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.
>
> 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.
> 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 
> 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.
>
> Give best practices for the deployment of existing mobility protocols 
> in a distributed mobility management and describe limitations of each 
> such approach.
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 31 Oct 2011 22:44:54 +0200

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, [email-masked] wrote:
> On Mon, Oct 31, 2011 at 7:47 AM,<[email-masked]>  wrote:
>>
>> Hi Jari,
>>
>>
>>

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 20:54:23 +0000

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

-Basavaraj

On 10/31/11 3:44 PM, "ext Jari Arkko" <[email-masked]> 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
>
>> 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
>>
>>> the network. This can result in a waste of resources and
>>>ever-increasing costs for the service provider.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 31 Oct 2011 16:33:54 -0500

Hi Jari,

draft-xia-mext-hioptv4-03.txt is for the charter item:

Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP'
to IESG for publication as Proposed Standard.

This is the only draft offered as a solution for this charter item.

The draft has received comments by DHCP experts like Ted Lemon and Tomek
Mrugalski and revised accordingly.

I think that it is ready for publication.

What should we do?

Regards,

Behcet

On Mon, Oct 31, 2011 at 2:58 PM, Jari Arkko <[email-masked]> wrote:

> Did it successfully complete WGLC? With sufficient support for taking the
> document forward? If yes, the chairs can either send it immediately to me
> as a WG output.
>
> Or I can AD sponsor it later. The offer to AD sponsor is also valid for
> other documents. They need to be in reasonable shape, naturally.
>
> Jari
>
>
>>> We are making some changes to the working group. While we have
>>> successfully published a large number of specifications in recent years,
>>> recently it has been difficult to make progress in the group. The chairs
>>> and ADs have looked at the situation and we believe we need a new focus and
>>> a bit of new organization as well. We are terminating the working group and
>>> moving the one remaining active work item to a new working group, the "DMM"
>>> working group. Here's what is going to happen:
>>>
>>> o  The charter of the group will be changed to focus only on the
>>> distributed mobility effort. We should discuss the details of this charter
>>> change both on the list and in the meeting. The meeting agenda should
>>> reserve some time both for technical discussions as well as the charter
>>> discussion.
>>>
>>> o  Once the discussion on the list and in the meeting has finished, we
>>> will rename the group to "DMM" and put the new charter in effect.
>>>
>>> o  If there are any other specifications that people would like to
>>> publish beyond the distributed mobility work, we can offer to AD sponsor
>>> them to RFCs outside the new working group. If there is some significant
>>> new activity, we can create new working groups for that.
>>>
>>> We would like to thank Marcelo for your many years of service in MEXT.
>>> We could not have completed all the work we did without your energy and
>>> push for high quality results. We would also like to thank Jouni for taking
>>> on this new challenge, and Julien for continuing the work in this space.
>>>
>>> Jari and Ralph
>>>
>>> ______________________________**_________________
>>> MEXT mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/mext<https://www.ietf.org/mailman/listinfo/mext>
>>>
>>
>>
> ______________________________**_________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mext<https://www.ietf.org/mailman/listinfo/mext>
>