From prvs=33168DE642=trust2012@sba-research.org Thu Dec 1 01:12:19 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C9721F842C for ; Thu, 1 Dec 2011 01:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN7fWDgCExoa for ; Thu, 1 Dec 2011 01:12:17 -0800 (PST) Received: from mail.securityresearch.at (mail.securityresearch.at [188.21.236.102]) by ietfa.amsl.com (Postfix) with ESMTP id B381421F844F for ; Thu, 1 Dec 2011 01:12:15 -0800 (PST) Received: from SATVIEEX02.securityresearch.local ([fe80::c5e7:fd42:5118:9799]) by SATVIEEX02.securityresearch.local ([fe80::c5e7:fd42:5118:9799%15]) with mapi id 14.01.0339.001; Thu, 1 Dec 2011 10:12:13 +0100 From: trust2012 To: "mext@ietf.org" Thread-Topic: TRUST 2012 - CfP Thread-Index: AcywCSBCLc+0MndDTV+nnxN7gqR1XAAABqVQAAADOCA= Date: Thu, 1 Dec 2011 09:12:11 +0000 Message-ID: <600C904F06E46446BE46FBE4D5E010CD0862ADE4@SATVIEEX02.securityresearch.local> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.1.150] Content-Type: multipart/alternative; boundary="_000_600C904F06E46446BE46FBE4D5E010CD0862ADE4SATVIEEX02secur_" MIME-Version: 1.0 Subject: [MEXT] TRUST 2012 - CfP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 09:12:19 -0000 --_000_600C904F06E46446BE46FBE4D5E010CD0862ADE4SATVIEEX02secur_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Call for Paper TRUST 2012 13 - 15 June 2012 Vienna, Austria http://www.trust.sba-research.org TRUST 2012 is an international conference on the technical and soci-economi= c aspects of trustworthy infrastructures. It provides an excellent interdis= ciplinary forum for researchers, practitioners, and decision makers to expl= ore new ideas and discuss experiences in building, designing, using and und= erstanding trustworthy computing systems. Building on the success of TRUST 2011 (held in Pittsburgh, USA) and TRUST 2= 010 (held in Berlin, Germany) TRUST 2009 (held in Oxford, UK), this confere= nce focuses on trusted and trustworthy computing, both from the technical a= nd social perspectives. The conference itself has two main strands, one dev= oted to technical aspects and one devoted to the socio-economic aspects of = trusted computing. Important dates: Submission due: 22 February 2012, 23:59 UTC Notification: 25 March 2012 Camera ready: 09 April 2012 Conference: 13-15 June 2012 The conference solicits original papers on any aspect (technical or social = and economic) of the design, application and usage of trusted and trustwort= hy computing, which concerns a broad range of concepts including trustworth= y infrastructures, cloud computing, services, hardware, software and protoc= ols. Topics of interest include, but are not limited to: Technical Strand: Architecture and implementation technologies for trusted platforms and trus= tworthy infrastructures Trust, Security and Privacy in embedded systems Trust, Security and Privacy in social networks Trusted mobile platforms and mobile phone security Implementations of trusted computing (hardware and software) Applications of trusted computing Trustworthy infrastructures and services for cloud computing (including res= ilience) Attestation and integrity verification Cryptographic aspects of trusted and trustworthy computing Design, implementation and analysis of security hardware, i.e., hardware wi= th cryptographic and security functions, physically unclonable functions (P= UFs) Intrusion resilience in trusted computing Virtualization for trusted platforms Secure storage Security policy and management of trusted computing Access control for trusted platforms Privacy aspects of trusted computing Verification of trusted computing architectures Usability and end-user interactions with trusted platforms Limitations of trusted computing Socio-economic Strand: Usability and user perceptions of trustworthy systems and risks Effects of trustworthy systems upon user, corporate, and governmental behav= ior Economic drivers for trustworthy systems in corporate environment The impact of trustworthy systems in enhancing trust in cloud-like infrastr= uctures The adequacy of guarantees provided by trustworthy systems for systems crit= ically dependent upon trust, such as elections and government oversight The impact of trustworthy systems upon digital forensics, police investigat= ions and court proceedings Game theoretical approaches to modeling or designing trustworthy systems Approaches to model and simulate scenarios of how trustworthy systems would= be used in corporate environments and in personal space Experimental economics studies of trustworthiness The interplay between privacy, privacy enhancing technologies and trustwort= hy systems Critiques of trustworthy systems Best regards Yvonne Poul Organisation TRUST 2012 --_000_600C904F06E46446BE46FBE4D5E010CD0862ADE4SATVIEEX02secur_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Call for Paper= TRUST 2012

13 – 15 June 2012

Vienna, Austria

http://www.t= rust.sba-research.org

&n= bsp;

TRUST 2012 is an international = conference on the technical and soci-economic aspects of trustworthy infras= tructures. It provides an excellent interdisciplinary forum for researchers= , practitioners, and decision makers to explore new ideas and discuss experiences in building, designing, using= and understanding trustworthy computing systems.

Building on the success of TRUS= T 2011 (held in Pittsburgh, USA) and TRUST 2010 (held in Berlin, Germany) T= RUST 2009 (held in Oxford, UK), this conference focuses on trusted and trus= tworthy computing, both from the technical and social perspectives. The conference itself has two main strands, one d= evoted to technical aspects and one devoted to the socio-economic aspects o= f trusted computing.

 

Important dates:<= /span>

Submission due: 22 February 201= 2, 23:59 UTC

Notification: 25 March 2012

Camera ready: 09 April 2012

Conference: 13-15 June 2012

 

The conference solicits origina= l papers on any aspect (technical or social and economic) of the design, ap= plication and usage of trusted and trustworthy computing, which concerns a = broad range of concepts including trustworthy infrastructures, cloud computing, services, hardware, software and protoco= ls. Topics of interest include, but are not limited to:

Technical Strand:=

Architecture and implementation= technologies for trusted platforms and trustworthy infrastructures

Trust, Security and Privacy in = embedded systems

Trust, Security and Privacy in = social networks

Trusted mobile platforms and mo= bile phone security

Implementations of trusted comp= uting (hardware and software)

Applications of trusted computi= ng

Trustworthy infrastructures and= services for cloud computing (including resilience)

Attestation and integrity verif= ication

Cryptographic aspects of truste= d and trustworthy computing

Design, implementation and anal= ysis of security hardware, i.e., hardware with cryptographic and security f= unctions, physically unclonable functions (PUFs)

Intrusion resilience in trusted= computing

Virtualization for trusted plat= forms

Secure storage

Security policy and management = of trusted computing

Access control for trusted plat= forms

Privacy aspects of trusted comp= uting

Verification of trusted computi= ng architectures

Usability and end-user interact= ions with trusted platforms

Limitations of trusted computin= g

Socio-economic Strand:<= /o:p>

Usability and user perceptions = of trustworthy systems and risks

Effects of trustworthy systems = upon user, corporate, and governmental behavior

Economic drivers for trustworth= y systems in corporate environment

The impact of trustworthy syste= ms in enhancing trust in cloud-like infrastructures

The adequacy of guarantees prov= ided by trustworthy systems for systems critically dependent upon trust, su= ch as elections and government oversight

The impact of trustworthy syste= ms upon digital forensics, police investigations and court proceedings=

Game theoretical approaches to = modeling or designing trustworthy systems

Approaches to model and simulat= e scenarios of how trustworthy systems would be used in corporate environme= nts and in personal space

Experimental economics studies = of trustworthiness

The interplay between privacy, = privacy enhancing technologies and trustworthy systems

Critiques of trustworthy systems

 

Best regards

Yvonne Poul

Organisation TRUST 2012

 

 

--_000_600C904F06E46446BE46FBE4D5E010CD0862ADE4SATVIEEX02secur_-- From jong-hyouk.lee@inria.fr Sun Dec 4 08:36:19 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2A021F8540 for ; Sun, 4 Dec 2011 08:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyvLe4vIGN88 for ; Sun, 4 Dec 2011 08:36:18 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 64BEA21F8532 for ; Sun, 4 Dec 2011 08:36:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,294,1320620400"; d="scan'208";a="133890429" Received: from ver78-4-82-244-181-122.fbx.proxad.net (HELO [192.168.0.16]) ([82.244.181.122]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 04 Dec 2011 17:36:15 +0100 Message-ID: <4EDBA17E.3010009@inria.fr> Date: Sun, 04 Dec 2011 17:36:14 +0100 From: Jong-Hyouk Lee Organization: INRIA User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: sjkoh@knu.ac.kr, mext Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MEXT] Comments on "draft-sjkoh-mext-pmip-dmc-03" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 16:36:19 -0000 Dear authors, I read the draft "draft-sjkoh-mext-pmip-dmc-03" and have comments/questions: How is an MN's handover handled in SD-PMIP? For instance: 1) It's not clear how a prefix of the MN is provided; and 2) it is also not clear from the draft how ongoing packets (destined to the MN or sent from the MN) are handled during handovers. Thanks. -- IMARA Team, INRIA, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com #webpage: http://sites.google.com/site/hurryon/ From jong-hyouk.lee@inria.fr Mon Dec 5 01:50:22 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B221F8B1D for ; Mon, 5 Dec 2011 01:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3t6PlszemCk for ; Mon, 5 Dec 2011 01:50:22 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id DD45921F8B1C for ; Mon, 5 Dec 2011 01:50:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,298,1320620400"; d="scan'208";a="133960130" Received: from dhcp-rocq-134.inria.fr (HELO [128.93.62.134]) ([128.93.62.134]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 05 Dec 2011 10:50:19 +0100 Message-ID: <4EDC93DA.6030309@inria.fr> Date: Mon, 05 Dec 2011 10:50:18 +0100 From: Jong-Hyouk Lee Organization: INRIA User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: pierrick.seite@orange.com, mext Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MEXT] Comments on "draft-seite-mext-dma-00" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 09:50:23 -0000 Dear authors, I read the draft "draft-seite-mext-dma-00" and have comments/questions: 1. The mobility support described in the draft seems for client mobility. In other words, it's hard to apply the suggested dynamic mobility anchoring scheme into a node dedicated for continuous services to clients. 2. In the suggested dynamic mobility anchoring scheme, data packets of a communication session established in a previous access network (MAR1) is forwarded from MAR1 to the current MAR. This data packet forwarding must be continuous as the address used in the communication session is continuously used. Note that the MN is not only the communication session initiator, but the CN could be. The data packet forwarding must impact the whole network performance as the session duration is longer, session is heavier, or mobility is higher. 3. Since the suggested dynamic mobility anchoring scheme allows the MN to send/receive data packets having different network prefix compared with that of the current access network, I'm not sure if the suggested one properly works in existing network security mechanisms. For instance, authors should address conflicts over ingress filtering mechanisms. 4. Since the suggested dynamic mobility anchoring scheme allows the MN to establish a communication session with its CN via a new address obtained in a new network. In other words, 1) the MN establishes its communication session with the CN via HoA1 at MAR1; 2) when the MN moves to MAR2, it possibly establishes a new communication session with the CN via HoA2 at MAR2 in order to avoid the overhead of data packet forwarding. This means that even if the MN wants to keep the same communication session with the CN, it must be re-establishes, i.e., making a new communication session with the CN. In addition, making the new communication session requires security operations again between the MN and CN. Authors should think the cost in handovers: continuous communication session maintaining vs. new session establishment. 5. Could you describe little bit more about the entity storing the session DB for all MNs? Hummm...we're talking about DMM, but the entity is a centralized entity in an architectural view; all MARs contacts for MN's session information. Thanks. -- IMARA Team, INRIA, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com #webpage: http://sites.google.com/site/hurryon/ From pierrick.seite@orange.com Mon Dec 5 03:11:10 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B127D21F8AF0 for ; Mon, 5 Dec 2011 03:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rnQ1SMKLR2R for ; Mon, 5 Dec 2011 03:10:57 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5621F8ACC for ; Mon, 5 Dec 2011 03:10:55 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9CEE46DC002; Mon, 5 Dec 2011 12:21:32 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 96C6E6DC001; Mon, 5 Dec 2011 12:21:32 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Dec 2011 12:10:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Dec 2011 12:10:52 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202127D29@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EDC93DA.6030309@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on "draft-seite-mext-dma-00" Thread-Index: AcyzM0zgRsylgXHyROOOMmXiXvOlJgAAxTbg References: <4EDC93DA.6030309@inria.fr> From: To: , X-OriginalArrivalTime: 05 Dec 2011 11:10:54.0079 (UTC) FILETIME=[8E2140F0:01CCB33E] Subject: Re: [MEXT] Comments on "draft-seite-mext-dma-00" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 11:11:10 -0000 Hello, Thanks for the review. Please see inline. Pierrick > -----Message d'origine----- > De=A0: Jong-Hyouk Lee [mailto:jong-hyouk.lee@inria.fr] > Envoy=E9=A0: lundi 5 d=E9cembre 2011 10:50 > =C0=A0: SEITE Pierrick RD-RESA-REN; mext > Objet=A0: Comments on "draft-seite-mext-dma-00" >=20 > Dear authors, >=20 > I read the draft "draft-seite-mext-dma-00" and have = comments/questions: >=20 > 1. The mobility support described in the draft seems for client > mobility. In other words, it's hard to apply the suggested dynamic > mobility anchoring scheme into a node dedicated for continuous = services > to clients. Actually, the solution applies to network based mobility management. The = I-D describes the deployment of PMIPv6 in a distributed fashion. >=20 > 2. In the suggested dynamic mobility anchoring scheme, data packets of = a > communication session established in a previous access network (MAR1) = is > forwarded from MAR1 to the current MAR. This data packet forwarding = must > be continuous as the address used in the communication session is > continuously used. Note that the MN is not only the communication > session initiator, but the CN could be.=20 Right, we have still to address incoming communications. The data packet forwarding must > impact the whole network performance as the session duration is = longer, > session is heavier, or mobility is higher. >=20 > 3. Since the suggested dynamic mobility anchoring scheme allows the MN > to send/receive data packets having different network prefix compared > with that of the current access network, I'm not sure if the suggested > one properly works in existing network security mechanisms. For > instance, authors should address conflicts over ingress filtering > mechanisms. >=20 Agreed. > 4. Since the suggested dynamic mobility anchoring scheme allows the MN > to establish a communication session with its CN via a new address > obtained in a new network. In other words, 1) the MN establishes its > communication session with the CN via HoA1 at MAR1; 2) when the MN = moves > to MAR2, it possibly establishes a new communication session with the = CN > via HoA2 at MAR2 in order to avoid the overhead of data packet > forwarding. This means that even if the MN wants to keep the same > communication session with the CN, it must be re-establishes, i.e., > making a new communication session with the CN.=20 No, in that case session continuity is ensures as per PMIP where MAR1 = and MAR2 play respectively the LMA and MAG role.=20 In addition, making the > new communication session requires security operations again between = the > MN and CN. Authors should think the cost in handovers: continuous > communication session maintaining vs. new session establishment. >=20 Actually, I'm not sure to understand your point... > 5. Could you describe little bit more about the entity storing the > session DB for all MNs? Hummm...we're talking about DMM,=20 but the entity is a centralized entity in an architectural view; all = MARs contacts for > MN's session information. >=20 Here we are going on the separation of the control plane and data plane. = The data plane is distributed while a part of the data plane is = centralized for localization purpose. Several approaches are possible = and have been described in = http://tools.ietf.org/html/draft-yokota-dmm-scenario-00: fully = distribution and partially distribution are both possible. With Fully = distributed MM, both control and data planes are distributed while = partial distribution focuses on distribution on the data plane (arguing = that The volume of data traffic is much higher than that of control = traffic). MN's localisation is an issue in fully distributed mobility = architectures; DHT or flooding are possible solutions but control/data = plane separation allows more simple localization scheme. I think it is = worth considering control/data plane separation in a first approach, = while I agree that the fully distribution is more optimal. > Thanks. >=20 > -- > IMARA Team, INRIA, France > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >=20 > #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com > #webpage: http://sites.google.com/site/hurryon/ From jong-hyouk.lee@inria.fr Mon Dec 5 04:16:12 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5723921F8B82 for ; Mon, 5 Dec 2011 04:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WMMpeQBw8CU for ; Mon, 5 Dec 2011 04:16:11 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 751C221F8B03 for ; Mon, 5 Dec 2011 04:16:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,298,1320620400"; d="scan'208,217";a="133985657" Received: from dhcp-rocq-134.inria.fr (HELO [128.93.62.134]) ([128.93.62.134]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 05 Dec 2011 13:16:08 +0100 Message-ID: <4EDCB608.6000309@inria.fr> Date: Mon, 05 Dec 2011 13:16:08 +0100 From: Jong-Hyouk Lee Organization: INRIA, France User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: pierrick.seite@orange.com References: <4EDC93DA.6030309@inria.fr> <843DA8228A1BA74CA31FB4E111A5C46202127D29@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202127D29@ftrdmel0.rd.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------070908040300070306010708" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on "draft-seite-mext-dma-00" X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 12:16:12 -0000 This is a multi-part message in MIME format. --------------070908040300070306010708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Dear Pierrick, thanks for your prompt response. Let me explain a little bit more about=20 the fourth point "cost in handovers: continuous communication session=20 maintaining vs. new session establishment". I thought that the proposed scheme would possibly provide an adaptive=20 communication session handling depending on session contexts, MN's=20 characteristics, and network configuration, but as you replied, the=20 proposed scheme in the draft do not support this (and you do not=20 consider it even). However, it is worth thinking of it. Suppose MN1 is a = mobile node having a heavy communication session with its CN. Then, for=20 MN1, in some cases, it's better to re-establish the heavy communication=20 session with the new address at the new access network; this should=20 reduce tunneling overhead, but it is all depending on the session's=20 context (e.g., session type, breakable or not, etc), MN's=20 characteristics (e.g., MN's type, mobility rate, etc) and network=20 configuration (wireless signaling range, inter-MAG congestion status, etc= ). In addition, regarding the separation of the control plane and data=20 plane, thanks to your explanation, it's clear to me. But, it should be=20 written in the draft to make it clearer...I suppose. Cheers. On 12/05/2011 12:10 PM, pierrick.seite@orange.com wrote: > Hello, > > Thanks for the review. Please see inline. > > Pierrick > >> -----Message d'origine----- >> De : Jong-Hyouk Lee [mailto:jong-hyouk.lee@inria.fr] >> Envoy=E9 : lundi 5 d=E9cembre 2011 10:50 >> =C0 : SEITE Pierrick RD-RESA-REN; mext >> Objet : Comments on "draft-seite-mext-dma-00" >> >> Dear authors, >> >> I read the draft "draft-seite-mext-dma-00" and have comments/questions= : >> >> 1. The mobility support described in the draft seems for client >> mobility. In other words, it's hard to apply the suggested dynamic >> mobility anchoring scheme into a node dedicated for continuous service= s >> to clients. > Actually, the solution applies to network based mobility management. Th= e I-D describes the deployment of PMIPv6 in a distributed fashion. > >> 2. In the suggested dynamic mobility anchoring scheme, data packets of= a >> communication session established in a previous access network (MAR1) = is >> forwarded from MAR1 to the current MAR. This data packet forwarding mu= st >> be continuous as the address used in the communication session is >> continuously used. Note that the MN is not only the communication >> session initiator, but the CN could be. > Right, we have still to address incoming communications. > > The data packet forwarding must >> impact the whole network performance as the session duration is longer= , >> session is heavier, or mobility is higher. >> >> 3. Since the suggested dynamic mobility anchoring scheme allows the MN= >> to send/receive data packets having different network prefix compared >> with that of the current access network, I'm not sure if the suggested= >> one properly works in existing network security mechanisms. For >> instance, authors should address conflicts over ingress filtering >> mechanisms. >> > Agreed. > >> 4. Since the suggested dynamic mobility anchoring scheme allows the MN= >> to establish a communication session with its CN via a new address >> obtained in a new network. In other words, 1) the MN establishes its >> communication session with the CN via HoA1 at MAR1; 2) when the MN mov= es >> to MAR2, it possibly establishes a new communication session with the = CN >> via HoA2 at MAR2 in order to avoid the overhead of data packet >> forwarding. This means that even if the MN wants to keep the same >> communication session with the CN, it must be re-establishes, i.e., >> making a new communication session with the CN. > No, in that case session continuity is ensures as per PMIP where MAR1 a= nd MAR2 play respectively the LMA and MAG role. > > In addition, making the >> new communication session requires security operations again between t= he >> MN and CN. Authors should think the cost in handovers: continuous >> communication session maintaining vs. new session establishment. >> > Actually, I'm not sure to understand your point... > >> 5. Could you describe little bit more about the entity storing the >> session DB for all MNs? Hummm...we're talking about DMM, > but the entity is a centralized entity in an architectural view; all MA= Rs contacts for >> MN's session information. >> > Here we are going on the separation of the control plane and data plane= =2E The data plane is distributed while a part of the data plane is centr= alized for localization purpose. Several approaches are possible and hav= e been described in http://tools.ietf.org/html/draft-yokota-dmm-scenario-= 00: fully distribution and partially distribution are both possible. With= Fully distributed MM, both control and data planes are distributed while= partial distribution focuses on distribution on the data plane (arguing = that The volume of data traffic is much higher than that of control traff= ic). MN's localisation is an issue in fully distributed mobility architec= tures; DHT or flooding are possible solutions but control/data plane sepa= ration allows more simple localization scheme. I think it is worth consid= ering control/data plane separation in a first approach, while I agree th= at the fully distribution is more optimal. > >> Thanks. >> >> -- >> IMARA Team, INRIA, France >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> >> #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com >> #webpage: http://sites.google.com/site/hurryon/ --=20 IMARA Team, INRIA, France Jong-Hyouk Lee, living somewhere between=20 /dev/null and /dev/random #email: hurryon (at) gmail.com ||=20 jong-hyouk.lee (at) inria.fr #webpage: http://sites.google.com/site/hurry= on/ --------------070908040300070306010708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Pierrick,

thanks for your prompt response. Let me explain a little bit more about the fourth point "cost in handovers: continuous communication session maintaining vs. new session establishment".

I thought that the proposed scheme would possibly provide an adaptive communication session handling depending on session contexts, MN's characteristics, and network configuration, but as you replied, the proposed scheme in the draft do not support this (and you do not consider it even). However, it is worth thinking of it. Suppose MN1 is a mobile node having a heavy communication session with its CN. Then, for MN1, in some cases, it's better to re-establish the heavy communication session with the new address at the new access network; this should reduce tunneling overhead, but it is all depending on the session's context (e.g., session type, breakable or not, etc), MN's characteristics (e.g., MN's type, mobility rate, etc) and network configuration (wireless signaling range, inter-MAG congestion status, etc).

In addition, regarding the separation of the control plane and data plane, thanks to your explanation, it's clear to me. But, it should be written in the draft to make it clearer...I suppose.

Cheers.


On 12/05/2011 12:10 PM, pierrick.seite@orange.com wrote: 
Hello,

Thanks for the review. Please see inline.

Pierrick


-----Message d'origine-----
De : Jong-Hyouk Lee [mailto:jong-hyouk.lee@inria.fr]
Envoyé : lundi 5 décembre 2011 10:50
À : SEITE Pierrick RD-RESA-REN; mext
Objet : Comments on "draft-seite-mext-dma-00"

Dear authors,

I read the draft "draft-seite-mext-dma-00" and have comments/questions:

1. The mobility support described in the draft seems for client
mobility. In other words, it's hard to apply the suggested dynamic
mobility anchoring scheme into a node dedicated for continuous services
to clients.

Actually, the solution applies to network based mobility management. The I-D describes the deployment of PMIPv6 in a distributed fashion.


2. In the suggested dynamic mobility anchoring scheme, data packets of a
communication session established in a previous access network (MAR1) is
forwarded from MAR1 to the current MAR. This data packet forwarding must
be continuous as the address used in the communication session is
continuously used. Note that the MN is not only the communication
session initiator, but the CN could be. 

Right, we have still to address incoming communications.

The data packet forwarding must

impact the whole network performance as the session duration is longer,
session is heavier, or mobility is higher.

3. Since the suggested dynamic mobility anchoring scheme allows the MN
to send/receive data packets having different network prefix compared
with that of the current access network, I'm not sure if the suggested
one properly works in existing network security mechanisms. For
instance, authors should address conflicts over ingress filtering
mechanisms.


Agreed.


4. Since the suggested dynamic mobility anchoring scheme allows the MN
to establish a communication session with its CN via a new address
obtained in a new network. In other words, 1) the MN establishes its
communication session with the CN via HoA1 at MAR1; 2) when the MN moves
to MAR2, it possibly establishes a new communication session with the CN
via HoA2 at MAR2 in order to avoid the overhead of data packet
forwarding. This means that even if the MN wants to keep the same
communication session with the CN, it must be re-establishes, i.e.,
making a new communication session with the CN. 

No, in that case session continuity is ensures as per PMIP where MAR1 and MAR2 play respectively the LMA and MAG role. 

In addition, making the

new communication session requires security operations again between the
MN and CN. Authors should think the cost in handovers: continuous
communication session maintaining vs. new session establishment.


Actually, I'm not sure to understand your point...


5. Could you describe little bit more about the entity storing the
session DB for all MNs? Hummm...we're talking about DMM, 

but the entity is a centralized entity in an architectural view; all MARs contacts for

MN's session information.


Here we are going on the separation of the control plane and data plane. The data plane is distributed while a part of the data plane is centralized for localization purpose.  Several approaches are possible and have been described in http://tools.ietf.org/html/draft-yokota-dmm-scenario-00: fully distribution and partially distribution are both possible. With Fully distributed MM, both control and data planes are distributed while partial distribution focuses on distribution on the data plane (arguing that The volume of data traffic is much higher than that of control traffic). MN's localisation is an issue in fully distributed mobility architectures; DHT or flooding are possible solutions but control/data plane separation allows more simple localization scheme. I think it is worth considering control/data plane separation in a first approach, while I agree that the fully dist
ribution is more optimal.


Thanks.

--
IMARA Team, INRIA, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com
#webpage: http://sites.google.com/site/hurryon/


    

    

    
-- 

      IMARA Team, INRIA, France
      Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
      #email: hurryon (at) gmail.com || jong-hyouk.lee (at) inria.fr
      #webpage: http://sites.google.com/site/hurryon/

  


--------------070908040300070306010708--

From jiin16@gmail.com  Mon Dec  5 19:01:41 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4167E11E80A1 for ; Mon,  5 Dec 2011 19:01:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVLOjB-ld0Bs for ; Mon,  5 Dec 2011 19:01:40 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96CA21F0C63 for ; Mon,  5 Dec 2011 19:01:40 -0800 (PST)
Received: by ywm13 with SMTP id 13so5827408ywm.31 for ; Mon, 05 Dec 2011 19:01:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=OiN9yczAQXPncGsT7B0BaZ21ACRCv8X/TI0PmWWxGvw=; b=UN6/R4y4HnTd3i5d0QwMtVVo+6WaYl5bwm4dqkN9rE8BxNw8Les2ciMxqv3J+uXDOS Y5V+7jsMXRWAGWFXRh58B+RZ3pIhaEWunOnQjX02RXYwEMXKNbKqSGPDqFxkoWRqC9we A8sPHiNUNB27cD0UK0qfSpIojzJLYJTmv4i9w=
Received: by 10.236.190.197 with SMTP id e45mr16339253yhn.101.1323140500169; Mon, 05 Dec 2011 19:01:40 -0800 (PST)
Received: from neobooriPC ([155.230.105.157]) by mx.google.com with ESMTPS id l19sm56972461anc.14.2011.12.05.19.01.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Dec 2011 19:01:39 -0800 (PST)
From: "Ji-In Kim" 
To: "'Jong-Hyouk Lee'" , "'mext'" 
References: <4EDBA17E.3010009@inria.fr>
In-Reply-To: <4EDBA17E.3010009@inria.fr>
Date: Tue, 6 Dec 2011 12:01:33 +0900
Message-ID: <022501ccb3c3$5ee5e0e0$1cb1a2a0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQIsD39K8Z15SVregNkFoj6aHglaH5UPZfvw
Content-Language: ko
Cc: =?ks_c_5601-1987?B?sO28rsHWsbO89rTU?= 
Subject: Re: [MEXT] Comments on "draft-sjkoh-mext-pmip-dmc-03"
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 03:01:41 -0000

Dear Jong-Hyuok Lee,

Thank you for the valuable comments. Please see my inline responses.

1) We suppose that both MN and CN are in the same domain in the S-PMIP and
SD-PMIP. So, all of the nodes in SD-PMIP have the same prefix.
2) In the draft, we didn't consider the handover scenario yet. However, we
will revise the draft to include the handover scenarios within this month.


Best Regards, Ji-In Kim
----------------------------------------------------------------------
Ph.D student, Communications Protocols Lab, Kyungpook National University.
1370 Sankyuk-dong, Buk-gu, Daegu, Korea.
E-mail: jiin16@gmail.com 
Tel: 82-53-940-8608 C.P: 82-10-9371-1324

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of
Jong-Hyouk Lee
> Sent: Monday, December 05, 2011 1:36 AM
> To: sjkoh@knu.ac.kr; mext
> Subject: [MEXT] Comments on "draft-sjkoh-mext-pmip-dmc-03"
>
> Dear authors,
>
> I read the draft "draft-sjkoh-mext-pmip-dmc-03" and have
comments/questions:
>
> How is an MN's handover handled in SD-PMIP? For instance: 1) It's not
clear how a prefix of the MN is provided; and 2) it is also not clear from
the draft how ongoing packets (destined to the MN or sent from the
> MN) are handled during handovers.
>
> Thanks.
>
> --
> IMARA Team, INRIA, France
> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
>
> #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com
> #webpage: http://sites.google.com/site/hurryon/
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext


From jong-hyouk.lee@inria.fr  Tue Dec  6 12:08:21 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF1F21F846D for ; Tue,  6 Dec 2011 12:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbdC4tvNr2Wi for ; Tue,  6 Dec 2011 12:08:20 -0800 (PST)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72021F846C for ; Tue,  6 Dec 2011 12:08:20 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,308,1320620400"; d="scan'208";a="134226807"
Received: from ver78-4-82-244-181-122.fbx.proxad.net (HELO [192.168.0.12]) ([82.244.181.122]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 06 Dec 2011 21:08:19 +0100
Message-ID: <4EDE7631.5020708@inria.fr>
Date: Tue, 06 Dec 2011 21:08:17 +0100
From: Jong-Hyouk Lee 
Organization: INRIA, France
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Ji-In Kim 
References: <4EDBA17E.3010009@inria.fr> <022501ccb3c3$5ee5e0e0$1cb1a2a0$@gmail.com>
In-Reply-To: <022501ccb3c3$5ee5e0e0$1cb1a2a0$@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'mext' , =?UTF-8?B?6rOg7ISd7KO86rWQ7IiY64uY?= 
Subject: Re: [MEXT] Comments on "draft-sjkoh-mext-pmip-dmc-03"
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 20:08:21 -0000

Dear Ji-In Kim,

I do not think that all mobile nodes have the same prefix in a SD-PMIP 
domain consisting of MAGs. I thought that a network prefix assigned to a 
mobile node is managed by a serving MAG. Are you really considering that 
all of the nodes in the SD-PMIP domain have the same prefix?

Cheers.

On Tue 06 Dec 2011 04:01:33 AM CET, Ji-In Kim wrote:
>
> Dear Jong-Hyuok Lee,
>
> Thank you for the valuable comments. Please see my inline responses.
>
> 1) We suppose that both MN and CN are in the same domain in the S-PMIP and
> SD-PMIP. So, all of the nodes in SD-PMIP have the same prefix.
> 2) In the draft, we didn't consider the handover scenario yet. However, we
> will revise the draft to include the handover scenarios within this month.
>
>
> Best Regards, Ji-In Kim
> ----------------------------------------------------------------------
> Ph.D student, Communications Protocols Lab, Kyungpook National University.
> 1370 Sankyuk-dong, Buk-gu, Daegu, Korea.
> E-mail: jiin16@gmail.com
> Tel: 82-53-940-8608 C.P: 82-10-9371-1324
>
>>
>> -----Original Message-----
>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of
>
> Jong-Hyouk Lee
>>
>> Sent: Monday, December 05, 2011 1:36 AM
>> To: sjkoh@knu.ac.kr; mext
>> Subject: [MEXT] Comments on "draft-sjkoh-mext-pmip-dmc-03"
>>
>> Dear authors,
>>
>> I read the draft "draft-sjkoh-mext-pmip-dmc-03" and have
>
> comments/questions:
>>
>>
>> How is an MN's handover handled in SD-PMIP? For instance: 1) It's not
>
> clear how a prefix of the MN is provided; and 2) it is also not clear from
> the draft how ongoing packets (destined to the MN or sent from the
>>
>> MN) are handled during handovers.
>>
>> Thanks.
>>
>> --
>> IMARA Team, INRIA, France
>> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
>>
>> #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com
>> #webpage: http://sites.google.com/site/hurryon/
>>
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>
>
> -- 
> IMARA Team, INRIA, France
> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
>
> #email: hurryon (at) gmail.com || jong-hyouk.lee (at) inria.fr
> #webpage: http://sites.google.com/site/hurryon/

From jong-hyouk.lee@inria.fr  Tue Dec  6 15:20:18 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6839D21F8BB2 for ; Tue,  6 Dec 2011 15:20:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level: 
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEHqKr76jWZA for ; Tue,  6 Dec 2011 15:20:17 -0800 (PST)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 02AB321F8BC3 for ; Tue,  6 Dec 2011 15:20:15 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,309,1320620400"; d="scan'208";a="122310955"
Received: from ver78-4-82-244-181-122.fbx.proxad.net (HELO [192.168.0.12]) ([82.244.181.122]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 07 Dec 2011 00:20:14 +0100
Message-ID: <4EDEA32D.20705@inria.fr>
Date: Wed, 07 Dec 2011 00:20:13 +0100
From: Jong-Hyouk Lee 
Organization: INRIA, France
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: =?UTF-8?B?Q2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2Fubw==?= , mext 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [MEXT] Comments on "draft-bernardos-mext-dmm-pmip-01"
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 23:20:18 -0000

Hi Carlos,

I read the draft "draft-bernardos-mext-dmm-pmip-01" and have 
comments/questions:

1. I'd like to avoid non-technical comments, but I should mention it. In 
Section 3, the following sentence "The purpose of Distributed Mobility 
Management approaches is to overcome the limitations of the traditional 
centralized mobility management by bringing the mobility anchor closer 
to the MN." should be revised. Brining the mobility anchor closer to MNs 
is to form a flattened architecture, not for DMM. ;)

2. In Section 3.2, even if you didn't explicitly describe, the proposed 
one could avoid a conflict over ingress filtering at MAARs. For 
instance, in Figure 2, MAAR2 updates its routing information after it 
receives the PBA message containing prefixes associated with the mobile 
node. Then, for addressing ingress filtering issues with the prefixes, 
MAAR2 is required to update its ingress filtering list (e.g., of a 
firewall) with the prefixes. With this way (as an example), the conflict 
over ingress filtering is solved.

3. In Section 3.2, you gave the following sentence "The drawback can be 
mitigated introducing a timeout at the CMD, by which, after its 
expiration, all the PBAs so far collected are transmitted, and the 
remaining are sent later upon their arrival." Hummm...actually, it does 
not help to mitigate the problem; it makes a bigger problem. Suppose 
that a mobile node has five prefixes, i.e., P1 (the prefix obtained from 
the first MAAR), P2, P3, P4, and P5 (the prefix obtained from the 
serving MAAR). Let t denotes the timer value at the CMD. Now...suppose 
that the transmission times of PBAs containing P1 and P2 are bigger than 
t. The CMD thus closes its waiting and sends out the PBA message 
containing only P3 and P4. Then, what are you expecting at the serving 
MAAR (MAAR5)? Since this guy now updates its routing table for the 
mobile node with only P3, P4, and P5, incoming packets associated with 
P1 and P2 to the mobile node are lost and outgoing packets with P1 and 
P2 are also definitely filtered (due to no ingress filtering list 
update). Those are happened during the time gap between the arrival of 
PBA (P3 and P4) and the arrival of PBA (P1 and P2) sent from the CMD to 
the serving MAAR. In addition, you didn't give a detail of handling of 
the late arrivals; shall the CMD wait another t for collecting and wait 
again for collecting rest all? Moreover, why does the CMD wait to 
collect all PBAs from other MAARs?

4. In addition, the approach of "CMD as PBU/PBA relay" described in 
Section 3.2 must cause long registration latency as the mobile node 
continuously moves around the domain consisted of MAARs. Moreover, I'm 
also concern about the routing loop as the mobile node moves around the 
domain and visits its previous locations again; special treatments for 
eliminating the routing loop are required at the CMD.

5. In Section 3.3, you introduce the approach of "CMD as MAAR locator" 
that seems for reducing latency compared to the approach of "CMD as 
PBU/PBA relay". However, I have doubt about the approach of "CMD as MAAR 
locator". Look at Figure 3. As shown, MAAR2 will allow any data 
transmission associated with P1 (i.e., mobile node's prefix assigned in 
MAAR1) at his access network without any confirmation from the CMD. 
Hummm...don't we need to check P1's validation? Without involvement of 
the CMD, it's hard to check prefix (or previous binding information)'s 
validation; revoked? expired? Hummm...at Figure 3, MAAR2 does not know 
such things, but he will allow the data transmission continuously.

6. The approach "CMD as PBU/PBA proxy" introduced in Section 3.4 also 
brings an issue. In short, look at Figure 4, without any confirmation 
from MAAR1, MAAR2 updates its routing information for P1. How about if 
MAAR1 does not properly work at the moment? Even MAAR1 sends its message 
to the CMD, but there is no way to provide it to MAAR2.

I hope...my comments help you to figure out ways to overtime these 
problems/issues for your next draft.

Cheers.

-- 
IMARA Team, INRIA, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: hurryon (at) gmail.com || jong-hyouk.lee (at) inria.fr
#webpage: http://sites.google.com/site/hurryon/


From cjbc@it.uc3m.es  Thu Dec  8 03:32:34 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE8021F891D for ; Thu,  8 Dec 2011 03:32:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFwa4ZtilNk8 for ; Thu,  8 Dec 2011 03:32:30 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA3A21F8A62 for ; Thu,  8 Dec 2011 03:32:30 -0800 (PST)
X-uc3m-safe: yes
Received: from [192.168.1.3] (82.158.121.177.dyn.user.ono.com [82.158.121.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 124F175ACDE; Thu,  8 Dec 2011 12:32:28 +0100 (CET)
Message-ID: <1323343947.4541.22.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: Jong-Hyouk Lee 
Date: Thu, 08 Dec 2011 12:32:27 +0100
In-Reply-To: <4EDEA32D.20705@inria.fr>
References: <4EDEA32D.20705@inria.fr>
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";  boundary="=-0a5gI1DoSL0+Y+fmBoBX"
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18568.003
Cc: mext 
Subject: Re: [MEXT] Comments on "draft-bernardos-mext-dmm-pmip-01"
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Dec 2011 11:32:34 -0000

--=-0a5gI1DoSL0+Y+fmBoBX
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

Hi Jong-Hyouk,

Thanks a lot for your comments. Please see some comments inline below.

On Wed, 2011-12-07 at 00:20 +0100, Jong-Hyouk Lee wrote:
> Hi Carlos,
>=20
> I read the draft "draft-bernardos-mext-dmm-pmip-01" and have=20
> comments/questions:
>=20
> 1. I'd like to avoid non-technical comments, but I should mention it. In=
=20
> Section 3, the following sentence "The purpose of Distributed Mobility=
=20
> Management approaches is to overcome the limitations of the traditional=
=20
> centralized mobility management by bringing the mobility anchor closer=
=20
> to the MN." should be revised. Brining the mobility anchor closer to MNs=
=20
> is to form a flattened architecture, not for DMM. ;)

Well, please allow me to disagree here :D. I think that "bringing
mobility anchors closer to the MN", so the MN can change anchor
dynamically and traffic is not always managed by the same centralized
entity is exactly one way of DMM. Maybe the writing was not the best
one, and we will revise it.

>=20
> 2. In Section 3.2, even if you didn't explicitly describe, the proposed=
=20
> one could avoid a conflict over ingress filtering at MAARs. For=20
> instance, in Figure 2, MAAR2 updates its routing information after it=20
> receives the PBA message containing prefixes associated with the mobile=
=20
> node. Then, for addressing ingress filtering issues with the prefixes,=
=20
> MAAR2 is required to update its ingress filtering list (e.g., of a=20
> firewall) with the prefixes. With this way (as an example), the conflict=
=20
> over ingress filtering is solved.

Well, sure MAARs have to update their ingress filtering rules, but it
exactly the same case of PMIPv6: MAAR2 plays the role of MAG, and
therefore has to allow and forward traffic with source addresses
belonging to a prefix assigned by the LMA (MAAR1).

>=20
> 3. In Section 3.2, you gave the following sentence "The drawback can be=
=20
> mitigated introducing a timeout at the CMD, by which, after its=20
> expiration, all the PBAs so far collected are transmitted, and the=20
> remaining are sent later upon their arrival." Hummm...actually, it does=
=20
> not help to mitigate the problem; it makes a bigger problem. Suppose=20
> that a mobile node has five prefixes, i.e., P1 (the prefix obtained from=
=20
> the first MAAR), P2, P3, P4, and P5 (the prefix obtained from the=20
> serving MAAR). Let t denotes the timer value at the CMD. Now...suppose=
=20
> that the transmission times of PBAs containing P1 and P2 are bigger than=
=20
> t. The CMD thus closes its waiting and sends out the PBA message=20
> containing only P3 and P4. Then, what are you expecting at the serving=
=20
> MAAR (MAAR5)? Since this guy now updates its routing table for the=20
> mobile node with only P3, P4, and P5, incoming packets associated with=
=20
> P1 and P2 to the mobile node are lost and outgoing packets with P1 and=
=20
> P2 are also definitely filtered (due to no ingress filtering list=20
> update). Those are happened during the time gap between the arrival of=
=20
> PBA (P3 and P4) and the arrival of PBA (P1 and P2) sent from the CMD to=
=20
> the serving MAAR. In addition, you didn't give a detail of handling of=
=20
> the late arrivals; shall the CMD wait another t for collecting and wait=
=20
> again for collecting rest all? Moreover, why does the CMD wait to=20
> collect all PBAs from other MAARs?

Details are definitely missing and we will provide more in a subsequent
revision. Regarding your comments, short answer is: you always lose
packets while the signaling is taking place (either that or you buffer
them and then once is completed deliver the packets). Therefore,
anything that avoids to wait to collect all PBAs is actually reducing
the time packets are lost for those prefixes that you could process
before all the PBAs are received.

>=20
> 4. In addition, the approach of "CMD as PBU/PBA relay" described in=20
> Section 3.2 must cause long registration latency as the mobile node=20
> continuously moves around the domain consisted of MAARs. Moreover, I'm=
=20
> also concern about the routing loop as the mobile node moves around the=
=20
> domain and visits its previous locations again; special treatments for=
=20
> eliminating the routing loop are required at the CMD.

I think the speed of movement to require that loops to appear is faster
than the usual one for a mobile node. Sure there might be temporal and
short periods of time with loops, but this is not exclusive of this kind
of solution (ping-pong effects are well known).

>=20
> 5. In Section 3.3, you introduce the approach of "CMD as MAAR locator"=
=20
> that seems for reducing latency compared to the approach of "CMD as=20
> PBU/PBA relay". However, I have doubt about the approach of "CMD as MAAR=
=20
> locator". Look at Figure 3. As shown, MAAR2 will allow any data=20
> transmission associated with P1 (i.e., mobile node's prefix assigned in=
=20
> MAAR1) at his access network without any confirmation from the CMD.=20
> Hummm...don't we need to check P1's validation? Without involvement of=
=20
> the CMD, it's hard to check prefix (or previous binding information)'s=
=20
> validation; revoked? expired? Hummm...at Figure 3, MAAR2 does not know=
=20
> such things, but he will allow the data transmission continuously.

The confirmation comes from MAAR1 (PBA), instead from CMD as in the
previous case.

>=20
> 6. The approach "CMD as PBU/PBA proxy" introduced in Section 3.4 also=20
> brings an issue. In short, look at Figure 4, without any confirmation=20
> from MAAR1, MAAR2 updates its routing information for P1. How about if=
=20
> MAAR1 does not properly work at the moment? Even MAAR1 sends its message=
=20
> to the CMD, but there is no way to provide it to MAAR2.

If MAAR1 does not work properly, there is nothing you can do to ensure
traffic anchored at MAAR1 is forwarded to the MN, no matter what you
do :D. Since CMD knows the prefixes MAAR1 anchors, this approach allows
to speed the process by doing things in parallel.

>=20
> I hope...my comments help you to figure out ways to overtime these=20
> problems/issues for your next draft.

Sure they help. We'll try to explain things better in the next version.
Thanks!

Carlos

>=20
> Cheers.
>=20

--=20
Carlos Jes=FAs Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

--=-0a5gI1DoSL0+Y+fmBoBX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7goEsACgkQNdy6TdFwT2eNBQCeJYO+7CHKQncbq77UBvSQydtX
QsEAoODTzerTcfIxHF+xgRJZDskgPWAT
=E1jC
-----END PGP SIGNATURE-----

--=-0a5gI1DoSL0+Y+fmBoBX--


From jiin16@gmail.com  Sun Dec 11 19:48:36 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7E21F8483 for ; Sun, 11 Dec 2011 19:48:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKk+qdS5OAbo for ; Sun, 11 Dec 2011 19:48:34 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7776721F847A for ; Sun, 11 Dec 2011 19:48:34 -0800 (PST)
Received: by iaek3 with SMTP id k3so9465782iae.31 for ; Sun, 11 Dec 2011 19:48:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=mHjEVMMY87t0IPu+vFdiPYseD5aFU6ihSqkcREKqLw8=; b=mHIMg4iPxO6Nw0EpthkvfoXCH3cqMMGeQlOXwa8o9gzyVt7dPx/PnrLSHwYLBz7e1K OuyFZB2dWUBXMFCtdL1gtRAQQNe1cVgF/e9PhQ279WgI8dJxa8t77YnGyjmfAMZkvr/h b7kEkeyDe05P6eSinUp//kJIsvx4K0kP+oTA0=
Received: by 10.50.51.234 with SMTP id n10mr13749260igo.10.1323661713928; Sun, 11 Dec 2011 19:48:33 -0800 (PST)
Received: from neobooriPC ([155.230.105.157]) by mx.google.com with ESMTPS id z22sm45827131ibg.5.2011.12.11.19.48.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Dec 2011 19:48:32 -0800 (PST)
From: "Ji-In Kim" 
To: "Jong-Hyouk Lee" 
References:  <50DC4102-EB18-4164-96DC-339344DF6F75@gmail.com>
In-Reply-To: <50DC4102-EB18-4164-96DC-339344DF6F75@gmail.com>
Date: Mon, 12 Dec 2011 12:48:28 +0900
Message-ID: <007b01ccb880$eaad1c80$c0075580$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01CCB8CC.5A97D1C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQCIX79YI69IgzEPAFPT3BlD82hDIQIiJyDhmE8wPsA=
Content-Language: ko
Cc: mext , =?UTF-8?B?6rOg7ISd7KO86rWQ7IiY64uY?= 
Subject: Re: [MEXT] Comments on "draft-sjkoh-mext-pmip-dmc-03"
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Dec 2011 03:48:36 -0000

This is a multipart message in MIME format.

------=_NextPart_000_007C_01CCB8CC.5A97D1C0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

RGVhciBKb25nLUh5b3VrIExlZSwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3Lg0KDQpUaGVy
ZSBpcyBhbiBpc3N1ZSBvbiBob3cgdG8gYXNzaWduIHRoZSBITlAgaW4gRE1NIHNvbHV0aW9uLiBJ
dCBuZWVkcyBtb3JlIGRpc2N1c3Npb24uDQpIb3dldmVyLCBpZiB0aGUgSE5QIGlzIG5vdCBhc3Np
Z25lZCB0byB0aGUgUE1JUCBkb21haW4gdGhhdCBjb25zaXN0IG9mIHNldmVyYWwgTUFHcywgYWxs
IG9mIE1BR3MgaW4gdGhlIEludGVybmV0IHNoYWxsIGpvaW4gdGhlIG11bHRpY2FzdCBncm91cCBm
b3IgY29udHJvbCBvcGVyYXRpb25zLg0KSW4gdGhpcyBjYXNlLCB0aGVyZSBtYXkgYmUgc2VyaW91
cyBtdWx0aWNhc3Qgb3ZlcmhlYWQuDQooSW4gU0QtUE1JUCwgdGhlIG11bHRpY2FzdCBxdWVyeSBv
cGVyYXRpb25zIHdpbGwgYmUgcGVyZm9ybWVkIHRvIGFsbCBvZiBNQUdzLikNCg0KDQoNCiANCg0K
QmVzdCBSZWdhcmRzLCBKaS1JbiBLaW0NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpQaC5EIHN0dWRlbnQs
IENvbW11bmljYXRpb25zIFByb3RvY29scyBMYWIsIEt5dW5ncG9vayBOYXRpb25hbCBVbml2ZXJz
aXR5Lg0KDQoxMzcwIFNhbmt5dWstZG9uZywgQnVrLWd1LCBEYWVndSwgS29yZWEuDQoNCkUtbWFp
bDogamlpbjE2QGdtYWlsLmNvbSANClRlbDogODItNTMtOTQwLTg2MDggQy5QOiA4Mi0xMC05Mzcx
LTEzMjQNCg0KIA0KDQpGcm9tOiBTZW9rLUpvbyBLb2ggW21haWx0bzpzamtvaDEyQGdtYWlsLmNv
bV0gDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDA5LCAyMDExIDc6NDcgUE0NClRvOiBqaWluMTZA
Z21haWwuY29tDQpTdWJqZWN0OiBGd2Q6IFtNRVhUXSBDb21tZW50cyBvbiAiZHJhZnQtc2prb2gt
bWV4dC1wbWlwLWRtYy0wMyINCg0KIA0KDQogDQoNCiANCg0KKioqKioqKioqKioqKioqKioqKioq
KioqKioNCg0KU2Vvay1Kb28gS29oDQoNCnNqa29oQGtudS5hYy5rcg0KDQoqKioqKioqKioqKioq
KioqKioqKioqKioqKg0KDQoNCuyghOuLrOuQnCDrqZTsi5zsp4Ag7Iuc7J6ROg0KDQrrs7Trgrgg
7IKs656MOiBTZW9rLUpvbyBLb2ggPHNqa29oMTJAZ21haWwuY29tPg0K64Kg7KecOiAyMDEx64WE
IDEy7JuUIDnsnbwg7Jik7ZuEIDfsi5wgNeu2hCA1OOy0iCBLU1QNCuuwm+uKlCDsgqzrnow6IEpp
LUluIEtpbSA8amlpbjE2QGdtYWlsLmNvbT4NCuywuOyhsDogc2prb2gxMkBnbWFpbC5jb20NCuyg
nOuqqTogUmU6IFtNRVhUXSBDb21tZW50cyBvbiAiZHJhZnQtc2prb2gtbWV4dC1wbWlwLWRtYy0w
MyINCuuLteyepeuwm+uKlCDsgqzrnow6IHNqa29oQGtudS5hYy5rcg0KDQrsiJjsoJXsgqztla0u
Lg0KDQogDQoNCjEuIFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUu
DQoNCi0tPiBTZWUgaW5saW5lIOyDneuetSAo7J206rG0LCDrrLjsnqUg7KSR6rCE7JeQIOuLteuz
gOydhCDri6zrlYwg7IKs7Jqp7ZWY64qUIOunkOyehCkNCg0KIA0KDQoyLiBUaGVyZSBpcyBhbiBp
c3N1ZSBob3cgdG8gYXNzaWduIHRoZSBITlAgaW4gRE1NLg0KDQotLT4gVGhlcmUgaXMgYW4gaXNz
dWUgb24gaG93IH4NCg0KIA0KDQozLiBJdCBuZWVkcyB0byBkaXNjdXNzLg0KDQotLT4gSXQgbmVl
ZHMgbW9yZSBkaXNjdXNzaW9uDQoNCg0KNC4gSG93ZXZlciwgaWYgdGhlIEhOUCBpcyBub3QgYXNz
aWduZWQgdG8gdGhlIFBNSVAgZG9tYWluIHRvIGNvbnNpc3Qgb2Ygc2V2ZXJhbCBNQUdzLCBhbGwg
b2YgTUFHcyBpbiB0aGUgSW50ZXJuZXQgam9pbiB0aGUgbXVsdGljYXN0IGdyb3VwIGZvciBjb250
cm9sIHNpZ25hbHMuDQoNCi0tPiBIb3dldmVyLCBpZiB0aGUgSE5QIGlzIG5vdCBhc3NpZ25lZCB0
byB0aGUgUE1JUCBkb21haW4gdGhhdCBjb25zaXN0cyBvZiBzZXZlcmFsIE1BR3MsIGFsbCBvZiBN
QUdzIGluIHRoZSBJbnRlcm5ldCBzaGFsbCBqb2luIHRoZSBtdWx0aWNhc3QgZ3JvdXAgZm9yIGNv
bnRyb2wgb3BlcmF0aW9ucy4NCg0KIA0KDQo1LiBJbiB0aGlzIGNhc2UsIHRoZXJlIGlzIHNlcmlv
dXMgbXVsdGljYXN0IG92ZXJoZWFkLg0KDQotLT4gSW4gdGhpcyBjYXNlLCB0aGVyZSBtYXkgYmUg
c2VyaW91cyBtdWx0aWNhc3Qgb3ZlcmhlYWQuDQoNCiANCg0KNi4gKEFzIGNvbm5lY3Rpb24gaXMg
ZXN0YWJsaXNoZWQsIG11bHRpY2FzdCBxdWVyeSBvcGVyYXRpb25zIHBlcmZvcm0gdG8gYWxsIG9m
IE1BR3MuKQ0KDQotLT4gKEluIFNELVBNSVAsIHRoZSBtdWx0aWNhc3QgcXVlcnkgb3BlcmF0aW9u
cyB3aWxsIGJlIHBlcmZvcm1lZCB0byBhbGwgb2YgTUFHcy4pDQoNCiANCg0KIA0KDQoyMDEx64WE
IDEy7JuUIDjsnbwg7Jik7ZuEIDg6NTksIEppLUluIEtpbSA8amlpbjE2QGdtYWlsLmNvbT7ri5js
nZgg66eQOg0KDQrslYjrhZXtlZjshLjsmpQuIOq1kOyImOuLmCDsp4DsnbjsnoXri4jri6QuDQoN
CuyVhOuemOyZgCDqsJnsnbQg64u167OA7J2EIO2VoCDsg53qsIHsnoXri4jri6QuDQoNCkRlYXIg
Sm9uZy1IeW91ayBMZWUsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBp
bmxpbmUuDQoNClRoZXJlIGlzIGFuIGlzc3VlIGhvdyB0byBhc3NpZ24gdGhlIEhOUCBpbiBETU0g
c29sdXRpb24uIEl0IG5lZWRzIHRvIGRpc2N1c3MuDQpIb3dldmVyLCBpZiB0aGUgSE5QIGlzIG5v
dCBhc3NpZ25lZCB0byB0aGUgUE1JUCBkb21haW4gdG8gY29uc2lzdCBvZiBzZXZlcmFsIE1BR3Ms
IGFsbCBvZiBNQUdzIGluIHRoZSBJbnRlcm5ldCBqb2luIHRoZSBtdWx0aWNhc3QgZ3JvdXAgZm9y
IGNvbnRyb2wgc2lnbmFscy4NCkluIHRoaXMgY2FzZSwgdGhlcmUgaXMgc2VyaW91cyBtdWx0aWNh
c3Qgb3ZlcmhlYWQuDQooQXMgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCwgbXVsdGljYXN0IHF1
ZXJ5IG9wZXJhdGlvbnMgcGVyZm9ybSB0byBhbGwgb2YgTUFHcy4pDQoNCk11bHRpY2FzdOyXkCDr
jIDtlZwgb3ZlcmhlYWTqsIAgSE5QIO2VoOuLueycvOuhnCDsnbjtlbQg7KSE7Ja065OkIOqyveya
sCBNdWx0aWNhc3Qg67Cp7Iud7J20IOyigCDrjZQgRE1N6rCAIOqwgOq5jOyatCDslrTtlITroZzs
uZjqsIAg65CgIOqygyDqsJnslYQg7KCc7Jm47ZWgIOqzhO2ajeydtOudvOuKlCDrp5DsnYAg7J28
64uoIOygnOyZuO2VmOyYgOyKteuLiOuLpC4NCuusuOyEnCDsl4XrjbDsnbTtirgg7IucIFNELVBN
SVDsl5Ag64yA7ZWcIO2VuOuTnOyYpOuyhCDsi5zrgpjrpqzsmKTrj4Qg6rOg66Ck66W8IO2VtOyE
nCDtj6ztlajtlbTslbwg7ZWgIOqygyDqsJnsirXri4jri6QuDQoNCg0K6rmA7KeA7J24IOuTnOum
vA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0K6rK967aB64yA7ZWZ6rWQIElU64yA7ZWZIOy7tO2TqO2EsO2Vmeu2
gCDthrXsi6DtlITroZzthqDsvZwg7Jew6rWs7IukIOuwleyCrOqzvOyglQ0K6rK967aB64yA7ZWZ
6rWQIElU64yA7ZWZIDPtmLjqtIAgMzA5Qe2YuA0KRS1tYWlsOiBqaWluMTZAZ21haWwuY29tDQpU
ZWw6IDA1My05NDAtODYwOCBDLlA6IDAxMC05MzcxLTEzMjQNCg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogU2Vvay1Kb28gS29oIFttYWlsdG86c2prb2gxMkBnbWFpbC5jb21d
DQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDA3LCAyMDExIDk6MjEgUE0NClRvOiBKaS1JbiBL
aW0NClN1YmplY3Q6IFJlOiBbTUVYVF0gQ29tbWVudHMgb24gImRyYWZ0LXNqa29oLW1leHQtcG1p
cC1kbWMtMDMiDQoNCuyYpOy8gOydtCwNCu2FjeyKpO2KuCDspIDruYTtlbTshJwg67O064K07KO8
7IK8Li4NCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKg0KU2Vvay1Kb28gS29oDQpzamtv
aEBrbnUuYWMua3INCioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCjIwMTEuIDEyLiA3LiDs
mKTtm4QgODowNSAiSmktSW4gS2ltIiA8amlpbjE2QGdtYWlsLmNvbT4g7J6R7ISxOg0KDQo+IOyV
iOuFle2VmOyEuOyalC4g6rWQ7IiY64uYIOyngOyduOyeheuLiOuLpC4NCj4NCj4g7Jes65+s66qo
66GcIOyDneqwgeydhCDtlbQg67O4IOqysOqzvCDtlbTri7kg7KeI66y47JeQIOuMgO2VnCDrjIDr
i7XsnYQg7JWE656Y7JmAIOqwmeydgCDrsKntlqXsnLzroZwg7J6R7ISx7ZW07JW8IO2VoCDqsoMg
6rCZ7Iq164uI64ukLg0KPg0KPiBITlDrpbwg7Ja065a76rKMIO2VoOuLue2VoOyngOyXkCDrjIDt
lbTshJzripQg7ZiE7J6sIERNTeyXkOyEnCDstqnrtoTtnogg7J207IqI6rCAIOuQmOqzoCDsnojs
nLzrqbAsIOyVhOyngeq5jOyngCDrhbzsnZjrpbwg7ZW07JW8IO2VoCDrtoDrtoTsnbQg66eO64uk
Lg0KPiDtlZjsp4Drp4wgUE1JUCDrj4TrqZTsnbgg67OE66GcIEhOUOuhnCDrrLbslrTshJwg7Ya1
7Iug7J2EIO2VmOyngCDslYrsnYQg6rK97JqwLCBJbnRlcm5ldCDsg4Hsl5Ag7J6I64qUIOuqqOuT
oCBNQUfrk6TsnbQg66mA7Yuw7LqQ7Iqk7Yq4IOq3uOujueyXkCDssLjsl6zrpbwg7ZW07JW8IO2V
mOqzoCwg7J2066GcIOyduO2VnCBNdWx0aWNhc3Qgb3ZlcmhlYWTqsIAg64SI66y064KYIOyLrOqw
ge2VmOuLpC4NCj4gKOyEuOyFmOydtCDtlZjrgpgg7Je066a0IOuVjCDrp4jri6Qg66qo65OgIE1B
R+yXkCBNdWx0aWNhc3QgUXVlcnnrpbwg7IiY7ZaJ7ZW07JW8IO2VnOuLpC4pIO2VmOyngOunjCDs
nbQg6rK97JqwIOuzuCDrrLjshJzsl5Ag7J6I64qUDQo+IFMtUE1JUOqzvOydmCDssKjsnbTsoJDs
nbQg66qo7Zi47ZW07KeA64qUIOusuOygnOqwgCDsobTsnqzrpbwg7ZWc64ukLg0KPiDqt7jrnpjs
hJwg7ZiE7J6sIFNELVBNSVAg6riw67KV7JeQIOuMgO2VtCDsoJzslYgg7Jes67aA66W8IOqzoOuv
vO2VmOqzoCDsnojri6QuDQo+DQo+IOydtOugh+qyjCDri7Xrs4DsnYQg7ZWc64uk66m0IOuLpOyd
jCDrrLjshJzsl5DshJwgU0QtUE1JUOydhCDsoJzsmbjtlZjripQg6rKD7JeQIOuMgO2VnCDsoJDr
j4Qg7Ja064qQIOygleuPhCBNRVhUIFdH7JeQIOyWtO2VhO2VoCDsiJgg7J6I6rOgIOuLteuzgOuP
hCDrkKAg6rKDIOqwmeyKteuLiOuLpC4NCj4NCj4g6rWQ7IiY64uYIOyDneqwgeydgCDslrTrlqDs
i6Dsp4DsmpQ/DQo+DQo+DQo+IOq5gOyngOyduCDrk5zrprwNCj4gLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiDq
sr3rtoHrjIDtlZnqtZAgSVTrjIDtlZkg7Lu07ZOo7YSw7ZWZ67aAIO2GteyLoO2UhOuhnO2GoOy9
nCDsl7Dqtazsi6Qg67CV7IKs6rO87KCVDQo+IOqyveu2geuMgO2Vmeq1kCBJVOuMgO2VmSAz7Zi4
6rSAIDMwOUHtmLgNCj4gRS1tYWlsOiBqaWluMTZAZ21haWwuY29tDQo+IFRlbDogMDUzLTk0MC04
NjA4IEMuUDogMDEwLTkzNzEtMTMyNA0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBTZW9rLUpvbyBLb2ggW21haWx0bzpzamtvaEBrbnUuYWMua3JdDQo+IFNlbnQ6
IFdlZG5lc2RheSwgRGVjZW1iZXIgMDcsIDIwMTEgODozOSBBTQ0KPiBUbzog6rmA7KeA7J24DQo+
IFN1YmplY3Q6IEZ3OiBbTUVYVF0gQ29tbWVudHMgb24gImRyYWZ0LXNqa29oLW1leHQtcG1pcC1k
bWMtMDMiDQo+DQo+IFBNSVDsnZggSG9BICjri6jrp5Ap7JmAIFBDb0EoTUFHKeulvCDtmLzrj5nt
lZjqs6Ag7J6I64qU65OvIO2VnOuNsC4uDQo+DQo+IOyWtOuWpCDso7zshozsl5Ag64yA7ZWcIHBy
ZWZpeCA/Pw0KPg0KPiDsnZHri7Xsi5zsl5Ag6rSA66CoIOyaqeyWtOulvCDrtoTrqoXtnogg7ZWY
64qU6rKMIOyii+ydhOuTry4uDQo+DQo+DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioNCj4g
U2Vvay1Kb28gS29oDQo+IHNqa29oQGtudS5hYy5rcg0KPiAqKioqKioqKioqKioqKioqKioqKioq
KioqDQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIkpvbmctSHlv
dWsgTGVlIiA8am9uZy1oeW91ay5sZWVAaW5yaWEuZnI+DQo+IFRvOiAiSmktSW4gS2ltIiA8amlp
bjE2QGdtYWlsLmNvbT4NCj4gQ2M6ICLqs6DshJ3so7zqtZDsiJjri5giIDxzamtvaEBrbnUuYWMu
a3I+OyAiJ21leHQnIiA8bWV4dEBpZXRmLm9yZz4NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJl
ciAwNywgMjAxMSA1OjA4IEFNDQo+IFN1YmplY3Q6IFJlOiBbTUVYVF0gQ29tbWVudHMgb24gImRy
YWZ0LXNqa29oLW1leHQtcG1pcC1kbWMtMDMiDQo+DQo+DQo+PiBEZWFyIEppLUluIEtpbSwNCj4+
DQo+PiBJIGRvIG5vdCB0aGluayB0aGF0IGFsbCBtb2JpbGUgbm9kZXMgaGF2ZSB0aGUgc2FtZSBw
cmVmaXggaW4gYSBTRC1QTUlQIGRvbWFpbiBjb25zaXN0aW5nIG9mIE1BR3MuDQo+PiBJIHRob3Vn
aHQgdGhhdCBhIG5ldHdvcmsgcHJlZml4IGFzc2lnbmVkIHRvIGEgbW9iaWxlIG5vZGUgaXMgbWFu
YWdlZA0KPj4gYnkgYSBzZXJ2aW5nIE1BRy4gQXJlIHlvdSByZWFsbHkgY29uc2lkZXJpbmcgdGhh
dCBhbGwgb2YgdGhlIG5vZGVzIGluIHRoZSBTRC1QTUlQIGRvbWFpbiBoYXZlIHRoZSBzYW1lIHBy
ZWZpeD8NCj4+DQo+PiBDaGVlcnMuDQo+Pg0KPj4gT24gVHVlIDA2IERlYyAyMDExIDA0OjAxOjMz
IEFNIENFVCwgSmktSW4gS2ltIHdyb3RlOg0KPj4+DQo+Pj4gRGVhciBKb25nLUh5dW9rIExlZSwN
Cj4+Pg0KPj4+IFRoYW5rIHlvdSBmb3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRzLiBQbGVhc2Ugc2Vl
IG15IGlubGluZSByZXNwb25zZXMuDQo+Pj4NCj4+PiAxKSBXZSBzdXBwb3NlIHRoYXQgYm90aCBN
TiBhbmQgQ04gYXJlIGluIHRoZSBzYW1lIGRvbWFpbiBpbiB0aGUNCj4+PiBTLVBNSVAgYW5kIFNE
LVBNSVAuIFNvLCBhbGwgb2YgdGhlIG5vZGVzIGluIFNELVBNSVAgaGF2ZSB0aGUgc2FtZSBwcmVm
aXguDQo+Pj4gMikgSW4gdGhlIGRyYWZ0LCB3ZSBkaWRuJ3QgY29uc2lkZXIgdGhlIGhhbmRvdmVy
IHNjZW5hcmlvIHlldC4NCj4+PiBIb3dldmVyLCB3ZSB3aWxsIHJldmlzZSB0aGUgZHJhZnQgdG8g
aW5jbHVkZSB0aGUgaGFuZG92ZXIgc2NlbmFyaW9zIHdpdGhpbiB0aGlzIG1vbnRoLg0KPj4+DQo+
Pj4NCj4+PiBCZXN0IFJlZ2FyZHMsIEppLUluIEtpbQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gLS0g
UGguRCBzdHVkZW50LCBDb21tdW5pY2F0aW9ucyBQcm90b2NvbHMgTGFiLCBLeXVuZ3Bvb2sgTmF0
aW9uYWwNCj4+PiBVbml2ZXJzaXR5Lg0KPj4+IDEzNzAgU2Fua3l1ay1kb25nLCBCdWstZ3UsIERh
ZWd1LCBLb3JlYS4NCj4+PiBFLW1haWw6IGppaW4xNkBnbWFpbC5jb20NCj4+PiBUZWw6IDgyLTUz
LTk0MC04NjA4IEMuUDogODItMTAtOTM3MS0xMzI0DQo+Pj4NCj4+Pj4NCj4+Pj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogbWV4dC1ib3VuY2VzQGlldGYub3JnIFttYWls
dG86bWV4dC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+PiBCZWhhbGYgT2YNCj4+Pg0KPj4+IEpv
bmctSHlvdWsgTGVlDQo+Pj4+DQo+Pj4+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDUsIDIwMTEg
MTozNiBBTQ0KPj4+PiBUbzogc2prb2hAa251LmFjLmtyOyBtZXh0DQo+Pj4+IFN1YmplY3Q6IFtN
RVhUXSBDb21tZW50cyBvbiAiZHJhZnQtc2prb2gtbWV4dC1wbWlwLWRtYy0wMyINCj4+Pj4NCj4+
Pj4gRGVhciBhdXRob3JzLA0KPj4+Pg0KPj4+PiBJIHJlYWQgdGhlIGRyYWZ0ICJkcmFmdC1zamtv
aC1tZXh0LXBtaXAtZG1jLTAzIiBhbmQgaGF2ZQ0KPj4+DQo+Pj4gY29tbWVudHMvcXVlc3Rpb25z
Og0KPj4+Pg0KPj4+Pg0KPj4+PiBIb3cgaXMgYW4gTU4ncyBoYW5kb3ZlciBoYW5kbGVkIGluIFNE
LVBNSVA/IEZvciBpbnN0YW5jZTogMSkgSXQncw0KPj4+PiBub3QNCj4+Pg0KPj4+IGNsZWFyIGhv
dyBhIHByZWZpeCBvZiB0aGUgTU4gaXMgcHJvdmlkZWQ7IGFuZCAyKSBpdCBpcyBhbHNvIG5vdA0K
Pj4+IGNsZWFyIGZyb20gdGhlIGRyYWZ0IGhvdyBvbmdvaW5nIHBhY2tldHMgKGRlc3RpbmVkIHRv
IHRoZSBNTiBvciBzZW50DQo+Pj4gZnJvbSB0aGUNCj4+Pj4NCj4+Pj4gTU4pIGFyZSBoYW5kbGVk
IGR1cmluZyBoYW5kb3ZlcnMuDQo+Pj4+DQo+Pj4+IFRoYW5rcy4NCj4+Pj4NCj4+Pj4gLS0NCj4+
Pj4gSU1BUkEgVGVhbSwgSU5SSUEsIEZyYW5jZQ0KPj4+PiBKb25nLUh5b3VrIExlZSwgbGl2aW5n
IHNvbWV3aGVyZSBiZXR3ZWVuIC9kZXYvbnVsbCBhbmQgL2Rldi9yYW5kb20NCj4+Pj4NCj4+Pj4g
I2VtYWlsOiBqb25nLWh5b3VrLmxlZSAoYXQpIGlucmlhLmZyIHx8IGh1cnJ5b24gKGF0KSBnbWFp
bC5jb20NCj4+Pj4gI3dlYnBhZ2U6IGh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaHVycnlv
bi8NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4+Pj4gTUVYVCBtYWlsaW5nIGxpc3QNCj4+Pj4gTUVYVEBpZXRmLm9yZw0KPj4+PiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQNCj4+Pg0KPj4+DQo+Pj4g
LS0NCj4+PiBJTUFSQSBUZWFtLCBJTlJJQSwgRnJhbmNlDQo+Pj4gSm9uZy1IeW91ayBMZWUsIGxp
dmluZyBzb21ld2hlcmUgYmV0d2VlbiAvZGV2L251bGwgYW5kIC9kZXYvcmFuZG9tDQo+Pj4NCj4+
PiAjZW1haWw6IGh1cnJ5b24gKGF0KSBnbWFpbC5jb20gfHwgam9uZy1oeW91ay5sZWUgKGF0KSBp
bnJpYS5mcg0KPj4+ICN3ZWJwYWdlOiBodHRwOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2h1cnJ5
b24vDQo+DQoNCg0KDQoNCg0KIA0KDQotLSANCiANCioqKioqKioqKioqKioqKioqKioqKioqDQpT
ZW9rLUpvbyBLb2gNCnNqa29oQGtudS5hYy5rcg0KKioqKioqKioqKioqKioqKioqKioqKioNCg0K
DQoNCg==

------=_NextPart_000_007C_01CCB8CC.5A97D1C0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear Jong-Hyouk Lee,

Thank =
you for the review.

There is an issue on how to assign the HNP in =
DMM solution. It needs more discussion.
However, if the HNP is not =
assigned to the PMIP domain that consist of several MAGs, all of MAGs in =
the Internet shall join the multicast group for control =
operations.
In this case, there may be serious multicast =
overhead.
(In SD-PMIP, the multicast query operations will be =
performed to all of MAGs.)

 
Best Regards, Ji-In =
Kim
--------------------------------------=
--------------------------------
Ph.D student, Communications =
Protocols Lab, Kyungpook National University.
1370 Sankyuk-dong, Buk-gu, Daegu, =
Korea.
E-mail: jiin16@gmail.com 
Tel: =
82-53-940-8608 C.P: 82-10-9371-1324
 
From:=
 Seok-Joo =
Koh [mailto:sjkoh12@gmail.com] 
Sent: Friday, December 09, =
2011 7:47 PM
To: jiin16@gmail.com
Subject: Fwd: =
[MEXT] Comments on =
"draft-sjkoh-mext-pmip-dmc-03"
 
 
 
**************************
Seok-Joo =
Koh
**************************
=


=EC=A0=84=EB=8B=AC=EB=90=9C =
=EB=A9=94=EC=8B=9C=EC=A7=80 =EC=8B=9C=EC=9E=91:
=EB=B3=B4=EB=82=B8 =
=EC=82=AC=EB=9E=8C: =
Seok-Joo Koh <sjkoh12@gmail.com>
=
=EB=82=A0=EC=A7=9C: =
2011=EB=85=84 12=EC=9B=94 9=EC=9D=BC =EC=98=A4=ED=9B=84 =
7=EC=8B=9C 5=EB=B6=84 58=EC=B4=88 =
KST
=EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C: Ji-In Kim <jiin16@gmail.com>
=EC=
=B0=B8=EC=A1=B0: sjkoh12@gmail.com
=EC=A0=
=9C=EB=AA=A9: Re: =
[MEXT] Comments on =
"draft-sjkoh-mext-pmip-dmc-03"
=EB=8B=B5=EC=9E=
=A5=EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C: sjkoh@knu.ac.kr
=

=EC=88=98=EC=A0=95=EC=82=AC=ED=95=AD..
 
1. Thank you for the review. =
Please see inline.
--> See inline =EC=83=9D=EB=9E=B5 (=EC=9D=B4=EA=B1=B4, =
=EB=AC=B8=EC=9E=A5 =EC=A4=91=EA=B0=84=EC=97=90 =
=EB=8B=B5=EB=B3=80=EC=9D=84 =EB=8B=AC=EB=95=8C =
=EC=82=AC=EC=9A=A9=ED=95=98=EB=8A=94 =EB=A7=90=EC=9E=84)
 
2. There is an issue how to assign the HNP in =
DMM.
--> There is an issue on how =
~
 
3. It needs to =
discuss.
--> It needs more =
discussion

4. However, if the HNP is not assigned to the PMIP =
domain to consist of several MAGs, all of MAGs in the Internet join the =
multicast group for control signals.
--> However, if the HNP is =
not assigned to the PMIP domain that consists of several MAGs, all of =
MAGs in the Internet shall join the multicast group for control =
operations.
 
5. In this case, there is serious =
multicast overhead.
--> In this case, there may =
be serious multicast overhead.
 
6. (As connection is established, =
multicast query operations perform to all of =
MAGs.)
--> (In SD-PMIP, the multicast query operations =
will be performed to all of MAGs.)
 
 
2011=EB=85=84 =
12=EC=9B=94 8=EC=9D=BC =
=EC=98=A4=ED=9B=84 8:59, Ji-In Kim <jiin16@gmail.com>=EB=8B=98=
=EC=9D=98 =EB=A7=90:
=EC=95=88=EB=85=95=ED=95=98=EC=84=B8=EC=9A=94. =EA=B5=90=EC=88=98=EB=8B=98 =
=EC=A7=80=EC=9D=B8=EC=9E=85=EB=8B=88=EB=8B=A4.

=EC=95=84=EB=9E=98=EC=99=80 =
=EA=B0=99=EC=9D=B4 =EB=8B=B5=EB=B3=80=EC=9D=84 =ED=95=A0 =
=EC=83=9D=EA=B0=81=EC=9E=85=EB=8B=88=EB=8B=A4.

Dear Jong-Hyouk Lee,

Thank you for the =
review. Please see inline.

There is an issue how to assign the =
HNP in DMM solution. It needs to discuss.
However, if the HNP is not =
assigned to the PMIP domain to consist of several MAGs, all of MAGs in =
the Internet join the multicast group for control signals.
In this =
case, there is serious multicast overhead.
(As connection is =
established, multicast query operations perform to all of =
MAGs.)

Multicast=EC=97=90 =EB=8C=80=ED=95=9C overhead=EA=B0=80 HNP =
=ED=95=A0=EB=8B=B9=EC=9C=BC=EB=A1=9C =EC=9D=B8=ED=95=B4 =
=EC=A4=84=EC=96=B4=EB=93=A4 =EA=B2=BD=EC=9A=B0 =
Multicast =EB=B0=A9=EC=8B=9D=EC=9D=B4 =EC=A2=80 =EB=8D=94 DMM=EA=B0=80 =EA=B0=80=EA=B9=8C=EC=9A=B4 =
=EC=96=B4=ED=94=84=EB=A1=9C=EC=B9=98=EA=B0=80 =EB=90=A0 =EA=B2=83 =
=EA=B0=99=EC=95=84 =EC=A0=9C=EC=99=B8=ED=95=A0 =
=EA=B3=84=ED=9A=8D=EC=9D=B4=EB=9D=BC=EB=8A=94 =EB=A7=90=EC=9D=80 =
=EC=9D=BC=EB=8B=A8 =
=EC=A0=9C=EC=99=B8=ED=95=98=EC=98=80=EC=8A=B5=EB=8B=88=EB=8B=A4.
=EB=AC=B8=EC=84=9C =
=EC=97=85=EB=8D=B0=EC=9D=B4=ED=8A=B8 =EC=8B=9C =
SD-PMIP=EC=97=90 =EB=8C=80=ED=95=9C =
=ED=95=B8=EB=93=9C=EC=98=A4=EB=B2=84 =
=EC=8B=9C=EB=82=98=EB=A6=AC=EC=98=A4=EB=8F=84 =
=EA=B3=A0=EB=A0=A4=EB=A5=BC =ED=95=B4=EC=84=9C =
=ED=8F=AC=ED=95=A8=ED=95=B4=EC=95=BC =ED=95=A0 =EA=B2=83 =
=EA=B0=99=EC=8A=B5=EB=8B=88=EB=8B=A4.


=EA=B9=80=EC=A7=80=EC=9D=B8 =
=EB=93=9C=EB=A6=BC
--------------------------------------------------------=
--------------
=EA=B2=BD=EB=B6=81=EB=8C=80=ED=95=99=EA=B5=90 IT=EB=8C=80=ED=95=99 =
=EC=BB=B4=ED=93=A8=ED=84=B0=ED=95=99=EB=B6=80 =
=ED=86=B5=EC=8B=A0=ED=94=84=EB=A1=9C=ED=86=A0=EC=BD=9C =
=EC=97=B0=EA=B5=AC=EC=8B=A4 =EB=B0=95=EC=82=AC=EA=B3=BC=EC=A0=95
=EA=B2=BD=EB=B6=81=EB=8C=80=ED=95=99=EA=B5=90 IT=EB=8C=80=ED=95=99 =
3=ED=98=B8=EA=B4=80 309A=ED=98=B8
E-mail: jiin16@gmail.com
Tel: =
053-940-8608 C.P: 010-9371-1324


-----Original =
Message-----
From: Seok-Joo Koh [mailto:sjkoh12@gmail.com]
Sent: =
Wednesday, December 07, 2011 9:21 PM
To: Ji-In Kim
Subject: Re: =
[MEXT] Comments on =
"draft-sjkoh-mext-pmip-dmc-03"

=EC=98=A4=EC=BC=80=
=EC=9D=B4,
=ED=85=8D=EC=8A=A4=ED=8A=B8 =
=EC=A4=80=EB=B9=84=ED=95=B4=EC=84=9C =
=EB=B3=B4=EB=82=B4=EC=A3=BC=EC=82=BC..


**************************
Seok-Joo =
Koh
sjkoh@knu.ac.kr
******************=
********

2011. 12. 7. =EC=98=A4=ED=9B=84 8:05 "Ji-In Kim" <jiin16@gmail.com> =
=EC=9E=91=EC=84=B1:

> =
=EC=95=88=EB=85=95=ED=95=98=EC=84=B8=EC=9A=94. =
=EA=B5=90=EC=88=98=EB=8B=98 =
=EC=A7=80=EC=9D=B8=EC=9E=85=EB=8B=88=EB=8B=A4.
>
> =
=EC=97=AC=EB=9F=AC=EB=AA=A8=EB=A1=9C =EC=83=9D=EA=B0=81=EC=9D=84 =
=ED=95=B4 =EB=B3=B8 =EA=B2=B0=EA=B3=BC =ED=95=B4=EB=8B=B9 =
=EC=A7=88=EB=AC=B8=EC=97=90 =EB=8C=80=ED=95=9C =
=EB=8C=80=EB=8B=B5=EC=9D=84 =EC=95=84=EB=9E=98=EC=99=80 =
=EA=B0=99=EC=9D=80 =EB=B0=A9=ED=96=A5=EC=9C=BC=EB=A1=9C =
=EC=9E=91=EC=84=B1=ED=95=B4=EC=95=BC =ED=95=A0 =EA=B2=83 =
=EA=B0=99=EC=8A=B5=EB=8B=88=EB=8B=A4.
>
> =
HNP=EB=A5=BC =EC=96=B4=EB=96=BB=EA=B2=8C =
=ED=95=A0=EB=8B=B9=ED=95=A0=EC=A7=80=EC=97=90 =
=EB=8C=80=ED=95=B4=EC=84=9C=EB=8A=94 =ED=98=84=EC=9E=AC DMM=EC=97=90=EC=84=9C =EC=B6=A9=EB=B6=84=ED=9E=88 =
=EC=9D=B4=EC=8A=88=EA=B0=80 =EB=90=98=EA=B3=A0 =
=EC=9E=88=EC=9C=BC=EB=A9=B0, =
=EC=95=84=EC=A7=81=EA=B9=8C=EC=A7=80 =EB=85=BC=EC=9D=98=EB=A5=BC =
=ED=95=B4=EC=95=BC =ED=95=A0 =EB=B6=80=EB=B6=84=EC=9D=B4 =
=EB=A7=8E=EB=8B=A4.
> =
=ED=95=98=EC=A7=80=EB=A7=8C PMIP =
=EB=8F=84=EB=A9=94=EC=9D=B8 =EB=B3=84=EB=A1=9C =
HNP=EB=A1=9C =EB=AC=B6=EC=96=B4=EC=84=9C =
=ED=86=B5=EC=8B=A0=EC=9D=84 =ED=95=98=EC=A7=80 =EC=95=8A=EC=9D=84 =
=EA=B2=BD=EC=9A=B0, Internet =
=EC=83=81=EC=97=90 =EC=9E=88=EB=8A=94 =EB=AA=A8=EB=93=A0 MAG=EB=93=A4=EC=9D=B4 =
=EB=A9=80=ED=8B=B0=EC=BA=90=EC=8A=A4=ED=8A=B8 =
=EA=B7=B8=EB=A3=B9=EC=97=90 =EC=B0=B8=EC=97=AC=EB=A5=BC =
=ED=95=B4=EC=95=BC =ED=95=98=EA=B3=A0, =
=EC=9D=B4=EB=A1=9C =EC=9D=B8=ED=95=9C =
Multicast overhead=EA=B0=80 =EB=84=88=EB=AC=B4=EB=82=98 =
=EC=8B=AC=EA=B0=81=ED=95=98=EB=8B=A4.
> =
(=EC=84=B8=EC=85=98=EC=9D=B4 =ED=95=98=EB=82=98 =
=EC=97=B4=EB=A6=B4 =EB=95=8C =EB=A7=88=EB=8B=A4 =EB=AA=A8=EB=93=A0 MAG=EC=97=90 Multicast =
Query=EB=A5=BC =EC=88=98=ED=96=89=ED=95=B4=EC=95=BC =
=ED=95=9C=EB=8B=A4.) =
=ED=95=98=EC=A7=80=EB=A7=8C =EC=9D=B4 =EA=B2=BD=EC=9A=B0 =
=EB=B3=B8 =EB=AC=B8=EC=84=9C=EC=97=90 =EC=9E=88=EB=8A=94
> S-PMIP=EA=B3=BC=EC=9D=98 =
=EC=B0=A8=EC=9D=B4=EC=A0=90=EC=9D=B4 =
=EB=AA=A8=ED=98=B8=ED=95=B4=EC=A7=80=EB=8A=94 =
=EB=AC=B8=EC=A0=9C=EA=B0=80 =EC=A1=B4=EC=9E=AC=EB=A5=BC =
=ED=95=9C=EB=8B=A4.
> =
=EA=B7=B8=EB=9E=98=EC=84=9C =ED=98=84=EC=9E=AC =
SD-PMIP =EA=B8=B0=EB=B2=95=EC=97=90 =EB=8C=80=ED=95=B4 =
=EC=A0=9C=EC=95=88 =EC=97=AC=EB=B6=80=EB=A5=BC =
=EA=B3=A0=EB=AF=BC=ED=95=98=EA=B3=A0 =EC=9E=88=EB=8B=A4.
>
> =EC=9D=B4=EB=A0=87=EA=B2=8C =
=EB=8B=B5=EB=B3=80=EC=9D=84 =ED=95=9C=EB=8B=A4=EB=A9=B4 =
=EB=8B=A4=EC=9D=8C =EB=AC=B8=EC=84=9C=EC=97=90=EC=84=9C SD-PMIP=EC=9D=84 =
=EC=A0=9C=EC=99=B8=ED=95=98=EB=8A=94 =EA=B2=83=EC=97=90 =
=EB=8C=80=ED=95=9C =EC=A0=90=EB=8F=84 =EC=96=B4=EB=8A=90 =
=EC=A0=95=EB=8F=84 MEXT WG=EC=97=90 =
=EC=96=B4=ED=95=84=ED=95=A0 =EC=88=98 =EC=9E=88=EA=B3=A0 =
=EB=8B=B5=EB=B3=80=EB=8F=84 =EB=90=A0 =EA=B2=83 =
=EA=B0=99=EC=8A=B5=EB=8B=88=EB=8B=A4.
>
> =
=EA=B5=90=EC=88=98=EB=8B=98 =EC=83=9D=EA=B0=81=EC=9D=80 =
=EC=96=B4=EB=96=A0=EC=8B=A0=EC=A7=80=EC=9A=94?
>
>
> =
=EA=B9=80=EC=A7=80=EC=9D=B8 =EB=93=9C=EB=A6=BC
> =
----------------------------------------------------------------------> =EA=B2=BD=EB=B6=81=EB=8C=80=ED=95=99=EA=B5=90 IT=EB=8C=80=ED=95=99 =
=EC=BB=B4=ED=93=A8=ED=84=B0=ED=95=99=EB=B6=80 =
=ED=86=B5=EC=8B=A0=ED=94=84=EB=A1=9C=ED=86=A0=EC=BD=9C =
=EC=97=B0=EA=B5=AC=EC=8B=A4 =EB=B0=95=EC=82=AC=EA=B3=BC=EC=A0=95
> =
=EA=B2=BD=EB=B6=81=EB=8C=80=ED=95=99=EA=B5=90 =
IT=EB=8C=80=ED=95=99 =
3=ED=98=B8=EA=B4=80 309A=ED=98=B8
> E-mail: jiin16@gmail.com
> Tel: =
053-940-8608 C.P: 010-9371-1324
>
>
> -----Original =
Message-----
> From: Seok-Joo Koh [mailto:sjkoh@knu.ac.kr]
> Sent: =
Wednesday, December 07, 2011 8:39 AM
> To: =
=EA=B9=80=EC=A7=80=EC=9D=B8
> Subject: =
Fw: [MEXT] Comments on =
"draft-sjkoh-mext-pmip-dmc-03"
>
> =
PMIP=EC=9D=98 HoA =
(=EB=8B=A8=EB=A7=90)=EC=99=80 PCoA(MAG)=EB=A5=BC =
=ED=98=BC=EB=8F=99=ED=95=98=EA=B3=A0 =EC=9E=88=EB=8A=94=EB=93=AF =
=ED=95=9C=EB=8D=B0..
>
> =
=EC=96=B4=EB=96=A4 =EC=A3=BC=EC=86=8C=EC=97=90 =
=EB=8C=80=ED=95=9C prefix ??
>
> =
=EC=9D=91=EB=8B=B5=EC=8B=9C=EC=97=90 =EA=B4=80=EB=A0=A8 =
=EC=9A=A9=EC=96=B4=EB=A5=BC =EB=B6=84=EB=AA=85=ED=9E=88 =
=ED=95=98=EB=8A=94=EA=B2=8C =EC=A2=8B=EC=9D=84=EB=93=AF..
>
>
> =
*************************
> Seok-Joo Koh
> sjkoh@knu.ac.kr
> =
*************************
>
> ----- Original Message =
-----
> From: "Jong-Hyouk Lee" <jong-hyouk.lee@inria.fr>> To: "Ji-In Kim" <jiin16@gmail.com>
> Cc: =
"=EA=B3=A0=EC=84=9D=EC=A3=BC=EA=B5=90=EC=88=98=EB=8B=98" <sjkoh@knu.ac.kr>; =
"'mext'" <mext@ietf.org>
> Sent: =
Wednesday, December 07, 2011 5:08 AM
> Subject: Re: [MEXT] =
Comments on =
"draft-sjkoh-mext-pmip-dmc-03"
>
>
>> =
Dear Ji-In Kim,
>>
>> I do not think that all mobile =
nodes have the same prefix in a SD-PMIP domain consisting of =
MAGs.
>> I thought that a network prefix assigned to a mobile =
node is managed
>> by a serving MAG. Are you really considering =
that all of the nodes in the SD-PMIP domain have the same =
prefix?
>>
>> Cheers.
>>
>> On Tue =
06 Dec 2011 04:01:33 AM CET, Ji-In Kim =
wrote:
>>>
>>> Dear Jong-Hyuok =
Lee,
>>>
>>> Thank you for the valuable =
comments. Please see my inline =
responses.
>>>
>>> 1) We suppose that both MN =
and CN are in the same domain in the
>>> S-PMIP and SD-PMIP. =
So, all of the nodes in SD-PMIP have the same prefix.
>>> 2) =
In the draft, we didn't consider the handover scenario =
yet.
>>> However, we will revise the draft to include the =
handover scenarios within this =
month.
>>>
>>>
>>> Best Regards, =
Ji-In Kim
>>> =
--------------------------------------------------------------------
&=
gt;>> -- Ph.D student, Communications Protocols Lab, Kyungpook =
National
>>> University.
>>> 1370 Sankyuk-dong, =
Buk-gu, Daegu, Korea.
>>> E-mail: jiin16@gmail.com
>>> =
Tel: 82-53-940-8608 C.P: =
82-10-9371-1324
>>>
>>>>
>>>> =
-----Original Message-----
>>>> From: mext-bounces@ietf.org =
[mailto:mext-bounces@ietf.org] =
On
>>>> Behalf Of
>>>
>>> =
Jong-Hyouk Lee
>>>>
>>>> Sent: Monday, =
December 05, 2011 1:36 AM
>>>> To: sjkoh@knu.ac.kr; =
mext
>>>> Subject: [MEXT] Comments on =
"draft-sjkoh-mext-pmip-dmc-03"
>>>>
>>&=
gt;> Dear authors,
>>>>
>>>> I read the =
draft "draft-sjkoh-mext-pmip-dmc-03" and =
have
>>>
>>> =
comments/questions:
>>>>
>>>>
>>&g=
t;> How is an MN's handover handled in SD-PMIP? For instance: 1) =
It's
>>>> not
>>>
>>> clear how a =
prefix of the MN is provided; and 2) it is also not
>>> =
clear from the draft how ongoing packets (destined to the MN or =
sent
>>> from the
>>>>
>>>> =
MN) are handled during =
handovers.
>>>>
>>>> Thanks.
>>>>
>>>> =
--
>>>> IMARA Team, INRIA, =
France
>>>> Jong-Hyouk Lee, =
living somewhere between /dev/null and /dev/random
>>>>
>>>> #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com
>>>> #webpage: http://sites.google.com/si=
te/hurryon/
>>>>
>>>> =
_______________________________________________
>>>> MEXT mailing list
>>>> MEXT@ietf.org
>>>> https://www.ietf.org/=
mailman/listinfo/mext
>>>
>>>
>>> =
--
>>> IMARA Team, INRIA, =
France
>>> Jong-Hyouk Lee, =
living somewhere between /dev/null and /dev/random
>>>
>>> =
#email: hurryon (at) gmail.com || =
jong-hyouk.lee (at) inria.fr
>>> #webpage: http://sites.google.com/si=
te/hurryon/
>


 
-- =

 
***********************
Seok-Joo Koh
sjkoh@knu.ac.kr
******************=
*****

<=
/div>
------=_NextPart_000_007C_01CCB8CC.5A97D1C0--


From jouni.nospam@gmail.com  Wed Dec 14 00:54:48 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E0621F8678 for ; Wed, 14 Dec 2011 00:54:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DC5TiQqVQ7g for ; Wed, 14 Dec 2011 00:54:47 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88B7721F8669 for ; Wed, 14 Dec 2011 00:54:46 -0800 (PST)
Received: by eeke49 with SMTP id e49so504025eek.31 for ; Wed, 14 Dec 2011 00:54:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=6Dqnt0Tg6Frs+AM0TjUFFKIpqH59ClF61ZYZ68g4bOM=; b=dCcRjSCw6qjCkoTvzXYw46/pzjOL2+273HLTAHM9uL/JX0P1BtI/PEYvqVJ/jGTM+q t33H7CGbY/00ieiUJRkooodK14rzhd+hroXI4yF+XMj9icYh4TQLfrrSqWl1Fi0q2kb5 ydh+f3f7qaV/ZJ+VHu51EzGayrS5lKp0E9iXI=
Received: by 10.14.32.15 with SMTP id n15mr1055587eea.116.1323852881676; Wed, 14 Dec 2011 00:54:41 -0800 (PST)
Received: from [10.45.197.110] (gprs-internet-ffc5ee00-110.dhcp.inet.fi. [188.238.197.110]) by mx.google.com with ESMTPS id s16sm7821936eef.2.2011.12.14.00.54.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Dec 2011 00:54:41 -0800 (PST)
From: jouni korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Dec 2011 10:54:26 +0200
Message-Id: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
To: mext@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: "julien.ietf@gmail.com Laganier" , jouni korhonen , Jari Arkko 
Subject: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 08:54:48 -0000

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

 Internet Area Directors:
     Ralph Droms 
     Jari Arkko 

 Internet Area Advisor:
     Jari Arkko 

 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:

  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.  =20
 =20
  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.
 =20
  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.
 =20
Work items related to the distributed mobility management include:
 =20
  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=20=

    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.
   =20
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.=20
  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 luo.wen@zte.com.cn  Wed Dec 14 01:30:29 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFC321F8B20 for ; Wed, 14 Dec 2011 01:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -90.931
X-Spam-Level: 
X-Spam-Status: No, score=-90.931 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001,  MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVACLlINbi-T for ; Wed, 14 Dec 2011 01:30:28 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id ED28421F8B1F for ; Wed, 14 Dec 2011 01:30:27 -0800 (PST)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901783477680; Wed, 14 Dec 2011 17:13:41 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 43852.4405237714; Wed, 14 Dec 2011 17:29:52 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pBE9Thhx060171; Wed, 14 Dec 2011 17:29:43 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
To: jouni korhonen 
MIME-Version: 1.0
X-KeepSent: 4079AAAC:D7E49201-48257966:00330B17; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: luo.wen@zte.com.cn
Date: Wed, 14 Dec 2011 17:29:38 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-14 17:29:44, Serialize complete at 2011-12-14 17:29:44
Content-Type: multipart/alternative; boundary="=_alternative 0034287948257966_="
X-MAIL: mse01.zte.com.cn pBE9Thhx060171
Cc: "julien.ietf@gmail.com Laganier" , mext@ietf.org
Subject: [MEXT] =?gb2312?b?tPC4tDogIFRoZSBmaXJzdCBwcm9wb3NhbCBmb3IgdGhl?= =?gb2312?b?IERNTSBjaGFydGVy?=
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 09:30:29 -0000

This is a multipart message in MIME format.
--=_alternative 0034287948257966_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgIGpvdW5pOg0KDQpJIGhhdmUgYSBxdWljayBxdWVzdGlvbiBhYm91dCAgJ0dvYWxzIGFuZCBN
aWxlc3RvbmVzJy4gDQoNCkFzIGl0IGlzIHN0YXRlZCAnSWYgbGltaXRhdGlvbnMgYXJlIGlkZW50
aWZpZWQgYXMgcGFydCBvZiB0aGUgYWJvdmUgDQpkZWxpdmVyYWJsZSwgc3BlY2lmeSBleHRlbnNp
b25zIHRvIGV4aXN0aW5nIHByb3RvY29scyB0aGF0IHJlbW92ZXMgdGhlc2UgDQpsaW1pdGF0aW9u
cyB3aXRoaW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IGVudmlyb25tZW50Licg
d2hpY2ggDQptZWFucywgSSBndWVzcywgYSBzb2x1dGlvbiB3aWxsIGJlIGNyZWF0ZWQgZm9yIHJl
bW92ZSB0aGVzZSBsaW1pdGF0aW9ucyANCmFuZCBhIFJGQyB3aWxsIGJlIG5lZWRlZC4NCg0KU28g
d2h5IHRoZSAgJ0dvYWxzIGFuZCBNaWxlc3RvbmVzJyBtaXNzZXMgdGhpcyBwYXJ0PyBPciBkb2Vz
IGl0IG1lYW4gdGhlIA0Kc29sdXRpb24gZm9yIHJlbW92ZSB0aGVzZSBsaW1pdGFpb25zIGlzIGFs
c28gaW5jbHVkZWQgaW4gdGhlIEktRCAnQmVzdCANCnByYWN0aWNlcyBhbmQgR2FwIEFuYWx5c2lz
JyA/DQoNCkNoZWVycw0KTHVvd2VuDQoNCg0KDQoNCg0KDQpqb3VuaSBrb3Job25lbiA8am91bmku
bm9zcGFtQGdtYWlsLmNvbT4gDQq3orz+yMs6ICBtZXh0LWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEt
MTItMTQgMTY6NTQNCg0KytW8/sjLDQptZXh0QGlldGYub3JnDQqzrcvNDQoianVsaWVuLmlldGZA
Z21haWwuY29tIExhZ2FuaWVyIiA8anVsaWVuLmlldGZAZ21haWwuY29tPiwgam91bmkga29yaG9u
ZW4gDQo8am91bmkubm9zcGFtQGdtYWlsLmNvbT4sIEphcmkgQXJra28gPGphcmkuYXJra29AcGl1
aGEubmV0Pg0K1vfM4g0KW01FWFRdIFRoZSBmaXJzdCBwcm9wb3NhbCBmb3IgdGhlIERNTSBjaGFy
dGVyDQoNCg0KDQoNCg0KDQpGb2xrcywNCg0KV2UgaGF2ZSBiZWVuIHdvcmtpbmcgb24gYSBjaGFy
dGVyIHRleHQgZnJvbSBETU0gYmFzZWQgb24gdGhlIGluaXRpYWwgZ29hbCANCnNldHRpbmcgYW5k
IHRoZSBpbnB1dCB3ZSByZWNlaXZlZCBkdXJpbmcgdGhlIFRhaXBlaSBtZWV0aW5nLiBOb3RlIHRo
YXQgDQp0aGlzIGlzIHRoZSBmaXJzdCBkcmFmdCBhbmQgbm93IHdlIGFyZSBzb2xpY2l0aW5nIGZv
ciBpbnB1dC4NCg0KLSBKb3VuaSAmIEp1bGllbg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRGlz
dHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdlbWVudCAoRE1NKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KDQpDaGFydGVyDQoNCiBDdXJyZW50IFN0YXR1czogQWN0aXZlDQoN
CiBDaGFpcnM6DQogICAgIEp1bGllbiBMYWdhbmllciA8anVsaWVuLmlldGZAZ21haWwuY29tPg0K
ICAgICBKb3VuaSBLb3Job25lbiA8am91bmkubm9zcGFtQGdtYWlsLmNvbT4NCg0KIEludGVybmV0
IEFyZWEgRGlyZWN0b3JzOg0KICAgICBSYWxwaCBEcm9tcyA8cmRyb21zLmlldGZAZ21haWwuY29t
Pg0KICAgICBKYXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4NCg0KIEludGVybmV0IEFy
ZWEgQWR2aXNvcjoNCiAgICAgSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQoNCiBN
YWlsaW5nIExpc3RzOg0KICAgICBHZW5lcmFsIERpc2N1c3Npb246IG1leHRAaWV0Zi5vcmcNCiAg
ICAgVG8gU3Vic2NyaWJlOiAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL21leHQNCiAgICAgQXJjaGl2ZTogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL21h
aWwtYXJjaGl2ZS93ZWIvbWV4dA0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOg0KDQog
IFRoZSBEaXN0cmlidXRlZCBNb2JpbGl0eSBNYW5hZ2VtZW50IChETU0pIHdvcmtpbmcgZ3JvdXAg
c3BlY2lmaWVzIElQDQogIG1vYmlsaXR5LCBhY2Nlc3MgbmV0d29yayBhbmQgcm91dGluZyBzb2x1
dGlvbnMsIHdoaWNoIGFsbG93IGZvcg0KICBzZXR0aW5nIHVwIElQIG5ldHdvcmtzIHNvIHRoYXQg
dHJhZmZpYyBpcyBkaXN0cmlidXRlZCBpbiBhbg0KICBvcHRpbWFsIHdheSBhbmQgZG9lcyBub3Qg
cmVseSBvbiBjZW50cmFsbHkgZGVwbG95ZWQgYW5jaG9ycyB0byBtYW5hZ2UNCiAgSVAgbW9iaWxp
dHkgc2Vzc2lvbnMuIFRoZSBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IHNvbHV0aW9u
cw0KICBhaW0gZm9yIHRyYW5zcGFyZW5jeSBhYm92ZSB0aGUgSVAgbGF5ZXIsIGluY2x1ZGluZyBt
YWludGVuYW5jZSBvZg0KICBhY3RpdmUgdHJhbnNwb3J0IGxldmVsIHNlc3Npb25zIGFzIG1vYmls
ZSBob3N0cyBvciBlbnRpcmUgbW9iaWxlDQogIG5ldHdvcmtzIGNoYW5nZSB0aGVpciBwb2ludCBv
ZiBhdHRhY2htZW50IHRvIHRoZSBJbnRlcm5ldC4gDQogDQogIFRoZSBwcm90b2NvbCBzb2x1dGlv
bnMgc2hvdWxkIGJlIGVuaGFuY2VtZW50cyB0byBleGlzdGluZyBJUCBtb2JpbGl0eQ0KICBwcm90
b2NvbHMsIGVpdGhlciBob3N0LSBvciBuZXR3b3JrLWJhc2VkLCBzdWNoIGFzIE1vYmlsZSBJUHY2
DQogIFtSRkM2Mjc1LCA1NTU1XSwgUHJveHkgTW9iaWxlIElQdjYgW1JGQzUyMTMsIDU4NDRdIGFu
ZA0KICBORU1PIFtSRkMzOTYzXS4gQWx0ZXJuYXRpdmVseSwgdGhlIGRpc3RyaWJ1dGVkIG1vYmls
aXR5IG1hbmFnZW1lbnQNCiAgc29sdXRpb24gY2FuIGJlIHRyYW5zcGFyZW50IHRvIGFueSB1bmRl
cmx5aW5nIElQIG1vYmlsaXR5IHByb3RvY29sLg0KICBBbHRob3VnaCB0aGUgbWFpbnRlbmFuY2Ug
b2Ygc3RhYmxlIGhvbWUgYWRkcmVzcyhlcykgYW5kL29yIHByZWZpeChlcykNCiAgYW5kIHVwcGVy
IGxldmVsIHNlc3Npb25zIGlzIGEgZGVzaXJhYmxlIGdvYWwgd2hlbiBtb2JpbGUgaG9zdHMvcm91
dGVycw0KICBjaGFuZ2UgdGhlaXIgcG9pbnQgb2YgYXR0YWNobWVudCB0byB0aGUgSW50ZXJuZXQs
IGl0IGlzIG5vdCBhIHN0cmljdA0KICByZXF1aXJlbWVudC4gTW9iaWxlIGhvc3RzL3JvdXRlcnMg
c2hvdWxkIG5vdCBhc3N1bWUgdGhhdCBJUA0KICBhZGRyZXNzaW5nIGluY2x1ZGluZyBob21lIGFk
ZHJlc3MoZXMpIGFuZC9vciBob21lIG5ldHdvcmsgcHJlZml4KGVzKQ0KICByZW1haW4gdGhlIHNh
bWUgdGhyb3VnaG91dCB0aGUgZW50aXJlIHVwcGVyIGxldmVsIHNlc3Npb24gbGlmZXRpbWUuDQog
DQogIFRoZSBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IHNvbHV0aW9ucyBwcmltYXJp
bHkgdGFyZ2V0IElQdjYNCiAgRGVwbG95bWVudCBhbmQgc2hvdWxkIG5vdCBiZSB0YWlsb3JlZCBz
cGVjaWZpY2FsbHkgdG8gc3VwcG9ydCBJUHY0LA0KICBpbiBwYXJ0aWN1bGFyIGluIHNpdHVhdGlv
bnMgd2hlcmUgcHJpdmF0ZSBJUHY0IGFkZHJlc3NlcyBhbmQvb3IgTkFUcw0KICBhcmUgdXNlZC4g
QXQgbGVhc3QgSVB2NiBpcyBhc3N1bWVkIHRvIGJlIHByZXNlbnQgaW4gYm90aCB0aGUgbW9iaWxl
DQogIGhvc3Qvcm91dGVyIGFuZCB0aGUgYWNjZXNzIG5ldHdvcmtzLiBJbmRlcGVuZGVudCBvZiB0
aGUgZGlzdHJpYnV0ZWQNCiAgbW9iaWxpdHkgbWFuYWdlbWVudCBzb2x1dGlvbiwgYmFja3dhcmQg
Y29tcGF0aWJpbGl0eSBtdXN0IGJlDQogIG1haW50YWluZWQuIElmIHRoZSBuZXR3b3JrIG9yIHRo
ZSBtb2JpbGUgaG9zdC9yb3V0ZXIgZG8gbm90IHN1cHBvcnQNCiAgdGhlIGRpc3RyaWJ1dGVkIG1v
YmlsaXR5IG1hbmFnZW1lbnQgZW5hYmxpbmcgcHJvdG9jb2wsIG5vdGhpbmcgc2hvdWxkDQogIGJy
ZWFrLg0KIA0KV29yayBpdGVtcyByZWxhdGVkIHRvIHRoZSBkaXN0cmlidXRlZCBtb2JpbGl0eSBt
YW5hZ2VtZW50IGluY2x1ZGU6DQogDQogIG8gU29sdXRpb24gUmVxdWlyZW1lbnRzOiBEZWZpbmUg
cHJlY2lzZWx5IHRoZSBwcm9ibGVtIG9mIGRpc3RyaWJ1dGVkDQogICAgbW9iaWxpdHkgbWFuYWdl
bWVudCBhbmQgaWRlbnRpdHkgdGhlIHJlcXVpcmVtZW50cyBmb3IgYSBkaXN0cmlidXRlZA0KICAg
IG1vYmlsaXR5IG1hbmFnZW1lbnQgc29sdXRpb24uDQoNCiAgbyBCZXN0IHByYWN0aWNlcyBhbmQg
R2FwIEFuYWx5c2lzOiBEb2N1bWVudCBiZXN0IHByYWN0aWNlcyBmb3IgdGhlDQogICAgZGVwbG95
bWVudCBvZiBleGlzdGluZyBtb2JpbGl0eSBwcm90b2NvbHMgaW4gYSBkaXN0cmlidXRlZCBtb2Jp
bGl0eSANCiAgICBtYW5hZ2VtZW50IGVudmlyb25tZW50IGFuZCBpZGVudGlmeSB0aGUgbGltaXRh
dGlvbnMgb2YgZWFjaCBzdWNoDQogICAgYXBwcm9hY2ggd2l0aCByZXNwZWN0IHRvIGZ1bGZpbGxt
ZW50IG9mIHRoZSBzb2x1dGlvbiByZXF1aXJlbWVudHMuDQoNCiAgbyBJZiBsaW1pdGF0aW9ucyBh
cmUgaWRlbnRpZmllZCBhcyBwYXJ0IG9mIHRoZSBhYm92ZSBkZWxpdmVyYWJsZSwNCiAgICBzcGVj
aWZ5IGV4dGVuc2lvbnMgdG8gZXhpc3RpbmcgcHJvdG9jb2xzIHRoYXQgcmVtb3ZlcyB0aGVzZQ0K
ICAgIGxpbWl0YXRpb25zIHdpdGhpbiBhIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQg
ZW52aXJvbm1lbnQuDQogDQpHb2FscyBhbmQgTWlsZXN0b25lczoNCg0KICBBdWcgMjAxMiAtIFN1
Ym1pdCBJLUQgJ1NvbHV0aW9uIFJlcXVpcmVtZW50cycgYXMgYSB3b3JraW5nDQogICAgICAgICAg
ICAgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIEluZm9ybWF0aW9uYWwgUkZDLg0KICBBdWcgMjAxMiAt
IFN1Ym1pdCBJLUQgJ0Jlc3QgcHJhY3RpY2VzIGFuZCBHYXAgQW5hbHlzaXMnIGFzIGEgd29ya2lu
Zw0KICAgICAgICAgICAgIGdyb3VwIGRvY3VtZW50LiBUbyBiZSBJbmZvcm1hdGlvbmFsIFJGQy4N
CiAgTm92IDIwMTIgLSBFdmFsdWF0ZSB0aGUgbmVlZCBmb3IgYWRkaXRpb25hbCB3b3JraW5nIGdy
b3VwIGRvY3VtZW50KHMpDQogICAgICAgICAgICAgZm9yIGV4dGVuc2lvbnMgdG8gZmlsbCB0aGUg
aWRlbnRpZmllZCBnYXBzLg0KICBKYW4gMjAxMyAtIFN1Ym1pdCBJLUQgJ1NvbHV0aW9uIFJlcXVp
cmVtZW50cycgdG8gdGhlIElFU0cgZm9yDQogICAgICAgICAgICAgY29uc2lkZXJhdGlvbiBhcyBh
biBJbmZvcm1hdGlvbmFsIFJGQy4gDQogIEphbiAyMDEzIC0gU3VibWl0IEktRCAnQmVzdCBwcmFj
dGljZXMgYW5kIEdhcCBBbmFseXNpcycgdG8gdGhlIElFU0cgZm9yDQogICAgICAgICAgICAgY29u
c2lkZXJhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy4NCiAgTWFyIDIwMTMgLSBDb25jbHVk
ZSB0aGUgd29ya2luZyBncm91cCBvciByZS1jaGFydGVyLg0KDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNRVhUIG1haWxpbmcgbGlzdA0KTUVYVEBp
ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0DQoNCg0K
DQo=
--=_alternative 0034287948257966_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICZuYnNwO2pvdW5pOjwvZm9u
dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBoYXZlIGEgcXVp
Y2sgcXVlc3Rpb24gYWJvdXQgJm5ic3A7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+J0dvYWxzDQph
bmQgTWlsZXN0b25lcycuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
QXMgaXQgaXMgc3RhdGVkICc8aT5JZiBsaW1pdGF0aW9ucyBhcmUgaWRlbnRpZmllZA0KYXMgcGFy
dCBvZiB0aGUgYWJvdmUgZGVsaXZlcmFibGUsIHNwZWNpZnkgZXh0ZW5zaW9ucyB0byBleGlzdGlu
ZyBwcm90b2NvbHMNCnRoYXQgcmVtb3ZlcyB0aGVzZSBsaW1pdGF0aW9ucyB3aXRoaW4gYSBkaXN0
cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50DQplbnZpcm9ubWVudDwvaT4uJyB3aGljaCBtZWFu
cywgSSBndWVzcywgYSBzb2x1dGlvbiB3aWxsIGJlIGNyZWF0ZWQgZm9yDQpyZW1vdmUgdGhlc2Ug
bGltaXRhdGlvbnMgYW5kIGEgUkZDIHdpbGwgYmUgbmVlZGVkLjwvZm9udD48L3R0Pg0KPGJyPg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+U28gd2h5IHRoZSAmbmJzcDsnR29hbHMgYW5kIE1pbGVzdG9u
ZXMnIG1pc3NlcyB0aGlzDQpwYXJ0PyBPciBkb2VzIGl0IG1lYW4gdGhlIHNvbHV0aW9uIGZvciBy
ZW1vdmUgdGhlc2UgbGltaXRhaW9ucyBpcyBhbHNvDQppbmNsdWRlZCBpbiB0aGUgPGk+SS1EICdC
ZXN0IHByYWN0aWNlcyBhbmQgR2FwIEFuYWx5c2lzJzwvaT4gPzwvZm9udD48L3R0Pg0KPGJyPg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Q2hlZXJzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj5MdW93ZW48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi
cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxm
b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5qb3VuaSBrb3Job25lbiAmbHQ7am91bmku
bm9zcGFtQGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bWV4dC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0K
PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMTItMTQgMTY6NTQ8L2ZvbnQ+
DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0
ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I
yzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+bWV4dEBp
ZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48
Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7anVsaWVuLmlldGZAZ21haWwuY29tIExh
Z2FuaWVyJnF1b3Q7DQombHQ7anVsaWVuLmlldGZAZ21haWwuY29tJmd0Oywgam91bmkga29yaG9u
ZW4gJmx0O2pvdW5pLm5vc3BhbUBnbWFpbC5jb20mZ3Q7LA0KSmFyaSBBcmtrbyAmbHQ7amFyaS5h
cmtrb0BwaXVoYS5uZXQmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs
aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2
Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bTUVYVF0gVGhlIGZpcnN0IHBy
b3Bvc2FsIGZvciB0aGUgRE1NDQpjaGFydGVyPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+
DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+
DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Gb2xrcyw8YnI+DQo8YnI+DQpXZSBoYXZlIGJl
ZW4gd29ya2luZyBvbiBhIGNoYXJ0ZXIgdGV4dCBmcm9tIERNTSBiYXNlZCBvbiB0aGUgaW5pdGlh
bCBnb2FsDQpzZXR0aW5nIGFuZCB0aGUgaW5wdXQgd2UgcmVjZWl2ZWQgZHVyaW5nIHRoZSBUYWlw
ZWkgbWVldGluZy4gTm90ZSB0aGF0DQp0aGlzIGlzIHRoZSBmaXJzdCBkcmFmdCBhbmQgbm93IHdl
IGFyZSBzb2xpY2l0aW5nIGZvciBpbnB1dC48YnI+DQo8YnI+DQotIEpvdW5pICZhbXA7IEp1bGll
bjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpEaXN0cmlidXRl
ZCBNb2JpbGl0eSBNYW5hZ2VtZW50IChETU0pPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCkNoYXJ0ZXI8YnI+DQo8YnI+DQogQ3VycmVudCBTdGF0
dXM6IEFjdGl2ZTxicj4NCjxicj4NCiBDaGFpcnM6PGJyPg0KICZuYnNwOyAmbmJzcDsgSnVsaWVu
IExhZ2FuaWVyICZsdDtqdWxpZW4uaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KICZuYnNwOyAmbmJz
cDsgSm91bmkgS29yaG9uZW4gJmx0O2pvdW5pLm5vc3BhbUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGJy
Pg0KIEludGVybmV0IEFyZWEgRGlyZWN0b3JzOjxicj4NCiAmbmJzcDsgJm5ic3A7IFJhbHBoIERy
b21zICZsdDtyZHJvbXMuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KICZuYnNwOyAmbmJzcDsgSmFy
aSBBcmtrbyAmbHQ7amFyaS5hcmtrb0BwaXVoYS5uZXQmZ3Q7PGJyPg0KPGJyPg0KIEludGVybmV0
IEFyZWEgQWR2aXNvcjo8YnI+DQogJm5ic3A7ICZuYnNwOyBKYXJpIEFya2tvICZsdDtqYXJpLmFy
a2tvQHBpdWhhLm5ldCZndDs8YnI+DQo8YnI+DQogTWFpbGluZyBMaXN0czo8YnI+DQogJm5ic3A7
ICZuYnNwOyBHZW5lcmFsIERpc2N1c3Npb246IG1leHRAaWV0Zi5vcmc8YnI+DQogJm5ic3A7ICZu
YnNwOyBUbyBTdWJzY3JpYmU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbWV4dDxicj4NCiAmbmJzcDsgJm5ic3A7IEFyY2hpdmU6ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL3d3dy5pZXRmLm9y
Zy9tYWlsLWFyY2hpdmUvd2ViL21leHQ8YnI+DQo8YnI+DQpEZXNjcmlwdGlvbiBvZiBXb3JraW5n
IEdyb3VwOjxicj4NCjxicj4NCiAmbmJzcDtUaGUgRGlzdHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdl
bWVudCAoRE1NKSB3b3JraW5nIGdyb3VwIHNwZWNpZmllcw0KSVA8YnI+DQogJm5ic3A7bW9iaWxp
dHksIGFjY2VzcyBuZXR3b3JrIGFuZCByb3V0aW5nIHNvbHV0aW9ucywgd2hpY2ggYWxsb3cgZm9y
PGJyPg0KICZuYnNwO3NldHRpbmcgdXAgSVAgbmV0d29ya3Mgc28gdGhhdCB0cmFmZmljIGlzIGRp
c3RyaWJ1dGVkIGluIGFuPGJyPg0KICZuYnNwO29wdGltYWwgd2F5IGFuZCBkb2VzIG5vdCByZWx5
IG9uIGNlbnRyYWxseSBkZXBsb3llZCBhbmNob3JzIHRvIG1hbmFnZTxicj4NCiAmbmJzcDtJUCBt
b2JpbGl0eSBzZXNzaW9ucy4gVGhlIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQgc29s
dXRpb25zPGJyPg0KICZuYnNwO2FpbSBmb3IgdHJhbnNwYXJlbmN5IGFib3ZlIHRoZSBJUCBsYXll
ciwgaW5jbHVkaW5nIG1haW50ZW5hbmNlIG9mPGJyPg0KICZuYnNwO2FjdGl2ZSB0cmFuc3BvcnQg
bGV2ZWwgc2Vzc2lvbnMgYXMgbW9iaWxlIGhvc3RzIG9yIGVudGlyZSBtb2JpbGU8YnI+DQogJm5i
c3A7bmV0d29ya3MgY2hhbmdlIHRoZWlyIHBvaW50IG9mIGF0dGFjaG1lbnQgdG8gdGhlIEludGVy
bmV0LiAmbmJzcDsNCjxicj4NCiAmbmJzcDs8YnI+DQogJm5ic3A7VGhlIHByb3RvY29sIHNvbHV0
aW9ucyBzaG91bGQgYmUgZW5oYW5jZW1lbnRzIHRvIGV4aXN0aW5nIElQIG1vYmlsaXR5PGJyPg0K
ICZuYnNwO3Byb3RvY29scywgZWl0aGVyIGhvc3QtIG9yIG5ldHdvcmstYmFzZWQsIHN1Y2ggYXMg
TW9iaWxlIElQdjY8YnI+DQogJm5ic3A7W1JGQzYyNzUsIDU1NTVdLCBQcm94eSBNb2JpbGUgSVB2
NiBbUkZDNTIxMywgNTg0NF0gYW5kPGJyPg0KICZuYnNwO05FTU8gW1JGQzM5NjNdLiBBbHRlcm5h
dGl2ZWx5LCB0aGUgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVudDxicj4NCiAmbmJzcDtz
b2x1dGlvbiBjYW4gYmUgdHJhbnNwYXJlbnQgdG8gYW55IHVuZGVybHlpbmcgSVAgbW9iaWxpdHkg
cHJvdG9jb2wuPGJyPg0KICZuYnNwO0FsdGhvdWdoIHRoZSBtYWludGVuYW5jZSBvZiBzdGFibGUg
aG9tZSBhZGRyZXNzKGVzKSBhbmQvb3IgcHJlZml4KGVzKTxicj4NCiAmbmJzcDthbmQgdXBwZXIg
bGV2ZWwgc2Vzc2lvbnMgaXMgYSBkZXNpcmFibGUgZ29hbCB3aGVuIG1vYmlsZSBob3N0cy9yb3V0
ZXJzPGJyPg0KICZuYnNwO2NoYW5nZSB0aGVpciBwb2ludCBvZiBhdHRhY2htZW50IHRvIHRoZSBJ
bnRlcm5ldCwgaXQgaXMgbm90IGEgc3RyaWN0PGJyPg0KICZuYnNwO3JlcXVpcmVtZW50LiBNb2Jp
bGUgaG9zdHMvcm91dGVycyBzaG91bGQgbm90IGFzc3VtZSB0aGF0IElQPGJyPg0KICZuYnNwO2Fk
ZHJlc3NpbmcgaW5jbHVkaW5nIGhvbWUgYWRkcmVzcyhlcykgYW5kL29yIGhvbWUgbmV0d29yayBw
cmVmaXgoZXMpPGJyPg0KICZuYnNwO3JlbWFpbiB0aGUgc2FtZSB0aHJvdWdob3V0IHRoZSBlbnRp
cmUgdXBwZXIgbGV2ZWwgc2Vzc2lvbiBsaWZldGltZS48YnI+DQogJm5ic3A7PGJyPg0KICZuYnNw
O1RoZSBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IHNvbHV0aW9ucyBwcmltYXJpbHkg
dGFyZ2V0IElQdjY8YnI+DQogJm5ic3A7RGVwbG95bWVudCBhbmQgc2hvdWxkIG5vdCBiZSB0YWls
b3JlZCBzcGVjaWZpY2FsbHkgdG8gc3VwcG9ydCBJUHY0LDxicj4NCiAmbmJzcDtpbiBwYXJ0aWN1
bGFyIGluIHNpdHVhdGlvbnMgd2hlcmUgcHJpdmF0ZSBJUHY0IGFkZHJlc3NlcyBhbmQvb3INCk5B
VHM8YnI+DQogJm5ic3A7YXJlIHVzZWQuIEF0IGxlYXN0IElQdjYgaXMgYXNzdW1lZCB0byBiZSBw
cmVzZW50IGluIGJvdGggdGhlIG1vYmlsZTxicj4NCiAmbmJzcDtob3N0L3JvdXRlciBhbmQgdGhl
IGFjY2VzcyBuZXR3b3Jrcy4gSW5kZXBlbmRlbnQgb2YgdGhlIGRpc3RyaWJ1dGVkPGJyPg0KICZu
YnNwO21vYmlsaXR5IG1hbmFnZW1lbnQgc29sdXRpb24sIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg
bXVzdCBiZTxicj4NCiAmbmJzcDttYWludGFpbmVkLiBJZiB0aGUgbmV0d29yayBvciB0aGUgbW9i
aWxlIGhvc3Qvcm91dGVyIGRvIG5vdCBzdXBwb3J0PGJyPg0KICZuYnNwO3RoZSBkaXN0cmlidXRl
ZCBtb2JpbGl0eSBtYW5hZ2VtZW50IGVuYWJsaW5nIHByb3RvY29sLCBub3RoaW5nIHNob3VsZDxi
cj4NCiAmbmJzcDticmVhay48YnI+DQogJm5ic3A7PGJyPg0KV29yayBpdGVtcyByZWxhdGVkIHRv
IHRoZSBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IGluY2x1ZGU6PGJyPg0KICZuYnNw
Ozxicj4NCiAmbmJzcDtvIFNvbHV0aW9uIFJlcXVpcmVtZW50czogRGVmaW5lIHByZWNpc2VseSB0
aGUgcHJvYmxlbSBvZiBkaXN0cmlidXRlZDxicj4NCiAmbmJzcDsgJm5ic3A7bW9iaWxpdHkgbWFu
YWdlbWVudCBhbmQgaWRlbnRpdHkgdGhlIHJlcXVpcmVtZW50cyBmb3IgYSBkaXN0cmlidXRlZDxi
cj4NCiAmbmJzcDsgJm5ic3A7bW9iaWxpdHkgbWFuYWdlbWVudCBzb2x1dGlvbi48YnI+DQo8YnI+
DQogJm5ic3A7byBCZXN0IHByYWN0aWNlcyBhbmQgR2FwIEFuYWx5c2lzOiBEb2N1bWVudCBiZXN0
IHByYWN0aWNlcyBmb3IgdGhlPGJyPg0KICZuYnNwOyAmbmJzcDtkZXBsb3ltZW50IG9mIGV4aXN0
aW5nIG1vYmlsaXR5IHByb3RvY29scyBpbiBhIGRpc3RyaWJ1dGVkDQptb2JpbGl0eSA8YnI+DQog
Jm5ic3A7ICZuYnNwO21hbmFnZW1lbnQgZW52aXJvbm1lbnQgYW5kIGlkZW50aWZ5IHRoZSBsaW1p
dGF0aW9ucyBvZiBlYWNoDQpzdWNoPGJyPg0KICZuYnNwOyAmbmJzcDthcHByb2FjaCB3aXRoIHJl
c3BlY3QgdG8gZnVsZmlsbG1lbnQgb2YgdGhlIHNvbHV0aW9uIHJlcXVpcmVtZW50cy48YnI+DQo8
YnI+DQogJm5ic3A7byBJZiBsaW1pdGF0aW9ucyBhcmUgaWRlbnRpZmllZCBhcyBwYXJ0IG9mIHRo
ZSBhYm92ZSBkZWxpdmVyYWJsZSw8YnI+DQogJm5ic3A7ICZuYnNwO3NwZWNpZnkgZXh0ZW5zaW9u
cyB0byBleGlzdGluZyBwcm90b2NvbHMgdGhhdCByZW1vdmVzIHRoZXNlPGJyPg0KICZuYnNwOyAm
bmJzcDtsaW1pdGF0aW9ucyB3aXRoaW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50
IGVudmlyb25tZW50Ljxicj4NCiAmbmJzcDsgJm5ic3A7PGJyPg0KR29hbHMgYW5kIE1pbGVzdG9u
ZXM6PGJyPg0KPGJyPg0KICZuYnNwO0F1ZyAyMDEyIC0gU3VibWl0IEktRCAnU29sdXRpb24gUmVx
dWlyZW1lbnRzJyBhcyBhIHdvcmtpbmc8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIEluZm9ybWF0aW9uYWwNClJGQy48
YnI+DQogJm5ic3A7QXVnIDIwMTIgLSBTdWJtaXQgSS1EICdCZXN0IHByYWN0aWNlcyBhbmQgR2Fw
IEFuYWx5c2lzJyBhcyBhIHdvcmtpbmc8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIEluZm9ybWF0aW9uYWwNClJGQy48
YnI+DQogJm5ic3A7Tm92IDIwMTIgLSBFdmFsdWF0ZSB0aGUgbmVlZCBmb3IgYWRkaXRpb25hbCB3
b3JraW5nIGdyb3VwIGRvY3VtZW50KHMpPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IGZvciBleHRlbnNpb25zIHRvIGZpbGwgdGhlIGlkZW50aWZpZWQNCmdh
cHMuPGJyPg0KICZuYnNwO0phbiAyMDEzIC0gU3VibWl0IEktRCAnU29sdXRpb24gUmVxdWlyZW1l
bnRzJyB0byB0aGUgSUVTRyBmb3I8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgY29uc2lkZXJhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsDQpSRkMuIDxicj4N
CiAmbmJzcDtKYW4gMjAxMyAtIFN1Ym1pdCBJLUQgJ0Jlc3QgcHJhY3RpY2VzIGFuZCBHYXAgQW5h
bHlzaXMnIHRvIHRoZSBJRVNHDQpmb3I8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgY29uc2lkZXJhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsDQpSRkMuPGJy
Pg0KICZuYnNwO01hciAyMDEzIC0gQ29uY2x1ZGUgdGhlIHdvcmtpbmcgZ3JvdXAgb3IgcmUtY2hh
cnRlci48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCk1FWFQgbWFpbGluZyBsaXN0PGJyPg0KTUVYVEBpZXRmLm9yZzxi
cj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dDxicj4NCjxicj4N
CjwvZm9udD48L3R0Pg0KPGJyPg0K
--=_alternative 0034287948257966_=--


From julien.ietf@gmail.com  Wed Dec 14 09:28:08 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F051F0C63 for ; Wed, 14 Dec 2011 09:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.177
X-Spam-Level: 
X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=-2.423, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOOlel--KkXJ for ; Wed, 14 Dec 2011 09:28:08 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28A351F0C61 for ; Wed, 14 Dec 2011 09:28:08 -0800 (PST)
Received: by pbdd12 with SMTP id d12so1010277pbd.31 for ; Wed, 14 Dec 2011 09:28:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AuGvrryOPKUiOUUeZiGE8liGNByL+FvF0g07u/GZJLs=; b=RcFQR6hKsu5XyTeqCA7Ldd69OhMU4hAxN13QIC44R/F64Hl4Tunew/KNpO5zBhI349 VEO31d/PKLt/oZgBLxWtEF9DV5TilxKEIbPuimeVkvyyVCTczvvqX8FBEkTmFGZMm932 +qOzOWXNmTuRiJAGcMaYzVd+Ol1pNP5IjhVLc=
MIME-Version: 1.0
Received: by 10.68.74.10 with SMTP id p10mr4583550pbv.3.1323883687817; Wed, 14 Dec 2011 09:28:07 -0800 (PST)
Received: by 10.142.102.10 with HTTP; Wed, 14 Dec 2011 09:28:07 -0800 (PST)
In-Reply-To: 
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> 
Date: Wed, 14 Dec 2011 09:28:07 -0800
Message-ID: 
From: Julien Laganier 
To: luo.wen@zte.com.cn
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: jouni korhonen , mext@ietf.org
Subject: Re: [MEXT] =?gb2312?b?tPC4tDogIFRoZSBmaXJzdCBwcm9wb3NhbCBmb3IgdGhl?= =?gb2312?b?IERNTSBjaGFydGVy?=
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 17:28:08 -0000

Luowen,

2011/12/14 
>
>
> Hi =A0jouni:
>
> I have a quick question about =A0'Goals and Milestones'.
>
> As it is stated 'If limitations are identified as part of the above deliv=
erable, specify extensions to existing protocols that removes these limitat=
ions within a distributed mobility management environment.' which means, I =
guess, a solution will be created for remove these limitations and a RFC wi=
ll be needed.
>
> So why the =A0'Goals and Milestones' misses this part? Or does it mean th=
e solution for remove these limitaions is also included in the I-D 'Best pr=
actices and Gap Analysis' ?

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

 Nov 2012 - Evaluate the need for additional working group document(s)
            for extensions to fill the identified gaps.

--julien

From sarikaya2012@gmail.com  Wed Dec 14 09:44:46 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1451F0C47 for ; Wed, 14 Dec 2011 09:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcLeGfVvoI5l for ; Wed, 14 Dec 2011 09:44:45 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5886C21F8A91 for ; Wed, 14 Dec 2011 09:44:45 -0800 (PST)
Received: by yenm7 with SMTP id m7so998794yen.31 for ; Wed, 14 Dec 2011 09:44:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=UF9pFyYKKUE5/r4KvKBACgLurGYmEPnsPKso911HjOI=; b=FlJV96l1/JBX40CNiOIBSgMHSIZjKJpIEDboeV10fhclgtzLB88GTPNeOhF/M01ag/ PcXWTb/zMmVUk4xvbqwvW6OirR4WKoz/AEjG3lIOctnzvbKg32N25+bTcOJjvXNXTQ9f sgyTYhV75D1TqzZMiEk5jz0UljHnNbtNydUlI=
MIME-Version: 1.0
Received: by 10.236.73.166 with SMTP id v26mr13760652yhd.100.1323884684987; Wed, 14 Dec 2011 09:44:44 -0800 (PST)
Received: by 10.236.125.201 with HTTP; Wed, 14 Dec 2011 09:44:44 -0800 (PST)
In-Reply-To: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
Date: Wed, 14 Dec 2011 11:44:44 -0600
Message-ID: 
From: Behcet Sarikaya 
To: jouni korhonen 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "julien.ietf@gmail.com Laganier" , Jari Arkko , mext@ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Dec 2011 17:44:46 -0000

Hi Jouni, Julien,

Should we say that multicast is out of scope?

Multicast dmm  could possibly be covered in Multimob.

Regards,

Behcet

On Wed, Dec 14, 2011 at 2:54 AM, jouni korhonen  wr=
ote:
> 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 thi=
s is the first draft and now we are soliciting for input.
>
> - Jouni & Julien
>
>
> -------------------------------------------------------------------------
>
> Distributed Mobility Management (DMM)
> -------------------------------------
>
> Charter
>
> =A0Current Status: Active
>
> =A0Chairs:
> =A0 =A0 Julien Laganier 
> =A0 =A0 Jouni Korhonen 
>
> =A0Internet Area Directors:
> =A0 =A0 Ralph Droms 
> =A0 =A0 Jari Arkko 
>
> =A0Internet Area Advisor:
> =A0 =A0 Jari Arkko 
>
> =A0Mailing Lists:
> =A0 =A0 General Discussion: mext@ietf.org
> =A0 =A0 To Subscribe: =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/m=
ext
> =A0 =A0 Archive: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/mail-archive/=
web/mext
>
> Description of Working Group:
>
> =A0The Distributed Mobility Management (DMM) working group specifies IP
> =A0mobility, access network and routing solutions, which allow for
> =A0setting up IP networks so that traffic is distributed in an
> =A0optimal way and does not rely on centrally deployed anchors to manage
> =A0IP mobility sessions. The distributed mobility management solutions
> =A0aim for transparency above the IP layer, including maintenance of
> =A0active transport level sessions as mobile hosts or entire mobile
> =A0networks change their point of attachment to the Internet.
>
> =A0The protocol solutions should be enhancements to existing IP mobility
> =A0protocols, either host- or network-based, such as Mobile IPv6
> =A0[RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
> =A0NEMO [RFC3963]. Alternatively, the distributed mobility management
> =A0solution can be transparent to any underlying IP mobility protocol.
> =A0Although the maintenance of stable home address(es) and/or prefix(es)
> =A0and upper level sessions is a desirable goal when mobile hosts/routers
> =A0change their point of attachment to the Internet, it is not a strict
> =A0requirement. Mobile hosts/routers should not assume that IP
> =A0addressing including home address(es) and/or home network prefix(es)
> =A0remain the same throughout the entire upper level session lifetime.
>
> =A0The distributed mobility management solutions primarily target IPv6
> =A0Deployment and should not be tailored specifically to support IPv4,
> =A0in particular in situations where private IPv4 addresses and/or NATs
> =A0are used. At least IPv6 is assumed to be present in both the mobile
> =A0host/router and the access networks. Independent of the distributed
> =A0mobility management solution, backward compatibility must be
> =A0maintained. If the network or the mobile host/router do not support
> =A0the distributed mobility management enabling protocol, nothing should
> =A0break.
>
> Work items related to the distributed mobility management include:
>
> =A0o Solution Requirements: Define precisely the problem of distributed
> =A0 =A0mobility management and identity the requirements for a distribute=
d
> =A0 =A0mobility management solution.
>
> =A0o Best practices and Gap Analysis: Document best practices for the
> =A0 =A0deployment of existing mobility protocols in a distributed mobilit=
y
> =A0 =A0management environment and identify the limitations of each such
> =A0 =A0approach with respect to fulfillment of the solution requirements.
>
> =A0o If limitations are identified as part of the above deliverable,
> =A0 =A0specify extensions to existing protocols that removes these
> =A0 =A0limitations within a distributed mobility management environment.
>
> Goals and Milestones:
>
> =A0Aug 2012 - Submit I-D 'Solution Requirements' as a working
> =A0 =A0 =A0 =A0 =A0 =A0 group document. To be Informational RFC.
> =A0Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
> =A0 =A0 =A0 =A0 =A0 =A0 group document. To be Informational RFC.
> =A0Nov 2012 - Evaluate the need for additional working group document(s)
> =A0 =A0 =A0 =A0 =A0 =A0 for extensions to fill the identified gaps.
> =A0Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
> =A0 =A0 =A0 =A0 =A0 =A0 consideration as an Informational RFC.
> =A0Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG fo=
r
> =A0 =A0 =A0 =A0 =A0 =A0 consideration as an Informational RFC.
> =A0Mar 2013 - Conclude the working group or re-charter.
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext

From luo.wen@zte.com.cn  Wed Dec 14 17:05:48 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80B521F8A91 for ; Wed, 14 Dec 2011 17:05:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -90.56
X-Spam-Level: 
X-Spam-Status: No, score=-90.56 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Memp3LvvtjJL for ; Wed, 14 Dec 2011 17:05:48 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C4CE521F8A7E for ; Wed, 14 Dec 2011 17:05:47 -0800 (PST)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901783477680; Thu, 15 Dec 2011 08:18:50 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 95341.4405237714; Thu, 15 Dec 2011 08:35:24 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pBF0ZJq5018435; Thu, 15 Dec 2011 08:35:19 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: 
To: Julien Laganier 
MIME-Version: 1.0
X-KeepSent: ED49F6F5:B9C35824-48257967:0002F383; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: luo.wen@zte.com.cn
Date: Thu, 15 Dec 2011 08:35:12 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-15 08:35:20, Serialize complete at 2011-12-15 08:35:20
Content-Type: multipart/alternative; boundary="=_alternative 00033B1248257967_="
X-MAIL: mse01.zte.com.cn pBF0ZJq5018435
Cc: jouni korhonen , mext@ietf.org
Subject: [MEXT] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiAgVGhlIGZpcnN0IHByb3Bv?= =?gb2312?b?c2FsIGZvciB0aGUgRE1NIGNoYXJ0ZXI=?=
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Dec 2011 01:05:48 -0000

This is a multipart message in MIME format.
--=_alternative 00033B1248257967_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgSnVsaWVuDQoNClRoYW5rIHlvdSBmb3IgY29ycmVjdGluZyBtZQ0KDQpDaGVlcnMNCkx1b3dl
biANCg0KDQoNCg0KSnVsaWVuIExhZ2FuaWVyIDxqdWxpZW4uaWV0ZkBnbWFpbC5jb20+IA0Kt6K8
/sjLOiAgbWV4dC1ib3VuY2VzQGlldGYub3JnDQoyMDExLTEyLTE1IDAxOjI4DQoNCsrVvP7Iyw0K
bHVvLndlbkB6dGUuY29tLmNuDQqzrcvNDQpqb3VuaSBrb3Job25lbiA8am91bmkubm9zcGFtQGdt
YWlsLmNvbT4sIG1leHRAaWV0Zi5vcmcNCtb3zOINClJlOiBbTUVYVF0gtPC4tDogIFRoZSBmaXJz
dCBwcm9wb3NhbCBmb3IgdGhlIERNTSBjaGFydGVyDQoNCg0KDQoNCg0KDQpMdW93ZW4sDQoNCjIw
MTEvMTIvMTQgPGx1by53ZW5AenRlLmNvbS5jbj4NCj4NCj4NCj4gSGkgIGpvdW5pOg0KPg0KPiBJ
IGhhdmUgYSBxdWljayBxdWVzdGlvbiBhYm91dCAgJ0dvYWxzIGFuZCBNaWxlc3RvbmVzJy4NCj4N
Cj4gQXMgaXQgaXMgc3RhdGVkICdJZiBsaW1pdGF0aW9ucyBhcmUgaWRlbnRpZmllZCBhcyBwYXJ0
IG9mIHRoZSBhYm92ZSANCmRlbGl2ZXJhYmxlLCBzcGVjaWZ5IGV4dGVuc2lvbnMgdG8gZXhpc3Rp
bmcgcHJvdG9jb2xzIHRoYXQgcmVtb3ZlcyB0aGVzZSANCmxpbWl0YXRpb25zIHdpdGhpbiBhIGRp
c3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQgZW52aXJvbm1lbnQuJyB3aGljaCANCm1lYW5z
LCBJIGd1ZXNzLCBhIHNvbHV0aW9uIHdpbGwgYmUgY3JlYXRlZCBmb3IgcmVtb3ZlIHRoZXNlIGxp
bWl0YXRpb25zIA0KYW5kIGEgUkZDIHdpbGwgYmUgbmVlZGVkLg0KPg0KPiBTbyB3aHkgdGhlICAn
R29hbHMgYW5kIE1pbGVzdG9uZXMnIG1pc3NlcyB0aGlzIHBhcnQ/IE9yIGRvZXMgaXQgbWVhbiB0
aGUgDQpzb2x1dGlvbiBmb3IgcmVtb3ZlIHRoZXNlIGxpbWl0YWlvbnMgaXMgYWxzbyBpbmNsdWRl
ZCBpbiB0aGUgSS1EICdCZXN0IA0KcHJhY3RpY2VzIGFuZCBHYXAgQW5hbHlzaXMnID8NCg0KSXQn
cyBub3QgbWlzc2luZywgaXQgaXMgY292ZXJlZCBhcyBwYXJ0IG9mIHRoaXMgbWlsZXN0b25lOg0K
DQogTm92IDIwMTIgLSBFdmFsdWF0ZSB0aGUgbmVlZCBmb3IgYWRkaXRpb25hbCB3b3JraW5nIGdy
b3VwIGRvY3VtZW50KHMpDQogICAgICAgICAgICBmb3IgZXh0ZW5zaW9ucyB0byBmaWxsIHRoZSBp
ZGVudGlmaWVkIGdhcHMuDQoNCi0tanVsaWVuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KTUVYVCBtYWlsaW5nIGxpc3QNCk1FWFRAaWV0Zi5vcmcNCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dA0KDQoNCg0K
--=_alternative 00033B1248257967_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEp1bGllbjwvZm9udD4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciBjb3Jy
ZWN0aW5nIG1lPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij5DaGVlcnM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkx1b3dl
biA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0
ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp
ZiI+PGI+SnVsaWVuIExhZ2FuaWVyICZsdDtqdWxpZW4uaWV0ZkBnbWFpbC5jb20mZ3Q7PC9iPg0K
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNw
O21leHQtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z
LXNlcmlmIj4yMDExLTEyLTE1IDAxOjI4PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3
aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250
IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg
c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmx1by53ZW5AenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2
YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z
ZXJpZiI+am91bmkga29yaG9uZW4gJmx0O2pvdW5pLm5vc3BhbUBnbWFpbC5jb20mZ3Q7LA0KbWV4
dEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo
dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48
Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtNRVhUXSC08Li0OiAmbmJzcDtUaGUg
Zmlyc3QgcHJvcG9zYWwNCmZvciB0aGUgRE1NIGNoYXJ0ZXI8L2ZvbnQ+PC90YWJsZT4NCjxicj4N
Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs
ZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkx1b3dlbiw8YnI+DQo8YnI+DQoy
MDExLzEyLzE0ICZsdDtsdW8ud2VuQHp0ZS5jb20uY24mZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8
YnI+DQomZ3Q7IEhpICZuYnNwO2pvdW5pOjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgaGF2ZSBhIHF1
aWNrIHF1ZXN0aW9uIGFib3V0ICZuYnNwOydHb2FscyBhbmQgTWlsZXN0b25lcycuPGJyPg0KJmd0
Ozxicj4NCiZndDsgQXMgaXQgaXMgc3RhdGVkICdJZiBsaW1pdGF0aW9ucyBhcmUgaWRlbnRpZmll
ZCBhcyBwYXJ0IG9mIHRoZSBhYm92ZQ0KZGVsaXZlcmFibGUsIHNwZWNpZnkgZXh0ZW5zaW9ucyB0
byBleGlzdGluZyBwcm90b2NvbHMgdGhhdCByZW1vdmVzIHRoZXNlDQpsaW1pdGF0aW9ucyB3aXRo
aW4gYSBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IGVudmlyb25tZW50Licgd2hpY2gN
Cm1lYW5zLCBJIGd1ZXNzLCBhIHNvbHV0aW9uIHdpbGwgYmUgY3JlYXRlZCBmb3IgcmVtb3ZlIHRo
ZXNlIGxpbWl0YXRpb25zDQphbmQgYSBSRkMgd2lsbCBiZSBuZWVkZWQuPGJyPg0KJmd0Ozxicj4N
CiZndDsgU28gd2h5IHRoZSAmbmJzcDsnR29hbHMgYW5kIE1pbGVzdG9uZXMnIG1pc3NlcyB0aGlz
IHBhcnQ/IE9yIGRvZXMNCml0IG1lYW4gdGhlIHNvbHV0aW9uIGZvciByZW1vdmUgdGhlc2UgbGlt
aXRhaW9ucyBpcyBhbHNvIGluY2x1ZGVkIGluIHRoZQ0KSS1EICdCZXN0IHByYWN0aWNlcyBhbmQg
R2FwIEFuYWx5c2lzJyA/PGJyPg0KPGJyPg0KSXQncyBub3QgbWlzc2luZywgaXQgaXMgY292ZXJl
ZCBhcyBwYXJ0IG9mIHRoaXMgbWlsZXN0b25lOjxicj4NCjxicj4NCiBOb3YgMjAxMiAtIEV2YWx1
YXRlIHRoZSBuZWVkIGZvciBhZGRpdGlvbmFsIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQocyk8YnI+
DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgZXh0ZW5zaW9u
cyB0byBmaWxsIHRoZSBpZGVudGlmaWVkDQpnYXBzLjxicj4NCjxicj4NCi0tanVsaWVuPGJyPg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpNRVhU
IG1haWxpbmcgbGlzdDxicj4NCk1FWFRAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL21leHQ8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg==
--=_alternative 00033B1248257967_=--


From jouni.nospam@gmail.com  Thu Dec 15 00:17:26 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9812A11E808C for ; Thu, 15 Dec 2011 00:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level: 
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D1qlNDc-TZS for ; Thu, 15 Dec 2011 00:17:25 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D09E11E8089 for ; Thu, 15 Dec 2011 00:17:25 -0800 (PST)
Received: by laah2 with SMTP id h2so902342laa.31 for ; Thu, 15 Dec 2011 00:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6A9ZRezn+IdbmBPaa2xptZbEoLrpfFC+81Mv+tUDkhU=; b=qt00GfQq+H1I5Z+yFa/Sw6t5mMSQfpRzsfFvdkJ+GIb0MfKKMv+kFikDpGqRb61iGp ZFwbWfUxJ8drDu1jj0c0iI1/Psz/uQtKC9JNBFy9TD/whIsZu1ayH+OEeoYPMUMKa3Rt 1Xov0xZ+v2otIfzDvOgdjwivu9MEPGllpn53c=
Received: by 10.152.144.136 with SMTP id sm8mr1610392lab.33.1323937044307; Thu, 15 Dec 2011 00:17:24 -0800 (PST)
Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id hy5sm1619742lab.4.2011.12.15.00.17.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Dec 2011 00:17:21 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=GB2312
From: jouni korhonen 
In-Reply-To: 
Date: Thu, 15 Dec 2011 10:17:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E37A011-7BA2-4B39-8AF5-8311E362A649@gmail.com>
References: 
To: luo.wen@zte.com.cn
X-Mailer: Apple Mail (2.1084)
Cc: Julien Laganier , mext@ietf.org
Subject: Re: [MEXT] =?utf-8?b?562U5aSNOiBSZTogIOetlOWkjTogIFRoZSBmaXJzdCBwcm9w?= =?utf-8?q?osal_for_the_DMM_charter?=
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Dec 2011 08:17:26 -0000

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


On Dec 15, 2011, at 2:35 AM, luo.wen@zte.com.cn wrote:

>=20
> Hi Julien=20
>=20
> Thank you for correcting me=20
>=20
> Cheers=20
> Luowen=20
>=20
>=20
>=20
> Julien Laganier =20
> =B7=A2=BC=FE=C8=CB:  mext-bounces@ietf.org
> 2011-12-15 01:28
>=20
> =CA=D5=BC=FE=C8=CB
> luo.wen@zte.com.cn
> =B3=AD=CB=CD
> jouni korhonen , mext@ietf.org
> =D6=F7=CC=E2
> Re: [MEXT] =B4=F0=B8=B4:  The first proposal for the DMM charter
>=20
>=20
>=20
>=20
>=20
> Luowen,
>=20
> 2011/12/14 
> >
> >
> > 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' ?
>=20
> It's not missing, it is covered as part of this milestone:
>=20
> Nov 2012 - Evaluate the need for additional working group document(s)
>            for extensions to fill the identified gaps.
>=20
> --julien
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>=20
>=20


From jouni.nospam@gmail.com  Thu Dec 15 00:47:58 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CEA21F8510 for ; Thu, 15 Dec 2011 00:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.502
X-Spam-Level: 
X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.097,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzw6YV+J+LUg for ; Thu, 15 Dec 2011 00:47:58 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A05421F850E for ; Thu, 15 Dec 2011 00:47:57 -0800 (PST)
Received: by laah2 with SMTP id h2so911416laa.31 for ; Thu, 15 Dec 2011 00:47:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kvG5zB7KxFknOoMS5ZntEGGDRjTSvzXf8Np+r2CM0Mo=; b=Vp1di1U+FRPMmXuCTVazpUlJjKBQfRgKMKGt/pQSq9R4TzsTDhAHddw83ek6ZSDGPp 8ujZlw3CD9YXUBnZTlZEn8K2bgM56AhJjbPiNRCBshzHEj5mzodrd6m+csRJdrBot9pj 8XX+WuKkDBa0VKGi106svfvUPyr1fyud7zd/4=
Received: by 10.152.105.226 with SMTP id gp2mr1687323lab.28.1323938876355; Thu, 15 Dec 2011 00:47:56 -0800 (PST)
Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id op2sm4771068lab.6.2011.12.15.00.47.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Dec 2011 00:47:54 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Thu, 15 Dec 2011 10:47:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AAF04FB-D322-4323-8891-436CD2B34923@gmail.com>
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> 
To: sarikaya@ieee.org
X-Mailer: Apple Mail (2.1084)
Cc: "julien.ietf@gmail.com Laganier" , Jari Arkko , mext@ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Dec 2011 08:47:58 -0000

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


On Dec 14, 2011, at 7:44 PM, Behcet Sarikaya wrote:

> Hi Jouni, Julien,
>=20
> Should we say that multicast is out of scope?
>=20
> Multicast dmm  could possibly be covered in Multimob.
>=20
> Regards,
>=20
> Behcet
>=20
> On Wed, Dec 14, 2011 at 2:54 AM, jouni korhonen =
 wrote:
>> Folks,
>>=20
>> 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.
>>=20
>> - Jouni & Julien
>>=20
>>=20
>> =
-------------------------------------------------------------------------
>>=20
>> Distributed Mobility Management (DMM)
>> -------------------------------------
>>=20
>> Charter
>>=20
>>  Current Status: Active
>>=20
>>  Chairs:
>>     Julien Laganier 
>>     Jouni Korhonen 
>>=20
>>  Internet Area Directors:
>>     Ralph Droms 
>>     Jari Arkko 
>>=20
>>  Internet Area Advisor:
>>     Jari Arkko 
>>=20
>>  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
>>=20
>> Description of Working Group:
>>=20
>>  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.
>>=20
>>  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.
>>=20
>>  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.
>>=20
>> Work items related to the distributed mobility management include:
>>=20
>>  o Solution Requirements: Define precisely the problem of distributed
>>    mobility management and identity the requirements for a =
distributed
>>    mobility management solution.
>>=20
>>  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.
>>=20
>>  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.
>>=20
>> Goals and Milestones:
>>=20
>>  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.
>>=20
>>=20
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext


From luo.wen@zte.com.cn  Thu Dec 15 16:41:32 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B5921F8448; Thu, 15 Dec 2011 16:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -90.375
X-Spam-Level: 
X-Spam-Status: No, score=-90.375 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQmSTv5cj5Ow; Thu, 15 Dec 2011 16:41:31 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDAA21F8481; Thu, 15 Dec 2011 16:41:29 -0800 (PST)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566902761818882; Fri, 16 Dec 2011 08:24:31 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 59129.5383578916; Fri, 16 Dec 2011 08:41:01 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pBG0fCK6017207; Fri, 16 Dec 2011 08:41:12 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn)
In-Reply-To: <4E37A011-7BA2-4B39-8AF5-8311E362A649@gmail.com>
To: jouni korhonen 
MIME-Version: 1.0
X-KeepSent: A57D4A0F:E141F511-48257968:00038DC2; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: luo.wen@zte.com.cn
Date: Fri, 16 Dec 2011 08:41:02 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-16 08:41:12, Serialize complete at 2011-12-16 08:41:12
Content-Type: multipart/alternative; boundary="=_alternative 0003C47948257968_="
X-MAIL: mse02.zte.com.cn pBG0fCK6017207
Cc: Julien Laganier , mext-bounces@ietf.org, mext@ietf.org
Subject: [MEXT] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiBSZTogILTwuLQ6ICBUaGUg?= =?gb2312?b?Zmlyc3QgcHJvcG9zYWwgZm9yIHRoZSBETU0gY2hhcnRlcg==?=
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 00:41:32 -0000

This is a multipart message in MIME format.
--=_alternative 0003C47948257968_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgam91bmk6DQoNCiAgICAgVGhhbmsgeW91IGZvciB0aGUgcmVwbHkuIA0KDQpDaGVlcnMNCkx1
b3dlbg0KDQoNCg0KDQpqb3VuaSBrb3Job25lbiA8am91bmkubm9zcGFtQGdtYWlsLmNvbT4gDQq3
orz+yMs6ICBtZXh0LWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMTItMTUgMTY6MTcNCg0KytW8/sjL
DQpsdW8ud2VuQHp0ZS5jb20uY24NCrOty80NCkp1bGllbiBMYWdhbmllciA8anVsaWVuLmlldGZA
Z21haWwuY29tPiwgbWV4dEBpZXRmLm9yZw0K1vfM4g0KUmU6IFtNRVhUXSC08Li0OiBSZTogILTw
uLQ6ICBUaGUgZmlyc3QgcHJvcG9zYWwgZm9yIHRoZSBETU0gY2hhcnRlcg0KDQoNCg0KDQoNCg0K
DQpIaSwNCg0KQXMgSnVsaWVuIHBvaW50ZWQgb3V0LCB3ZSBoYXZlIGEgY2hlY2twb2ludCBwbGFu
bmVkIGZvciBJRVRGIzg1Lg0KQWZ0ZXIgdHdvIG1lZXRpbmcgY3ljbGVzIHdlIHNob3VsZCBiZSBj
bGVhciB3aGljaCBkb2N1bWVudHMgd2lsbA0KYmUgdGhlIGJhc2lzIChjYW4gYmUgYSBjb21iaW5h
dGlvbiBvZiBtdWx0aXBsZSwgbm90IGp1c3Qgb25lKSBmb3INCnJlcXVpcmVtZW50cyAmIGFuYWx5
c2lzLiAgVGhhdCBzaG91bGQgZ2l2ZSB1cyBlbm91Z2ggdGltZSAmDQpiYWNrZ3JvdW5kIHRvIHJl
YWxpemVkIHdoZXRoZXIgY29uY3JldGUgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhcmUNCm5lZWRlZCBh
bmQgd2hhdCB0aGV5IHJvdWdobHkgYXJlLiBOZXcgZ29hbHMgZm9yIHBvc3NpYmxlIG5ldw0Kc29s
dXRpb25zIChpLmUuIGV4dGVuc2lvbnMgdG8gc29tZSBwcm90b2NvbCwgbm90IG5lY2Vzc2FyaWx5
IGp1c3QNCm1vYmlsaXR5IHByb3RvY29scykgd2lsbCBiZSBhZGRlZCBhcyBhIHBhcnQgb2YgY2hh
cnRlciBnb2FscyB1cGRhdGUuDQoNCi0gSm91bmkNCg0KDQpPbiBEZWMgMTUsIDIwMTEsIGF0IDI6
MzUgQU0sIGx1by53ZW5AenRlLmNvbS5jbiB3cm90ZToNCg0KPiANCj4gSGkgSnVsaWVuIA0KPiAN
Cj4gVGhhbmsgeW91IGZvciBjb3JyZWN0aW5nIG1lIA0KPiANCj4gQ2hlZXJzIA0KPiBMdW93ZW4g
DQo+IA0KPiANCj4gDQo+IEp1bGllbiBMYWdhbmllciA8anVsaWVuLmlldGZAZ21haWwuY29tPiAN
Cj4gt6K8/sjLOiAgbWV4dC1ib3VuY2VzQGlldGYub3JnDQo+IDIwMTEtMTItMTUgMDE6MjgNCj4g
DQo+IMrVvP7Iyw0KPiBsdW8ud2VuQHp0ZS5jb20uY24NCj4gs63LzQ0KPiBqb3VuaSBrb3Job25l
biA8am91bmkubm9zcGFtQGdtYWlsLmNvbT4sIG1leHRAaWV0Zi5vcmcNCj4g1vfM4g0KPiBSZTog
W01FWFRdILTwuLQ6ICBUaGUgZmlyc3QgcHJvcG9zYWwgZm9yIHRoZSBETU0gY2hhcnRlcg0KPiAN
Cj4gDQo+IA0KPiANCj4gDQo+IEx1b3dlbiwNCj4gDQo+IDIwMTEvMTIvMTQgPGx1by53ZW5AenRl
LmNvbS5jbj4NCj4gPg0KPiA+DQo+ID4gSGkgIGpvdW5pOg0KPiA+DQo+ID4gSSBoYXZlIGEgcXVp
Y2sgcXVlc3Rpb24gYWJvdXQgICdHb2FscyBhbmQgTWlsZXN0b25lcycuDQo+ID4NCj4gPiBBcyBp
dCBpcyBzdGF0ZWQgJ0lmIGxpbWl0YXRpb25zIGFyZSBpZGVudGlmaWVkIGFzIHBhcnQgb2YgdGhl
IGFib3ZlIA0KZGVsaXZlcmFibGUsIHNwZWNpZnkgZXh0ZW5zaW9ucyB0byBleGlzdGluZyBwcm90
b2NvbHMgdGhhdCByZW1vdmVzIHRoZXNlIA0KbGltaXRhdGlvbnMgd2l0aGluIGEgZGlzdHJpYnV0
ZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBlbnZpcm9ubWVudC4nIHdoaWNoIA0KbWVhbnMsIEkgZ3Vl
c3MsIGEgc29sdXRpb24gd2lsbCBiZSBjcmVhdGVkIGZvciByZW1vdmUgdGhlc2UgbGltaXRhdGlv
bnMgDQphbmQgYSBSRkMgd2lsbCBiZSBuZWVkZWQuDQo+ID4NCj4gPiBTbyB3aHkgdGhlICAnR29h
bHMgYW5kIE1pbGVzdG9uZXMnIG1pc3NlcyB0aGlzIHBhcnQ/IE9yIGRvZXMgaXQgbWVhbiANCnRo
ZSBzb2x1dGlvbiBmb3IgcmVtb3ZlIHRoZXNlIGxpbWl0YWlvbnMgaXMgYWxzbyBpbmNsdWRlZCBp
biB0aGUgSS1EICdCZXN0IA0KcHJhY3RpY2VzIGFuZCBHYXAgQW5hbHlzaXMnID8NCj4gDQo+IEl0
J3Mgbm90IG1pc3NpbmcsIGl0IGlzIGNvdmVyZWQgYXMgcGFydCBvZiB0aGlzIG1pbGVzdG9uZToN
Cj4gDQo+IE5vdiAyMDEyIC0gRXZhbHVhdGUgdGhlIG5lZWQgZm9yIGFkZGl0aW9uYWwgd29ya2lu
ZyBncm91cCBkb2N1bWVudChzKQ0KPiAgICAgICAgICAgIGZvciBleHRlbnNpb25zIHRvIGZpbGwg
dGhlIGlkZW50aWZpZWQgZ2Fwcy4NCj4gDQo+IC0tanVsaWVuDQo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1FWFQgbWFpbGluZyBsaXN0DQo+IE1F
WFRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0
DQo+IA0KPiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCk1FWFQgbWFpbGluZyBsaXN0DQpNRVhUQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL21leHQNCg0KDQo=
--=_alternative 0003C47948257968_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGpvdW5pOjwvZm9udD4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz
cDtUaGFuayB5b3UgZm9yIHRoZQ0KcmVwbHkuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0ic2Fucy1zZXJpZiI+Q2hlZXJzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl
PSJzYW5zLXNlcmlmIj5MdW93ZW48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi
bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXpl
PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+am91bmkga29yaG9uZW4gJmx0O2pvdW5pLm5vc3BhbUBn
bWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl
cmlmIj63orz+yMs6ICZuYnNwO21leHQtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250
IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTEyLTE1IDE2OjE3PC9mb250Pg0KPHRkIHdp
ZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2
IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+
PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmx1by53ZW5AenRlLmNv
bS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz
aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+SnVsaWVuIExhZ2FuaWVyICZsdDtqdWxpZW4uaWV0ZkBn
bWFpbC5jb20mZ3Q7LA0KbWV4dEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk
Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv
Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtNRVhU
XSC08Li0OiBSZTogJm5ic3A7tPC4tDoNCiZuYnNwO1RoZSBmaXJzdCBwcm9wb3NhbCBmb3IgdGhl
IERNTSBjaGFydGVyPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv
cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj48YnI+DQpIaSw8YnI+DQo8YnI+DQpBcyBKdWxpZW4gcG9pbnRlZCBvdXQs
IHdlIGhhdmUgYSBjaGVja3BvaW50IHBsYW5uZWQgZm9yIElFVEYjODUuPGJyPg0KQWZ0ZXIgdHdv
IG1lZXRpbmcgY3ljbGVzIHdlIHNob3VsZCBiZSBjbGVhciB3aGljaCBkb2N1bWVudHMgd2lsbDxi
cj4NCmJlIHRoZSBiYXNpcyAoY2FuIGJlIGEgY29tYmluYXRpb24gb2YgbXVsdGlwbGUsIG5vdCBq
dXN0IG9uZSkgZm9yPGJyPg0KcmVxdWlyZW1lbnRzICZhbXA7IGFuYWx5c2lzLiAmbmJzcDtUaGF0
IHNob3VsZCBnaXZlIHVzIGVub3VnaCB0aW1lICZhbXA7PGJyPg0KYmFja2dyb3VuZCB0byByZWFs
aXplZCB3aGV0aGVyIGNvbmNyZXRlIHByb3RvY29sIGV4dGVuc2lvbnMgYXJlPGJyPg0KbmVlZGVk
IGFuZCB3aGF0IHRoZXkgcm91Z2hseSBhcmUuIE5ldyBnb2FscyBmb3IgcG9zc2libGUgbmV3PGJy
Pg0Kc29sdXRpb25zIChpLmUuIGV4dGVuc2lvbnMgdG8gc29tZSBwcm90b2NvbCwgbm90IG5lY2Vz
c2FyaWx5IGp1c3Q8YnI+DQptb2JpbGl0eSBwcm90b2NvbHMpIHdpbGwgYmUgYWRkZWQgYXMgYSBw
YXJ0IG9mIGNoYXJ0ZXIgZ29hbHMgdXBkYXRlLjxicj4NCjxicj4NCi0gSm91bmk8YnI+DQo8YnI+
DQo8YnI+DQpPbiBEZWMgMTUsIDIwMTEsIGF0IDI6MzUgQU0sIGx1by53ZW5AenRlLmNvbS5jbiB3
cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgSnVsaWVuIDxicj4NCiZndDsgPGJy
Pg0KJmd0OyBUaGFuayB5b3UgZm9yIGNvcnJlY3RpbmcgbWUgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IENoZWVycyA8YnI+DQomZ3Q7IEx1b3dlbiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IEp1bGllbiBMYWdhbmllciAmbHQ7anVsaWVuLmlldGZAZ21haWwuY29tJmd0
OyA8YnI+DQomZ3Q7ILeivP7IyzogJm5ic3A7bWV4dC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0
OyAyMDExLTEyLTE1IDAxOjI4PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IMrVvP7Iyzxicj4NCiZndDsg
bHVvLndlbkB6dGUuY29tLmNuPGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyBqb3VuaSBrb3Job25l
biAmbHQ7am91bmkubm9zcGFtQGdtYWlsLmNvbSZndDssIG1leHRAaWV0Zi5vcmc8YnI+DQomZ3Q7
INb3zOI8YnI+DQomZ3Q7IFJlOiBbTUVYVF0gtPC4tDogJm5ic3A7VGhlIGZpcnN0IHByb3Bvc2Fs
IGZvciB0aGUgRE1NIGNoYXJ0ZXI8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBMdW93ZW4sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDIwMTEvMTIvMTQgJmx0O2x1by53ZW5AenRlLmNvbS5jbiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSGkgJm5ic3A7am91bmk6PGJyPg0KJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7IEkgaGF2ZSBhIHF1aWNrIHF1ZXN0aW9uIGFib3V0ICZuYnNwOydHb2Fs
cyBhbmQgTWlsZXN0b25lcycuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFzIGl0IGlz
IHN0YXRlZCAnSWYgbGltaXRhdGlvbnMgYXJlIGlkZW50aWZpZWQgYXMgcGFydCBvZiB0aGUNCmFi
b3ZlIGRlbGl2ZXJhYmxlLCBzcGVjaWZ5IGV4dGVuc2lvbnMgdG8gZXhpc3RpbmcgcHJvdG9jb2xz
IHRoYXQgcmVtb3Zlcw0KdGhlc2UgbGltaXRhdGlvbnMgd2l0aGluIGEgZGlzdHJpYnV0ZWQgbW9i
aWxpdHkgbWFuYWdlbWVudCBlbnZpcm9ubWVudC4nDQp3aGljaCBtZWFucywgSSBndWVzcywgYSBz
b2x1dGlvbiB3aWxsIGJlIGNyZWF0ZWQgZm9yIHJlbW92ZSB0aGVzZSBsaW1pdGF0aW9ucw0KYW5k
IGEgUkZDIHdpbGwgYmUgbmVlZGVkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTbyB3
aHkgdGhlICZuYnNwOydHb2FscyBhbmQgTWlsZXN0b25lcycgbWlzc2VzIHRoaXMgcGFydD8gT3IN
CmRvZXMgaXQgbWVhbiB0aGUgc29sdXRpb24gZm9yIHJlbW92ZSB0aGVzZSBsaW1pdGFpb25zIGlz
IGFsc28gaW5jbHVkZWQNCmluIHRoZSBJLUQgJ0Jlc3QgcHJhY3RpY2VzIGFuZCBHYXAgQW5hbHlz
aXMnID88YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQncyBub3QgbWlzc2luZywgaXQgaXMgY292ZXJl
ZCBhcyBwYXJ0IG9mIHRoaXMgbWlsZXN0b25lOjxicj4NCiZndDsgPGJyPg0KJmd0OyBOb3YgMjAx
MiAtIEV2YWx1YXRlIHRoZSBuZWVkIGZvciBhZGRpdGlvbmFsIHdvcmtpbmcgZ3JvdXAgZG9jdW1l
bnQocyk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
Zm9yIGV4dGVuc2lvbnMgdG8gZmlsbCB0aGUNCmlkZW50aWZpZWQgZ2Fwcy48YnI+DQomZ3Q7IDxi
cj4NCiZndDsgLS1qdWxpZW48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBNRVhUIG1haWxpbmcgbGlzdDxicj4NCiZndDsg
TUVYVEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tZXh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjxicj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTUVYVCBtYWlsaW5nIGxpc3Q8
YnI+DQpNRVhUQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tZXh0PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo=
--=_alternative 0003C47948257968_=--


From jouni.nospam@gmail.com  Sun Dec 18 14:20:46 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46E421F85B8 for ; Sun, 18 Dec 2011 14:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd18DOtFqmjt for ; Sun, 18 Dec 2011 14:20:45 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 649D321F88A0 for ; Sun, 18 Dec 2011 14:20:45 -0800 (PST)
Received: by laah2 with SMTP id h2so2215229laa.31 for ; Sun, 18 Dec 2011 14:20:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VWWyocRb5mFwCbel9ccAn511A8y6399RhPHd0aZrmGo=; b=TxXH9/WltmPadowVwJX8B8+iz4gTqvjUsXcITXiSL5yNaIhj0SYvcUTlNCy0DLWCrH fQQ9haMirG677A2AuUAweJvRMEaRrmr/FDxmix6pNXxAaNjVQfjurvj5fzXOK15aLc2B gt/jGbTN9oRHHSnBeM9HHxDfbLN67l8H/sCTs=
Received: by 10.152.113.131 with SMTP id iy3mr14164945lab.39.1324246843398; Sun, 18 Dec 2011 14:20:43 -0800 (PST)
Received: from a83-245-212-5.elisa-laajakaista.fi (a83-245-212-5.elisa-laajakaista.fi. [83.245.212.5]) by mx.google.com with ESMTPS id jb5sm15112924lab.15.2011.12.18.14.20.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Dec 2011 14:20:42 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
Date: Mon, 19 Dec 2011 00:20:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <80F8FA76-88EF-4986-AE9C-DBCFCA027DB9@gmail.com>
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
To: mext@ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: "julien.ietf@gmail.com Laganier" , jouni korhonen , Jari Arkko 
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Dec 2011 22:20:46 -0000

Folks,

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

- Jouni


On Dec 14, 2011, at 10:54 AM, jouni korhonen wrote:

> Folks,
>=20
> 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.
>=20
> - Jouni & Julien
>=20
>=20
> =
-------------------------------------------------------------------------
>=20
> Distributed Mobility Management (DMM)
> -------------------------------------
>=20
> Charter
>=20
> Current Status: Active
>=20
> Chairs:
>     Julien Laganier 
>     Jouni Korhonen 
>=20
> Internet Area Directors:
>     Ralph Droms 
>     Jari Arkko 
>=20
> Internet Area Advisor:
>     Jari Arkko 
>=20
> 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
>=20
> Description of Working Group:
>=20
>  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.  =20
>=20
>  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.
>=20
>  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.
>=20
> Work items related to the distributed mobility management include:
>=20
>  o Solution Requirements: Define precisely the problem of distributed
>    mobility management and identity the requirements for a distributed
>    mobility management solution.
>=20
>  o Best practices and Gap Analysis: Document best practices for the
>    deployment of existing mobility protocols in a distributed mobility=20=

>    management environment and identify the limitations of each such
>    approach with respect to fulfillment of the solution requirements.
>=20
>  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.
>=20
> Goals and Milestones:
>=20
>  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.=20
>  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.
>=20
>=20


From Dirk.von-Hugo@telekom.de  Mon Dec 19 05:32:57 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA2811E8080 for ; Mon, 19 Dec 2011 05:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byWJBNthjC3d for ; Mon, 19 Dec 2011 05:32:55 -0800 (PST)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 89A2E11E8073 for ; Mon, 19 Dec 2011 05:32:47 -0800 (PST)
Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 19 Dec 2011 14:32:44 +0100
Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.112]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 19 Dec 2011 14:32:44 +0100
From: 
To: , 
Date: Mon, 19 Dec 2011 14:28:51 +0100
Thread-Topic: [MEXT] The first proposal for the DMM charter
Thread-Index: Acy901Ti26SbOvHBRYq9ieqmFqxjHgAe5/1g
Message-ID: <05C81A773E48DD49B181B04BA21A342A26809A837B@HE113484.emea1.cds.t-internal.com>
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <80F8FA76-88EF-4986-AE9C-DBCFCA027DB9@gmail.com>
In-Reply-To: <80F8FA76-88EF-4986-AE9C-DBCFCA027DB9@gmail.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: julien.ietf@gmail.com, jari.arkko@piuha.net
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 13:32:57 -0000

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 a=
s Host mobility with HIP (Host Identity Protocol) as described in (http://t=
ools.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 o=
f (soon to be) standard (lightweight) LISP (Locator/ID Separation Protocol)=
 functions and services to provide scalable mobility for LISP MNs is envisa=
ged?

Thanks and best regards
Dirk


-----Urspr=FCngliche Nachricht-----
Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von jo=
uni korhonen
Gesendet: Sonntag, 18. Dezember 2011 23:21
An: mext@ietf.org
Cc: julien.ietf@gmail.com Laganier; jouni korhonen; Jari Arkko
Betreff: Re: [MEXT] The first proposal for the DMM charter


Folks,

Based of the "feedback" can I assume folks are mostly happy with the curren=
t text?

- Jouni


On Dec 14, 2011, at 10:54 AM, jouni korhonen wrote:

> 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 thi=
s is the first draft and now we are soliciting for input.
>
> - Jouni & Julien
>
>
> -------------------------------------------------------------------------
>
> Distributed Mobility Management (DMM)
> -------------------------------------
>
> Charter
>
> Current Status: Active
>
> Chairs:
>     Julien Laganier 
>     Jouni Korhonen 
>
> Internet Area Directors:
>     Ralph Droms 
>     Jari Arkko 
>
> Internet Area Advisor:
>     Jari Arkko 
>
> 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:
>
>  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.
>
>

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

From bruno.mongazon-cazavet@alcatel-lucent.com  Sun Dec 18 23:30:26 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF6521F8ADE for ; Sun, 18 Dec 2011 23:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5eG+tKDpkhM for ; Sun, 18 Dec 2011 23:30:25 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2672321F8AD2 for ; Sun, 18 Dec 2011 23:30:24 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pBJ7UK9O024873 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Dec 2011 08:30:22 +0100
Received: from [172.27.205.116] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Dec 2011 08:30:20 +0100
Message-ID: <4EEEE80D.4000904@alcatel-lucent.com>
Date: Mon, 19 Dec 2011 08:30:21 +0100
From: Bruno Mongazon-Cazavet 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: 
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <80F8FA76-88EF-4986-AE9C-DBCFCA027DB9@gmail.com>
In-Reply-To: <80F8FA76-88EF-4986-AE9C-DBCFCA027DB9@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
X-Mailman-Approved-At: Mon, 19 Dec 2011 06:29:21 -0800
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 07:30:26 -0000

Le 18/12/2011 23:20, jouni korhonen a écrit :
> Folks,
>
> 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
>
>
> On Dec 14, 2011, at 10:54 AM, jouni korhonen wrote:
>
>> 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
>>      Jouni Korhonen
>>
>> Internet Area Directors:
>>      Ralph Droms
>>      Jari Arkko
>>
>> Internet Area Advisor:
>>      Jari Arkko
>>
>> 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:
>>
>>   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.
>>
>>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>


From pseite35@gmail.com  Mon Dec 19 03:09:14 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDF521F8B56 for ; Mon, 19 Dec 2011 03:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7XRPfy5T+XJ for ; Mon, 19 Dec 2011 03:09:12 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71421F8B53 for ; Mon, 19 Dec 2011 03:09:12 -0800 (PST)
Received: by eekc14 with SMTP id c14so3941468eek.31 for ; Mon, 19 Dec 2011 03:09:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=eI7lKI8EOwERleCl7ttMDGH5yGypXLaN2IO936G7rP4=; b=hp4AsOHX5p+dPBtRtA1AZIiPzCMgYQqsbnxNg8M6lo28DOXjLn/dGUCqjsX4Js+qRS TCEww+eoQ5QtjPSEkxMD8xEM5qEryTjICFZbzbfLw6vW22BfnlShFGyYbMWLzJQsEjaM HPArdKujH7K8i9SfYAuCSP/ZtbLdZWTxfBlfs=
MIME-Version: 1.0
Received: by 10.213.26.217 with SMTP id f25mr4726575ebc.123.1324292951281; Mon, 19 Dec 2011 03:09:11 -0800 (PST)
Received: by 10.213.22.71 with HTTP; Mon, 19 Dec 2011 03:09:11 -0800 (PST)
Date: Mon, 19 Dec 2011 12:09:11 +0100
Message-ID: 
From: Pierrick Seite 
To: jouni.nospam@gmail.com, mext@ietf.org
Content-Type: multipart/alternative; boundary=0015174c1aaaf08f4d04b46ffa6a
X-Mailman-Approved-At: Mon, 19 Dec 2011 06:29:21 -0800
Cc: julien.ietf@gmail.com, jari.arkko@piuha.net
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 12:55:22 -0000

--0015174c1aaaf08f4d04b46ffa6a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Jouni,



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



Pierrick Seite



> -----Message d'origine-----

> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part

> de jouni korhonen Envoy=E9 : dimanche 18 d=E9cembre 2011 23:21 =C0 :

> mext@ietf.org Cc : julien.ietf@gmail.com 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 : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part

> de jouni korhonen Envoy=E9 : mercredi 14 d=E9cembre 2011 09:54 =C0 :

> mext@ietf.org Cc : julien.ietf@gmail.com 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 

>      Jouni Korhonen 

>

>  Internet Area Directors:

>      Ralph Droms 

>      Jari Arkko 

>

>  Internet Area Advisor:

>      Jari Arkko 

>

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

>

>   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

> MEXT@ietf.org

> https://www.ietf.org/mailman/listinfo/mext

--0015174c1aaaf08f4d04b46ffa6a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




Hi Jouni,



=A0



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



=A0



Pierrick Seite



=A0



> -----Message d'origine-----



> De=A0: mext-bounces@ietf.org
[mailto:mext-bounces@ietf.org]=
 De la part 



> de jouni korhonen Envoy=E9=A0: dimanche 18 d=
=E9cembre
2011 23:21 =C0=A0: 



> mext@ietf.o=
rg Cc=A0: julien.ietf@gmail.co=
m
Laganier; jouni korhonen; 



> Jari Arkko Objet=A0: Re: [MEXT] The first
proposal for the DMM charter



> 



> 



> Folks,



> 



> Based of the "feedback" can I assu=
me folks
are mostly happy with the 



> current text?



> 



> - Jouni



> 



=A0



=A0



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



=A0



Hi Jouni & Julien,



=A0



This charter looks good. However, please see inli=
ne few
suggestions for modifications.



=A0



Thanks,



Pierrick



=A0



> -----Message d'origine-----



> De : mext-bounces@ietf.org
[mailto:mext-bounces@ietf.org]=
 De la part 



> de jouni korhonen Envoy=E9 : mercredi 14 d=
=E9cembre 2011
09:54 =C0 :



> mext@ietf.o=
rg Cc : julien.ietf@gmail.com<=
/a> 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 durin=
g the
Taipei meeting. Note 



> that this is the first draft and now we are
soliciting for input.



> 



> - Jouni & Julien



> 



> 



> --------------------------------------------=
--------------------------



> -



> --



> 



> Distributed Mobility Management (DMM)



> -------------------------------------



> 



> Charter



> 



>=A0 Current
Status: Active



> 



>=A0 Chairs:



>=A0=A0=A0=A0=A0 Julien
Laganier <julien.ietf@gmail.com=
>



>=A0=A0=A0=A0=A0 Jouni
Korhonen <jouni.nospam@gmail.c=
om>



> 



>=A0 Internet Area
Directors:



>=A0=A0=A0=A0=A0 Ralph
Droms <rdroms.ietf@gmail.com>



>=A0=A0=A0=A0=A0 Jari
Arkko <jari.arkko@piuha.net&=
gt;



> 



>=A0 Internet Area
Advisor:



>=A0=A0=A0=A0=A0 Jari
Arkko <jari.arkko@piuha.net&=
gt;



> 



>=A0 Mailing
Lists:



>=A0 =A0=A0=A0=
=A0General Discussion: mext@ietf.or=
g



>=A0=A0=A0=A0=A0 To
Subscribe:=A0=A0=A0=A0=A0=A0 https://www.ietf.org/mailman/listinfo/mext<=
/p>


>=A0=A0=A0=A0=A0
Archive:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/mail-arc=
hive/web/mext



> 



> Description of Working Group:



> 



>=A0=A0 The
Distributed Mobility Management (DMM) working group specifies IP



>=A0=A0 mobility,
access network and routing solutions, which allow for



>=A0=A0 setting up
IP networks so that traffic is distributed in an



>=A0=A0 optimal way
and does not rely on centrally deployed anchors to manage



>=A0=A0 IP mobility
sessions. The distributed mobility management solutions



>=A0=A0 aim for
transparency above the IP layer, including maintenance of



>=A0=A0 active
transport level sessions as mobile hosts or entire mobile



>=A0=A0 networks
change their point of attachment to the Internet.



> 



>=A0=A0 The protocol
solutions should be enhancements to existing IP mobility



>=A0=A0 protocols,
either host- or network-based, such as Mobile IPv6



>=A0=A0 [RFC6275,
5555], Proxy Mobile IPv6 [RFC5213, 5844] and



>=A0=A0 NEMO
[RFC3963]. 



=A0



This sentence gives the impression that extension=
s 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 incons=
istent
with the two steps approach suggested by the work items: best current pract=
ices
(without protocol modification), then, if necessary, specify extensions. So=
,
I'd suggest to reword as follows:



=A0



The protocol solutions should be based on existin=
g IP
mobility



=A0 Protocols and
related mechanisms, either host- or network-based, such as Mobile IPv6



=A0=A0 [RFC6275, 5555],
Proxy Mobile IPv6 [RFC5213, 5844] and



=A0 NEMO [RFC3963]. 



=A0



Alternatively, the distributed mobility managemen=
t



>=A0=A0 solution can
be transparent to any underlying IP mobility protocol.



>=A0=A0 Although the
maintenance of stable home address(es) and/or prefix(es)



>=A0=A0 and upper
level sessions is a desirable goal when mobile 



> hosts/routers



>=A0=A0 change their
point of attachment to the Internet, it is not a strict



>=A0=A0 requirement.
Mobile hosts/routers should not assume that IP



>=A0=A0 addressing
including home address(es) and/or home network prefix(es)



>=A0=A0 remain the
same throughout the entire upper level session lifetime.



> 



=A0



I suggest to add the following statement:



=A0



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



=A0



>=A0=A0 The
distributed mobility management solutions primarily target IPv6



>=A0=A0 Deployment
and should not be tailored specifically to support IPv4,



>=A0=A0 in
particular in situations where private IPv4 addresses and/or NATs



>=A0=A0 are used. At
least IPv6 is assumed to be present in both the mobile



>=A0=A0 host/router
and the access networks. Independent of the distributed



>=A0=A0 mobility
management solution, backward compatibility must be



>=A0=A0 maintained.
If the network or the mobile host/router do not support



>=A0=A0 the
distributed mobility management enabling protocol, nothing should



>=A0=A0 break.



> 



> Work items related to the distributed mobili=
ty
management include:



> 



>=A0=A0 o Solution
Requirements: Define precisely the problem of distributed



>=A0=A0=A0=A0 mobility
management and identity the requirements for a distributed



>=A0=A0=A0=A0 mobility
management solution.



> 



>=A0=A0 o Best
practices and Gap Analysis: Document best practices for the



>=A0=A0=A0=A0 deployment
of existing mobility protocols in a distributed mobility



>=A0=A0=A0=A0 management
environment and identify the limitations of each such



>=A0=A0=A0=A0 approach
with respect to fulfillment of the solution requirements.



> 



>=A0=A0 o If
limitations are identified as part of the above deliverable,



>=A0=A0=A0=A0 specify
extensions to existing protocols that removes these



>=A0=A0=A0=A0
limitations within a distributed mobility management environment.


> 



=A0



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



=A0



=A0=A0 o Best practices:
Document best practices for the



=A0=A0=A0=A0 deployment of
existing mobility protocols in a distributed mobility



=A0=A0=A0=A0 management
environment.



=A0



=A0



=A0o=A0 Gap=
 Analysis and extensions: identify the
limitations of each such



=A0=A0=A0 approach with
respect to fulfillment of the solution requirements. If limitations are,


=A0=A0=A0 specify
extensions to existing protocols that removes these



=A0=A0=A0 limitations
within a distributed mobility management environment.



=A0



=A0



> Goals and Milestones:



> 



>=A0=A0 Aug 2012 -
Submit I-D 'Solution Requirements' as a working



>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0
group document. To be Informational RFC.



>=A0=A0 Aug 2012 -
Submit I-D 'Best practices and Gap Analysis' as a working



>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0
group document. To be Informational RFC.



=A0



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



=A0



=A0=A0 Aug 2012 -
Submit I-D 'Best practices' as a working



=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 group
document. To be Informational RFC.



=A0



>=A0=A0 Nov 2012 -
Evaluate the need for additional working group document(s)



>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0
for extensions to fill the identified gaps.



=A0



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



=A0



Nov 2012 - Gap analysis and evaluation for the ne=
ed of
additional working group document(s)



=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for
extensions to fill the identified gaps.



=A0



>=A0=A0 Jan 2013 -
Submit I-D 'Solution Requirements' to the IESG for



>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0
consideration as an Informational RFC.



>=A0=A0 Jan 2013 -
Submit I-D 'Best practices and Gap Analysis' to the IESG 



> for



>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0
consideration as an Informational RFC.



>=A0=A0 Mar 2013 -
Conclude the working group or re-charter.



> 



> 



> ____________________________________________=
___



> MEXT mailing list



> MEXT@ietf.o=
rg



> https://www.ietf.org/mailman/listinfo/mext



--0015174c1aaaf08f4d04b46ffa6a--

From jari.arkko@piuha.net  Tue Dec 20 00:29:58 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D15C21F89BA for ; Tue, 20 Dec 2011 00:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNBZDzoGF5Sz for ; Tue, 20 Dec 2011 00:29:57 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8C21F89B8 for ; Tue, 20 Dec 2011 00:29:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 592812CC4D; Tue, 20 Dec 2011 10:29:55 +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 sT03rpQE+06d; Tue, 20 Dec 2011 10:29:53 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 99D6A2CC31; Tue, 20 Dec 2011 10:29:53 +0200 (EET)
Message-ID: <4EF04781.3080700@piuha.net>
Date: Tue, 20 Dec 2011 10:29:53 +0200
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: jouni korhonen 
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
In-Reply-To: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "julien.ietf@gmail.com Laganier" , mext@ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 08:29:58 -0000

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.

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

Charter

  Current Status: Active

  Chairs:
      Julien Laganier 
      Jouni Korhonen 

  Internet Area Directors:
      Ralph Droms 
      Jari Arkko 

  Internet Area Advisor:
      Jari Arkko 

  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:

   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]. 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 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.nospam@gmail.com  Tue Dec 20 00:52:24 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0324121F84A2 for ; Tue, 20 Dec 2011 00:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmsXq0IZ6tCO for ; Tue, 20 Dec 2011 00:52:23 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6ED21F84A1 for ; Tue, 20 Dec 2011 00:52:22 -0800 (PST)
Received: by laah2 with SMTP id h2so2736984laa.31 for ; Tue, 20 Dec 2011 00:52:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8b+RIdemcJ7HxDCKLHG3FfAGch59sA9ezBpMhV6a5nE=; b=szHbl9dg7025ETR+5wRG27dD8uY2P+G/zP7/cZBf7cODBaZdxgcIjG2tl5nw0rFvzF 4XLU4vXmZoedl7d/zS6Npu1qwf5CUIioagVneliSLe8i1UbJpJTUzkwysAUU5ruIaVqb LodSXREHYK1m6FaRAbdeZcq1nhuD+4bZTmonI=
Received: by 10.152.135.195 with SMTP id pu3mr843149lab.17.1324371140071; Tue, 20 Dec 2011 00:52:20 -0800 (PST)
Received: from a83-245-212-5.elisa-laajakaista.fi (a83-245-212-5.elisa-laajakaista.fi. [83.245.212.5]) by mx.google.com with ESMTPS id pf2sm913934lab.1.2011.12.20.00.52.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Dec 2011 00:52:18 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <4EF04781.3080700@piuha.net>
Date: Tue, 20 Dec 2011 10:52:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <563F11DB-2F08-40AC-A788-70CBE9EFE745@gmail.com>
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <4EF04781.3080700@piuha.net>
To: Jari Arkko 
X-Mailer: Apple Mail (2.1084)
Cc: "julien.ietf@gmail.com Laganier" , mext@ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 08:52:24 -0000

Jari,


On Dec 20, 2011, at 10:29 AM, Jari Arkko wrote:

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

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


>=20
> Suggested edits below. I have sent this version to the IESG and IAB, =
but I expect that the chairs may produce additional refined versions.
>=20
> Distributed Mobility Management (DMM)
> -------------------------------------
>=20
> Charter
>=20
> Current Status: Active
>=20
> Chairs:
>     Julien Laganier 
>     Jouni Korhonen 
>=20
> Internet Area Directors:
>     Ralph Droms 
>     Jari Arkko 
>=20
> Internet Area Advisor:
>     Jari Arkko 
>=20
> 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
>=20
> Description of Working Group:
>=20
>  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.
>=20
>  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.
>=20
>  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.
>=20
>  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.
>=20
> Work items related to the distributed mobility management include:
>=20
>  o Solution Requirements: Define precisely the problem of distributed
>    mobility management and identity the requirements for a distributed
>    mobility management solution.
>=20
>  o Best practices: Document best practices for the
>     deployment of existing mobility protocols in a distributed =
mobility
>     management environment.
>=20
> o  Gap Analysis and extensions: identify the limitations in the best =
current
>     practices with respect to providing the expected functionality.
>=20
>  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.
>=20
> Goals and Milestones:
>=20
>  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
>=20


From pierrick.seite@orange.com  Tue Dec 20 01:51:06 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E67C21F8AAF for ; Tue, 20 Dec 2011 01:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF+ZzXr55bJ2 for ; Tue, 20 Dec 2011 01:51:05 -0800 (PST)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id CB67121F8B1B for ; Tue, 20 Dec 2011 01:51:04 -0800 (PST)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1D332A445CB; Tue, 20 Dec 2011 10:50:42 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 7FB68DE4AC1; Mon, 19 Dec 2011 11:59:12 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 19 Dec 2011 11:57:46 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Dec 2011 11:57:44 +0100
Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202169B1B@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <80F8FA76-88EF-4986-AE9C-DBCFCA027DB9@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] The first proposal for the DMM charter
Thread-Index: Acy90024+f9JEbUiTneED4RGoCt71QAaInuQ
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <80F8FA76-88EF-4986-AE9C-DBCFCA027DB9@gmail.com>
From: 
To: , 
X-OriginalArrivalTime: 19 Dec 2011 10:57:46.0631 (UTC) FILETIME=[0A8EB970:01CCBE3D]
Cc: julien.ietf@gmail.com, jari.arkko@piuha.net
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 09:51:06 -0000

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=A0: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part =
de
> jouni korhonen
> Envoy=E9=A0: dimanche 18 d=E9cembre 2011 23:21
> =C0=A0: mext@ietf.org
> Cc=A0: julien.ietf@gmail.com Laganier; jouni korhonen; Jari Arkko
> Objet=A0: Re: [MEXT] The first proposal for the DMM charter
>=20
>=20
> Folks,
>=20
> Based of the "feedback" can I assume folks are mostly happy with the
> current text?
>=20
> - Jouni
>=20


----------------------------------------=20

Hi Jouni & Julien,

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

Thanks,
Pierrick

> -----Message d'origine-----
> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part=20
> de jouni korhonen Envoy=E9 : mercredi 14 d=E9cembre 2011 09:54 =C0 :=20
> mext@ietf.org Cc : julien.ietf@gmail.com Laganier; jouni korhonen;=20
> Jari Arkko Objet : [MEXT] The first proposal for the DMM charter
>=20
> Folks,
>=20
> We have been working on a charter text from DMM based on the initial=20
> 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.
>=20
> - Jouni & Julien
>=20
>=20
> ----------------------------------------------------------------------
> -
> --
>=20
> Distributed Mobility Management (DMM)
> -------------------------------------
>=20
> Charter
>=20
>  Current Status: Active
>=20
>  Chairs:
>      Julien Laganier 
>      Jouni Korhonen 
>=20
>  Internet Area Directors:
>      Ralph Droms 
>      Jari Arkko 
>=20
>  Internet Area Advisor:
>      Jari Arkko 
>=20
>  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
>=20
> Description of Working Group:
>=20
>   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.
>=20
>   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].=20

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].=20

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

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.
>=20
> Work items related to the distributed mobility management include:
>=20
>   o Solution Requirements: Define precisely the problem of distributed
>     mobility management and identity the requirements for a =
distributed
>     mobility management solution.
>=20
>   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.
>=20
>   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.
>=20

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:=20

   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:
>=20
>   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=20
> for
>              consideration as an Informational RFC.
>   Mar 2013 - Conclude the working group or re-charter.
>=20
>=20
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext

From conny.larsson@ericsson.com  Tue Dec 20 10:54:19 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2F51F0C3B for ; Tue, 20 Dec 2011 10:54:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUFeSFl01UCs for ; Tue, 20 Dec 2011 10:54:19 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CE6B41F0C35 for ; Tue, 20 Dec 2011 10:54:18 -0800 (PST)
X-AuditID: c1b4fb3d-b7cfeae000005b81-7b-4ef0d9d739a1
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A2.7E.23425.7D9D0FE4; Tue, 20 Dec 2011 19:54:15 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Dec 2011 19:54:15 +0100
Message-ID: <4EF0D9D5.2070609@ericsson.com>
Date: Tue, 20 Dec 2011 19:54:13 +0100
From: Conny Larsson 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: jouni korhonen , "julien.ietf@gmail.com Laganier" 
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
In-Reply-To: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: Jari Arkko , "mext@ietf.org" 
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 18:54:20 -0000

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


On 2011-12-14 09:54, jouni korhonen wrote:
> 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
>       Jouni Korhonen
>
>   Internet Area Directors:
>       Ralph Droms
>       Jari Arkko
>
>   Internet Area Advisor:
>       Jari Arkko
>
>   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:
>
>    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.
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>



From maxpassion@gmail.com  Wed Dec 21 09:53:05 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E7F11E8089 for ; Wed, 21 Dec 2011 09:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQZXeiGo+0ex for ; Wed, 21 Dec 2011 09:53:04 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 666DB11E8073 for ; Wed, 21 Dec 2011 09:53:04 -0800 (PST)
Received: by ggnk5 with SMTP id k5so6462780ggn.31 for ; Wed, 21 Dec 2011 09:53:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lm75jsIu9zTlW0oNd4MOhEyd4MvVmbJp5MzmbvApHOc=; b=dZjWs4RFvgVQxsHbRmcq8WRwExCAJh1Vdn4wb2+RPANEv47r1aK7z+0glbZZKMlS1P /mTQKjwMUkd9+W4WBkMn6/LOcyIKUSoz2lZeIsDSTwi7YcrvsMPg7rmCG2eDFebunIYc eY3G5pIlGjo+OX0FoZb+qjQZ/II4UtSKDQpzM=
MIME-Version: 1.0
Received: by 10.50.187.226 with SMTP id fv2mr4718009igc.20.1324489981691; Wed, 21 Dec 2011 09:53:01 -0800 (PST)
Received: by 10.43.50.1 with HTTP; Wed, 21 Dec 2011 09:53:01 -0800 (PST)
In-Reply-To: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
Date: Thu, 22 Dec 2011 01:53:01 +0800
Message-ID: 
From: liu dapeng 
To: jouni korhonen 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "julien.ietf@gmail.com Laganier" , Jari Arkko , mext@ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Dec 2011 17:53:05 -0000

2011/12/14, jouni korhonen :
> 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 th=
is
> is the first draft and now we are soliciting for input.
>
> - Jouni & Julien
>
>
> -------------------------------------------------------------------------
>
> Distributed Mobility Management (DMM)
> -------------------------------------
>
> Charter
>
>  Current Status: Active
>
>  Chairs:
>      Julien Laganier 
>      Jouni Korhonen 
>
>  Internet Area Directors:
>      Ralph Droms 
>      Jari Arkko 
>
>  Internet Area Advisor:
>      Jari Arkko 
>
>  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:
>
>   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 : =93it is not a
strict requirement to maintenance stable IP address=94 (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 add=
ress.



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
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>


--=20

------
Best Regards,
Dapeng Liu

From peer.azmat@yahoo.co.uk  Wed Dec 21 21:25:34 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EAC11E80F4 for ; Wed, 21 Dec 2011 21:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.302
X-Spam-Level: 
X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, MANGLED_SAVELE=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-s-HmQ8LUmu for ; Wed, 21 Dec 2011 21:25:31 -0800 (PST)
Received: from nm13-vm0.bullet.mail.ukl.yahoo.com (nm13-vm0.bullet.mail.ukl.yahoo.com [217.146.183.248]) by ietfa.amsl.com (Postfix) with SMTP id 355AB11E80EE for ; Wed, 21 Dec 2011 21:25:29 -0800 (PST)
Received: from [217.146.183.180] by nm13.bullet.mail.ukl.yahoo.com with NNFMP; 22 Dec 2011 05:25:26 -0000
Received: from [217.146.183.160] by tm11.bullet.mail.ukl.yahoo.com with NNFMP; 22 Dec 2011 05:25:26 -0000
Received: from [127.0.0.1] by omp1001.mail.ukl.yahoo.com with NNFMP; 22 Dec 2011 05:25:26 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 787497.23080.bm@omp1001.mail.ukl.yahoo.com
Received: (qmail 17420 invoked by uid 60001); 22 Dec 2011 05:25:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1324531526; bh=dYGPqlmdBGZLsBOuNdp4Zy8KXOQtpPYpFMuvPVja+5Q=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fL+UY5NG9CpLGnIb/nBYXm4E8cgASO9wyBD5lLbEQf8hOPuh8WxgKdQ+wlht5zG9Cd9k1qyH+2IsKoDqFxBIDhK1OanLAVk1NjBVCyFBwV8Y97ZMQx+8+TQ1Dr67WfmXiK/YWRjUoUcWzklbooL9FGU0uaz1SR/81tpWMUOXP94=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=iw1rJsAOiYlnkM4M/4VslyaHQxhYJO5s6QdPJc+ebj6yisV/JLNyUnrrvd9YvPMy9ZHfNX99B2QSaaYgnyb3Mjp+pmeL4C2ByMaf+NUDkTdTfCWUukH3828E7PbMdIKhS6xtGAiznwroK7Rok7gxrs/XoSzPNfmpTry2f95uzEg=;
X-YMail-OSG: 4TJfj9cVM1kaRAjMRzlhdMEhCzTgwQ8jbHxt31D4mYaX9U0 Xiwx.0_D0owJ.4xGfm12DHfTIYAgmReWABwVXS9nIQXGJEPCTJ47QfvmF7MM w10mfpHPgJcsDWl1R3xjWhumrTM6eu4VL65eoyPVw9CopE18PTz55udVXG6X uXkKUhVFTUVM_b5BDe7Ps2tPRjZhgTX2BW_8SGgR3pXIGjVO_5jWO5oOlBCd 6e2OIXuUuksHREJszYVwwELWgFSwXaQ48pAuVuRJdvQcbdNTu62YSwT_ik2i XfSh1f9c9PGNRyBUiZG95xgnalypte5ng1vRtRxv.oZMRE_9BB8yFes2ai58 HSPTnMXmLfLw63ZkiCUm6CN2JxtZJ8_jnnq1e1A..zo2ymTnUGdDBsr.lIbg vqS170C7imAqrykM-
Received: from [175.142.125.110] by web28212.mail.ukl.yahoo.com via HTTP; Thu, 22 Dec 2011 05:25:26 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: 
Message-ID: <1324531526.16224.YahooMailNeo@web28212.mail.ukl.yahoo.com>
Date: Thu, 22 Dec 2011 05:25:26 +0000 (GMT)
From: Peer Azmat Shah 
To: "mext@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="394961386-255435238-1324531526=:16224"
Subject: Re: [MEXT] MEXT Digest, Vol 54, Issue 12
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Peer Azmat Shah 
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Dec 2011 05:25:34 -0000

--394961386-255435238-1324531526=:16224
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

In my opinion, the term " traffic is distributed in an optimal way" seems a=
mbiguous.=A0=0AFrom this statement, one can get confused, that aim of DMM i=
s to distribute the whole data traffic along-with handling mobility in a di=
stributed manner.=0A=0AOne thing more: when we talk about DMM, then it mean=
s that we have to make changes in the network (routers, gateways, access po=
ints, base stations) so that they can handle mobility in a combined effort,=
 not relying on a single MAP. But in 2nd paragraph of charter, it is writte=
n "either host- or network-based" means that new solutions can be either ne=
twork based or host based (E2E). How, a mobility solution that works in a d=
istributed manner can be host based (E2E)? It will be a network based solut=
ion. =0A=0A=A0=0Aregards=0A=0A---------------=0A=0APeer Azmat Shah=0A=0A=0A=
1.=A0 Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONAS, Mala=
ysia | +60 14 345 60202.=A0 Lecturer | Department of CS | COMSATS Universit=
y of Science & Technology, Pakistan | +92 321 582 2507=0A=0A=0A=0A=0A______=
__________________________=0A =0A------------------------------------------=
----------------------------=0A=0AMessage: 1=0ADate: Tue, 20 Dec 2011 10:29=
:53 +0200=0AFrom: Jari Arkko =0ATo: jouni korhonen =0ACc: "julien.ietf@gmail.com Laganier" ,=0A=A0=A0=A0 mext@ietf.org=0ASubject: Re: [MEXT] The first propo=
sal for the DMM charter=0AMessage-ID: <4EF04781.3080700@piuha.net>=0AConten=
t-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed=0A=0AI 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 trans=
parent to any underlying mobility protocol part", because it confuses me. A=
nd per questions on the list, it seems to confuse other people too.=0A=0ASu=
ggested edits below. I have sent this version to the IESG and IAB, but I ex=
pect that the chairs may produce additional refined versions.=0A=0ADistribu=
ted Mobility Management (DMM)=0A-------------------------------------=0A=0A=
Charter=0A=0A=A0 Current Status: Active=0A=0A=A0 Chairs:=0A=A0 =A0 =A0 Juli=
en Laganier =0A=A0 =A0 =A0 Jouni Korhonen =0A=0A=A0 Internet Area Directors:=0A=A0 =A0 =A0 Ralph Droms =
=0A=A0 =A0 =A0 Jari Arkko =0A=
=0A=A0 Internet Area Advisor:=0A=A0 =A0 =A0 Jari Arkko =0A=0A=A0 Mailing Lists:=0A=A0 =A0 =A0 General Discussion: mext@ietf.org=
=0A=A0 =A0 =A0 To Subscribe:=A0 =A0 =A0 https://www.ietf.org/mailman/listin=
fo/mext=0A=A0 =A0 =A0 Archive:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/m=
ail-archive/web/mext=0A=0ADescription of Working Group:=0A=0A=A0  The Distr=
ibuted Mobility Management (DMM) working group specifies IP=0A=A0  mobility=
, access network and routing solutions, which allow for=0A=A0  setting up I=
P networks so that traffic is distributed in an=0A=A0  optimal way and does=
 not rely on centrally deployed anchors to manage=0A=A0  IP mobility sessio=
ns. The distributed mobility management solutions=0A=A0  aim for transparen=
cy above the IP layer, including maintenance of=0A=A0  active transport lev=
el sessions as mobile hosts or entire mobile=0A=A0  networks change their p=
oint of attachment to the Internet.=0A=0A=A0  The protocol solutions should=
 be based on existing IP mobility=0A=A0  protocols, either host- or network=
-based, such as Mobile IPv6=0A=A0  [RFC6275, 5555], Proxy Mobile IPv6 [RFC5=
213, 5844] and=0A=A0  NEMO [RFC3963]. Solutions may also focus specifically=
=0A=A0  on managing the use of care-of versus home addresses in an=0A=A0  e=
fficient manner for different types of communications.=0A=0A=A0  Although t=
he maintenance of stable home address(es) and/or prefix(es)=0A=A0  and uppe=
r level sessions is a desirable goal when mobile hosts/routers=0A=A0  chang=
e their point of attachment to the Internet, it is not a strict=0A=A0  requ=
irement. Mobile hosts/routers should not assume that IP=0A=A0  addressing i=
ncluding home address(es) and/or home network prefix(es)=0A=A0  remain the =
same throughout the entire upper level session lifetime,=0A=A0  or that sup=
port for mobility functions is provided on the network side=0A=A0  in all c=
onditions.=0A=0A=A0  The distributed mobility management solutions primaril=
y target IPv6=0A=A0  Deployment and should not be tailored specifically to =
support IPv4,=0A=A0  in particular in situations where private IPv4 address=
es and/or NATs=0A=A0  are used. At least IPv6 is assumed to be present in b=
oth the mobile=0A=A0  host/router and the access networks. Independent of t=
he distributed=0A=A0  mobility management solution, backward compatibility =
must be=0A=A0  maintained. If the network or the mobile host/router do not =
support=0A=A0  the distributed mobility management enabling protocol, nothi=
ng should=0A=A0  break.=0A=0AWork items related to the distributed mobility=
 management include:=0A=0A=A0  o Solution Requirements: Define precisely th=
e problem of distributed=0A=A0 =A0  mobility management and identity the re=
quirements for a distributed=0A=A0 =A0  mobility management solution.=0A=0A=
=A0  o Best practices: Document best practices for the=0A=A0 =A0 =A0 deploy=
ment of existing mobility protocols in a distributed mobility=0A=A0 =A0 =A0=
 management environment.=0A=0A=A0 o=A0 Gap Analysis and extensions: identif=
y the limitations in the best current=0A=A0 =A0 =A0 practices with respect =
to providing the expected functionality.=0A=0A=A0  o If limitations are ide=
ntified as part of the above deliverable,=0A=A0 =A0  specify extensions to =
existing protocols that removes these=0A=A0 =A0  limitations within a distr=
ibuted mobility management environment.=0A=0AGoals and Milestones:=0A=0A=A0=
  Aug 2012 - Submit I-D 'Solution Requirements' as a working=0A=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 group document. To be Informational RFC.=0A=A0  Aug 2012 - =
Submit I-D 'Best practices and Gap Analysis' as a working=0A=A0 =A0 =A0 =A0=
 =A0 =A0 =A0 group document. To be Informational RFC.=0A=A0  Nov 2012 - Eva=
luate the need for additional working group document(s)=0A=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 for extensions to fill the identified gaps.=0A=A0  Jan 2013 - S=
ubmit I-D 'Solution Requirements' to the IESG for=0A=A0 =A0 =A0 =A0 =A0 =A0=
 =A0 consideration as an Informational RFC.=0A=A0  Jan 2013 - Submit I-D 'B=
est practices ' to the IESG for=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 consideration=
 as an Informational RFC.=0A=A0  Mar 2013 - Submit I-D 'Gap Analysis' to th=
e IESG for=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 consideration as an Informational =
RFC.=0A=A0  Mar 2013 - Evaluate the need for further work based on the iden=
tified gaps=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 and revise the milestones and/or =
the charter of the group=0A=0A=0A=0A------------------------------=0A=0AMes=
sage: 2=0ADate: Tue, 20 Dec 2011 10:52:15 +0200=0AFrom: jouni korhonen =0ATo: Jari Arkko =0ACc: "julien.=
ietf@gmail.com Laganier" ,=0A=A0=A0=A0 mext@ietf.org=
=0ASubject: Re: [MEXT] The first proposal for the DMM charter=0AMessage-ID:=
 <563F11DB-2F08-40AC-A788-70CBE9EFE745@gmail.com>=0AContent-Type: text/plai=
n; charset=3Dus-ascii=0A=0A=0AJari,=0A=0A=0AOn Dec 20, 2011, at 10:29 AM, J=
ari Arkko wrote:=0A=0A> I think this looks very good, but I would still tak=
e into account Pierrick's suggested edits, and I think we have to be far mo=
re specific about that "can be transparent to any underlying mobility proto=
col part", because it confuses me. And per questions on the list, it seems =
to confuse other people too.=0A=0AThanks for the edit. The "transparent" pa=
rt was definitely poorly worded as it was meant for bettering the use of Co=
As.. But wording ended up far too open ended. The new text expresses the or=
iginal intent clearly.=0A=0AI also agree with Pierrick's comments that are =
now also included.=0A=0A- Jouni=0A=0A=0A> =0A> Suggested edits below. I hav=
e sent this version to the IESG and IAB, but I expect that the chairs may p=
roduce additional refined versions.=0A> =0A> Distributed Mobility Managemen=
t (DMM)=0A> -------------------------------------=0A> =0A> Charter=0A> =0A>=
 Current Status: Active=0A> =0A> Chairs:=0A>=A0 =A0  Julien Laganier =0A>=A0 =A0  Jouni Korhonen =0A> =
=0A> Internet Area Directors:=0A>=A0 =A0  Ralph Droms =0A>=A0 =A0  Jari Arkko =0A> =0A> Internet Area Adv=
isor:=0A>=A0 =A0  Jari Arkko =0A> =0A> Mailing Lists:=
=0A>=A0 =A0  General Discussion: mext@ietf.org=0A>=A0 =A0  To Subscribe:=A0=
 =A0 =A0 https://www.ietf.org/mailman/listinfo/mext=0A>=A0 =A0  Archive:=A0=
 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/mail-archive/web/mext=0A> =0A> Des=
cription of Working Group:=0A> =0A>=A0 The Distributed Mobility Management =
(DMM) working group specifies IP=0A>=A0 mobility, access network and routin=
g solutions, which allow for=0A>=A0 setting up IP networks so that traffic =
is distributed in an=0A>=A0 optimal way and does not rely on centrally depl=
oyed anchors to manage=0A>=A0 IP mobility sessions. The distributed mobilit=
y management solutions=0A>=A0 aim for transparency above the IP layer, incl=
uding maintenance of=0A>=A0 active transport level sessions as mobile hosts=
 or entire mobile=0A>=A0 networks change their point of attachment to the I=
nternet.=0A> =0A>=A0 The protocol solutions should be based on existing IP =
mobility=0A>=A0 protocols, either host- or network-based, such as Mobile IP=
v6=0A>=A0 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and=0A>=A0 NEM=
O [RFC3963]. Solutions may also focus specifically=0A>=A0 on managing the u=
se of care-of versus home addresses in an=0A>=A0 efficient manner for diffe=
rent types of communications.=0A> =0A>=A0 Although the maintenance of stabl=
e home address(es) and/or prefix(es)=0A>=A0 and upper level sessions is a d=
esirable goal when mobile hosts/routers=0A>=A0 change their point of attach=
ment to the Internet, it is not a strict=0A>=A0 requirement. Mobile hosts/r=
outers should not assume that IP=0A>=A0 addressing including home address(e=
s) and/or home network prefix(es)=0A>=A0 remain the same throughout the ent=
ire upper level session lifetime,=0A>=A0 or that support for mobility funct=
ions is provided on the network side=0A>=A0 in all conditions.=0A> =0A>=A0 =
The distributed mobility management solutions primarily target IPv6=0A>=A0 =
Deployment and should not be tailored specifically to support IPv4,=0A>=A0 =
in particular in situations where private IPv4 addresses and/or NATs=0A>=A0=
 are used. At least IPv6 is assumed to be present in both the mobile=0A>=A0=
 host/router and the access networks. Independent of the distributed=0A>=A0=
 mobility management solution, backward compatibility must be=0A>=A0 mainta=
ined. If the network or the mobile host/router do not support=0A>=A0 the di=
stributed mobility management enabling protocol, nothing should=0A>=A0 brea=
k.=0A> =0A> Work items related to the distributed mobility management inclu=
de:=0A> =0A>=A0 o Solution Requirements: Define precisely the problem of di=
stributed=0A>=A0 =A0 mobility management and identity the requirements for =
a distributed=0A>=A0 =A0 mobility management solution.=0A> =0A>=A0 o Best p=
ractices: Document best practices for the=0A>=A0 =A0  deployment of existin=
g mobility protocols in a distributed mobility=0A>=A0 =A0  management envir=
onment.=0A> =0A> o=A0 Gap Analysis and extensions: identify the limitations=
 in the best current=0A>=A0 =A0  practices with respect to providing the ex=
pected functionality.=0A> =0A>=A0 o If limitations are identified as part o=
f the above deliverable,=0A>=A0 =A0 specify extensions to existing protocol=
s that removes these=0A>=A0 =A0 limitations within a distributed mobility m=
anagement environment.=0A> =0A> Goals and Milestones:=0A> =0A>=A0 Aug 2012 =
- Submit I-D 'Solution Requirements' as a working=0A>=A0 =A0 =A0 =A0 =A0 =
=A0  group document. To be Informational RFC.=0A>=A0 Aug 2012 - Submit I-D =
'Best practices and Gap Analysis' as a working=0A>=A0 =A0 =A0 =A0 =A0 =A0  =
group document. To be Informational RFC.=0A>=A0 Nov 2012 - Evaluate the nee=
d for additional working group document(s)=0A>=A0 =A0 =A0 =A0 =A0 =A0  for =
extensions to fill the identified gaps.=0A>=A0 Jan 2013 - Submit I-D 'Solut=
ion Requirements' to the IESG for=0A>=A0 =A0 =A0 =A0 =A0 =A0  consideration=
 as an Informational RFC.=0A>=A0 Jan 2013 - Submit I-D 'Best practices ' to=
 the IESG for=0A>=A0 =A0 =A0 =A0 =A0 =A0  consideration as an Informational=
 RFC.=0A>=A0 Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for=0A>=A0 =
=A0 =A0 =A0 =A0 =A0  consideration as an Informational RFC.=0A>=A0 Mar 2013=
 - Evaluate the need for further work based on the identified gaps=0A>=A0 =
=A0 =A0 =A0 =A0 =A0  and revise the milestones and/or the charter of the gr=
oup=0A> =0A=0A=0A=0A------------------------------=0A=0AMessage: 3=0ADate: =
Mon, 19 Dec 2011 11:57:44 +0100=0AFrom: =0ATo: <=
jouni.nospam@gmail.com>,=A0=A0=A0 =0ACc: julien.ietf@gmail.c=
om, jari.arkko@piuha.net=0ASubject: Re: [MEXT] The first proposal for the D=
MM charter=0AMessage-ID:=0A=A0=A0=A0 <843DA8228A1BA74CA31FB4E111A5C46202169=
B1B@ftrdmel0.rd.francetelecom.fr>=0A=A0=A0=A0 =0AContent-Type: text/plain;=
=A0=A0=A0 charset=3D"iso-8859-1"=0A=0AHi Jouni,=0A=0AIt seems that I've som=
e trouble with my mail box.... Please see below my comments sent on Friday.=
..=0A=0APierrick=0A=0A> -----Message d'origine-----=0A> De?: mext-bounces@i=
etf.org [mailto:mext-bounces@ietf.org] De la part de=0A> jouni korhonen=0A>=
 Envoy??: dimanche 18 d?cembre 2011 23:21=0A> ??: mext@ietf.org=0A> Cc?: ju=
lien.ietf@gmail.com Laganier; jouni korhonen; Jari Arkko=0A> Objet?: Re: [M=
EXT] The first proposal for the DMM charter=0A> =0A> =0A> Folks,=0A> =0A> B=
ased of the "feedback" can I assume folks are mostly happy with the=0A> cur=
rent text?=0A> =0A> - Jouni=0A> =0A=0A=0A----------------------------------=
------ =0A=0AHi Jouni & Julien,=0A=0AThis charter looks good. However, plea=
se see inline few suggestions for modifications.=0A=0AThanks,=0APierrick=0A=
=0A> -----Message d'origine-----=0A> De : mext-bounces@ietf.org [mailto:mex=
t-bounces@ietf.org] De la part =0A> de jouni korhonen Envoy? : mercredi 14 =
d?cembre 2011 09:54 ? : =0A> mext@ietf.org Cc : julien.ietf@gmail.com Lagan=
ier; jouni korhonen; =0A> Jari Arkko Objet : [MEXT] The first proposal for =
the DMM charter=0A> =0A> Folks,=0A> =0A> We have been working on a charter =
text from DMM based on the initial =0A> goal setting and the input we recei=
ved during the Taipei meeting. Note =0A> that this is the first draft and n=
ow we are soliciting for input.=0A> =0A> - Jouni & Julien=0A> =0A> =0A> ---=
-------------------------------------------------------------------=0A> -=
=0A> --=0A> =0A> Distributed Mobility Management (DMM)=0A> ----------------=
---------------------=0A> =0A> Charter=0A> =0A>=A0 Current Status: Active=
=0A> =0A>=A0 Chairs:=0A>=A0 =A0 =A0 Julien Laganier =
=0A>=A0 =A0 =A0 Jouni Korhonen =0A> =0A>=A0 Interne=
t Area Directors:=0A>=A0 =A0 =A0 Ralph Droms =0A>=A0=
 =A0 =A0 Jari Arkko =0A> =0A>=A0 Internet Area Adviso=
r:=0A>=A0 =A0 =A0 Jari Arkko =0A> =0A>=A0 Mailing Lis=
ts:=0A>=A0 =A0 =A0 General Discussion: mext@ietf.org=0A>=A0 =A0 =A0 To Subs=
cribe:=A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/mext=0A>=A0 =A0 =A0=
 Archive:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/mail-archive/web/mext=
=0A> =0A> Description of Working Group:=0A> =0A>=A0  The Distributed Mobili=
ty Management (DMM) working group specifies IP=0A>=A0  mobility, access net=
work and routing solutions, which allow for=0A>=A0  setting up IP networks =
so that traffic is distributed in an=0A>=A0  optimal way and does not rely =
on centrally deployed anchors to manage=0A>=A0  IP mobility sessions. The d=
istributed mobility management solutions=0A>=A0  aim for transparency above=
 the IP layer, including maintenance of=0A>=A0  active transport level sess=
ions as mobile hosts or entire mobile=0A>=A0  networks change their point o=
f attachment to the Internet.=0A> =0A>=A0  The protocol solutions should be=
 enhancements to existing IP mobility=0A>=A0  protocols, either host- or ne=
twork-based, such as Mobile IPv6=0A>=A0  [RFC6275, 5555], Proxy Mobile IPv6=
 [RFC5213, 5844] and=0A>=A0  NEMO [RFC3963]. =0A=0AThis sentence gives the =
impression that extensions to MIP/PMIP will be necessary, i.e. here, the ch=
arter 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), th=
en, if necessary, specify extensions. So, I'd suggest to reword as follows:=
=0A=0AThe protocol solutions should be based on existing IP mobility=0A=A0 =
Protocols and related mechanisms, either host- or network-based, such as Mo=
bile IPv6=0A=A0  [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and=0A=
=A0 NEMO [RFC3963]. =0A=0AAlternatively, the distributed mobility managemen=
t=0A>=A0  solution can be transparent to any underlying IP mobility protoco=
l.=0A>=A0  Although the maintenance of stable home address(es) and/or prefi=
x(es)=0A>=A0  and upper level sessions is a desirable goal when mobile =0A>=
 hosts/routers=0A>=A0  change their point of attachment to the Internet, it=
 is not a strict=0A>=A0  requirement. Mobile hosts/routers should not assum=
e that IP=0A>=A0  addressing including home address(es) and/or home network=
 prefix(es)=0A>=A0  remain the same throughout the entire upper level sessi=
on lifetime.=0A> =0A=0AI suggest to add the following statement:=0A=0AMobil=
e hosts/routers should not assume always-on mobility support.=0A=0A>=A0  Th=
e distributed mobility management solutions primarily target IPv6=0A>=A0  D=
eployment and should not be tailored specifically to support IPv4,=0A>=A0  =
in particular in situations where private IPv4 addresses and/or NATs=0A>=A0=
  are used. At least IPv6 is assumed to be present in both the mobile=0A>=
=A0  host/router and the access networks. Independent of the distributed=0A=
>=A0  mobility management solution, backward compatibility must be=0A>=A0  =
maintained. If the network or the mobile host/router do not support=0A>=A0 =
 the distributed mobility management enabling protocol, nothing should=0A>=
=A0  break.=0A> =0A> Work items related to the distributed mobility managem=
ent include:=0A> =0A>=A0  o Solution Requirements: Define precisely the pro=
blem of distributed=0A>=A0 =A0  mobility management and identity the requir=
ements for a distributed=0A>=A0 =A0  mobility management solution.=0A> =0A>=
=A0  o Best practices and Gap Analysis: Document best practices for the=0A>=
=A0 =A0  deployment of existing mobility protocols in a distributed mobilit=
y=0A>=A0 =A0  management environment and identify the limitations of each s=
uch=0A>=A0 =A0  approach with respect to fulfillment of the solution requir=
ements.=0A> =0A>=A0  o If limitations are identified as part of the above d=
eliverable,=0A>=A0 =A0  specify extensions to existing protocols that remov=
es these=0A>=A0 =A0  limitations within a distributed mobility management e=
nvironment.=0A> =0A=0AIMHO, the gap analysis should not be part of the best=
 current practices. The BCP may stress some limitations but an exhaustive g=
ap analysis should be the motivation for protocols extensions. So, I sugges=
t to rearrange work items as follows: =0A=0A=A0  o Best practices: Document=
 best practices for the=0A=A0 =A0  deployment of existing mobility protocol=
s in a distributed mobility=0A=A0 =A0  management environment.=0A=0A=0Ao=A0=
 Gap Analysis and extensions: identify the limitations of each such=0A=A0 =
=A0 approach with respect to fulfillment of the solution requirements. If l=
imitations are,=0A=A0 =A0 specify extensions to existing protocols that rem=
oves these=0A=A0 =A0 limitations within a distributed mobility management e=
nvironment.=0A=0A=0A> Goals and Milestones:=0A> =0A>=A0  Aug 2012 - Submit =
I-D 'Solution Requirements' as a working=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 gro=
up document. To be Informational RFC.=0A>=A0  Aug 2012 - Submit I-D 'Best p=
ractices and Gap Analysis' as a working=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 grou=
p document. To be Informational RFC.=0A=0AAs explained above, I think the g=
ap analysis should not be part of the BCP. So, this goal should be:=0A=0A=
=A0  Aug 2012 - Submit I-D 'Best practices' as a working=0A=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 group document. To be Informational RFC.=0A=0A>=A0  Nov 2012 - =
Evaluate the need for additional working group document(s)=0A>=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 for extensions to fill the identified gaps.=0A=0AExtensions=
 should be motivated by a complete gap analysis. So, this goal should be:=
=0A=0ANov 2012 - Gap analysis and evaluation for the need of additional wor=
king group document(s)=0A=A0 =A0 =A0 =A0 =A0 =A0 for extensions to fill the=
 identified gaps.=0A=0A>=A0  Jan 2013 - Submit I-D 'Solution Requirements' =
to the IESG for=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 consideration as an Informat=
ional RFC.=0A>=A0  Jan 2013 - Submit I-D 'Best practices and Gap Analysis' =
to the IESG =0A> for=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 consideration as an Inf=
ormational RFC.=0A>=A0  Mar 2013 - Conclude the working group or re-charter=
.=0A> =0A> =0A> _______________________________________________=0A> MEXT ma=
iling list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/listinfo/mext=
=0A=0A=0A------------------------------=0A=0AMessage: 4=0ADate: Tue, 20 Dec=
 2011 19:54:13 +0100=0AFrom: Conny Larsson =0AT=
o: jouni korhonen , "julien.ietf@gmail.com=0A=A0=A0=
=A0 Laganier"=A0=A0=A0 =0ACc: Jari Arkko , "mext@ietf.org" =0ASubject: Re: [MEXT] The firs=
t proposal for the DMM charter=0AMessage-ID: <4EF0D9D5.2070609@ericsson.com=
>=0AContent-Type: text/plain; charset=3D"ISO-8859-1"; format=3Dflowed=0A=0A=
Hi Jouni, Julien=0A=0AI believe the charter looks good but I would like to =
ask you if =0Adeployment scenarios are covered by the charter or not (I'm t=
hinking of =0Aa Informational RFC)?=0A=0ALet me be a bit more specific. Whe=
n discussing DMM (in a 3GPP =0Aperspective) with people I=A0 get the impres=
sion that many operators are =0Ainterested in the topic but that they have =
very few peering points. They =0Aare not always interested (or they do not =
see the need) in deploying =0Amore peering points since they are expensive.=
 Perhaps the reason for =0Athis is related to the current hierarchical arch=
itecture and will change =0Awith a more distributed architecture.=0A=0ASo w=
hat do you think? Is there a need for this kind of document?=0A=0ABest Rega=
rds=0AConny=0A=0A=0AOn 2011-12-14 09:54, jouni korhonen wrote:=0A> Folks,=
=0A>=0A> We have been working on a charter text from DMM based on the initi=
al goal setting and the input we received during the Taipei meeting. Note t=
hat this is the first draft and now we are soliciting for input.=0A>=0A> - =
Jouni&=A0 Julien=0A>=0A>=0A> ----------------------------------------------=
---------------------------=0A>=0A> Distributed Mobility Management (DMM)=
=0A> -------------------------------------=0A>=0A> Charter=0A>=0A>=A0  Curr=
ent Status: Active=0A>=0A>=A0  Chairs:=0A>=A0 =A0 =A0  Julien Laganier=0A>=A0 =A0 =A0  Jouni Korhonen=
=0A>=0A>=A0  Internet Area Directors:=0A>=A0 =A0 =A0  Ralph Droms=0A>=A0 =A0 =A0  Jari Arkko=0A>=0A>=A0  =
Internet Area Advisor:=0A>=A0 =A0 =A0  Jari Arkko=0A>=
=0A>=A0  Mailing Lists:=0A>=A0 =A0 =A0  General Discussion: mext@ietf.org=
=0A>=A0 =A0 =A0  To Subscribe:=A0 =A0 =A0 https://www.ietf.org/mailman/list=
info/mext=0A>=A0 =A0 =A0  Archive:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.o=
rg/mail-archive/web/mext=0A>=0A> Description of Working Group:=0A>=0A>=A0 =
=A0 The Distributed Mobility Management (DMM) working group specifies IP=0A=
>=A0 =A0 mobility, access network and routing solutions, which allow for=0A=
>=A0 =A0 setting up IP networks so that traffic is distributed in an=0A>=A0=
 =A0 optimal way and does not rely on centrally deployed anchors to manage=
=0A>=A0 =A0 IP mobility sessions. The distributed mobility management solut=
ions=0A>=A0 =A0 aim for transparency above the IP layer, including maintena=
nce of=0A>=A0 =A0 active transport level sessions as mobile hosts or entire=
 mobile=0A>=A0 =A0 networks change their point of attachment to the Interne=
t.=0A>=0A>=A0 =A0 The protocol solutions should be enhancements to existing=
 IP mobility=0A>=A0 =A0 protocols, either host- or network-based, such as M=
obile IPv6=0A>=A0 =A0 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] an=
d=0A>=A0 =A0 NEMO [RFC3963]. Alternatively, the distributed mobility manage=
ment=0A>=A0 =A0 solution can be transparent to any underlying IP mobility p=
rotocol.=0A>=A0 =A0 Although the maintenance of stable home address(es) and=
/or prefix(es)=0A>=A0 =A0 and upper level sessions is a desirable goal when=
 mobile hosts/routers=0A>=A0 =A0 change their point of attachment to the In=
ternet, it is not a strict=0A>=A0 =A0 requirement. Mobile hosts/routers sho=
uld not assume that IP=0A>=A0 =A0 addressing including home address(es) and=
/or home network prefix(es)=0A>=A0 =A0 remain the same throughout the entir=
e upper level session lifetime.=0A>=0A>=A0 =A0 The distributed mobility man=
agement solutions primarily target IPv6=0A>=A0 =A0 Deployment and should no=
t be tailored specifically to support IPv4,=0A>=A0 =A0 in particular in sit=
uations where private IPv4 addresses and/or NATs=0A>=A0 =A0 are used. At le=
ast IPv6 is assumed to be present in both the mobile=0A>=A0 =A0 host/router=
 and the access networks. Independent of the distributed=0A>=A0 =A0 mobilit=
y management solution, backward compatibility must be=0A>=A0 =A0 maintained=
. If the network or the mobile host/router do not support=0A>=A0 =A0 the di=
stributed mobility management enabling protocol, nothing should=0A>=A0 =A0 =
break.=0A>=0A> Work items related to the distributed mobility management in=
clude:=0A>=0A>=A0 =A0 o Solution Requirements: Define precisely the problem=
 of distributed=0A>=A0 =A0 =A0 mobility management and identity the require=
ments for a distributed=0A>=A0 =A0 =A0 mobility management solution.=0A>=0A=
>=A0 =A0 o Best practices and Gap Analysis: Document best practices for the=
=0A>=A0 =A0 =A0 deployment of existing mobility protocols in a distributed =
mobility=0A>=A0 =A0 =A0 management environment and identify the limitations=
 of each such=0A>=A0 =A0 =A0 approach with respect to fulfillment of the so=
lution requirements.=0A>=0A>=A0 =A0 o If limitations are identified as part=
 of the above deliverable,=0A>=A0 =A0 =A0 specify extensions to existing pr=
otocols that removes these=0A>=A0 =A0 =A0 limitations within a distributed =
mobility management environment.=0A>=0A> Goals and Milestones:=0A>=0A>=A0 =
=A0 Aug 2012 - Submit I-D 'Solution Requirements' as a working=0A>=A0 =A0 =
=A0 =A0 =A0 =A0 =A0  group document. To be Informational RFC.=0A>=A0 =A0 Au=
g 2012 - Submit I-D 'Best practices and Gap Analysis' as a working=0A>=A0 =
=A0 =A0 =A0 =A0 =A0 =A0  group document. To be Informational RFC.=0A>=A0 =
=A0 Nov 2012 - Evaluate the need for additional working group document(s)=
=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0  for extensions to fill the identified gaps=
.=0A>=A0 =A0 Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for=
=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0  consideration as an Informational RFC.=0A>=
=A0 =A0 Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG=
 for=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0  consideration as an Informational RFC.=
=0A>=A0 =A0 Mar 2013 - Conclude the working group or re-charter.=0A>=0A>=0A=
> _______________________________________________=0A> MEXT mailing list=0A>=
 MEXT@ietf.org=0A> https://www.ietf.org/mailman/listinfo/mext=0A>=0A=0A=0A=
=0A=0A------------------------------=0A=0A_________________________________=
______________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/m=
ailman/listinfo/mext=0A=0A=0AEnd of MEXT Digest, Vol 54, Issue 12=0A*******=
*****************************
--394961386-255435238-1324531526=:16224
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


In my opinion, the term " traffic is distributed in an optima=
l way" seems ambiguous. 
From this s=
tatement, one can get confused, that aim of DMM is to distribute the whole =
data traffic along-with handling mobility in a distributed manner.

One thing =
more: when we talk about DMM, then it means that we have to make changes in=
 the network (routers, gateways, access points, base stations) so that they=
 can handle mobility in a combined effort, not relying on a single MAP. But=
 in 2nd paragraph of charter, it is written "either host- or network-based"=
 means that new solutions can be either network based or host based (E2E). =
How, a mobility solution that works in a distributed manner can be host bas=
ed
 (E2E)? It will be a network based solution. 
 
regards
<=
div>---------------

Peer Azmat Shah

<=
div>1.  Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONA=
S, Malaysia | +60 14 345 6020
2.  Lecturer | Department of CS | C=
OMSATS University of Science & Technology, Pakistan | +92 321 582 2507<=
br>

  
 
  
  
---=
-------------------------------------------------------------------

=
Message: 1
Date: Tue, 20 Dec 2011 10:29:53 +0200
From: Jari Arkko <=
;jari.arkko@piuha.net>
To: j=
ouni korhonen <jouni.nospam@gmail.com>
Cc: "ju=
lien.ietf@gmail.com Laganier" <julien.ietf@gmail.com>,=

    mext@ietf.org
Subject: Re: [MEXT] The first proposal f=
or the DMM charter
Message-ID: <4EF04781.3080700@piu=
ha.net>
Content-Type: text/plain; charset=3DISO-8859-1; format=3D=
flowed

I think this looks very good, but I would still take into acc=
ount Pierrick's suggested edits, and I think we have to be far more specifi=
c about that "can
 be transparent to any underlying mobility protocol part", because it confu=
ses 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 IA=
B, but I expect that the chairs may produce additional refined versions.
Distributed Mobility Management (DMM)
-----------------------------=
--------

Charter

  Current Status: Active

  =
Chairs:
      Julien Laganier <julien.ietf@gmai=
l.com>
      Jouni Korhonen <jouni.nos=
pam@gmail.com>

  Internet Area Directors:
  &nbs=
p;   Ralph Droms <rdroms.ietf@gmail.com>
  &=
nbsp;
   Jari Arkko <jari.arkko@piuha.net>

  Inte=
rnet Area Advisor:
      Jari Arkko <jari.arkko@p=
iuha.net>

  Mailing Lists:
      Gener=
al Discussion: mext@ietf.org
      To Subscribe:    =
   https://www.ietf.org/mailman/listinfo/mext
     =
; Archive:            http://www.ietf.org/mail-a=
rchive/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 u=
p IP networks so that traffic is distributed in an
   optimal way a=
nd does not rely on centrally deployed anchors to manage
   IP mobi=
lity sessions. The distributed mobility management solutions
   aim=
 for transparency above the IP layer, including maintenance of
   a=
ctive transport level sessions as mobile hosts or entire mobile
   =
networks change their point of attachment to the Internet.

   T=
he protocol solutions should be based on existing IP mobility
   pr=
otocols, either host- or network-based, such as Mobile IPv6
   [RFC=
6275, 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 differe=
nt types of communications.

   Although the maintenance
 of stable home address(es) and/or prefix(es)
   and upper level se=
ssions is a desirable goal when mobile hosts/routers
   change thei=
r point of attachment to the Internet, it is not a strict
   requir=
ement. Mobile hosts/routers should not assume that IP
   addressing=
 including home address(es) and/or home network prefix(es)
   remai=
n the same throughout the entire upper level session lifetime,
   o=
r that support for mobility functions is provided on the network side
&n=
bsp;  in all conditions.

   The distributed mobility management=
 solutions primarily target IPv6
   Deployment and should not be ta=
ilored specifically to support IPv4,
   in particular in situations=
 where private IPv4 addresses and/or NATs
   are used. At least IPv=
6 is assumed to be present in both the mobile
   host/router and th=
e access networks. Independent of the distributed
 =20
 mobility management solution, backward compatibility must be
   ma=
intained. 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 manage=
ment include:

   o Solution Requirements: Define precisely the =
problem of distributed
     mobility management and identity t=
he requirements for a distributed
     mobility management sol=
ution.

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

 =
 o  Gap Analysis and extensions: identify the limitations in the best =
current
      practices with respect to providing the exp=
ected 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<=
br>              group document. To be I=
nformational 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)
      &nbs=
p;       for extensions to fill the identified gaps.
&nbs=
p;  Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
 =
             consideration as an Informationa=
l RFC.
   Jan 2013 - Submit I-D 'Best practices ' to the
 IESG for
              consideration=
 as an Informational RFC.
   Mar 2013 - Submit I-D 'Gap Analysis' t=
o the IESG for
              consider=
ation as an Informational RFC.
   Mar 2013 - Evaluate the need for =
further work based on the identified gaps
        &n=
bsp;     and revise the milestones and/or the charter of the grou=
p



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

Message: 2
Date: =
Tue, 20 Dec 2011 10:52:15 +0200
From: jouni korhonen <jouni.=
nospam@gmail.com>
To: Jari Arkko <jari.arkko@piuha.net>
Cc: "julien.ietf@gmail.com Laganier" <julien.ietf@gmail.com>,
    mext@ietf.org
Subje=
ct: Re: [MEXT] The first proposal for the DMM charter
Message-ID: <563F11DB-2F08-40AC-A=
788-70CBE9EFE745@gmail.com>
Content-Type: text/plain; charset=3Du=
s-ascii


Jari,


On Dec 20, 2011, at 10:29 AM, Jari Arkk=
o wrote:

> I think this looks very good, but I would still take i=
nto 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.

Thanks for the edit. The "transparent" par=
t was
 definitely poorly worded as it was meant for bettering the use of CoAs.. B=
ut 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


> 
> Suggested edits belo=
w. I have sent this version to the IESG and IAB, but I expect that the chai=
rs may produce additional refined versions.
> 
> Distributed Mo=
bility Management (DMM)
> -------------------------------------
&g=
t; 
> Charter
> 
> Current Status: Active
> 
>=
; Chairs:
>     Julien Laganier <julien.ietf@gmai=
l.com>
>     Jouni Korhonen <jouni.nospa=
m@gmail.com>
> 
> Internet Area Directors:
> 
    Ralph Droms <rdroms.ietf@gmail.com>
>&nbs=
p;    Jari Arkko <jari.arkko@piuha.net>
> 
&=
gt; Internet Area Advisor:
>     Jari Arkko <jari.=
arkko@piuha.net>
> 
> Mailing Lists:
>   =
;  General Discussion: mext@ietf.org
>     To Subscribe:  &=
nbsp;    https://www.ietf.org/mailman/listinfo/mext
>  &n=
bsp;  Archive:            http://www.ietf.org/mail-archive/web/mext
> > Description of Working Group:
> 
>  The Distributed=
 Mobility Management (DMM) working group specifies IP
>  mobilit=
y, access network and routing solutions, which allow for
>  sett=
ing up IP networks so that traffic is distributed in an
>  optim=
al way and does not rely on centrally deployed anchors to manage
>&nb=
sp; IP mobility sessions. The distributed mobility management solutions
=
>  aim for transparency above the IP layer, including maintenance o=
f
>  active transport level sessions as mobile hosts or entire m=
obile
>  networks change their point of attachment to the Intern=
et.
> 
>  The protocol solutions should be based on existi=
ng 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 addr=
esses in an
>  efficient manner for different types of communica=
tions.
> 
>  Although the maintenance of stable home addre=
ss(es) and/or prefix(es)
>  and upper level sessions is a desira=
ble goal when mobile hosts/routers
>  change their point of atta=
chment to the Internet, it is not a strict
>  requirement. Mobil=
e hosts/routers should not assume that IP
>  addressing includin=
g home address(es) and/or home network prefix(es)
>  remain the =
same throughout the entire upper level session lifetime,
>  or t=
hat support for mobility functions is provided on the network side
>&=
nbsp; in all conditions.
> 
>  The distributed mobility ma=
nagement 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
>&n=
bsp; are used. At least IPv6 is assumed to be present in both the mobile>  host/router and the access networks. Independent of the distrib=
uted
>  mobility management solution, backward compatibility mus=
t be
>  maintained. If the network or the mobile host/router do =
not support
>  the distributed mobility management enabling prot=
ocol, nothing should
>  break.
> 
> Work items relat=
ed to the distributed mobility management include:
> 
>  o=
 Solution Requirements: Define precisely the problem of distributed
>=
    mobility management and identity the requirements for a distr=
ibuted
>    mobility management solution.
> 
>&=
nbsp; o Best practices: Document best practices for
 the
>     deployment of existing mobility protocols in a d=
istributed mobility
>     management environment.
> <=
br>> o  Gap Analysis and extensions: identify the limitations in th=
e best current
>     practices with respect to providing th=
e expected functionality.
> 
>  o If limitations are ident=
ified as part of the above deliverable,
>    specify extens=
ions to existing protocols that removes these
>    limitati=
ons within a distributed mobility management environment.
> 
> =
Goals and Milestones:
> 
>  Aug 2012 - Submit I-D 'Solutio=
n Requirements' as a working
>          &nbs=
p;  group document. To be Informational RFC.
>  Aug 2012 - Submi=
t I-D 'Best practices and Gap Analysis' as a working
>    &=
nbsp;        group document. To be Informational
 RFC.
>  Nov 2012 - Evaluate the need for additional working gro=
up document(s)
>             for extens=
ions to fill the identified gaps.
>  Jan 2013 - Submit I-D 'Solu=
tion Requirements' to the IESG for
>         =
;    consideration as an Informational RFC.
>  Jan 2013 - S=
ubmit I-D 'Best practices ' to the IESG for
>      &nb=
sp;      consideration as an Informational RFC.
>  Mar=
 2013 - Submit I-D 'Gap Analysis' to the IESG for
>    &nbs=
p;        consideration as an Informational RFC.
>&nbs=
p; Mar 2013 - Evaluate the need for further work based on the identified ga=
ps
>             and revise the milesto=
nes and/or the charter of the group
> 



---------------=
---------------

Message: 3
Date: Mon, 19 Dec 2011 11:57:44
 +0100
From: <pierrick.seite@orange.com>
To:=
 <jouni.nospam@gmail.com>,    <mext@ietf.org>
Cc: julien.ietf@gmail.com, jari.arkko@piuha.net
Subject: Re: [MEXT] The first proposal for the DMM charter
Message-=
ID:
    <843DA8228A1BA74CA=
31FB4E111A5C46202169B1B@ftrdmel0.rd.francetelecom.fr>
  =
; 
 
Content-Type: text/plain;    charset=3D"iso-8859-1"
=

Hi Jouni,

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

Pierrick

> -=
----Message d'origine-----
> De?: mext-bounces@ietf.org [m=
ailto:mext-bounces@ietf.org] De la part de
> jouni korhone=
n
> Envoy??: dimanche 18 d?cembre 2011 23:21
> ??: mext@ietf.org> Cc?: julien.ietf@gmail.com 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?
> 
> - J=
ouni
> 


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

H=
i Jouni & Julien,

This charter looks good. However, please see i=
nline few suggestions for modifications.

Thanks,
Pierrick

=
> -----Message d'origine-----
> De : mext-bounces@ietf.org<=
/a> [mailto:mext-bounces@ietf.org] De la part 
> de jouni =
korhonen Envoy? : mercredi 14 d?cembre 2011 09:54 ? : 
> mext@ietf.org C=
c : julien.ietf@gmail.com Laganier; jouni korhonen; 
> Jar=
i Arkko Objet : [MEXT] The first proposal for the DMM charter
> 
&=
gt;
 Folks,
> 
> We have been working on a charter text from DMM ba=
sed on the initial 
> goal setting and the input we received during t=
he Taipei meeting. Note 
> that this is the first draft and now we ar=
e soliciting for input.
> 
> - Jouni & Julien
> 
&=
gt; 
> --------------------------------------------------------------=
--------
> -
> --
> 
> Distributed Mobility Managem=
ent (DMM)
> -------------------------------------
> 
> Ch=
arter
> 
>  Current Status: Active
> 
>  =
Chairs:
>      Julien Laganier <julien.ietf@=
gmail.com>
>      Jouni Korhonen <j=
ouni.nospam@gmail.com>
> 
>  Internet Area
 Directors:
>      Ralph Droms <rdroms.ietf@=
gmail.com>
>      Jari Arkko <jari.arkk=
o@piuha.net>
> 
>  Internet Area Advisor:
>&n=
bsp;     Jari Arkko <jari.arkko@piuha.net>
>=
 
>  Mailing Lists:
>      General Discussi=
on: mext@=
ietf.org
>      To Subscribe:      =
 h=
ttps://www.ietf.org/mailman/listinfo/mext
>      A=
rchive:            http:=
//www.ietf.org/mail-archive/web/mext
> 
> Description of Wo=
rking Group:
> 
>   The Distributed Mobility Management (D=
MM) 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 ses=
sions. The distributed mobility management solutions
>   aim for=
 transparency above the IP layer, including maintenance of
>   a=
ctive transport level sessions as mobile hosts or entire mobile
>&nbs=
p;  networks change their point of attachment to the Internet.
> 
=
>   The protocol solutions should be enhancements to existing IP mo=
bility
>   protocols, either host- or network-based, such as
 Mobile IPv6
>   [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 58=
44] and
>   NEMO [RFC3963]. 

This sentence gives the impr=
ession that extensions to MIP/PMIP will be necessary, i.e. here, the charte=
r 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] a=
nd
  NEMO [RFC3963]. 

Alternatively, the distributed mobilit=
y management
>   solution can be transparent to any underlying I=
P mobility protocol.
>   Although the maintenance of
 stable home address(es) and/or prefix(es)
>   and upper level s=
essions 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 prefi=
x(es)
>   remain the same throughout the entire upper level sess=
ion lifetime.
> 

I suggest to add the following statement:
=

Mobile hosts/routers should not assume always-on mobility support.
<=
br>>   The distributed mobility management solutions primarily targ=
et IPv6
>   Deployment and should not be tailored specifically t=
o support IPv4,
>   in particular in situations where private IP=
v4 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 ma=
nagement solution, backward compatibility must be
>   maintained=
. If the network or the mobile host/router do not support
>   th=
e distributed mobility management enabling protocol, nothing should
>=
   break.
> 
> Work items related to the distributed mobil=
ity management include:
> 
>   o Solution Requirements: De=
fine precisely the problem of distributed
>     mobility ma=
nagement and identity the requirements for a distributed
>  &nbs=
p;  mobility management solution.
> 
>   o Best practices =
and Gap Analysis: Document best practices for the
>     dep=
loyment of existing mobility protocols in a distributed mobility
>&nb=
sp;    management environment and identify the limitations of each suc=
h
>     approach with respect to fulfillment of the
 solution requirements.
> 
>   o If limitations are identi=
fied as part of the above deliverable,
>     specify extens=
ions to existing protocols that removes these
>     limitat=
ions within a distributed mobility management environment.
> 

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

   o Best practices: Document best practices f=
or the
     deployment of existing mobility protocols in a dis=
tributed mobility
     management environment.


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


> Goals and Mi=
lestones:
> 
>   Aug 2012 - Submit I-D 'Solution Requireme=
nts' as a working
>              g=
roup document. To be Informational RFC.
>   Aug 2012 - Submit I-=
D 'Best practices and Gap Analysis' as a working
>     =
;         group document. To be Informational RFC.
<=
br>As explained above, I think the gap analysis should not be part of the B=
CP. So, this goal should be:

   Aug 2012 - Submit I-D 'Best pra=
ctices' as a working
              gr=
oup document. To be Informational RFC.

>   Nov 2012 - Evalua=
te the need for additional working group document(s)
>    &=
nbsp;         for extensions to fill the
 identified gaps.

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

Nov 2012 - Gap analysis and evalua=
tion 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 f=
or
>              consideration as=
 an Informational RFC.
>   Jan 2013 - Submit I-D 'Best practices=
 and Gap Analysis' to the IESG 
> for
>      &nb=
sp;       consideration as an Informational RFC.
>&nbs=
p;  Mar 2013 - Conclude the working group or re-charter.
> 
> <=
br>> _______________________________________________
> MEXT mailin=
g list
> MEXT@ietf.org
> http=
s://www.ietf.org/mailman/listinfo/mext


---------------------=
---------

Message: 4
Date: Tue, 20 Dec 2011 19:54:13 +0100
Fro=
m: Conny Larsson <conny.larsson@ericsson.com>To: jouni korhonen <jouni.nospam@gmail.com>, "=
julien.ietf@gmail.com
    Laganier"   =
 <julien.ietf@gmail.com>
Cc: Jari Arkko <jari.=
arkko@piuha.net>, "mext@ietf.org" <mext@ietf.org>
Subje=
ct: Re: [MEXT] The first proposal for the DMM charter
Message-ID: <4EF0D9D5.2070609@ericsson.com>
Content-Type:=
 text/plain; charset=3D"ISO-8859-1"; format=3Dflowed

Hi Jouni, Julie=
n

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 <=
br>a Informational RFC)?

Let me be a bit more specific. When discuss=
ing 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. P=
erhaps
 the reason for 
this is related to the current hierarchical architectur=
e and will change 
with a more distributed architecture.

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

Best Regard=
s
Conny


On 2011-12-14 09:54, jouni korhonen wrote:
> Fo=
lks,
>
> We have been working on a charter text from DMM based =
on the initial goal setting and the input we received during the Taipei mee=
ting. Note that this is the first draft and now we are soliciting for input=
.
>
> - Jouni&  Julien
>
>
> -------=
------------------------------------------------------------------
><=
br>> Distributed Mobility Management (DMM)
> ---------------------=
----------------
>
> Charter
>
>   Current Sta=
tus: Active
>
>   Chairs:
>       Jul=
ien Laganier<julien.ietf@gmail.com>
>=
;       Jouni Korhonen<jouni.nospam@gmail.com>
>
>   Internet Area Directors:
>    =
   Ralph Droms<rdroms.ietf@gmail.com>
>  &=
nbsp;    Jari Arkko<jari.arkko@piuha.net>
>
&g=
t;   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
>
> Descripti=
on 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
>  &=
nbsp; optimal way and does not rely on centrally deployed anchors to manage=

>    IP mobility sessions. The distributed mobility manage=
ment solutions
>    aim for transparency above the IP layer=
, including maintenance of
>    active transport level
 sessions as mobile hosts or entire mobile
>    networks ch=
ange 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 m=
obility management
>    solution can be transparent to any =
underlying IP mobility protocol.
>    Although the maintena=
nce of stable home address(es) and/or prefix(es)
>    and u=
pper level sessions is a desirable goal when mobile hosts/routers
>&n=
bsp;   change their point of attachment to the Internet, it is not a s=
trict
>    requirement. Mobile hosts/routers should not ass=
ume that IP
>    addressing including home
 address(es) and/or home network prefix(es)
>    remain the=
 same throughout the entire upper level session lifetime.
>
>&n=
bsp;   The distributed mobility management solutions primarily target =
IPv6
>    Deployment and should not be tailored specificall=
y to support IPv4,
>    in particular in situations where p=
rivate IPv4 addresses and/or NATs
>    are used. At least I=
Pv6 is assumed to be present in both the mobile
>    host/r=
outer 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 p=
rotocol, nothing should
>    break.
>
> Work it=
ems related to the distributed mobility management
 include:
>
>    o Solution Requirements: Define prec=
isely the problem of distributed
>      mobility manag=
ement and identity the requirements for a distributed
>    =
  mobility management solution.
>
>    o Best pr=
actices and Gap Analysis: Document best practices for the
>  &nb=
sp;   deployment of existing mobility protocols in a distributed mobil=
ity
>      management environment and identify the lim=
itations 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<=
br>>      limitations within a distributed mobility manag=
ement environment.
>
> Goals and
 Milestones:
>
>    Aug 2012 - Submit I-D 'Solution R=
equirements' as a working
>            =
   group document. To be Informational RFC.
>    Aug 2=
012 - Submit I-D 'Best practices and Gap Analysis' as a working
>&nbs=
p;              group document. To be Informa=
tional RFC.
>    Nov 2012 - Evaluate the need for additiona=
l 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 Information=
al 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.
>
>
&g=
t; _______________________________________________
> MEXT mailing lis=
t
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
=
>




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

_____________=
__________________________________
MEXT mailing list
MEXT@ietf.org
https:=
//www.ietf.org/mailman/listinfo/mext


End of MEXT Digest, Vol=
 54, Issue 12
************************************


 
   

--394961386-255435238-1324531526=:16224--

From jouni.nospam@gmail.com  Wed Dec 21 22:54:15 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127ED21F8BB3 for ; Wed, 21 Dec 2011 22:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVLtXoXJIZNz for ; Wed, 21 Dec 2011 22:54:14 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F395221F8B8F for ; Wed, 21 Dec 2011 22:54:13 -0800 (PST)
Received: by werb14 with SMTP id b14so3680840wer.31 for ; Wed, 21 Dec 2011 22:54:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Lg4NwgDvVvjSbnr/JR1WgvoK1vCpU70IEci8eCwWk3A=; b=rkiSKcq1eDp7qAoITEBn91cvDPhVhRZmgDVCwIsCUSjlrdWhuvXe+zDCXx4uY6asxh 9rMUy+VMHlPfhm9LtJAjz7afcw226v6aqHevrqxBE/iB8FvUyyOB+5cLhUakXsORHlL/ t483yh2OTR4YSTSPVo+E2QgVGxG6qfYza4yNA=
Received: by 10.216.136.204 with SMTP id w54mr10658688wei.44.1324536848790; Wed, 21 Dec 2011 22:54:08 -0800 (PST)
Received: from [10.255.137.69] ([192.100.123.77]) by mx.google.com with ESMTPS id ep16sm8519283wbb.21.2011.12.21.22.54.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 22:54:06 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <4EF0D9D5.2070609@ericsson.com>
Date: Thu, 22 Dec 2011 08:54:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <4EF0D9D5.2070609@ericsson.com>
To: Conny Larsson 
X-Mailer: Apple Mail (2.1084)
Cc: "julien.ietf@gmail.com Laganier" , Jari Arkko , "mext@ietf.org" 
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Dec 2011 06:54:15 -0000

Conny,

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

> Hi Jouni, Julien
>=20
> 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

>=20
> Best Regards
> Conny
>=20
>=20
> On 2011-12-14 09:54, jouni korhonen wrote:
>> Folks,
>>=20
>> 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.
>>=20
>> - Jouni&  Julien
>>=20
>>=20
>> =
-------------------------------------------------------------------------
>>=20
>> Distributed Mobility Management (DMM)
>> -------------------------------------
>>=20
>> Charter
>>=20
>>  Current Status: Active
>>=20
>>  Chairs:
>>      Julien Laganier
>>      Jouni Korhonen
>>=20
>>  Internet Area Directors:
>>      Ralph Droms
>>      Jari Arkko
>>=20
>>  Internet Area Advisor:
>>      Jari Arkko
>>=20
>>  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
>>=20
>> Description of Working Group:
>>=20
>>   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.
>>=20
>>   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.
>>=20
>>   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.
>>=20
>> Work items related to the distributed mobility management include:
>>=20
>>   o Solution Requirements: Define precisely the problem of =
distributed
>>     mobility management and identity the requirements for a =
distributed
>>     mobility management solution.
>>=20
>>   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.
>>=20
>>   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.
>>=20
>> Goals and Milestones:
>>=20
>>   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.
>>=20
>>=20
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>=20
>=20
>=20


From jouni.nospam@gmail.com  Wed Dec 21 23:05:23 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3321F8B9B for ; Wed, 21 Dec 2011 23:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPJwjKjaaCUe for ; Wed, 21 Dec 2011 23:05:22 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D521F8B98 for ; Wed, 21 Dec 2011 23:05:22 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so11707395wgb.13 for ; Wed, 21 Dec 2011 23:05:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PbLGh9oNspnFF+0z+Uaz3+Dmz4j5y4Q5d6Lar6OPYJs=; b=w6PfSc1WWmKnI0RyE4uR6xZSxTkQfwlNVumLIFc8IYijAH334xHD5Y38UMujJx9arQ IDLtUjkkouf6c8DzgTaWn7DJKahy4gDGkEAdSBPg9CXicIbZVQ/kdShLhE+jr1FfUdHo Id069Bl3IAphwxOOLcuPrYJra/OhXw4WqCMkY=
Received: by 10.216.136.20 with SMTP id v20mr5258205wei.14.1324537521670; Wed, 21 Dec 2011 23:05:21 -0800 (PST)
Received: from [10.255.137.69] ([192.100.123.77]) by mx.google.com with ESMTPS id dd4sm19868147wib.1.2011.12.21.23.05.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 23:05:20 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <1324531526.16224.YahooMailNeo@web28212.mail.ukl.yahoo.com>
Date: Thu, 22 Dec 2011 09:05:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <00748B2A-D48E-41E5-9101-20E4ECD8A263@gmail.com>
References:  <1324531526.16224.YahooMailNeo@web28212.mail.ukl.yahoo.com>
To: Peer Azmat Shah 
X-Mailer: Apple Mail (2.1084)
Cc: "mext@ietf.org" 
Subject: Re: [MEXT] The first proposal for the DMM charter was Re: MEXT Digest, Vol 54, Issue 12
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Dec 2011 07:05:23 -0000

On Dec 22, 2011, at 7:25 AM, Peer Azmat Shah wrote:
>=20
>=20
> One thing more: when we talk about DMM, then it means that we have to =
make changes in the network (routers, gateways, access points, base =
stations) so that they can handle mobility in a combined effort, not =
relying on a single MAP. But in 2nd paragraph of charter, it is written =
"either host- or network-based" means that new solutions can be either =
network based or host based (E2E). How, a mobility solution that works =
in a distributed manner can be host based (E2E)? It will be a network =
based solution.=20

Not necessarily. Say that a mobile node evaluates each time it moves =
whether there is a need to a) find a more suitable anchor for subsequent =
sessions or b) whether use CoA instead of HoA for new sessions. For that =
network based solution is not needed.

- Jouni

ps: please, do not change the subject.. it complicates following the =
thread.


> =20
> regards
> ---------------
>=20
> Peer Azmat Shah
>=20
> 1.  Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONAS, =
Malaysia | +60 14 345 6020
> 2.  Lecturer | Department of CS | COMSATS University of Science & =
Technology, Pakistan | +92 321 582 2507
>=20
>=20

[snip]


From pierrick.seite@orange.com  Thu Dec 22 01:44:59 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D67321F8B4A for ; Thu, 22 Dec 2011 01:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.211
X-Spam-Level: 
X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjBF1u7nI638 for ; Thu, 22 Dec 2011 01:44:58 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4414E21F8AF9 for ; Thu, 22 Dec 2011 01:44:58 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 774765D8858; Thu, 22 Dec 2011 10:44:57 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 6CE375D8857; Thu, 22 Dec 2011 10:44:57 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 22 Dec 2011 10:44:57 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 22 Dec 2011 10:44:56 +0100
Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AB086@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <00748B2A-D48E-41E5-9101-20E4ECD8A263@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] The first proposal for the DMM charter 
Thread-Index: AczAeCdjv81ZnG5ETfK4i9yG/9oH1QAERT+Q
References: <1324531526.16224.YahooMailNeo@web28212.mail.ukl.yahoo.com> <00748B2A-D48E-41E5-9101-20E4ECD8A263@gmail.com>
From: 
To: , 
X-OriginalArrivalTime: 22 Dec 2011 09:44:57.0369 (UTC) FILETIME=[5D838090:01CCC08E]
Cc: mext@ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Dec 2011 09:44:59 -0000

> -----Message d'origine-----
> De=A0: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part =
de
> jouni korhonen
> Envoy=E9=A0: jeudi 22 d=E9cembre 2011 08:05
> =C0=A0: Peer Azmat Shah
> Cc=A0: mext@ietf.org
> Objet=A0: Re: [MEXT] The first proposal for the DMM charter was Re:
> MEXTDigest, Vol 54, Issue 12
>=20
>=20
> On Dec 22, 2011, at 7:25 AM, Peer Azmat Shah wrote:
> >
> >
> > One thing more: when we talk about DMM, then it means that we have =
to
> make changes in the network (routers, gateways, access points, base
> stations) so that they can handle mobility in a combined effort, not
> relying on a single MAP. But in 2nd paragraph of charter, it is =
written
> "either host- or network-based" means that new solutions can be either
> network based or host based (E2E). How, a mobility solution that works
> in a distributed manner can be host based (E2E)? It will be a network
> based solution.
>=20

I do not see the point. Why are you saying only network based solutions =
apply to DMM?

> Not necessarily. Say that a mobile node evaluates each time it moves
> whether there is a need to a) find a more suitable anchor for
> subsequent sessions or b) whether use CoA instead of HoA for new
> sessions. For that network based solution is not needed.
>=20

I second Jouni. Moreover, a  basic of DMM is the distribution of =
mobility anchors. IMHO, this is independent of the location of the =
mobility client; this principle can be applied either to host based or =
network based mobility management.

Pierrick

> - Jouni
>=20
> ps: please, do not change the subject.. it complicates following the
> thread.
>=20
>=20
> >
> > regards
> > ---------------
> >
> > Peer Azmat Shah
> >
> > 1.  Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONAS,
> Malaysia | +60 14 345 6020
> > 2.  Lecturer | Department of CS | COMSATS University of Science &
> Technology, Pakistan | +92 321 582 2507
> >
> >
>=20
> [snip]
>=20
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext

From conny.larsson@ericsson.com  Thu Dec 22 09:06:41 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E23F21F8AFD for ; Thu, 22 Dec 2011 09:06:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGJ2YpLeIiT3 for ; Thu, 22 Dec 2011 09:06:40 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5221F86B3 for ; Thu, 22 Dec 2011 09:06:39 -0800 (PST)
X-AuditID: c1b4fb39-b7b3eae00000252a-f0-4ef3639ff39d
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.DC.09514.F9363FE4; Thu, 22 Dec 2011 18:06:39 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Dec 2011 18:06:38 +0100
Message-ID: <4EF36396.7090002@ericsson.com>
Date: Thu, 22 Dec 2011 18:06:30 +0100
From: Conny Larsson 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: jouni korhonen 
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <4EF0D9D5.2070609@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: "julien.ietf@gmail.com Laganier" , Jari Arkko , "mext@ietf.org" 
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Dec 2011 17:06:41 -0000

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

On 2011-12-22 07:54, jouni korhonen wrote:
> 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
>
>> Best Regards
>> Conny
>>
>>
>> On 2011-12-14 09:54, jouni korhonen wrote:
>>> 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
>>>       Jouni Korhonen
>>>
>>>   Internet Area Directors:
>>>       Ralph Droms
>>>       Jari Arkko
>>>
>>>   Internet Area Advisor:
>>>       Jari Arkko
>>>
>>>   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:
>>>
>>>    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.
>>>
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>>



From g.hajer@gmail.com  Thu Dec 29 13:47:35 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEF621F8BB1 for ; Thu, 29 Dec 2011 13:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rca3W8d3sQu for ; Thu, 29 Dec 2011 13:47:34 -0800 (PST)
Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3B74921F8B7F for ; Thu, 29 Dec 2011 13:47:34 -0800 (PST)
Received: by ghrr16 with SMTP id r16so5442991ghr.13 for ; Thu, 29 Dec 2011 13:47:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MFfxtlsmWbN4MQ+zrK8CZn4/ePyAMpBrqRdGoyyyWdU=; b=h01JyolGYisidFrpC8K9JnF2GwzkCA4N5CPOZjlBaCbrmXAL+m0EPdzz4+fHgz5PW+ m67oaNYF/R5fa+iAXJyFW0xKXoraOt5rqgEQXNQjGBEvtbzTC9iEqX9wFgEXu285fGd+ Lks72bmgBB0O69L/BgxU9sBRVYib9+35PFFtc=
MIME-Version: 1.0
Received: by 10.236.178.101 with SMTP id e65mr50012620yhm.40.1325195253546; Thu, 29 Dec 2011 13:47:33 -0800 (PST)
Received: by 10.236.187.5 with HTTP; Thu, 29 Dec 2011 13:47:33 -0800 (PST)
Date: Thu, 29 Dec 2011 22:47:33 +0100
Message-ID: 
From: "G.Hajer" 
To: mext@ietfa.amsl.com
Content-Type: multipart/alternative; boundary=20cf303f65a8587f4304b542102c
Subject: [MEXT] reply
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Dec 2011 21:47:57 -0000

--20cf303f65a8587f4304b542102c
Content-Type: text/plain; charset=ISO-8859-1



--20cf303f65a8587f4304b542102c
Content-Type: text/html; charset=ISO-8859-1







--20cf303f65a8587f4304b542102c--

From g.hajer@gmail.com  Thu Dec 29 13:48:45 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6D921F8BB5 for ; Thu, 29 Dec 2011 13:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.406
X-Spam-Level: 
X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9nWgwskinkP for ; Thu, 29 Dec 2011 13:48:44 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C442721F8B7F for ; Thu, 29 Dec 2011 13:48:44 -0800 (PST)
Received: by ggnk5 with SMTP id k5so9796520ggn.31 for ; Thu, 29 Dec 2011 13:48:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zzqoG/okgj5qnyRS65QSLDUPDvBeQC8bTYOUYlpeKes=; b=qPt5/QU/joebzVHcS9jv7ipTzaS9ucLm4zzh3QcPhkxAfrWYXWA73gYsP7qcmgeZrf TXGgwUWOUMx3d0x5P9UYJ/bZ4Qqmhndqcwwm6CaIfGVl20rF0PU79bM/cfeYAt34G5N2 TPjqCAXu5oM7k9usQdoD0zb5epNCLOsoSf6/g=
MIME-Version: 1.0
Received: by 10.236.185.138 with SMTP id u10mr32088188yhm.57.1325195324469; Thu, 29 Dec 2011 13:48:44 -0800 (PST)
Received: by 10.236.187.5 with HTTP; Thu, 29 Dec 2011 13:48:44 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 29 Dec 2011 22:48:44 +0100
Message-ID: 
From: "G.Hajer" 
To: mext@ietf.org
Content-Type: multipart/alternative; boundary=20cf3056430d92b0c404b542148c
Subject: [MEXT] Fwd: mobile ip
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Dec 2011 21:48:45 -0000

--20cf3056430d92b0c404b542148c
Content-Type: text/plain; charset=ISO-8859-1

hello
i want to ask you how can i install the patch mobile ip for ns-2.33...i
also need an exemple of tcl file.that simulte an ip network
can somebody,also, help me to calculate the handoff latency, and if someone
has awk or perl script to do so, please send me .
i need it thanks in advance.


-- 
"Somewhere, something incredible is waiting to be known."




-- 
"Somewhere, something incredible is waiting to be known."

--20cf3056430d92b0c404b542148c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



hello=A0

i want to ask you how can i install the=
 patch mobile ip for ns-2.33...i also need an exemple of tcl file.that simu=
lte an ip network=A0



can somebody,also, =
help me to calculate the handoff latency, and if someone has awk or perl sc=
ript to do so, please send me .=A0


i need it thanks in advance.=A0=





-- 
"Somewhere, s=
omething incredible is waiting to be known."










-- 
"Somewhere, something incre=
dible is waiting to be known."





--20cf3056430d92b0c404b542148c--

From jari.arkko@piuha.net  Thu Dec 29 23:52:43 2011
Return-Path: 
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1D921F858D for ; Thu, 29 Dec 2011 23:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.497
X-Spam-Level: 
X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mndxxdnNtAQ9 for ; Thu, 29 Dec 2011 23:52:42 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D4F6A21F856F for ; Thu, 29 Dec 2011 23:52:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 694C62CC4D; Fri, 30 Dec 2011 09:52:40 +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 nuUJwCf96WUv; Fri, 30 Dec 2011 09:52:39 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1E8D42CC31; Fri, 30 Dec 2011 09:52:39 +0200 (EET)
Message-ID: <4EFD6DC6.3070904@piuha.net>
Date: Fri, 30 Dec 2011 09:52:38 +0200
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: draft-ietf-mext-mip6-tls@tools.ietf.org, "mext@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [MEXT] draft-ietf-mext-mip6-tls AD review
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Dec 2011 07:52:43 -0000

I have reviewed this specification. I think it is in good shape and almost ready to move forward. I have some comments below, please address them in a new revision of the draft. My main comments relate to sequence numbers, Section 7, and IANA considerations.

> The HAC can be co-located with the HA, or can be an
> independent entity.  For the latter case, communication between HAC
> and HA is not defined by this document.  The Diameter protocol can be
> used between the HA and HAC when the two entities are not collocated.

I'd change the last sentence to: "Such communication could be built on top of AAA protocols such as Diameter, for instance."

(You can't just use Diameter, you'd have to define a specific way of doing it.)

> The security framework proposed in this document is not intended to
> replace the currently specified architecture which relies on IPsec
> and IKEv2.  It provides an alternative solution which is more optimal
> for certain deployment scenarios.
>

Add to the end:

This and other alternative security models have been considered by the MEXT working group at the IETF, and it has been decided that the alternative solutions should be published as Experimental RFCs, so that more implementation and deployment experience with these models can be gathered. The working group may reconsider the status of the different models in the future, if it becomes clear that one is superior to the others.

>    Mobile IPv6 implementation complexity increases quite dramatically.

I would just say "... complexity increases."

> At an abstract level it can
> be said that implementing Mobile IPv6 with IPsec and IKEv2 is
> possible only with modifications to the IPsec and IKEv2 components.
> The original design intent was to reuse IPsec without having to
> modify them.  The current security model requires an IPsec/IKEv2
> implementation that is specific to Mobile IPv6.

I don't think this is quite right. I'd reword to:

Implementing Mobile IPv6 with IPsec and IKEv2 requires modifications to both the IPsec and IKEv2 components, due to the communication models that Mobile IPv6 uses and the changing IP addresses. For further details, see Section 7.1 in [RFC3776].

Section 3 felt a little bit duplicated text from Section 1. Might be an idea to look at merging the two. Don't spend too much effort on that however, I can live with the current two sections as well.

>     Sequence numbers:
>
>        A monotonically increasing unsigned sequence number used in all
>        protected packets exchanged between the MN and the HA in the same
>        direction.  Sequence numbers are maintained per direction, so each
>        SA includes two independent sequence numbers (MN ->  HA, HA ->  MN).
>        The initial sequence number for each direction MUST always be set
>        to 0 (zero).  Sequence numbers cycle to 0 (zero) when increasing
>        beyond their maximum defined value.
>

I don't understand why sequence numbers have to be agreed on between the MN and HAC. Perhaps the use of sequence numbers should be, not the numbers themselves?

Please clarify.

>     form of a Network Access Identifier (NAI) [RFC4282  ].
>
>        mn-id = "mn-id" ":" nai CRLF
>        nai = username
>            | "@" realm
>            | username "@" realm
>        ...

I'd prefer you to just say after the first line that "nai" is as defined in RFC4282, not repeat the definition here. Or if you do repeat it, please indicate that it is copied here for convenience. Otherwise people have to go back to RFC 4282 and check that the definition is the same. (I did that, for instance.)

You should use ABNF, please respecify the syntax in ABNF. If I take your syntax and change "|" to "/" I still get at least one error here:

>
>       mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date
>       CRLF

>     The HAC SHOULD provision the MN with an UDP port number, where the HA
>     expects to receive UDP packets.  If this parameter is not present,
>

This comes suddenly for the reader, who at this point has not been introduced to the change that you run everything on top of UDP. Please explain this better earlier in the document.

>     The SPI value is followed by a 32-bit Sequence Number value that is
>     used to identify retransmissions of encrypted messages.  Each
>     endpoint in the security association maintains two "current" Sequence
>     Numbers: the next one to be used for a packet it initiates and the
>     next one it expects to see in a packet from the other end.  If the MN
>     and the HA ends initiate very different numbers of messages, the
>     Sequence Numbers in the two directions can be very different.  In a
>     case encryption is not used, the Sequence Number MUST be set to 0
>     (zero).

It seems odd to use sequence numbers only for encrypted packets. What about integrity protected packets?

>    All
>     packets that are specific to the Mobile IPv6 protocol and contain a
>     Mobility Header (as defined inSection 6.1.1  . ofRFC 6275  ) SHOULD use
>     the packet format shown in Figure 7.  (This means that some Mobile
>     IPv6 mobility management messages, such as the HoTI message, as
>     treated as data packets and using encapsulation described in
>     Section 6.4  ).

This seems like an inconsistency. HOTI messages are MH messages. Which format do you require for them? Please ciarify.

Section 7 seems odd. First, you say that you don't cover the RO part and then you go on explaining nice ideas that could be done. I would replace Section 7 with the following information:

- statement that this specification does not change any of the procedures for RO
- explanation that tells the reader how the TLS-based HA security model can still support the existing RO procedures (and if it can not... I think you'd have to change your spec... but I don't see why it would have problems).
- identification of possible gaps for future work, such as supporting RO to IPv4 destinations (but we don't support that today, so this isn't the fault of your document). But do not include extra new ideas that could be done (like HAC-based RO).

IANA considerations seems to need some material for the attributes used in your new protocol. Who can allocate them, and should there be a registry?

Jari