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

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 1 Nov 2011 15:31:21 -0700

Jari,

I don't see any objection during WGLC. In fact, we had thoughtful reviews and improved the document. 
I am fine either AD-sponsor or regular WG procedure, but I need to see progress. WGLC was ended at Aug 1.

thanks
ryuji

On 2011/10/31, at 12:58, Jari Arkko 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
> 
> On 31.10.2011 19:08, Ryuji Wakikawa wrote:
>> 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
>> 
>> On 2011/10/28, at 5:08, Jari Arkko wrote:
>> 
>>> 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
>>> 
>>> _______________________________________________
>>> MEXT mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mext
>> 
>

---

From: <[email-masked]>
Date: Wed, 2 Nov 2011 16:10:28 +0100

Hi Jari,

Just a minor comment:

This charter addresses both the distribution of mobility functions and the dynamic mobility management. Even if dynamic activation/deactivation of mobility support can be seen as an enabler to distributed mobility management, I think the work item acronym should refer to both features. So, to avoid any ambiguity, I'd suggest to use the acronym DDMM (Distributed and Dynamic Mobility Management) for the work item.

Regards,

Pierrick

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de Jari Arkko
Envoyé : vendredi 28 octobre 2011 14:21
À : [email-masked]
Objet : 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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 03 Nov 2011 10:49:21 -0700

Hello folks,

For several years now, I have been studying 4G wireless
network architecture and wondering why there is such a
disconnect between, say, LTE mobility management and
IETF mobility management.  Mobile IP has a secondary
role, to say the least.  IETF approaches may be seen to
have several inadequacies, and 3GPP approaches also show
some major problems.  I think that it is important for
the IETF to devote some serious effort towards bringing
these two worlds together, because current directions
are leading towards an impossibly baroque, wasteful,
nearly impenetrable mess of complication.  The effects
overall is loss of performance and opportunity.

Taking a look at S101 and S103, we can immediately
recognize that they are drastically more complicated,
restrictive, and operationally more expensive than
Mobile IP.  Taking a look at S102, we immediately see
that 3GPP mobility management threatens to be different
for each class of application, with an unnecessary
per-application proliferation of servers, protocol,
permissions, traffic controls, configuration, and so on.
Taking a look at recent efforts towards WiFi offload,
we see the same trend of complication and software
hacks that could be avoided with proper IETF
approaches.

On the IETF side, we should specify:
- Integrated authentication for access control
   as well as IP address continuity
- Location-assisted handovers (think MIIS / ANDSF)
- Modular/alternative security
- Signaling on control plane, user traffic on
   data plane
- Alternative tunneling (GTP is simply not going
   to die a quick death, to say the least)
- geez, the list does go on, but no one reads
   long lists ...
...

I don't know if we already have 3GPP liaison, but
if we do the communication channels don't seem to
have had very much effect within the [mext] work
lately.

My fear is that if we don't take action, we are
choosing a future that is ever more complicated,
non-extendible, non-flexible, radio technology
specific, application specific, and bug-ridden.
In short, everything we don't want the Internet
to be.  And, I am sure no one here doubts that
the Internet of the future is all high-speed
wireless.  Where is the IETF going to be?

If the [mext] working group is shut down, there
is no natural place for this work to happen.
Therefore, I hope that [mext] would NOT shut
down, and instead recharter to tackle these
urgent problems.

Regards,
Charlie P.

On 10/28/2011 5:08 AM, Jari Arkko wrote:
> 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 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
>

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 03 Nov 2011 21:28:42 +0100

I'm supporting what Charlie wrote, and share the same concerns.

Regards,
Thierry.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 3 Nov 2011 23:02:42 +0200

Charlie,

It was 2005, a warm May week in Athens when SA2, RAN2 and RAN3 had a meeting., and EPS took its first steps.. This, for example, was on a table: http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_46_Athens/Docs/S2-051260.zip
That did/does not too bad actually.  I still remember some operator folk standing up back then and giving a loud comment "This science fiction.." ;-)

- Jouni

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 03 Nov 2011 15:29:30 -0700

Hello Jouni,

I think S2-051260 is an outstanding design document
that everyone in [mext] should read.  From it, we
"SHOULD" have seen a much better designed system.
The result, however, would not be recognizable from
figure 1 and figure 2 except by a quite optimistic
LTE expert.  I started to think about how to quantify
the huge jump in complexity between the stated design
goals in the document and the result of S1 --> S$\infty$
but my head started to hurt... never mind Ga --> Gz
and the 200 IEs for GTP, and all the other modules.

Is it possible to have some discussion on my proposal
[i.e., "On the IETF side, we should specify: ..."] at
IETF 82?  I realize it is quite broad and would
probably engender a lot of discussion, but it's a
discussion that needs to happen.

Regards,
Charlie P.

---

From: <[email-masked]>
Date: Thu, 3 Nov 2011 22:53:38 +0000

Hi Jari,

Comments inline:

>> extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. cellular phones)

What does "extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. cellular phones" this imply? The term always-on does not necessarily apply as well. If an MN is registered with an HA it is reachable but always-on would require the MN to be network-attached and registered with an HA which may not always be the case.

>> The presence of the centralized mobility anchor allows a mobile device to be reachable when it is not connected to its home domain.

What is a home domain for a user/MN? 

>> 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.
>> 

The comment about deployment of the Mobile IP protocols is irrelevant in this context. 

>> 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, se…

Offloading to wifi or the fact that CDNs are used for content delivery are really not a motivator for DMM.

>> 
>> 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).

Would you consider a P-GW/GGSN as introducing multiple levels of routing hierarchy? In Internet architecture terms the P-GW/GGSN is the NAS/Gateway router. 

>> This view is reinforced by the shift in users’ traffic behaviour, aimed at increasing direct communications among peers in the same geographical area.

This is highly speculative. What study shows that users traffic behavior displays such characteristics?

>> 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.

What is a truly flat mobile architecture?

>> 
>> 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.
>> 

Gap analysis is an academic exercise and not worth the effort of a WG.

>> Give best practices for the deployment of existing mobility protocols in a distributed mobility management and describe limitations of each such approach.

I think this is the most sane proposal in terms of how existing protocols can be deployed to address concerns that have been highlighted in various I-Ds.

>> Describe extensions, if needed, to current mobility protocols for their application in distributed mobility architectures

Yes. As needed.

-Basavaraj

---

From: jouni korhonen <[email-masked]>
Date: Fri, 4 Nov 2011 02:21:53 +0200

Hi,

Few quick comments. I would remove all explicit references to 3GPP and existing offload mechanisms therein. FWIW this WG is not supposed to be a stub of SA2. The possible (protocol) enhancement must be generic enough to be applicable outside of a specific deployment architecture.

Also, I think we ought not only consider just mobility enhancement. More efficient use of CoA(s) for direct/local/non-tunneled communication along with existing mobility solutions should be in scope as well. 

- Jouni

On Oct 28, 2011, at 3:21 PM, Jari Arkko wrote:

>> 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: Hesham Soliman <[email-masked]>
Date: Fri, 04 Nov 2011 11:43:50 +1100

Hi Charlie,

I agree completely with you on the problems with the current interfaces in
LTE, and in 3G before that.
I don't know what the best way to go about it would be. I say this because
many people on this list are aware of what's happening in LTE and
presumably have similar opinions about the complexity of their solutions,
but it's still there.

Hesham

---

From: Pete McCann <[email-masked]>
Date: Thu, 3 Nov 2011 21:16:14 -0400

A good architecture is made not only from deciding what to standardize but
also from what not to standardize.

Operators like to open up and specify interfaces because they think it gives
them leverage with suppliers.  They don't want to be locked into a single vendor
for their whole network.

Non-incumbent vendors like to open up and specify interfaces because it
opens up new business opportunities for their boxes.

A good architecture would integrate the NAS/Gateway with the radio.  We
should have exercised restraint in opening up any interface between those
two.

There is in 3GPP a feature called Local IP Access (LIPA).  It was originally
designed for femtocells, because it was obvious that people who deployed
them on their own network would want access to their own local services
on their own network instead of being put into a compulsory tunnel back to
some distant home operator network.

Perhaps IETF could take LIPA as a starting point to design a cleaner
mobility management solution.

It isn't clear to me that we should even start with tunnels as a basic building
block.

-Pete

---

From: jouni korhonen <[email-masked]>
Date: Fri, 4 Nov 2011 10:19:16 +0200

Pete,

> also from what not to standardize.

Exactly.

[snip]

> mobility management solution.

What came out from a certain SDO as a "Local IP Access" did not turn out as the most elegant solution :) But I do agree that from the idea & initial use case point of view, it definitely is something to look at.. even as a basis for a cleaner design.

> It isn't clear to me that we should even start with tunnels as a basic building

I am along the same lines. See my earlier mail on the charter http://www.ietf.org/mail-archive/web/mext/current/msg04905.html

- Jouni

>>> For several years now, I have been studying 4G wireless

[snap]

---

From: <[email-masked]>
Date: Fri, 4 Nov 2011 10:28:18 +0100

Hi,

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> jouni korhonen
> Envoyé : vendredi 4 novembre 2011 01:22
> À : Jari Arkko
> Cc : [email-masked]
> Few quick comments. I would remove all explicit references to 3GPP and
> existing offload mechanisms therein. FWIW this WG is not supposed to be a
> stub of SA2. The possible (protocol) enhancement must be generic enough to
> be applicable outside of a specific deployment architecture.
> 

I definitely agree to remove reference to 3GPP. However, I think we need clear use-case to motivate the distribution. As a starting point, we could assume a network architecture relying on the distribution of traffic anchors for local IP access/CDN; then study how to bring mobility support in this context. 

> Also, I think we ought not only consider just mobility enhancement. More
> efficient use of CoA(s) for direct/local/non-tunneled communication along
> with existing mobility solutions should be in scope as well.
> 

Actually, this is the idea behind dynamic mobility management described in the charter: use the CoA for IP flow which does not require mobility support. We are inline.

Pierrick

> > 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:
> >> 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.
> >>
> >> 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: jouni korhonen <[email-masked]>
Date: Fri, 4 Nov 2011 14:37:47 +0200

Pierrick,

> Actually, this is the idea behind dynamic mobility management described in the charter: use the CoA for IP flow which does not require mobility support. We are inline.

Nit picking and a bit of intentional teasing ;) Above is currently about a half.. one clear statement in the charter proposal is "the distribution of mobility anchors to achieve a more flat design".  The other clear statement is "the dynamic activation/deactivation of mobility protocol support as an enabler". However to use CoA(s) or any address you get locally falls greatly into the source address selection issues, which is not really about mobility per se. You don't necessarily even need distributed mobility anchors to facilitate that. Of course, there are vast amount possible solution approaches in this space.

- Jouni

---

From: <[email-masked]>
Date: Fri, 4 Nov 2011 15:46:19 +0100

> De : jouni korhonen [mailto:[email-masked]]
> Envoyé : vendredi 4 novembre 2011 13:38
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]
> > Actually, this is the idea behind dynamic mobility management described
> in the charter: use the CoA for IP flow which does not require mobility
> support. We are inline.
> >
> > Pierrick
> 
> Nit picking and a bit of intentional teasing ;) Above is currently about a
> half.. one clear statement in the charter proposal is "the distribution of
> mobility anchors to achieve a more flat design".  The other clear
> statement is "the dynamic activation/deactivation of mobility protocol
> support as an enabler". However to use CoA(s) or any address you get
> locally falls greatly into the source address selection issues, which is
> not really about mobility per se. You don't necessarily even need
> distributed mobility anchors to facilitate that. 

I agree, and I'm not saying that we need to distribute mobility management to benefit from dynamic MM. But I think that distribution can facilitate dynamic MM, even brings dynamic MM natively. Typically, if HA are co-located on each AR: the MN can initiate a communication with the IP obtained from the current AR, with standard IP routing coming into play. Then, if the MN changes the point of attachment, mobility management come into play: previous AR plays the HA role and the current IP is binded to the Ip obtained on the new AR. But, it's just an example of solution and, as you said, there are many other possible ways. So, I'll not digress more; I just want to stress that dynamic MM should not be ignored in future work.

Pierrick

Of course, there are vast
> amount possible solution approaches in this space.
> 
> - Jouni

---

From: <[email-masked]>
Date: Fri, 4 Nov 2011 16:05:21 +0000

> presumably have similar opinions about the complexity of their solutions,

Unless you can make a clear and definitive case that the current LTE solution does not work or scale or inefficient in terms of performance or otherwise, it is difficult to bring about change. Complexity has its own benefits.. Its just a matter of who the beneficiaries are :)
Hence claiming complexity as the reason to consider alternatives is an uphill task. If this complexity becomes an issue in terms of interop, CAPEX/OPEX costs etc. that may trigger a revisit to the architecture. 

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Nov 2011 11:18:08 -0500

Hi all,

I am confused about all these very high level, intelligent looking
comments, and I must say I am fed up with them :-).

Non-tunneled communications is already there in DMM. You connect to the
nearest HA and all new communications is non-tunneled.

Do we agree that we should differentiate client-based and network based
protocols and discuss them in different places? or even there is no issue
for one.

I think this is what we should decide now.

Regards,

Behcet

On Fri, Nov 4, 2011 at 3:19 AM, jouni korhonen <[email-masked]>wrote:

> What came out from a certain SDO as a "Local IP Access" did not turn out
> as the most elegant solution :) But I do agree that from the idea & initial
> use case point of view, it definitely is something to look at.. even as a
> basis for a cleaner design.
>
> I am along the same lines. See my earlier mail on the charter
> http://www.ietf.org/mail-archive/web/mext/current/msg04905.html
>
> - Jouni
>
>
>
> >
> > -Pete
> >

---

From: liu dapeng <[email-masked]>
Date: Sat, 5 Nov 2011 00:41:42 +0800

Hi Pierrick,

2011/11/2, [email-masked] <[email-masked]>:
> Hi Jari,
>
>
>
> Just a minor comment:
>
>
>
> This charter addresses both the distribution of mobility functions and the
> dynamic mobility management. Even if dynamic activation/deactivation of
> mobility support can be seen as an enabler to distributed mobility
> management, I think the work item acronym should refer to both features. So,
> to avoid any ambiguity, I'd suggest to use the acronym DDMM (Distributed and
> Dynamic Mobility Management) for the work item.

There is no contradiction between distributed and dynamic. Actually
"dynamic mobility" could be considered as some sort of  "distributed
mobility". So I think DMM is a simple and concise acronym.

Dapeng

> 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.
>
>
>
>
> 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.
>
> impose stringent requirements in terms of delay. Notions of localization and
> distribution of local agents have been introduced to reduce signalling
> 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.
>
> 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.
>
> 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.
>
> Give best practices for the deployment of existing mobility protocols in a
> distributed mobility management and describe limitations of each such
> approach.
>

-- 

------
Best Regards,
Dapeng Liu

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 04 Nov 2011 10:05:36 -0700

Hello Behcet,

> comments, and I must say I am fed up with them :-).

- I'm guessing you don't wish to restrict to only stupid comments.
- Do you mean that only low-level comments are of interest?
   That doesn't seem appropriate in response to the proposal to
   shut down the working group...?

> nearest HA and all new communications is non-tunneled.

That doesn't provide IP address continuity, does it?

> protocols and discuss them in different places?

If I understand your point, this is the status quo, right?

> or even there is no issue for one.

I did not understand the point of that.

> I think this is what we should decide now.

I'm not sure what "this" means in your sentence.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 04 Nov 2011 10:15:49 -0700

Hello Basavaraj,

Comments inline:

On 11/4/2011 9:05 AM, [email-masked] wrote:

> Unless you can make a clear and definitive case that the current LTE
> solution does not work or scale or inefficient in terms of performance
> or otherwise, it is difficult to bring about change.

Even with a clear case, it will be difficult to bring
about change.

>                                                        Complexity has
> its own benefits.. Its just a matter of who the beneficiaries are

Why don't we start from designing for the beneficiaries to be
the end users?  Every strategy has beneficiaries, but yours is
in no way a useful criterion for design.  Elminating electronic
communications and commerce would have very many beneficiaries,
as just one example.  Enabling high-speed smooth handovers
between heterogeneous radio technologies would benefit some
people more than others.  I'll be very surprised if [mext]
explicitly aims to protect complexity on the basis of your
argument.

> Hence claiming complexity as the reason to consider alternatives is
> an uphill task. If this complexity becomes an issue in terms of interop,
> CAPEX/OPEX costs etc. that may trigger a revisit to the architecture.

> hacks that could be avoided with proper IETF

... and ...

>    ..........    if we don't take action, we are
> to be.

Do you disagree with _any_ of my claims above?

Regards,
Charlie P.

>> From: "Charles E. Perkins"<[email-masked]>
>> To: Jari Arkko<[email-masked]>
>> Cc:<[email-masked]>,<[email-masked]>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 04 Nov 2011 10:31:38 -0700

Hello Jouni,

Comments inline:

On 11/3/2011 5:21 PM, jouni korhonen wrote:

> existing offload mechanisms therein. FWIW this WG is not supposed to
> be a stub of SA2. The possible (protocol) enhancement must be generic
> enough to be applicable outside of a specific deployment architecture.

I agree 100%.  I use 3GPP as an example.  However, it is a likely
bet that a huge fraction of the mobile devices in the future will
implement wireless connectivity specified by 3GPP and depend upon
network backhaul specified by 3GPP, so it is pretty relevant
to consider the design needs specifically of 3GPP -- if nothing
else, then at least as a reality check.

> Also, I think we ought not only consider just mobility enhancement.
> More efficient use of CoA(s) for direct/local/non-tunneled communication
> along with existing mobility solutions should be in scope as well.

Again, agree 100%.  However, we might eventually determine that the
methods for efficient use of CoA(s) are somewhat different than the
methods for enabling IP address continuity and smooth handover.
I wonder whether the two different technologies would even belong
in the same working group.

Before enabling a mechanism to select a CoA, we need some way
for classifying the "characteristics" of an IP address as bound
to a specific radio interface and Internet PoA.  To me, it's not
at all obvious that such a problem is "like" the other problems
of interest within the Internet Area.

Regards,
Charlie P.

---

From: <[email-masked]>
Date: Fri, 4 Nov 2011 18:06:08 +0000

Hi Charlie,

> Even with a clear case, it will be difficult to bring

No doubt… But at least there is some reasoning/justification that one can consider.

> explicitly aims to protect complexity on the basis of your

I do agree that a simpler approach would have many beneficiaries including end users.
End users are happy with the status quo. Handovers across heterogeneous access technologies is a nice feature. But is not critical if the session can be continued on the currently attached network. Applications are evolving such that they can handle change in access network connectivity. A small set of applications currently need the type of seamless mobility and handovers that Mobile IP provides. But that advantage and benefit is waning IMHO.

> Do you disagree with _any_ of my claims above?

I dont disagree with your points above and I guess having a document which illustrates how a Mobile IP based approach can dramatically simplify the interfaces and complexity would be useful. But then again maybe the requirements are such that any attempt to meet those with Mobile IP and IETF protocols would result in an equivalently complex system. I don't know.. But thats a possibility. 

You could also view a future where the complexity of the architecture is overwhelming enough to cause its own demise. 

-Basavaraj

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 05 Nov 2011 10:04:49 +1100

>solution does not work or scale or inefficient in terms of performance or
>otherwise, it is difficult to bring about change. Complexity has its own
>benefits.. Its just a matter of who the beneficiaries are :)
>Hence claiming complexity as the reason to consider alternatives is an
>uphill task. If this complexity becomes an issue in terms of interop,

=> Right, I think OPEX is the key issue here. The CAPEX argument is
subjective and speculative but OPEX differences are a bit easier to show.

Hesham

---

From: Pete McCann <[email-masked]>
Date: Fri, 4 Nov 2011 23:15:31 -0400

On Fri, Nov 4, 2011 at 2:06 PM,  <[email-masked]> wrote:
>
> Applications are evolving such that they can handle change in access network
> connectivity. A small set of applications currently need the type of seamless
> mobility and handovers that Mobile IP provides. But that advantage and benefit
> is waning IMHO.

The same argument could be applied to the GPRS architecture.  Gluing
additional access technologies to the P-GW with GTP tunnels is completely
unnecessary.

> I dont disagree with your points above and I guess having a document which
> illustrates how a Mobile IP based approach can dramatically simplify the interfaces
> and complexity would be useful. But then again maybe the requirements are such
> that any attempt to meet those with Mobile IP and IETF protocols would result in
> an equivalently complex system. I don't know.. But thats a possibility.

We should definitely not try to replicate GPRS with Mobile IP.  I think the
point of this discussion is that some of the requirements (like IP address
continuity throughout all space and time) that drove the existing architecture
need to be relaxed.

> You could also view a future where the complexity of the architecture is
> overwhelming enough to cause its own demise.

I think we may be close to that point already.

-Pete

---

From: jouni korhonen <[email-masked]>
Date: Sun, 6 Nov 2011 22:32:21 +0200

On Nov 4, 2011, at 6:18 PM, Behcet Sarikaya wrote:

> Hi all,
> 
> I am confused about all these very high level, intelligent looking comments, and I must say I am fed up with them :-).
> 
> Non-tunneled communications is already there in DMM. You connect to the nearest HA and all new communications is non-tunneled.
> 
> Do we agree that we should differentiate client-based and network based protocols and discuss them in different places? or even there is no issue for one.

IMHO I see no reason to focus only on client-based or network-based solutions. FWIW the DMM solution space:

o is incremental to an existing IETF mobility protocol, be that client-,
  network- or even transport-based.
o or alternatively may not depend on a specific mobility protocol at all
  i.e. non-anchored solution is also in scope.
o solution is backward compatible in a sense that if a host or a network
  does not support DMM, nothing breaks.
o focuses on IPv6 because anything IPv4 is just NAT-games.

- Jouni

> On Fri, Nov 4, 2011 at 3:19 AM, jouni korhonen <[email-masked]> wrote:
> Pete,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Nov 2011 14:06:17 +0100

Hello Jari, WG members,

Le 28/10/2011 14:08, Jari Arkko a écrit :
> 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:
>
> 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.
>
> publish beyond the distributed mobility work, we can offer to AD
> sponsor them to RFCs outside the new working group.

I wonder what is the plan about
draft-ietf-mext-nemo-ro-automotive-req-02? "Automotive Industry
Requirements for NEMO Route Optimization"
http://tools.ietf.org/html/draft-ietf-mext-nemo-ro-automotive-req-02

I can see a number of options to move it forward, like for example:
- change in authorship, title.
- continue as part of new Charter (fulfill earlier objectives) or
   sponsor separately per your offer.
- change in focus.

What do you think?

Alex

> 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
>

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 07 Nov 2011 14:16:48 +0100

Thanks Alex for raising this.

My view on this is that the automotive industry has some needs that are 
partly related to NEMO RO, but not only related to NEMO.

So, I would like to seek advice from our AD about where would be the 
best place at the IETF to discuss automotive requirements related to IPv6 ?

Regarding the dratf itself, it is our intention to update it.

Regards,
Thierry

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Nov 2011 15:47:30 +0100

Le 07/11/2011 14:16, Thierry Ernst a écrit :
> My view on this is that the automotive industry has some needs that
> are partly related to NEMO RO, but not only related to NEMO.

I agree.  That's why its title could change (dont use "ro" in title nor
filename).  The contents of the draft as of now already include a number
of use cases which do not necessarily need RO.

Some NEMO wording could be softened, to present it as an alternative not
necessarily _the_ solution.

Additionally, a number of discussions happened in 2011 on IETF email
lists (mext, 6man) which relate to automotive requirements and IPv6.
How about adding VIN and ULA text into it?

>  best place at the IETF to discuss automotive requirements related to

I am also interested to learn where else have automotive discussions
happened at IETF, other than 6MAN and MEXT.

VIN, March 2011:
http://www.ietf.org/mail-archive/web/ipv6/current/msg13729.html

ULA, September 2011:
http://www.ietf.org/mail-archive/web/ipv6/current/msg14715.html

> Regarding the dratf itself, it is our intention to update it.

Good to know.

Alex

> Regards, Thierry
>>> 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:
>>>
>>> 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.
>>
I can see a number of options to move it forward, like for example:
>> - change in authorship, title. - continue as part of new Charter
>> (fulfill earlier objectives) or sponsor separately per your offer.
>> - change in focus.
>>
>> What do you think?
>>
>> Alex
>>
>>> If there is some significant new activity, we can create new
>>> working groups for that.
>>
>>
>>>
>>> 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
>>> _______________________________________________ MEXT mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>>
>>
>>

---

From: <[email-masked]>
Date: Mon, 7 Nov 2011 15:53:22 +0100

I agree with this scope.

Pierrick

---

From: <[email-masked]>
Date: Mon, 7 Nov 2011 15:52:04 +0000

Hi all,

I agree with Alex and Thierry on this issue!
Where is the best place at the IETF to discuss and work out automotive requirements?

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thierry Ernst
> Sent: maandag 7 november 2011 14:17
> To: [email-masked]
> Subject: Re: [MEXT] automotive reqs WG item
> 
> 
> So, I would like to seek advice from our AD about where would be the best
> place at the IETF to discuss automotive requirements related to IPv6 ?
> 
> >> 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: <[email-masked]>
Date: Mon, 7 Nov 2011 17:41:11 +0100

Dear all,
I agree with the importance of the topic and remember that at least in the mobopts session the charter of which should be under discussion/revision this topic was also mentioned ...
Would that work - or is the intention more on vehicular engineering rather than research topics?

Regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Montag, 7. November 2011 16:52
An: [email-masked]; [email-masked]
Betreff: Re: [MEXT] automotive reqs WG item

Hi all,

Best regards,
Georgios

---

From: <[email-masked]>
Date: Mon, 7 Nov 2011 20:06:09 +0000

>Where is the best place at the IETF to discuss and work out automotive

Maybe it would be worthwhile to organize a BoF and consider the potential
for a separate WG since the automotive requirements are not just mobility
related.

-Raj

>>best

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 07 Nov 2011 12:42:54 -0800

Hello Raj,

Not disagreeing that a BOF would be useful, but
I'm wondering whether the requirements as laid out
in the expired Internet Draft would fit in a single
working group.  The distinction between IP-based
and C2C-CC-based applications would probably need
a very contentious BOF, just on that single issue.
There have been so many failed proposals to replace
TCP, that it's hard to avoid skepticism for this one.

Anyway, I'd have more confidence that a BOF which was
restricted to just the mobility part of the problem
might get some useful results.

Regards,
Charlie P.

On 11/7/2011 12:06 PM, [email-masked] wrote:
>
>
> On 11/7/11 9:52 AM, "ext [email-masked]"<[email-masked]>
> wrote:
>
>> Hi all,
>>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 10 Nov 2011 21:41:38 +0900

Hi,

I think that the point is to give a choice to the network and user if
mobility is needed or not. Some applications benefit from seamless
mobility (e.g., VoIP), but others may not (e.g., Web access). The
network and user should be able to specify the capability of mobility
and appropriate access network for each application. In that sense,
Dynamic MM is an interesting feature.

I agree that the current 3GPP architecture is very complicated and may
not be optimal, but I don't think it is a good idea to change it in IETF...

Regards,
-- 
Hidetoshi

(2011/11/05 12:15), Pete McCann wrote:
> On Fri, Nov 4, 2011 at 2:06 PM,<[email-masked]>  wrote:
>>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Nov 2011 13:42:15 -0800

Hello Hidetoshi,

> Dynamic MM is an interesting feature.

I pretty much agree with this; I expect that working out the
details will be pretty tedious and perhaps even contentious.

> not be optimal, but I don't think it is a good idea to change it in IETF...

I agree we can't "change" 3GPP architecture in the IETF, but
we can respond to the needs which are evident from considering
the 3GPP architecture.  It seems very few believe that LTE
is really immune from further evolution and even significant
change in the future.  If IETF does NOT respond to the needs made
evident in current 3GPP specifications, we have little hope of
proper integration into their future evolved designs.

Regards,
Charlie P.

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 11 Nov 2011 10:12:33 +0900

Hi Charlie,

> proper integration into their future evolved designs.

I fully agree with your point and am glad you initiated this discussion.
One of the reasons for its complicatedness is that the 3GPP architecture
has been incrementally built considering all the backward compatibility
and interoperability along with introducing new features and minimizing
the unhappiness of all. I respect this effort and achievement we all
enjoy today. On the other hand, the current mobile traffic is way too
much for this architecture to be able to handle. If IETF can contribute
to tackling this issue toward the future evolved design, it will be very
valuable. I don't know if DMM is the start point or we need a new WG,
but we still have a high mountain to climb.

Regards,
-- 
Hidetoshi

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 11 Nov 2011 13:28:55 +1100

Hi Charlie, 

>proper integration into their future evolved designs.

=> I think we should all learn from the RFC 3314 experience where IETF
(IPv6 WG at the time) made clear recommendations to 3GPP about address
configuration and all the recommendations were adopted in the same
release. I know these are smaller recommendations but this happens all the
time and we shouldn't worry about achieving things before trying to get a
unified view and presenting it. RFC 3316 is another example, although it
was more of a consensus-based approach between the two organisations

Hesham

---

From: liu dapeng <[email-masked]>
Date: Sun, 13 Nov 2011 17:30:59 +0800

> o focuses on IPv6 because anything IPv4 is just NAT-games.

I have concern about only focuse on IPv6. IPv4 is still widely used
today, we have to consider that.

regards,
Dapeng

>> as the most elegant solution :) But I do agree that from the idea &
>> initial use case point of view, it definitely is something to look at..
>> even as a basis for a cleaner design.
>>

-- 

------
Best Regards,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Sun, 13 Nov 2011 17:56:50 +0800

> but we still have a high mountain to climb.

I fully aggree with this point. The mobile operators faces the presure
of  rapidly traffic increasing. We should consider this point when we
try to optimize mobility protocols.

regards,
Dapeng

-- 

------
Best Regards,
Dapeng Liu

---

From: jouni korhonen <[email-masked]>
Date: Sun, 13 Nov 2011 19:10:41 +0200

> today, we have to consider that.

I understand this. However, the day any DMM solution hits the market can we assume that IPv4 is the protocol those new subscribers & mobiles are then mainly using? Given the minimum 2-3 year window anything penetrates the mass market we manage to define here, I hope IPv6 will have more significant role, for example, in cellular systems.

- Jouni

---

From: h chan <[email-masked]>
Date: Mon, 14 Nov 2011 05:55:40 +0000

The DMM design team consisting of people from initially 8 (and later more) major operators and vendors had worked on DMM from over a year ago. It was also open to anyone and had later been joined by more people from more both industry and academia. In the past, the activities from this team (such as dmm discussion group and a couple of dmm meetings in Prague and in Quebec City) had been considered individual activities not part of the mext WG. As the mext WG is now re-chartered into DMM WG and has used the charter statement from the team as candidate input to the re-charter statement, is it reasonable to consider incorporating the work from this team into the DMM WG? It is of cause open to more suggestions and inputs from anyone as it had always been in the past.

The following 2 documents were the initial outputs from the team:
Problem statement: draft-chan-distributed-mobility-ps-
Use cases: draft-yokota-dmm-scenario-00
and a charter statement

The majority of the charter statement can be found in the introduction charter of the above problem statement from over a year ago.
This charter statement from this team is now being used by Jari as input to the re-charter to the WG.

In the last dmm meeting in July, work had already started in drafting the requirements, and an initial draft has also been produced in one session of the above ps draft, which had taken the discussions into account and had closely relate the requirements to address the problem statements.

In addition, the contents from the above documents had largely been used and improved in the following journal paper so that they had also been reviewed through the journal publication process:

"Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues," Journal of Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.

I especially point out the above because they are the team work of many people resulting from a lot of efforts as well as using extensive discussions in emails (design team and then dmm mailing list) and in meetings.

I have not mentioned many other drafts on dmm from many other authors here.

Also, the earlier discussions in the dmm mailing list had caused the mext WG to not hold mext meeting in Quebec City with the reason that there was not enough interest in dmm. If the mext WG is to rename to dmm WG, are we going to use the dmm mailing list in future?

H Anthony Chan, Fellow IEEE

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

Comments?

Jari