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

Hi Jouni, 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of jouni korhonen
> Sent: Monday, January 02, 2012 2:45 AM
> To: liu dapeng
> Cc: [email protected] Laganier; [email protected]
> Subject: Re: [MEXT] The first proposal for the DMM charter
> 
> Dapeng,
> 
> Below is the charter text that was submitted to the next 
> IESG. Does it cover all your concerns?
> 
> - JOuni
> 
> 
> 
> Distributed Mobility Management (DMM)
> -------------------------------------
> 
> Charter
> 
> Current Status: Active
> 
> Chairs:
>     Julien Laganier <[email protected]>
>     Jouni Korhonen <[email protected]>
> 
> Internet Area Directors:
>     Ralph Droms <[email protected]>
>     Jari Arkko <[email protected]>
> 
> Internet Area Advisor:
>     Jari Arkko <[email protected]>
> 
> Mailing Lists:
>     General Discussion: [email protected]
>     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 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].

I don't understand the "should be based on existing IP
mobility protocols". IRON for example provides an
alternative mobility management solution which I believe
has significant advantages over other approaches:

http://tools.ietf.org/html/draft-templin-ironbis-10

Thanks - Fred
[email protected]

>  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.
> 
>  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: 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.
> 
>  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 ' to the IESG forvconsideration
>             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.
> 
> 
> 
> 
> On Dec 21, 2011, at 7:53 PM, liu dapeng wrote:
> 
> > 2011/12/14, jouni korhonen <[email protected]>:
> >> 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 protected]>
> >>     Jouni Korhonen <[email protected]>
> >> 
> >> Internet Area Directors:
> >>     Ralph Droms <[email protected]>
> >>     Jari Arkko <[email protected]>
> >> 
> >> Internet Area Advisor:
> >>     Jari Arkko <[email protected]>
> >> 
> >> Mailing Lists:
> >>     General Discussion: [email protected]
> >>     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.
> > 
> > [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?
> > 
> > 
> >>  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.
> > 
> > [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
> >>  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.
> > 
> > [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
> >>  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.
> >> 
> >> 
> >> _______________________________________________
> >> MEXT mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/mext
> >> 
> > 
> > 
> > -- 
> > 
> > ------
> > Best Regards,
> > Dapeng Liu
> 
> _______________________________________________
> MEXT mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mext
>