Subject: [MEXT] The first proposal for the DMM charter

From: jouni korhonen <[email-masked]>
Date: Wed, 14 Dec 2011 10:54:26 +0200

Folks,

We have been working on a charter text from DMM based on the initial goal setting and the input we received during the Taipei meeting. Note that this is the first draft and now we are soliciting for input.

- Jouni & Julien

-------------------------------------------------------------------------

Distributed Mobility Management (DMM)
-------------------------------------

Charter

 Current Status: Active

 Chairs:
     Julien Laganier <[email-masked]>
     Jouni Korhonen <[email-masked]>

 Internet Area Directors:
     Ralph Droms <[email-masked]>
     Jari Arkko <[email-masked]>

 Internet Area Advisor:
     Jari Arkko <[email-masked]>

 Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       https://www.ietf.org/mailman/listinfo/mext
     Archive:            http://www.ietf.org/mail-archive/web/mext

Description of Working Group:

  The Distributed Mobility Management (DMM) working group specifies IP
  mobility, access network and routing solutions, which allow for
  setting up IP networks so that traffic is distributed in an
  optimal way and does not rely on centrally deployed anchors to manage
  IP mobility sessions. The distributed mobility management solutions
  aim for transparency above the IP layer, including maintenance of
  active transport level sessions as mobile hosts or entire mobile
  networks change their point of attachment to the Internet.   
  
  The protocol solutions should be enhancements to existing IP mobility
  protocols, either host- or network-based, such as Mobile IPv6
  [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
  NEMO [RFC3963]. Alternatively, the distributed mobility management
  solution can be transparent to any underlying IP mobility protocol.
  Although the maintenance of stable home address(es) and/or prefix(es)
  and upper level sessions is a desirable goal when mobile hosts/routers
  change their point of attachment to the Internet, it is not a strict
  requirement. Mobile hosts/routers should not assume that IP
  addressing including home address(es) and/or home network prefix(es)
  remain the same throughout the entire upper level session lifetime.
  
  The distributed mobility management solutions primarily target IPv6
  Deployment and should not be tailored specifically to support IPv4,
  in particular in situations where private IPv4 addresses and/or NATs
  are used. At least IPv6 is assumed to be present in both the mobile
  host/router and the access networks. Independent of the distributed
  mobility management solution, backward compatibility must be
  maintained. If the network or the mobile host/router do not support
  the distributed mobility management enabling protocol, nothing should
  break.
  
Work items related to the distributed mobility management include:
  
  o Solution Requirements: Define precisely the problem of distributed
    mobility management and identity the requirements for a distributed
    mobility management solution.

  o Best practices and Gap Analysis: Document best practices for the
    deployment of existing mobility protocols in a distributed mobility 
    management environment and identify the limitations of each such
    approach with respect to fulfillment of the solution requirements.

  o If limitations are identified as part of the above deliverable,
    specify extensions to existing protocols that removes these
    limitations within a distributed mobility management environment.
    
Goals and Milestones:

  Aug 2012 - Submit I-D 'Solution Requirements' as a working
             group document. To be Informational RFC.
  Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
             group document. To be Informational RFC.
  Nov 2012 - Evaluate the need for additional working group document(s)
             for extensions to fill the identified gaps.
  Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
             consideration as an Informational RFC. 
  Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG for
             consideration as an Informational RFC.
  Mar 2013 - Conclude the working group or re-charter.

---

From: [email-masked]
Date: Wed, 14 Dec 2011 17:29:38 +0800

Hi  jouni:

I have a quick question about  'Goals and Milestones'. 

As it is stated 'If limitations are identified as part of the above 
deliverable, specify extensions to existing protocols that removes these 
limitations within a distributed mobility management environment.' which 
means, I guess, a solution will be created for remove these limitations 
and a RFC will be needed.

So why the  'Goals and Milestones' misses this part? Or does it mean the 
solution for remove these limitaions is also included in the I-D 'Best 
practices and Gap Analysis' ?

Cheers
Luowen

jouni korhonen <[email-masked]> 
发件人:  [email-masked]
2011-12-14 16:54

收件人
[email-masked]
抄送
"[email-masked] Laganier" <[email-masked]>, jouni korhonen 
<[email-masked]>, Jari Arkko <[email-masked]>
主题
[MEXT] The first proposal for the DMM charter

Folks,

We have been working on a charter text from DMM based on the initial goal 
setting and the input we received during the Taipei meeting. Note that 
this is the first draft and now we are soliciting for input.

- Jouni & Julien

Charter

 Current Status: Active

 Chairs:

 Internet Area Directors:

 Internet Area Advisor:

 Mailing Lists:

 

 

 
Goals and Milestones:

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 14 Dec 2011 09:28:07 -0800

Luowen,

2011/12/14 <[email-masked]>
> As it is stated 'If limitations are identified as part of the above deliverable, specify extensions to existing protocols that removes these limitations within a distributed mobility management environment.' which means, I guess, a solution will be created for remove these limitations and a RFC will be needed.
>
> So why the  'Goals and Milestones' misses this part? Or does it mean the solution for remove these limitaions is also included in the I-D 'Best practices and Gap Analysis' ?

It's not missing, it is covered as part of this milestone:

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Dec 2011 11:44:44 -0600

Hi Jouni, Julien,

Should we say that multicast is out of scope?

Multicast dmm  could possibly be covered in Multimob.

Regards,

Behcet

---

From: [email-masked]
Date: Thu, 15 Dec 2011 08:35:12 +0800

Hi Julien

Thank you for correcting me

Cheers
Luowen 

2011-12-15 01:28

收件人
[email-masked]
抄送
jouni korhonen <[email-masked]>, [email-masked]
主题
Re: [MEXT] 答复:  The first proposal for the DMM charter

Luowen,

--julien

---

From: jouni korhonen <[email-masked]>
Date: Thu, 15 Dec 2011 10:17:21 +0200

Hi,

As Julien pointed out, we have a checkpoint planned for IETF#85.
After two meeting cycles we should be clear which documents will
be the basis (can be a combination of multiple, not just one) for
requirements & analysis.  That should give us enough time &
background to realized whether concrete protocol extensions are
needed and what they roughly are. New goals for possible new
solutions (i.e. extensions to some protocol, not necessarily just
mobility protocols) will be added as a part of charter goals update.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Thu, 15 Dec 2011 10:47:54 +0200

Behcet,

Reading Multimob's current charter and the planned continuum thru possible
rechartering:

   Future work, subject to rechartering, may study/evaluate extensions
   to IGMPv3/MLDv2 to support better operation in mobile environments.

I would be inclined to say that anything DMM related was not planned for
Multimob and DMM goes beyond the original scope of 'providing guidance
for supporting multicast in a mobile environment'. I would not add any
restricting text regarding multicast into DMM charter.

However, I leave this to our ADs to judge whether multicast enhancement
*shall not* be done within DMM after our requirement and analysis work
conclude that multicast enhancements are needed. Assuming we (DMM) would
conclude enhancements are needed for multicast around IETF#85, it would
be a bit odd if another WG is already chartered to work in a solution
space in the exactly same area.

- Jouni

---

From: [email-masked]
Date: Fri, 16 Dec 2011 08:41:02 +0800

Hi jouni:

     Thank you for the reply. 

Cheers
Luowen

2011-12-15 16:17

收件人
[email-masked]
抄送
Julien Laganier <[email-masked]>, [email-masked]
主题
Re: [MEXT] 答复: Re:  答复:  The first proposal for the DMM charter

Hi,

- Jouni

> >
> > So why the  'Goals and Milestones' misses this part? Or does it mean 
the solution for remove these limitaions is also included in the I-D 'Best 
practices and Gap Analysis' ?

---

From: jouni korhonen <[email-masked]>
Date: Mon, 19 Dec 2011 00:20:43 +0200

Folks,

Based of the "feedback" can I assume folks are mostly happy with the current text?

- Jouni

---

From: <[email-masked]>
Date: Mon, 19 Dec 2011 14:28:51 +0100

Hi Jouni and all,

Just a short question on the meaning of
'DMM solution can be transparent to any underlying IP mobility protocol'

So does that also include a potential view on alternative approaches auch as Host mobility with HIP (Host Identity Protocol) as described in (http://tools.ietf.org/id/draft-ietf-hip-rfc5206-bis-03.txt) or as the LISP mobility solution (http://tools.ietf.org/id/draft-meyer-lisp-mn-06.txt) where use of (soon to be) standard (lightweight) LISP (Locator/ID Separation Protocol) functions and services to provide scalable mobility for LISP MNs is envisaged?

Thanks and best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von jouni korhonen
Gesendet: Sonntag, 18. Dezember 2011 23:21
An: [email-masked]
Cc: [email-masked] Laganier; jouni korhonen; Jari Arkko
Betreff: Re: [MEXT] The first proposal for the DMM charter

Folks,

- Jouni

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Mon, 19 Dec 2011 08:30:21 +0100

> Based of the "feedback" can I assume folks are mostly happy with the current text?

The title should be changed to "DMM6" since it does not cover IPv4.
Bruno

>> - Jouni&  Julien
>>      Julien Laganier<[email-masked]>
>>      Jouni Korhonen<[email-masked]>
>>
>> Internet Area Directors:
>>      Ralph Droms<[email-masked]>
>>      Jari Arkko<[email-masked]>
>>
>> Internet Area Advisor:
>>      Jari Arkko<[email-masked]>
>>
>> Mailing Lists:

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Dec 2011 10:29:53 +0200

I think this looks very good, but I would still take into account Pierrick's suggested edits, and I think we have to be far more specific about that "can be transparent to any underlying mobility protocol part", because it confuses me. And per questions on the list, it seems to confuse other people too.

Suggested edits below. I have sent this version to the IESG and IAB, but I expect that the chairs may produce additional refined versions.

Charter

  Current Status: Active

  Chairs:

  Internet Area Directors:

  Internet Area Advisor:

  Mailing Lists:

   The protocol solutions should be based on existing IP mobility
   protocols, either host- or network-based, such as Mobile IPv6
   [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
   NEMO [RFC3963]. Solutions may also focus specifically
   on managing the use of care-of versus home addresses in an
   efficient manner for different types of communications.

   Although the maintenance of stable home address(es) and/or prefix(es)
   and upper level sessions is a desirable goal when mobile hosts/routers
   change their point of attachment to the Internet, it is not a strict
   requirement. Mobile hosts/routers should not assume that IP
   addressing including home address(es) and/or home network prefix(es)
   remain the same throughout the entire upper level session lifetime,
   or that support for mobility functions is provided on the network side
   in all conditions.

   o Best practices: Document best practices for the
      deployment of existing mobility protocols in a distributed mobility
      management environment.

  o  Gap Analysis and extensions: identify the limitations in the best current
      practices with respect to providing the expected functionality.

Goals and Milestones:

   Aug 2012 - Submit I-D 'Solution Requirements' as a working
              group document. To be Informational RFC.
   Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
              group document. To be Informational RFC.
   Nov 2012 - Evaluate the need for additional working group document(s)
              for extensions to fill the identified gaps.
   Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
              consideration as an Informational RFC.
   Jan 2013 - Submit I-D 'Best practices ' to the IESG for
              consideration as an Informational RFC.
   Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for
              consideration as an Informational RFC.
   Mar 2013 - Evaluate the need for further work based on the identified gaps
              and revise the milestones and/or the charter of the group

---

From: jouni korhonen <[email-masked]>
Date: Tue, 20 Dec 2011 10:52:15 +0200

Jari,

> I think this looks very good, but I would still take into account Pierrick's suggested edits, and I think we have to be far more specific about that "can be transparent to any underlying mobility p…

Thanks for the edit. The "transparent" part was definitely poorly worded as it was meant for bettering the use of CoAs.. But wording ended up far too open ended. The new text expresses the original intent clearly.

I also agree with Pierrick's comments that are now also included.

- Jouni

---

From: <[email-masked]>
Date: Mon, 19 Dec 2011 11:57:44 +0100

Hi Jouni,

It seems that I've some trouble with my mail box.... Please see below my comments sent on Friday...

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> jouni korhonen
> Envoyé : dimanche 18 décembre 2011 23:21
> À : [email-masked]
> Cc : [email-masked] Laganier; jouni korhonen; Jari Arkko
> Objet : Re: [MEXT] The first proposal for the DMM charter
> 
> 
> Folks,
> 

---------------------------------------- 

Hi Jouni & Julien,

This charter looks good. However, please see inline few suggestions for modifications.

Thanks,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part 
> de jouni korhonen Envoyé : mercredi 14 décembre 2011 09:54 À : 
> [email-masked] Cc : [email-masked] Laganier; jouni korhonen; 
> Jari Arkko Objet : [MEXT] The first proposal for the DMM charter
> 
> Folks,
> 
> We have been working on a charter text from DMM based on the initial 
> goal setting and the input we received during the Taipei meeting. Note 
> that this is the first draft and now we are soliciting for input.
> 
> - Jouni & Julien
> 
> 
> ----------------------------------------------------------------------
> -
> --
> 
>   NEMO [RFC3963]. 

This sentence gives the impression that extensions to MIP/PMIP will be necessary, i.e. here, the charter seems put extensions as a requirement (I don't think it is the goal :-)). It appears to be inconsistent with the two steps approach suggested by the work items: best current practices (without protocol modification), then, if necessary, specify extensions. So, I'd suggest to reword as follows:

The protocol solutions should be based on existing IP mobility
  Protocols and related mechanisms, either host- or network-based, such as Mobile IPv6
   [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
  NEMO [RFC3963]. 

Alternatively, the distributed mobility management
>   remain the same throughout the entire upper level session lifetime.

I suggest to add the following statement:

Mobile hosts/routers should not assume always-on mobility support.

>     limitations within a distributed mobility management environment.

IMHO, the gap analysis should not be part of the best current practices. The BCP may stress some limitations but an exhaustive gap analysis should be the motivation for protocols extensions. So, I suggest to rearrange work items as follows: 

 o  Gap Analysis and extensions: identify the limitations of each such
    approach with respect to fulfillment of the solution requirements. If limitations are,
    specify extensions to existing protocols that removes these
    limitations within a distributed mobility management environment.

>              group document. To be Informational RFC.

As explained above, I think the gap analysis should not be part of the BCP. So, this goal should be:

   Aug 2012 - Submit I-D 'Best practices' as a working
              group document. To be Informational RFC.

>              for extensions to fill the identified gaps.

Extensions should be motivated by a complete gap analysis. So, this goal should be:

Nov 2012 - Gap analysis and evaluation for the need of additional working group document(s)
            for extensions to fill the identified gaps.

---

From: Conny Larsson <[email-masked]>
Date: Tue, 20 Dec 2011 19:54:13 +0100

Hi Jouni, Julien

I believe the charter looks good but I would like to ask you if 
deployment scenarios are covered by the charter or not (I'm thinking of 
a Informational RFC)?

Let me be a bit more specific. When discussing DMM (in a 3GPP 
perspective) with people I  get the impression that many operators are 
interested in the topic but that they have very few peering points. They 
are not always interested (or they do not see the need) in deploying 
more peering points since they are expensive. Perhaps the reason for 
this is related to the current hierarchical architecture and will change 
with a more distributed architecture.

So what do you think? Is there a need for this kind of document?

Best Regards
Conny

---

From: liu dapeng <[email-masked]>
Date: Thu, 22 Dec 2011 01:53:01 +0800

2011/12/14, jouni korhonen <[email-masked]>:
> setting and the input we received during the Taipei meeting. Note that this
> is the first draft and now we are soliciting for input.
>
> - Jouni & Julien
>
>

[Comment]

This point seems not specific to DMM, since all IP mobility protocol
aim for transparency above IP layer. And the point (maintenance of
active transport level sessions) contradicts with : “it is not a
strict requirement to maintenance stable IP address” (later in the
charter). Or does it mean that DMM aims to develop solutions that can
maintain active transport level sessions without maintaining stable IP
address?

>   requirement.

[comment]
please refer the previous comment.
I think we should not exclude the solutions that can maintain stable IP address.

Mobile hosts/routers should not assume that IP
>   are used.

[comment] Since DMM remains backward compatibility with existing IP
mobility protocol. And DSMIPv6 can support IPv4, should we also need
to keep IPv4 support in DMM?

At least IPv6 is assumed to be present in both the mobile

-- 

------
Best Regards,
Dapeng Liu

---

From: jouni korhonen <[email-masked]>
Date: Thu, 22 Dec 2011 08:54:03 +0200

Conny,

On Dec 20, 2011, at 8:54 PM, Conny Larsson wrote:

> Hi Jouni, Julien
> 
> I believe the charter looks good but I would like to ask you if deployment scenarios are covered by the charter or not (I'm thinking of a Informational RFC)?

Not a bad idea but I am a bit reluctant to expand milestones at the moment. Deployment scenarios that are doable using existing technologies deployment scenarios could be documented as part of the best current practices. Obvious deployment scenarios that are seen essential but not doable using existing machinery could go into the gap analysis.

> Let me be a bit more specific. When discussing DMM (in a 3GPP perspective) with people I  get the impression that many operators are interested in the topic but that they have very few peering points. They are not always interested (or they do not see the need) in deploying more peering points since they are expensive. Perhaps the reason for this is related to the current hierarchical architecture and will change with a more distributed architecture.

Distributing mobility and more aggressive use of CoAs does not necessarily imply new peering points. Just being able to avoid few central aggregating gateways (i.e. those nodes that do far more than just packet forwarding) or make use of possible local resources (e.g. some local content caches) could be of significant help already.

> So what do you think? Is there a need for this kind of document?

We could consider that when we actually know more of our current state of the art and possible new enhancements. That would be around rechartering..? Before that I encourage to contribute relevant deployment scenarios to the best current practices and gap analysis documents.

- Jouni

---

From: Conny Larsson <[email-masked]>
Date: Thu, 22 Dec 2011 18:06:30 +0100

Hi Jouni,

Thanks for your reply. You clarified one important thing regarding the 
CoA and peering points, which I was not aware of. I believe relevant 
deployment scenarios to the best current practices and gap analysis 
documents can be enough.

/Conny