Re: [MEXT] suggest charter item for distributed mobility work

Jari Arkko <jari.arkko@piuha.net> Thu, 20 January 2011 18:22 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE4B3A704B; Thu, 20 Jan 2011 10:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level:
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg6WUCY7wNtV; Thu, 20 Jan 2011 10:22:36 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D35FC3A7048; Thu, 20 Jan 2011 10:22:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 888A72CC31; Thu, 20 Jan 2011 20:25:18 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILHUFyjDap5t; Thu, 20 Jan 2011 20:25:17 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1C5932CC2D; Thu, 20 Jan 2011 20:25:15 +0200 (EET)
Message-ID: <4D387E0C.8070200@piuha.net>
Date: Thu, 20 Jan 2011 20:25:16 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Sri Gundavelli <sgundave@cisco.com>
References: <C95CE87E.D35B%sgundave@cisco.com>
In-Reply-To: <C95CE87E.D35B%sgundave@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: dmm@ietf.org, "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] suggest charter item for distributed mobility work
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jan 2011 18:22:40 -0000

Sri,

> Thanks for the updated charter text. This looks good to me. Just 
> couple of comments.
>
>     * The approach of closest home agent selection is one aspect of
>       the DMM proposal. I assumed it includes other aspects such as
>       CP/DP separation.  Does the charter text gives such provision
>       for such extensions ?
>

Yes. Its says "for instance".

>     * The BOF discussed the chained models around CMIP/PMIP mobility
>       domains and the optimized routing paths in such context. The
>       potential extensions should be applicable to both
>       client-based/network-based and chained mobility models.
>

I think anything in the area of operational guidance, or usage of 
existing protocols to do some form of distribution or optimized route 
paths would be fair game, IMO.

>     * There were some issues that were raised around CP/DP separation
>       and around the distributed deployment models. There should be
>       analysis on the issues around such deployment models, in
>       relation to centralized models that are deployed today.
>

Again, I think this is included. But I would rather not write all of 
this to the charter explicitly; we might miss some issues that we will 
in any case have to deal with in the documents.


> If the charter text broadly allows for some work around this, probably 
> it should be fine. Finally, glad to see this work not defining a new 
> protocol suite. But bringing value to the existing protocols.

Right.

Jari

>
>
> Regards
> Sri
>
>
> On 1/11/11 2:54 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote:
>
>     All,
>
>     I have been thinking about what to do about the distributed mobility
>     work since our meeting in Beijing. My suggestion is to add a work
>     item
>     to the MEXT charter. Here's the proposed new item:
>
>     Jari
>
>     ------------------------------------------------------------------------
>     Mobility EXTensions for IPv6 (mext)
>     -----------------------------------
>
>      Current Status: Active
>
>      Chairs:
>          Marcelo Bagnulo <marcelo@it.uc3m.es>
>          Julien Laganier <julienl@qualcomm.com>
>
>      Internet Area Directors:
>          Ralph Droms <rdroms.ietf@gmail.com>
>          Jari Arkko <jari.arkko@piuha.net>
>
>      Internet Area Advisor:
>          Jari Arkko <jari.arkko@piuha.net>
>
>      Mailing Lists:
>          General Discussion: mext@ietf.org
>          To Subscribe:       https://www.ietf.org/mailman/listinfo/mext
>          Archive:            http://www.ietf.org/mail-archive/web/mext
>
>     Description of Working Group:
>
>       Mobile IPv6 specifies routing support which permits an IPv6 host to
>       continue using its home address as it moves around the Internet,
>       enabling continuity of sessions. Mobile IPv6 supports
>     transparency above
>       the IP layer, including maintenance of active transport level
>     sessions.
>       In addition, network mobility (NEMO) mechanisms built on top of
>     Mobile
>       IPv6 allow managing the mobility of an entire network, as it
>     changes its
>       point of attachment to the Internet. The base specifications
>     consist of:
>
>       o RFC 3775 (Mobile IPv6)
>       o RFC 3963 (NEMO)
>       o RFC 4877 (Mobile IPv6 Operation with IKEv2)
>       o RFC 5555 (Dual Stack Mobile IPv6)
>       o RFC 5648 (Multiple Care-of Addresses Registration)
>       o RFC 5846 (Binding Revocation)
>       o RFC-to-be (Flow Binding Policy Transport and Flow Binding
>     Policy Format)
>
>       The MEXT Working Group continues the work of the former MIP6,
>     NEMO, and
>       MONAMI6 Working Groups.
>
>       The primary goal of MEXT will be to enhance base IPv6 mobility by
>       continuing work on developments that are required for wide-scale
>       deployments and specific deployment scenarios. Additionally, the
>     working
>       group will ensure that any issues identified by implementation and
>       interoperability experience are addressed, and that the base
>       specifications are maintained. The group will also produce
>     informational
>       documentation, such as design rationale documents or description of
>       specific issues within the protocol.
>
>       The MEXT WG will also explore experimental alternative security
>       mechanisms. The security mechanism specified in the existing
>     standard
>       track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement
>       mechanism that guarantees interoperability between different
>       implementations. The MEXT WG is chartered to deliver one or more
>       experimental alternative mechanisms. All the alternative
>     solutions will
>       be published as experimental RFCs.
>
>       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.
>
>       In addition, the working group will bring to completion earlier
>     work on
>       prefix delegation for NEMO, RADIUS  support for Mobile IPv6,
>     Mobile IPv6
>       operation with firewalls, and home agent reliability specifications.
>
>       Work items related to base specification maintenance include:
>     Create and
>       maintain issue lists that are generated on the basis of
>     implementation
>       and interoperability experience. Address specific issues with
>     specific
>       updates or revisions of the base specification. Currently known
>     specific
>       issues include support for overlapping (private) IPv4 home
>     addresses,
>       negotiation of the protection required for payload traffic, and
>       discovery of the home agent address in IPv4-only networks.
>
>
>     Goals and Milestones:
>       Jun 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to
>     IESG for publication as Informational.
>       Jun 2011 - Submit I-D 'Home agent reliability' to IESG for
>     publication as a Proposed Standard.
>       Aug 2011 - Submit I-Ds on alternative security mechanisms to the
>     IESG for publication as Experimental.
>       Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG
>     for publication as Proposed Standard.
>       Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only
>     networks via DHCP' to IESG for publication as Proposed Standard.
>       Oct 2011 - Submit I-D 'Operational considerations for
>     distributed use of Mobile IPv6' for publication as Informational
>       Dec 2011 - Submit I-D 'Negotiation of the protection for payload
>     traffic' to IESG for publication as Proposed Standard.
>       Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG
>     for publication as a proposed standard.
>
>     ------------------------------------------------------------------------
>                
>      charterjan2011.txt   charterjan2011withdmm.txt   
>       
>     skipping to change at/ line 60/ skipping to change at/ line 60/
>       specific issues within the protocol.   specific issues within
>     the protocol.
>       
>       The MEXT WG will also explore experimental alternative security
>       The MEXT WG will also explore experimental alternative security
>       mechanisms. The security mechanism specified in the existing
>     standard   mechanisms. The security mechanism specified in the
>     existing standard
>       track RFCs (RFC3775bis, RFC4877) remains the mandatory to
>     implement   track RFCs (RFC3775bis, RFC4877) remains the mandatory
>     to implement
>       mechanism that guarantees interoperability between different
>       mechanism that guarantees interoperability between different
>       implementations. The MEXT WG is chartered to deliver one or more
>       implementations. The MEXT WG is chartered to deliver one or more
>       experimental alternative mechanisms. All the alternative
>     solutions will   experimental alternative mechanisms. All the
>     alternative solutions will
>       be published as experimental RFCs.   be published as
>     experimental RFCs.
>       
>      
>        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.
>                                                                                
>       In addition, the working group will bring to completion earlier
>     work on   In addition, the working group will bring to completion
>     earlier work on
>       prefix delegation for NEMO, RADIUS  support for Mobile IPv6,
>     Mobile IPv6   prefix delegation for NEMO, RADIUS  support for
>     Mobile IPv6, Mobile IPv6
>       operation with firewalls, and home agent reliability
>     specifications.   operation with firewalls, and home agent
>     reliability specifications.
>       
>       Work items related to base specification maintenance include:
>     Create and   Work items related to base specification maintenance
>     include: Create and
>       maintain issue lists that are generated on the basis of
>     implementation   maintain issue lists that are generated on the
>     basis of implementation
>       and interoperability experience. Address specific issues with
>     specific   and interoperability experience. Address specific
>     issues with specific
>       updates or revisions of the base specification. Currently known
>     specific   updates or revisions of the base specification.
>     Currently known specific
>       issues include support for overlapping (private) IPv4 home
>     addresses,   issues include support for overlapping (private) IPv4
>     home addresses,
>       negotiation of the protection required for payload traffic, and
>       negotiation of the protection required for payload traffic, and
>       discovery of the home agent address in IPv4-only networks.
>       discovery of the home agent address in IPv4-only networks.
>       
>     Goals and Milestones: Goals and Milestones:
>      
>       Done     - Submit I-D 'Mobile IPv6 Vendor Specific Option' to
>     IESG for publication as a Proposed Standard   Jun 2011 - Submit
>     I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication
>     as Informational.
>       Done     - Submit I-D 'Mobile IPv6 Experimental Allocations' to
>     IESG for publication as a Proposed Standard   Jun 2011 - Submit
>     I-D 'Home agent reliability' to IESG for publication as a Proposed
>     Standard.
>       Done     - Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG
>     for publication as a Proposed Standard.  
>       Done     - Submit I-D 'Motivation for Authentication I-D' to
>     IESG for publication as Informational.  
>       Done     - Submit Multiple CoA Registration to IESG  
>       Done     - Submit I-D 'Goals for AAA HA Interface' to IESG for
>     publication as Informational.  
>       Done     - Submit -00 draft on Route Optimization Needs for
>     Automobile and Highway Deployments  
>       Done     - Submit -00 draft on Route Optimization Needs for
>     Aircraft and Spacecraft Deployments  
>       Done     - Submit I-D 'Mobility Header Home Agent Switch
>     Message' to IESG for publication as a Proposed Standard  
>       Done     - Submit final doc on Route Optimization Needs for
>     Aircraft and Spacecraft Deployments, for Informational  
>       Done     - Submit 00 draft on Binding Revocation  
>       Done     - Submit the final doc on MIB for NEMO Basic Support to
>     the IESG, for Proposed Standard  
>       Done     - Submit draft on Binding Revocation to IESG  
>       Done     - Submit I-D(s) related to specific updates and
>     corrections of RFC 3775 to IESG for publication as Proposed
>     Standard.  
>       Done     - Submit the final doc on Prefix Delegation for NEMO to
>     the IESG, for Proposed Standard  
>       Dec 2010 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG
>     for publication as a proposed standard.  
>       Jan 2011 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to
>     IESG for publication as Informational.  
>       Jan 2011 - Submit I-D 'Home agent reliability' to IESG for
>     publication as a Proposed Standard.  
>       Aug 2011 - Submit I-Ds on alternative security mechanisms to the
>     IESG for publication as Experimental.   Aug 2011 - Submit I-Ds on
>     alternative security mechanisms to the IESG for publication as
>     Experimental.
>       Sep 2011 - Submit I-D 'Overlapping IPv4 address support' to IESG
>     for publication as Proposed Standard.   Sep 2011 - Submit I-D
>     'Overlapping IPv4 address support' to IESG for publication as
>     Proposed Standard.
>       Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only
>     networks via DHCP' to IESG for publication as Proposed Standard.
>       Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only
>     networks via DHCP' to IESG for publication as Proposed Standard.
>      
>        Oct 2011 - Submit I-D 'Operational considerations for
>     distributed use of Mobile IPv6' for publication as Informational
>       Dec 2011 - Submit I-D 'Negotiation of the protection for payload
>     traffic' to IESG for publication as Proposed Standard.   Dec 2011
>     - Submit I-D 'Negotiation of the protection for payload traffic'
>     to IESG for publication as Proposed Standard.
>      
>        Dec 2011 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG
>     for publication as a proposed standard.  
>       
>      End of changes. 4 change blocks.  
>     /18 lines changed or deleted 8 lines changed or added/
>     This html diff was produced by rfcdiff 1.32. The latest version is
>     available from http://www.levkowetz.com/ietf/tools/rfcdiff/   
>     ------------------------------------------------------------------------
>     _______________________________________________
>     MEXT mailing list
>     MEXT@ietf.org
>     https://www.ietf.org/mailman/listinfo/mext
>