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

[<[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] De la part de
> jouni korhonen
> Envoyé : dimanche 18 décembre 2011 23:21
> À : [e-mail]
> Cc : [e-mail] Laganier; jouni korhonen; Jari Arkko
> Objet : Re: [MEXT] The first proposal for the DMM charter
> 
> 
> Folks,
> 
> Based of the "feedback" can I assume folks are mostly happy with the
> current text?
> 
> - Jouni
> 


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

Hi Jouni & Julien,

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

Thanks,
Pierrick

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part 
> de jouni korhonen Envoyé : mercredi 14 décembre 2011 09:54 À : 
> [e-mail] Cc : [e-mail] 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
> 
> 
> ----------------------------------------------------------------------
> -
> --
> 
> Distributed Mobility Management (DMM)
> -------------------------------------
> 
> Charter
> 
>  Current Status: Active
> 
>  Chairs:
>      Julien Laganier <[e-mail]>
>      Jouni Korhonen <[e-mail]>
> 
>  Internet Area Directors:
>      Ralph Droms <[e-mail]>
>      Jari Arkko <[e-mail]>
> 
>  Internet Area Advisor:
>      Jari Arkko <[e-mail]>
> 
>  Mailing Lists:
>      General Discussion: [e-mail]
>      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]. 

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

I suggest to add the following statement:

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

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

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


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

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.

>   Nov 2012 - Evaluate the need for additional working group document(s)
>              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.

>   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.
> 
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext