IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Dienstag, 3. M=E4rz 2015 11:34 To: dmm@ietf.org Subject: [DMM] [FPSM] next WebEx call We'll have another WebEx call this week to discuss and resolve some open is= sues associated with a solution draft for DMM Forwarding Path Configuration. The call will be on Thursday, 05th March 2015 Time: 23:30 CET / 14:30 PST / 07:30 JST (Friday in Asia) Duration: max 90min. Best regards, marco --_000_69756203DDDDE64E987BC4F70B71A26D999CFA90Hydraofficehd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

For tomorrow’s d= iscussion, please use the WebEx information below to connect.

Best regards,

Marco

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

FPSM

Thursday, March 5, 2015

2:30 pm | Pacific Standard Ti= me (San Francisco, GMT-08:00) | 1 hr

Join WebEx meeting

Meeting number:	200 642 348
Meeting password:	dmm

Join by phone

+1-408-525-6800 Call-in toll number (US/Canada)

+1-866-432-9903 Call-in toll-free number (US/Canada)

Access code: 200 642 348

Global call-in numbers | Toll-free calling restrictions<= o:p>

Add this meeting to your calendar.

Can't join the meeting? Contact support.

IMPORTANT NOTICE: Please note t= hat this WebEx service allows audio and other information sent during the s= ession to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to s= uch recordings. If you do not consent to being recorded, discuss your conce= rns with the host or do not join the session.

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Dienstag, 3. M=E4rz 2015 11:34
To: dmm@ietf.org
Subject: [DMM] [FPSM] next WebEx call

We’ll have another WebEx call this week to dis= cuss and resolve some open issues associated with
a solution draft for DMM Forwarding Path Configuration.

The call will be on Thursday, 05^th March = 2015

Time: 23:30 CET / 14:30 PST / 07:30 JST (Friday in A= sia)

Duration: max 90min.

Best regards,

marco

--_000_69756203DDDDE64E987BC4F70B71A26D999CFA90Hydraofficehd_-- From nobody Wed Mar 4 12:12:58 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84A91A88E4 for ; Wed, 4 Mar 2015 12:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SksPvb1htDYW for ; Wed, 4 Mar 2015 12:12:54 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4591A88DD for ; Wed, 4 Mar 2015 12:12:53 -0800 (PST) Received: from [192.168.2.49] ([88.232.220.127]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0MejCI-1Y9PSt1odc-00OK7o; Wed, 04 Mar 2015 21:12:51 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <003301d051e2$63bf3b00$2b3db100$@av.it.pt> Date: Wed, 4 Mar 2015 22:12:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B756F6B-5AC3-4DC4-8455-1CD71B1600DD@yegin.org> References: <20150226162235.24366.4232.idtracker@ietfa.amsl.com> <003301d051e2$63bf3b00$2b3db100$@av.it.pt> To: Seil Jeon X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:bq6yx3M+IVw9zYJcZNwC3wv+QXk8Zoy11FJ6SQbWQUxEGUXsL5I prrTZ8NRgc17bsV4WleKHbf4aVETx2EGfWOA80e5iinghanFUx9NbuYpvdzoHTT3ZdfYvOO 1RvxqeAYOmTUN+a/TNJ1hs/PKyFNEbD9zVkpw0qx34xKXiG7IjWs/732JuxsFDVsPeAFFq6 Gx6RRSoMv+7WBl+FQkN0w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] New Version Notification for draft-sijeon-dmm-use-cases-api-source-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:12:56 -0000 Hello Seil, As I understand, this new flag helps apps tell the IP stack to configure = a new/additional IP address even if the IP stack is already configured = with there requested type address. It'd be good to spell this out in the I-D. And also, it'd be good to explain why this might be needed, and when = should the apps use this flag. Alper On Feb 26, 2015, at 6:36 PM, Seil Jeon wrote: > Hi DMM folks, >=20 > We submitted a new draft that present specified use cases based on the = on-demand draft we are based on for further steps. > As we discussed and agreed in the previous audio conference, checking = and investigating use cases with the three types of IP addresses, i.e. = fixed, sustained, nomadic IP addresses. Hope to start broad discussions = on this while trying to extend the existing address configuration = mechanisms. Grasping and identifying more definitive requirements based = on the IP address type will be easy and make clear our ways to go, such = as what to extend and how. >=20 > With the discussion, any kinds of comments on it are welcomed. >=20 > Regards, >=20 > Seil Jeon, Ph.D >=20 > Advanced Telecommunications and Networks Group (ATNoG) - = http://atnog.av.it.pt > Instituto de Telecomunicacoes, Aveiro, Portugal - http://www.it.pt >=20 >=20 > Seil Jeon, Ph.D >=20 > Advanced Telecommunications and Networks Group (ATNoG) - = http://atnog.av.it.pt > Instituto de Telecomunicacoes, Aveiro, Portugal - http://www.it.pt >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Thursday, February 26, 2015 4:23 PM > To: Young-Han Kim; Sergio Figueiredo; Seil Jeon; > Subject: New Version Notification for = draft-sijeon-dmm-use-cases-api-source-00.txt >=20 >=20 > A new version of I-D, draft-sijeon-dmm-use-cases-api-source-00.txt > has been successfully submitted by Seil Jeon and posted to the IETF = repository. >=20 > Name: draft-sijeon-dmm-use-cases-api-source > Revision: 00 > Title: Use Cases and API Extension for Source IP = address selection > Document date: 2015-02-26 > Group: Individual Submission > Pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-sijeon-dmm-use-cases-api-source-= 00.txt > Status: = https://datatracker.ietf.org/doc/draft-sijeon-dmm-use-cases-api-source/ > Htmlized: = http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00 >=20 >=20 > Abstract: > This draft specifies and analyzes the expected cases regarding the > selection of a proper source IP address and address type based on > the application features over a distributed mobility management > (DMM) network. It also provides available selection methods in the > specified scenarios. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Mar 4 13:18:41 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CA21A891A for ; Wed, 4 Mar 2015 13:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J034NaY3aCag for ; Wed, 4 Mar 2015 13:18:38 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59C1A890B for ; Wed, 4 Mar 2015 13:18:37 -0800 (PST) Received: from [192.168.25.5] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77267669; Wed, 04 Mar 2015 21:18:36 +0000 From: "Seil Jeon" To: "'Alper Yegin'" References: <20150226162235.24366.4232.idtracker@ietfa.amsl.com> <003301d051e2$63bf3b00$2b3db100$@av.it.pt> <9B756F6B-5AC3-4DC4-8455-1CD71B1600DD@yegin.org> In-Reply-To: <9B756F6B-5AC3-4DC4-8455-1CD71B1600DD@yegin.org> Date: Wed, 4 Mar 2015 21:18:44 -0000 Message-ID: <000301d056c0$cc208fe0$6461afa0$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOJLpdTSu1Exst2WXweS+HLXBkoAH6MziAA3G4DNub5dFRcA== Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] New Version Notification for draft-sijeon-dmm-use-cases-api-source-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 21:18:40 -0000 Hi Alper, Thanks for your interest and valuable comment. Actually, the need of the proposed flag is being explained in Section 2.2.3 Case 2. And the use of this flag depends on such as session duration and sensitivity of IP address change required by apps. This will be considered in a next update. Regards, Seil Jeon -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, March 04, 2015 8:13 PM To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] New Version Notification for draft-sijeon-dmm-use-cases-api-source-00.txt Hello Seil, As I understand, this new flag helps apps tell the IP stack to configure a new/additional IP address even if the IP stack is already configured with there requested type address. It'd be good to spell this out in the I-D. And also, it'd be good to explain why this might be needed, and when should the apps use this flag. Alper On Feb 26, 2015, at 6:36 PM, Seil Jeon wrote: > Hi DMM folks, > > We submitted a new draft that present specified use cases based on the on-demand draft we are based on for further steps. > As we discussed and agreed in the previous audio conference, checking and investigating use cases with the three types of IP addresses, i.e. fixed, sustained, nomadic IP addresses. Hope to start broad discussions on this while trying to extend the existing address configuration mechanisms. Grasping and identifying more definitive requirements based on the IP address type will be easy and make clear our ways to go, such as what to extend and how. > > With the discussion, any kinds of comments on it are welcomed. > > Regards, > > Seil Jeon, Ph.D > > Advanced Telecommunications and Networks Group (ATNoG) - > http://atnog.av.it.pt Instituto de Telecomunicacoes, Aveiro, Portugal > - http://www.it.pt > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, February 26, 2015 4:23 PM > To: Young-Han Kim; Sergio Figueiredo; Seil Jeon; > Subject: New Version Notification for > draft-sijeon-dmm-use-cases-api-source-00.txt > > > A new version of I-D, draft-sijeon-dmm-use-cases-api-source-00.txt > has been successfully submitted by Seil Jeon and posted to the IETF repository. > > Name: draft-sijeon-dmm-use-cases-api-source > Revision: 00 > Title: Use Cases and API Extension for Source IP address selection > Document date: 2015-02-26 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-sijeon-dmm-use-cases-api-source-00 .txt > Status: https://datatracker.ietf.org/doc/draft-sijeon-dmm-use-cases-api-source/ > Htmlized: http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00 > > > Abstract: > This draft specifies and analyzes the expected cases regarding the > selection of a proper source IP address and address type based on > the application features over a distributed mobility management > (DMM) network. It also provides available selection methods in the > specified scenarios. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Sun Mar 8 18:01:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1CD1A0052 for ; Sun, 8 Mar 2015 18:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqHFoa1pyd8k for ; Sun, 8 Mar 2015 18:01:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:622]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4621A004D for ; Sun, 8 Mar 2015 18:01:48 -0700 (PDT) Received: from DM2PR0701MB761.namprd07.prod.outlook.com (10.242.126.18) by DM2PR0701MB762.namprd07.prod.outlook.com (10.242.126.19) with Microsoft SMTP Server (TLS) id 15.1.106.15; Mon, 9 Mar 2015 01:01:33 +0000 Received: from DM2PR0701MB761.namprd07.prod.outlook.com ([10.242.126.18]) by DM2PR0701MB761.namprd07.prod.outlook.com ([10.242.126.18]) with mapi id 15.01.0106.007; Mon, 9 Mar 2015 01:01:32 +0000 From: Abhishek Parakh To: "dmm@ietf.org" Thread-Topic: MobiPST 2015 - Deadline March 16th (extended) Thread-Index: AdBaAUwQ1soujoP9RuWC07aat/94PgAAIuYwAABYr3AAAEh/oAAADHUA Date: Mon, 9 Mar 2015 01:01:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.48.184.172] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0701MB762; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(13624006)(33656002)(15975445007)(2501003)(88552001)(19617315012)(229853001)(77156002)(102836002)(19625215002)(2656002)(77096005)(450100001)(19580405001)(99286002)(62966003)(86362001)(40100003)(74316001)(75432002)(66066001)(19580395003)(46102003)(89122001)(122556002)(107886001)(16236675004)(92566002)(2351001)(87936001)(19300405004)(110136001)(76576001)(50986999)(54356999)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0701MB762; H:DM2PR0701MB761.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR0701MB762; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0701MB762; x-forefront-prvs: 05102978A2 Content-Type: multipart/alternative; boundary="_000_DM2PR0701MB7612AC49299DB9A8135449CB11B0DM2PR0701MB761na_" MIME-Version: 1.0 X-OriginatorOrg: unomaha.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 01:01:32.6814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f1f4be86-d048-47e8-aa26-15b01dcdb13d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0701MB762 Archived-At: Subject: [DMM] MobiPST 2015 - Deadline March 16th (extended) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 01:01:51 -0000 --_000_DM2PR0701MB7612AC49299DB9A8135449CB11B0DM2PR0701MB761na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The 5th International Workshop on Privacy, Security and Trust in Mobile and= Wireless Systems (MobiPST 2015) Las Vegas, Nevada, USA August 6, 2015 Important Dates Paper submission due: March 16, 2015 (extended) Acceptance notification: April 24, 2015 Camera-ready due: May 8, 2015 Workshop: August 6, 2015 Held in conjunction with ICCCN 2015 (Aug 3-5, 2015). ICCCN is technically c= o-sponsored by the IEEE Communications Society. The Proceedings of the ICCC= N 2015 has already been accepted in the IEEE Conference Publication Program= . Workshop papers will appear in the conference proceedings and will be EI = indexed. Workshop webpage: http://faculty.ist.unomaha.edu/aparakh/mobipst2015.html Special issue announced: Outstanding papers from the workshop will be invit= ed for a special issue on "Challenges and Solutions in Mobile Systems Secur= ity" http://www.journals.elsevier.com/computers-and-electrical-engineering/= call-for-papers/challenges-and-solutions-in-mobile-systems-security/ *********************************************** This workshop aims to bring together the technologists and researchers who = share interest in the area of security, privacy and trust in mobile and wir= eless systems, as well as explore new venues of collaboration. The main pur= pose is to promote discussions of research and relevant activities in the m= odels and designs of secure, privacy-preserving, or trust architectures, pr= otocols, algorithms, services, and applications, as well as analysis on cyb= er threat in mobile and wireless systems. It also aims at increasing the sy= nergy between academic and industry professionals working in this area. We = plan to seek papers that address theoretical, experimental research, and wo= rk in-progress for security, privacy and trust related issues in the contex= t of mobile and wireless systems that include, but are not limited to, the = following, * Cryptography for Mobile and Wireless Systems * Wireless Local Area Networks * Wireless Sensor Networks * Wireless Mesh Networks * Wireless Ad-hoc Networks * Vehicular Networks * Body-area Networks * Cellular Networks (3G, 4G, ...) * WiMAX Networks * Machine to Machine (M2M) Netwroks * Software Defined Networks (SDN) * Social Networks * Smart Grid * RFID-based Systems * Mobile Cloud * Cyber-Physical Systems (CPS) * Internet of Things * Location-based Service Systems * Mobile Healthcare Systems * Smart Building Systems * Big Data Accepted and registered workshop papers will be published in proceedings of= the ICCCN 2015 that has already been accepted in the IEEE Conference Publi= cation Program and EI indexed. Submission link: http://www.easychair.org/ Please choose appropriate track= while submitting your paper. Workshop webpage: http://faculty.ist.unomaha.edu/aparakh/mobipst2015.html Co-chairs Abhishek Parakh and Zhiwei Wang ______________________________________________________________ IEEE Communications Society Tech. Committee on Computer Communications http= ://committees.comsoc.org/tccc/ TCCC Announce: For announcements concerning computer networking and communi= cations. tccc-announce@comsoc.org https://comsoc-listserv.ieee.org/ --_000_DM2PR0701MB7612AC49299DB9A8135449CB11B0DM2PR0701MB761na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 5th International Workshop on Privacy, Sec= urity and Trust in Mobile and Wireless Systems (MobiPST 2015)

Las Vegas, Nevada, USA

August 6, 2015

Important Dates

Paper submission due: March 16, 2015 (ex= tended)

Acceptance notification: April 24, 2015

Camera-ready due: May 8, 2015

Workshop: August 6, 2015

Held in conjunction with ICCCN 2015 (Aug 3-5, 201= 5). ICCCN is technically co-sponsored by the IEEE Communications Society. T= he Proceedings of the ICCCN 2015 has already been accepted in the IEEE Conf= erence Publication Program. Workshop papers will appear in the conference proceedings and will be EI indexed.

Workshop webpage: http://faculty.ist.unomaha.edu/aparakh/mobipst2015.html

Special issue announced: Outstanding papers from = the workshop will be invited for a special issue on "Challenges and So= lutions in Mobile Systems Security" http://www.journals.elsevier.com/computers-and-electrical-engineering/call-= for-papers/challenges-and-solutions-in-mobile-systems-security/

***********************************************

This workshop aims to bring together the technolo= gists and researchers who share interest in the area of security, privacy a= nd trust in mobile and wireless systems, as well as explore new venues of c= ollaboration. The main purpose is to promote discussions of research and relevant activities in the models a= nd designs of secure, privacy-preserving, or trust architectures, protocols= , algorithms, services, and applications, as well as analysis on cyber thre= at in mobile and wireless systems. It also aims at increasing the synergy between academic and industry profe= ssionals working in this area. We plan to seek papers that address theoreti= cal, experimental research, and work in-progress for security, privacy and = trust related issues in the context of mobile and wireless systems that include, but are not limited to, the f= ollowing,

* Cryptography for Mobile and W= ireless Systems

* Wireless Local Area Networks<= o:p>

* Wireless Sensor Networks=

* Wireless Mesh Networks

* Wireless Ad-hoc Networks=

* Vehicular Networks=

* Body-area Networks=

* Cellular Networks (3G, 4G, ..= .)

* WiMAX Networks

* Machine to Machine (M2M) Netw= roks

* Software Defined Networks (SD= N)

* Social Networks

* Smart Grid

* RFID-based Systems=

* Mobile Cloud

* Cyber-Physical Systems (CPS)<= o:p>

* Internet of Things=

* Location-based Service System= s

* Mobile Healthcare Systems

* Smart Building Systems

* Big Data

Accepted and registered workshop papers will be p= ublished in proceedings of the ICCCN 2015 that has already been accepted in= the IEEE Conference Publication Program and EI indexed.

Submission link: http://www.easychair.org/ Please choose appropriate track w= hile submitting your paper.

Workshop webpage: http://faculty.ist.unomaha.edu/aparakh/mobipst2015.html

Co-chairs

Abhishek Parakh and Zhiwei Wang

_________________________________________________= _____________

IEEE Communications Society Tech. Committee on Co= mputer Communications http://committees.comsoc.org= /tccc/

TCCC Announce: For announcements concerning compu= ter networking and communications.

tccc-= announce@comsoc.org

htt= ps://comsoc-listserv.ieee.org/

--_000_DM2PR0701MB7612AC49299DB9A8135449CB11B0DM2PR0701MB761na_-- From nobody Tue Mar 10 06:03:15 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DD01A8862 for ; Tue, 10 Mar 2015 06:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twMQpzCAMlCt for ; Tue, 10 Mar 2015 06:03:06 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAF01A87A8 for ; Tue, 10 Mar 2015 06:03:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CA70F109657 for ; Tue, 10 Mar 2015 14:03:04 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjJtC5rfnwHE for ; Tue, 10 Mar 2015 14:03:04 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id AC1D8109655 for ; Tue, 10 Mar 2015 14:03:02 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.37]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 13:59:15 +0100 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: FPSM work team draft Thread-Index: AdBbMehEOMyhzZDaT3uvew8WpvlIMg== Date: Tue, 10 Mar 2015 12:59:15 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D999EA4E0@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D999EA4E0PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: [DMM] FPSM work team draft X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 13:03:14 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D999EA4E0PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, the FPSM work team published a first draft about a solution and information= model for DMM Forwarding Policy Configuration. The draft should pretty much convey the approach but it's not yet complete. It would be good to receive some feedback, constructive comments and foster= discussion before IETF92 meeting on this mailing list, so we can address a set of items during the meeting. marco A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully su= bmitted by Marco Liebsch and posted to the IETF repository. Name: draft-wt-dmm-fpc-cpdp Revision: 00 Title: Protocol for Forwarding Policy Configuration (F= PC) in DMM Document date: 2015-03-09 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-0= 0.txt Status: https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/ Htmlized: http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00 --_000_69756203DDDDE64E987BC4F70B71A26D999EA4E0PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

the FPSM work team published a first draft about a s= olution and information model for DMM Forwarding Policy Configuration.
The draft should pretty much convey the approach but it’s not yet com= plete.

It would be good to receive some feedback, construct= ive comments and foster discussion before IETF92 meeting
on this mailing list, so we can address a set of items during the meeting.<= o:p>

marco

A new version of I-D, draft-wt-dmm-fpc-cpdp-00.tx= t has been successfully submitted by Marco Liebsch and posted to the IETF r= epository.

Name: &n= bsp; = ; draft-wt-dmm-fpc-cpdp

Revision: &nbs= p; 00

Title: &= nbsp; &nbs= p; Protocol for Forwarding Policy Configuration (FPC) in DMM

Document date: = ; 2015-03-09

Group: &= nbsp; Individual Subm= ission

Pages: &= nbsp; 26

URL: &nb= sp; http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-00.txt

Status: = ; = https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/

Htmlized: http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00

--_000_69756203DDDDE64E987BC4F70B71A26D999EA4E0PALLENEofficehd_-- From nobody Fri Mar 13 05:08:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789721A0419 for ; Fri, 13 Mar 2015 05:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XafiSxK1EI0N for ; Fri, 13 Mar 2015 05:08:17 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4591A0122 for ; Fri, 13 Mar 2015 05:08:15 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 13 Mar 2015 13:08:13 +0100 X-IronPort-AV: E=Sophos;i="5.11,394,1422918000"; d="scan'208,217";a="634970329" Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 13 Mar 2015 13:08:13 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 13 Mar 2015 13:08:12 +0100 From: To: , Date: Fri, 13 Mar 2015 13:08:11 +0100 Thread-Topic: FPSM work team draft Thread-Index: AdBbMehEOMyhzZDaT3uvew8WpvlIMgCUboag Message-ID: <05C81A773E48DD49B181B04BA21A342A2FC0344FCC@HE113484.emea1.cds.t-internal.com> References: <69756203DDDDE64E987BC4F70B71A26D999EA4E0@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D999EA4E0@PALLENE.office.hd> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2FC0344FCCHE113484emea1_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FPSM work team draft X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 12:08:21 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2FC0344FCCHE113484emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Marco and WT, Thanks for all the work! IMO the draft is quite clearly written and covers = many details on messages and attributes for node configuration according to= policies - I didn't find missing ones so far ... ;-) I only have few comments / nits detected so far: P.3: These requirements are met by various transport network components, such as IP switches and routers, though configuration semantics differs between them. =3D> These requirements are met by various transport network components, such as IP switches and routers, though configuration semantics differ between them. P.6: or multiple DPA(s) according =3D> should this be DPN(s) or is the Data-Plane Anchor (DPA) meant? P.7: o Build, modify or delete logical ports as needed =3D> in Fig. 4 only messages for add and delete of ports are listed - modif= y here refers only to the attributes i.e. properties and rules, right? p.10: o PRT_ADD - Issued by a Client to add a new logical port at an Agent, to which traffic can be directed. =3D> AFAIU the port is added at the DPN (where any traffic is directed to),= so should it read: o PRT_ADD - Issued by a Client to an Agent to add a new logical port at= a DPN, to which traffic can be directed. (?) P.11: The Agent receiving such message should delete the rules from its =3D> The Agent receiving such message should delete the rule from its p.13: LMA Control-Plane function (LMA_C), the LMA-C selects a suitable DPN =3D> LMA Control-Plane function (LMA-C), the LMA-C selects a suitable DPN For the Appendix I am too little of a YANG Dr. so I only detected on P.22: container trafic-descriptor { =3D> container traffic-descriptor { Thanks and best regards - and have a nice weekend Dirk From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Dienstag, 10. M=E4rz 2015 13:59 To: dmm@ietf.org Subject: [DMM] FPSM work team draft Folks, the FPSM work team published a first draft about a solution and information= model for DMM Forwarding Policy Configuration. The draft should pretty much convey the approach but it's not yet complete. It would be good to receive some feedback, constructive comments and foster= discussion before IETF92 meeting on this mailing list, so we can address a set of items during the meeting. marco A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully su= bmitted by Marco Liebsch and posted to the IETF repository. Name: draft-wt-dmm-fpc-cpdp Revision: 00 Title: Protocol for Forwarding Policy Configuration (F= PC) in DMM Document date: 2015-03-09 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-0= 0.txt Status: https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/ Htmlized: http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00 --_000_05C81A773E48DD49B181B04BA21A342A2FC0344FCCHE113484emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Marco and WT,

= Thanks for all the work! IMO the draft is qui= te clearly written and covers many details on messages and attributes for n= ode configuration according to policies – I didn’t find missing= ones so far … ;-)

I only have few comments / nits detected so far:

P.3:

These

=A0=A0 requirements are met by various transport network componen= ts, such as

=A0=A0 IP switches and r= outers, though configuration semantics differs

=A0=A0 between them.

=3D>

These

=A0=A0 requ= irements are met by various transport network components, such as

=A0=A0 IP switches and routers, though confi= guration semantics differ

=A0=A0 <= /span>between them.

<= p class=3DMsoNormal style=3D'text-autospace:none'>P.6:

or multiple DPA(s) according

=3D>=A0 should this be DPN(s) or is the Data-Plane Anchor (D= PA) meant?

<= /p>

P.7:

o=A0 Bui= ld, modify or delete logical ports as need= ed

= =3D> in Fig. 4 only messages f= or add and delete of ports are listed – modify here refers only to th= e attributes i.e. properties and rules, right?

p.10:

=A0=A0 o=A0 PRT_ADD - Issued by a Client to add a new logical port at an

=A0= =A0=A0=A0=A0 Agent, to whi= ch traffic can be directed.

=3D> AFAIU the port is added at the= DPN (where any traffic is directed to), so should it read:

=A0=A0 o=A0 PRT_ADD - Issued by a Client to an Agen= t to add a new logical port at a

=A0=A0=A0=A0=A0 DPNThe Agent receiv= ing such message should delete the rules f= rom its

=3D> The Agent receiving such message should delete the= rule from its

p.13:

LMA Control-Plane function (LMA_C), the LMA-C selects a suitable DPN

=3D> LMA Control-Plane function (LMA-C), the LMA-C selects a suitable DPN

For the Append= ix I am too little of a YANG Dr. so I only detected on

P= .22:

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 container trafic-descriptor {

=3D>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= container traffic-descriptor {

<= p class=3DMsoListParagraph>&nb= sp;

Thanks and best regards – and have a nice weekend
Dirk <= /span>

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marc= o Liebsch
Sent: Dienstag, 10. M=E4rz 2015 13:59
To: dmm= @ietf.org
Subject: [DMM] FPSM work team draft

Folks,

= the FPSM work team published a first draft about a solution and information= model for DMM Forwarding Policy Configuration.
The draft should pretty = much convey the approach but it’s not yet complete.

It would be go= od to receive some feedback, constructive comments and foster discussion be= fore IETF92 meeting
on this mailing list, so we can address a set of ite= ms during the meeting.

marco

&nbs= p;

A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully= submitted by Marco Liebsch and posted to the IETF repository.

Name: &nbs= p; draft-wt-dmm-fpc-cpdp

Revision: = ; 00

Title: = ; P= rotocol for Forwarding Policy Configuration (FPC) in DMM

Document date: = ; 2015-03-09

Group: &nb= sp; Individual Submission

Pages: &n= bsp; = ; 26

URL: &nbs= p; http://www.ietf.org/internet-draft= s/draft-wt-dmm-fpc-cpdp-00.txt

St= atus: https://datatracker.ietf.org= /doc/draft-wt-dmm-fpc-cpdp/

Htmli= zed: http://tools.ietf.org/html/draft-wt-dmm-fpc-c= pdp-00

= --_000_05C81A773E48DD49B181B04BA21A342A2FC0344FCCHE113484emea1_-- From nobody Fri Mar 13 06:54:56 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104F21A87A3 for ; Fri, 13 Mar 2015 06:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q8SC0gOuQ7U for ; Fri, 13 Mar 2015 06:54:51 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB39E1A8798 for ; Fri, 13 Mar 2015 06:54:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5DAA81096FC; Fri, 13 Mar 2015 14:54:49 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOuQgfQJhRM7; Fri, 13 Mar 2015 14:54:49 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 3A9591096F9; Fri, 13 Mar 2015 14:54:45 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.208]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Fri, 13 Mar 2015 14:54:24 +0100 From: Marco Liebsch To: "Dirk.von-Hugo@telekom.de" , "dmm@ietf.org" Thread-Topic: FPSM work team draft Thread-Index: AdBbMehEOMyhzZDaT3uvew8WpvlIMgCUboagAARON3A= Date: Fri, 13 Mar 2015 13:54:24 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D99A0728A@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D999EA4E0@PALLENE.office.hd> <05C81A773E48DD49B181B04BA21A342A2FC0344FCC@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2FC0344FCC@HE113484.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99A0728APALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] FPSM work team draft X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 13:54:55 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D99A0728APALLENEofficehd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Dirk, thanks a lot for the feedback and the spotted typos. We'll take them into account for the next revision. Hope we can continue discussion during f2f meeting in Dallas. marco From: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de] Sent: Freitag, 13. M=E4rz 2015 13:08 To: Marco Liebsch; dmm@ietf.org Subject: RE: FPSM work team draft Dear Marco and WT, Thanks for all the work! IMO the draft is quite clearly written and covers = many details on messages and attributes for node configuration according to= policies - I didn't find missing ones so far ... ;-) I only have few comments / nits detected so far: P.3: These requirements are met by various transport network components, such as IP switches and routers, though configuration semantics differs between them. =3D> These requirements are met by various transport network components, such as IP switches and routers, though configuration semantics differ between them. P.6: or multiple DPA(s) according =3D> should this be DPN(s) or is the Data-Plane Anchor (DPA) meant? P.7: o Build, modify or delete logical ports as needed =3D> in Fig. 4 only messages for add and delete of ports are listed - modif= y here refers only to the attributes i.e. properties and rules, right? p.10: o PRT_ADD - Issued by a Client to add a new logical port at an Agent, to which traffic can be directed. =3D> AFAIU the port is added at the DPN (where any traffic is directed to),= so should it read: o PRT_ADD - Issued by a Client to an Agent to add a new logical port at= a DPN, to which traffic can be directed. (?) P.11: The Agent receiving such message should delete the rules from its =3D> The Agent receiving such message should delete the rule from its p.13: LMA Control-Plane function (LMA_C), the LMA-C selects a suitable DPN =3D> LMA Control-Plane function (LMA-C), the LMA-C selects a suitable DPN For the Appendix I am too little of a YANG Dr. so I only detected on P.22: container trafic-descriptor { =3D> container traffic-descriptor { Thanks and best regards - and have a nice weekend Dirk From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Dienstag, 10. M=E4rz 2015 13:59 To: dmm@ietf.org Subject: [DMM] FPSM work team draft Folks, the FPSM work team published a first draft about a solution and information= model for DMM Forwarding Policy Configuration. The draft should pretty much convey the approach but it's not yet complete. It would be good to receive some feedback, constructive comments and foster= discussion before IETF92 meeting on this mailing list, so we can address a set of items during the meeting. marco A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully su= bmitted by Marco Liebsch and posted to the IETF repository. Name: draft-wt-dmm-fpc-cpdp Revision: 00 Title: Protocol for Forwarding Policy Configuration (F= PC) in DMM Document date: 2015-03-09 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-0= 0.txt Status: https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/ Htmlized: http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00 --_000_69756203DDDDE64E987BC4F70B71A26D99A0728APALLENEofficehd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Dirk,

thanks a lot for the f= eedback and the spotted typos.

We’ll take them = into account for the next revision. Hope we can continue
discussion during f2f meeting in Dallas.

marco

From: Dirk.von= -Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de]
Sent: Freitag, 13. M=E4rz 2015 13:08
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPSM work team draft

Dear Marco and WT,

Thanks for all the wor= k! IMO the draft is quite clearly written and covers many details on messag= es and attributes for node configuration according to policies – I di= dn’t find missing ones so far … ;-)

I only have few commen= ts / nits detected so far:

P.3:=

These

requirements are met by various = transport network components, such as

IP switches and routers, though = configuration semantics differs=

betw= een them.

=3D>

These

requirements are met by various = transport network components, such as

IP switches and routers, though = configuration semantics differ

betw= een them.

P.6:

or multiple DPA(s) according

=3D> should this be DPN(s) or is the= Data-Plane Anchor (DPA) meant?

P.7:

o Build, modify or delete logical ports as needed

=3D> in Fig. 4 only messages for add and d= elete of ports are listed – modify here refers only to the attributes= i.e. properties and rules, right?

p.10:

o PRT_ADD - Issued by a Cl= ient to add a new logical port at an

Agent, to which traffic can be directed.

= =3D> AFAIU the port is added at the DPN (where any traffic is directed t= o), so should it read:

o PRT_ADD - Issued by a Cl= ient to an Agent to add a new logical port at a

DPN, to which traffic can be directed. (?)

P.11:

= The Agent receiving such message should delete the rules from its

= =3D> The Agent receiving such message should delete the rule from its

= p.13:

LMA Control-Plane function (LMA_C), the LMA-C selects a suitable DPN

=3D> LMA Control-Plane function (LMA-C), the LMA-C selects a suitable DPN

= For the Appendix I am too little of a YANG Dr. so I only detected on

P.22:

&nb= sp; container trafic-descri= ptor {

=3D> &n= bsp; container traffi= c-descriptor {

Thanks and best regards – and have a nice we= ekend
Dirk

= ;

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Dienstag, 10. M=E4rz 2015 13:59
To: dmm@ietf.org
Subject: [DMM] FPSM work team draft

Folks,

It would be good to receive some feedback, construct= ive comments and foster discussion before IETF92 meeting
on this mailing list, so we can address a set of items during the meeting.<= o:p>

marco

A new version of I-D, draft-wt-dmm-fpc-cpdp-00.tx= t has been successfully submitted by Marco Liebsch and posted to the IETF r= epository.

Name: &n= bsp; = ; draft-wt-dmm-fpc-cpdp

Revision: &nbs= p; 00

Title: &= nbsp; &nbs= p; Protocol for Forwarding Policy Configuration (FPC) in DMM

Document date: = ; 2015-03-09

Group: &= nbsp; Individual Subm= ission

Pages: &= nbsp; 26

URL: &nb= sp; http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-00.txt

Status: = ; = https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/

Htmlized: http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00

--_000_69756203DDDDE64E987BC4F70B71A26D99A0728APALLENEofficehd_-- From nobody Wed Mar 18 02:54:34 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF74A1A8871 for ; Wed, 18 Mar 2015 02:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2OSnBZT3jna for ; Wed, 18 Mar 2015 02:54:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F060E1A8849 for ; Wed, 18 Mar 2015 02:54:30 -0700 (PDT) Received: from [192.168.2.2] ([88.235.141.59]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MUWfN-1Yyo5O1j2x-00RJ5b for ; Wed, 18 Mar 2015 10:54:29 +0100 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_1457839B-E64E-4CF0-BF93-4ECA906403C7" Date: Wed, 18 Mar 2015 11:54:10 +0200 Message-Id: To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:UzLxLBkGuANYdyj8YY8QTwdX/dWUtDa4n8ovwcf4bwVlQLXF4Kt R96XWOVve1ZuFzvjTuQiVUeLc2rDmTt2ssHGDMB7RkxnP9o6AgeqUB0ZFve2qshT5h9O69Z qgh27+8ejubYuc+Cy+629IHir8YPJBRvgOkjL1X2RVt04ZYqSbPG1s8e6lsnqTYxs4lOVDW bh9/9Yo8pP0FgMvKlGg2w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 09:54:32 -0000 --Apple-Mail=_1457839B-E64E-4CF0-BF93-4ECA906403C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello DMM WG members, As you remember, WT#1 came to an agreement to propose the following I-D = as the baseline for the API piece: http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt We'll be proposing its adoption in Dallas. FYI, and here's your chance to voice any input in advance. Cheers, Alper --Apple-Mail=_1457839B-E64E-4CF0-BF93-4ECA906403C7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Hello DMM WG members,

As you remember, WT#1 came to an agreement to propose the following I-D as the baseline for the API piece:

http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt

We'll be proposing its adoption in Dallas.

FYI, and here's your chance to voice any input in advance.

Cheers,

Alper

--Apple-Mail=_1457839B-E64E-4CF0-BF93-4ECA906403C7-- From nobody Thu Mar 19 10:09:15 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DABA1A6EE4 for ; Thu, 19 Mar 2015 10:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujWxA7oIzhsx for ; Thu, 19 Mar 2015 10:09:10 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB901A1BF5 for ; Thu, 19 Mar 2015 10:09:03 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP; 19 Mar 2015 18:09:00 +0100 X-IronPort-AV: E=Sophos;i="5.11,430,1422918000"; d="scan'208,217";a="639011555" Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 19 Mar 2015 18:09:00 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 Mar 2015 18:09:00 +0100 From: To: , Date: Thu, 19 Mar 2015 18:09:00 +0100 Thread-Topic: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 Thread-Index: AdBhYfppCyhZxHdOS0a0JWSWNLl6IgA5lubQ Message-ID: <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2FC04310EDHE113484emea1_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:09:14 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2FC04310EDHE113484emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Alper and co-authors, Thanks for your work! IMO the draft is clearly written and ready for adoption though some questio= ns and comments came to my mind: In the Intro Mobile IP is referenced to both client and Proxy MIP In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], - but in the remaining PMIP functional elements (MAG, LMA) are never mentio= ned ... silly question: so do you propose to apply the solution only to cli= ent MIP based approaches or do you implicitly assume for mobility unaware h= osts/devices that the IP stack on MAG is addressed instead? I suggest to ad= d a clarification in the beginning ... P.4: A sustained IP address may be configured and maintained by using access network anchoring, corresponding network anchoring, or some other solution. I suggest to add a reference here (RFC7429 defining Anchoring Function) or = explain with "allocating to a mobile node an IP address analogous to CoA at FA in MIP by selecting an anchor router = for relaying the traffic" or similar ... P.5: Applications running as servers at a published IP address require a Fixed IP Address. Long-standing applications (e.g., an SSH session) may also require this type of address. Those applications could use a Sustained IP Address, but that can produce sub-optimal results if the mobile host ends up far from the anchor gateway. The latter sentence sounds to me as such sub-optimality will not happen in= case of Fixed IP Address - isn't it even worse when the host already start= s far from the centrally-located Home Network ...? then the IP stack shall fail the associated socket request. =3D> then the IP stack shall fail to fulfil/meet/comply with the associated= socket request. P.6: - Determination of a default address type when an application does not make any explicit indication, whether it already supports the required API or it is just a legacy application. Do you refer here to the below mentioned Socket API-based interface ... [R= FC5014]? Otherwise I suggest to add some explanatory words on the required API. P.7: More than one of these flags may be set on the same socket. In that case, an IP address compliant with any one of them shall be selected. TBD: Disallow this case? Since here we have requirements instead of preferences unavailability of th= e required address type would force configuration of compliant address - bu= t some applications can accept several types (for different planes CP/DP or= with different priority). Question is what would be the additional effort = for forced configuration vs. gain by 'more optimal' performance? My guess: allow, but introduce priority for selection In addition few nits detected: P.2: despite the mobile host chaging its point of attachment within the IP =3D> despite the mobile host changing its point of attachment within the = IP P.3: session continuity and IP address reachability should be be provided =3D> session continuity and IP address reachability should be provided P.4: The mobile host is configures a HoA from a centrally-located Home =3D> The mobile host configures a HoA from a centrally-located Home Thanks! Best Regards Dirk From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Mittwoch, 18. M=E4rz 2015 10:54 To: dmm@ietf.org Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 Hello DMM WG members, As you remember, WT#1 came to an agreement to propose the following I-D as = the baseline for the API piece: http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt We'll be proposing its adoption in Dallas. FYI, and here's your chance to voice any input in advance. Cheers, Alper --_000_05C81A773E48DD49B181B04BA21A342A2FC04310EDHE113484emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Alpe= r and co-authors,

Thanks f= or your work!

IMO the draf= t is clearly written and ready for adoption though some questions and comme= nts came to my mind:

In the Intro Mobile IP = is referenced to both client and Proxy MIP

In = the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],

– but in the rema= ining PMIP functional elements (MAG, LMA) are never mentioned … silly= question: so do you propose to apply the solution only to client MIP based= approaches or do you implicitly assume for mobility unaware hosts/devices = that the IP stack on MAG is addressed instead? I suggest to add a clarifica= tion in the beginning …

P.4:=

=A0=A0 A sustained IP addre= ss may be configured and maintained by using

=A0=A0 access network anchoring, corresponding n= etwork anchoring, or some

=A0=A0 other solution.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>I suggest to add a reference here (RFC7429 defining Anchoring Functio= n) or explain with “allocating to a mobile node an IP

=A0=A0=A0=A0=A0=A0 address analogous to C= oA at FA in MIP by selecting an anchor router for relaying the traffic̶= 1; or similar …

P.5:<= /p>

Applications running as servers at a = published IP address require a

=A0=A0 Fixed IP Address.=A0 Long-standing applications (e.g., a= n SSH session)

=A0= =A0 may also require this type of address.=A0 Tho= se applications could use

=A0=A0 a Sustained IP Address, but that can produce= sub-optimal results if

=A0=A0 the mobi= le host ends up far from the anchor gateway.

The latter sentence sounds to me as such sub-optimality will =A0n= ot happen in case of Fixed IP Address – isn’t it even worse whe= n the host already starts far from the centrally-located Home Network ̷= 0;?

then the IP stack shall fail the associated socket request.=A0 <= o:p>

=3D> then the IP stack shall fail to fulfil/meet/comply with the associated socket requ= est.=A0

P.6:

=A0=A0 - Determination of a default address type when an= application does

= =A0=A0 not make any explicit indication, whether = it already supports the

=A0=A0 required API or it is just a legacy application.

D= o you refer here to the below mentioned =A0Socket API-based interface … [RFC50= 14]?

Otherwise I suggest to add some explanatory words on = the required API.

P.7:

More than one of these flags may be set on the same so= cket.=A0 In that

= =A0=A0 case, an IP address compliant with any one of them shall be selected= .

<= span style=3D'font-size:11.0pt;font-family:"Courier New"'>=A0=A0 TBD: Disallow this case?

Since here we have req= uirements instead of preferences unavailability of the required address typ= e would force configuration of compliant address – but some applicati= ons can accept several types (for different planes CP/DP or with different = priority). Question is what would be the additional effort for forced confi= guration vs. gain by ‘more optimal’ performance?

My gue= ss: allow, but introduce priority for selection

In additi= on few nits detected:

P.2:

=A0=A0 despite the mobile host chaging its point of attachmen= t within the IP

=3D>=A0=A0 despite the mobile host changing its point of attachment within the IP

P.3:

=A0=A0 session continuity= and IP address reachability should be be = provided

=3D>=A0=A0 session continuity and IP address reachability should be pr= ovided

P.4:

= =A0=A0 The mobile host is configures a HoA= from a centrally-located Home

=3D>=A0=A0 The mobile host configures a HoA from= a centrally-located Home

Thanks!

Best Regards
Dirk <= span style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:black;= text-transform:uppercase'>

From: dmm [mailto:dmm-bounces@= ietf.org] On Behalf Of Alper Yegin
Sent: Mittwoch, 18. M= =E4rz 2015 10:54
To: dmm@ietf.org
Subject: [DMM] WG ado= ption for draft-yegin-ondemand-mobility-03

Hello = DMM WG members,

As you remember, WT#1 came to an ag= reement to propose the following I-D as the baseline for the API piece:

http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-0= 3.txt

We'll be proposing its adoption in Dallas.=

<= p class=3DMsoNormal>FYI, and here's your chance to voice any input in advan= ce.

Cheers,

Alper

= --_000_05C81A773E48DD49B181B04BA21A342A2FC04310EDHE113484emea1_-- From nobody Thu Mar 19 11:04:51 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6C91A876B for ; Thu, 19 Mar 2015 11:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1sWT06b4Ym3 for ; Thu, 19 Mar 2015 11:04:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E08E1A8743 for ; Thu, 19 Mar 2015 11:04:47 -0700 (PDT) Received: from [192.168.2.2] ([88.235.141.59]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0MTyy7-1Yysn30F0b-00QhwD; Thu, 19 Mar 2015 19:04:41 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_86FA385D-D185-4E21-A832-799ACAD5768A" From: Alper Yegin In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com> Date: Thu, 19 Mar 2015 20:04:23 +0200 Message-Id: References: <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:nOkZkorrNvdZswa0m295fD+O5YEkYx0lgB8VvJqaVwl4ikElYOX hhY0epmgJ6o6bPtWPwxj8gZGgyx/slIWJffgzdD44I8ydbqsx7uMsroA7XYTfV1w4CWihpO Ksumf5P/lsAwr2f9M3JX7bGTIMBLPofDni7Z6j5M5KRdtc/7Ji8M9msT5nxaE+HIkfmlSW1 2O7vXm6OJ9nEzHqZ5MIvw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:04:50 -0000 --Apple-Mail=_86FA385D-D185-4E21-A832-799ACAD5768A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Dirk, Thanks for the comments. Please see below. On Mar 19, 2015, at 7:09 PM, wrote: > Dear Alper and co-authors, > Thanks for your work! > IMO the draft is clearly written and ready for adoption though some = questions and comments came to my mind: > =20 > In the Intro Mobile IP is referenced to both client and Proxy MIP > In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], > =96 but in the remaining PMIP functional elements (MAG, LMA) are never = mentioned =85 silly question: so do you propose to apply the solution = only to client MIP based approaches or do you implicitly assume for = mobility unaware hosts/devices that the IP stack on MAG is addressed = instead? I suggest to add a clarification in the beginning =85 API applies to both CMIP and PMIP hosts. We don't mention MAG or LMA, as those details are not related to the = "API". > =20 > P.4: > A sustained IP address may be configured and maintained by using > access network anchoring, corresponding network anchoring, or some > other solution. > I suggest to add a reference here (RFC7429 defining Anchoring = Function) or explain with =93allocating to a mobile node an IP > address analogous to CoA at FA in MIP by selecting an anchor = router for relaying the traffic=94 or similar =85 Very good idea, will do. > =20 > P.5: > Applications running as servers at a published IP address require a > Fixed IP Address. Long-standing applications (e.g., an SSH = session) > may also require this type of address. Those applications could = use > a Sustained IP Address, but that can produce sub-optimal results if > the mobile host ends up far from the anchor gateway. > The latter sentence sounds to me as such sub-optimality will not = happen in case of Fixed IP Address =96 isn=92t it even worse when the = host already starts far from the centrally-located Home Network =85? > =20 Right, it can be=85.. But depending on the deployment, a centralized HA = may be in a better position to serve long sessions than an AR at the = edge (because of scalability, and also funneling traffic "in&out" may = not suit the AR well, as its uplink may not be provisioned with enough = capacity).=20 Anyways, we should massage the text, .. will propose something. > then the IP stack shall fail the associated socket request.=20 > =3D> then the IP stack shall fail to fulfil/meet/comply with the = associated socket request.=20 > P.6: > - Determination of a default address type when an application does > not make any explicit indication, whether it already supports the > required API or it is just a legacy application. > Do you refer here to the below mentioned Socket API-based interface =85= [RFC5014]? > Otherwise I suggest to add some explanatory words on the required API. We are referring to the API we are defining in this I-D. Will clarify in = the text. > =20 > P.7: > More than one of these flags may be set on the same socket. In that > case, an IP address compliant with any one of them shall be = selected. > TBD: Disallow this case? > Since here we have requirements instead of preferences unavailability = of the required address type would force configuration of compliant = address =96 but some applications can accept several types (for = different planes CP/DP or with different priority). Question is what = would be the additional effort for forced configuration vs. gain by = =91more optimal=92 performance? > My guess: allow, but introduce priority for selection > =20 >=20 Where should the priority come from? The spec shall state it? > In addition few nits detected: > P.2: > despite the mobile host chaging its point of attachment within the = IP > =3D> despite the mobile host changing its point of attachment within = the IP > P.3: > session continuity and IP address reachability should be be = provided > =3D> session continuity and IP address reachability should be = provided > P.4: > The mobile host is configures a HoA from a centrally-located Home > =3D> The mobile host configures a HoA from a centrally-located Home > Thanks! Thank you! Alper > Best Regards > Dirk > =20 > =20 > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: Mittwoch, 18. M=E4rz 2015 10:54 > To: dmm@ietf.org > Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 > =20 > Hello DMM WG members, > =20 > As you remember, WT#1 came to an agreement to propose the following = I-D as the baseline for the API piece: > =20 > http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt > =20 > We'll be proposing its adoption in Dallas. > =20 > FYI, and here's your chance to voice any input in advance. > =20 > Cheers, > =20 > Alper > =20 > =20 --Apple-Mail=_86FA385D-D185-4E21-A832-799ACAD5768A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Dirk,

Thanks for the = comments.

Please see below.

On Mar 19, = 2015, at 7:09 PM, <Dirk.von-Hugo@telekom.de> = wrote:

Dear = Alper and co-authors,
Thanks for your work!
IMO the draft is clearly written = and ready for adoption though some questions and comments came to my = mind:
In = the Intro Mobile IP is referenced to both client and Proxy = MIP
In the context of Mobile IP = [RFC5563][RFC6275][RFC5213][RFC5944],=96 but in = the remaining PMIP functional elements (MAG, LMA) are never mentioned =85 = silly question: so do you propose to apply the solution only to client = MIP based approaches or do you implicitly assume for mobility unaware = hosts/devices that the IP stack on MAG is addressed instead? I suggest = to add a clarification in the beginning =85

   A sustained IP address = may be configured and maintained by using
   access network anchoring, corresponding network = anchoring, or some
   other = solution.
I = suggest to add a reference here (RFC7429 defining Anchoring Function) or = explain with =93allocating to a mobile node an = IP
Applications running as servers at a = published IP address require a
   Fixed IP Address. Long-standing applications = (e.g., an SSH session)
   may = also require this type of address.     a Sustained IP Address, but that can = produce sub-optimal results if
   the mobile host ends up far from the = anchor gateway.
The = latter sentence sounds to me as such sub-optimality will not = happen in case of Fixed IP Address =96 isn=92t it even worse when the = host already starts far from the centrally-located Home Network = =85?
Anyways, we should = massage the text, .. will propose = something.

then the IP stack shall fail the = associated socket request.
=3D> then the IP stack shall fail  the associated = socket request. P.6:
   - Determination of a = default address type when an application = does
   not make any explicit = indication, whether    required API or it is just a = legacy application.
Do you refer here to the below mentioned =
Otherwise I suggest to add some explanatory = words on the required API.

More than one of these flags may be set on = the same socket. In that
   case, an IP address compliant with any one of them = shall be selected.
   Since here we have = requirements instead of preferences unavailability of the required = address type would force configuration of compliant address =96 but some = applications can accept several types (for different planes CP/DP or = with different priority). Question is what would be the additional = effort for forced configuration vs. gain by =91more optimal=92 = performance?
My guess: allow, but introduce priority for = selection
In addition few nits = detected:
P.2:
   despite the mobile host = chaging its point of attachment within the = IP
   despite the mobile host changing its point of attachment within the = IP
   session continuity and IP = address reachability should  be = provided
   session continuity and IP address reachability = should be provided
P.4:
   The mobile host  configures = a HoA from a centrally-located Home
=3D>   The = mobile host configures a HoA from a centrally-located = Home
Best Regards
Dirk

dmm = [mailto:dmm-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Mittwoch, 18. M=E4rz 2015 = 10:54
To: dmm@ietf.org
Subject: [DMM] WG adoption for = draft-yegin-ondemand-mobility-03

Hello DMM WG = members,
As you remember, WT#1 = came to an agreement to propose the following I-D as the baseline for = the API piece:

We'll be proposing its adoption in = Dallas.
FYI, and here's your = chance to voice any input in advance.

Cheers,

Alper

To: Date: Fri, 20 Mar 2015 11:12:46 +0100 Thread-Topic: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 Thread-Index: AdBiby+TuG1nOvReR8+Ilz8CqgNmvAAhkipQ Message-ID: <05C81A773E48DD49B181B04BA21A342A2FC04EDDA0@HE113484.emea1.cds.t-internal.com> References: <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2FC04EDDA0HE113484emea1_" MIME-Version: 1.0 Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 10:13:06 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2FC04EDDA0HE113484emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alper, Ok, thanks! Regarding More than one of these flags may be set on the same socket. In that case, an IP address compliant with any one of them shall be selected. TBD: Disallow this case? Since here we have requirements instead of preferences unavailability of th= e required address type would force configuration of compliant address - bu= t some applications can accept several types (for different planes CP/DP or= with different priority). Question is what would be the additional effort = for forced configuration vs. gain by 'more optimal' performance? My guess: allow, but introduce priority for selection Where should the priority come from? The spec shall state it? I think the application should be able to decide on the priority, and the s= pec includes a corresponding option with values to pick from (for the time = being only 3-level priority needed ... unless there should be room for late= r update with more refined types) Best Regards Dirk From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Donnerstag, 19. M=E4rz 2015 19:04 To: von Hugo, Dirk Cc: dmm@ietf.org Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 Hello Dirk, Thanks for the comments. Please see below. On Mar 19, 2015, at 7:09 PM, > wrote: Dear Alper and co-authors, Thanks for your work! IMO the draft is clearly written and ready for adoption though some questio= ns and comments came to my mind: In the Intro Mobile IP is referenced to both client and Proxy MIP In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], - but in the remaining PMIP functional elements (MAG, LMA) are never mentio= ned ... silly question: so do you propose to apply the solution only to cli= ent MIP based approaches or do you implicitly assume for mobility unaware h= osts/devices that the IP stack on MAG is addressed instead? I suggest to ad= d a clarification in the beginning ... API applies to both CMIP and PMIP hosts. We don't mention MAG or LMA, as those details are not related to the "API". P.4: A sustained IP address may be configured and maintained by using access network anchoring, corresponding network anchoring, or some other solution. I suggest to add a reference here (RFC7429 defining Anchoring Function) or = explain with "allocating to a mobile node an IP address analogous to CoA at FA in MIP by selecting an anchor router = for relaying the traffic" or similar ... Very good idea, will do. P.5: Applications running as servers at a published IP address require a Fixed IP Address. Long-standing applications (e.g., an SSH session) may also require this type of address. Those applications could use a Sustained IP Address, but that can produce sub-optimal results if the mobile host ends up far from the anchor gateway. The latter sentence sounds to me as such sub-optimality will not happen in= case of Fixed IP Address - isn't it even worse when the host already start= s far from the centrally-located Home Network ...? Right, it can be..... But depending on the deployment, a centralized HA may= be in a better position to serve long sessions than an AR at the edge (bec= ause of scalability, and also funneling traffic "in&out" may not suit the A= R well, as its uplink may not be provisioned with enough capacity). Anyways, we should massage the text, .. will propose something. then the IP stack shall fail the associated socket request. =3D> then the IP stack shall fail to fulfil/meet/comply with the associated= socket request. P.6: - Determination of a default address type when an application does not make any explicit indication, whether it already supports the required API or it is just a legacy application. Do you refer here to the below mentioned Socket API-based interface ... [R= FC5014]? Otherwise I suggest to add some explanatory words on the required API. We are referring to the API we are defining in this I-D. Will clarify in th= e text. P.7: More than one of these flags may be set on the same socket. In that case, an IP address compliant with any one of them shall be selected. TBD: Disallow this case? Since here we have requirements instead of preferences unavailability of th= e required address type would force configuration of compliant address - bu= t some applications can accept several types (for different planes CP/DP or= with different priority). Question is what would be the additional effort = for forced configuration vs. gain by 'more optimal' performance? My guess: allow, but introduce priority for selection Where should the priority come from? The spec shall state it? In addition few nits detected: P.2: despite the mobile host chaging its point of attachment within the IP =3D> despite the mobile host changing its point of attachment within the = IP P.3: session continuity and IP address reachability should be be provided =3D> session continuity and IP address reachability should be provided P.4: The mobile host is configures a HoA from a centrally-located Home =3D> The mobile host configures a HoA from a centrally-located Home Thanks! Thank you! Alper Best Regards Dirk From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Mittwoch, 18. M=E4rz 2015 10:54 To: dmm@ietf.org Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 Hello DMM WG members, As you remember, WT#1 came to an agreement to propose the following I-D as = the baseline for the API piece: http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt We'll be proposing its adoption in Dallas. FYI, and here's your chance to voice any input in advance. Cheers, Alper --_000_05C81A773E48DD49B181B04BA21A342A2FC04EDDA0HE113484emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Alper,=
Ok, thanks!
Regarding
Mor= e than one of these flags may be set on the same socket. In that
   case, an IP address compliant with any o= ne of them shall be selected.
   TBD: Di= sallow this case?
Since here we have requirements instead of prefe= rences unavailability of the required address type would force configuratio= n of compliant address – but some applications can accept several typ= es (for different planes CP/DP or with different priority). Question is wha= t would be the additional effort for forced configuration vs. gain by ̵= 6;more optimal’ performance?
My guess: allow, but introduce priorit= y for selection

Where should the priority come from? The spec shall state it?

I think the applicati= on should be able to decide on the priority, and the spec includes a corres= ponding option with values to pick from (for the time being only 3-level pr= iority needed … unless there should be room for later update with mor= e refined types)
&nbs= p;
Best Regards
Dirk

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Donn= erstag, 19. M=E4rz 2015 19:04
To: von Hugo, Dirk
Cc: dm= m@ietf.org
Subject: Re: [DMM] WG adoption for draft-yegin-ondeman= d-mobility-03
&n= bsp;
Hello Dirk,

Thanks fo= r the comments.
Please see be= low.

On Mar 19, 2015, at 7:09 PM, <Dirk.von-Hugo@telekom.de> wrote:<= /o:p>

Dear Alper and co-authors,
Thanks for your work!
IMO the draft is clearly written a= nd ready for adoption though some questions and comments came to my mind:

In the Intro Mobile IP i= s referenced to both client and Proxy MIP
<= p class=3DMsoNormal>In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],
– but in the r= emaining PMIP functional elements (MAG, LMA) are never mentioned … si= lly question: so do you propose to apply the solution only to client MIP ba= sed approaches or do you implicitly assume for mobility unaware hosts/devic= es that the IP stack on MAG is addressed instead? I suggest to add a clarif= ication in the beginning …

API a= pplies to both CMIP and PMIP hosts.
We don't mention MAG or LMA, as those details are not related to the= "API".
=

P.4:
   A sustained IP address may = be configured and maintained by using
=    access network anchoring, corresponding network anchoring, or = some
   other solution.
I suggest to add a = reference here (RFC7429 defining Anchoring Function) or explain with “= ;allocating to a mobile node an IP
       address analogous = to CoA at FA in MIP by selecting an anchor router for relaying the traffic&= #8221; or similar …

Very good id= ea, will do.

<= div>
P.5:
A= pplications running as servers at a published IP address require a
   Fixed IP Address. Long-stan= ding applications (e.g., an SSH session)
&= nbsp; a Sustained IP Address, but that can produce sub-optimal results if
   the mobile host = ends up far from the anchor gateway.
The latter sentence sounds to me as such sub-optimality will &= nbsp;not happen in case of Fixed IP Address – isn’t it even wor= se when the host already starts far from the centrally-located Home Network= …?
&nbs= p;

Right, it can be….. But depen= ding on the deployment, a centralized HA may be in a better position to ser= ve long sessions than an AR at the edge (because of scalability, and also f= unneling traffic "in&out" may not suit the AR well, as its up= link may not be provisioned with enough capacity).
Anyways, we should massage the text, .. will pr= opose something.
<= /o:p>

then the= IP stack shall fail the associated socket request. =
=3D> then the IP stack shall fail to fulfil/meet/comp= ly with the associat= ed socket request.
P.6:
&= nbsp; - Determination of a default address type when an application d= oes
   not make any explicit= indication, whether it already supports the
   required API or it is just a legacy application.
Do you refer here = to the below mentioned Socket API-based interface … [RFC5014]?
Otherw= ise I suggest to add some explanatory words on the required API.

We are referring to the API we are = defining in this I-D. Will clarify in the text.

=

P.7:
More than one of these f= lags may be set on the same socket. In that
   case, an IP address compliant with any one of them= shall be selected.
   TBD: D= isallow this case?
Since here we have requirements instead o= f preferences unavailability of the required address type would force confi= guration of compliant address – but some applications can accept seve= ral types (for different planes CP/DP or with different priority). Question= is what would be the additional effort for forced configuration vs. gain b= y ‘more optimal’ performance?
My guess: allow, but introduce = priority for selection

<= o:p>

Where should the priority come = from? The spec shall state it?

In addition few nits detect= ed:
P.2:
   despite the mobile h= ost chaging its point of attachment within the IP
=3D>   despite the mobile host = changing its point of attachment within th= e IP
P.3:
   session conti= nuity and IP address reachability should be be provided
=3D>   session continuity and IP address reachability= should be provided
P.4:
&nb= sp; The mobile host is configures a HoA from a centrally-located Home
=3D>   The mobile host configures a HoA= from a centrally-located Home
Thanks!
<= /div>

Thank you!
&nbs= p;
Alper
=

Best Regards
Dirk

<= /div>
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Mittwoch, 18. M=E4rz 2015 10:54
To:= dmm@ietf.org
Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
=
Hello DMM WG members,

As you remember, WT#1 came to an ag= reement to propose the following I-D as the baseline for the API piece:

=
http://www.ietf.org/id/draft-yegin-d= mm-ondemand-mobility-03.txt

We'= ll be proposing its adoption in Dallas.

FYI, and here's your chance to voice any input in advance.

=
Cheers,

Alper

&= nbsp;
= ;
= --_000_05C81A773E48DD49B181B04BA21A342A2FC04EDDA0HE113484emea1_-- From nobody Fri Mar 20 06:54:12 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2A1B2DBA for ; Fri, 20 Mar 2015 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-qkMmYptmc7 for ; Fri, 20 Mar 2015 06:54:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2B21B2DB2 for ; Fri, 20 Mar 2015 06:54:05 -0700 (PDT) Received: from [10.119.24.3] ([173.245.80.44]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MbQwc-1YpWHh2sAG-00Iof0; Fri, 20 Mar 2015 14:54:00 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_631C609D-0BEB-45EC-90A4-5FB349680C73" From: Alper Yegin In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2FC04EDDA0@HE113484.emea1.cds.t-internal.com> Date: Fri, 20 Mar 2015 15:53:54 +0200 Message-Id: References: <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com> <05C81A773E48DD49B181B04BA21A342A2FC04EDDA0@HE113484.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:VrSyEXC3CpHylk2l5HXO3yVlMmiWOSJ/4nscjm5M9iVCs4wUzCE Ln6SsHpUoVgZ2QmQOzcLarzvAQKOSIa1AZcz8AzLi1JlVadf8AWmDu/r1/EUlTJtROiUDZV 9p22zTb0d3ptwpvAUyC7taccPkPx7BJsHBFde8C4btSdfpRbt5j0UiLrEeetLQFCJz7QJyR Y6ng0OhZhB9Rem/EBWjPw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 13:54:09 -0000 --Apple-Mail=_631C609D-0BEB-45EC-90A4-5FB349680C73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dirk, I think we need to look at some example scenarios to see how common this = case would be. If this additional logic is used rarely, then it may not be worth = burdening the API with it. Alper On Mar 20, 2015, at 12:12 PM, wrote: > Hi Alper, > Ok, thanks! > Regarding > More than one of these flags may be set on the same socket. In that > case, an IP address compliant with any one of them shall be = selected. > TBD: Disallow this case? > Since here we have requirements instead of preferences unavailability = of the required address type would force configuration of compliant = address =96 but some applications can accept several types (for = different planes CP/DP or with different priority). Question is what = would be the additional effort for forced configuration vs. gain by = =91more optimal=92 performance? > My guess: allow, but introduce priority for selection > =20 > =20 > =20 > Where should the priority come from? The spec shall state it? >=20 > I think the application should be able to decide on the priority, and = the spec includes a corresponding option with values to pick from (for = the time being only 3-level priority needed =85 unless there should be = room for later update with more refined types) > =20 > Best Regards > Dirk > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Donnerstag, 19. M=E4rz 2015 19:04 > To: von Hugo, Dirk > Cc: dmm@ietf.org > Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 > =20 > Hello Dirk, > =20 > Thanks for the comments. > Please see below. > =20 > On Mar 19, 2015, at 7:09 PM, wrote: >=20 >=20 > Dear Alper and co-authors, > Thanks for your work! > IMO the draft is clearly written and ready for adoption though some = questions and comments came to my mind: > =20 > In the Intro Mobile IP is referenced to both client and Proxy MIP > In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], > =96 but in the remaining PMIP functional elements (MAG, LMA) are never = mentioned =85 silly question: so do you propose to apply the solution = only to client MIP based approaches or do you implicitly assume for = mobility unaware hosts/devices that the IP stack on MAG is addressed = instead? I suggest to add a clarification in the beginning =85 > =20 > API applies to both CMIP and PMIP hosts. > We don't mention MAG or LMA, as those details are not related to the = "API". > =20 > =20 >=20 >=20 > =20 > P.4: > A sustained IP address may be configured and maintained by using > access network anchoring, corresponding network anchoring, or some > other solution. > I suggest to add a reference here (RFC7429 defining Anchoring = Function) or explain with =93allocating to a mobile node an IP > address analogous to CoA at FA in MIP by selecting an anchor = router for relaying the traffic=94 or similar =85 > =20 > Very good idea, will do. >=20 >=20 > =20 > P.5: > Applications running as servers at a published IP address require a > Fixed IP Address. Long-standing applications (e.g., an SSH = session) > may also require this type of address. Those applications could = use > a Sustained IP Address, but that can produce sub-optimal results if > the mobile host ends up far from the anchor gateway. > The latter sentence sounds to me as such sub-optimality will not = happen in case of Fixed IP Address =96 isn=92t it even worse when the = host already starts far from the centrally-located Home Network =85? > =20 > =20 > Right, it can be=85.. But depending on the deployment, a centralized = HA may be in a better position to serve long sessions than an AR at the = edge (because of scalability, and also funneling traffic "in&out" may = not suit the AR well, as its uplink may not be provisioned with enough = capacity).=20 > Anyways, we should massage the text, .. will propose something. > =20 > =20 > then the IP stack shall fail the associated socket request.=20 > =3D> then the IP stack shall fail to fulfil/meet/comply with the = associated socket request.=20 > P.6: > - Determination of a default address type when an application does > not make any explicit indication, whether it already supports the > required API or it is just a legacy application. > Do you refer here to the below mentioned Socket API-based interface =85= [RFC5014]? > Otherwise I suggest to add some explanatory words on the required API. > =20 > We are referring to the API we are defining in this I-D. Will clarify = in the text. > =20 >=20 >=20 > =20 > P.7: > More than one of these flags may be set on the same socket. In that > case, an IP address compliant with any one of them shall be = selected. > TBD: Disallow this case? > Since here we have requirements instead of preferences unavailability = of the required address type would force configuration of compliant = address =96 but some applications can accept several types (for = different planes CP/DP or with different priority). Question is what = would be the additional effort for forced configuration vs. gain by = =91more optimal=92 performance? > My guess: allow, but introduce priority for selection > =20 > =20 > =20 > Where should the priority come from? The spec shall state it? >=20 >=20 > In addition few nits detected: > P.2: > despite the mobile host chaging its point of attachment within the = IP > =3D> despite the mobile host changing its point of attachment within = the IP > P.3: > session continuity and IP address reachability should be be = provided > =3D> session continuity and IP address reachability should be = provided > P.4: > The mobile host is configures a HoA from a centrally-located Home > =3D> The mobile host configures a HoA from a centrally-located Home > Thanks! > =20 > Thank you! > =20 > Alper > =20 >=20 >=20 > Best Regards > Dirk > =20 > =20 > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: Mittwoch, 18. M=E4rz 2015 10:54 > To: dmm@ietf.org > Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 > =20 > Hello DMM WG members, > =20 > As you remember, WT#1 came to an agreement to propose the following = I-D as the baseline for the API piece: > =20 > http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt > =20 > We'll be proposing its adoption in Dallas. > =20 > FYI, and here's your chance to voice any input in advance. > =20 > Cheers, > =20 > Alper > =20 > =20 --Apple-Mail=_631C609D-0BEB-45EC-90A4-5FB349680C73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Dirk,

I think we need to look = at some example scenarios to see how common this case would = be.
If this additional logic is used rarely, then it may not = be worth burdening the API with = it.

Alper

On Mar 20, 2015, at 12:12 PM, <Dirk.von-Hugo@telekom.de> = wrote:

Hi = Alper,
Ok, = thanks!
More than one of these flags may be = set on the same socket. In that
   case, an IP address compliant with any one of them = shall be selected.
   Since here we have = requirements instead of preferences unavailability of the required = address type would force configuration of compliant address =96 but some = applications can accept several types (for different planes CP/DP or = with different priority). Question is what would be the additional = effort for forced configuration vs. gain by =91more optimal=92 = performance?
My guess: allow, but introduce priority for = selection

Where should the priority come = from? The spec shall state it?

I think the = application should be able to decide on the priority, and the spec = includes a corresponding option with values to pick from (for the time = being only 3-level priority needed =85 unless there should be room for = later update with more refined types)
Best Regards
Dirk
Alper = Yegin [mailto:alper.yegin@yegin.org]
Sent: Donnerstag, 19. M=E4rz 2015 = 19:04
To: von = Hugo, Dirk
Cc: dmm@ietf.org
Subject: Re: [DMM] WG adoption for = draft-yegin-ondemand-mobility-03

Hello = Dirk,
Thanks for the = comments.
Please see = below.
On Mar 19, 2015, at 7:09 = PM, <Dirk.von-Hugo@telekom.de> = wrote:
Dear = Alper and co-authors,
Thanks for your = work!
IMO = the draft is clearly written and ready for adoption though some = questions and comments came to my = mind:
In the Intro Mobile IP is referenced to both client = and Proxy MIP
In the context = of Mobile IP = [RFC5563][RFC6275][RFC5213][RFC5944],
=96 but in the remaining PMIP = functional elements (MAG, LMA) are never mentioned =85 silly question: = so do you propose to apply the solution only to client MIP based = approaches or do you implicitly assume for mobility unaware = hosts/devices that the IP stack on MAG is addressed instead? I suggest = to add a clarification in the beginning = =85
API applies to both CMIP = and PMIP hosts.
We don't = mention MAG or LMA, as those details are not related to the = "API".
P.4:
   A sustained IP address may be configured and = maintained by using
   access network anchoring, corresponding network = anchoring, or some
   other = solution.
I suggest to add a reference here (RFC7429 defining = Anchoring Function) or explain with =93allocating to a mobile node an = IP
Very good idea, will = do.
P.5:
Applications running as servers at a published IP address = require a
   = Fixed IP Address. Long-standing applications (e.g., an SSH = session)
   may = also require this type of address.  .
The latter sentence sounds to me as such = sub-optimality will not happen in case of Fixed IP Address =96 = isn=92t it even worse when the host already starts far from the = centrally-located Home Network =85?
Right, it can be=85.. But = depending on the deployment, a centralized HA may be in a better = position to serve long sessions than an AR at the edge (because of = scalability, and also funneling traffic "in&out" may not suit the AR = well, as its uplink may not be provisioned with enough = capacity).
Anyways, we = should massage the text, .. will propose = something.
then the IP stack shall fail the = associated socket request.
=3D> then the IP stack shall fail  the associated = socket request.
   - Determination of a = default address type when an application = does
   not make any explicit = indication, whether    required API or it is just a = legacy application.
Do you refer here to the below mentioned = Otherwise I suggest to add = some explanatory words on the required = API.

We are referring to the API we are defining in this = I-D. Will clarify in the text.

More than one of these flags may be = set on the same socket. In = that
   case, an IP address = compliant with any one of them shall be = selected.
TBD: Disallow this = case?
Since here we have requirements instead of = preferences unavailability of the required address type would force = configuration of compliant address =96 but some applications can accept = several types (for different planes CP/DP or with different priority). = Question is what would be the additional effort for forced configuration = vs. gain by =91more optimal=92 performance?
My guess: allow, but = introduce priority for selection

Where should = the priority come from? The spec shall state = it?

In addition few nits = detected:
P.2:
   = despite the mobile host chaging its point of attachment within the = IP
=3D>   despite the mobile host = changing its point of attachment = within the IP
P.3:
   session continuity and IP address reachability = should be be = provided
=3D>   session continuity and IP address = reachability should be provided
   The mobile host  configures = a HoA from a centrally-located = Home
   The mobile host configures a HoA from a = centrally-located Home
Thank = you!

Best = Regards
Dirk

dmm [ On Behalf Of Alper = Yegin
Sent: Mittwoch, 18. M=E4rz 2015 = 10:54
To: dmm@ietf.org
Subject: [DMM] WG adoption for = draft-yegin-ondemand-mobility-03
=

Hello DMM WG = members,
As you = remember, WT#1 came to an agreement to propose the following I-D as the = baseline for the API piece:

We'll be = proposing its adoption in = Dallas.

FYI, and = here's your chance to voice any input in = advance.

Message-ID: X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55118fe5_62a5d5bd_a9e" Archived-At: Subject: [DMM] IETF92 agenda X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:25:17 -0000 --55118fe5_62a5d5bd_a9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Please note that the chairs have updated the agenda for Thursday session: https://www.ietf.org/proceedings/92/agenda/agenda-92-dmm Thanks, -- Dapeng Liu --55118fe5_62a5d5bd_a9e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Please note that the chairs have updated the agenda = for Thursday session: https://www.ietf.org/proceedings/92/agenda/agenda-92-dmm

Thanks,
--
=
Dapeng Liu

--55118fe5_62a5d5bd_a9e-- From lyleb551144@gmail.com Wed Mar 25 05:40:51 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7531A8A79 for ; Wed, 25 Mar 2015 05:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKSRwmHekpIk for ; Wed, 25 Mar 2015 05:40:50 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F6E1ACEC5 for ; Wed, 25 Mar 2015 05:39:03 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so17985376obc.2 for ; Wed, 25 Mar 2015 05:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dM2TRdNA1hVPLNfyEWYLc7OSj3hRWgksoBa4srcdyis=; b=GeU3a18Rq943Ad2CobpJ0eEE8muCtnlrfaxRhAqjEpXxkWWgR21Ey1PivrMtzwTF9i rApP67fkWiZV5UkWCioqWdvtlUqONkfWy70FiXu3fI3VGCaudl4fCeXdiAJrdwcW73h+ 7pFjPNUdaGzXcVoNMftRsWyfz2VM8gJ1uTacTsgwQTcn171RzIvryk0q88NxnRgEv0LQ uPMNklkNlLd2pKpqY1UF1a4wMA9gpve7CKgAsrqQpLOYvifIdCD42YjEpssbNzmv7PhV +NC1t5Usnv/mK3GeLXvl2OMSkMrnvjmi1fFeayDOc7rhVpqjmxMhciapd0t3tITCpCPb VYBw== MIME-Version: 1.0 X-Received: by 10.60.63.39 with SMTP id d7mr7290250oes.72.1427287142764; Wed, 25 Mar 2015 05:39:02 -0700 (PDT) Received: by 10.60.161.109 with HTTP; Wed, 25 Mar 2015 05:39:02 -0700 (PDT) Date: Wed, 25 Mar 2015 07:39:02 -0500 Message-ID: From: Lyle Bertz To: dmm@ietf.org Content-Type: multipart/alternative; boundary=001a11c21ff023140c05121c2fa2 Archived-At: Subject: [DMM] Developer Usage of Socket Types as described in draft-yegin-dmm-ondemand-mobility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 12:42:42 -0000 --001a11c21ff023140c05121c2fa2 Content-Type: text/plain; charset=UTF-8 A question was raised during the dmm session regarding whether a developer would use the Socket options specified in the draft or even be aware of them. Mobile developers (Android and other OSes) are quite aware of not only the network type but also the 'features' that can be requested. Using Android as an example - The basic networking tutorial exposes the developer to ways to check connections and their types ( http://developer.android.com/training/basics/network-ops/managing.html). The developer is also made aware of permissions requests and features of the connection type during this and many other 'Getting Started' tutorials one may find on the Internet. The Android API permits a developer to request a feature using the requestNetwork( request, operation) method. The method is described as "Request a network to satisfy a set of NetworkCapabilities " which can be found here - http://developer.android.com/reference/android/net/NetworkCapabilities.html Although many of these capabilities are merely network types you'll note a few are sub-features or 'qualities' such as NOT_RESTRICTED (general use) or NOT_METERED. It is reasonable to assume that for Android the options specified in the draft would be enumerated here if the developer wishes to manipulate it at the application level or pass as socket options in the Android Socket API which likely, in turn, calls the ConnectivityManager first and, upon success, attempts to open the Socket. Other operating systems in the mobile space have similar features. If security is an issue the OS provider can use their respective application permissions frameworks to restrict the application's request. I think the OSes have very good methods to accommodate the options as described in the draft and developers have a good idea of how to or discover how to use them. Lyle --001a11c21ff023140c05121c2fa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A question was raised during the dmm sess= ion regarding whether a developer would use the Socket options specified in= the draft or even be aware of them.=C2=A0 Mobile developers (Android and o= ther OSes) are quite aware of not only the network type but also the 'f= eatures' that can be requested. =C2=A0=C2=A0

Using A= ndroid as an example -=C2=A0
The basic networking tutorial expose= s the developer to ways to check connections and their types (http://developer.android.com/training/basics/network-ops/manag= ing.html).=C2=A0 The developer is also made aware of permissions reques= ts and features of the connection type during this and many other 'Gett= ing Started' tutorials one may find on the Internet.

The Android API permits a developer to request a feature using the r= equestNetwork( request, operation) method.=C2=A0 The method is described as= "Request a network to satisfy a = set of=C2=A0NetworkCapabilities=C2=A0" which can be found here = -=C2=A0http://developer.android.com/referenc= e/android/net/NetworkCapabilities.html

Althoug= h many of these capabilities are merely network types you'll note a few= are sub-features or 'qualities' such as NOT_RESTRICTED (general us= e) or NOT_METERED. =C2=A0

It is reasonable to assu= me that for Android the options specified in the draft would be enumerated = here if the developer wishes to manipulate it at the application level or p= ass as socket options in the Android Socket API which likely, in turn, call= s the ConnectivityManager first and, upon success, attempts to open the Soc= ket. =C2=A0 Other operating systems in the mobile space have similar featur= es. =C2=A0=C2=A0

If security is an issue the OS pr= ovider can use their respective application permissions frameworks to restr= ict the application's request.

I think the OSe= s have very good methods to accommodate the options as described in the dra= ft and developers have a good idea of how to or discover how to use them.

Lyle

--001a11c21ff023140c05121c2fa2-- From nobody Wed Mar 25 12:03:00 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15641A8999 for ; Wed, 25 Mar 2015 12:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMJoDoN_WBgb for ; Wed, 25 Mar 2015 12:02:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EC81B2B63 for ; Wed, 25 Mar 2015 12:02:38 -0700 (PDT) Received: from [10.119.8.8] ([67.230.161.148]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MThig-1Z1LeW2HXk-00QU0s; Wed, 25 Mar 2015 20:02:36 +0100 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2015 21:02:35 +0200 Message-Id: To: Dapeng Liu , Alexandru Petrescu Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:ucfA0XzJBG1n5t7H2M39+9TnVXpYkjWUuB31hL0GMV7CKD1eC9X 1exkIAFasdQ+spJ/7ZZI0X1tqC01xKKUTF+/CktjSDQ1XwqI/OKVmwgC+asrnYqueNg04bK BqoBaMuFrFjxStZ4WSu9Syw8fZOuPeP+a+3pw7h/G3J2MLpYEl/Iqo9PdCylP7i/onzoRYo b+LsYgs3Xyt3O1vky0cyg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: [DMM] DMM API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:02:58 -0000 Hello Dapeng and Alex, I hope you had a chance to digest our responses to your comments and = questions about the API work. If you have any remaining issues, please let us know over the email at = your earliest convenience. It'd be good if you can articulate them in detail. Thanks. Alper From nobody Wed Mar 25 14:02:05 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7731A1B34 for ; Wed, 25 Mar 2015 14:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnYDoic4AmIK for ; Wed, 25 Mar 2015 14:02:02 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26A21A8A9E for ; Wed, 25 Mar 2015 14:01:56 -0700 (PDT) Received: by pdnc3 with SMTP id c3so40338630pdn.0 for ; Wed, 25 Mar 2015 14:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=NWw6WTUxXcYTUI0alHDtT+e+VQhePA1VjKmYur2JADc=; b=y/0fL9tL76ZlHsFcI1GAvptmZOucDDtxjaE65K/QMH/iZClVoFRQ20VNRovqUPBZuc OInW/hAWKV53rsK0r+3x+vxiZWsB2+ssCd0N9tDP++Vg0wk9oOXBC2O0QI40dBbmTRIS nFciT/mvzkGy2OZrUfNcGdM9QVkRREcFJ8PtaL4fYdLBOXz5FrDVMYo+n2eNSq36ksLi /IoXTpJHTCIRoarvBhUfAfGAgYsiPzcD5zRuaOVWF0FB1jczPfrTehA0lW3+N29ANCXq nmg/HC9nNnfmuaujXQ/a7nRCuMinoV625FoZFWMdlxCIn9y+TbhVDWd+ojMa2+meMJLD eDVg== X-Received: by 10.66.141.109 with SMTP id rn13mr20223041pab.113.1427317316586; Wed, 25 Mar 2015 14:01:56 -0700 (PDT) Received: from [31.133.166.135] (dhcp-a687.meeting.ietf.org. [31.133.166.135]) by mx.google.com with ESMTPSA id jy9sm3344394pbc.31.2015.03.25.14.01.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 14:01:52 -0700 (PDT) Date: Wed, 25 Mar 2015 16:01:45 -0500 From: Dapeng Liu To: Alper Yegin Message-ID: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> In-Reply-To: References: X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55132239_2357e574_a9e" Archived-At: Cc: dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:02:04 -0000 --55132239_2357e574_a9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Alper, =20 I still have the following comments: 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in the = draft: =E2=80=9C- =46ixed IP Address This is what standard Mobile IP provides with a Home Address (HoA). The m= obile host is configures a HoA from a centrally-located Home Network. Bot= h IP session continuity and IP address reachability are provided to the m= obile host with the help of a router in the Home Network (Home Agent, HA)= . This router acts as an anchor for the IP =20 address of the mobile host.=E2=80=9D =20 If this is equal to HoA, then R=46C5014 already cover that. We do not nee= d to repeat it here with another name. 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D in = the draft: =22- Sustained IP Address This type of IP address provides IP session con= tinuity but not IP address reachability. It is achieved by ensuring that = the IP address used at the beginning of the session remains usable despit= e the movement of the mobile host. The IP address may change after the te= rmination of the IP session(s), therefore it does not exhibit persistence= . =22 =20 There is no clear dividing line between fixed IP address and sustained IP= address. Whether the IP address is used for reachability is not determin= ed by the IP address itself. =46or example, even when the MN get a HoA, a= fter it moves to another location of the network, it may decide to releas= e current HoA and get another HoA, in this case the =22fixed IP address=22= becomes a =22sustained IP address=22. =46urther more, the reachability normally is implemented by domain name i= nstead of IP address. =46or example, we reach =E2=80=9CGoogle=E2=80=9D by= its domain name, never by it=E2=80=99s server=E2=80=99s IP address. =20 Using temporary private IP address we can also achieve the goal of =E2=80= =9Creachability=E2=80=9D. =46or example, using dynamic DNS, as shown in = http://hsk.oray.com/ , it can provide reachability even the host get a p= rivate IP address. 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D: =E2=80=9C- Nomadic IP Address This type of IP address provides neither IP session continuity nor IP add= ress reachability. The IP address is obtained from the serving IP gateway= and it is not maintained across gateway changes. In other words, the IP = address may be released and replaced by a new IP address when the IP gate= way changes due to the movement of the mobile =20 host.=E2=80=9D Seems this IP address is the IP address that we normally used in most cas= es. If this is the case, why we need a new name for it=3F -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A > Hello Dapeng and Alex, > =20 > I hope you had a chance to digest our responses to your comments and qu= estions about the API work. > If you have any remaining issues, please let us know over the email at = your earliest convenience. > It'd be good if you can articulate them in detail. > =20 > =20 > Thanks. > =20 > Alper =20 --55132239_2357e574_a9e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello Alper,

I still have the following comm= ents:

1. Regarding the definition of =E2=80=9Cfi= xed IP address=E2=80=9D in the draft:

=E2= =80=9C- =46ixed IP Address
This is what standard Mobile IP provides with a Ho= me Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP&nb= sp;
address of the mobile host.=E2=80=9D

If this is equal to HoA, then R=46C5014 already cover tha= t. We do not need to repeat it here with another name.

2. Regarding the definition of =E2=80=9Csustained IP address=E2=80= =9D in the draft:

=22- Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. =22

There is no clear dividing line between fixed I= P address and sustained IP address. Whether the IP address is used for re= achability is not determined by the IP address itself. =46or example, eve= n when the MN get a HoA, after it moves to another location of the networ= k, it may decide to release current HoA and get another HoA, in this case= the =22fixed IP address=22 becomes a =22sustained IP address=22.

=46urther more, the reachability normally is implemente= d by domain name instead of IP address. =46or example, we reach =E2=80=9C= Google=E2=80=9D by its domain name, never by it=E2=80=99s server=E2=80=99= s IP address.

Using temporary private= IP address we can also achieve the goal of =E2=80=9Creachability=E2=80=9D= . =46or example, using dynamic DNS, as shown in http://hsk.oray.com/ , it can provide re= achability even the host get a private IP address.

3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:

=E2=80=9C- Nomadic IP Address
This type of IP addre= ss provides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile&= nbsp;
host.=E2=80=9D

Seems this= IP address is the IP address that we normally used in most cases. If thi= s is the case, why we need a new name for it=3F

=
--
Dapeng Liu

=20
=E5=9C=A8 2015=E5=B9=B4= 3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D= =882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your c= omments and questions about the API work.
If you have any remai= ning issues, please let us know over the email at your earliest convenien= ce.
It'd be good if you can articulate them in detail.

Thanks.

Alper
=20 =20 =20 =20 =20

--55132239_2357e574_a9e-- From nobody Wed Mar 25 14:43:55 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CFA1A03C7 for ; Wed, 25 Mar 2015 14:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC7LtVqUek3l for ; Wed, 25 Mar 2015 14:43:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3657A1A00D8 for ; Wed, 25 Mar 2015 14:43:52 -0700 (PDT) Received: from [10.119.8.5] ([81.17.21.68]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0Lkyod-1ZB2qu09I5-00ad73; Wed, 25 Mar 2015 22:43:50 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_CE699CFF-3090-4B1A-8220-7EB1758B3AF8" From: Alper Yegin In-Reply-To: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> Date: Wed, 25 Mar 2015 23:43:46 +0200 Message-Id: References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> To: Dapeng Liu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:sU7rgA7Mo+Q/L1Lfoyr36e6YtT8SHcSwo/n7wbsNuNdpCF6I6ef yV0xzChdAipaVpmyr3Lyky7g2a+QyT90aIz3TByBNjAad33peq8E7t2Q96jMz1ojtaNDqem n5U5l3xOQeNO2JP/Dbk6DVwCqqRUNoRcG7gE7k/uku3vSftV/0yOb9Eu+ixCcFG+WUikqZ+ skoONsEsfMNFyMtpEeG9Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:43:54 -0000 --Apple-Mail=_CE699CFF-3090-4B1A-8220-7EB1758B3AF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Dapeng, On Mar 25, 2015, at 11:01 PM, Dapeng Liu wrote: > Hello Alper, >=20 > I still have the following comments: >=20 > 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in = the draft: >=20 > =E2=80=9C- Fixed IP Address > This is what standard Mobile IP provides with a Home Address (HoA). > The mobile host is configures a HoA from a centrally-located Home > Network. Both IP session continuity and IP address reachability = are > provided to the mobile host with the help of a router in the Home > Network (Home Agent, HA). This router acts as an anchor for the IP=20= > address of the mobile host.=E2=80=9D=20 >=20 > If this is equal to HoA, then RFC5014 already cover that. We do not = need to repeat it here with another name. >=20 This is not equal to "HoA". This is equal to "HoA permanently allocated on a HA in the core network" (as opposed to "HoA temporarily allocated on a HA in the access = network") > 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D = in the draft: >=20 > "- Sustained IP Address >=20 > This type of IP address provides IP session continuity but not IP > address reachability. It is achieved by ensuring that the IP = address > used at the beginning of the session remains usable despite the > movement of the mobile host. The IP address may change after the > termination of the IP session(s), therefore it does not exhibit > persistence. > " > There is no clear dividing line between fixed IP address and sustained = IP address. Whether the IP address is used for reachability is not = determined by the IP address itself. For example, even when the MN get a = HoA, after it moves to another location of the network, it may decide to = release current HoA and get another HoA, in this case the "fixed IP = address" becomes a "sustained IP address". >=20 If the IP stack on the host releases the IP address, then of course it's = not a "fixed IP address".=20 Please see the definitions of these terms in the I-D. > Further more, the reachability normally is implemented by domain name = instead of IP address. For example, we reach =E2=80=9CGoogle=E2=80=9D by = its domain name, never by it=E2=80=99s server=E2=80=99s IP address.=20 >=20 > Using temporary private IP address we can also achieve the goal of = =E2=80=9Creachability=E2=80=9D. For example, using dynamic DNS, as shown = in http://hsk.oray.com/ , it can provide reachability even the host = get a private IP address. >=20 You had said this before, and I had explained it. Nevertheless, let me recap: You cannot ensure an ongoing IP flow continues w/o interruption if you = simply rely on dynamic DNS. Ongoing flows break even if you update the = DNS. Furthermore, even if you ignore the ongoing flows, also note that DNS = clients have a cache, hence a dynamic DNS update cannot be = instantaneously reflected on the hosts.=20 So, you cannot provide full mobility solution by relying on dynamic DNS. > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D: >=20 > =E2=80=9C- Nomadic IP Address > This type of IP address provides neither IP session continuity nor = IP > address reachability. The IP address is obtained from the serving = IP > gateway and it is not maintained across gateway changes. In other > words, the IP address may be released and replaced by a new IP > address when the IP gateway changes due to the movement of the = mobile=20 > host.=E2=80=9D >=20 > Seems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for it? >=20 If you don't name it, how would you refer to it in this context? Alper >=20 > --=20 > Dapeng Liu >=20 > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper = Yegin =E5=86=99=E9=81=93=EF=BC=9A >=20 >> Hello Dapeng and Alex, >>=20 >> I hope you had a chance to digest our responses to your comments and = questions about the API work. >> If you have any remaining issues, please let us know over the email = at your earliest convenience. >> It'd be good if you can articulate them in detail. >>=20 >>=20 >> Thanks. >>=20 >> Alper >=20 --Apple-Mail=_CE699CFF-3090-4B1A-8220-7EB1758B3AF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello = Dapeng,

On Mar 25, 2015, at 11:01 PM, = Dapeng Liu wrote:

Hello Alper,

I still have the following = comments:

1. Regarding the definition of = =E2=80=9Cfixed IP address=E2=80=9D in the = draft:

=E2=80=9C- Fixed IP = Address
This is what standard Mobile IP provides with a Home Address = (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the = IP
address of the mobile = host.=E2=80=9D

If this is equal to = HoA, then RFC5014 already cover that. We do not need to repeat it here = with another = name.

= This is not equal to "HoA".
This is equal to "HoA permanently = allocated on a HA in the core network"
(as opposed to "HoA = temporarily allocated on a HA in the access = network")

2. = Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D in = the draft:

"- Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "

There is no clear dividing line between fixed = IP address and sustained IP address. Whether the IP address is used for = reachability is not determined by the IP address itself. For example, = even when the MN get a HoA, after it moves to another location of the = network, it may decide to release current HoA and get another HoA, in = this case the "fixed IP address" becomes a "sustained IP = address".

If = the IP stack on the host releases the IP address, then of course it's = not a "fixed IP address".
Please see the definitions of = these terms in the I-D.

Further more, the reachability normally is = implemented by domain name instead of IP address. For example, we reach = =E2=80=9CGoogle=E2=80=9D by its domain name, never by it=E2=80=99s = server=E2=80=99s IP = address.

Using temporary private IP address we can = also achieve the goal of =E2=80=9Creachability=E2=80=9D. For example, = using dynamic DNS, as shown in http://hsk.oray.com/ , it can = provide reachability even the host get a private IP = address.

You = had said this before, and I had explained it.
Nevertheless, = let me recap:
You cannot ensure an ongoing IP flow continues = w/o interruption if you simply rely on dynamic DNS. Ongoing flows break = even if you update the DNS.
Furthermore, even if you ignore = the ongoing flows, also note that DNS clients have a cache, hence a = dynamic DNS update cannot be instantaneously reflected on the = hosts.
So, you cannot provide full mobility solution by = relying on dynamic DNS.

3. Regarding the definition of =E2=80=9Cnomadic = IP address=E2=80=9D:

=E2=80=9C- Nomadic IP = Address
This type of IP address provides neither IP session continuity = nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the = mobile
host.=E2=80=9D

Se= ems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for = it?

<= div>If you don't name it, how would you refer to it in this = context?

Alper

--
Dapeng = Liu

=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper = Yegin =E5=86=99=E9=81=93=EF=BC=9A

Hello Dapeng and = Alex,

I hope you had a chance to digest our = responses to your comments and questions about the API = work.
If you have any remaining issues, please let us know = over the email at your earliest convenience.
It'd be good if = you can articulate them in = detail.

Thanks.

Alper
=20 =20 =20 =20
=20

= --Apple-Mail=_CE699CFF-3090-4B1A-8220-7EB1758B3AF8-- From nobody Wed Mar 25 15:27:28 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0CA1A1A72 for ; Wed, 25 Mar 2015 15:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSMj6L9mXL1w for ; Wed, 25 Mar 2015 15:27:24 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0E21A1A94 for ; Wed, 25 Mar 2015 15:27:22 -0700 (PDT) Received: by wgs2 with SMTP id 2so44265552wgs.1 for ; Wed, 25 Mar 2015 15:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=dpyUaiK3T+6yOzsvVUnU0TRXxywgOpSSWurAVos/syo=; b=qIFpnfbwacY6Y5538yDXMD7NratS+V4jcqxLkymXx/iNumHoRt0iaCRKUbpO1u/cqi Y5/Gxj9Ed98HCy3s2uIs9sHaEHAEXevdnGs/CmSEPjU758NHUodf1liFHXaccAaHVWwR bkCs28hDO6QNtKVPEpsbUcuHudiVLIu+r9QoNJIwlsCOTQ3zdDt7k4KNgZaw0dzep0c4 v0/k4Z+aqCqQv1ZSGc5t3VHZPyKrdEQ1FwyrNglPs7q1eCbRwcBULA//et9Ja/mixDwT n0udzA2vYoPsiYXOoHX5Drq6QJZTm4t1VoHSIfDLtaxPYePRn8kW8AjHpp47G4FdeMlD zW7g== X-Received: by 10.180.85.97 with SMTP id g1mr41353182wiz.17.1427322440945; Wed, 25 Mar 2015 15:27:20 -0700 (PDT) Received: from [2001:67c:370:160::] ([2001:67c:370:160:f0fd:13ae:b935:34e8]) by mx.google.com with ESMTPSA id gj16sm6176921wic.24.2015.03.25.15.27.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 15:27:20 -0700 (PDT) Date: Wed, 25 Mar 2015 17:27:16 -0500 From: Dapeng Liu To: Alper Yegin Message-ID: <16D77D43C73143B9A76C580ECBA39A87@gmail.com> In-Reply-To: References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55133644_69dffc_a9e" Archived-At: Cc: dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 22:27:26 -0000 --55133644_69dffc_a9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C=E4=B8=8B=E5=8D=884:43=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A > Hello Dapeng, > =20 > =20 > On Mar 25, 2015, at 11:01 PM, Dapeng Liu wrote: > > Hello Alper, =20 > > =20 > > I still have the following comments: > > =20 > > 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in = the draft: > > =20 > > =E2=80=9C- =46ixed IP Address > > This is what standard Mobile IP provides with a Home Address (HoA). T= he mobile host is configures a HoA from a centrally-located Home Network.= Both IP session continuity and IP address reachability are provided to t= he mobile host with the help of a router in the Home Network (Home Agent,= HA). This router acts as an anchor for the IP =20 > > address of the mobile host.=E2=80=9D =20 > > =20 > > If this is equal to HoA, then R=46C5014 already cover that. We do not= need to repeat it here with another name. > > =20 > =20 > =20 > This is not equal to =22HoA=22. > This is equal to =22HoA permanently allocated on a HA in the core netwo= rk=22 > (as opposed to =22HoA temporarily allocated on a HA in the access netwo= rk=22) > =20 The draft says: =E2=80=9CThis is what standard Mobile IP provides with a = Home Address (HoA)...=E2=80=9D If it is not equal to HoA, need clarifica= tion in the draft. > =20 > =20 > > 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D= in the draft: > > =20 > > =22- Sustained IP Address This type of IP address provides IP session= continuity but not IP address reachability. It is achieved by ensuring t= hat the IP address used at the beginning of the session remains usable de= spite the movement of the mobile host. The IP address may change after th= e termination of the IP session(s), therefore it does not exhibit persist= ence. =22 =20 > > There is no clear dividing line between fixed IP address and sustaine= d IP address. Whether the IP address is used for reachability is not dete= rmined by the IP address itself. =46or example, even when the MN get a Ho= A, after it moves to another location of the network, it may decide to re= lease current HoA and get another HoA, in this case the =22fixed IP addre= ss=22 becomes a =22sustained IP address=22. > > =20 > =20 > If the IP stack on the host releases the IP address, then of course it'= s not a =22fixed IP address=22. =20 > Please see the definitions of these terms in the I-D. > =20 > =20 > > =46urther more, the reachability normally is implemented by domain na= me instead of IP address. =46or example, we reach =E2=80=9CGoogle=E2=80=9D= by its domain name, never by it=E2=80=99s server=E2=80=99s IP address. =20 > > =20 > > Using temporary private IP address we can also achieve the goal of =E2= =80=9Creachability=E2=80=9D. =46or example, using dynamic DNS, as shown i= n http://hsk.oray.com/ , it can provide reachability even the host get = a private IP address. > > =20 > =20 > You had said this before, and I had explained it. > Nevertheless, let me recap: > You cannot ensure an ongoing IP flow continues w/o interruption if you = simply rely on dynamic DNS. Ongoing flows break even if you update the DN= S. > =46urthermore, even if you ignore the ongoing flows, also note that DNS= clients have a cache, hence a dynamic DNS update cannot be instantaneous= ly reflected on the hosts. =20 > So, you cannot provide full mobility solution by relying on dynamic DNS= . > =20 > =20 The point here is =E2=80=9Creachability=E2=80=9D instead of =E2=80=9Cmobi= lity=E2=80=9D. =20 =46urther more, even mobile IP may lost some packet during handover. =20 > > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D: > > =20 > > =E2=80=9C- Nomadic IP Address > > This type of IP address provides neither IP session continuity nor IP= address reachability. The IP address is obtained from the serving IP gat= eway and it is not maintained across gateway changes. In other words, the= IP address may be released and replaced by a new IP address when the IP = gateway changes due to the movement of the mobile =20 > > host.=E2=80=9D > > =20 > > Seems this IP address is the IP address that we normally used in most= cases. If this is the case, why we need a new name for it=3F > > =20 > =20 > =20 > If you don't name it, how would you refer to it in this context=3F If the justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D a= nd =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not necessar= y need a new name for normal IP address. Dapeng =20 > =20 > =20 > Alper > =20 > =20 > > =20 > > -- =20 > > Dapeng Liu > > =20 > > =20 > > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8= =89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93= =EF=BC=9A > > =20 > > > Hello Dapeng and Alex, > > > =20 > > > I hope you had a chance to digest our responses to your comments an= d questions about the API work. > > > If you have any remaining issues, please let us know over the email= at your earliest convenience. > > > It'd be good if you can articulate them in detail. > > > =20 > > > =20 > > > Thanks. > > > =20 > > > Alper =20 > > =20 > =20 --55133644_69dffc_a9e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=20
=E5=9C=A8 2015=E5=B9=B4= 3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D= =884:43=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

Hello Dapeng,

= On Mar 25, 2015, at 11:01 PM, Dapeng Liu wrote:

Hello Alper,

I still have the following comm= ents:

1. Regarding the definition of =E2=80=9Cfi= xed IP address=E2=80=9D in the draft:

=E2= =80=9C- =46ixed IP Address
= This is what standard Mobile IP provides with a Home Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP&nb= sp;
address of the mobile host.=E2=80=9D

If this is equal to HoA, then R=46C5014 already cover tha= t. We do not need to repeat it here with another name.

This is not equal= to =22HoA=22.
This is equal to =22HoA permanently allocated on= a HA in the core network=22
(as opposed to =22HoA temporarily = allocated on a HA in the access network=22)

The draft says: =E2=80=9CThis is what standard M= obile IP provides with a Home Address (HoA)...=E2=80=9D If i= t is not equal to HoA, need clarification in the draft.

2. Regarding the definition of =E2=80=9C= sustained IP address=E2=80=9D in the draft:

=22- Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. =22

There is no clear dividing line between fixed I= P address and sustained IP address. Whether the IP address is used for re= achability is not determined by the IP address itself. =46or example, eve= n when the MN get a HoA, after it moves to another location of the networ= k, it may decide to release current HoA and get another HoA, in this case= the =22fixed IP address=22 becomes a =22sustained IP address=22.

If the IP stack= on the host releases the IP address, then of course it's not a =22fixed = IP address=22.
Please see the definitions of these terms = in the I-D.

=46urther more, the reachability normally is implemented by= domain name instead of IP address. =46or example, we reach =E2=80=9CGoog= le=E2=80=9D by its domain name, never by it=E2=80=99s server=E2=80=99s IP= address.

Using temporary = private IP address we can also achieve the goal of =E2=80=9Creachability=E2= =80=9D. =46or example, using dynamic DNS, as shown in http://hsk.oray.com/ , it can prov= ide reachability even the host get a private IP address.

You had said this before, and = I had explained it.
Nevertheless, let me recap:
You c= annot ensure an ongoing IP flow continues w/o interruption if you simply = rely on dynamic DNS. Ongoing flows break even if you update the DNS.
=46urthermore, even if you ignore the ongoing flows, also note that= DNS clients have a cache, hence a dynamic DNS update cannot be instantan= eously reflected on the hosts.
So, you cannot provide ful= l mobility solution by relying on dynamic DNS.

The point here is =E2=80=9Creachabilit= y=E2=80=9D instead of =E2=80=9Cmobility=E2=80=9D.
=46urth= er more, even mobile IP may lost some packet during handover.
=
3. Regarding the definition of =E2=80=9Cnom= adic IP address=E2=80=9D:

=E2=80=9C- Nomadic IP Addr= ess
This type of IP a= ddress provides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile&= nbsp;
host.=E2=80=9D

Seems this= IP address is the IP address that we normally used in most cases. If thi= s is the case, why we need a new name for it=3F

If you don't name it, ho= w would you refer to it in this context=3F
If the justification of naming IP address as =E2=80=9Cfixed I= P=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may = not necessary need a new name for normal IP address.

=

Dapeng

Alper

--
Dapeng Liu

=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98= =9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin = =E5=86=99=E9=81=93=EF=BC=9A

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your c= omments and questions about the API work.
If you have any remai= ning issues, please let us know over the email at your earliest convenien= ce.
It'd be good if you can articulate them in detail.

Thanks.

Alper
=20 =20 =20 =20

=20 =20 =20 =20 =20

--55133644_69dffc_a9e-- From nobody Wed Mar 25 16:18:40 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DAE1A1B8F for ; Wed, 25 Mar 2015 16:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nit_mJBsz64k for ; Wed, 25 Mar 2015 16:18:35 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302031A6F39 for ; Wed, 25 Mar 2015 16:18:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2PNIWjv002461; Thu, 26 Mar 2015 00:18:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EDEAF2035DB; Thu, 26 Mar 2015 00:19:16 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DDF7D200BEB; Thu, 26 Mar 2015 00:19:16 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.99]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2PNISeI012277; Thu, 26 Mar 2015 00:18:32 +0100 Message-ID: <55134244.602@gmail.com> Date: Wed, 25 Mar 2015 18:18:28 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alper Yegin , Dapeng Liu References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:18:38 -0000 Hi, Alper, Sorry for interfering but I have a few points where I agree with Dapeng. Le 25/03/2015 16:43, Alper Yegin a écrit : > Hello Dapeng, > > > On Mar 25, 2015, at 11:01 PM, Dapeng Liu wrote: > >> Hello Alper, >> >> I still have the following comments: >> >> 1. Regarding the definition of “fixed IP address” in the draft: >> >> “- Fixed IP Address >> This is what standard Mobile IP provides with a Home Address (HoA). >> The mobile host is configures a HoA from a centrally-located Home >> Network. Both IP session continuity and IP address reachability are >> provided to the mobile host with the help of a router in the Home >> Network (Home Agent, HA). This router acts as an anchor for the IP >> address of the mobile host.” >> >> If this is equal to HoA, then RFC5014 already cover that. We do not >> need to repeat it here with another name. >> > > > This is not equal to "HoA". > This is equal to "HoA permanently allocated on a HA in the core network" > (as opposed to "HoA temporarily allocated on a HA in the access network") So that's a HoA, and RFC5014 already covers that, right? >> 2. Regarding the definition of “sustained IP address” in the draft: >> >> "- Sustained IP Address >> >> This type of IP address provides IP session continuity but not IP >> address reachability. It is achieved by ensuring that the IP address >> used at the beginning of the session remains usable despite the >> movement of the mobile host. The IP address may change after the >> termination of the IP session(s), therefore it does not exhibit >> persistence. >> " >> There is no clear dividing line between fixed IP address and sustained >> IP address. Whether the IP address is used for reachability is not >> determined by the IP address itself. For example, even when the MN get >> a HoA, after it moves to another location of the network, it may >> decide to release current HoA and get another HoA, in this case the >> "fixed IP address" becomes a "sustained IP address". >> > > If the IP stack on the host releases the IP address, then of course it's > not a "fixed IP address". > Please see the definitions of these terms in the I-D. > > >> Further more, the reachability normally is implemented by domain name >> instead of IP address. For example, we reach “Google” by its domain >> name, never by it’s server’s IP address. >> >> Using temporary private IP address we can also achieve the goal of >> “reachability”. For example, using dynamic DNS, as shown in >> http://hsk.oray.com/ , it can provide reachability even the host get >> a private IP address. >> > > You had said this before, and I had explained it. > Nevertheless, let me recap: > You cannot ensure an ongoing IP flow continues w/o interruption if you > simply rely on dynamic DNS. Ongoing flows break even if you update the DNS. But Dapeng talks about reachability, not about session continuity. In that sense he's right, no? (DNS updates ensure reachability upon address change). Even I would go as far as to say that _some_ application flows will resist to changes in that IP address and get restarted with the new address if that DNS update process was performed. This is because the concept of 'flow' is very much ambiguous. Very rarely a read in packet dump can show 'flows' as we talk commonly about them in the DMM discussions. It is for this reason that there is no option in Wireshark that groups packets in 'flows', like a mail reader would group messages into 'conversations' or 'threads'. It is for this reason too that firewall rules trying to be smart and identify 'flows' before blocking them very often fail, even if we do Deep Packet Inspection. People always find ways to 'drill' through these rules. > Furthermore, even if you ignore the ongoing flows, also note that DNS > clients have a cache, hence a dynamic DNS update cannot be > instantaneously reflected on the hosts. I can agree to that. I guess though there may be forced updates on these caches, or that the timers can be configured shorter in domains supporting mobility. > So, you cannot provide full mobility solution by relying on dynamic DNS. We dont know what full mobility is, and DNS updates is a good tool to provide reachability and session continuity, in some cases. Alex > > >> 3. Regarding the definition of “nomadic IP address”: >> >> “- Nomadic IP Address >> This type of IP address provides neither IP session continuity nor IP >> address reachability. The IP address is obtained from the serving IP >> gateway and it is not maintained across gateway changes. In other >> words, the IP address may be released and replaced by a new IP >> address when the IP gateway changes due to the movement of the mobile >> host.” >> >> Seems this IP address is the IP address that we normally used in most >> cases. If this is the case, why we need a new name for it? >> > > > If you don't name it, how would you refer to it in this context? > > > Alper > > >> >> -- >> Dapeng Liu >> >> 在 2015年3月25日星期三，下午2:02，Alper Yegin 写道： >> >>> Hello Dapeng and Alex, >>> >>> I hope you had a chance to digest our responses to your comments and >>> questions about the API work. >>> If you have any remaining issues, please let us know over the email >>> at your earliest convenience. >>> It'd be good if you can articulate them in detail. >>> >>> >>> Thanks. >>> >>> Alper >> > From nobody Wed Mar 25 16:27:54 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C8C1AC3B0 for ; Wed, 25 Mar 2015 16:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBWDogXsnnJF for ; Wed, 25 Mar 2015 16:27:49 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016F51ACCDC for ; Wed, 25 Mar 2015 16:27:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2PNRg0u007722 for ; Thu, 26 Mar 2015 00:27:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E376E2035DB for ; Thu, 26 Mar 2015 00:28:26 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CF98820350B for ; Thu, 26 Mar 2015 00:28:26 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.99]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2PNRdwO028603 for ; Thu, 26 Mar 2015 00:27:42 +0100 Message-ID: <5513446A.4060307@gmail.com> Date: Wed, 25 Mar 2015 18:27:38 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] SUSTAINED, NOMADIC, FIXED: existing kinds, lifetimes X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:27:51 -0000 Alper, authors of draft-yegin-dmm-ondemand-mobility-03, I would like to ask how do you see the relationships between other kinds of addresses (HoW, CoA, LL, GUA, ULA, NATTed, privacy, multicast) and the SUSTAINED, NOMADIC, FIXED addresses. In addition, I think there may be a relationship with the lifetimes of the addresses generated by existing address configuration mechanisms. Alex From nobody Wed Mar 25 16:41:43 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832761A8A43 for ; Wed, 25 Mar 2015 16:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce4OoVTu5E_j for ; Wed, 25 Mar 2015 16:41:40 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A281A899C for ; Wed, 25 Mar 2015 16:41:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2PNfbCB010428 for ; Thu, 26 Mar 2015 00:41:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2AA620373B for ; Thu, 26 Mar 2015 00:42:21 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A9DFF20373A for ; Thu, 26 Mar 2015 00:42:21 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.99]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2PNfYEI029105 for ; Thu, 26 Mar 2015 00:41:37 +0100 Message-ID: <551347AE.6030208@gmail.com> Date: Wed, 25 Mar 2015 18:41:34 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] clarifications on draft-chan-dmm-distributed-mobility-anchoring-01 - and 2 questions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:41:41 -0000 Hello, During yesterday's DMM meeting there were several clarification questions on draft-chan-dmm-distributed-mobility-anchoring-01. I talked this morning to Anthony, and I think there is a case. The IP Anchor - we all know what is. It typically anchors the HoA of Mobile IPv6 protocol. It is a Border Router or a Home Agent, or so. The "Session IP" Anchor is new and deserves clarification. The "Session IP Anchor" is actually a "Session Anchor". If a session is identified by an IP address (i.e. a brief web browsing session to the IP address of a web server) then that's the Care-of Address; that is a "Session IP Anchor" and it is typically an Access Router where that IP address (CoA) is topologically correct. On another hand, Sessions can be identified by something else than an IP address. For example, a TCP session is identified by a quad IPsrc/IPdst/srcport/srcdst. The anchor of this session may be something else than the Access Router. It could be for example an Application Layer Gateway (ALG) like for example a HTTP proxy. So we end up with two anchors: the "Address Anchor" and the "HTTP Proxy Anchor". A session can be identified by a SIP identifier as well (SIP - Session Initiation Protocol). In that case the "Session Anchor" would be a SIP Server. Following this presumably locator-identifier split, we can think about this session to be for HIP, for SHIM6 and even DNS. Each time there is a different Session Anchor. And this draft proposes to offer a double-level mobility which allows changing the IP anchor or the session anchor without interrupting the sessions. That said, I wonder whether the IP Anchor of this draft supports SUSTAINED, NOMADIC, FIXED kinds of addresses. I also wonder whether the Alper's API draft supports SUSTAINED, NOMADIC, FIXED attributes of IP addresses in the DNS. Alex From nobody Wed Mar 25 16:54:27 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8E01A8AF6 for ; Wed, 25 Mar 2015 16:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7_zzpMOaaN1 for ; Wed, 25 Mar 2015 16:54:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC4C1A8892 for ; Wed, 25 Mar 2015 16:54:24 -0700 (PDT) Received: from [10.119.16.2] ([81.17.21.69]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0LnzHq-1Z841O3sBk-00g293; Thu, 26 Mar 2015 00:54:23 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E9050FF-A42C-43B3-A4A5-30AE9C727F17" From: Alper Yegin In-Reply-To: <16D77D43C73143B9A76C580ECBA39A87@gmail.com> Date: Thu, 26 Mar 2015 01:54:19 +0200 Message-Id: References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> To: Dapeng Liu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:bZN/mG9xHXpRDJ1GKB4I+gXZ8V0c1+3tvMq9ItuubuAxf5zomPX HsDDp88Rx99TmLq91AOUWu3TZCsOuZsWzMt357KMnEjYaO/ZPLBPFXelC2+V2+0kkTw/4Zv kCdT8RJNF+E29vlTVtz2OhAs1uyci56/H0654AC/2IwS7ZCRUW/EpIJJkVTbqv4GNRskGWa 1SukV6JGRMBlsIxahBi6Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:54:27 -0000 --Apple-Mail=_4E9050FF-A42C-43B3-A4A5-30AE9C727F17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>>=20 >>> 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in = the draft: >>>=20 >>> =E2=80=9C- Fixed IP Address >>> This is what standard Mobile IP provides with a Home Address = (HoA). >>> The mobile host is configures a HoA from a centrally-located Home >>> Network. Both IP session continuity and IP address reachability = are >>> provided to the mobile host with the help of a router in the Home >>> Network (Home Agent, HA). This router acts as an anchor for the = IP=20 >>> address of the mobile host.=E2=80=9D=20 >>>=20 >>> If this is equal to HoA, then RFC5014 already cover that. We do not = need to repeat it here with another name. >>>=20 >>=20 >>=20 >> This is not equal to "HoA". >> This is equal to "HoA permanently allocated on a HA in the core = network" >> (as opposed to "HoA temporarily allocated on a HA in the access = network") >>=20 > The draft says: =E2=80=9CThis is what standard Mobile IP provides with = a Home Address (HoA)...=E2=80=9D If it is not equal to HoA, need = clarification in the draft. >>=20 Draft says "This is what standard Mobile IP provides with a Home Address = (HoA). The mobile host is configures a HoA from a centrally-located Home = Network. " If this is not clear enough, we can certainly elaborate more on that in = the I-D. >>> 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D = in the draft: >>>=20 >>> "- Sustained IP Address >>>=20 >>> This type of IP address provides IP session continuity but not IP >>> address reachability. It is achieved by ensuring that the IP = address >>> used at the beginning of the session remains usable despite the >>> movement of the mobile host. The IP address may change after the >>> termination of the IP session(s), therefore it does not exhibit >>> persistence. >>> " >>> There is no clear dividing line between fixed IP address and = sustained IP address. Whether the IP address is used for reachability is = not determined by the IP address itself. For example, even when the MN = get a HoA, after it moves to another location of the network, it may = decide to release current HoA and get another HoA, in this case the = "fixed IP address" becomes a "sustained IP address". >>>=20 >>=20 >> If the IP stack on the host releases the IP address, then of course = it's not a "fixed IP address".=20 >> Please see the definitions of these terms in the I-D. >>=20 >>=20 >>> Further more, the reachability normally is implemented by domain = name instead of IP address. For example, we reach =E2=80=9CGoogle=E2=80=9D= by its domain name, never by it=E2=80=99s server=E2=80=99s IP address.=20= >>>=20 >>> Using temporary private IP address we can also achieve the goal of = =E2=80=9Creachability=E2=80=9D. For example, using dynamic DNS, as shown = in http://hsk.oray.com/ , it can provide reachability even the host = get a private IP address. >>>=20 >>=20 >> You had said this before, and I had explained it. >> Nevertheless, let me recap: >> You cannot ensure an ongoing IP flow continues w/o interruption if = you simply rely on dynamic DNS. Ongoing flows break even if you update = the DNS. >> Furthermore, even if you ignore the ongoing flows, also note that DNS = clients have a cache, hence a dynamic DNS update cannot be = instantaneously reflected on the hosts.=20 >> So, you cannot provide full mobility solution by relying on dynamic = DNS. >>=20 >>=20 > The point here is =E2=80=9Creachability=E2=80=9D instead of = =E2=80=9Cmobility=E2=80=9D.=20 > Further more, even mobile IP may lost some packet during handover.=20 Not sure if this point has any impact on the discussion. >>> 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D: >>>=20 >>> =E2=80=9C- Nomadic IP Address >>> This type of IP address provides neither IP session continuity = nor IP >>> address reachability. The IP address is obtained from the = serving IP >>> gateway and it is not maintained across gateway changes. In = other >>> words, the IP address may be released and replaced by a new IP >>> address when the IP gateway changes due to the movement of the = mobile=20 >>> host.=E2=80=9D >>>=20 >>> Seems this IP address is the IP address that we normally used in = most cases. If this is the case, why we need a new name for it? >>>=20 >>=20 >>=20 >> If you don't name it, how would you refer to it in this context? > If the justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D = and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not = necessary need a new name for normal IP address. >=20 I and the WT#1 believe that justification is valid. If you believe otherwise, please elaborate. Alper >=20 > Dapeng=20 >>=20 >>=20 >> Alper >>=20 >>=20 >>>=20 >>> --=20 >>> Dapeng Liu >>>=20 >>> =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper = Yegin =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>>> Hello Dapeng and Alex, >>>>=20 >>>> I hope you had a chance to digest our responses to your comments = and questions about the API work. >>>> If you have any remaining issues, please let us know over the email = at your earliest convenience. >>>> It'd be good if you can articulate them in detail. >>>>=20 >>>>=20 >>>> Thanks. >>>>=20 >>>> Alper >>>=20 >>=20 >=20 --Apple-Mail=_4E9050FF-A42C-43B3-A4A5-30AE9C727F17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

1. Regarding the definition of = =E2=80=9Cfixed IP address=E2=80=9D in the = draft:

=E2=80=9C- Fixed IP = Address
This is = what standard Mobile IP provides with a Home Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the = IP
address of the mobile = host.=E2=80=9D

If this is equal to = HoA, then RFC5014 already cover that. We do not need to repeat it here = with another = name.

This is not equal to "HoA".
This is equal to "HoA = permanently allocated on a HA in the core network"
(as opposed = to "HoA temporarily allocated on a HA in the access = network")

The = draft says: =E2=80=9CThis is what standard Mobile IP provides with a = Home Address (HoA)...=E2=80=9D If it is not equal to HoA, = need clarification in the draft.

Draft says "This is what standard Mobile IP provides with a Home Address = (HoA). The mobile host is configures a HoA = from a centrally-located Home Network. = "

If this = is not clear enough, we can certainly elaborate more on that in the = I-D.

2. = Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D in = the draft:

"- Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "

There is no clear dividing line between fixed = IP address and sustained IP address. Whether the IP address is used for = reachability is not determined by the IP address itself. For example, = even when the MN get a HoA, after it moves to another location of the = network, it may decide to release current HoA and get another HoA, in = this case the "fixed IP address" becomes a "sustained IP = address".

If the IP stack on the host releases the IP address, then of course = it's not a "fixed IP address".
Please see the = definitions of these terms in the = I-D.

Further more, the reachability normally is = implemented by domain name instead of IP address. For example, we reach = =E2=80=9CGoogle=E2=80=9D by its domain name, never by it=E2=80=99s = server=E2=80=99s IP = address.

Using temporary = private IP address we can also achieve the goal of =E2=80=9Creachability=E2= =80=9D. For example, using dynamic DNS, as shown in http://hsk.oray.com/ , it can = provide reachability even the host get a private IP = address.

You = had said this before, and I had explained it.
Nevertheless, = let me recap:
You cannot ensure an ongoing IP flow continues = w/o interruption if you simply rely on dynamic DNS. Ongoing flows break = even if you update the DNS.
Furthermore, even if you ignore = the ongoing flows, also note that DNS clients have a cache, hence a = dynamic DNS update cannot be instantaneously reflected on the = hosts.
So, you cannot provide full mobility solution by = relying on dynamic = DNS.

The = point here is =E2=80=9Creachability=E2=80=9D instead of = =E2=80=9Cmobility=E2=80=9D.

Further more, even mobile IP = may lost some packet during = handover.

Not sure if this = point has any impact on the = discussion.

3. = Regarding the definition of =E2=80=9Cnomadic IP = address=E2=80=9D:

=E2=80=9C- Nomadic IP = Address
This type = of IP address provides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the = mobile
host.=E2=80=9D

Se= ems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for = it?

<= div>If you don't name it, how would you refer to it in this = context?

If the justification = of naming IP address as =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C = sustained IP=E2=80=9D is not valid, then we may not necessary need a new = name for normal IP = address.

I and the = WT#1 believe that justification is valid.

If you believe = otherwise, please = elaborate.

Alper

Dapeng

Alper
=

--
Dapeng = Liu

=E5=9C=A8 = 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4= =B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

Hello Dapeng and = Alex,

I hope you had a chance to digest our = responses to your comments and questions about the API = work.
If you have any remaining issues, please let us know = over the email at your earliest convenience.
It'd be good if = you can articulate them in = detail.

Thanks.

Alper
=20 =20 =20 =20

=20 =20 =20 =20 =20

= --Apple-Mail=_4E9050FF-A42C-43B3-A4A5-30AE9C727F17-- From nobody Wed Mar 25 18:32:43 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AC91A8880 for ; Wed, 25 Mar 2015 18:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFU0SZdoE3dK for ; Wed, 25 Mar 2015 18:32:39 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D581D1A1B76 for ; Wed, 25 Mar 2015 18:32:38 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so34303510obc.2 for ; Wed, 25 Mar 2015 18:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=zLL2B605vCLoclJjwyGo2EvwGnSE30sVzlDMlOHBZHo=; b=NdJLoTJjuM0p2HmFebwgkylpN5PzAOQBcJNXVbPG/UM0hh2gtMkH54el8ukQZ9NVUl FbZEL4LfIoj/SdHTlEiSrr2P9eVj/gn8vSVy5o8KOEaBy1GJ/VoRzMQOWC1R/6e1iGyt 0OOPCbxe6dCRCDR5bTpi/nak3sjsPnmSIj2GgaOTjjPYFDLMnogIjwpKSoDxWoT9E89Y 7W5YQ/tnH6SwPdbCsSQ1yFrR/hXxRrW6cjz/xh0PUpK7hmGL8wTdfMAaLCvJZOdTPikW aYsyZ6nF3PsXlch6K2I8LFGUwwrrnGBMzkj441r8MASFrkE2naEeYzhRF0kmpHpW8w7+ 2PSw== X-Received: by 10.182.72.225 with SMTP id g1mr10109472obv.80.1427333558355; Wed, 25 Mar 2015 18:32:38 -0700 (PDT) Received: from [10.1.213.204] ([38.96.210.190]) by mx.google.com with ESMTPSA id h8sm3411907obe.2.2015.03.25.18.32.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 18:32:36 -0700 (PDT) Date: Wed, 25 Mar 2015 20:32:33 -0500 From: Dapeng Liu To: Alper Yegin Message-ID: <52AC56D3ADC0481CBF02BAADF720991B@gmail.com> In-Reply-To: References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="551361b1_55c3594c_a9e" Archived-At: Cc: dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 01:32:42 -0000 --551361b1_55c3594c_a9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C=E4=B8=8B=E5=8D=886:54=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A > > > > =20 > > > > 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D= in the draft: > > > > =20 > > > > =E2=80=9C- =46ixed IP Address > > > > This is what standard Mobile IP provides with a Home Address (HoA= ). The mobile host is configures a HoA from a centrally-located Home Netw= ork. Both IP session continuity and IP address reachability are provided = to the mobile host with the help of a router in the Home Network (Home Ag= ent, HA). This router acts as an anchor for the IP =20 > > > > address of the mobile host.=E2=80=9D =20 > > > > =20 > > > > If this is equal to HoA, then R=46C5014 already cover that. We do= not need to repeat it here with another name. > > > > =20 > > > =20 > > > =20 > > > This is not equal to =22HoA=22. > > > This is equal to =22HoA permanently allocated on a HA in the core n= etwork=22 > > > (as opposed to =22HoA temporarily allocated on a HA in the access n= etwork=22) > > > =20 > > The draft says: =E2=80=9CThis is what standard Mobile IP provides wit= h a Home Address (HoA)...=E2=80=9D If it is not equal to HoA, need clari= fication in the draft. > > > =20 > =20 > Draft says =22This is what standard Mobile IP provides with a Home Addr= ess (HoA). The mobile host is configures a HoA from a centrally-located H= ome Network. =22 > =20 > If this is not clear enough, we can certainly elaborate more on that in= the I-D. > =20 Yes. It needs more elaboration. =20 > =20 > =20 > > > > 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80= =9D in the draft: > > > > =20 > > > > =22- Sustained IP Address This type of IP address provides IP ses= sion continuity but not IP address reachability. It is achieved by ensuri= ng that the IP address used at the beginning of the session remains usabl= e despite the movement of the mobile host. The IP address may change afte= r the termination of the IP session(s), therefore it does not exhibit per= sistence. =22 =20 > > > > There is no clear dividing line between fixed IP address and sust= ained IP address. Whether the IP address is used for reachability is not = determined by the IP address itself. =46or example, even when the MN get = a HoA, after it moves to another location of the network, it may decide t= o release current HoA and get another HoA, in this case the =22fixed IP a= ddress=22 becomes a =22sustained IP address=22. > > > > =20 > > > =20 > > > If the IP stack on the host releases the IP address, then of course= it's not a =22fixed IP address=22. =20 > > > Please see the definitions of these terms in the I-D. > > > =20 > > > =20 > > > > =46urther more, the reachability normally is implemented by domai= n name instead of IP address. =46or example, we reach =E2=80=9CGoogle=E2=80= =9D by its domain name, never by it=E2=80=99s server=E2=80=99s IP address= . =20 > > > > =20 > > > > Using temporary private IP address we can also achieve the goal o= f =E2=80=9Creachability=E2=80=9D. =46or example, using dynamic DNS, as sh= own in http://hsk.oray.com/ , it can provide reachability even the host= get a private IP address. > > > > =20 > > > =20 > > > You had said this before, and I had explained it. > > > Nevertheless, let me recap: > > > You cannot ensure an ongoing IP flow continues w/o interruption if = you simply rely on dynamic DNS. Ongoing flows break even if you update th= e DNS. > > > =46urthermore, even if you ignore the ongoing flows, also note that= DNS clients have a cache, hence a dynamic DNS update cannot be instantan= eously reflected on the hosts. =20 > > > So, you cannot provide full mobility solution by relying on dynamic= DNS. > > > =20 > > > =20 > > The point here is =E2=80=9Creachability=E2=80=9D instead of =E2=80=9C= mobility=E2=80=9D. =20 > > =46urther more, even mobile IP may lost some packet during handover. = =20 > > =20 > =20 > =20 > Not sure if this point has any impact on the discussion. > =20 > =20 The point is: in the draft, whether support =E2=80=9Creachability=E2=80=9D= is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sust= ained IP=E2=80=9D, but the truth is any type of IP address can provide =E2= =80=9Creachability=E2=80=9D. So there is no clear dividing line between = =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D in the def= inition. That is why the definition of the IP types is not valid. > > > > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D= : > > > > =20 > > > > =E2=80=9C- Nomadic IP Address > > > > This type of IP address provides neither IP session continuity no= r IP address reachability. The IP address is obtained from the serving IP= gateway and it is not maintained across gateway changes. In other words,= the IP address may be released and replaced by a new IP address when the= IP gateway changes due to the movement of the mobile =20 > > > > host.=E2=80=9D > > > > =20 > > > > Seems this IP address is the IP address that we normally used in = most cases. If this is the case, why we need a new name for it=3F > > > > =20 > > > =20 > > > =20 > > > If you don't name it, how would you refer to it in this context=3F > > If the justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D= and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not necess= ary need a new name for normal IP address. > > =20 > =20 > I and the WT=231 believe that justification is valid. > If you believe otherwise, please elaborate. > =20 > =20 > =20 Pls see above comment. Dapeng =20 > =20 > Alper > =20 > =20 > =20 > > =20 > > Dapeng =20 > > > =20 > > > =20 > > > Alper > > > =20 > > > =20 > > > > =20 > > > > -- =20 > > > > Dapeng Liu > > > > =20 > > > > =20 > > > > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4= =B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81= =93=EF=BC=9A > > > > =20 > > > > > Hello Dapeng and Alex, > > > > > =20 > > > > > I hope you had a chance to digest our responses to your comment= s and questions about the API work. > > > > > If you have any remaining issues, please let us know over the e= mail at your earliest convenience. > > > > > It'd be good if you can articulate them in detail. > > > > > =20 > > > > > =20 > > > > > Thanks. > > > > > =20 > > > > > Alper =20 > > > > =20 > > > =20 > > =20 > =20 --551361b1_55c3594c_a9e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=20
=E5=9C=A8 2015=E5=B9=B4= 3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D= =886:54=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

1. Regarding the definition of =E2=80= =9Cfixed IP address=E2=80=9D in the draft:

= ; =E2=80=9C- =46ixed IP Address
This is what standard Mobile IP provides with a Home Address (HoA= ). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP&nb= sp;
address of the mobile host.=E2=80=9D

If this is equal to HoA, then R=46C5014 already cover tha= t. We do not need to repeat it here with another name.

This is not equal= to =22HoA=22.
This is equal to =22HoA permanently allocated on= a HA in the core network=22
(as opposed to =22HoA temporarily = allocated on a HA in the access network=22)

The draft says: =E2=80=9CThis is what stan= dard Mobile IP provides with a Home Address (HoA)...=E2=80=9D &nbs= p;If it is not equal to HoA, need clarification in the draft.

Draft says =22This is wha= t standard Mobile IP provides with a Home Address (HoA). The mobile hos= t is configures a HoA from a centrally-located Home Network. =22=

If this is not clear enough, we can certainly e= laborate more on that in the I-D.

<= /span>
Yes. It needs more elaboration.
=
2. Regarding the= definition of =E2=80=9Csustained IP address=E2=80=9D in the draft:
=

=22- Sustained I= P Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. =22

There is no clear dividing line between fixed I= P address and sustained IP address. Whether the IP address is used for re= achability is not determined by the IP address itself. =46or example, eve= n when the MN get a HoA, after it moves to another location of the networ= k, it may decide to release current HoA and get another HoA, in this case= the =22fixed IP address=22 becomes a =22sustained IP address=22.

If the IP stack= on the host releases the IP address, then of course it's not a =22fixed = IP address=22.
Please see the definitions of these terms = in the I-D.

=46urther more, the reachability normally is implement= ed by domain name instead of IP address. =46or example, we reach =E2=80=9C= Google=E2=80=9D by its domain name, never by it=E2=80=99s server=E2=80=99= s IP address.

Using tempor= ary private IP address we can also achieve the goal of =E2=80=9Creachabil= ity=E2=80=9D. =46or example, using dynamic DNS, as shown in http://hsk.oray.com/ , it can &nbs= p;provide reachability even the host get a private IP address.
=

You had said this = before, and I had explained it.
Nevertheless, let me recap:
You cannot ensure an ongoing IP flow continues w/o interruption if= you simply rely on dynamic DNS. Ongoing flows break even if you update t= he DNS.
=46urthermore, even if you ignore the ongoing flows, al= so note that DNS clients have a cache, hence a dynamic DNS update cannot = be instantaneously reflected on the hosts.
So, you cannot= provide full mobility solution by relying on dynamic DNS.

=

The point here is =E2= =80=9Creachability=E2=80=9D instead of =E2=80=9Cmobility=E2=80=9D. <= /div>
=46urther more, even mobile IP may lost some packet during hand= over.

Not sure if this = point has any impact on the discussion.

The point is: in the draft, wheth= er support =E2=80=9Creachability=E2=80=9D is the distinction between =E2=80= =9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D, but the truth i= s any type of IP address can provide =E2=80=9Creachability=E2=80=9D. So t= here is no clear dividing line between =E2=80=9Cfixed IP=E2=80=9D a= nd =E2=80=9C sustained IP=E2=80=9D in the definition. That is why the def= inition of the IP types is not valid.
=
3. Regarding the definition of =E2=80=9Cnomadic IP addr= ess=E2=80=9D:

=E2=80=9C- Nomadic IP Address<= /div>
This type of IP address prov= ides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile&= nbsp;
host.=E2=80=9D

Seems this= IP address is the IP address that we normally used in most cases. If thi= s is the case, why we need a new name for it=3F

If you don't name it, ho= w would you refer to it in this context=3F
=
If the justification of naming IP address as =E2=80=9Cf= ixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then w= e may not necessary need a new name for normal IP address.

=

I and the WT=231 believe tha= t justification is valid.
If you believe otherwise, please elab= orate.
Pls see above comm= ent.

Dapeng

Alper

Dapeng

Alper

-- =
Dapeng Liu

=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F= =E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9= =81=93=EF=BC=9A

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your c= omments and questions about the API work.
If you have any remai= ning issues, please let us know over the email at your earliest convenien= ce.
It'd be good if you can articulate them in detail.

Thanks.

Alper
=20 =20 =20 =20

=20 =20 =20 =20

=20 =20 =20 =20 =20

--551361b1_55c3594c_a9e-- From nobody Wed Mar 25 21:26:16 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4665D1A90A1 for ; Wed, 25 Mar 2015 21:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4VZdOTHdbrc for ; Wed, 25 Mar 2015 21:26:12 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CE61A9080 for ; Wed, 25 Mar 2015 21:26:12 -0700 (PDT) Received: from [192.168.0.66] ([50.84.137.11]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0MUWvt-1Z0fDd0kJH-00RGSR; Thu, 26 Mar 2015 05:26:10 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Alper Yegin In-Reply-To: <55134244.602@gmail.com> Date: Thu, 26 Mar 2015 06:26:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F067406-0687-40AF-A2EB-65CAD8005B69@yegin.org> References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <55134244.602@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:Qhlzr2OWdkbqXqYDbGwiMt0gXZY+l7lpX7Rc4RsfOCumGm6XG7J y2+z92hSTQuh8UpcT+48f+SZOB9wopPulbljP0jYrP6C0P3+yhwaTzHboyqjj0gyft56vP6 XQJBbvqbhh8rl21LwcqIvVkwsA/vvTOU1Yx/Cw43vvKR6JC8MIzlaEcjzh5X65k9DUuz9X8 UzzeElMrcZ96tSnFxqd3g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 04:26:14 -0000 >>> I still have the following comments: >>>=20 >>> 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in = the draft: >>>=20 >>> =E2=80=9C- Fixed IP Address >>> This is what standard Mobile IP provides with a Home Address = (HoA). >>> The mobile host is configures a HoA from a centrally-located Home >>> Network. Both IP session continuity and IP address reachability = are >>> provided to the mobile host with the help of a router in the Home >>> Network (Home Agent, HA). This router acts as an anchor for the = IP >>> address of the mobile host.=E2=80=9D >>>=20 >>> If this is equal to HoA, then RFC5014 already cover that. We do not >>> need to repeat it here with another name. >>>=20 >>=20 >>=20 >> This is not equal to "HoA". >> This is equal to "HoA permanently allocated on a HA in the core = network" [1] >> (as opposed to "HoA temporarily allocated on a HA in the access = network") [2] >=20 > So that's a HoA, and RFC5014 already covers that, right? No. I tried to explain it below, that it's not just "HoA". [1] provides a fixed IP address, [2] provides a sustained IP address. That distinction is not captured when you call it "HoA". >=20 >>> 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D = in the draft: >>>=20 >>> "- Sustained IP Address >>>=20 >>> This type of IP address provides IP session continuity but not IP >>> address reachability. It is achieved by ensuring that the IP = address >>> used at the beginning of the session remains usable despite the >>> movement of the mobile host. The IP address may change after the >>> termination of the IP session(s), therefore it does not exhibit >>> persistence. >>> " >>> There is no clear dividing line between fixed IP address and = sustained >>> IP address. Whether the IP address is used for reachability is not >>> determined by the IP address itself. For example, even when the MN = get >>> a HoA, after it moves to another location of the network, it may >>> decide to release current HoA and get another HoA, in this case the >>> "fixed IP address" becomes a "sustained IP address". >>>=20 >>=20 >> If the IP stack on the host releases the IP address, then of course = it's >> not a "fixed IP address". >> Please see the definitions of these terms in the I-D. >>=20 >>=20 >>> Further more, the reachability normally is implemented by domain = name >>> instead of IP address. For example, we reach =E2=80=9CGoogle=E2=80=9D = by its domain >>> name, never by it=E2=80=99s server=E2=80=99s IP address. >>>=20 >>> Using temporary private IP address we can also achieve the goal of >>> =E2=80=9Creachability=E2=80=9D. For example, using dynamic DNS, as = shown in >>> http://hsk.oray.com/ , it can provide reachability even the host = get >>> a private IP address. >>>=20 >>=20 >> You had said this before, and I had explained it. >> Nevertheless, let me recap: >> You cannot ensure an ongoing IP flow continues w/o interruption if = you >> simply rely on dynamic DNS. Ongoing flows break even if you update = the DNS. >=20 > But Dapeng talks about reachability, not about session continuity. In = that sense he's right, no? (DNS updates ensure reachability upon address = change). it's not "IP address" reachability. When the host releases its IP = address, that IP address is no longer reachable.=20 >=20 > Even I would go as far as to say that _some_ application flows will = resist to changes in that IP address and get restarted with the new = address if that DNS update process was performed. >=20 > This is because the concept of 'flow' is very much ambiguous. Very = rarely a read in packet dump can show 'flows' as we talk commonly about = them in the DMM discussions. It is for this reason that there is no = option in Wireshark that groups packets in 'flows', like a mail reader = would group messages into 'conversations' or 'threads'. >=20 > It is for this reason too that firewall rules trying to be smart and = identify 'flows' before blocking them very often fail, even if we do = Deep Packet Inspection. People always find ways to 'drill' through = these rules. >=20 >> Furthermore, even if you ignore the ongoing flows, also note that DNS >> clients have a cache, hence a dynamic DNS update cannot be >> instantaneously reflected on the hosts. >=20 > I can agree to that. I guess though there may be forced updates on = these caches, or that the timers can be configured shorter in domains = supporting mobility. Nope, not practical. You need to enforce that on all possible hosts that = may be in comm. with the MN across the Internet. Can't do that. >=20 >> So, you cannot provide full mobility solution by relying on dynamic = DNS. >=20 > We dont know what full mobility is, and DNS updates is a good tool to = provide reachability and session continuity, in some cases. >=20 Full mobility is what you get out of Mobile IP. You cannot achieve the same effect using dynamic DNS. Alper > Alex >=20 >>=20 >>=20 >>> 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D: >>>=20 >>> =E2=80=9C- Nomadic IP Address >>> This type of IP address provides neither IP session continuity = nor IP >>> address reachability. The IP address is obtained from the = serving IP >>> gateway and it is not maintained across gateway changes. In = other >>> words, the IP address may be released and replaced by a new IP >>> address when the IP gateway changes due to the movement of the = mobile >>> host.=E2=80=9D >>>=20 >>> Seems this IP address is the IP address that we normally used in = most >>> cases. If this is the case, why we need a new name for it? >>>=20 >>=20 >>=20 >> If you don't name it, how would you refer to it in this context? >>=20 >>=20 >> Alper >>=20 >>=20 >>>=20 >>> -- >>> Dapeng Liu >>>=20 >>> =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper = Yegin =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>>> Hello Dapeng and Alex, >>>>=20 >>>> I hope you had a chance to digest our responses to your comments = and >>>> questions about the API work. >>>> If you have any remaining issues, please let us know over the email >>>> at your earliest convenience. >>>> It'd be good if you can articulate them in detail. >>>>=20 >>>>=20 >>>> Thanks. >>>>=20 >>>> Alper >>>=20 >>=20 >=20 >=20 From nobody Wed Mar 25 21:29:33 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E381A90A8 for ; Wed, 25 Mar 2015 21:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85IAsazGVNGk for ; Wed, 25 Mar 2015 21:29:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA16E1A90B4 for ; Wed, 25 Mar 2015 21:29:26 -0700 (PDT) Received: from [192.168.0.66] ([50.84.137.11]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0MJDJ6-1Ycd361RVa-002pVM; Thu, 26 Mar 2015 05:29:26 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_5EF4A945-10D0-44CC-B72E-F31B5A52810C" From: Alper Yegin In-Reply-To: <5513446A.4060307@gmail.com> Date: Thu, 26 Mar 2015 06:29:25 +0200 Message-Id: <1706A923-62A2-4964-90B1-8FBDE63C51D1@yegin.org> References: <5513446A.4060307@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:GuYf2yTTQSD4NN7A92TT++DoysyH3pWcIr91dqJCyjCGZtugGOa 8jPdavVaWZY6E+fQxrNtY+Vw8Ocgmfk2rB89+wQ5ifmEU7fyjQGhco6Iwv3Z4nnoKunnCkC xwB0p+AhbS1gbZNUf48n+e6J5V+LcrPeLaHn5u3G6qbgR+KSI8G1LvKBQ8OB8zmO354IYGQ m3jTcQ5T5UvznUHGA9+FA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] SUSTAINED, NOMADIC, FIXED: existing kinds, lifetimes X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 04:29:31 -0000 --Apple-Mail=_5EF4A945-10D0-44CC-B72E-F31B5A52810C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Mar 26, 2015, at 1:27 AM, Alexandru Petrescu wrote: > Alper, authors of draft-yegin-dmm-ondemand-mobility-03, > > I would like to ask how do you see the relationships between > other kinds of addresses (HoW, CoA, LL, GUA, ULA, NATTed, privacy, > multicast) and the SUSTAINED, NOMADIC, FIXED addresses. > Alex, do you remember you had asked that question, and I had answered it? Here: http://www.ietf.org/mail-archive/web/dmm/current/msg01814.html > In addition, I think there may be a relationship with the lifetimes of > the addresses generated by existing address configuration mechanisms. > Please explain the relationship. Alper > Alex > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_5EF4A945-10D0-44CC-B72E-F31B5A52810C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Alper, authors of = draft-yegin-dmm-ondemand-mobility-03,

I would like to ask how do = you see the relationships between
other kinds of addresses (HoW, CoA, = LL, GUA, ULA, NATTed, privacy,
multicast) and the SUSTAINED, NOMADIC, = FIXED addresses.

Alex, do = you remember you had asked that question, and I had answered = it?
Here: ht= tp://www.ietf.org/mail-archive/web/dmm/current/msg01814.html

=
In addition, I think there may be a = relationship with the lifetimes of
the addresses generated by = existing address configuration = mechanisms.

Please explain = the = relationship.

Alper

=

Alex

_______________________________________= ________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mail= man/listinfo/dmm

= --Apple-Mail=_5EF4A945-10D0-44CC-B72E-F31B5A52810C-- From nobody Wed Mar 25 21:43:24 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA91A89FD for ; Wed, 25 Mar 2015 21:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MkH0LOSLqIW for ; Wed, 25 Mar 2015 21:43:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C761A9141 for ; Wed, 25 Mar 2015 21:43:20 -0700 (PDT) Received: from [192.168.0.66] ([50.84.137.11]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0MT99c-1Z22Q42Mbe-00SHIv; Thu, 26 Mar 2015 05:43:19 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_02FA2D98-7970-4515-962C-2B80DF6C0C6A" From: Alper Yegin In-Reply-To: <52AC56D3ADC0481CBF02BAADF720991B@gmail.com> Date: Thu, 26 Mar 2015 06:42:33 +0200 Message-Id: <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org> References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> <52AC56D3ADC0481CBF02BAADF720991B@gmail.com> To: Dapeng Liu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:eWXuox4hEkJkrcjZpuTOPrGOdiCfoK8OcMu8tBdVSPwsoZX3f65 uYqrw49LNAWCtjByYRPlTZW8RYFdAw9XGKMyAL3LI47dtKoeu5oHgrMy0k1kIvih5BcC9S+ QyVGA9VYNA8839ClPRLOh8yMqxRumMuN2JaE4Z9njLERzBgAlp9mUEDV99tMth+Kg3FcqWk LiJzAO9nym4gjI1FOXdbg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 04:43:22 -0000 --Apple-Mail=_02FA2D98-7970-4515-962C-2B80DF6C0C6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The point is: in the draft, whether support =E2=80=9Creachability=E2=80= =9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C = sustained IP=E2=80=9D, but the truth is any type of IP address can = provide =E2=80=9Creachability=E2=80=9D. So there is no clear dividing = line between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D= in the definition. That is why the definition of the IP types is not = valid. "IP address reachability" is about ability to reach the host at a = specific "IP address" even when the host changes its point of = attachment. You seem to interpret it as if it said "IP reachability" (ability to = reach the host using IP protocol), but that's not the case. That term is already defined in the I-D: IP address reachability: The ability to maintain the same IP address for an extended period of time. The IP address stays the same across independent IP sessions, and even in the absence of any IP session. The IP address may be published in a long-term registry (e.g., DNS), and it is made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/published IP addresses. >>>>> 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:= >>>>>=20 >>>>> =E2=80=9C- Nomadic IP Address >>>>> This type of IP address provides neither IP session continuity = nor IP >>>>> address reachability. The IP address is obtained from the = serving IP >>>>> gateway and it is not maintained across gateway changes. In = other >>>>> words, the IP address may be released and replaced by a new IP >>>>> address when the IP gateway changes due to the movement of the = mobile=20 >>>>> host.=E2=80=9D >>>>>=20 >>>>> Seems this IP address is the IP address that we normally used in = most cases. If this is the case, why we need a new name for it? >>>>>=20 >>>>=20 >>>>=20 >>>> If you don't name it, how would you refer to it in this context? >>> If the justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D= and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not = necessary need a new name for normal IP address. >>>=20 >>=20 >> I and the WT#1 believe that justification is valid. >> If you believe otherwise, please elaborate. > Pls see above comment. >=20 > Dapeng=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>>=20 >>> Dapeng=20 >>>>=20 >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>>=20 >>>>> --=20 >>>>> Dapeng Liu >>>>>=20 >>>>> =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper = Yegin =E5=86=99=E9=81=93=EF=BC=9A >>>>>=20 >>>>>> Hello Dapeng and Alex, >>>>>>=20 >>>>>> I hope you had a chance to digest our responses to your comments = and questions about the API work. >>>>>> If you have any remaining issues, please let us know over the = email at your earliest convenience. >>>>>> It'd be good if you can articulate them in detail. >>>>>>=20 >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> Alper >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_02FA2D98-7970-4515-962C-2B80DF6C0C6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The point is: in the draft, = whether support =E2=80=9Creachability=E2=80=9D is the distinction = between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D, = but the truth is any type of IP address can provide =E2=80=9Creachability=E2= =80=9D. So there is no clear dividing line between =E2=80=9Cfixed = IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D in the definition. That = is why the definition of the IP types is not = valid.

"IP address = reachability" is about ability to reach the host at a specific "IP = address" even when the host changes its point of = attachment.
You seem to interpret it as if it said "IP = reachability" (ability to reach the host using IP protocol), but that's = not the case.

That term is already defined in = the I-D:

IP address reachability: The ability to maintain the same = IP address for an extended period of time. The IP address stays the same across independent IP sessions, and even in the absence of any IP session. The IP address may be published in a long-term registry (e.g., DNS), and it is made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/published IP = addresses.

3. = Regarding the definition of =E2=80=9Cnomadic IP = address=E2=80=9D:

=E2=80=9C- Nomadic IP = Address
This type = of IP address provides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the = mobile
host.=E2=80=9D

Se= ems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for = it?

<= div>If you don't name it, how would you refer to it in this = context?
If the = justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D and =E2=80= =9C sustained IP=E2=80=9D is not valid, then we may not necessary need a = new name for normal IP = address.

I = and the WT#1 believe that justification is valid.
If you = believe otherwise, please = elaborate.
Pls see above = comment.

Dapeng

Alper

<= /div>

Dapeng

Alpe= r

--
Dapeng = Liu

=E5=9C=A8 = 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4= =B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

Hello Dapeng and = Alex,

I hope you had a chance to digest our = responses to your comments and questions about the API = work.
If you have any remaining issues, please let us know = over the email at your earliest convenience.
It'd be good if = you can articulate them in = detail.

Thanks.

Alper
=20 =20 =20 =20

=20 =20 =20 =20

=20 =20 =20 =20 =20

= --Apple-Mail=_02FA2D98-7970-4515-962C-2B80DF6C0C6A-- From nobody Thu Mar 26 10:39:22 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC531A8F37 for ; Thu, 26 Mar 2015 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2WSGEYqQl2V for ; Thu, 26 Mar 2015 10:39:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31E81A8F4D for ; Thu, 26 Mar 2015 10:39:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQT03315; Thu, 26 Mar 2015 17:39:16 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 17:39:15 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 01:39:11 +0800 From: "Weixinpeng (Jackie)" To: Dapeng Liu , Alper Yegin Thread-Topic: =?gb2312?B?UmWjuiBETU0gQVBJ?= Thread-Index: AQHQZ+vETXUKkoT1hkqe8nT0z2URPg== Date: Thu, 26 Mar 2015 17:39:10 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.153] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46E331EE0nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dmm@ietf.org" Subject: [DMM] =?gb2312?b?UmWjuiBETU0gQVBJ?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 17:39:21 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46E331EE0nkgeml507mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxwZXINCg0KTXkgdW5kZXJzdGFuZGluZyBhYm91dCB0aGUgcmVhc29uIHdoeSB0aGVyZSBu ZWVkcyB0byBkZWZpbmUgc2VydmFsIHR5cGVzIG9mIElQIHByZWZpeGVzIGlzIHRoYXQsICBpZiB0 aGUgYXBwbGljYXRpb24gaXRzZWxmIGNvdWxkIGRlYWwgd2l0aCB0aGUgY2hhbmdlIG9mIElQIGFk ZHJlc3MsIGkuZS4gdGhlIGFwcGxpY2F0aW9uIGl0c2VsZiBjb3VsZCBkZWFsIHdpdGggc2Vzc2lv biBjb250aW51dHkgaW4gY2FzZSBvZiBJUCBhZGRyZXNzIGNoYW5nZSwgc28gdGhlIGhvc3Qgd291 bGQgY2hvb3NlIGEgbm9ybWFkaWMgYWRkcmVzcyBvdGhlcndpc2UgdGhlIGhvc3Qgc2hvdWxkIGNo b29zZSBhIHN1c3RhaW5lZCBhZGRyZXNzLg0KDQpCdXQgbXkgcXVlc3Rpb24gaXMgdGhhdCwgaWYg dGhlIGFwcGxpY2F0aW9uIGNvdWxkIGRlYWwgd2l0aCBzZXNzaW9uIGNvbnRpbnV0eSBpdHNlbGYs IGRvZXMgdGhhdCBtZWFuIHRoZSBhcHBsaWNhdGlvbiBpcyB3aWxsaW5nIHRvIGNoYW5nZSBpdHMg SVAgYWRkcmVzcz8gQmVjYXVzZSBldmVuIHRob3VnaCBhIG5ldyBhZGRyZXNzIG1pZ2h0IGJyaW5n IHNvbWUga2luZHMgb2YgYmVuZWZpdCwgYnV0IGl0IHdpbGwgYWxzbw0KDQpicmluZyBhZGRpdGlv bmFsIGNvc3QgZm9yIGFwcGxpY2F0aW9uIHRvIGRlYWwgd2l0aCBJUCBhZGRyZXNzIGNoYW5nZS4N Cg0KVGhhbmtzLg0KDQoNCg0KWGlucGVuZw0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQq3orz+yMs6IGRtbSBbZG1tLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGFw ZW5nIExpdSBbbWF4cGFzc2lvbkBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxNcTqM9TCMjbI1SA1 OjAxDQrK1bz+yMs6IEFscGVyIFllZ2luDQqzrcvNOiBkbW1AaWV0Zi5vcmcNCtb3zOI6IFtETU1d ILvYuLSjuiBETU0gQVBJDQoNCkhlbGxvIEFscGVyLA0KDQpJIHN0aWxsIGhhdmUgdGhlIGZvbGxv d2luZyBjb21tZW50czoNCg0KMS4gUmVnYXJkaW5nIHRoZSBkZWZpbml0aW9uIG9mIKGwZml4ZWQg SVAgYWRkcmVzc6GxIGluIHRoZSBkcmFmdDoNCg0KICChsC0gRml4ZWQgSVAgQWRkcmVzcw0KDQog ICBUaGlzIGlzIHdoYXQgc3RhbmRhcmQgTW9iaWxlIElQIHByb3ZpZGVzIHdpdGggYSBIb21lIEFk ZHJlc3MgKEhvQSkuDQogICBUaGUgbW9iaWxlIGhvc3QgaXMgY29uZmlndXJlcyBhIEhvQSBmcm9t IGEgY2VudHJhbGx5LWxvY2F0ZWQgSG9tZQ0KICAgTmV0d29yay4gIEJvdGggSVAgc2Vzc2lvbiBj b250aW51aXR5IGFuZCBJUCBhZGRyZXNzIHJlYWNoYWJpbGl0eSBhcmUNCiAgIHByb3ZpZGVkIHRv IHRoZSBtb2JpbGUgaG9zdCB3aXRoIHRoZSBoZWxwIG9mIGEgcm91dGVyIGluIHRoZSBIb21lDQog ICBOZXR3b3JrIChIb21lIEFnZW50LCBIQSkuICBUaGlzIHJvdXRlciBhY3RzIGFzIGFuIGFuY2hv ciBmb3IgdGhlIElQDQoNCmFkZHJlc3Mgb2YgdGhlIG1vYmlsZSBob3N0LqGxDQoNCklmIHRoaXMg aXMgZXF1YWwgdG8gSG9BLCB0aGVuIFJGQzUwMTQgYWxyZWFkeSBjb3ZlciB0aGF0LiBXZSBkbyBu b3QgbmVlZCB0byByZXBlYXQgaXQgaGVyZSB3aXRoIGFub3RoZXIgbmFtZS4NCg0KMi4gUmVnYXJk aW5nIHRoZSBkZWZpbml0aW9uIG9mIKGwc3VzdGFpbmVkIElQIGFkZHJlc3OhsSBpbiB0aGUgZHJh ZnQ6DQoNCg0KIi0gU3VzdGFpbmVkIElQIEFkZHJlc3MNCg0KICAgVGhpcyB0eXBlIG9mIElQIGFk ZHJlc3MgcHJvdmlkZXMgSVAgc2Vzc2lvbiBjb250aW51aXR5IGJ1dCBub3QgSVANCiAgIGFkZHJl c3MgcmVhY2hhYmlsaXR5LiAgSXQgaXMgYWNoaWV2ZWQgYnkgZW5zdXJpbmcgdGhhdCB0aGUgSVAg YWRkcmVzcw0KICAgdXNlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZXNzaW9uIHJlbWFpbnMg dXNhYmxlIGRlc3BpdGUgdGhlDQogICBtb3ZlbWVudCBvZiB0aGUgbW9iaWxlIGhvc3QuICBUaGUg SVAgYWRkcmVzcyBtYXkgY2hhbmdlIGFmdGVyIHRoZQ0KICAgdGVybWluYXRpb24gb2YgdGhlIElQ IHNlc3Npb24ocyksIHRoZXJlZm9yZSBpdCBkb2VzIG5vdCBleGhpYml0DQogICBwZXJzaXN0ZW5j ZS4NCiINCg0KVGhlcmUgaXMgbm8gY2xlYXIgZGl2aWRpbmcgbGluZSBiZXR3ZWVuIGZpeGVkIElQ IGFkZHJlc3MgYW5kIHN1c3RhaW5lZCBJUCBhZGRyZXNzLiBXaGV0aGVyIHRoZSBJUCBhZGRyZXNz IGlzIHVzZWQgZm9yIHJlYWNoYWJpbGl0eSBpcyBub3QgZGV0ZXJtaW5lZCBieSB0aGUgSVAgYWRk cmVzcyBpdHNlbGYuIEZvciBleGFtcGxlLCBldmVuIHdoZW4gdGhlIE1OIGdldCBhIEhvQSwgYWZ0 ZXIgaXQgbW92ZXMgdG8gYW5vdGhlciBsb2NhdGlvbiBvZiB0aGUgbmV0d29yaywgaXQgbWF5IGRl Y2lkZSB0byByZWxlYXNlIGN1cnJlbnQgSG9BIGFuZCBnZXQgYW5vdGhlciBIb0EsIGluIHRoaXMg Y2FzZSB0aGUgImZpeGVkIElQIGFkZHJlc3MiIGJlY29tZXMgYSAic3VzdGFpbmVkIElQIGFkZHJl c3MiLg0KDQpGdXJ0aGVyIG1vcmUsIHRoZSByZWFjaGFiaWxpdHkgbm9ybWFsbHkgaXMgaW1wbGVt ZW50ZWQgYnkgZG9tYWluIG5hbWUgaW5zdGVhZCBvZiBJUCBhZGRyZXNzLiBGb3IgZXhhbXBsZSwg d2UgcmVhY2ggobBHb29nbGWhsSBieSBpdHMgZG9tYWluIG5hbWUsIG5ldmVyIGJ5IGl0oa9zIHNl cnZlcqGvcyBJUCBhZGRyZXNzLg0KDQpVc2luZyB0ZW1wb3JhcnkgcHJpdmF0ZSBJUCBhZGRyZXNz IHdlIGNhbiBhbHNvIGFjaGlldmUgdGhlIGdvYWwgb2YgobByZWFjaGFiaWxpdHmhsS4gRm9yIGV4 YW1wbGUsIHVzaW5nIGR5bmFtaWMgRE5TLCBhcyBzaG93biBpbiAgaHR0cDovL2hzay5vcmF5LmNv bS8gLCBpdCBjYW4gIHByb3ZpZGUgcmVhY2hhYmlsaXR5IGV2ZW4gdGhlIGhvc3QgZ2V0IGEgcHJp dmF0ZSBJUCBhZGRyZXNzLg0KDQozLiBSZWdhcmRpbmcgdGhlIGRlZmluaXRpb24gb2YgobBub21h ZGljIElQIGFkZHJlc3OhsToNCg0KobAtIE5vbWFkaWMgSVAgQWRkcmVzcw0KDQogICBUaGlzIHR5 cGUgb2YgSVAgYWRkcmVzcyBwcm92aWRlcyBuZWl0aGVyIElQIHNlc3Npb24gY29udGludWl0eSBu b3IgSVANCiAgIGFkZHJlc3MgcmVhY2hhYmlsaXR5LiAgVGhlIElQIGFkZHJlc3MgaXMgb2J0YWlu ZWQgZnJvbSB0aGUgc2VydmluZyBJUA0KICAgZ2F0ZXdheSBhbmQgaXQgaXMgbm90IG1haW50YWlu ZWQgYWNyb3NzIGdhdGV3YXkgY2hhbmdlcy4gIEluIG90aGVyDQogICB3b3JkcywgdGhlIElQIGFk ZHJlc3MgbWF5IGJlIHJlbGVhc2VkIGFuZCByZXBsYWNlZCBieSBhIG5ldyBJUA0KICAgYWRkcmVz cyB3aGVuIHRoZSBJUCBnYXRld2F5IGNoYW5nZXMgZHVlIHRvIHRoZSBtb3ZlbWVudCBvZiB0aGUg bW9iaWxlDQoNCmhvc3QuobENCg0KU2VlbXMgdGhpcyBJUCBhZGRyZXNzIGlzIHRoZSBJUCBhZGRy ZXNzIHRoYXQgd2Ugbm9ybWFsbHkgdXNlZCBpbiBtb3N0IGNhc2VzLiBJZiB0aGlzIGlzIHRoZSBj YXNlLCB3aHkgd2UgbmVlZCBhIG5ldyBuYW1lIGZvciBpdD8NCg0KDQotLQ0KRGFwZW5nIExpdQ0K DQoNCtTaIDIwMTXE6jPUwjI1yNUg0MfG2sj9o6zPws7nMjowMqOsQWxwZXIgWWVnaW4g0LS1wKO6 DQoNCkhlbGxvIERhcGVuZyBhbmQgQWxleCwNCg0KSSBob3BlIHlvdSBoYWQgYSBjaGFuY2UgdG8g ZGlnZXN0IG91ciByZXNwb25zZXMgdG8geW91ciBjb21tZW50cyBhbmQgcXVlc3Rpb25zIGFib3V0 IHRoZSBBUEkgd29yay4NCklmIHlvdSBoYXZlIGFueSByZW1haW5pbmcgaXNzdWVzLCBwbGVhc2Ug bGV0IHVzIGtub3cgb3ZlciB0aGUgZW1haWwgYXQgeW91ciBlYXJsaWVzdCBjb252ZW5pZW5jZS4N Ckl0J2QgYmUgZ29vZCBpZiB5b3UgY2FuIGFydGljdWxhdGUgdGhlbSBpbiBkZXRhaWwuDQoNCg0K VGhhbmtzLg0KDQpBbHBlcg0KDQo= --_000_C5C3BB522B1DDF478AA09545169155B46E331EE0nkgeml507mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Alper

My understanding about the reason why there needs to define serval = types of IP prefixes is that, if the application itself could de= al with the change of IP address, i.e. the application itself could deal wi= th session continuty in case of IP address change, so the host would choose a normadic address otherwise the host should choo= se a sustained address.

But my question is that, if the application could deal with session cont= inuty itself, does that mean the application is willing to change its IP ad= dress? Because even though a new address might bring some kinds of benefit,= but it will also

bring additional cost for application to deal with IP address change.
Thanks.

Xinpeng

=B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.= org] =B4=FA=B1=ED Dapeng Liu [maxpassion@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5 5:01
=CA=D5=BC=FE=C8=CB: Alper Yegin
=B3=AD=CB=CD: dmm@ietf.org
=D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA DMM API

Hello Alper,

I still have the following comments:

1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the dra= ft:

=A1=B0- Fixed IP Address

This is what standard Mo= bile IP provides with a Home Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP = ;

addre= ss of the mobile host.=A1=B1

If this is equal to HoA, then RFC5014 already cover that. We do not ne= ed to repeat it here with another name.

2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in the= draft:

"- Sustained IP Addres= s This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "

There is no clear dividing line between fixed IP address and sustained= IP address. Whether the IP address is used for reachability is not determi= ned by the IP address itself. For example, even when the MN get a HoA, afte= r it moves to another location of the network, it may decide to release current HoA and get another HoA, in = this case the "fixed IP address" becomes a "sustained IP add= ress".

Further more, the reachability normally is implemented by domain name = instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its doma= in name, never by it=A1=AFs server=A1=AFs IP address.

Using temporary private IP address we can also achieve the goal o= f =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in &nb= sp;http://hsk.oray.com/<= /a> , it can provide reachability even the host get a private IP address.

3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:

=A1=B0- Nomadic IP Address

This type of IP address = provides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile&nb= sp;

host.= =A1=B1

Seems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for it?

--

Dapeng Liu

=D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA= =C8=FD=A3=AC=CF=C2=CE=E72:02=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your comments and q= uestions about the API work.

If you have any remaining issues, please let us know over the email at= your earliest convenience.

It'd be good if you can articulate them in detail.

Thanks.

Alper

--_000_C5C3BB522B1DDF478AA09545169155B46E331EE0nkgeml507mbxchi_-- From nobody Thu Mar 26 10:53:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CD41A8AED for ; Thu, 26 Mar 2015 10:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdTSSF_URbLG for ; Thu, 26 Mar 2015 10:53:20 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2F81A8F3A for ; Thu, 26 Mar 2015 10:53:08 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so73981392wib.0 for ; Thu, 26 Mar 2015 10:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=kcI/OyCfumQbvTOTVt9wA55XirBkzu6wXL2TGJYDiHc=; b=SyIS32T7obBgTCWgPT7oFcma4yWBjaEDXP6mOYw9wZ4j+qeqcsy5Wjn5V8QGwjrnio W6jzqYRUQZri6BhJqRsuA9ebv96kKUeQO+wooUlB64ljKuNPExj0s4ONHkwACCvEN10v oNECm+Ifh2DysChZAYQ5EV/4Z8BcDnRRhCXs6ckEz0eDVLXCYq3O4XeEKuRZxMNQYJo1 qpZR2gVa/6SA2qo80wxtgbXa3pmVYjA0RZRyOc9DNMUYsbSaeVKhi9AZKqDwEhGkUEip qCd9XlLgNoy3rzPT2RaKGPHOnowg3VvRQW4h5x0s5KEGqESdQnjpGMiztxREOiIDF67L N4/g== X-Received: by 10.180.75.73 with SMTP id a9mr49961880wiw.45.1427392387384; Thu, 26 Mar 2015 10:53:07 -0700 (PDT) Received: from [31.133.166.135] (dhcp-a687.meeting.ietf.org. [31.133.166.135]) by mx.google.com with ESMTPSA id e18sm9369202wjz.27.2015.03.26.10.53.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 10:53:06 -0700 (PDT) Date: Thu, 26 Mar 2015 12:52:04 -0500 From: Dapeng Liu To: Alper Yegin Message-ID: <4CE129E555DF4375A64796B658BB6098@gmail.com> In-Reply-To: <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org> References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> <52AC56D3ADC0481CBF02BAADF720991B@gmail.com> <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55144744_4f93aad5_a9e" Archived-At: Cc: dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 17:53:22 -0000 --55144744_4f93aad5_a9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C=E4=B8=8B=E5=8D=8811:42=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A > > The point is: in the draft, whether support =E2=80=9Creachability=E2= =80=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C= sustained IP=E2=80=9D, but the truth is any type of IP address can provi= de =E2=80=9Creachability=E2=80=9D. So there is no clear dividing line bet= ween =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D in t= he definition. That is why the definition of the IP types is not valid. > =20 > =20 > =20 > =22IP address reachability=22 is about ability to reach the host at a s= pecific =22IP address=22 even when the host changes its point of attachme= nt. > You seem to interpret it as if it said =22IP reachability=22 (ability t= o reach the host using IP protocol), but that's not the case. > =20 No, I guess we have the same understanding regarding what is =E2=80=9C r= eachability=E2=80=9D here and still my question is: if we use =E2=80=9C r= eachability=E2=80=9D as characteristic to distinguish =E2=80=9Cfixed IP = address=E2=80=9D and =E2=80=9Csustained IP address=E2=80=9D, there will = be no clear dividing line between them. Dapeng =20 > =20 > That term is already defined in the I-D: > =20 > IP address reachability: The ability to maintain the same IP address fo= r an extended period of time. The IP address stays the same across indepe= ndent IP sessions, and even in the absence of any IP session. The IP addr= ess may be published in a long-term registry (e.g., DNS), and it is made = available for serving incoming (e.g., TCP) connections. IP address reacha= bility is essential for mobile hosts to use specific/published IP address= es. > =20 > =20 > > > > > > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2= =80=9D: > > > > > > =20 > > > > > > =E2=80=9C- Nomadic IP Address > > > > > > This type of IP address provides neither IP session continuit= y nor IP address reachability. The IP address is obtained from the servin= g IP gateway and it is not maintained across gateway changes. In other wo= rds, the IP address may be released and replaced by a new IP address when= the IP gateway changes due to the movement of the mobile =20 > > > > > > host.=E2=80=9D > > > > > > =20 > > > > > > Seems this IP address is the IP address that we normally used= in most cases. If this is the case, why we need a new name for it=3F > > > > > > =20 > > > > > =20 > > > > > =20 > > > > > If you don't name it, how would you refer to it in this context= =3F > > > > If the justification of naming IP address as =E2=80=9Cfixed IP=E2= =80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not = necessary need a new name for normal IP address. > > > > =20 > > > =20 > > > I and the WT=231 believe that justification is valid. > > > If you believe otherwise, please elaborate. > > > =20 > > > =20 > > > =20 > > > =20 > > =20 > > Pls see above comment. > > =20 > > Dapeng =20 > > > =20 > > > Alper > > > =20 > > > =20 > > > =20 > > > > =20 > > > > Dapeng =20 > > > > > =20 > > > > > =20 > > > > > Alper > > > > > =20 > > > > > =20 > > > > > > =20 > > > > > > -- =20 > > > > > > Dapeng Liu > > > > > > =20 > > > > > > =20 > > > > > > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F= =E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9= =81=93=EF=BC=9A > > > > > > =20 > > > > > > > Hello Dapeng and Alex, > > > > > > > =20 > > > > > > > I hope you had a chance to digest our responses to your com= ments and questions about the API work. > > > > > > > If you have any remaining issues, please let us know over t= he email at your earliest convenience. > > > > > > > It'd be good if you can articulate them in detail. > > > > > > > =20 > > > > > > > =20 > > > > > > > Thanks. > > > > > > > =20 > > > > > > > Alper =20 > > > > > > =20 > > > > > =20 > > > > =20 > > > =20 > > =20 > =20 --55144744_4f93aad5_a9e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=20
=E5=9C=A8 2015=E5=B9=B4= 3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D= =8811:42=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

The point is: in the draft, whether support =E2=80=9Creachabilit= y=E2=80=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80= =9C sustained IP=E2=80=9D, but the truth is any type of IP address can pr= ovide =E2=80=9Creachability=E2=80=9D. So there is no clear dividing line = between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80= =9D in the definition. That is why the definition of the IP types is not = valid.

=22IP address= reachability=22 is about ability to reach the host at a specific =22IP a= ddress=22 even when the host changes its point of attachment.
Y= ou seem to interpret it as if it said =22IP reachability=22 (ability to r= each the host using IP protocol), but that's not the case.

=
No, I guess we have the = same understanding regarding what is =E2=80=9C reachability=E2=80=9D= here and still my question is: if we use =E2=80=9C reachability=E2=80=9D= as characteristic to distinguish =E2=80=9Cfixed IP address=E2=80=9D= and =E2=80=9Csustained IP address=E2=80=9D, there will be no clear= dividing line between them.

Dape= ng

<= span>
That term is already defined in the I= -D:

IP = address reachability: The ability to maintain the same IP address for an extended period of time. The IP address stays the same across independent IP sessions, and even in the absence of any IP session. The IP address may be published in a long-term registry (e.g., DNS), and it is made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/published IP addresses.

3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D= :

=E2=80=9C- Nomadic IP Address
This type of IP address provides neither= IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile&= nbsp;
host.=E2=80=9D

Seems this= IP address is the IP address that we normally used in most cases. If thi= s is the case, why we need a new name for it=3F

If you don't name it, ho= w would you refer to it in this context=3F
=
If the justification of naming IP address as =E2=80=9Cf= ixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then w= e may not necessary need a new name for normal IP address.

=

I and the WT=231 believe tha= t justification is valid.
If you believe otherwise, please elab= orate.
Pls see abov= e comment.

Dapeng

Alper
=

=
Dapeng

Alper

<= blockquote type=3D=22cite=22>

--
=
Dapeng Liu

=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8= =89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93= =EF=BC=9A

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your c= omments and questions about the API work.
If you have any remai= ning issues, please let us know over the email at your earliest convenien= ce.
It'd be good if you can articulate them in detail.

Thanks.

Alper
=20 =20 =20 =20

=20 =20 =20 =20

=20 =20 =20 =20

=20 =20 =20 =20 =20

--55144744_4f93aad5_a9e-- From nobody Thu Mar 26 10:54:14 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221DD1A87B9 for ; Thu, 26 Mar 2015 10:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjauQGkQ3Puz for ; Thu, 26 Mar 2015 10:54:11 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9D71A8F37 for ; Thu, 26 Mar 2015 10:54:11 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so96603040wib.1 for ; Thu, 26 Mar 2015 10:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=tlBWMTX/BFL/nXJYcGCrBkZx8i1XTL2wIM+rnX40w9g=; b=ElFOjGSPcUK1BFDq4epBHBV4ttPEpbu85ZdOwuphwhA5giFSwdu1L6JwW/FJM1pKjq 42HOId2K+1zV9GgdbwwrhDcjSu+BTg5fsSYUpH5eW+AZPaXiR1eUfB2bVnW6m1i5LzLC S0XsQfg4cVnD/PMG8W23WbwlQCgTFnbpaezFuX2/5qZLNgNevkp5lfzH/+B/QjWEz0yR mwpfuDj2kGCnU7uM0w9QmBGxXJvt9HA1fAzhJRBnGtnH/b7Xnlqag9E1ny4jvgONhsG5 ilmVX/Y9VjgiI1ijQvFR19zWS4OYGkrZrKREmlgln5u4CRvLUlfL7tVRkKASUJ+/8amU b3xA== X-Received: by 10.180.187.171 with SMTP id ft11mr50658451wic.0.1427392450107; Thu, 26 Mar 2015 10:54:10 -0700 (PDT) Received: from [31.133.166.135] (dhcp-a687.meeting.ietf.org. [31.133.166.135]) by mx.google.com with ESMTPSA id hl15sm26314160wib.3.2015.03.26.10.54.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 10:54:09 -0700 (PDT) Date: Thu, 26 Mar 2015 12:52:54 -0500 From: Dapeng Liu To: Alper Yegin Message-ID: <272F5CDBAEC1453EA530EC284E8FEBC9@gmail.com> In-Reply-To: <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org> References: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> <52AC56D3ADC0481CBF02BAADF720991B@gmail.com> <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55144783_7b6c7dc6_a9e" Archived-At: Cc: dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 17:54:13 -0000 --55144783_7b6c7dc6_a9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C=E4=B8=8B=E5=8D=8811:42=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A > > The point is: in the draft, whether support =E2=80=9Creachability=E2= =80=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C= sustained IP=E2=80=9D, but the truth is any type of IP address can provi= de =E2=80=9Creachability=E2=80=9D. So there is no clear dividing line bet= ween =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D in t= he definition. That is why the definition of the IP types is not valid. > =20 > =20 > =20 > =22IP address reachability=22 is about ability to reach the host at a s= pecific =22IP address=22 even when the host changes its point of attachme= nt. > You seem to interpret it as if it said =22IP reachability=22 (ability t= o reach the host using IP protocol), but that's not the case. > =20 No, I guess we have the same understanding regarding what is =E2=80=9C r= eachability=E2=80=9D here and still my question is: if we use =E2=80=9C r= eachability=E2=80=9D as characteristic to distinguish =E2=80=9Cfixed IP = address=E2=80=9D and =E2=80=9Csustained IP address=E2=80=9D, there will = be no clear dividing line between them. Dapeng =20 > That term is already defined in the I-D: > =20 > IP address reachability: The ability to maintain the same IP address fo= r an extended period of time. The IP address stays the same across indepe= ndent IP sessions, and even in the absence of any IP session. The IP addr= ess may be published in a long-term registry (e.g., DNS), and it is made = available for serving incoming (e.g., TCP) connections. IP address reacha= bility is essential for mobile hosts to use specific/published IP address= es. > =20 > =20 > > > > > > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2= =80=9D: > > > > > > =20 > > > > > > =E2=80=9C- Nomadic IP Address > > > > > > This type of IP address provides neither IP session continuit= y nor IP address reachability. The IP address is obtained from the servin= g IP gateway and it is not maintained across gateway changes. In other wo= rds, the IP address may be released and replaced by a new IP address when= the IP gateway changes due to the movement of the mobile =20 > > > > > > host.=E2=80=9D > > > > > > =20 > > > > > > Seems this IP address is the IP address that we normally used= in most cases. If this is the case, why we need a new name for it=3F > > > > > > =20 > > > > > =20 > > > > > =20 > > > > > If you don't name it, how would you refer to it in this context= =3F > > > > If the justification of naming IP address as =E2=80=9Cfixed IP=E2= =80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not = necessary need a new name for normal IP address. > > > > =20 > > > =20 > > > I and the WT=231 believe that justification is valid. > > > If you believe otherwise, please elaborate. > > > =20 > > > =20 > > > =20 > > > =20 > > =20 > > Pls see above comment. > > =20 > > Dapeng =20 > > > =20 > > > Alper > > > =20 > > > =20 > > > =20 > > > > =20 > > > > Dapeng =20 > > > > > =20 > > > > > =20 > > > > > Alper > > > > > =20 > > > > > =20 > > > > > > =20 > > > > > > -- =20 > > > > > > Dapeng Liu > > > > > > =20 > > > > > > =20 > > > > > > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F= =E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9= =81=93=EF=BC=9A > > > > > > =20 > > > > > > > Hello Dapeng and Alex, > > > > > > > =20 > > > > > > > I hope you had a chance to digest our responses to your com= ments and questions about the API work. > > > > > > > If you have any remaining issues, please let us know over t= he email at your earliest convenience. > > > > > > > It'd be good if you can articulate them in detail. > > > > > > > =20 > > > > > > > =20 > > > > > > > Thanks. > > > > > > > =20 > > > > > > > Alper =20 > > > > > > =20 > > > > > =20 > > > > =20 > > > =20 > > =20 > =20 --55144783_7b6c7dc6_a9e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=20
=E5=9C=A8 2015=E5=B9=B4= 3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D= =8811:42=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

The point is: in the draft, whether support =E2=80=9Creachabilit= y=E2=80=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80= =9C sustained IP=E2=80=9D, but the truth is any type of IP address can pr= ovide =E2=80=9Creachability=E2=80=9D. So there is no clear dividing line = between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80= =9D in the definition. That is why the definition of the IP types is not = valid.

=22IP address= reachability=22 is about ability to reach the host at a specific =22IP a= ddress=22 even when the host changes its point of attachment.
Y= ou seem to interpret it as if it said =22IP reachability=22 (ability to r= each the host using IP protocol), but that's not the case.

=
No, I guess we hav= e the same understanding regarding what is =E2=80=9C reachability=E2= =80=9D here and still my question is: if we use =E2=80=9C reachability=E2= =80=9D as characteristic to distinguish =E2=80=9Cfixed IP address=E2= =80=9D and =E2=80=9Csustained IP address=E2=80=9D, there will be no= clear dividing line between them.

Dapeng

<= div>
That term is already defined in the I-D:
IP address reachabil= ity: The ability to maintain the same IP address for an extended period of time. The IP address stays the same across independent IP sessions, and even in the absence of any IP session. The IP address may be published in a long-term registry (e.g., DNS), and it is made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/published IP addresses.

3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D= :

=E2=80=9C- Nomadic IP Address
This type of IP address provides neither= IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile&= nbsp;
host.=E2=80=9D

Seems this= IP address is the IP address that we normally used in most cases. If thi= s is the case, why we need a new name for it=3F

If you don't name it, ho= w would you refer to it in this context=3F
=
If the justification of naming IP address as =E2=80=9Cf= ixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then w= e may not necessary need a new name for normal IP address.

=

I and the WT=231 believe tha= t justification is valid.
If you believe otherwise, please elab= orate.
Pls see abov= e comment.

Dapeng

Alper
=

=
Dapeng

Alper

<= blockquote type=3D=22cite=22>

--
=
Dapeng Liu

=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8= =89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93= =EF=BC=9A

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your c= omments and questions about the API work.
If you have any remai= ning issues, please let us know over the email at your earliest convenien= ce.
It'd be good if you can articulate them in detail.

Thanks.

Alper
=20 =20 =20 =20

=20 =20 =20 =20

=20 =20 =20 =20

=20 =20 =20 =20

--55144783_7b6c7dc6_a9e-- From nobody Thu Mar 26 10:54:54 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DEC1A8F4A for ; Thu, 26 Mar 2015 10:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuFfWrJODGNZ for ; Thu, 26 Mar 2015 10:54:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EA51A8A44 for ; Thu, 26 Mar 2015 10:54:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUE25169; Thu, 26 Mar 2015 17:54:39 +0000 (GMT) Received: from SZXEML427-HUB.china.huawei.com (10.82.67.182) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 17:54:39 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.158]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 01:54:33 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KA Date: Thu, 26 Mar 2015 17:54:32 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521EFCA4@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.73] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521EFCA4szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 17:54:53 -0000 --_000_6E31144C030982429702B11D6746B98C521EFCA4szxeml557mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXMgYXNrZWQgdG8gcHJvdmlkZSBtb3JlIGV4cGxhbmF0aW9uIGFib3V0IGFuY2hvcmluZy4N Cg0KRGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBtYXkgaGF2ZSBhbmNob3JpbmcgZnVu Y3Rpb25hbGl0eSBpbiBkaWZmZXJlbnQgbmV0d29ya3Mgc28gdGhhdCByb3V0ZXMgZG8gbm90IG5l ZWQgdG8gdHJhdmVyc2UgYSBjZW50cmFsaXplZCBhbmNob3IuDQoNCllldCwgdGhlIGRlZmluaXRp b24gb2YgImFuY2hvcmluZyBmdW5jdGlvbiIgKEFGKSBpbiBSRkMgNzMzMyBpcyBpbiB0ZXJtcyBv ZiByb3V0ZSBhZHZlcnRpc2VtZW50IGZvciB0aGUgSVAgYWRkcmVzcyBvbmx5LCBhbmQgc3VjaCBm dW5jdGlvbiBpcyBhdmFpbGFibGUgaW4gbXVsdGlwbGUgbmV0d29yay4NCg0KU28gd2hhdCBhcmUg dGhlIHJlc3Qgb2YgdGhlIGZ1bmN0aW9ucz8NCg0KU3VjaCBmdW5jdGlvbnMgbWF5IHRlbmQgdG8g Y2F1c2UgdGhlIHBhY2tldHMgdG8gdHJhdmVyc2UgY2VydGFpbiBub2Rlcy4NCg0KQ29uc2lkZXIg YSB0eXBpY2FsIGhhbmRvdmVyIHNjZW5hcmlvOiBNTiBtb3ZlcyBmcm9tIE5ldDEgbW92ZXMgdG8g TmV0MiwgYW5kIENOIGlzIGluIE5ldDMNCg0KVGhlIG9sZCBBUiAoQVIxKSBvZiBNTiBpbiBOZXQx IHBlcmZvcm1zIFJBIGZvciBJUDE7IHRoZSBuZXcgQVIgKEFSMikgb2YgTU4gaW4gTmV0MiBwZXJm b3JtcyBSQSBmb3IgSVAyOyB0aGUgQVIgKEFSMykgb2YgQ04gaW4gTmV0MyBwZXJmb3JtcyBSQSBm b3IgSVAzLg0KDQpUaGUgYWRkaXRpb25hbCBmdW5jdGlvbnMgYXQgQVIxIGFuZCBBUjIgYm90aCB0 cnkgdG8gY2F1c2UgdGhlIHBhY2tldHMgb2YgdGhlIGZsb3cgdG8gdHJhdmVyc2UgdGhlbS4gSWYg d2UgY2FsbCB0aGVzZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBwYXJ0IG9mIGRpc3RyaWJ1dGVkIGFu Y2hvcmluZyBmdW5jdGlvbiwgdGhlIHF1ZXN0aW9uIGlzIHdoYXQgdGhleSBhcmUgYW5jaG9yaW5n Lg0KDQpTbyBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb24gb2YgQUYsIEFSMSBwZXJmb3JtcyBB RiBmb3IgSVAxOyBBUjIgcGVyZm9ybXMgQUYgZm9yIElQMiAobm90IElQMSk7IGFuZCBBUjMgcGVy Zm9ybXMgQUYgZm9yIElQMy4NCg0KT25lIGFwcHJvYWNoIGlzIHRvIGJvcnJvdyB0aGUgd2VsbCBr bm93biBjb25jZXB0IG9mIHNlcGFyYXRpb24gb2Ygc2Vzc2lvbiBJRCAoU0lEKSBmcm9tIHJvdXRp bmcgYWRkcmVzcy4gVGhlcmUgYXJlIHRvbnMgb2YgcGFwZXJzIGFkZHJlc3Npbmcgc3VjaCBzZXBh cmF0aW9uLCBhbmQgdGhlIGxhY2sgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIGNvbnNpZGVyZWQgdGhl IGZ1bmRhbWVudGFsIHByb2JsZW0gb2YgYnJlYWtpbmcgc2Vzc2lvbiBhcyBhbiBJUCBhZGRyZXNz IGNoYW5nZXMgZHVyaW5nIGhhbmRvdmVyLg0KDQpJbiBsaW5lIHdpdGggdGhpcyBzZXBhcmF0aW9u LCB0aGUgZnVuY3Rpb24gb2YgYW5jaG9yaW5nIG9mIGEgc2Vzc2lvbi9mbG93IGNhbiBiZSBzZXBh cmF0ZWQgZnJvbSB0aGF0IG9mIGFuY2hvcmluZyBhbiBJUCBhZGRyZXNzLg0KDQpUaGUgc2VwYXJh dGlvbiBvZiBzZXNzaW9uIElEIGFuZCByb3V0aW5nIGFkZHJlc3MgY2FuIGJlIGNvbnNpZGVyZWQg YSBnZW5lcmFsaXphdGlvbiwgYmVjYXVzZSB0aGUgc2Vzc2lvbiBJRCBjYW4gYmUgYW55dGhpbmcu IEFuIGV4YW1wbGUgaXMgSElUIGluIHRoZSBJRVRGIHByb3RvY29sIEhJUC4NCg0KVGhlIHVzZSBv ZiBIb0EgYW5kIENvQSBjYW4gYmUgY29uc2lkZXJlZCBhIHBhcnRpY3VsYXIgY2FzZSBvZiBTSUQg YW5kIHJvdXRpbmcgYWRkcmVzcyBzZXBhcmF0aW9uLiBJbiB1c2luZyBpbmRpcmVjdGlvbiwgb25l IElQIGFkZHJlc3MgKENvQSkgaXMgdXNlZCBmb3Igcm91dGluZywgd2hlcmVhcyBhbm90aGVyIElQ IGFkZHJlc3MgKEhvQSkgaXMgdXNlZCBpbiB0aGUgc29ja2V0IGFzIHBhcnQgb2YgdGhlIFNJRCBp ZGVudGlmaWNhdGlvbi4NCg0KQW5vdGhlciBJRVRGIHByb3RvY29sIG9mIHN1Y2ggc2VwYXJhdGlv biBpcyBMSVNQLg0KDQpJbiBvbmUgZXhhbXBsZSBvZiBoYW5kb3ZlciBzY2VuYXJpbyB0aGUgZGVz aXJlZCBwYXRoIGNhbiBiZToNCg0KcGFja2V0IGZyb20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRv IHdoaWNoIElQMyBpcyBhbmNob3JlZC4NCg0KaXQgdGhlbiBnb2VzIHRvIEFSMSwgdG8gd2hpY2gg SVAxIGlzIGFuY2hvcmVkLg0KDQppdCB0aGVuIGdvZXMgdG8gQVIyLCB0byB3aGljaCBJUDIgaXMg YW5jaG9yZWQuDQoNCldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IHRvIGdvIHRo aXMgd2F5IG1heSBiZToNCg0KQVIyIGhhcyB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb246IHRoZSBi aW5kaW5nIG9mIFNJRCBvZiB0aGUgZmxvdyAoSVAxKSB0byBJUCBhZGRyZXNzIG9mIEFSMi4gSXQg c2VuZHMgdGhpcyBpbmZvcm1hdGlvbiB0byBBUjEuDQoNClN1Y2ggYWRkaXRpb25hbCBmdW5jdGlv biBiYXNpY2FsbHkgdHJpZXMgdG8gY2F1c2UgdGhlIHBhY2tldHMgb2YgdGhlIGZsb3cgKElQMSkg dG8gdHJhdmVyc2UgQVIxIGFuZCBBUjIuDQoNCkluIGFub3RoZXIgZXhhbXBsZSBvZiB0aGlzIHNh bWUgc2NlbmFyaW8sIHRoZSBkZXNpcmVkIHBhdGggaXM6DQoNCnBhY2tldCBmcm9tIENOIGZpcnN0 IGdvZXMgdG8gQVIzLCB0byB3aGljaCBJUDMgaXMgYW5jaG9yZWQuDQoNCml0IHRoZW4gZ29lcyBk aXJlY3RseSB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBhbmNob3JlZC4NCg0KV2hhdCBjYXVzZXMg dGhlIHBhY2tldHMgb2YgdGhlIGZsb3cgdG8gZ28gdGhpcyB3YXkgbWF5IGJlOg0KDQpBUjMgaGFz IHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbjogdGhlIGJpbmRpbmcgb2YgU0lEIG9mIHRoZSBmbG93 IChJUDEpIHRvIElQIGFkZHJlc3Mgb2YgQVIyLg0KDQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgYW55 IG9mIHRoZXNlIGlzIG5vdCBjbGVhciBlbm91Z2guIFRoYW5rIHlvdS4NCg0KSCBBbnRob255IENo YW4NCg0KDQoNCg0KDQoNCg== --_000_6E31144C030982429702B11D6746B98C521EFCA4szxeml557mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkkgd2FzIGFza2VkIHRvIHByb3ZpZGUgbW9yZSBleHBsYW5hdGlvbiBhYm91dCBhbmNo b3Jpbmc8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Ljwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQgbWF5IGhhdmUgYW5jaG9yaW5nIGZ1bmN0 aW9uYWxpdHkgaW4gZGlmZmVyZW50IG5ldHdvcmtzIHNvIHRoYXQgcm91dGVzIGRvIG5vdCBuZWVk IHRvIHRyYXZlcnNlIGEgY2VudHJhbGl6ZWQgYW5jaG9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WWV0LCB0 aGUgZGVmaW5pdGlvbiBvZiAmcXVvdDthbmNob3JpbmcgZnVuY3Rpb24mcXVvdDsgKEFGKSZuYnNw O2luIFJGQyA3MzMzIGlzIGluIHRlcm1zIG9mIHJvdXRlIGFkdmVydGlzZW1lbnQgZm9yIHRoZSBJ UCBhZGRyZXNzIG9ubHksIGFuZCBzdWNoJm5ic3A7ZnVuY3Rpb24gaXMgYXZhaWxhYmxlIGluIG11 bHRpcGxlIG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TbyB3aGF0IGFyZSB0aGUgcmVzdCBvZiB0 aGUgZnVuY3Rpb25zPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWNoIGZ1bmN0aW9ucyBtYXkgdGVuZCB0 byBjYXVzZSB0aGUgcGFja2V0cyB0byB0cmF2ZXJzZSBjZXJ0YWluIG5vZGVzLg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Db25zaWRlciBhIHR5cGljYWwgaGFuZG92ZXImbmJzcDtzY2VuYXJpbzogTU4gbW92 ZXMgZnJvbSBOZXQxIG1vdmVzIHRvIE5ldDIsIGFuZCBDTiBpcyBpbiBOZXQzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5UaGUgb2xkIEFSIChBUjEpIG9mIE1OJm5ic3A7aW4gTmV0MSBwZXJmb3JtcyBSQSBmb3Ig SVAxOyB0aGUgbmV3IEFSIChBUjIpIG9mIE1OIGluIE5ldDIgcGVyZm9ybXMgUkEgZm9yIElQMjsg dGhlIEFSIChBUjMpIG9mIENOIGluIE5ldDMgcGVyZm9ybXMgUkEgZm9yIElQMy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBhdCBBUjEgYW5kIEFSMiBib3RoIHRyeSB0 byBjYXVzZSB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyB0byB0cmF2ZXJzZSB0aGVtLiBJZiB3ZSBj YWxsIHRoZXNlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHBhcnQgb2YgZGlzdHJpYnV0ZWQgYW5jaG9y aW5nIGZ1bmN0aW9uLCB0aGUgcXVlc3Rpb24NCiBpcyB3aGF0IHRoZXkgYXJlIGFuY2hvcmluZy4g PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U28gYWNjb3JkaW5nIHRvIHRoZSZuYnNwO2RlZmluaXRp b24gb2YgQUYsIEFSMSBwZXJmb3JtcyBBRiBmb3IgSVAxOyBBUjIgcGVyZm9ybXMgQUYgZm9yIElQ MiAobm90IElQMSk7IGFuZCBBUjMgcGVyZm9ybXMgQUYgZm9yIElQMy4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+T25lIGFwcHJvYWNoIGlzIHRvIGJvcnJvdyB0aGUgd2VsbCBrbm93biBjb25jZXB0IG9mIHNl cGFyYXRpb24gb2Ygc2Vzc2lvbiBJRCAoU0lEKSBmcm9tIHJvdXRpbmcgYWRkcmVzcy4gVGhlcmUg YXJlIHRvbnMgb2YgcGFwZXJzIGFkZHJlc3Npbmcgc3VjaCBzZXBhcmF0aW9uLCBhbmQgdGhlIGxh Y2sgb2Ygc3VjaCBzZXBhcmF0aW9uDQogaXMgY29uc2lkZXJlZCB0aGUgZnVuZGFtZW50YWwgcHJv YmxlbSBvZiBicmVha2luZyBzZXNzaW9uJm5ic3A7YXMgYW4gSVAgYWRkcmVzcyBjaGFuZ2VzIGR1 cmluZyBoYW5kb3Zlci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4gbGluZSB3aXRoIHRoaXMgc2VwYXJh dGlvbiwgdGhlIGZ1bmN0aW9uIG9mIGFuY2hvcmluZyBvZiBhIHNlc3Npb24vZmxvdyBjYW4gYmUg c2VwYXJhdGVkIGZyb20gdGhhdCBvZiBhbmNob3JpbmcgYW4gSVAgYWRkcmVzcy4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VGhlIHNlcGFyYXRpb24gb2Ygc2Vzc2lvbiBJRCBhbmQgcm91dGluZyBhZGRyZXNz IGNhbiBiZSBjb25zaWRlcmVkIGEgZ2VuZXJhbGl6YXRpb24sIGJlY2F1c2UgdGhlIHNlc3Npb24g SUQgY2FuIGJlIGFueXRoaW5nLiBBbiBleGFtcGxlIGlzIEhJVCBpbiB0aGUgSUVURiBwcm90b2Nv bCBISVAuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSB1c2Ugb2YgSG9BIGFuZCBDb0EgY2FuIGJlIGNv bnNpZGVyZWQgYSBwYXJ0aWN1bGFyIGNhc2Ugb2YgU0lEIGFuZCByb3V0aW5nIGFkZHJlc3Mgc2Vw YXJhdGlvbi4gSW4gdXNpbmcgaW5kaXJlY3Rpb24sIG9uZSBJUCBhZGRyZXNzIChDb0EpIGlzIHVz ZWQgZm9yIHJvdXRpbmcsIHdoZXJlYXMgYW5vdGhlciBJUCBhZGRyZXNzDQogKEhvQSkgaXMgdXNl ZCBpbiB0aGUgc29ja2V0IGFzIHBhcnQgb2YgdGhlIFNJRCBpZGVudGlmaWNhdGlvbi4gPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Bbm90aGVyIElFVEYgcHJvdG9jb2wgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIExJ U1AuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIG9uZSBleGFtcGxlIG9mIGhhbmRvdmVyIHNjZW5hcmlv IHRoZSBkZXNpcmVkIHBhdGggY2FuIGJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGFja2V0IGZyb20gQ04g Zmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+aXQgdGhlbiBnb2VzIHRvIEFSMSwgdG8gd2hpY2ggSVAxIGlzIGFuY2hvcmVkLg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5pdCB0aGVuIGdvZXMgdG8gQVIyLCB0byB3aGljaCBJUDIgaXMgYW5jaG9y ZWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93 IHRvIGdvIHRoaXMgd2F5IG1heSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFSMiBoYXMgdGhlIGxvY2F0 aW9uIGluZm9ybWF0aW9uOiB0aGUgYmluZGluZyBvZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAoSVAx KSB0byBJUCBhZGRyZXNzIG9mIEFSMi4gSXQgc2VuZHMgdGhpcyBpbmZvcm1hdGlvbiB0byBBUjEu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5TdWNoIGFkZGl0aW9uYWwgZnVuY3Rpb24gYmFzaWNhbGx5IHRyaWVz IHRvIGNhdXNlIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IChJUDEpIHRvIHRyYXZlcnNlIEFSMSBh bmQgQVIyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbiBhbm90aGVyIGV4YW1wbGUgb2YgdGhpcyBzYW1l IHNjZW5hcmlvLCB0aGUgZGVzaXJlZCBwYXRoIGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGFja2V0IGZy b20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPml0IHRoZW4gZ29lcyBkaXJlY3RseSB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBh bmNob3JlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBm bG93IHRvIGdvIHRoaXMgd2F5IG1heSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFSMyBoYXMgdGhlIGxv Y2F0aW9uIGluZm9ybWF0aW9uOiB0aGUgYmluZGluZyBvZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAo SVAxKSB0byBJUCBhZGRyZXNzIG9mIEFSMi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGxlYXNlIGxldCBt ZSBrbm93IGlmIGFueSBvZiB0aGVzZSBpcyBub3QgY2xlYXIgZW5vdWdoLiBUaGFuayB5b3UuDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkggQW50aG9ueSBDaGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E31144C030982429702B11D6746B98C521EFCA4szxeml557mbxchi_-- From nobody Thu Mar 26 11:01:03 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB581AD36E for ; Thu, 26 Mar 2015 11:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QY_SSrMZp3u for ; Thu, 26 Mar 2015 11:00:59 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E0E1A9053 for ; Thu, 26 Mar 2015 11:00:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QI0sZs016105 for ; Thu, 26 Mar 2015 19:00:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 815F4204E70 for ; Thu, 26 Mar 2015 19:01:39 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7996C200CD8 for ; Thu, 26 Mar 2015 19:01:39 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.136]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QI0pOZ024701 for ; Thu, 26 Mar 2015 19:00:53 +0100 Message-ID: <55144953.8070104@gmail.com> Date: Thu, 26 Mar 2015 13:00:51 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> In-Reply-To: <54E60579.5090401@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:01:02 -0000 Le 19/02/2015 10:47, Alexandru Petrescu a �crit : > Le 19/02/2015 16:30, Alper Yegin a �crit : >>>> >>>> This is source address selection, hence multicast address is out-of >>>> picture. Unicast vs anycast distinction is orthogonal to mobility >>>> type of the address. >>>> >>>>> - MAC-based, random-based (RFC7217). >>>> >>>> Orthogonal. >>> >>> ? One wouldn't want her 'fixed' address (not the 'sustained', not >>> the 'nomadic') be a random-based address RFC7217. That RFC's abstract >>> says: >>>> This document specifies a method for generating IPv6 Interface >>>> Identifiers to be used with IPv6 Stateless Address Autoconfiguration >>>> (SLAAC), such that an IPv6 address configured using this method is >>>> stable within each subnet, but the corresponding Interface >>>> Identifier changes when the host moves from one network to another. >>> >>> >> >> When using the "fixed" IP address, the host stays connected to the same >> (logical/home) network at all times, anyways. >> Hence, by the above definition, there's no reason to change the >> interface ID. > > I thought by "fixed" you meant it stays the same wherever the Host goes > (something like the Home Address). Alper - I think a LL address can also be qualified as 'fixed' - it never changes. I think it's hard to disagree with that, no? Alex > > So, I guess, I should have referred to the "nomadic" address to mean the > one that is constant, wherever the Host goes. > > As such, my suggestion is that a "nomadic" address can never be an > RFC7217 address. > > In practice that would mean that if you configure an address to be > "nomadic" you must also tell the kernel to not run RFC7217 on it. > > But ok, one might think that these two aspects ("nomadic" and RFC7217) > are orthogonal at this point in time. > > Alex > >> >> I don't know if it makes sense to request a fixed and random-based IP >> address. But if someone does it, it works. > > >> >> Alper >> >> >> >> >>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC >>>>> 6775). >>>>> >>>> >>>> Orthogonal. >>>> >>>> >>>>> E.g. a nomadic address could never be a link-local address. >>>>> >>>>>> #2. Describe how IP address type information is conveyed from >>>>>> network to MN. >>>>> >>>>> If one designs a protocol to convey address type information from >>>>> the network to the end node, then one could also add the other >>>>> types mentioned above. >>>>> >>>>> SLAAC could never 'convey' the address type to the end-node, >>>>> because SLAAC is an operation happening with as heavy weight from >>>>> the Server (router) as from the Client (Host): the Router decides >>>>> the prefix but the Client decides the Interface ID. >>>>> >>>> >>>> Still, the network can convey the type of IP address to the host. >>>> Also, one can imagine augmenting Router Solicitation to let the host >>>> convey its requested type. >>> >>> I agree. >>> >>> Alex >>> >>> >>>>> Address Registration Option of 6lo and BTLE would have the Host >>>>> conveying this information to the Router (and not vice-versa). >>>>> >>>> >>>> OK. >>>> >>>> Alper >>>> >>>> >>>>> Yours, >>>>> >>>>> Alex >>>>> >>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the >>>>>> baseline for item#1 (the API). A revision of the draft will also >>>>>> include a new section to cover backward compatibility (Danny will >>>>>> provide the draft text). Comments on the draft are welcome. >>>>>> >>>>>> The next call will be about items #2/#3 (IP address >>>>>> configuration enhancements associated with the API). We intend to >>>>>> schedule that one in about 2 weeks. >>>>>> >>>>>> Alper >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: >>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> See below for the Webex details. Remember, the call is on Tue, >>>>>>> Feb 10, at 4pm CET. And don't forget to read the documents in >>>>>>> the reading list prior to the call. >>>>>>> >>>>>>>> Attendees _shall read _the following material before the call >>>>>>>> so that we can directly jump to the discussions: >>>>>>>> >>>>>>>> 1. >>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>> >>>>>>>> >>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>> 3. >>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>> >>>>>>>> >>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Alper >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February >>>>>>> 2015 16:00 | Europe Time (Paris, GMT+01:00) | 1 hr 30 min >>>>>>> >>>>>>>> *Join WebEx meeting* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>> Meeting number:641 085 326 >>>>>>>> Meeting password:dmm1911 >>>>>>>> >>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number >>>>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada) >>>>>>>> Access code: 641 085 326 Toll-free calling restrictions >>>>>>>> >>>>>>>> >>>>>>>> Add this meeting >>>>>>>> >>>>>>>> >>>>>>>> to your calendar. >>>>>>>> >>>>>>>> Can't join the meeting? Contact support. >>>>>>>> >>>>>>>> >>>>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows >>>>>>>> audio and other information sent during the session to be >>>>>>>> recorded, which may be discoverable in a legal matter. By >>>>>>>> joining this session, you automatically consent to such >>>>>>>> recordings. If you do not consent to being recorded, discuss >>>>>>>> your concerns with the host or do not join the session. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: >>>>>>> >>>>>>>> Poll is closed, and majority selected the following date for >>>>>>>> the call: >>>>>>>> >>>>>>>> Feb 10, 4pm CET. 1,5hr call. >>>>>>>> >>>>>>>> Please mark your calendars. >>>>>>>> >>>>>>>> In this call, we'll aim making progress on the I-D for item#1 >>>>>>>> (an API for source address selection). >>>>>>>> >>>>>>>> Attendees _shall read _the following material before the call >>>>>>>> so that we can directly jump to the discussions: >>>>>>>> >>>>>>>> 1. >>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>> >>>>>>>> >>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>> 3. >>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>> >>>>>>>> >>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>> >>>>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote: >>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> Please mark your availability on the following doodle for >>>>>>>>> our next DMM WG Mobility Exposure and Selection WT call: >>>>>>>>> >>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur >>>>>>>>> >>>>>>>>> Register your availability no later than the end of Monday >>>>>>>>> (Jan 26). >>>>>>>>> >>>>>>>>> Alper >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>> >>>>> >>>>> >>>>> _______________________________________________ dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >>>> >>>> >>> >>> >> > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > From nobody Thu Mar 26 11:01:32 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF1B1B29CA for ; Thu, 26 Mar 2015 11:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Cj3HytvO1Uw for ; Thu, 26 Mar 2015 11:01:27 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7EA1AD36E for ; Thu, 26 Mar 2015 11:01:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QI1OWt016327; Thu, 26 Mar 2015 19:01:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 32D3D204E70; Thu, 26 Mar 2015 19:02:09 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 26492200CD8; Thu, 26 Mar 2015 19:02:09 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.136]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QI1MY5025560; Thu, 26 Mar 2015 19:01:23 +0100 Message-ID: <55144971.5080208@gmail.com> Date: Thu, 26 Mar 2015 13:01:21 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alper Yegin References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> In-Reply-To: <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:01:31 -0000 Le 13/02/2015 03:09, Alper Yegin a �crit : > Hello Alex, > >> I looked at the slides. I think I understand the concept of type >> of IP address from a mobility perspective: fixed, sustained, >> nomadic. >> >> I have remarks: - could an aquired prefix (DHCPv6 PD) also be >> qualified as fixed, sustained, nomadic? > > Yes. > >> - how would a mobility address type relate to other address >> 'types'? - link-local, ULA, global. > > Link-local can only be nomadic. I disagree. A LL can also be 'fixed', because it's fixed. > Global can be any type. Ok. > We cannot assure a ULA address stays the same > (considering border crossings), hence it can only be nomadic. But it can also be sustained. >> - unicast, anycast, multicast. > > This is source address selection, hence multicast address is out-of > picture. Unicast vs anycast distinction is orthogonal to mobility > type of the address. So all SUSTAINED, NOMADIC, FIXED addresses can only be unicast, right? >> - MAC-based, random-based (RFC7217). > > Orthogonal. What does that mean? orthogonal? Alex > >> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC >> 6775). >> > > Orthogonal. > > >> E.g. a nomadic address could never be a link-local address. >> >>> #2. Describe how IP address type information is conveyed from >>> network to MN. >> >> If one designs a protocol to convey address type information from >> the network to the end node, then one could also add the other >> types mentioned above. >> >> SLAAC could never 'convey' the address type to the end-node, >> because SLAAC is an operation happening with as heavy weight from >> the Server (router) as from the Client (Host): the Router decides >> the prefix but the Client decides the Interface ID. >> > > Still, the network can convey the type of IP address to the host. > Also, one can imagine augmenting Router Solicitation to let the host > convey its requested type. > > >> Address Registration Option of 6lo and BTLE would have the Host >> conveying this information to the Router (and not vice-versa). >> > > OK. > > Alper > > >> Yours, >> >> Alex >> >>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the >>> baseline for item#1 (the API). A revision of the draft will also >>> include a new section to cover backward compatibility (Danny will >>> provide the draft text). Comments on the draft are welcome. >>> >>> The next call will be about items #2/#3 (IP address >>> configuration enhancements associated with the API). We intend to >>> schedule that one in about 2 weeks. >>> >>> Alper >>> >>> >>> >>> >>> >>> >>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: >>> >>>> Folks, >>>> >>>> See below for the Webex details. Remember, the call is on Tue, >>>> Feb 10, at 4pm CET. And don't forget to read the documents in >>>> the reading list prior to the call. >>>> >>>>> Attendees _shall read _the following material before the call >>>>> so that we can directly jump to the discussions: >>>>> >>>>> 1. >>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>> >>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>> 3. >>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>> >>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>> >>>> >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> >>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February >>>> 2015 16:00 | Europe Time (Paris, GMT+01:00) | 1 hr 30 min >>>> >>>>> *Join WebEx meeting* >>>>> >>>>> >>>>> >>>>> Meeting number: 641 085 326 >>>>> Meeting password: dmm1911 >>>>> >>>>> *Join by phone* *1-877-668-4493* Call-in toll free number >>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada) >>>>> Access code: 641 085 326 Toll-free calling restrictions >>>>> >>>>> >>>>> Add this meeting >>>>> >>>>> to your calendar. >>>>> >>>>> Can't join the meeting? Contact support. >>>>> >>>>> >>>>> IMPORTANT NOTICE: Please note that this WebEx service allows >>>>> audio and other information sent during the session to be >>>>> recorded, which may be discoverable in a legal matter. By >>>>> joining this session, you automatically consent to such >>>>> recordings. If you do not consent to being recorded, discuss >>>>> your concerns with the host or do not join the session. >>>>> >>>> >>>> >>>> >>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: >>>> >>>>> Poll is closed, and majority selected the following date for >>>>> the call: >>>>> >>>>> Feb 10, 4pm CET. 1,5hr call. >>>>> >>>>> Please mark your calendars. >>>>> >>>>> In this call, we'll aim making progress on the I-D for item#1 >>>>> (an API for source address selection). >>>>> >>>>> Attendees _shall read _the following material before the call >>>>> so that we can directly jump to the discussions: >>>>> >>>>> 1. >>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>> >>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>> 3. >>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>> >>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>> >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> Please mark your availability on the following doodle for >>>>>> our next DMM WG Mobility Exposure and Selection WT call: >>>>>> >>>>>> http://doodle.com/7xgcr8x6cgxnbzur >>>>>> >>>>>> Register your availability no later than the end of Monday >>>>>> (Jan 26). >>>>>> >>>>>> Alper >>>>>> >>>>> >>>> >>> >>> >>> >>> _______________________________________________ dmm mailing list >>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>> >> >> >> _______________________________________________ dmm mailing list >> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > > From nobody Thu Mar 26 11:13:39 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562511A88F3 for ; Thu, 26 Mar 2015 11:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.85 X-Spam-Level: X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34v6iAp2I6de for ; Thu, 26 Mar 2015 11:13:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555681A9086 for ; Thu, 26 Mar 2015 11:13:35 -0700 (PDT) Received: from [10.119.8.1] ([31.7.59.44]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0Lvj4s-1ZXbL83Imi-017UbP; Thu, 26 Mar 2015 19:13:27 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DCCC73CA-F585-49FD-BD14-C3E981D54324" From: Alper Yegin In-Reply-To: Date: Thu, 26 Mar 2015 20:13:22 +0200 Message-Id: References: To: Weixinpeng (Jackie) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:Obnhh1d/HMimrqRQBynqZkW3Wft81z4DMdq1QpC8+i+5w9khI/H B635uCOj7NrzM3eGUOLmuTixhcRYobsXAkTSEMttx5EJUV6ckjLq1dwXuZwPPkOIUhy3XbZ /mN7YJyx15Lvs4i/QxBNaB/tt0bcJDqNhzg1Qv81+tcqXPnrjhbo70qQMIGOvZrFA6egzXF OuoXPbYU88oGjQHTr2+3w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Re=EF=BC=9A_DMM_API?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:13:38 -0000 --Apple-Mail=_DCCC73CA-F585-49FD-BD14-C3E981D54324 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Xinpeng, If your app knows how to deal with IP address changes, then it's better = if we give it a chance to do so, because (as the I-D explains): Achieving IP session continuity and IP address reachability by using Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP session continuity and IP address reachability should be be provided only when needed. Alper On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote: > Hi Alper > My understanding about the reason why there needs to define serval = types of IP prefixes is that, if the application itself could deal with = the change of IP address, i.e. the application itself could deal with = session continuty in case of IP address change, so the host would choose = a normadic address otherwise the host should choose a sustained address. > But my question is that, if the application could deal with session = continuty itself, does that mean the application is willing to change = its IP address? Because even though a new address might bring some kinds = of benefit, but it will also > bring additional cost for application to deal with IP address change. > Thanks. > =20 > Xinpeng > =20 > =20 > =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng Liu = [maxpassion@gmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5 5:01 > =CA=D5=BC=FE=C8=CB: Alper Yegin > =B3=AD=CB=CD: dmm@ietf.org > =D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA DMM API >=20 > Hello Alper, >=20 > I still have the following comments: >=20 > 1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the = draft: >=20 > =A1=B0- Fixed IP Address > This is what standard Mobile IP provides with a Home Address (HoA). > The mobile host is configures a HoA from a centrally-located Home > Network. Both IP session continuity and IP address reachability = are > provided to the mobile host with the help of a router in the Home > Network (Home Agent, HA). This router acts as an anchor for the IP=20= > address of the mobile host.=A1=B1=20 >=20 > If this is equal to HoA, then RFC5014 already cover that. We do not = need to repeat it here with another name. >=20 > 2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in the = draft: >=20 > "- Sustained IP Address >=20 > This type of IP address provides IP session continuity but not IP > address reachability. It is achieved by ensuring that the IP = address > used at the beginning of the session remains usable despite the > movement of the mobile host. The IP address may change after the > termination of the IP session(s), therefore it does not exhibit > persistence. > " > There is no clear dividing line between fixed IP address and sustained = IP address. Whether the IP address is used for reachability is not = determined by the IP address itself. For example, even when the MN get a = HoA, after it moves to another location of the network, it may decide to = release current HoA and get another HoA, in this case the "fixed IP = address" becomes a "sustained IP address". >=20 > Further more, the reachability normally is implemented by domain name = instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its = domain name, never by it=A1=AFs server=A1=AFs IP address.=20 >=20 > Using temporary private IP address we can also achieve the goal of = =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in = http://hsk.oray.com/ , it can provide reachability even the host get a = private IP address. >=20 > 3. Regarding the definition of =A1=B0nomadic IP address=A1=B1: >=20 > =A1=B0- Nomadic IP Address > This type of IP address provides neither IP session continuity nor = IP > address reachability. The IP address is obtained from the serving = IP > gateway and it is not maintained across gateway changes. In other > words, the IP address may be released and replaced by a new IP > address when the IP gateway changes due to the movement of the = mobile=20 > host.=A1=B1 >=20 > Seems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for it? >=20 >=20 > --=20 > Dapeng Liu >=20 > =D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:0= 2=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA >> Hello Dapeng and Alex, >>=20 >> I hope you had a chance to digest our responses to your comments and = questions about the API work. >> If you have any remaining issues, please let us know over the email = at your earliest convenience. >> It'd be good if you can articulate them in detail. >>=20 >>=20 >> Thanks. >>=20 >> Alper >=20 >=20 --Apple-Mail=_DCCC73CA-F585-49FD-BD14-C3E981D54324 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Xinpeng,

If your app knows = how to deal with IP address changes, then it's better if we give it a = chance to do so, because (as the I-D = explains):

Achieving IP session continuity and IP address = reachability by using Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP session continuity and IP address reachability should be be provided only when = needed.

Alper

=
On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) = wrote:

Hi Alper
My understanding about = the reason why there needs to define serval types of IP = prefixes is that, if the application itself could deal with the = change of IP address, i.e. the application itself could deal with = session continuty in case of IP address change, so the host would choose = a normadic address otherwise the host should choose a sustained = address.
But = my question is that, if the application could deal with session = continuty itself, does that mean the application is willing to change = its IP address? Because even though a new address might bring some kinds = of benefit, but it will also
bring additional cost for application to deal with = IP address change.
Thanks.
=B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED= Dapeng Liu [maxpassion@gmail.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5 = 5:01
=CA=D5=BC=FE=C8=CB: Alper = Yegin
=B3=AD=CB=CD: dmm@ietf.org
=D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA = DMM API

Hello = Alper,

I still have the following = comments:

1. Regarding the definition of = =A1=B0fixed IP address=A1=B1 in the = draft:

=A1=B0- Fixed IP = Address
address of the mobile = host.=A1=B1

If this is equal to = HoA, then RFC5014 already cover that. We do not need to repeat it here = with another name.

2. Regarding the definition = of =A1=B0sustained IP address=A1=B1 in the = draft:

"- Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "
There is no clear dividing line between fixed IP = address and sustained IP address. Whether the IP address is used for = reachability is not determined by the IP address itself. For example, = even when the MN get a HoA, after it moves to another location of the = network, it may decide to release current HoA and get another HoA, in = this case the "fixed IP address" becomes a "sustained IP = address".

Further more, the reachability = normally is implemented by domain name instead of IP address. For = example, we reach =A1=B0Google=A1=B1 by its domain name, never by it=A1=AF= s server=A1=AFs IP = address.

Using temporary private IP = address we can also achieve the goal of =A1=B0reachability=A1=B1. For = example, using dynamic DNS, as shown in http://hsk.oray.com/ , it can provide = reachability even the host get a private IP = address.

3. Regarding the definition of = =A1=B0nomadic IP address=A1=B1:

=A1=B0- Nomadic = IP Address
host.=A1=B1

Seems this = IP address is the IP address that we normally used in most cases. If = this is the case, why we need a new name for = it?

--
Dapeng = Liu

=D4=DA 2015=C4=EA3=D4=C22= 5=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02=A3=ACAlper Yegin = =D0=B4=B5=C0=A3=BA

= --Apple-Mail=_DCCC73CA-F585-49FD-BD14-C3E981D54324-- From nobody Thu Mar 26 11:17:51 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204F71A90B0 for ; Thu, 26 Mar 2015 11:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlHWeOKr-eOg for ; Thu, 26 Mar 2015 11:17:47 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CF41A9087 for ; Thu, 26 Mar 2015 11:17:47 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so72929643wgb.0 for ; Thu, 26 Mar 2015 11:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MxtOZaSDshTiujt5vioG7mpYO10NaS5AYBRvGm9T2kw=; b=EQIevEA35VDqt6HrKR68p4FJFBJYQO4uOcJjQFGylydL8dqIYX/muuz2F1uTN7qj3K MwnHjAN4N0bwnmIxAcGUSBm1l8fapoLGmB2bybyaBjdrK67PKegi4YzcXEJSY5iI6HzJ KRi2wVJZswBAgEF+aMFftVSxBIiBMiVJFSvoUFpn0GZNWUkV/FLAIS2DNKH4EBUeiqiF rJtjD+a8XCV5wyopXjXSYSnWh7T57vRVH0ND0w9ccq55C45B3vSwYNNVz71nfYlf+zaa gOz+tTVUDnjbRslNrj/aacWJUKPX9XTecEX/cxT7pZqoTuPguaC1D4UamEbWXqhzcMbz Igiw== X-Received: by 10.180.79.65 with SMTP id h1mr50149064wix.59.1427393865925; Thu, 26 Mar 2015 11:17:45 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:9860:4b20:ac20:5e7a? ([2001:67c:370:160:9860:4b20:ac20:5e7a]) by mx.google.com with ESMTPSA id ev7sm9441477wjb.47.2015.03.26.11.17.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 11:17:45 -0700 (PDT) Message-ID: <55144D3F.2030002@gmail.com> Date: Thu, 26 Mar 2015 11:17:35 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alexandru Petrescu , dmm@ietf.org References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> In-Reply-To: <55144953.8070104@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:17:50 -0000 Alex, 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: [snip] >> I thought by "fixed" you meant it stays the same wherever the Host goes >> (something like the Home Address). > > Alper - I think a LL address can also be qualified as 'fixed' - it never > changes. Does LL here mean link-local or link-layer? If it is the former one, then the above assertion is not correct. - Jouni > > I think it's hard to disagree with that, no? > > Alex > >> >> So, I guess, I should have referred to the "nomadic" address to mean the >> one that is constant, wherever the Host goes. >> >> As such, my suggestion is that a "nomadic" address can never be an >> RFC7217 address. >> >> In practice that would mean that if you configure an address to be >> "nomadic" you must also tell the kernel to not run RFC7217 on it. >> >> But ok, one might think that these two aspects ("nomadic" and RFC7217) >> are orthogonal at this point in time. >> >> Alex >> >>> >>> I don't know if it makes sense to request a fixed and random-based IP >>> address. But if someone does it, it works. >> >> >>> >>> Alper >>> >>> >>> >>> >>>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC >>>>>> 6775). >>>>>> >>>>> >>>>> Orthogonal. >>>>> >>>>> >>>>>> E.g. a nomadic address could never be a link-local address. >>>>>> >>>>>>> #2. Describe how IP address type information is conveyed from >>>>>>> network to MN. >>>>>> >>>>>> If one designs a protocol to convey address type information from >>>>>> the network to the end node, then one could also add the other >>>>>> types mentioned above. >>>>>> >>>>>> SLAAC could never 'convey' the address type to the end-node, >>>>>> because SLAAC is an operation happening with as heavy weight from >>>>>> the Server (router) as from the Client (Host): the Router decides >>>>>> the prefix but the Client decides the Interface ID. >>>>>> >>>>> >>>>> Still, the network can convey the type of IP address to the host. >>>>> Also, one can imagine augmenting Router Solicitation to let the host >>>>> convey its requested type. >>>> >>>> I agree. >>>> >>>> Alex >>>> >>>> >>>>>> Address Registration Option of 6lo and BTLE would have the Host >>>>>> conveying this information to the Router (and not vice-versa). >>>>>> >>>>> >>>>> OK. >>>>> >>>>> Alper >>>>> >>>>> >>>>>> Yours, >>>>>> >>>>>> Alex >>>>>> >>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the >>>>>>> baseline for item#1 (the API). A revision of the draft will also >>>>>>> include a new section to cover backward compatibility (Danny will >>>>>>> provide the draft text). Comments on the draft are welcome. >>>>>>> >>>>>>> The next call will be about items #2/#3 (IP address >>>>>>> configuration enhancements associated with the API). We intend to >>>>>>> schedule that one in about 2 weeks. >>>>>>> >>>>>>> Alper >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: >>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> See below for the Webex details. Remember, the call is on Tue, >>>>>>>> Feb 10, at 4pm CET. And don't forget to read the documents in >>>>>>>> the reading list prior to the call. >>>>>>>> >>>>>>>>> Attendees _shall read _the following material before the call >>>>>>>>> so that we can directly jump to the discussions: >>>>>>>>> >>>>>>>>> 1. >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>> >>>>>>>>> >>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>> 3. >>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February >>>>>>>> 2015 16:00 | Europe Time (Paris, GMT+01:00) | 1 hr 30 min >>>>>>>> >>>>>>>>> *Join WebEx meeting* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> Meeting number:641 085 326 >>>>>>>>> Meeting password:dmm1911 >>>>>>>>> >>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number >>>>>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada) >>>>>>>>> Access code: 641 085 326 Toll-free calling restrictions >>>>>>>>> >>>>>>>>> >>>>>>>>> Add this meeting >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> to your calendar. >>>>>>>>> >>>>>>>>> Can't join the meeting? Contact support. >>>>>>>>> >>>>>>>>> >>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows >>>>>>>>> audio and other information sent during the session to be >>>>>>>>> recorded, which may be discoverable in a legal matter. By >>>>>>>>> joining this session, you automatically consent to such >>>>>>>>> recordings. If you do not consent to being recorded, discuss >>>>>>>>> your concerns with the host or do not join the session. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: >>>>>>>> >>>>>>>>> Poll is closed, and majority selected the following date for >>>>>>>>> the call: >>>>>>>>> >>>>>>>>> Feb 10, 4pm CET. 1,5hr call. >>>>>>>>> >>>>>>>>> Please mark your calendars. >>>>>>>>> >>>>>>>>> In this call, we'll aim making progress on the I-D for item#1 >>>>>>>>> (an API for source address selection). >>>>>>>>> >>>>>>>>> Attendees _shall read _the following material before the call >>>>>>>>> so that we can directly jump to the discussions: >>>>>>>>> >>>>>>>>> 1. >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>> >>>>>>>>> >>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>> 3. >>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>> >>>>>>>>> >>>>>>>>> Alper >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote: >>>>>>>>> >>>>>>>>>> Folks, >>>>>>>>>> >>>>>>>>>> Please mark your availability on the following doodle for >>>>>>>>>> our next DMM WG Mobility Exposure and Selection WT call: >>>>>>>>>> >>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur >>>>>>>>>> >>>>>>>>>> Register your availability no later than the end of Monday >>>>>>>>>> (Jan 26). >>>>>>>>>> >>>>>>>>>> Alper >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 26 11:53:39 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D08B1A9037 for ; Thu, 26 Mar 2015 11:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJfhNydAsq7q for ; Thu, 26 Mar 2015 11:53:37 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C901A89FF for ; Thu, 26 Mar 2015 11:53:33 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 32D15880D1 for ; Thu, 26 Mar 2015 11:53:33 -0700 (PDT) Received: from dhcp-89de.meeting.ietf.org (unknown [IPv6:2001:67c:370:136:ad30:fc8a:e969:4436]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4244471B0001 for ; Thu, 26 Mar 2015 11:53:28 -0700 (PDT) Message-ID: <551455AB.80600@innovationslab.net> Date: Thu, 26 Mar 2015 13:53:31 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hgUgSCcpDIbfD4MiHERb9oilORS3F2GaV" Archived-At: Subject: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:53:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hgUgSCcpDIbfD4MiHERb9oilORS3F2GaV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DMM WG, I want to, once again, clarify the guiding principles for the DMM work teams. Hopefully, this will make it clear to all participants how the work teams will influence the WG. The guiding principles are: 1. All work teams are open to input from anyone 2. Any work team holding a meeting will announce that meeting to the WG 3. Any document produced by a work team is treated as any individual draf= t 4. Anyone can publish alternative proposals and ask the WG to consider th= em 5. WG consensus will drive the adoption of any solutions drafts (work team generated or otherwise). If you have any questions about the above, please contact me. Regards, Brian --hgUgSCcpDIbfD4MiHERb9oilORS3F2GaV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVFFWrAAoJEBOZRqCi7goqkbsH/jmyhida8NVsNbLoJOlFlXPM jGJJCq1tWyZhk0w3Gi+U662etKQX9+ANILysIDV6clJG8tF5GPI3FhcXk8tMT/fi VWovbIRBpYCK9jnGHBA+hPFUjcnhZFjJzgCf9Cb9omtnu1Yd6m1248/Nly7lvGLz Uy6ggx+Z0T22XYsP87TAf73AeY8HS3k4dGIDwy1JAFBib+AiET5z+abuf1o6xAnV DnnRqUhtsz/tsauFbxnIvjuCSaf5Bu+98yBUVyMWg4ox1pjnt+E50S1VBDPhOwe+ e6xeqCp+gCzBM0DCXhhkUZsRkvJ04NdKZnJaN3WJ0/coLm3Hm6QxPtMaxVt9isY= =5lEb -----END PGP SIGNATURE----- --hgUgSCcpDIbfD4MiHERb9oilORS3F2GaV-- From nobody Thu Mar 26 12:02:45 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E81B2A9C for ; Thu, 26 Mar 2015 12:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BDzxBKWXK70 for ; Thu, 26 Mar 2015 12:02:41 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D941B2A8E for ; Thu, 26 Mar 2015 12:01:46 -0700 (PDT) Received: from [10.119.8.1] ([31.7.59.44]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0M1pgC-1ZUpYg0rjG-00tg2q; Thu, 26 Mar 2015 20:01:44 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <551455AB.80600@innovationslab.net> Date: Thu, 26 Mar 2015 21:01:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org> References: <551455AB.80600@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:L9wmCLQjv0t4KzOvUp8bu4SnFHrhpYJJCPPMzR3ti2+ulWylG1f uGnVxc2SQaVFN0OHI77LQbJcdIc6Zrp6RXWBFzzMhItmlBify2YCq/zQCeFBfbJs6RFjZ/V L7fQtSabRGL4F3XHUS2WMpn9OCB5UOR37MlWBMDYgGHKfrumhHjoo+qkX9UncXzb6baFVJo krr1g46f2Ld7JYTZ3nhKg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:02:43 -0000 Brian, This is exactly how WTs have been operating. Anyone thinking otherwise is not closely following the work. Alper On Mar 26, 2015, at 8:53 PM, Brian Haberman wrote: > DMM WG, > I want to, once again, clarify the guiding principles for the DMM > work teams. Hopefully, this will make it clear to all participants how > the work teams will influence the WG. The guiding principles are: > > 1. All work teams are open to input from anyone > > 2. Any work team holding a meeting will announce that meeting to the WG > > 3. Any document produced by a work team is treated as any individual draft > > 4. Anyone can publish alternative proposals and ask the WG to consider them > > 5. WG consensus will drive the adoption of any solutions drafts (work > team generated or otherwise). > > If you have any questions about the above, please contact me. > > Regards, > Brian > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 26 12:05:30 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20B1B2DA2 for ; Thu, 26 Mar 2015 12:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59BsuzZwEIve for ; Thu, 26 Mar 2015 12:05:25 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875A11B2D9F for ; Thu, 26 Mar 2015 12:03:36 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6DD1C880E2; Thu, 26 Mar 2015 12:03:36 -0700 (PDT) Received: from dhcp-89de.meeting.ietf.org (unknown [IPv6:2001:67c:370:136:ad30:fc8a:e969:4436]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 88FAD71B0001; Thu, 26 Mar 2015 12:03:31 -0700 (PDT) Message-ID: <55145807.1010302@innovationslab.net> Date: Thu, 26 Mar 2015 14:03:35 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alper Yegin References: <551455AB.80600@innovationslab.net> <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org> In-Reply-To: <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jWn2oCq0fsAPn4m3Mq6OGNqvCs9cDqNVa" Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:05:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jWn2oCq0fsAPn4m3Mq6OGNqvCs9cDqNVa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Alper, On 3/26/15 2:01 PM, Alper Yegin wrote: > Brian, >=20 > This is exactly how WTs have been operating. I agree. >=20 > Anyone thinking otherwise is not closely following the work. >=20 I agree, but I have had people complain and just wanted to re-iterate my message from several months ago. Regards, Brian --jWn2oCq0fsAPn4m3Mq6OGNqvCs9cDqNVa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVFFgHAAoJEBOZRqCi7goqWkUH/0HTeO6vRhliZNd8tEOx8dWC hmw6UzSL+fylh4qclRYfgS91JAs720vZhQjsEMvAJWSApYxE6pZnZR9nMYKpCQgx vPUagkubJXjJq71ogN6SFzp3AI37j+1IG0rzxjRdscFNbLEwDYpcBJ03uQ89STe7 DHQPIHPv7eSkQQBSoxPxQouWl23rV5d/nADsQxRn5k38voZ//oEef1/GpHPgd1qu Rrs721GS+Q1+X8RTIoAUN4m0vnadfiF6y96EpGZaGjx5oyEXWXQL8Ltsqy80/eZZ NtO4NIQMoYLRex838vByd6uv4J2L4fiz1McJNwHcKFZqHqkEj/IrtC8s3zrOOJY= =8Ki6 -----END PGP SIGNATURE----- --jWn2oCq0fsAPn4m3Mq6OGNqvCs9cDqNVa-- From nobody Thu Mar 26 13:08:16 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6C1A8A4E for ; Thu, 26 Mar 2015 13:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIIQAMMFBolW for ; Thu, 26 Mar 2015 13:08:12 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 149311A89C7 for ; Thu, 26 Mar 2015 13:08:11 -0700 (PDT) Received: from [192.168.26.107] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77405288 for dmm@ietf.org; Thu, 26 Mar 2015 20:08:10 +0000 From: "Seil Jeon" To: Date: Thu, 26 Mar 2015 20:08:12 -0000 Message-ID: <006701d06800$96a57960$c3f06c20$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01D06800.96A7C350" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYg== Content-Language: ko Archived-At: Subject: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:08:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0068_01D06800.96A7C350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case in the draft. On receiving this API with the SUSTAINED IP address type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access network. So, actual obtaining of the IP address will be tried one time while attached at a specific access network. Even some applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, that is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should show its requirement with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon ------=_NextPart_000_0068_01D06800.96A7C350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

I = could attend DMM Thursday meeting via MeetEcho.
I = could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions.

First, regarding the need of = the proposed API (IPV6_PREFER_SRC_NEW),

The = use of the proposed API is suggested in the SUSTAINED IP address case in = the draft. On receiving this API with the SUSTAINED IP address type at = the IP stack, it will try to get a new SUSTAINED IP address if there is = no available in the currently attached access network. So, actual = obtaining of the IP address will be tried one time while attached at a = specific access network. Even some applications put this API after, the = already obtained SUSTAINED IP will be used. So, no worries about = abuse.

Second question sounded to me = like that this API is not needed because the host can get a new = SUSTAINED IP address, right?
If = the question is right, I don’t understand what the question is = meant, that is how the host can get a new SUSTAINED IP = address?
Based on the definition of = three types of IP address, an application should show its requirement = with an API among them. If it is the SUSTAINED IP address, how do we = expect the IP stack will try to get a new SUSTAINED IP = address?

Besides, the propsoed API is = not used alone but with the three type APIs.

Regards,
=

Seil = Jeon

------=_NextPart_000_0068_01D06800.96A7C350-- From nobody Thu Mar 26 13:42:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5357F1A8AA1 for ; Thu, 26 Mar 2015 13:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9kHRpHES8vO for ; Thu, 26 Mar 2015 13:42:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07221A8941 for ; Thu, 26 Mar 2015 13:42:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUE33435; Thu, 26 Mar 2015 20:42:45 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 20:42:44 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 04:42:38 +0800 From: "Weixinpeng (Jackie)" To: Alper Yegin Thread-Topic: =?gb2312?B?UmWjuiBETU0gQVBJ?= Thread-Index: AQHQZ+vETXUKkoT1hkqe8nT0z2URPp0uiyIAgACqUpM= Date: Thu, 26 Mar 2015 20:42:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.34] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46E332048nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dmm@ietf.org" Subject: [DMM] =?gb2312?b?tPC4tDogUmWjuiBETU0gQVBJ?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:42:50 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46E332048nkgeml507mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxwZXIsDQoNCkZvciBhbiBhcHBsaWNhdGlvbiBkZXZlbG9wZXIsIGlmIHRoZXJlIGFyZSB0 aHJlZSBraW5kcyBvZiBhZGRyZXNzZXMgdG8gdXNlIHdoaWNoIGFyZSAiRml4ZWQgSVAgQWRkcmVz cyIsICJTdXN0YWluZWQgSVAgQWRkcmVzcyIgYW5kICJOb21hZGljIElQIEFkZHJlc3MiLA0KDQp0 aGVuIEkgYmVsaWV2ZSB0aGUgZGV2ZWxvcGVyIHdvdWxkIGFsd2F5cyB3YW50cyB0byB1c2UgdGhl ICJGaXhlZCBJUCBhZGRyZXNzIiwgcmF0aGVyIHRoYW4gdGhlIG90aGVyIG9uZXMuIEJlY2F1c2Ug ZXZlbiB0aG91Z2ggdGhlIGFwcGxpY2F0aW9uIGNvdWxkIGNvcGUgd2l0aCBJUCBhZGRyZXNzDQoN CmNoYW5nZSwgYnV0IHRoZSBJUCBhZGRyZXNzIGNoYW5nZSBpcyBub3Qgd2hhdCB0aGUgYXBwbGlj YXRpb24gd2FudC4NCg0KDQoNCi1YaW5wZW5nDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCreivP7IyzogQWxwZXIgWWVnaW4gW2FscGVyLnllZ2luQHllZ2luLm9y Z10NCreiy83KsbzkOiAyMDE1xOoz1MIyN8jVIDI6MTMNCsrVvP7IyzogV2VpeGlucGVuZyAoSmFj a2llKQ0Ks63LzTogRGFwZW5nIExpdTsgZG1tQGlldGYub3JnDQrW98ziOiBSZTogUmWjuiBETU0g QVBJDQoNCkhpIFhpbnBlbmcsDQoNCklmIHlvdXIgYXBwIGtub3dzIGhvdyB0byBkZWFsIHdpdGgg SVAgYWRkcmVzcyBjaGFuZ2VzLCB0aGVuIGl0J3MgYmV0dGVyIGlmIHdlIGdpdmUgaXQgYSBjaGFu Y2UgdG8gZG8gc28sIGJlY2F1c2UgKGFzIHRoZSBJLUQgZXhwbGFpbnMpOg0KDQoNCiAgIEFjaGll dmluZyBJUCBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IGJ5 IHVzaW5nDQogICBNb2JpbGUgSVAgaW5jdXJzIHNvbWUgY29zdC4gIE1vYmlsZSBJUCBwcm90b2Nv bCBmb3JjZXMgdGhlIG1vYmlsZQ0KICAgaG9zdCdzIElQIHRyYWZmaWMgdG8gdHJhdmVyc2UgYSBj ZW50cmFsbHktbG9jYXRlZCByb3V0ZXIgKEhvbWUgQWdlbnQsDQogICBIQSksIHdoaWNoIGluY3Vy cyBhZGRpdGlvbmFsIHRyYW5zbWlzc2lvbiBsYXRlbmN5IGFuZCB1c2Ugb2YNCiAgIGFkZGl0aW9u YWwgbmV0d29yayByZXNvdXJjZXMsIGFkZHMgdG8gdGhlIG5ldHdvcmsgQ0FQRVggYW5kIE9QRVgs IGFuZA0KICAgZGVjcmVhc2VzIHRoZSByZWxpYWJpbGl0eSBvZiB0aGUgbmV0d29yayBkdWUgdG8g dGhlIGludHJvZHVjdGlvbiBvZiBhDQogICBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZSBbSS1ELmll dGYtZG1tLXJlcXVpcmVtZW50c10uICBUaGVyZWZvcmUsIElQDQogICBzZXNzaW9uIGNvbnRpbnVp dHkgYW5kIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IHNob3VsZCBiZSBiZSBwcm92aWRlZA0KICAg b25seSB3aGVuIG5lZWRlZC4NCg0KDQpBbHBlcg0KDQpPbiBNYXIgMjYsIDIwMTUsIGF0IDc6Mzkg UE0sIFdlaXhpbnBlbmcgKEphY2tpZSkgd3JvdGU6DQoNCkhpIEFscGVyDQpNeSB1bmRlcnN0YW5k aW5nIGFib3V0IHRoZSByZWFzb24gd2h5IHRoZXJlIG5lZWRzIHRvIGRlZmluZSBzZXJ2YWwgdHlw ZXMgb2YgSVAgcHJlZml4ZXMgaXMgdGhhdCwgIGlmIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgY291 bGQgZGVhbCB3aXRoIHRoZSBjaGFuZ2Ugb2YgSVAgYWRkcmVzcywgaS5lLiB0aGUgYXBwbGljYXRp b24gaXRzZWxmIGNvdWxkIGRlYWwgd2l0aCBzZXNzaW9uIGNvbnRpbnV0eSBpbiBjYXNlIG9mIElQ IGFkZHJlc3MgY2hhbmdlLCBzbyB0aGUgaG9zdCB3b3VsZCBjaG9vc2UgYSBub3JtYWRpYyBhZGRy ZXNzIG90aGVyd2lzZSB0aGUgaG9zdCBzaG91bGQgY2hvb3NlIGEgc3VzdGFpbmVkIGFkZHJlc3Mu DQpCdXQgbXkgcXVlc3Rpb24gaXMgdGhhdCwgaWYgdGhlIGFwcGxpY2F0aW9uIGNvdWxkIGRlYWwg d2l0aCBzZXNzaW9uIGNvbnRpbnV0eSBpdHNlbGYsIGRvZXMgdGhhdCBtZWFuIHRoZSBhcHBsaWNh dGlvbiBpcyB3aWxsaW5nIHRvIGNoYW5nZSBpdHMgSVAgYWRkcmVzcz8gQmVjYXVzZSBldmVuIHRo b3VnaCBhIG5ldyBhZGRyZXNzIG1pZ2h0IGJyaW5nIHNvbWUga2luZHMgb2YgYmVuZWZpdCwgYnV0 IGl0IHdpbGwgYWxzbw0KYnJpbmcgYWRkaXRpb25hbCBjb3N0IGZvciBhcHBsaWNhdGlvbiB0byBk ZWFsIHdpdGggSVAgYWRkcmVzcyBjaGFuZ2UuDQpUaGFua3MuDQoNCg0KDQpYaW5wZW5nDQoNCg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogZG1tIFtkbW0t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtIERhcGVu ZyBMaXUgW21heHBhc3Npb25AZ21haWwuY29tPG1haWx0bzptYXhwYXNzaW9uQGdtYWlsLmNvbT5d DQq3osvNyrG85DogMjAxNcTqM9TCMjbI1SA1OjAxDQrK1bz+yMs6IEFscGVyIFllZ2luDQqzrcvN OiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCtb3zOI6IFtETU1dILvYuLSjuiBE TU0gQVBJDQoNCkhlbGxvIEFscGVyLA0KDQpJIHN0aWxsIGhhdmUgdGhlIGZvbGxvd2luZyBjb21t ZW50czoNCg0KMS4gUmVnYXJkaW5nIHRoZSBkZWZpbml0aW9uIG9mIKGwZml4ZWQgSVAgYWRkcmVz c6GxIGluIHRoZSBkcmFmdDoNCg0KICChsC0gRml4ZWQgSVAgQWRkcmVzcw0KDQogICBUaGlzIGlz IHdoYXQgc3RhbmRhcmQgTW9iaWxlIElQIHByb3ZpZGVzIHdpdGggYSBIb21lIEFkZHJlc3MgKEhv QSkuDQogICBUaGUgbW9iaWxlIGhvc3QgaXMgY29uZmlndXJlcyBhIEhvQSBmcm9tIGEgY2VudHJh bGx5LWxvY2F0ZWQgSG9tZQ0KICAgTmV0d29yay4gIEJvdGggSVAgc2Vzc2lvbiBjb250aW51aXR5 IGFuZCBJUCBhZGRyZXNzIHJlYWNoYWJpbGl0eSBhcmUNCiAgIHByb3ZpZGVkIHRvIHRoZSBtb2Jp bGUgaG9zdCB3aXRoIHRoZSBoZWxwIG9mIGEgcm91dGVyIGluIHRoZSBIb21lDQogICBOZXR3b3Jr IChIb21lIEFnZW50LCBIQSkuICBUaGlzIHJvdXRlciBhY3RzIGFzIGFuIGFuY2hvciBmb3IgdGhl IElQDQoNCmFkZHJlc3Mgb2YgdGhlIG1vYmlsZSBob3N0LqGxDQoNCklmIHRoaXMgaXMgZXF1YWwg dG8gSG9BLCB0aGVuIFJGQzUwMTQgYWxyZWFkeSBjb3ZlciB0aGF0LiBXZSBkbyBub3QgbmVlZCB0 byByZXBlYXQgaXQgaGVyZSB3aXRoIGFub3RoZXIgbmFtZS4NCg0KMi4gUmVnYXJkaW5nIHRoZSBk ZWZpbml0aW9uIG9mIKGwc3VzdGFpbmVkIElQIGFkZHJlc3OhsSBpbiB0aGUgZHJhZnQ6DQoNCg0K Ii0gU3VzdGFpbmVkIElQIEFkZHJlc3MNCg0KICAgVGhpcyB0eXBlIG9mIElQIGFkZHJlc3MgcHJv dmlkZXMgSVAgc2Vzc2lvbiBjb250aW51aXR5IGJ1dCBub3QgSVANCiAgIGFkZHJlc3MgcmVhY2hh YmlsaXR5LiAgSXQgaXMgYWNoaWV2ZWQgYnkgZW5zdXJpbmcgdGhhdCB0aGUgSVAgYWRkcmVzcw0K ICAgdXNlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZXNzaW9uIHJlbWFpbnMgdXNhYmxlIGRl c3BpdGUgdGhlDQogICBtb3ZlbWVudCBvZiB0aGUgbW9iaWxlIGhvc3QuICBUaGUgSVAgYWRkcmVz cyBtYXkgY2hhbmdlIGFmdGVyIHRoZQ0KICAgdGVybWluYXRpb24gb2YgdGhlIElQIHNlc3Npb24o cyksIHRoZXJlZm9yZSBpdCBkb2VzIG5vdCBleGhpYml0DQogICBwZXJzaXN0ZW5jZS4NCiINCg0K VGhlcmUgaXMgbm8gY2xlYXIgZGl2aWRpbmcgbGluZSBiZXR3ZWVuIGZpeGVkIElQIGFkZHJlc3Mg YW5kIHN1c3RhaW5lZCBJUCBhZGRyZXNzLiBXaGV0aGVyIHRoZSBJUCBhZGRyZXNzIGlzIHVzZWQg Zm9yIHJlYWNoYWJpbGl0eSBpcyBub3QgZGV0ZXJtaW5lZCBieSB0aGUgSVAgYWRkcmVzcyBpdHNl bGYuIEZvciBleGFtcGxlLCBldmVuIHdoZW4gdGhlIE1OIGdldCBhIEhvQSwgYWZ0ZXIgaXQgbW92 ZXMgdG8gYW5vdGhlciBsb2NhdGlvbiBvZiB0aGUgbmV0d29yaywgaXQgbWF5IGRlY2lkZSB0byBy ZWxlYXNlIGN1cnJlbnQgSG9BIGFuZCBnZXQgYW5vdGhlciBIb0EsIGluIHRoaXMgY2FzZSB0aGUg ImZpeGVkIElQIGFkZHJlc3MiIGJlY29tZXMgYSAic3VzdGFpbmVkIElQIGFkZHJlc3MiLg0KDQpG dXJ0aGVyIG1vcmUsIHRoZSByZWFjaGFiaWxpdHkgbm9ybWFsbHkgaXMgaW1wbGVtZW50ZWQgYnkg ZG9tYWluIG5hbWUgaW5zdGVhZCBvZiBJUCBhZGRyZXNzLiBGb3IgZXhhbXBsZSwgd2UgcmVhY2gg obBHb29nbGWhsSBieSBpdHMgZG9tYWluIG5hbWUsIG5ldmVyIGJ5IGl0oa9zIHNlcnZlcqGvcyBJ UCBhZGRyZXNzLg0KDQpVc2luZyB0ZW1wb3JhcnkgcHJpdmF0ZSBJUCBhZGRyZXNzIHdlIGNhbiBh bHNvIGFjaGlldmUgdGhlIGdvYWwgb2YgobByZWFjaGFiaWxpdHmhsS4gRm9yIGV4YW1wbGUsIHVz aW5nIGR5bmFtaWMgRE5TLCBhcyBzaG93biBpbiAgaHR0cDovL2hzay5vcmF5LmNvbS8gLCBpdCBj YW4gIHByb3ZpZGUgcmVhY2hhYmlsaXR5IGV2ZW4gdGhlIGhvc3QgZ2V0IGEgcHJpdmF0ZSBJUCBh ZGRyZXNzLg0KDQozLiBSZWdhcmRpbmcgdGhlIGRlZmluaXRpb24gb2YgobBub21hZGljIElQIGFk ZHJlc3OhsToNCg0KobAtIE5vbWFkaWMgSVAgQWRkcmVzcw0KDQogICBUaGlzIHR5cGUgb2YgSVAg YWRkcmVzcyBwcm92aWRlcyBuZWl0aGVyIElQIHNlc3Npb24gY29udGludWl0eSBub3IgSVANCiAg IGFkZHJlc3MgcmVhY2hhYmlsaXR5LiAgVGhlIElQIGFkZHJlc3MgaXMgb2J0YWluZWQgZnJvbSB0 aGUgc2VydmluZyBJUA0KICAgZ2F0ZXdheSBhbmQgaXQgaXMgbm90IG1haW50YWluZWQgYWNyb3Nz IGdhdGV3YXkgY2hhbmdlcy4gIEluIG90aGVyDQogICB3b3JkcywgdGhlIElQIGFkZHJlc3MgbWF5 IGJlIHJlbGVhc2VkIGFuZCByZXBsYWNlZCBieSBhIG5ldyBJUA0KICAgYWRkcmVzcyB3aGVuIHRo ZSBJUCBnYXRld2F5IGNoYW5nZXMgZHVlIHRvIHRoZSBtb3ZlbWVudCBvZiB0aGUgbW9iaWxlDQoN Cmhvc3QuobENCg0KU2VlbXMgdGhpcyBJUCBhZGRyZXNzIGlzIHRoZSBJUCBhZGRyZXNzIHRoYXQg d2Ugbm9ybWFsbHkgdXNlZCBpbiBtb3N0IGNhc2VzLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB3aHkg d2UgbmVlZCBhIG5ldyBuYW1lIGZvciBpdD8NCg0KDQotLQ0KRGFwZW5nIExpdQ0KDQrU2iAyMDE1 xOoz1MIyNcjVINDHxtrI/aOsz8LO5zI6MDKjrEFscGVyIFllZ2luINC0tcCjug0KSGVsbG8gRGFw ZW5nIGFuZCBBbGV4LA0KDQpJIGhvcGUgeW91IGhhZCBhIGNoYW5jZSB0byBkaWdlc3Qgb3VyIHJl c3BvbnNlcyB0byB5b3VyIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgYWJvdXQgdGhlIEFQSSB3b3Jr Lg0KSWYgeW91IGhhdmUgYW55IHJlbWFpbmluZyBpc3N1ZXMsIHBsZWFzZSBsZXQgdXMga25vdyBv dmVyIHRoZSBlbWFpbCBhdCB5b3VyIGVhcmxpZXN0IGNvbnZlbmllbmNlLg0KSXQnZCBiZSBnb29k IGlmIHlvdSBjYW4gYXJ0aWN1bGF0ZSB0aGVtIGluIGRldGFpbC4NCg0KDQpUaGFua3MuDQoNCkFs cGVyDQoNCg0KDQo= --_000_C5C3BB522B1DDF478AA09545169155B46E332048nkgeml507mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Alper,

For an application developer, if there are three kinds of addresses= to use which are "Fixed IP Address", "Sustained IP Address&= quot; and "Nomadic IP Address",

then I believe the developer would always wants to use the "Fixed I= P address", rather than the other ones. Because even though the applic= ation could cope with IP address

change, but the IP address change is not what the application want.=

-Xinpeng

=B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yeg= in@yegin.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:13
=CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie)
=B3=AD=CB=CD: Dapeng Liu; dmm@ietf.org
=D6=F7=CC=E2: Re: Re=A3=BA DMM API

Hi Xinpeng,

If your app knows how to deal with IP address changes, then it's bette= r if we give it a chance to do so, because (as the I-D explains):

Achieving IP session continuity and IP a= ddress reachability by using Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP session continuity and IP address reachability should be be provided only when needed.

Alper

On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote:

Hi Alper

My understanding about t= he reason why there needs to define serval types of IP prefixes i= s that, if the application itself could deal with the change of IP ad= dress, i.e. the application itself could deal with session continuty in case of IP address change, so the host would choose a= normadic address otherwise the host should choose a sustained address.
But my question is that,= if the application could deal with session continuty itself, does that mea= n the application is willing to change its IP address? Because even though = a new address might bring some kinds of benefit, but it will also

bring additional cost fo= r application to deal with IP address change.

Thanks.

Xinpeng

=B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng Liu [maxpassion@gmail.com= ]
=B7=A2=CB=CD=CA=B1=BC=E4: = ;2015=C4=EA3=D4=C226=C8=D5 5:01
=CA=D5=BC=FE=C8=CB: Alper Yegin
=B3=AD=CB=CD: dmm@ietf.org
=D6=F7=CC=E2: [DMM= ] =BB=D8=B8=B4=A3=BA DMM API

Hello Alper,

I still have the following comments:

1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the dra= ft:

=A1=B0- Fixed IP Address

This is what standard Mo= bile IP provides with a Home Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP = ;

addre= ss of the mobile host.=A1=B1

If this is equal to HoA, then RFC5014 already cover that. We do not ne= ed to repeat it here with another name.

2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in the= draft:

"- Sustained IP Addres= s This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "

There is no clear dividing line between fixed IP address and sustained= IP address. Whether the IP address is used for reachability is not determi= ned by the IP address itself. For example, even when the MN get a HoA, afte= r it moves to another location of the network, it may decide to release current HoA and get another HoA, in = this case the "fixed IP address" becomes a "sustained IP add= ress".

Further more, the reachability normally is implemented by domain name = instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its doma= in name, never by it=A1=AFs server=A1=AFs IP address.

Using temporary private IP address we can also achieve the goal o= f =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in &nb= sp;http://hsk.oray.com/<= /a> , it can provide reachability even the host get a private IP address.

3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:

=A1=B0- Nomadic IP Address

This type of IP address = provides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile&nb= sp;

host.= =A1=B1

Seems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for it?

--

Dapeng Liu

=D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02= =A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your comments and q= uestions about the API work.

If you have any remaining issues, please let us know over the email at= your earliest convenience.

It'd be good if you can articulate them in detail.

Thanks.

Alper

--_000_C5C3BB522B1DDF478AA09545169155B46E332048nkgeml507mbxchi_-- From nobody Thu Mar 26 13:49:58 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D623C1B2A0D for ; Thu, 26 Mar 2015 13:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzrC772CrBei for ; Thu, 26 Mar 2015 13:49:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BDC1A89B4 for ; Thu, 26 Mar 2015 13:49:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQT12537; Thu, 26 Mar 2015 20:49:53 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 20:49:52 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 04:49:48 +0800 From: "Weixinpeng (Jackie)" To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] DMM work teams Thread-Index: AQHQZ/YxwkkOmm0xTEWTBzE9oeA+O50vOw2y Date: Thu, 26 Mar 2015 20:49:48 +0000 Message-ID: References: <551455AB.80600@innovationslab.net> In-Reply-To: <551455AB.80600@innovationslab.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.34] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:49:57 -0000 SSB0aGluayBpdCdzIGdvb2QgdG8gc3RhcnQgc2VydmFsIHdvcmsgdGVhbXMgdG8gcHJvY2VzcyB0 aGUgd29yay4NCklmIHRoZXJlIGFyZSBzb21lIHBlb3BsZSBjb21wbGFpbiBhYm91dCB0aGlzLCBJ IHRoaW5rIHRoZSByZWFzb24gd291bGQgYmUgdGhhdCBpdA0KbWlnaHQgYmUgbm90IGNvbnZpZW50 IGZvciB0aGVtIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBvbmxpbmUgaW50ZXJpbSBtZWV0aW5nIGZv ciByZWFzb25zIHN1Y2ggYXMgdGltZXpvbmUgZXRjLg0KDQpNeSBhbm90aGVyIGZlZWxpbmcgaXMg dGhhdCBhZnRlciB0aGUgZm9ybWluZyBvZiB0ZWFtcyB0aGVyZSBpcyByZWFsbHkgcmFyZSBkaXNj dXNzaW9uIGluIHRoZSBtYWlsbGlzdCB3aGVyZSBzaG91bGQgDQpiZSB0aGUgbWFpbiBkaXNjdXNz aW5nIHBsYWNlIG9mIElFVEYuIFNvIG15IHN1Z2dlc3Rpb24gaXMgdGhhdCBldmVuIHRob3VnaCB0 aGVyZSBhcmUgd29yayB0ZWFtcywgcGxlYXNlIGFsc28NCmJyaW5nIHRoZSBkaXNjdXNzaW9uIHRv IG1haWxsaXN0Lg0KDQpUaGFua3MuDQoNCi1YaW5wZW5nDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCreivP7IyzogZG1tIFtkbW0tYm91bmNlc0BpZXRmLm9yZ10g tPqx7SBCcmlhbiBIYWJlcm1hbiBbYnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0XQ0Kt6LLzcqxvOQ6 IDIwMTXE6jPUwjI3yNUgMjo1Mw0KytW8/sjLOiBkbW1AaWV0Zi5vcmcNCtb3zOI6IFtETU1dIERN TSB3b3JrIHRlYW1zDQoNCkRNTSBXRywNCiAgICAgSSB3YW50IHRvLCBvbmNlIGFnYWluLCBjbGFy aWZ5IHRoZSBndWlkaW5nIHByaW5jaXBsZXMgZm9yIHRoZSBETU0NCndvcmsgdGVhbXMuIEhvcGVm dWxseSwgdGhpcyB3aWxsIG1ha2UgaXQgY2xlYXIgdG8gYWxsIHBhcnRpY2lwYW50cyBob3cNCnRo ZSB3b3JrIHRlYW1zIHdpbGwgaW5mbHVlbmNlIHRoZSBXRy4gIFRoZSBndWlkaW5nIHByaW5jaXBs ZXMgYXJlOg0KDQoxLiBBbGwgd29yayB0ZWFtcyBhcmUgb3BlbiB0byBpbnB1dCBmcm9tIGFueW9u ZQ0KDQoyLiBBbnkgd29yayB0ZWFtIGhvbGRpbmcgYSBtZWV0aW5nIHdpbGwgYW5ub3VuY2UgdGhh dCBtZWV0aW5nIHRvIHRoZSBXRw0KDQozLiBBbnkgZG9jdW1lbnQgcHJvZHVjZWQgYnkgYSB3b3Jr IHRlYW0gaXMgdHJlYXRlZCBhcyBhbnkgaW5kaXZpZHVhbCBkcmFmdA0KDQo0LiBBbnlvbmUgY2Fu IHB1Ymxpc2ggYWx0ZXJuYXRpdmUgcHJvcG9zYWxzIGFuZCBhc2sgdGhlIFdHIHRvIGNvbnNpZGVy IHRoZW0NCg0KNS4gV0cgY29uc2Vuc3VzIHdpbGwgZHJpdmUgdGhlIGFkb3B0aW9uIG9mIGFueSBz b2x1dGlvbnMgZHJhZnRzICh3b3JrDQp0ZWFtIGdlbmVyYXRlZCBvciBvdGhlcndpc2UpLg0KDQpJ ZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIGFib3V0IHRoZSBhYm92ZSwgcGxlYXNlIGNvbnRhY3Qg bWUuDQoNClJlZ2FyZHMsDQpCcmlhbg== From nobody Thu Mar 26 14:19:58 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78B61B2F2F for ; Thu, 26 Mar 2015 14:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.549 X-Spam-Level: X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSJnjk1hLLQz for ; Thu, 26 Mar 2015 14:19:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E028E1B2F30 for ; Thu, 26 Mar 2015 14:19:52 -0700 (PDT) Received: from [10.119.8.4] ([46.19.140.68]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0Lp5Pe-1Z53cy2tz2-00ejeA; Thu, 26 Mar 2015 22:19:47 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=GB2312 From: Alper Yegin In-Reply-To: Date: Thu, 26 Mar 2015 23:19:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551455AB.80600@innovationslab.net> To: "Weixinpeng (Jackie)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:XsMMbpEb0eLXWSU6TyYFNOx1bB0kqeWmybzGp1fDXEW/9QKUz4L Szq6gymm5RE1u/hxsyeKLIP1nTk/rRFey8dD+RKNdZyqBmLNBFUkwz6khs1Bk9+V3pQpINR hGeXJgPCouYv80oyu0cOBtc5XCX+SYxkdPD6U4uG4NYRhANTJdbkfDVGuj0Nt5mwYRJYVBT +DuG0kXmqL2jaNb7MLKQg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:19:57 -0000 Hi Xinpeng, On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote: > I think it's good to start serval work teams to process the work. > If there are some people complain about this, I think the reason would = be that it > might be not convient for them to participate in the online interim = meeting for reasons such as timezone etc. >=20 It's always a challenge to find timeslots that works for everyone, = considering the around-the-world participation in DMM (in a way, that's = true :-) > My another feeling is that after the forming of teams there is really = rare discussion in the maillist where should=20 > be the main discussing place of IETF. So my suggestion is that even = though there are work teams, please also > bring the discussion to mail list. That's why we, WT leaders, publish meeting notes, so that people who = were not at the meeting can join the discussion on the mailing list, and this is, again, why WT leaders present the status at each IETF = meeting. My issue is=A1=AD.. some people don't read the meeting notes.. they = don't read the I-D. they don't follow the email discussions. They don't = even remember what we presented at the previous IETF and established as = common understanding across the WG. They don't bring up any discussion = for things that has been out there at least 2 IETF meeting cycles=A1=AD = And then! ask questions as if this is the first time we are presenting = it (for very specific example: need for 3 distinct types of IP = addresses). And then, this causing us significant amount of productivity = loss=A1=AD.=20 Alper >=20 > Thanks. >=20 > -Xinpeng >=20 > ________________________________________ > =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Brian = Haberman [brian@innovationslab.net] > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:53 > =CA=D5=BC=FE=C8=CB: dmm@ietf.org > =D6=F7=CC=E2: [DMM] DMM work teams >=20 > DMM WG, > I want to, once again, clarify the guiding principles for the DMM > work teams. Hopefully, this will make it clear to all participants how > the work teams will influence the WG. The guiding principles are: >=20 > 1. All work teams are open to input from anyone >=20 > 2. Any work team holding a meeting will announce that meeting to the = WG >=20 > 3. Any document produced by a work team is treated as any individual = draft >=20 > 4. Anyone can publish alternative proposals and ask the WG to consider = them >=20 > 5. WG consensus will drive the adoption of any solutions drafts (work > team generated or otherwise). >=20 > If you have any questions about the above, please contact me. >=20 > Regards, > Brian > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 26 14:26:53 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD61B2EFA for ; Thu, 26 Mar 2015 14:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.85 X-Spam-Level: X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn2c8Gi9Dr70 for ; Thu, 26 Mar 2015 14:26:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DD81B2AF7 for ; Thu, 26 Mar 2015 14:26:49 -0700 (PDT) Received: from [10.119.8.4] ([46.19.140.68]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0LyCFX-1ZVdaE1kY9-015RKw; Thu, 26 Mar 2015 22:26:41 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FFD0C010-73BB-4046-B198-A46EA691305F" From: Alper Yegin In-Reply-To: Date: Thu, 26 Mar 2015 23:26:36 +0200 Message-Id: References: , To: "Weixinpeng (Jackie)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:33T67Nzx8IS1tAkDaKIdgUzh48yDP2VqyVJDUURtkSiEsWyyjYN UhyXLqhrjzj4inNF20DGqpNvbylUgiVEOlFrDsBlIkW+2O4RAS+tqVk9QkwAmy8RYkuFQu7 ZPpH2BEF9OC4rYxEkQyYz0q9a18vttX2mEeGugy3SapZtReBhPv8CIJllRIAIx8+s2EfGYm TBEcQOXX2uCz9sND32ssw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Re=EF=BC=9A_DMM_API?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:26:52 -0000 --Apple-Mail=_FFD0C010-73BB-4046-B198-A46EA691305F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Xinpeng, I'll give you a counter example to what you are claiming. Imagine you are developing a chat (IM) client. Because your app will be running on terminals that'd connect to both = cellular and WiFi networks, you don't have any other option but to = implement app-layer mobility management (because otherwise your chat = sessions will break when the terminal moves in and out of WiFi = hotspots). Now, given that you already implemented app-layer mobility, it's to your = advantage to use it even when you are on cellular network, if there was = a way to tell the network to provide you a nomadic IP address (as = opposed to fixed/mobile IP address that it'd normally do). Because that = way, you ensure your IP packets take the shortest path, which reduces = the end2end latency. Besides, we also expect that the mobile network operators will promote = "proper use" of these flags, because that ensures efficient use of their = network resources. Letting an app use a fixed IP address when it could = very well use a nomadic IP address is waste of network resources (back = hauling, PGW capacity, etc.) As a future thing, we can even envision mobile operators charging = differently based on the type of traffic -- after all each type is = consuming different amounts of network resources.=20 Alper On Mar 26, 2015, at 10:42 PM, Weixinpeng (Jackie) wrote: > Hi Alper, > For an application developer, if there are three kinds of addresses to = use which are "Fixed IP Address", "Sustained IP Address" and "Nomadic IP = Address", > then I believe the developer would always wants to use the "Fixed IP = address", rather than the other ones. Because even though the = application could cope with IP address > change, but the IP address change is not what the application want. > =20 > -Xinpeng > =20 > =20 > =B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yegin@yegin.org] > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:13 > =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie) > =B3=AD=CB=CD: Dapeng Liu; dmm@ietf.org > =D6=F7=CC=E2: Re: Re=A3=BA DMM API >=20 > Hi Xinpeng, >=20 > If your app knows how to deal with IP address changes, then it's = better if we give it a chance to do so, because (as the I-D explains): >=20 > Achieving IP session continuity and IP address reachability by = using > Mobile IP incurs some cost. Mobile IP protocol forces the mobile > host's IP traffic to traverse a centrally-located router (Home = Agent, > HA), which incurs additional transmission latency and use of > additional network resources, adds to the network CAPEX and OPEX, = and > decreases the reliability of the network due to the introduction of = a > single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP > session continuity and IP address reachability should be be = provided > only when needed. >=20 >=20 > Alper >=20 > On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote: >=20 >> Hi Alper >> My understanding about the reason why there needs to define serval = types of IP prefixes is that, if the application itself could deal with = the change of IP address, i.e. the application itself could deal with = session continuty in case of IP address change, so the host would choose = a normadic address otherwise the host should choose a sustained address. >> But my question is that, if the application could deal with session = continuty itself, does that mean the application is willing to change = its IP address? Because even though a new address might bring some kinds = of benefit, but it will also >> bring additional cost for application to deal with IP address change. >> Thanks. >> =20 >> Xinpeng >> =20 >> =20 >> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng = Liu [maxpassion@gmail.com] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5 5:01 >> =CA=D5=BC=FE=C8=CB: Alper Yegin >> =B3=AD=CB=CD: dmm@ietf.org >> =D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA DMM API >>=20 >> Hello Alper, >>=20 >> I still have the following comments: >>=20 >> 1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the = draft: >>=20 >> =A1=B0- Fixed IP Address >> This is what standard Mobile IP provides with a Home Address = (HoA). >> The mobile host is configures a HoA from a centrally-located Home >> Network. Both IP session continuity and IP address reachability = are >> provided to the mobile host with the help of a router in the Home >> Network (Home Agent, HA). This router acts as an anchor for the = IP=20 >> address of the mobile host.=A1=B1=20 >>=20 >> If this is equal to HoA, then RFC5014 already cover that. We do not = need to repeat it here with another name. >>=20 >> 2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in = the draft: >>=20 >> "- Sustained IP Address >>=20 >> This type of IP address provides IP session continuity but not IP >> address reachability. It is achieved by ensuring that the IP = address >> used at the beginning of the session remains usable despite the >> movement of the mobile host. The IP address may change after the >> termination of the IP session(s), therefore it does not exhibit >> persistence. >> " >> There is no clear dividing line between fixed IP address and = sustained IP address. Whether the IP address is used for reachability is = not determined by the IP address itself. For example, even when the MN = get a HoA, after it moves to another location of the network, it may = decide to release current HoA and get another HoA, in this case the = "fixed IP address" becomes a "sustained IP address". >>=20 >> Further more, the reachability normally is implemented by domain name = instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its = domain name, never by it=A1=AFs server=A1=AFs IP address.=20 >>=20 >> Using temporary private IP address we can also achieve the goal of = =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in = http://hsk.oray.com/ , it can provide reachability even the host get a = private IP address. >>=20 >> 3. Regarding the definition of =A1=B0nomadic IP address=A1=B1: >>=20 >> =A1=B0- Nomadic IP Address >> This type of IP address provides neither IP session continuity nor = IP >> address reachability. The IP address is obtained from the serving = IP >> gateway and it is not maintained across gateway changes. In other >> words, the IP address may be released and replaced by a new IP >> address when the IP gateway changes due to the movement of the = mobile=20 >> host.=A1=B1 >>=20 >> Seems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for it? >>=20 >>=20 >> --=20 >> Dapeng Liu >>=20 >> =D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:= 02=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA >>> Hello Dapeng and Alex, >>>=20 >>> I hope you had a chance to digest our responses to your comments and = questions about the API work. >>> If you have any remaining issues, please let us know over the email = at your earliest convenience. >>> It'd be good if you can articulate them in detail. >>>=20 >>>=20 >>> Thanks. >>>=20 >>> Alper --Apple-Mail=_FFD0C010-73BB-4046-B198-A46EA691305F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Xinpeng,

I'll give you a counter = example to what you are claiming.

Imagine you = are developing a chat (IM) client.
Because your app will be = running on terminals that'd connect to both cellular and WiFi networks, = you don't have any other option but to implement app-layer mobility = management (because otherwise your chat sessions will break when the = terminal moves in and out of WiFi = hotspots).

Now, given that you already = implemented app-layer mobility, it's to your advantage to use it even = when you are on cellular network, if there was a way to tell the network = to provide you a nomadic IP address (as opposed to fixed/mobile IP = address that it'd normally do). Because that way, you ensure your IP = packets take the shortest path, which reduces the end2end = latency.

Besides, we also expect that the = mobile network operators will promote "proper use" of these flags, = because that ensures efficient use of their network resources. Letting = an app use a fixed IP address when it could very well use a nomadic IP = address is waste of network resources (back hauling, PGW capacity, = etc.)

As a future thing, we can even envision = mobile operators charging differently based on the type of traffic -- = after all each type is consuming different amounts of network = resources.

Alper

<= br>
On Mar 26, 2015, at 10:42 PM, Weixinpeng (Jackie) = wrote:

then I believe the developer would always wants to = use the "Fixed IP address", rather than the other ones. Because even = though the application could cope with IP address
change, but the IP = address change is not what the application want.

-Xinpeng

=B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yegin@yegin.org]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 = 2:13
=CA=D5=BC=FE=C8=CB: Weixinpeng = (Jackie)
=B3=AD=CB=CD: Dapeng Liu; dmm@ietf.org
=D6=F7=CC=E2: Re: Re=A3=BA DMM = API

Hi = Xinpeng,

If your app knows how to deal with IP = address changes, then it's better if we give it a chance to do so, = because (as the I-D explains):

Achieving IP session = continuity and IP address reachability by using Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP session continuity and IP address reachability should be be provided only when = needed.

Alper

=
On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) = wrote:

Hi Alper
My understanding about the reason why there needs = to define serval types of IP prefixes is that, if the = application itself could deal with the change of IP address, i.e. the = application itself could deal with session continuty in case of IP = address change, so the host would choose a normadic address otherwise = the host should choose a sustained address.
But my question is that, if the application = could deal with session continuty itself, does that mean the application = is willing to change its IP address? Because even though a new address = might bring some kinds of benefit, but it will also
bring additional cost = for application to deal with IP address change.
Thanks.

Xinpeng

=B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng Liu [maxpassion@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2015=C4=EA3=D4=C22= 6=C8=D5 5:01
=CA=D5=BC=FE=C8=CB: Alper = Yegin
=B3=AD=CB=CD: dmm@ietf.org
=D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA = DMM API

Hello = Alper,

I still have the following = comments:

1. Regarding the definition of = =A1=B0fixed IP address=A1=B1 in the = draft:

=A1=B0- Fixed IP = Address
address of the mobile = host.=A1=B1

If this is equal to = HoA, then RFC5014 already cover that. We do not need to repeat it here = with another name.

2. Regarding the definition = of =A1=B0sustained IP address=A1=B1 in the = draft:

"- Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "
There is no clear dividing line between fixed IP = address and sustained IP address. Whether the IP address is used for = reachability is not determined by the IP address itself. For example, = even when the MN get a HoA, after it moves to another location of the = network, it may decide to release current HoA and get another HoA, in = this case the "fixed IP address" becomes a "sustained IP = address".

Further more, the reachability = normally is implemented by domain name instead of IP address. For = example, we reach =A1=B0Google=A1=B1 by its domain name, never by it=A1=AF= s server=A1=AFs IP = address.

Using temporary private IP = address we can also achieve the goal of =A1=B0reachability=A1=B1. For = example, using dynamic DNS, as shown in http://hsk.oray.com/ , it can provide = reachability even the host get a private IP = address.

3. Regarding the definition of = =A1=B0nomadic IP address=A1=B1:

=A1=B0- Nomadic = IP Address
host.=A1=B1

Seems this = IP address is the IP address that we normally used in most cases. If = this is the case, why we need a new name for = it?

--
Dapeng = Liu

=D4=DA 2015=C4=EA3=D4=C22= 5=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02=A3=ACAlper Yegin = =D0=B4=B5=C0=A3=BA
Cc: "Weixinpeng $Jackie$" , "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:49:53 -0000 --55147efa_c0a92d4_a9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Alper, =20 Please note that we still need mailing list confirmation for call for ado= ption of the API document. So even now we can not say that we have =E2=80= =9Ccommon udnerstadning=E2=80=9C from the group. Your claim of =E2=80=9C= common understanding across the WG=E2=80=9D is not exist. As Brian menti= oned, agreement within WT or among draft authors does not mean it is the = consensus of the group. The group should always keep open and welcome an= yone to ask any question. =20 -- =20 Dapeng Liu =E5=9C=A8 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF= =BC=8C=E4=B8=8B=E5=8D=884:19=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A > Hi Xinpeng, > =20 > On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote: > =20 > > I think it's good to start serval work teams to process the work. > > If there are some people complain about this, I think the reason woul= d be that it > > might be not convient for them to participate in the online interim m= eeting for reasons such as timezone etc. > > =20 > =20 > =20 > It's always a challenge to find timeslots that works for everyone, cons= idering the around-the-world participation in DMM (in a way, that's true = :-) > =20 > > My another feeling is that after the forming of teams there is really= rare discussion in the maillist where should =20 > > be the main discussing place of IET=46. So my suggestion is that even= though there are work teams, please also > > bring the discussion to mail list. > > =20 > =20 > =20 > That's why we, WT leaders, publish meeting notes, so that people who we= re not at the meeting can join the discussion on the mailing list, > and this is, again, why WT leaders present the status at each IET=46 me= eting. > =20 > My issue is=E2=80=A6.. some people don't read the meeting notes.. they = don't read the I-D. they don't follow the email discussions. They don't e= ven remember what we presented at the previous IET=46 and established as = common understanding across the WG. They don't bring up any discussion fo= r things that has been out there at least 2 IET=46 meeting cycles=E2=80=A6= And then=21 ask questions as if this is the first time we are presenting= it (for very specific example: need for 3 distinct types of IP addresses= ). And then, this causing us significant amount of productivity loss=E2=80= =A6. =20 > =20 > Alper > =20 > =20 > =20 > > Thanks. > > =20 > > -Xinpeng > > =20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > =E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bdmm-bounces=40ietf.org (mailto:dm= m-bounces=40ietf.org)=5D =E4=BB=A3=E8=A1=A8 Brian Haberman =5Bbrian=40inn= ovationslab.net (mailto:brian=40innovationslab.net)=5D > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97= =A5 2:53 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: dmm=40ietf.org (mailto:dmm=40ietf.org) > > =E4=B8=BB=E9=A2=98: =5BDMM=5D DMM work teams > > =20 > > DMM WG, > > I want to, once again, clarify the guiding principles for the DMM > > work teams. Hopefully, this will make it clear to all participants ho= w > > the work teams will influence the WG. The guiding principles are: > > =20 > > 1. All work teams are open to input from anyone > > =20 > > 2. Any work team holding a meeting will announce that meeting to the = WG > > =20 > > 3. Any document produced by a work team is treated as any individual = draft > > =20 > > 4. Anyone can publish alternative proposals and ask the WG to conside= r them > > =20 > > 5. WG consensus will drive the adoption of any solutions drafts (work= > > team generated or otherwise). > > =20 > > If you have any questions about the above, please contact me. > > =20 > > Regards, > > Brian > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > dmm mailing list > > dmm=40ietf.org (mailto:dmm=40ietf.org) > > https://www.ietf.org/mailman/listinfo/dmm > > =20 > =20 > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > dmm mailing list > dmm=40ietf.org (mailto:dmm=40ietf.org) > https://www.ietf.org/mailman/listinfo/dmm > =20 > =20 --55147efa_c0a92d4_a9e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Alper,

Please note that we still need = mailing list confirmation for call for adoption of the API document. So e= ven now we can not say that we have =E2=80=9Ccommon udnerstadning=E2=80=9C= from the group. Your claim of =E2=80=9Ccommon understanding across= the WG=E2=80=9D is not exist. As Brian mentioned, agreement within= WT or among draft authors does not mean it is the consensus of the group= . The group should always keep open and welcome anyone to ask any q= uestion.

--
Dapeng Li= u

=20
=E5=9C=A8 2015=E5=B9=B4= 3=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=BC=8C=E4=B8=8B=E5=8D= =884:19=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

Hi Xinpeng,

=
On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote:
<= br>
I think it's good to sta= rt serval work teams to process the work.
If there are some peo= ple complain about this, I think the reason would be that it
mi= ght be not convient for them to participate in the online interim meeting= for reasons such as timezone etc.

It's always a challenge to find timeslots that works for everyone, = considering the around-the-world participation in DMM (in a way, that's t= rue :-)

My an= other feeling is that after the forming of teams there is really rare dis= cussion in the maillist where should
be the main discussing pl= ace of IET=46. So my suggestion is that even though there are work teams,= please also
bring the discussion to mail list.

That's why we, WT leaders, publish meeting n= otes, so that people who were not at the meeting can join the discussion = on the mailing list,
and this is, again, why WT leaders present= the status at each IET=46 meeting.

My issue is=E2= =80=A6.. some people don't read the meeting notes.. they don't read the I= -D. they don't follow the email discussions. They don't even remember wha= t we presented at the previous IET=46 and established as common understan= ding across the WG. They don't bring up any discussion for things that ha= s been out there at least 2 IET=46 meeting cycles=E2=80=A6 And then=21 as= k questions as if this is the first time we are presenting it (for very s= pecific example: need for 3 distinct types of IP addresses). And then, th= is causing us significant amount of productivity loss=E2=80=A6.

Alper

Thanks.

-Xinpeng
=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=E5= =8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bdmm-bounces=40ietf.org=5D =E4=BB=A3=E8=A1=A8 Brian Haberman =5B= brian=40innovationslab.= net=5D
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43= =E6=9C=8827=E6=97=A5 2:53
=E6=94=B6=E4=BB=B6=E4=BA=BA: dmm=40ietf.org
=E4=B8=BB=E9=A2=98= : =5BDMM=5D DMM work teams

DMM WG,
= I want to, once again, clarify the guiding principles for the DMM
<= div>work teams. Hopefully, this will make it clear to all participants ho= w
the work teams will influence the WG. The guiding principles= are:

1. All work teams are open to input from a= nyone

2. Any work team holding a meeting will an= nounce that meeting to the WG

3. Any document pr= oduced by a work team is treated as any individual draft

4. Anyone can publish alternative proposals and ask the WG to co= nsider them

5. WG consensus will drive the adopt= ion of any solutions drafts (work
team generated or otherwise).=

If you have any questions about the above, plea= se contact me.

Regards,
Brian
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dmm mailing list
d= mm=40ietf.org
https://www.ietf.org/mailman/listinfo/dmm

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
dmm mailing list
dmm=40ietf.org
https://www.ietf.org/mailman/listin= fo/dmm
=20 =20 =20 =20
=20

--55147efa_c0a92d4_a9e-- From nobody Thu Mar 26 15:02:53 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55381B2F9C for ; Thu, 26 Mar 2015 15:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwT72_YEePwo for ; Thu, 26 Mar 2015 15:02:43 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D6C1B2DC9 for ; Thu, 26 Mar 2015 15:02:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QM2cux028062; Thu, 26 Mar 2015 23:02:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4FDAD2051D6; Thu, 26 Mar 2015 23:03:24 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 43A0F2050EE; Thu, 26 Mar 2015 23:03:24 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.14]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QM2Wcx009953; Thu, 26 Mar 2015 23:02:38 +0100 Message-ID: <551481F8.9090507@gmail.com> Date: Thu, 26 Mar 2015 17:02:32 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jouni Korhonen , dmm@ietf.org References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> In-Reply-To: <55144D3F.2030002@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:02:47 -0000 Le 26/03/2015 13:17, Jouni Korhonen a �crit : > Alex, > > 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: > > [snip] > >>> I thought by "fixed" you meant it stays the same wherever the Host goes >>> (something like the Home Address). >> >> Alper - I think a LL address can also be qualified as 'fixed' - it never >> changes. > > Does LL here mean link-local or link-layer? If it is the former one, > then the above assertion is not correct. Link-local. And you seem to say a link-local address is not fixed? I think link-local addresses _are_ fixed set in stone. They are formed locally without need of help from router. Alex > > - Jouni > >> >> I think it's hard to disagree with that, no? >> >> Alex >> >>> >>> So, I guess, I should have referred to the "nomadic" address to mean the >>> one that is constant, wherever the Host goes. >>> >>> As such, my suggestion is that a "nomadic" address can never be an >>> RFC7217 address. >>> >>> In practice that would mean that if you configure an address to be >>> "nomadic" you must also tell the kernel to not run RFC7217 on it. >>> >>> But ok, one might think that these two aspects ("nomadic" and RFC7217) >>> are orthogonal at this point in time. >>> >>> Alex >>> >>>> >>>> I don't know if it makes sense to request a fixed and random-based IP >>>> address. But if someone does it, it works. >>> >>> >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC >>>>>>> 6775). >>>>>>> >>>>>> >>>>>> Orthogonal. >>>>>> >>>>>> >>>>>>> E.g. a nomadic address could never be a link-local address. >>>>>>> >>>>>>>> #2. Describe how IP address type information is conveyed from >>>>>>>> network to MN. >>>>>>> >>>>>>> If one designs a protocol to convey address type information from >>>>>>> the network to the end node, then one could also add the other >>>>>>> types mentioned above. >>>>>>> >>>>>>> SLAAC could never 'convey' the address type to the end-node, >>>>>>> because SLAAC is an operation happening with as heavy weight from >>>>>>> the Server (router) as from the Client (Host): the Router decides >>>>>>> the prefix but the Client decides the Interface ID. >>>>>>> >>>>>> >>>>>> Still, the network can convey the type of IP address to the host. >>>>>> Also, one can imagine augmenting Router Solicitation to let the host >>>>>> convey its requested type. >>>>> >>>>> I agree. >>>>> >>>>> Alex >>>>> >>>>> >>>>>>> Address Registration Option of 6lo and BTLE would have the Host >>>>>>> conveying this information to the Router (and not vice-versa). >>>>>>> >>>>>> >>>>>> OK. >>>>>> >>>>>> Alper >>>>>> >>>>>> >>>>>>> Yours, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the >>>>>>>> baseline for item#1 (the API). A revision of the draft will also >>>>>>>> include a new section to cover backward compatibility (Danny will >>>>>>>> provide the draft text). Comments on the draft are welcome. >>>>>>>> >>>>>>>> The next call will be about items #2/#3 (IP address >>>>>>>> configuration enhancements associated with the API). We intend to >>>>>>>> schedule that one in about 2 weeks. >>>>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: >>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> See below for the Webex details. Remember, the call is on Tue, >>>>>>>>> Feb 10, at 4pm CET. And don't forget to read the documents in >>>>>>>>> the reading list prior to the call. >>>>>>>>> >>>>>>>>>> Attendees _shall read _the following material before the call >>>>>>>>>> so that we can directly jump to the discussions: >>>>>>>>>> >>>>>>>>>> 1. >>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>>> >>>>>>>>>> >>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>>> 3. >>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Alper >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February >>>>>>>>> 2015 16:00 | Europe Time (Paris, GMT+01:00) | 1 hr 30 min >>>>>>>>> >>>>>>>>>> *Join WebEx meeting* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> Meeting number:641 085 326 >>>>>>>>>> Meeting password:dmm1911 >>>>>>>>>> >>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number >>>>>>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada) >>>>>>>>>> Access code: 641 085 326 Toll-free calling restrictions >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Add this meeting >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> to your calendar. >>>>>>>>>> >>>>>>>>>> Can't join the meeting? Contact support. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows >>>>>>>>>> audio and other information sent during the session to be >>>>>>>>>> recorded, which may be discoverable in a legal matter. By >>>>>>>>>> joining this session, you automatically consent to such >>>>>>>>>> recordings. If you do not consent to being recorded, discuss >>>>>>>>>> your concerns with the host or do not join the session. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: >>>>>>>>> >>>>>>>>>> Poll is closed, and majority selected the following date for >>>>>>>>>> the call: >>>>>>>>>> >>>>>>>>>> Feb 10, 4pm CET. 1,5hr call. >>>>>>>>>> >>>>>>>>>> Please mark your calendars. >>>>>>>>>> >>>>>>>>>> In this call, we'll aim making progress on the I-D for item#1 >>>>>>>>>> (an API for source address selection). >>>>>>>>>> >>>>>>>>>> Attendees _shall read _the following material before the call >>>>>>>>>> so that we can directly jump to the discussions: >>>>>>>>>> >>>>>>>>>> 1. >>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf >>>>>>>>>> >>>>>>>>>> >>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf >>>>>>>>>> 3. >>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf >>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Alper >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote: >>>>>>>>>> >>>>>>>>>>> Folks, >>>>>>>>>>> >>>>>>>>>>> Please mark your availability on the following doodle for >>>>>>>>>>> our next DMM WG Mobility Exposure and Selection WT call: >>>>>>>>>>> >>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur >>>>>>>>>>> >>>>>>>>>>> Register your availability no later than the end of Monday >>>>>>>>>>> (Jan 26). >>>>>>>>>>> >>>>>>>>>>> Alper >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ dmm mailing list >>>>>>>> dmm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu Mar 26 15:04:49 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF01B2F9A for ; Thu, 26 Mar 2015 15:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SUjiVPdDVDB for ; Thu, 26 Mar 2015 15:04:45 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE6D1B2DC9 for ; Thu, 26 Mar 2015 15:04:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QM4hEW032305 for ; Thu, 26 Mar 2015 23:04:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9F21C20515B for ; Thu, 26 Mar 2015 23:05:28 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8BF432050EE for ; Thu, 26 Mar 2015 23:05:28 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.14]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QM4fkn011529 for ; Thu, 26 Mar 2015 23:04:42 +0100 Message-ID: <55148279.4090608@gmail.com> Date: Thu, 26 Mar 2015 17:04:41 -0500 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmm@ietf.org References: <551455AB.80600@innovationslab.net> <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org> In-Reply-To: <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:04:47 -0000 Le 26/03/2015 14:01, Alper Yegin a �crit : > Brian, > > This is exactly how WTs have been operating. > > Anyone thinking otherwise is not closely following the work. Alper, I agree. Just one little comment: some times it is difficult to participate to audioconferences. Alex > > Alper > > > On Mar 26, 2015, at 8:53 PM, Brian Haberman wrote: > >> DMM WG, >> I want to, once again, clarify the guiding principles for the DMM >> work teams. Hopefully, this will make it clear to all participants how >> the work teams will influence the WG. The guiding principles are: >> >> 1. All work teams are open to input from anyone >> >> 2. Any work team holding a meeting will announce that meeting to the WG >> >> 3. Any document produced by a work team is treated as any individual draft >> >> 4. Anyone can publish alternative proposals and ask the WG to consider them >> >> 5. WG consensus will drive the adoption of any solutions drafts (work >> team generated or otherwise). >> >> If you have any questions about the above, please contact me. >> >> Regards, >> Brian >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu Mar 26 15:17:47 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD841A011D for ; Thu, 26 Mar 2015 15:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR43WfTYsDwi for ; Thu, 26 Mar 2015 15:17:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68341A01D8 for ; Thu, 26 Mar 2015 15:17:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQT16444; Thu, 26 Mar 2015 22:17:37 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 22:17:35 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 06:17:29 +0800 From: "Weixinpeng (Jackie)" To: Alper Yegin Thread-Topic: =?gb2312?B?UmWjuiBETU0gQVBJ?= Thread-Index: AQHQZ+vETXUKkoT1hkqe8nT0z2URPp0uiyIAgACqUpP//4urAIAAivUQ Date: Thu, 26 Mar 2015 22:17:28 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.34] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46E3320DFnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dmm@ietf.org" Subject: [DMM] =?gb2312?b?tPC4tDogUmWjuiBETU0gQVBJ?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:17:45 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46E3320DFnkgeml507mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QWxwZXIsDQoNCg0KDQpUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4gQW5kIHRoZXJlIGFy ZSBzb21lIG9mIG15IHJlcGxpZXMgaW5saW5lLg0KDQoNCg0KVGhhbmtzLg0KDQotWGlucGVuZw0K DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEFscGVy IFllZ2luIFthbHBlci55ZWdpbkB5ZWdpbi5vcmddDQq3osvNyrG85DogMjAxNcTqM9TCMjfI1SA1 OjI2DQrK1bz+yMs6IFdlaXhpbnBlbmcgKEphY2tpZSkNCrOty806IERhcGVuZyBMaXU7IGRtbUBp ZXRmLm9yZw0K1vfM4jogUmU6IFJlo7ogRE1NIEFQSQ0KDQpYaW5wZW5nLA0KDQpJJ2xsIGdpdmUg eW91IGEgY291bnRlciBleGFtcGxlIHRvIHdoYXQgeW91IGFyZSBjbGFpbWluZy4NCg0KSW1hZ2lu ZSB5b3UgYXJlIGRldmVsb3BpbmcgYSBjaGF0IChJTSkgY2xpZW50Lg0KQmVjYXVzZSB5b3VyIGFw cCB3aWxsIGJlIHJ1bm5pbmcgb24gdGVybWluYWxzIHRoYXQnZCBjb25uZWN0IHRvIGJvdGggY2Vs bHVsYXIgYW5kIFdpRmkgbmV0d29ya3MsIHlvdSBkb24ndCBoYXZlIGFueSBvdGhlciBvcHRpb24g YnV0IHRvIGltcGxlbWVudCBhcHAtbGF5ZXIgbW9iaWxpdHkgbWFuYWdlbWVudCAoYmVjYXVzZSBv dGhlcndpc2UgeW91ciBjaGF0IHNlc3Npb25zIHdpbGwgYnJlYWsgd2hlbiB0aGUgdGVybWluYWwg bW92ZXMgaW4gYW5kIG91dCBvZiBXaUZpIGhvdHNwb3RzKS4NCg0KW1dlaV0gTXkgdW5kZXJzdGFu ZGluZyBhYm91dGggdGhlIHJlYXNvbiB3aHkgYXBwbGljYXRpb24gZGV2ZWxvcGVyIGltcGxlbWVu dHMgYXBwbGljYXRpb24gbGF5ZXIgc3VwcG9ydCBpcyB0aGF0IHRoZSBob3N0J3MgSVAgYWRkcmVz cyBtaWdodCBjaGFuZ2Ugd2hlbiB0aGVpciBhcHBsaWNhdGlvbiBpcyBydW5uaW5nLCBzbyB0aGV5 ICoqaGF2ZSB0byoqIHByb3ZpZGUNCg0KbWVjaGFuaXNtIHRvIGNvcGUgd2l0aCB0aGUgc2l0dWF0 aW9uLCBidXQgaXQncyBub3QgdGhlaXIgd2lsbGluZyB0byBjaGFuZ2UgdGhlIElQIGFkZHJlc3Mu IEFkZGl0aW9uYWwsIFRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgbWlnaHQgYmUgYSBiaXQgb2Yg Y29uZnVzZWQgd2l0aCB0aGUgbmFtZSBvZiAiTm9tYWRpYyBhZGRyZXNzIiwgdGhleXdvdWxkIGp1 c3QgdGhpbmsgdGhlIG5vbWFkaWMgYWRkcmVzcyBpcyBhIGtpbmQgb2YgYWRkcmVzcyB0aGF0IHdv dWxkIGJlIGNoYW5nZWQuDQoNCk5vdywgZ2l2ZW4gdGhhdCB5b3UgYWxyZWFkeSBpbXBsZW1lbnRl ZCBhcHAtbGF5ZXIgbW9iaWxpdHksIGl0J3MgdG8geW91ciBhZHZhbnRhZ2UgdG8gdXNlIGl0IGV2 ZW4gd2hlbiB5b3UgYXJlIG9uIGNlbGx1bGFyIG5ldHdvcmssIGlmIHRoZXJlIHdhcyBhIHdheSB0 byB0ZWxsIHRoZSBuZXR3b3JrIHRvIHByb3ZpZGUgeW91IGEgbm9tYWRpYyBJUCBhZGRyZXNzIChh cyBvcHBvc2VkIHRvIGZpeGVkL21vYmlsZSBJUCBhZGRyZXNzIHRoYXQgaXQnZCBub3JtYWxseSBk bykuIEJlY2F1c2UgdGhhdCB3YXksIHlvdSBlbnN1cmUgeW91ciBJUCBwYWNrZXRzIHRha2UgdGhl IHNob3J0ZXN0IHBhdGgsIHdoaWNoIHJlZHVjZXMgdGhlIGVuZDJlbmQgbGF0ZW5jeS4NCg0KW1dl aV0gVGhlIGFwcGxpY2F0aW9uIGxheWVyIG1vYmlsaXR5IG1hbmFnZW1lbnQgYW5kIHRoZSByZWR1 bmRhbnQgcm91dGluZyBwYXRoIGJvdGggYnJpbmcgYWRkaXRpb25hbCBjb3N0ZXMsIGJ1dCBpdHMg aGFyZCBmb3IgYXBwbGljYXRpb24gZGV2ZWxvcGVycyB0byBoYXZlIGFuIGlkZWEgd2hpY2ggb25l IGhhcyBhIG1vcmUgbG93ZXIgY29zdC4NCg0KQmVzaWRlcywgd2UgYWxzbyBleHBlY3QgdGhhdCB0 aGUgbW9iaWxlIG5ldHdvcmsgb3BlcmF0b3JzIHdpbGwgcHJvbW90ZSAicHJvcGVyIHVzZSIgb2Yg dGhlc2UgZmxhZ3MsIGJlY2F1c2UgdGhhdCBlbnN1cmVzIGVmZmljaWVudCB1c2Ugb2YgdGhlaXIg bmV0d29yayByZXNvdXJjZXMuIExldHRpbmcgYW4gYXBwIHVzZSBhIGZpeGVkIElQIGFkZHJlc3Mg d2hlbiBpdCBjb3VsZCB2ZXJ5IHdlbGwgdXNlIGEgbm9tYWRpYyBJUCBhZGRyZXNzIGlzIHdhc3Rl IG9mIG5ldHdvcmsgcmVzb3VyY2VzIChiYWNrIGhhdWxpbmcsIFBHVyBjYXBhY2l0eSwgZXRjLikN Cg0KW1dlaV0gQWdyZWUgdGhhdCBuZXR3b3JrIG9wZXJhdG9yIHdhbnRzIHRvIHJlZHVjZSB0aGVp ciBuZXR3b3JrIGNvc3QsIGJ1dCB3ZSBjYW5ub3QgbWFrZSBzdXJlIHRoZSBhcHBsaWNhdGlvbiBk ZXZlbG9wZXIgd2lsbCBiZWNhcmUgYWJvdXQgdG9vIG11Y2ggZm9yIHRoZSBvcGVyYXRvcnMuLi4N Cg0KQXMgYSBmdXR1cmUgdGhpbmcsIHdlIGNhbiBldmVuIGVudmlzaW9uIG1vYmlsZSBvcGVyYXRv cnMgY2hhcmdpbmcgZGlmZmVyZW50bHkgYmFzZWQgb24gdGhlIHR5cGUgb2YgdHJhZmZpYyAtLSBh ZnRlciBhbGwgZWFjaCB0eXBlIGlzIGNvbnN1bWluZyBkaWZmZXJlbnQgYW1vdW50cyBvZiBuZXR3 b3JrIHJlc291cmNlcy4NCg0KQWxwZXINCg0KDQpPbiBNYXIgMjYsIDIwMTUsIGF0IDEwOjQyIFBN LCBXZWl4aW5wZW5nIChKYWNraWUpIHdyb3RlOg0KDQpIaSBBbHBlciwNCkZvciBhbiBhcHBsaWNh dGlvbiBkZXZlbG9wZXIsIGlmIHRoZXJlIGFyZSB0aHJlZSBraW5kcyBvZiBhZGRyZXNzZXMgdG8g dXNlIHdoaWNoIGFyZSAiRml4ZWQgSVAgQWRkcmVzcyIsICJTdXN0YWluZWQgSVAgQWRkcmVzcyIg YW5kICJOb21hZGljIElQIEFkZHJlc3MiLA0KdGhlbiBJIGJlbGlldmUgdGhlIGRldmVsb3BlciB3 b3VsZCBhbHdheXMgd2FudHMgdG8gdXNlIHRoZSAiRml4ZWQgSVAgYWRkcmVzcyIsIHJhdGhlciB0 aGFuIHRoZSBvdGhlciBvbmVzLiBCZWNhdXNlIGV2ZW4gdGhvdWdoIHRoZSBhcHBsaWNhdGlvbiBj b3VsZCBjb3BlIHdpdGggSVAgYWRkcmVzcw0KY2hhbmdlLCBidXQgdGhlIElQIGFkZHJlc3MgY2hh bmdlIGlzIG5vdCB3aGF0IHRoZSBhcHBsaWNhdGlvbiB3YW50Lg0KDQoNCg0KLVhpbnBlbmcNCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBBbHBlciBZ ZWdpbiBbYWxwZXIueWVnaW5AeWVnaW4ub3JnPG1haWx0bzphbHBlci55ZWdpbkB5ZWdpbi5vcmc+ XQ0Kt6LLzcqxvOQ6IDIwMTXE6jPUwjI3yNUgMjoxMw0KytW8/sjLOiBXZWl4aW5wZW5nIChKYWNr aWUpDQqzrcvNOiBEYXBlbmcgTGl1OyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4N Ctb3zOI6IFJlOiBSZaO6IERNTSBBUEkNCg0KSGkgWGlucGVuZywNCg0KSWYgeW91ciBhcHAga25v d3MgaG93IHRvIGRlYWwgd2l0aCBJUCBhZGRyZXNzIGNoYW5nZXMsIHRoZW4gaXQncyBiZXR0ZXIg aWYgd2UgZ2l2ZSBpdCBhIGNoYW5jZSB0byBkbyBzbywgYmVjYXVzZSAoYXMgdGhlIEktRCBleHBs YWlucyk6DQoNCg0KICAgQWNoaWV2aW5nIElQIHNlc3Npb24gY29udGludWl0eSBhbmQgSVAgYWRk cmVzcyByZWFjaGFiaWxpdHkgYnkgdXNpbmcNCiAgIE1vYmlsZSBJUCBpbmN1cnMgc29tZSBjb3N0 LiAgTW9iaWxlIElQIHByb3RvY29sIGZvcmNlcyB0aGUgbW9iaWxlDQogICBob3N0J3MgSVAgdHJh ZmZpYyB0byB0cmF2ZXJzZSBhIGNlbnRyYWxseS1sb2NhdGVkIHJvdXRlciAoSG9tZSBBZ2VudCwN CiAgIEhBKSwgd2hpY2ggaW5jdXJzIGFkZGl0aW9uYWwgdHJhbnNtaXNzaW9uIGxhdGVuY3kgYW5k IHVzZSBvZg0KICAgYWRkaXRpb25hbCBuZXR3b3JrIHJlc291cmNlcywgYWRkcyB0byB0aGUgbmV0 d29yayBDQVBFWCBhbmQgT1BFWCwgYW5kDQogICBkZWNyZWFzZXMgdGhlIHJlbGlhYmlsaXR5IG9m IHRoZSBuZXR3b3JrIGR1ZSB0byB0aGUgaW50cm9kdWN0aW9uIG9mIGENCiAgIHNpbmdsZSBwb2lu dCBvZiBmYWlsdXJlIFtJLUQuaWV0Zi1kbW0tcmVxdWlyZW1lbnRzXS4gIFRoZXJlZm9yZSwgSVAN CiAgIHNlc3Npb24gY29udGludWl0eSBhbmQgSVAgYWRkcmVzcyByZWFjaGFiaWxpdHkgc2hvdWxk IGJlIGJlIHByb3ZpZGVkDQogICBvbmx5IHdoZW4gbmVlZGVkLg0KDQoNCkFscGVyDQoNCk9uIE1h ciAyNiwgMjAxNSwgYXQgNzozOSBQTSwgV2VpeGlucGVuZyAoSmFja2llKSB3cm90ZToNCg0KSGkg QWxwZXINCk15IHVuZGVyc3RhbmRpbmcgYWJvdXQgdGhlIHJlYXNvbiB3aHkgdGhlcmUgbmVlZHMg dG8gZGVmaW5lIHNlcnZhbCB0eXBlcyBvZiBJUCBwcmVmaXhlcyBpcyB0aGF0LCAgaWYgdGhlIGFw cGxpY2F0aW9uIGl0c2VsZiBjb3VsZCBkZWFsIHdpdGggdGhlIGNoYW5nZSBvZiBJUCBhZGRyZXNz LCBpLmUuIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgY291bGQgZGVhbCB3aXRoIHNlc3Npb24gY29u dGludXR5IGluIGNhc2Ugb2YgSVAgYWRkcmVzcyBjaGFuZ2UsIHNvIHRoZSBob3N0IHdvdWxkIGNo b29zZSBhIG5vcm1hZGljIGFkZHJlc3Mgb3RoZXJ3aXNlIHRoZSBob3N0IHNob3VsZCBjaG9vc2Ug YSBzdXN0YWluZWQgYWRkcmVzcy4NCkJ1dCBteSBxdWVzdGlvbiBpcyB0aGF0LCBpZiB0aGUgYXBw bGljYXRpb24gY291bGQgZGVhbCB3aXRoIHNlc3Npb24gY29udGludXR5IGl0c2VsZiwgZG9lcyB0 aGF0IG1lYW4gdGhlIGFwcGxpY2F0aW9uIGlzIHdpbGxpbmcgdG8gY2hhbmdlIGl0cyBJUCBhZGRy ZXNzPyBCZWNhdXNlIGV2ZW4gdGhvdWdoIGEgbmV3IGFkZHJlc3MgbWlnaHQgYnJpbmcgc29tZSBr aW5kcyBvZiBiZW5lZml0LCBidXQgaXQgd2lsbCBhbHNvDQpicmluZyBhZGRpdGlvbmFsIGNvc3Qg Zm9yIGFwcGxpY2F0aW9uIHRvIGRlYWwgd2l0aCBJUCBhZGRyZXNzIGNoYW5nZS4NClRoYW5rcy4N Cg0KDQoNClhpbnBlbmcNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBkbW0gW2RtbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkbW0tYm91bmNlc0Bp ZXRmLm9yZz5dILT6se0gRGFwZW5nIExpdSBbbWF4cGFzc2lvbkBnbWFpbC5jb208bWFpbHRvOm1h eHBhc3Npb25AZ21haWwuY29tPl0NCreiy83KsbzkOiAyMDE1xOoz1MIyNsjVIDU6MDENCsrVvP7I yzogQWxwZXIgWWVnaW4NCrOty806IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0K 1vfM4jogW0RNTV0gu9i4tKO6IERNTSBBUEkNCg0KSGVsbG8gQWxwZXIsDQoNCkkgc3RpbGwgaGF2 ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KDQoxLiBSZWdhcmRpbmcgdGhlIGRlZmluaXRpb24g b2YgobBmaXhlZCBJUCBhZGRyZXNzobEgaW4gdGhlIGRyYWZ0Og0KDQogIKGwLSBGaXhlZCBJUCBB ZGRyZXNzDQoNCiAgIFRoaXMgaXMgd2hhdCBzdGFuZGFyZCBNb2JpbGUgSVAgcHJvdmlkZXMgd2l0 aCBhIEhvbWUgQWRkcmVzcyAoSG9BKS4NCiAgIFRoZSBtb2JpbGUgaG9zdCBpcyBjb25maWd1cmVz IGEgSG9BIGZyb20gYSBjZW50cmFsbHktbG9jYXRlZCBIb21lDQogICBOZXR3b3JrLiAgQm90aCBJ UCBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IGFyZQ0KICAg cHJvdmlkZWQgdG8gdGhlIG1vYmlsZSBob3N0IHdpdGggdGhlIGhlbHAgb2YgYSByb3V0ZXIgaW4g dGhlIEhvbWUNCiAgIE5ldHdvcmsgKEhvbWUgQWdlbnQsIEhBKS4gIFRoaXMgcm91dGVyIGFjdHMg YXMgYW4gYW5jaG9yIGZvciB0aGUgSVANCg0KYWRkcmVzcyBvZiB0aGUgbW9iaWxlIGhvc3QuobEN Cg0KSWYgdGhpcyBpcyBlcXVhbCB0byBIb0EsIHRoZW4gUkZDNTAxNCBhbHJlYWR5IGNvdmVyIHRo YXQuIFdlIGRvIG5vdCBuZWVkIHRvIHJlcGVhdCBpdCBoZXJlIHdpdGggYW5vdGhlciBuYW1lLg0K DQoyLiBSZWdhcmRpbmcgdGhlIGRlZmluaXRpb24gb2YgobBzdXN0YWluZWQgSVAgYWRkcmVzc6Gx IGluIHRoZSBkcmFmdDoNCg0KDQoiLSBTdXN0YWluZWQgSVAgQWRkcmVzcw0KDQogICBUaGlzIHR5 cGUgb2YgSVAgYWRkcmVzcyBwcm92aWRlcyBJUCBzZXNzaW9uIGNvbnRpbnVpdHkgYnV0IG5vdCBJ UA0KICAgYWRkcmVzcyByZWFjaGFiaWxpdHkuICBJdCBpcyBhY2hpZXZlZCBieSBlbnN1cmluZyB0 aGF0IHRoZSBJUCBhZGRyZXNzDQogICB1c2VkIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHNlc3Np b24gcmVtYWlucyB1c2FibGUgZGVzcGl0ZSB0aGUNCiAgIG1vdmVtZW50IG9mIHRoZSBtb2JpbGUg aG9zdC4gIFRoZSBJUCBhZGRyZXNzIG1heSBjaGFuZ2UgYWZ0ZXIgdGhlDQogICB0ZXJtaW5hdGlv biBvZiB0aGUgSVAgc2Vzc2lvbihzKSwgdGhlcmVmb3JlIGl0IGRvZXMgbm90IGV4aGliaXQNCiAg IHBlcnNpc3RlbmNlLg0KIg0KDQpUaGVyZSBpcyBubyBjbGVhciBkaXZpZGluZyBsaW5lIGJldHdl ZW4gZml4ZWQgSVAgYWRkcmVzcyBhbmQgc3VzdGFpbmVkIElQIGFkZHJlc3MuIFdoZXRoZXIgdGhl IElQIGFkZHJlc3MgaXMgdXNlZCBmb3IgcmVhY2hhYmlsaXR5IGlzIG5vdCBkZXRlcm1pbmVkIGJ5 IHRoZSBJUCBhZGRyZXNzIGl0c2VsZi4gRm9yIGV4YW1wbGUsIGV2ZW4gd2hlbiB0aGUgTU4gZ2V0 IGEgSG9BLCBhZnRlciBpdCBtb3ZlcyB0byBhbm90aGVyIGxvY2F0aW9uIG9mIHRoZSBuZXR3b3Jr LCBpdCBtYXkgZGVjaWRlIHRvIHJlbGVhc2UgY3VycmVudCBIb0EgYW5kIGdldCBhbm90aGVyIEhv QSwgaW4gdGhpcyBjYXNlIHRoZSAiZml4ZWQgSVAgYWRkcmVzcyIgYmVjb21lcyBhICJzdXN0YWlu ZWQgSVAgYWRkcmVzcyIuDQoNCkZ1cnRoZXIgbW9yZSwgdGhlIHJlYWNoYWJpbGl0eSBub3JtYWxs eSBpcyBpbXBsZW1lbnRlZCBieSBkb21haW4gbmFtZSBpbnN0ZWFkIG9mIElQIGFkZHJlc3MuIEZv ciBleGFtcGxlLCB3ZSByZWFjaCChsEdvb2dsZaGxIGJ5IGl0cyBkb21haW4gbmFtZSwgbmV2ZXIg YnkgaXShr3Mgc2VydmVyoa9zIElQIGFkZHJlc3MuDQoNClVzaW5nIHRlbXBvcmFyeSBwcml2YXRl IElQIGFkZHJlc3Mgd2UgY2FuIGFsc28gYWNoaWV2ZSB0aGUgZ29hbCBvZiChsHJlYWNoYWJpbGl0 eaGxLiBGb3IgZXhhbXBsZSwgdXNpbmcgZHluYW1pYyBETlMsIGFzIHNob3duIGluICBodHRwOi8v aHNrLm9yYXkuY29tLyAsIGl0IGNhbiAgcHJvdmlkZSByZWFjaGFiaWxpdHkgZXZlbiB0aGUgaG9z dCBnZXQgYSBwcml2YXRlIElQIGFkZHJlc3MuDQoNCjMuIFJlZ2FyZGluZyB0aGUgZGVmaW5pdGlv biBvZiChsG5vbWFkaWMgSVAgYWRkcmVzc6GxOg0KDQqhsC0gTm9tYWRpYyBJUCBBZGRyZXNzDQoN CiAgIFRoaXMgdHlwZSBvZiBJUCBhZGRyZXNzIHByb3ZpZGVzIG5laXRoZXIgSVAgc2Vzc2lvbiBj b250aW51aXR5IG5vciBJUA0KICAgYWRkcmVzcyByZWFjaGFiaWxpdHkuICBUaGUgSVAgYWRkcmVz cyBpcyBvYnRhaW5lZCBmcm9tIHRoZSBzZXJ2aW5nIElQDQogICBnYXRld2F5IGFuZCBpdCBpcyBu b3QgbWFpbnRhaW5lZCBhY3Jvc3MgZ2F0ZXdheSBjaGFuZ2VzLiAgSW4gb3RoZXINCiAgIHdvcmRz LCB0aGUgSVAgYWRkcmVzcyBtYXkgYmUgcmVsZWFzZWQgYW5kIHJlcGxhY2VkIGJ5IGEgbmV3IElQ DQogICBhZGRyZXNzIHdoZW4gdGhlIElQIGdhdGV3YXkgY2hhbmdlcyBkdWUgdG8gdGhlIG1vdmVt ZW50IG9mIHRoZSBtb2JpbGUNCg0KaG9zdC6hsQ0KDQpTZWVtcyB0aGlzIElQIGFkZHJlc3MgaXMg dGhlIElQIGFkZHJlc3MgdGhhdCB3ZSBub3JtYWxseSB1c2VkIGluIG1vc3QgY2FzZXMuIElmIHRo aXMgaXMgdGhlIGNhc2UsIHdoeSB3ZSBuZWVkIGEgbmV3IG5hbWUgZm9yIGl0Pw0KDQoNCi0tDQpE YXBlbmcgTGl1DQoNCtTaIDIwMTXE6jPUwjI1yNUg0MfG2sj9o6zPws7nMjowMqOsQWxwZXIgWWVn aW4g0LS1wKO6DQpIZWxsbyBEYXBlbmcgYW5kIEFsZXgsDQoNCkkgaG9wZSB5b3UgaGFkIGEgY2hh bmNlIHRvIGRpZ2VzdCBvdXIgcmVzcG9uc2VzIHRvIHlvdXIgY29tbWVudHMgYW5kIHF1ZXN0aW9u cyBhYm91dCB0aGUgQVBJIHdvcmsuDQpJZiB5b3UgaGF2ZSBhbnkgcmVtYWluaW5nIGlzc3Vlcywg cGxlYXNlIGxldCB1cyBrbm93IG92ZXIgdGhlIGVtYWlsIGF0IHlvdXIgZWFybGllc3QgY29udmVu aWVuY2UuDQpJdCdkIGJlIGdvb2QgaWYgeW91IGNhbiBhcnRpY3VsYXRlIHRoZW0gaW4gZGV0YWls Lg0KDQoNClRoYW5rcy4NCg0KQWxwZXINCg0K --_000_C5C3BB522B1DDF478AA09545169155B46E3320DFnkgeml507mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Alper,

Thanks for your clarification. And there are some of my replies inline.<= /p>

Thanks.

-Xinpeng

=B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yeg= in@yegin.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 5:26
=CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie)
=B3=AD=CB=CD: Dapeng Liu; dmm@ietf.org
=D6=F7=CC=E2: Re: Re=A3=BA DMM API

Xinpeng,

I'll give you a counter example to what you are claiming.

Imagine you are developing a chat (IM) client.

Because your app will be running on terminals that'd connect to both c= ellular and WiFi networks, you don't have any other option but to implement= app-layer mobility management (because otherwise your chat sessions will b= reak when the terminal moves in and out of WiFi hotspots).

[Wei] My understanding abouth the reason why a= pplication developer implements application layer support is that the host'= s IP address might change when their application is running, so they **have= to** provide
mechanism to cope with the situation, but it's n= ot their willing to change the IP address. Additional, The application= developer might be a bit of confused with the name of "Nomadic a= ddress", theywould just think the nomadic address is a kind of address that would be changed.

Now, given that you already implemented app-layer mobility, it's to yo= ur advantage to use it even when you are on cellular network, if there was = a way to tell the network to provide you a nomadic IP address (as opposed t= o fixed/mobile IP address that it'd normally do). Because that way, you ensure your IP packets take the shorte= st path, which reduces the end2end latency.

[Wei] The application layer mobility managemen= t and the redundant routing path both bring additional costes, but its hard= for application developers to have an idea which one has a more lower cost= .

Besides, we also expect that the mobile network operators will promote= "proper use" of these flags, because that ensures efficient use = of their network resources. Letting an app use a fixed IP address when it c= ould very well use a nomadic IP address is waste of network resources (back hauling, PGW capacity, etc.)

[Wei] Agree that network operator wants t= o reduce their network cost, but we cannot make sure the applicat= ion developer will becare about too much for the operators...

As a future thing, we can even envision mobile operators charging diff= erently based on the type of traffic -- after all each type is consuming di= fferent amounts of network resources.

Alper

On Mar 26, 2015, at 10:42 PM, Weixinpeng (Jackie) wrote:

Hi Alper,

For an application = developer, if there are three kinds of addresses to use which are "Fix= ed IP Address", "Sustained IP Address" and "Nomadic IP = Address",

then I believe the devel= oper would always wants to use the "Fixed IP address", rather tha= n the other ones. Because even though the application could cope with IP ad= dress

change, but the IP addre= ss change is not what the application want.

-Xinpeng

=B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yegin@yegin.org]
=B7=A2=CB=CD=CA=B1=BC=E4: = ;2015=C4=EA3=D4=C227=C8=D5 2:13
=CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie)
=B3=AD=CB=CD: Dape= ng Liu; dmm@ietf.org
=D6=F7=CC=E2: Re: = Re=A3=BA DMM API

Hi Xinpeng,

If your app knows how to deal with IP address changes, then it's bette= r if we give it a chance to do so, because (as the I-D explains):

Achieving IP session continuity and IP a= ddress reachability by using Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP session continuity and IP address reachability should be be provided only when needed.

Alper

On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote:

Hi Alper

My understanding about t= he reason why there needs to define serval types of IP prefixes i= s that, if the application itself could deal with the change of IP ad= dress, i.e. the application itself could deal with session continuty in case of IP address change, so the host would choose a= normadic address otherwise the host should choose a sustained address.
But my question is that,= if the application could deal with session continuty itself, does that mea= n the application is willing to change its IP address? Because even though = a new address might bring some kinds of benefit, but it will also

bring additional cost fo= r application to deal with IP address change.

Thanks.

Xinpeng

=B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng Liu [maxpassion@gmail.com= ]
=B7=A2=CB=CD=CA=B1=BC=E4: = ;2015=C4=EA3=D4=C226=C8=D5 5:01
=CA=D5=BC=FE=C8=CB: Alper Yegin
=B3=AD=CB=CD: dmm@ietf.org
=D6=F7=CC=E2: [DMM= ] =BB=D8=B8=B4=A3=BA DMM API

Hello Alper,

I still have the following comments:

1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the dra= ft:

=A1=B0- Fixed IP Address

This is what standard Mo= bile IP provides with a Home Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP = ;

addre= ss of the mobile host.=A1=B1

If this is equal to HoA, then RFC5014 already cover that. We do not ne= ed to repeat it here with another name.

2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in the= draft:

"- Sustained IP Addres= s This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "

There is no clear dividing line between fixed IP address and sustained= IP address. Whether the IP address is used for reachability is not determi= ned by the IP address itself. For example, even when the MN get a HoA, afte= r it moves to another location of the network, it may decide to release current HoA and get another HoA, in = this case the "fixed IP address" becomes a "sustained IP add= ress".

Further more, the reachability normally is implemented by domain name = instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its doma= in name, never by it=A1=AFs server=A1=AFs IP address.

Using temporary private IP address we can also achieve the goal o= f =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in &nb= sp;http://hsk.oray.com/<= /a> , it can provide reachability even the host get a private IP address.

3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:

=A1=B0- Nomadic IP Address

This type of IP address = provides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile&nb= sp;

host.= =A1=B1

Seems this IP address is the IP address that we normally used in most = cases. If this is the case, why we need a new name for it?

--

Dapeng Liu

=D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02= =A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your comments and q= uestions about the API work.

If you have any remaining issues, please let us know over the email at= your earliest convenience.

It'd be good if you can articulate them in detail.

Thanks.

Alper

--_000_C5C3BB522B1DDF478AA09545169155B46E3320DFnkgeml507mbxchi_-- From nobody Thu Mar 26 16:10:12 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05A61A1B7A for ; Thu, 26 Mar 2015 16:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.89 X-Spam-Level: X-Spam-Status: No, score=0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0hAqHPdCLG1 for ; Thu, 26 Mar 2015 16:10:09 -0700 (PDT) Received: from SNT004-OMC2S23.hotmail.com (snt004-omc2s23.hotmail.com [65.55.90.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD041A1B8D for ; Thu, 26 Mar 2015 16:10:07 -0700 (PDT) Received: from SNT407-EAS190 ([65.55.90.71]) by SNT004-OMC2S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 26 Mar 2015 16:10:07 -0700 X-TMN: [0/w1Ih61SkRBAYRKX1C7b626wEEDLofZ] X-Originating-Email: [cmccvic@outlook.com] Message-ID: From: "Vic Liu(CMCC)" To: "'Alper Yegin'" , "'Weixinpeng $Jackie$'" Date: Fri, 27 Mar 2015 07:12:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBoGeLai0uxqfxKRT6IkR/irdXhVw== Content-Language: zh-cn X-OriginalArrivalTime: 26 Mar 2015 23:10:07.0127 (UTC) FILETIME=[FFF21270:01D06819] Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:10:11 -0000 Hi Alper You can't claim that anyone who disagree with your proposal as =A1=B0do = not read the meeting notes etc. ...=A1=B1, it is kind of misleading and not fair. Furthermore, IETF attendees should always have the right to challenge = any proposal that they think have technical flaw. It is the correct process = that fair to everyone and not "causing productivity loss=A1=B1 as you = claimed. Thank you! All the Best Vic -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: dmm [mailto:dmm-bounces@ietf.org] =B4=FA=B1=ED Alper = Yegin =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5, =D0=C7=C6=DA=CE=E5 = 5:20 =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie) =B3=AD=CB=CD: dmm@ietf.org =D6=F7=CC=E2: Re: [DMM] DMM work teams Hi Xinpeng, On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote: > I think it's good to start serval work teams to process the work. > If there are some people complain about this, I think the reason would = > be that it might be not convient for them to participate in the online interim meeting for reasons such as timezone etc. >=20 It's always a challenge to find timeslots that works for everyone, considering the around-the-world participation in DMM (in a way, that's = true :-) > My another feeling is that after the forming of teams there is really=20 > rare discussion in the maillist where should be the main discussing=20 > place of IETF. So my suggestion is that even though there are work = teams, please also bring the discussion to mail list. That's why we, WT leaders, publish meeting notes, so that people who = were not at the meeting can join the discussion on the mailing list, and this = is, again, why WT leaders present the status at each IETF meeting. My issue is=A1=AD.. some people don't read the meeting notes.. they = don't read the I-D. they don't follow the email discussions. They don't even = remember what we presented at the previous IETF and established as common understanding across the WG. They don't bring up any discussion for = things that has been out there at least 2 IETF meeting cycles=A1=AD And then! = ask questions as if this is the first time we are presenting it (for very specific example: need for 3 distinct types of IP addresses). And then, = this causing us significant amount of productivity loss=A1=AD.=20 Alper >=20 > Thanks. >=20 > -Xinpeng >=20 > ________________________________________ > =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Brian = Haberman=20 > [brian@innovationslab.net] > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:53 > =CA=D5=BC=FE=C8=CB: dmm@ietf.org > =D6=F7=CC=E2: [DMM] DMM work teams >=20 > DMM WG, > I want to, once again, clarify the guiding principles for the DMM=20 > work teams. Hopefully, this will make it clear to all participants how = > the work teams will influence the WG. The guiding principles are: >=20 > 1. All work teams are open to input from anyone >=20 > 2. Any work team holding a meeting will announce that meeting to the=20 > WG >=20 > 3. Any document produced by a work team is treated as any individual=20 > draft >=20 > 4. Anyone can publish alternative proposals and ask the WG to consider = > them >=20 > 5. WG consensus will drive the adoption of any solutions drafts (work=20 > team generated or otherwise). >=20 > If you have any questions about the above, please contact me. >=20 > Regards, > Brian > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 26 16:33:31 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8EA1A1EF7 for ; Thu, 26 Mar 2015 16:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpky53fGaqaI for ; Thu, 26 Mar 2015 16:33:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9D71A1B88 for ; Thu, 26 Mar 2015 16:33:25 -0700 (PDT) Received: from [10.119.8.5] ([81.17.21.68]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MRmqV-1Z4GGO4AI5-00SwvJ; Fri, 27 Mar 2015 00:33:22 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=GB2312 From: Alper Yegin In-Reply-To: Date: Fri, 27 Mar 2015 01:33:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C34DE30-4682-402E-A5DE-67BD56B2BD0F@yegin.org> References: To: "Vic Liu(CMCC)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:S/wNjF/BIkS0JwjG88EiDQiZlLpEYVJVPTOg588joz8kMgV/JTH XJS8iOxLj03AlQLdl+jb/f1pYNQmbkSPX9skofR1iUWPnfoCySO2421fscO2bNaHPs3ooGL T6G44wYyoABumL8wwxrKbpPRwWbpKjuqBv9FwkUK+7UQ68irUZOnSxb7jGevbqtXqq0xKG5 VJCXZYDXSbG3PBLy9/lpw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "'Weixinpeng $Jackie$'" , dmm@ietf.org Subject: Re: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:33:27 -0000 Let's see: The so-called "challenges" that Dapeng is raising are based on the = points that: - WT captured and sent out as notes on the DMM ML before IETF 91, - Later presented to DMM WG in IETF 91. Oh, btw, they were even presented as individual contribution twice = before in the WG! So, if one does not say anything all along, and stay mute until IETF 92, = do you think this is a productive way of contributing to the WG effort?=20= WG chairs shall seriously discourage this kind of behavior in the WG. = It's unfair and discouraging for numerous people who are spending cycles = on this work. So, "anyone who disagrees" is not an accurate characterization of what = is going on in here. =20 On Mar 27, 2015, at 1:12 AM, Vic Liu(CMCC) wrote: > Hi Alper >=20 > You can't claim that anyone who disagree with your proposal as =A1=B0do = not read > the meeting notes etc. ...=A1=B1, it is kind of misleading and not = fair. > Furthermore, IETF attendees should always have the right to challenge = any > proposal that they think have technical flaw. It is the correct = process that > fair to everyone and not "causing productivity loss=A1=B1 as you = claimed. >=20 > Thank you! > All the Best > Vic >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: dmm [mailto:dmm-bounces@ietf.org] =B4=FA=B1=ED = Alper Yegin > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5, =D0=C7=C6=DA=CE=E5 = 5:20 > =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie) > =B3=AD=CB=CD: dmm@ietf.org > =D6=F7=CC=E2: Re: [DMM] DMM work teams >=20 > Hi Xinpeng, >=20 > On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote: >=20 >> I think it's good to start serval work teams to process the work. >> If there are some people complain about this, I think the reason = would=20 >> be that it might be not convient for them to participate in the = online > interim meeting for reasons such as timezone etc. >>=20 >=20 > It's always a challenge to find timeslots that works for everyone, > considering the around-the-world participation in DMM (in a way, = that's true > :-) >=20 >> My another feeling is that after the forming of teams there is really=20= >> rare discussion in the maillist where should be the main discussing=20= >> place of IETF. So my suggestion is that even though there are work = teams, > please also bring the discussion to mail list. >=20 > That's why we, WT leaders, publish meeting notes, so that people who = were > not at the meeting can join the discussion on the mailing list, and = this is, > again, why WT leaders present the status at each IETF meeting. >=20 > My issue is=A1=AD.. some people don't read the meeting notes.. they = don't read > the I-D. they don't follow the email discussions. They don't even = remember > what we presented at the previous IETF and established as common > understanding across the WG. They don't bring up any discussion for = things > that has been out there at least 2 IETF meeting cycles=A1=AD And then! = ask > questions as if this is the first time we are presenting it (for very > specific example: need for 3 distinct types of IP addresses). And = then, this > causing us significant amount of productivity loss=A1=AD.=20 >=20 >=20 >=20 > Alper >=20 >=20 >>=20 >=20 >> Thanks. >>=20 >> -Xinpeng >>=20 >> ________________________________________ >> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Brian = Haberman=20 >> [brian@innovationslab.net] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:53 >> =CA=D5=BC=FE=C8=CB: dmm@ietf.org >> =D6=F7=CC=E2: [DMM] DMM work teams >>=20 >> DMM WG, >> I want to, once again, clarify the guiding principles for the DMM=20= >> work teams. Hopefully, this will make it clear to all participants = how=20 >> the work teams will influence the WG. The guiding principles are: >>=20 >> 1. All work teams are open to input from anyone >>=20 >> 2. Any work team holding a meeting will announce that meeting to the=20= >> WG >>=20 >> 3. Any document produced by a work team is treated as any individual=20= >> draft >>=20 >> 4. Anyone can publish alternative proposals and ask the WG to = consider=20 >> them >>=20 >> 5. WG consensus will drive the adoption of any solutions drafts (work=20= >> team generated or otherwise). >>=20 >> If you have any questions about the above, please contact me. >>=20 >> Regards, >> Brian >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 26 16:46:29 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723D31A6F2A for ; Thu, 26 Mar 2015 16:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.85 X-Spam-Level: X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcgyAeh89G17 for ; Thu, 26 Mar 2015 16:46:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB801A702C for ; Thu, 26 Mar 2015 16:46:25 -0700 (PDT) Received: from [10.119.8.5] ([81.17.21.68]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0MLhDB-1Yc6Yb3NmV-000tqc; Fri, 27 Mar 2015 00:46:20 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FE76840B-8DA6-4DC3-AA41-96F884D4C1F0" From: Alper Yegin In-Reply-To: Date: Fri, 27 Mar 2015 01:46:16 +0200 Message-Id: <7CFF12C5-C0F3-4A71-B38E-DE24A2E8DAA0@yegin.org> References: , , To: "Weixinpeng (Jackie)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:XgCk5lXSHyVCPTFLtlzclY3UdTFGdqcBnWvNlKcddVOkUb4gbt8 ibbguIAiFPWmoHBoXJsiXOcQfMxYiKSgvFcz/NlIUnM1+jc2plt7CasW2TNv9hSdxSMrt25 c0KYLbxecZLl/Vqp1UmofbldKWHNxNJCRegu2kyKtaCEYWLXMmLahqMIW1+YhIbM06wxImg fvgbq78yNWWzCBdhutX2A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Re=EF=BC=9A_DMM_API?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:46:28 -0000 --Apple-Mail=_FE76840B-8DA6-4DC3-AA41-96F884D4C1F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Xinpeng, > Imagine you are developing a chat (IM) client. > Because your app will be running on terminals that'd connect to both = cellular and WiFi networks, you don't have any other option but to = implement app-layer mobility management (because otherwise your chat = sessions will break when the terminal moves in and out of WiFi = hotspots). > =20 > [Wei] My understanding abouth the reason why application developer = implements application layer support is that the host's IP address might = change when their application is running, so they **have to** provide > mechanism to cope with the situation, That's what I'm saying too. > but it's not their willing to change the IP address. Sure. My point is, they know how to deal with it. And the code already = handles it. So, what we are suggesting does not cause any new code = development from that perspective. > Additional, The application developer might be a bit of confused with = the name of "Nomadic address", theywould just think the nomadic address = is a kind of address that would be changed. >=20 Well, if you are not liking the name, please suggest a better one. We = are obviously open to improvements. > Now, given that you already implemented app-layer mobility, it's to = your advantage to use it even when you are on cellular network, if there = was a way to tell the network to provide you a nomadic IP address (as = opposed to fixed/mobile IP address that it'd normally do). Because that = way, you ensure your IP packets take the shortest path, which reduces = the end2end latency. > =20 > [Wei] The application layer mobility management and the redundant = routing path both bring additional costes, but its hard for application = developers to have an idea which one has a more lower cost. >=20 For the IM app developer, the gain is the reduced latency. What is the cost? > Besides, we also expect that the mobile network operators will promote = "proper use" of these flags, because that ensures efficient use of their = network resources. Letting an app use a fixed IP address when it could = very well use a nomadic IP address is waste of network resources (back = hauling, PGW capacity, etc.) > =20 > [Wei] Agree that network operator wants to reduce their network cost, = but we cannot make sure the application developer will becare about too = much for the operators... >=20 Operators know how to make the app developers care about things that the = operators care. > As a future thing, we can even envision mobile operators charging = differently based on the type of traffic -- after all each type is = consuming different amounts of network resources.=20 >=20 Alper > Alper >=20 >=20 > On Mar 26, 2015, at 10:42 PM, Weixinpeng (Jackie) wrote: >=20 >> Hi Alper, >> For an application developer, if there are three kinds of addresses = to use which are "Fixed IP Address", "Sustained IP Address" and "Nomadic = IP Address", >> then I believe the developer would always wants to use the "Fixed IP = address", rather than the other ones. Because even though the = application could cope with IP address >> change, but the IP address change is not what the application want. >> =20 >> -Xinpeng >> =20 >> =20 >> =B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yegin@yegin.org] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:13 >> =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie) >> =B3=AD=CB=CD: Dapeng Liu; dmm@ietf.org >> =D6=F7=CC=E2: Re: Re=A3=BA DMM API >>=20 >> Hi Xinpeng, >>=20 >> If your app knows how to deal with IP address changes, then it's = better if we give it a chance to do so, because (as the I-D explains): >>=20 >> Achieving IP session continuity and IP address reachability by = using >> Mobile IP incurs some cost. Mobile IP protocol forces the mobile >> host's IP traffic to traverse a centrally-located router (Home = Agent, >> HA), which incurs additional transmission latency and use of >> additional network resources, adds to the network CAPEX and OPEX, = and >> decreases the reliability of the network due to the introduction = of a >> single point of failure [I-D.ietf-dmm-requirements]. Therefore, = IP >> session continuity and IP address reachability should be be = provided >> only when needed. >>=20 >>=20 >> Alper >>=20 >> On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote: >>=20 >>> Hi Alper >>> My understanding about the reason why there needs to define serval = types of IP prefixes is that, if the application itself could deal with = the change of IP address, i.e. the application itself could deal with = session continuty in case of IP address change, so the host would choose = a normadic address otherwise the host should choose a sustained address. >>> But my question is that, if the application could deal with session = continuty itself, does that mean the application is willing to change = its IP address? Because even though a new address might bring some kinds = of benefit, but it will also >>> bring additional cost for application to deal with IP address = change. >>> Thanks. >>> =20 >>> Xinpeng >>> =20 >>> =20 >>> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng = Liu [maxpassion@gmail.com] >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5 5:01 >>> =CA=D5=BC=FE=C8=CB: Alper Yegin >>> =B3=AD=CB=CD: dmm@ietf.org >>> =D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA DMM API >>>=20 >>> Hello Alper, >>>=20 >>> I still have the following comments: >>>=20 >>> 1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the = draft: >>>=20 >>> =A1=B0- Fixed IP Address >>> This is what standard Mobile IP provides with a Home Address = (HoA). >>> The mobile host is configures a HoA from a centrally-located Home >>> Network. Both IP session continuity and IP address reachability = are >>> provided to the mobile host with the help of a router in the Home >>> Network (Home Agent, HA). This router acts as an anchor for the = IP=20 >>> address of the mobile host.=A1=B1=20 >>>=20 >>> If this is equal to HoA, then RFC5014 already cover that. We do not = need to repeat it here with another name. >>>=20 >>> 2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in = the draft: >>>=20 >>> "- Sustained IP Address >>>=20 >>> This type of IP address provides IP session continuity but not IP >>> address reachability. It is achieved by ensuring that the IP = address >>> used at the beginning of the session remains usable despite the >>> movement of the mobile host. The IP address may change after the >>> termination of the IP session(s), therefore it does not exhibit >>> persistence. >>> " >>> There is no clear dividing line between fixed IP address and = sustained IP address. Whether the IP address is used for reachability is = not determined by the IP address itself. For example, even when the MN = get a HoA, after it moves to another location of the network, it may = decide to release current HoA and get another HoA, in this case the = "fixed IP address" becomes a "sustained IP address". >>>=20 >>> Further more, the reachability normally is implemented by domain = name instead of IP address. For example, we reach =A1=B0Google=A1=B1 by = its domain name, never by it=A1=AFs server=A1=AFs IP address.=20 >>>=20 >>> Using temporary private IP address we can also achieve the goal of = =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in = http://hsk.oray.com/ , it can provide reachability even the host get a = private IP address. >>>=20 >>> 3. Regarding the definition of =A1=B0nomadic IP address=A1=B1: >>>=20 >>> =A1=B0- Nomadic IP Address >>> This type of IP address provides neither IP session continuity = nor IP >>> address reachability. The IP address is obtained from the = serving IP >>> gateway and it is not maintained across gateway changes. In = other >>> words, the IP address may be released and replaced by a new IP >>> address when the IP gateway changes due to the movement of the = mobile=20 >>> host.=A1=B1 >>>=20 >>> Seems this IP address is the IP address that we normally used in = most cases. If this is the case, why we need a new name for it? >>>=20 >>>=20 >>> --=20 >>> Dapeng Liu >>>=20 >>> =D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72= :02=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA >>>> Hello Dapeng and Alex, >>>>=20 >>>> I hope you had a chance to digest our responses to your comments = and questions about the API work. >>>> If you have any remaining issues, please let us know over the email = at your earliest convenience. >>>> It'd be good if you can articulate them in detail. >>>>=20 >>>>=20 >>>> Thanks. >>>>=20 >>>> Alper --Apple-Mail=_FE76840B-8DA6-4DC3-AA41-96F884D4C1F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Xinpeng,

Imagine you are developing a = chat (IM) client.
Because your app will be running on = terminals that'd connect to both cellular and WiFi networks, you don't = have any other option but to implement app-layer mobility management = (because otherwise your chat sessions will break when the terminal moves = in and out of WiFi hotspots).

[Wei] My understanding abouth the reason why = application developer implements application layer support is that the = host's IP address might change when their application is running, so = they **have to** provide
mechanism to cope with the = situation, =

That's what I'm saying too.

but it's not their = willing to change the IP address. =

Sure. My point is, they know how to deal with = it. And the code already handles it. So, what we are suggesting does not = cause any new code development from that = perspective.

Additional, = The application developer might be a bit of confused with the = name of "Nomadic address", theywould just think the nomadic address is a = kind of address that would be changed.

Well, if you are not liking the = name, please suggest a better one. We are obviously open to = improvements.

Now, given that you already = implemented app-layer mobility, it's to your advantage to use it even = when you are on cellular network, if there was a way to tell the network = to provide you a nomadic IP address (as opposed to fixed/mobile IP = address that it'd normally do). Because that way, you ensure your IP = packets take the shortest path, which reduces the end2end = latency.

[Wei] The = application layer mobility management and the redundant routing path = both bring additional costes, but its hard for application developers to = have an idea which one has a more lower = cost.

For the IM app developer, the gain is the reduced = latency.
What is the cost?

Besides, we also expect that = the mobile network operators will promote "proper use" of these flags, = because that ensures efficient use of their network resources. Letting = an app use a fixed IP address when it could very well use a nomadic IP = address is waste of network resources (back hauling, PGW capacity, = etc.)

[Wei] Agree = that network operator wants to reduce their network cost, = but we cannot make sure the application developer will becare about = too much for the = operators...

Operators know how to make the app = developers care about things that the operators = care.

As a future thing, we can = even envision mobile operators charging differently based on the type of = traffic -- after all each type is consuming different amounts of network = resources.

Alper

<= br>

Hi Alper,
For an application developer, if there are = three kinds of addresses to use which are "Fixed IP Address", "Sustained = IP Address" and "Nomadic IP Address",
then I believe the developer would always = wants to use the "Fixed IP address", rather than the other ones. Because = even though the application could cope with IP address
change, but the IP = address change is not what the application want.

-Xinpeng

=B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yegin@yegin.org]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2015=C4=EA3=D4=C22= 7=C8=D5 2:13
=CA=D5=BC=FE=C8=CB: Weixinpeng = (Jackie)
=B3=AD=CB=CD: Dapeng Liu; dmm@ietf.org
=D6=F7=CC=E2: Re: Re=A3=BA DMM = API

Hi = Xinpeng,

If your app knows how to deal with IP = address changes, then it's better if we give it a chance to do so, = because (as the I-D explains):

Achieving IP session = continuity and IP address reachability by using Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP session continuity and IP address reachability should be be provided only when = needed.

Alper

=
On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) = wrote:

Hi Alper
My understanding about the reason why there needs = to define serval types of IP prefixes is that, if the = application itself could deal with the change of IP address, i.e. the = application itself could deal with session continuty in case of IP = address change, so the host would choose a normadic address otherwise = the host should choose a sustained address.
But my question is that, if the application = could deal with session continuty itself, does that mean the application = is willing to change its IP address? Because even though a new address = might bring some kinds of benefit, but it will also
bring additional cost = for application to deal with IP address change.
Thanks.

Xinpeng

=B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng Liu [maxpassion@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2015=C4=EA3=D4=C22= 6=C8=D5 5:01
=CA=D5=BC=FE=C8=CB: Alper = Yegin
=B3=AD=CB=CD: dmm@ietf.org
=D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA = DMM API

Hello = Alper,

I still have the following = comments:

1. Regarding the definition of = =A1=B0fixed IP address=A1=B1 in the = draft:

=A1=B0- Fixed IP = Address
address of the mobile = host.=A1=B1

If this is equal to = HoA, then RFC5014 already cover that. We do not need to repeat it here = with another name.

2. Regarding the definition = of =A1=B0sustained IP address=A1=B1 in the = draft:

"- Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "
There is no clear dividing line between fixed IP = address and sustained IP address. Whether the IP address is used for = reachability is not determined by the IP address itself. For example, = even when the MN get a HoA, after it moves to another location of the = network, it may decide to release current HoA and get another HoA, in = this case the "fixed IP address" becomes a "sustained IP = address".

Further more, the reachability = normally is implemented by domain name instead of IP address. For = example, we reach =A1=B0Google=A1=B1 by its domain name, never by it=A1=AF= s server=A1=AFs IP = address.

Using temporary private IP = address we can also achieve the goal of =A1=B0reachability=A1=B1. For = example, using dynamic DNS, as shown in http://hsk.oray.com/ , it can provide = reachability even the host get a private IP = address.

3. Regarding the definition of = =A1=B0nomadic IP address=A1=B1:

=A1=B0- Nomadic = IP Address
host.=A1=B1

Seems this = IP address is the IP address that we normally used in most cases. If = this is the case, why we need a new name for = it?

--
Dapeng = Liu

=D4=DA 2015=C4=EA3=D4=C22= 5=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02=A3=ACAlper Yegin = =D0=B4=B5=C0=A3=BA
To: "'Alper Yegin'" Date: Thu, 26 Mar 2015 19:12:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBoIoVsuIgmYWWCQxO6T3oAnzIG6w== Content-Language: zh-cn X-OriginalArrivalTime: 27 Mar 2015 00:10:30.0305 (UTC) FILETIME=[6F872910:01D06822] Archived-At: Cc: "'Weixinpeng $Jackie$'" , dmm@ietf.org Subject: Re: [DMM] DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:10:33 -0000 Hi Alper I think Dapeng is not the only one who challenge your proposal and = please don't be personal. Working group chair should prevent anyone who use the = WT to push their own draft. That's working group and AD should really care about. Thank you=20 All the best!=20 Vic -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Alper Yegin [mailto:alper.yegin@yegin.org]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5, =D0=C7=C6=DA=CB=C4 = 18:33 =CA=D5=BC=FE=C8=CB: Vic Liu(CMCC) =B3=AD=CB=CD: 'Weixinpeng (Jackie)'; dmm@ietf.org =D6=F7=CC=E2: Re: [DMM] DMM work teams Let's see: The so-called "challenges" that Dapeng is raising are based on the = points that: - WT captured and sent out as notes on the DMM ML before IETF 91, - Later presented to DMM WG in IETF 91. Oh, btw, they were even presented as individual contribution twice = before in the WG! So, if one does not say anything all along, and stay mute until IETF 92, = do you think this is a productive way of contributing to the WG effort?=20 WG chairs shall seriously discourage this kind of behavior in the WG. = It's unfair and discouraging for numerous people who are spending cycles on = this work. So, "anyone who disagrees" is not an accurate characterization of what = is going on in here. =20 On Mar 27, 2015, at 1:12 AM, Vic Liu(CMCC) wrote: > Hi Alper >=20 > You can't claim that anyone who disagree with your proposal as = =A1=B0do not=20 > read the meeting notes etc. ...=A1=B1, it is kind of misleading and = not fair. > Furthermore, IETF attendees should always have the right to challenge=20 > any proposal that they think have technical flaw. It is the correct=20 > process that fair to everyone and not "causing productivity = loss=A1=B1 as you claimed. >=20 > Thank you! > All the Best > Vic >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: dmm [mailto:dmm-bounces@ietf.org] =B4=FA=B1=ED = Alper Yegin > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5, = =D0=C7=C6=DA=CE=E5 5:20 > =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie) > =B3=AD=CB=CD: dmm@ietf.org > =D6=F7=CC=E2: Re: [DMM] DMM work teams >=20 > Hi Xinpeng, >=20 > On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote: >=20 >> I think it's good to start serval work teams to process the work. >> If there are some people complain about this, I think the reason=20 >> would be that it might be not convient for them to participate in the = >> online > interim meeting for reasons such as timezone etc. >>=20 >=20 > It's always a challenge to find timeslots that works for everyone,=20 > considering the around-the-world participation in DMM (in a way,=20 > that's true > :-) >=20 >> My another feeling is that after the forming of teams there is really = >> rare discussion in the maillist where should be the main discussing=20 >> place of IETF. So my suggestion is that even though there are work=20 >> teams, > please also bring the discussion to mail list. >=20 > That's why we, WT leaders, publish meeting notes, so that people who=20 > were not at the meeting can join the discussion on the mailing list,=20 > and this is, again, why WT leaders present the status at each IETF meeting. >=20 > My issue is=A1=AD.. some people don't read the meeting notes.. they = don't=20 > read the I-D. they don't follow the email discussions. They don't even = > remember what we presented at the previous IETF and established as=20 > common understanding across the WG. They don't bring up any discussion = > for things that has been out there at least 2 IETF meeting = cycles=A1=AD And=20 > then! ask questions as if this is the first time we are presenting it=20 > (for very specific example: need for 3 distinct types of IP=20 > addresses). And then, this causing us significant amount of = productivity loss=A1=AD. >=20 >=20 >=20 > Alper >=20 >=20 >>=20 >=20 >> Thanks. >>=20 >> -Xinpeng >>=20 >> ________________________________________ >> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Brian = Haberman=20 >> [brian@innovationslab.net] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:53 >> =CA=D5=BC=FE=C8=CB: dmm@ietf.org >> =D6=F7=CC=E2: [DMM] DMM work teams >>=20 >> DMM WG, >> I want to, once again, clarify the guiding principles for the DMM=20 >> work teams. Hopefully, this will make it clear to all participants=20 >> how the work teams will influence the WG. The guiding principles = are: >>=20 >> 1. All work teams are open to input from anyone >>=20 >> 2. Any work team holding a meeting will announce that meeting to the=20 >> WG >>=20 >> 3. Any document produced by a work team is treated as any individual=20 >> draft >>=20 >> 4. Anyone can publish alternative proposals and ask the WG to=20 >> consider them >>=20 >> 5. WG consensus will drive the adoption of any solutions drafts (work = >> team generated or otherwise). >>=20 >> If you have any questions about the above, please contact me. >>=20 >> Regards, >> Brian >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 26 17:19:50 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2B1A877C for ; Thu, 26 Mar 2015 17:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3XkQHWUm71L for ; Thu, 26 Mar 2015 17:19:46 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8573C1A8747 for ; Thu, 26 Mar 2015 17:19:45 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so81566624wgb.0 for ; Thu, 26 Mar 2015 17:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=398xsV4FZMv1YpKUfbd+ijuFCgSj7/XxC2JUwuB6U3E=; b=zMoE400ZfImykyUnzqElAJcVAIKCkZE7qpKt6As2OWeftBH1NWqmEyj+fZyZlT7g1y yT0Fuy4/XbVpgG7rKhFBtuElOXKSzCjZHwX9lngoUBpMtZfdS3Zoe7GIAYVuhoMSuneo lSp/RITIE6n82QYKmVgowKqPGwZ8pojN2yBKBuE8Nh+y/ZrdTF1HXfdJUUPxS+TE4Mvu 0jlEVHL5wpSW3mxV7AE5jadMTsqm8yyHd/+SIU9z9z9Vh13mkHMDa/PpB3zkXDGzLcNJ cwB2xWbJMV6fZhJf24bEK8C3k2rK39HsECXmZX3oaabbVx++1P9pmqLEqIYzkbGGXH1A TP1w== X-Received: by 10.194.133.101 with SMTP id pb5mr33706989wjb.40.1427415584284; Thu, 26 Mar 2015 17:19:44 -0700 (PDT) Received: from [31.133.166.135] (dhcp-a687.meeting.ietf.org. [31.133.166.135]) by mx.google.com with ESMTPSA id o10sm1076822wiy.18.2015.03.26.17.19.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 17:19:43 -0700 (PDT) Date: Thu, 26 Mar 2015 19:18:41 -0500 From: Dapeng Liu To: Alper Yegin Message-ID: In-Reply-To: <1C34DE30-4682-402E-A5DE-67BD56B2BD0F@yegin.org> References: <1C34DE30-4682-402E-A5DE-67BD56B2BD0F@yegin.org> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5514a1e1_1313c32b_a9e" Archived-At: Cc: "Weixinpeng $Jackie$" , dmm@ietf.org Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= DMM work teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:19:48 -0000 --5514a1e1_1313c32b_a9e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF= =BC=8C=E4=B8=8B=E5=8D=886:33=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A > =20 > Let's see: > =20 > The so-called =22challenges=22 that Dapeng is raising are based on the = points that: > =20 > - WT captured and sent out as notes on the DMM ML before IET=46 91, > - Later presented to DMM WG in IET=46 91. > =20 > Oh, btw, they were even presented as individual contribution twice befo= re in the WG=21 Hi Alper, You are misleading. As you may remember, I have raised concerns several times regarding this = proposal even during the offline discussion with you. And the proposal is= not improved to address my concern. There is no much changing of the pro= posal since you present the first time and my concerns still remain. =20 > =20 > So, if one does not say anything all along, and stay mute until IET=46 = 92, do you think this is a productive way of contributing to the WG effor= t=3F =20 > =20 > WG chairs shall seriously discourage this kind of behavior in the WG. I= t's unfair and discouraging for numerous people who are spending cycles o= n this work. The chairs should guarantee the process is open and fair to others. Unfor= tunately, our AD have got complains of this WT. -Dapeng =20 > =20 > =20 > So, =22anyone who disagrees=22 is not an accurate characterization of w= hat is going on in here. > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > On Mar 27, 2015, at 1:12 AM, Vic Liu(CMCC) wrote: > =20 > > Hi Alper > > =20 > > You can't claim that anyone who disagree with your proposal as =E2=80= =9Cdo not read > > the meeting notes etc. ...=E2=80=9D, it is kind of misleading and not= fair. > > =46urthermore, IET=46 attendees should always have the right to chall= enge any > > proposal that they think have technical flaw. It is the correct proce= ss that > > fair to everyone and not =22causing productivity loss=E2=80=9D as you= claimed. > > =20 > > Thank you=21 > > All the Best > > Vic > > =20 > > =20 > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bmailto:dmm-bounces=40ietf.org=5D = =E4=BB=A3=E8=A1=A8 Alper Yegin > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97= =A5, =E6=98=9F=E6=9C=9F=E4=BA=94 5:20 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Weixinpeng (Jackie) > > =E6=8A=84=E9=80=81: dmm=40ietf.org (mailto:dmm=40ietf.org) > > =E4=B8=BB=E9=A2=98: Re: =5BDMM=5D DMM work teams > > =20 > > Hi Xinpeng, > > =20 > > On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote: > > =20 > > > I think it's good to start serval work teams to process the work. > > > If there are some people complain about this, I think the reason wo= uld =20 > > > be that it might be not convient for them to participate in the onl= ine > > > =20 > > =20 > > interim meeting for reasons such as timezone etc. > > > =20 > > =20 > > =20 > > It's always a challenge to find timeslots that works for everyone, > > considering the around-the-world participation in DMM (in a way, that= 's true > > :-) > > =20 > > > My another feeling is that after the forming of teams there is real= ly =20 > > > rare discussion in the maillist where should be the main discussing= =20 > > > place of IET=46. So my suggestion is that even though there are wor= k teams, > > > =20 > > =20 > > please also bring the discussion to mail list. > > =20 > > That's why we, WT leaders, publish meeting notes, so that people who = were > > not at the meeting can join the discussion on the mailing list, and t= his is, > > again, why WT leaders present the status at each IET=46 meeting. > > =20 > > My issue is=E2=80=A6.. some people don't read the meeting notes.. the= y don't read > > the I-D. they don't follow the email discussions. They don't even rem= ember > > what we presented at the previous IET=46 and established as common > > understanding across the WG. They don't bring up any discussion for t= hings > > that has been out there at least 2 IET=46 meeting cycles=E2=80=A6 And= then=21 ask > > questions as if this is the first time we are presenting it (for very= > > specific example: need for 3 distinct types of IP addresses). And the= n, this > > causing us significant amount of productivity loss=E2=80=A6. =20 > > =20 > > =20 > > =20 > > Alper > > =20 > > =20 > > =20 > > > Thanks. > > > =20 > > > -Xinpeng > > > =20 > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bdmm-bounces=40ietf.org (mailto:= dmm-bounces=40ietf.org)=5D =E4=BB=A3=E8=A1=A8 Brian Haberman =20 > > > =5Bbrian=40innovationslab.net (mailto:brian=40innovationslab.net)=5D= > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97= =A5 2:53 > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: dmm=40ietf.org (mailto:dmm=40ietf.org)= > > > =E4=B8=BB=E9=A2=98: =5BDMM=5D DMM work teams > > > =20 > > > DMM WG, > > > I want to, once again, clarify the guiding principles for the DMM =20 > > > work teams. Hopefully, this will make it clear to all participants = how =20 > > > the work teams will influence the WG. The guiding principles are: > > > =20 > > > 1. All work teams are open to input from anyone > > > =20 > > > 2. Any work team holding a meeting will announce that meeting to th= e =20 > > > WG > > > =20 > > > 3. Any document produced by a work team is treated as any individua= l =20 > > > draft > > > =20 > > > 4. Anyone can publish alternative proposals and ask the WG to consi= der =20 > > > them > > > =20 > > > 5. WG consensus will drive the adoption of any solutions drafts (wo= rk =20 > > > team generated or otherwise). > > > =20 > > > If you have any questions about the above, please contact me. > > > =20 > > > Regards, > > > Brian > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > dmm mailing list > > > dmm=40ietf.org (mailto:dmm=40ietf.org) > > > https://www.ietf.org/mailman/listinfo/dmm > > > =20 > > =20 > > =20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > dmm mailing list > > dmm=40ietf.org (mailto:dmm=40ietf.org) > > https://www.ietf.org/mailman/listinfo/dmm > > =20 > =20 > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > dmm mailing list > dmm=40ietf.org (mailto:dmm=40ietf.org) > https://www.ietf.org/mailman/listinfo/dmm > =20 > =20 --5514a1e1_1313c32b_a9e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=E5=9C= =A8 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=BC=8C= =E4=B8=8B=E5=8D=886:33=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A

Let's see:
<= div>
The so-called =22challenges=22 that Dapeng is raising = are based on the points that:

- WT captured and = sent out as notes on the DMM ML before IET=46 91,
- Later prese= nted to DMM WG in IET=46 91.

Oh, btw, they were= even presented as individual contribution twice before in the WG=21
Hi Alper,

= You are misleading.

As you may remember, I have = raised concerns several times regarding this proposal even during the off= line discussion with you. And the proposal is not improved to address my = concern. There is no much changing of the proposal since you present the = first time and my concerns still remain.

<= div>So, if one does not say anything all along, and stay mute until IET=46= 92, do you think this is a productive way of contributing to the WG effo= rt=3F

WG chairs shall seriously discourage this= kind of behavior in the WG. It's unfair and discouraging for numerous pe= ople who are spending cycles on this work.
The chairs should guarantee the process is open and fair to o= thers. Unfortunately, our AD have got complains of this WT.

-Dapeng

So, = =22anyone who disagrees=22 is not an accurate characterization of what is= going on in here.

=
On Mar 27, 2015, at 1:12 AM, Vic Liu(CMCC) wrote:

Hi Alper
You can't claim that anyone who disagree with your proposal = as =E2=80=9Cdo not read
the meeting notes etc. ...=E2=80=9D, it= is kind of misleading and not fair.
=46urthermore, IET=46 atte= ndees should always have the right to challenge any
proposal th= at they think have technical flaw. It is the correct process that
fair to everyone and not =22causing productivity loss=E2=80=9D as you= claimed.

Thank you=21
All the Best
Vic

-----=E9=82=AE=E4=BB=B6= =E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bmailto:dmm-bounces=40ietf.org<= /a>=5D =E4=BB=A3=E8=A1=A8 Alper Yegin
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=94= 5:20
=E6=94=B6=E4=BB=B6=E4=BA=BA: Weixinpeng (Jackie)
=E6=8A=84=E9=80=81: dmm=40ietf.or= g
=E4=B8=BB=E9=A2=98: Re: =5BDMM=5D DMM work teams

Hi Xinpeng,

On Mar 26, 2015, at= 10:49 PM, Weixinpeng (Jackie) wrote:

I think it's good to start serval work teams to = process the work.
If there are some people complain about this,= I think the reason would
be that it might be not convient for= them to participate in the online
interim m= eeting for reasons such as timezone etc.

It's always a challenge to f= ind timeslots that works for everyone,
considering the around-t= he-world participation in DMM (in a way, that's true
:-)
<= div>
My another feeling = is that after the forming of teams there is really
rare discus= sion in the maillist where should be the main discussing
place= of IET=46. So my suggestion is that even though there are work teams,
please also bring the discussion to mail list.=

That's why we, WT leaders, publish meeting note= s, so that people who were
not at the meeting can join the disc= ussion on the mailing list, and this is,
again, why WT leaders = present the status at each IET=46 meeting.

My is= sue is=E2=80=A6.. some people don't read the meeting notes.. they don't r= ead
the I-D. they don't follow the email discussions. They don'= t even remember
what we presented at the previous IET=46 and es= tablished as common
understanding across the WG. They don't bri= ng up any discussion for things
that has been out there at leas= t 2 IET=46 meeting cycles=E2=80=A6 And then=21 ask
questions as= if this is the first time we are presenting it (for very
speci= fic example: need for 3 distinct types of IP addresses). And then, this
causing us significant amount of productivity loss=E2=80=A6.

Alper

=

Thanks.

-Xinpeng

=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
=E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bdmm-bounces=40ietf.org=5D =E4= =BB=A3=E8=A1=A8 Brian Haberman
=5Bbrian=40innovationslab.net=5D
=E5=8F=91= =E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97=A5 2:53
=E6=94=B6=E4=BB=B6=E4=BA=BA: = dmm=40ietf.org
=E4=B8=BB=E9=A2=98: =5BDMM=5D DMM work teams=

DMM WG,
I want to, once again, cla= rify the guiding principles for the DMM
work teams. Hopefully,= this will make it clear to all participants how
the work team= s will influence the WG. The guiding principles are:

1. All work teams are open to input from anyone

2. Any work team holding a meeting will announce that meeting to th= e
WG

3. Any document produced by a wo= rk team is treated as any individual
draft

4. Anyone can publish alternative proposals and ask the WG to consi= der
them

5. WG consensus will drive t= he adoption of any solutions drafts (work
team generated or ot= herwise).

If you have any questions about the ab= ove, please contact me.

Regards,
Brian=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
dmm mailing list
dmm=40ietf.org
https://www.ietf.org/mailman/listinfo/dmm

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dmm mailing list
dmm=40ietf.org
https://www.ietf.org/mailman= /listinfo/dmm

=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dmm mail= ing list
dmm=40ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dmm
=20 =20 =20 =20
=20

--5514a1e1_1313c32b_a9e-- From nobody Mon Mar 30 07:08:15 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B148D1ACEF6 for ; Mon, 30 Mar 2015 07:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWMCl6zop5n4 for ; Mon, 30 Mar 2015 07:08:11 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 277FD1ACE08 for ; Mon, 30 Mar 2015 07:08:09 -0700 (PDT) Received: from [192.168.26.107] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77419399; Mon, 30 Mar 2015 15:08:08 +0100 From: "Seil Jeon" To: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> In-Reply-To: <006701d06800$96a57960$c3f06c20$@av.it.pt> Date: Mon, 30 Mar 2015 15:08:07 +0100 Message-ID: <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01D06AFB.547B59D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/5uK9A1Q Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: [DMM] FW: Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 14:08:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000E_01D06AFB.547B59D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01D06AFB.547B59D0" ------=_NextPart_001_000F_01D06AFB.547B59D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Danny, Any comments? Regards, Seil Jeon From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case in the draft. On receiving this API with the SUSTAINED IP address type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access network. So, actual obtaining of the IP address will be tried one time while attached at a specific access network. Even some applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, that is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should show its requirement with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon ------=_NextPart_001_000F_01D06AFB.547B59D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = Danny,

Any = comments?

Regards,
Seil = Jeon

From:= = dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil = Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: = dmm@ietf.org
Subject: [DMM] Answer on raised questions for the = proposed API

Hi,

I = could attend DMM Thursday meeting via MeetEcho.
I = could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions.

First, regarding the need of = the proposed API (IPV6_PREFER_SRC_NEW),

The = use of the proposed API is suggested in the SUSTAINED IP address case in = the draft. On receiving this API with the SUSTAINED IP address type at = the IP stack, it will try to get a new SUSTAINED IP address if there is = no available in the currently attached access network. So, actual = obtaining of the IP address will be tried one time while attached at a = specific access network. Even some applications put this API after, the = already obtained SUSTAINED IP will be used. So, no worries about = abuse.

Second question sounded to me = like that this API is not needed because the host can get a new = SUSTAINED IP address, right?
If = the question is right, I don’t understand what the question is = meant, that is how the host can get a new SUSTAINED IP = address?
Based on the definition of = three types of IP address, an application should show its requirement = with an API among them. If it is the SUSTAINED IP address, how do we = expect the IP stack will try to get a new SUSTAINED IP = address?

Besides, the propsoed API is = not used alone but with the three type APIs.

Regards,
=

Seil = Jeon

------=_NextPart_001_000F_01D06AFB.547B59D0-- ------=_NextPart_000_000E_01D06AFB.547B59D0 Content-Type: text/plain; name="Untitled attachment 00120.sdx" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Untitled attachment 00120.sdx" _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ------=_NextPart_000_000E_01D06AFB.547B59D0-- From nobody Mon Mar 30 08:44:07 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4D1A0113 for ; Mon, 30 Mar 2015 08:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tyJoc9Udp5b for ; Mon, 30 Mar 2015 08:44:01 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id B05BC1A00E4 for ; Mon, 30 Mar 2015 08:44:01 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 30 Mar 2015 08:44:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,494,1422950400"; d="scan'208,217";a="548418578" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga003.jf.intel.com with ESMTP; 30 Mar 2015 08:43:59 -0700 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by IRSMSX151.ger.corp.intel.com (163.33.192.59) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 30 Mar 2015 16:43:57 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by LCSMSX154.ger.corp.intel.com ([169.254.7.140]) with mapi id 14.03.0224.002; Mon, 30 Mar 2015 18:43:56 +0300 From: "Moses, Danny" To: Seil Jeon Thread-Topic: [DMM] Answer on raised questions for the proposed API Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYgC2fzqAAAjVfcA= Date: Mon, 30 Mar 2015 15:43:55 +0000 Message-ID: References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> In-Reply-To: <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.11] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134908F15HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 15:44:05 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134908F15HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request= a sustained IP address more than once after each movement to a new LAN (wi= th a different prefix), than there will be no abuse. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request= a Nomadic IP address and a Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any appl= ications requesting any addresses. This way, whenever an application is lau= nched and requests either a Nomadic or Sustained IP address, the stack can = provide one without having to issue a request to the network. In this case,= there is no need for this flag from the application. Another potential implementation of the IP stack in the host is not to requ= est IP addresses in advance. In that case, it will issue a request for a No= madic IP address or a Sustained IP address the first time an application re= quests one and use it for subsequent requests as long as it is not moving t= o a different LAN. Once it moves, it will again request a new IP address (N= omadic or Sustained - according to what is required) after receiving the fi= rst request from any application. In this case as well, there is no need fo= r this flag. As a matter of fact, if such a flag is defined, I cannot think of an exampl= e where it will not be used. It seems to me that applications will always r= equest a refreshed Sustained IP address (when requesting a Sustained IP add= ress). If this is correct, the flag is redundant. Can you provide a scenario in which an application will not request to refr= esh the Sustained IP address? Regards, /Danny From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answ= ers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case i= n the draft. On receiving this API with the SUSTAINED IP address type at th= e IP stack, it will try to get a new SUSTAINED IP address if there is no av= ailable in the currently attached access network. So, actual obtaining of t= he IP address will be tried one time while attached at a specific access ne= twork. Even some applications put this API after, the already obtained SUST= AINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the = host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, th= at is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should= show its requirement with an API among them. If it is the SUSTAINED IP add= ress, how do we expect the IP stack will try to get a new SUSTAINED IP addr= ess? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134908F15HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Seil,

As to the potential of= abuse:

Yes, I see your point = and you are correct. If the IP stack will not request a sustained IP addres= s more than once after each movement to a new LAN (with a different prefix)= , than there will be no abuse.

As to the second comme= nt, please let me elaborate:

One potential implemen= tation of the IP stack in the host, can be to request a Nomadic IP address = and a Sustained IP address whenever connecting to a network, and when= ever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an appli= cation is launched and requests either a Nomadic or Sustained IP address, t= he stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the application.

Another potential impl= ementation of the IP stack in the host is not to request IP addresses in ad= vance. In that case, it will issue a request for a Nomadic IP address or a = Sustained IP address the first time an application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again request a= new IP address (Nomadic or Sustained – according to what is required= ) after receiving the first request from any application. In this case as well, there is no need for this flag.

As a matter of fact, i= f such a flag is defined, I cannot think of an example where it will not be= used. It seems to me that applications will always request a refreshed Sus= tained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant.

Can you provide a scen= ario in which an application will not request to refresh the Sustained IP a= ddress?

Regards,

&nbs= p; /Danny=

From: Seil Jeo= n [mailto:seiljeon@av.it.pt]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org
Subject: FW: [DMM] Answer on raised questions for the proposed API

Hi Danny,

Any comments?

Regards,

Seil Jeon

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org
Subject: [DMM] Answer on raised questions for the proposed API<= /o:p>

Hi,

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someon= e. Here goes answers to the raised questions.

First, regarding the need of the proposed API (IPV6_PREFER= _SRC_NEW),

The use of the proposed API is suggested in the SUSTAINED = IP address case in the draft. On receiving this API with the SUSTAINED IP a= ddress type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access netwo= rk. So, actual obtaining of the IP address will be tried one time while att= ached at a specific access network. Even some applications put this API aft= er, the already obtained SUSTAINED IP will be used. So, no worries about abuse.

Second question sounded to me like that this API is not ne= eded because the host can get a new SUSTAINED IP address, right?=

If the question is right, I don’t understand what th= e question is meant, that is how the host can get a new SUSTAINED IP addres= s?

Based on the definition of three types of IP address, an a= pplication should show its requirement with an API among them. If it is the= SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address?

Besides, the propsoed API is not used alone but with the t= hree type APIs.

Regards,

Seil Jeon

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--_000_F0CF5715D3D1884BAC731EA1103AC28134908F15HASMSX106gercor_-- From nobody Mon Mar 30 15:42:52 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259731A6FED for ; Mon, 30 Mar 2015 15:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDLfPUuRYcPv for ; Mon, 30 Mar 2015 15:42:48 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFE21A6F7B for ; Mon, 30 Mar 2015 15:42:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2UMgmvJ009576; Mon, 30 Mar 2015 15:42:48 -0700 Received: from XCH-BLV-201.nw.nos.boeing.com (xch-blv-201.nw.nos.boeing.com [10.57.37.66]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2UMgeo4009437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 30 Mar 2015 15:42:40 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-201.nw.nos.boeing.com ([169.254.1.181]) with mapi id 14.03.0210.002; Mon, 30 Mar 2015 15:42:39 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] Mobility Exposure and Selection WT call Thread-Index: AQHQaBCuHeg12xmiXkGwZvQpxTNtk501pKnA Date: Mon, 30 Mar 2015 22:42:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com> References: <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com> In-Reply-To: <551481F8.9090507@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Mobility Exposure and Selection WT call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 22:42:51 -0000 Hi Alex, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Thursday, March 26, 2015 3:03 PM > To: Jouni Korhonen; dmm@ietf.org > Subject: Re: [DMM] Mobility Exposure and Selection WT call >=20 > Le 26/03/2015 13:17, Jouni Korhonen a =E9crit : > > Alex, > > > > 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: > > > > [snip] > > > >>> I thought by "fixed" you meant it stays the same wherever the Host go= es > >>> (something like the Home Address). > >> > >> Alper - I think a LL address can also be qualified as 'fixed' - it nev= er > >> changes. > > > > Does LL here mean link-local or link-layer? If it is the former one, > > then the above assertion is not correct. >=20 > Link-local. >=20 > And you seem to say a link-local address is not fixed? I think > link-local addresses _are_ fixed set in stone. They are formed locally > without need of help from router. AERO provides a fixed link-local address that is formed from a prefix received by DHCPv6 Prefix Delegation (PD). Once the AERO Client is given a PD (either IPv6 or IPv4) it can form an AERO link-local address that stays the same wherever the Client moves and with no need to perform Duplicate Address Detection (DAD). It makes IPv6 ND simple and seamless. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > - Jouni > > > >> > >> I think it's hard to disagree with that, no? > >> > >> Alex > >> > >>> > >>> So, I guess, I should have referred to the "nomadic" address to mean = the > >>> one that is constant, wherever the Host goes. > >>> > >>> As such, my suggestion is that a "nomadic" address can never be an > >>> RFC7217 address. > >>> > >>> In practice that would mean that if you configure an address to be > >>> "nomadic" you must also tell the kernel to not run RFC7217 on it. > >>> > >>> But ok, one might think that these two aspects ("nomadic" and RFC7217= ) > >>> are orthogonal at this point in time. > >>> > >>> Alex > >>> > >>>> > >>>> I don't know if it makes sense to request a fixed and random-based I= P > >>>> address. But if someone does it, it works. > >>> > >>> > >>>> > >>>> Alper > >>>> > >>>> > >>>> > >>>> > >>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC > >>>>>>> 6775). > >>>>>>> > >>>>>> > >>>>>> Orthogonal. > >>>>>> > >>>>>> > >>>>>>> E.g. a nomadic address could never be a link-local address. > >>>>>>> > >>>>>>>> #2. Describe how IP address type information is conveyed from > >>>>>>>> network to MN. > >>>>>>> > >>>>>>> If one designs a protocol to convey address type information from > >>>>>>> the network to the end node, then one could also add the other > >>>>>>> types mentioned above. > >>>>>>> > >>>>>>> SLAAC could never 'convey' the address type to the end-node, > >>>>>>> because SLAAC is an operation happening with as heavy weight from > >>>>>>> the Server (router) as from the Client (Host): the Router decides > >>>>>>> the prefix but the Client decides the Interface ID. > >>>>>>> > >>>>>> > >>>>>> Still, the network can convey the type of IP address to the host. > >>>>>> Also, one can imagine augmenting Router Solicitation to let the ho= st > >>>>>> convey its requested type. > >>>>> > >>>>> I agree. > >>>>> > >>>>> Alex > >>>>> > >>>>> > >>>>>>> Address Registration Option of 6lo and BTLE would have the Host > >>>>>>> conveying this information to the Router (and not vice-versa). > >>>>>>> > >>>>>> > >>>>>> OK. > >>>>>> > >>>>>> Alper > >>>>>> > >>>>>> > >>>>>>> Yours, > >>>>>>> > >>>>>>> Alex > >>>>>>> > >>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the > >>>>>>>> baseline for item#1 (the API). A revision of the draft will also > >>>>>>>> include a new section to cover backward compatibility (Danny wil= l > >>>>>>>> provide the draft text). Comments on the draft are welcome. > >>>>>>>> > >>>>>>>> The next call will be about items #2/#3 (IP address > >>>>>>>> configuration enhancements associated with the API). We intend t= o > >>>>>>>> schedule that one in about 2 weeks. > >>>>>>>> > >>>>>>>> Alper > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: > >>>>>>>> > >>>>>>>>> Folks, > >>>>>>>>> > >>>>>>>>> See below for the Webex details. Remember, the call is on Tue, > >>>>>>>>> Feb 10, at 4pm CET. And don't forget to read the documents in > >>>>>>>>> the reading list prior to the call. > >>>>>>>>> > >>>>>>>>>> Attendees _shall read _the following material before the call > >>>>>>>>>> so that we can directly jump to the discussions: > >>>>>>>>>> > >>>>>>>>>> 1. > >>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf > >>>>>>>>>> > >>>>>>>>>> > >>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > >>>>>>>>>> 3. > >>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobi= lity/ > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > >>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Alper > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February > >>>>>>>>> 2015 16:00 | Europe Time (Paris, GMT+01:00) | 1 hr 30 min > >>>>>>>>> > >>>>>>>>>> *Join WebEx meeting* > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>> Meeting number:641 085 326 > >>>>>>>>>> Meeting password:dmm1911 > >>>>>>>>>> > >>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number > >>>>>>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada) > >>>>>>>>>> Access code: 641 085 326 Toll-free calling restrictions > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Add this meeting > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> to your calendar. > >>>>>>>>>> > >>>>>>>>>> Can't join the meeting? Contact support. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows > >>>>>>>>>> audio and other information sent during the session to be > >>>>>>>>>> recorded, which may be discoverable in a legal matter. By > >>>>>>>>>> joining this session, you automatically consent to such > >>>>>>>>>> recordings. If you do not consent to being recorded, discuss > >>>>>>>>>> your concerns with the host or do not join the session. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: > >>>>>>>>> > >>>>>>>>>> Poll is closed, and majority selected the following date for > >>>>>>>>>> the call: > >>>>>>>>>> > >>>>>>>>>> Feb 10, 4pm CET. 1,5hr call. > >>>>>>>>>> > >>>>>>>>>> Please mark your calendars. > >>>>>>>>>> > >>>>>>>>>> In this call, we'll aim making progress on the I-D for item#1 > >>>>>>>>>> (an API for source address selection). > >>>>>>>>>> > >>>>>>>>>> Attendees _shall read _the following material before the call > >>>>>>>>>> so that we can directly jump to the discussions: > >>>>>>>>>> > >>>>>>>>>> 1. > >>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf > >>>>>>>>>> > >>>>>>>>>> > >>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > >>>>>>>>>> 3. > >>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobi= lity/ > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > >>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Alper > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote: > >>>>>>>>>> > >>>>>>>>>>> Folks, > >>>>>>>>>>> > >>>>>>>>>>> Please mark your availability on the following doodle for > >>>>>>>>>>> our next DMM WG Mobility Exposure and Selection WT call: > >>>>>>>>>>> > >>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur > >>>>>>>>>>> > >>>>>>>>>>> Register your availability no later than the end of Monday > >>>>>>>>>>> (Jan 26). > >>>>>>>>>>> > >>>>>>>>>>> Alper > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ dmm mailing list > >>>>>>>> dmm@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ dmm mailing list > >>>>>>> dmm@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >>> > >>> > >> > >> > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm > > >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Mar 31 02:52:04 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9B1A896D for ; Tue, 31 Mar 2015 02:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAMJJX7yUcOf for ; Tue, 31 Mar 2015 02:52:02 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC601A896C for ; Tue, 31 Mar 2015 02:52:01 -0700 (PDT) Received: by patj18 with SMTP id j18so14875281pat.2 for ; Tue, 31 Mar 2015 02:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:subject:mime-version:content-type; bh=V4ppmNeb2Ln1ZZcVQUcRcBu9YSaFq9zG8Zy6lq0cI4M=; b=Hg56bxdJi4xerlHKtJddbpSHeo9UQOpvsA3S9HdWPpIyMsqVDQhQ+thjlbLJdZ9awB kcPxbYlSdSbeNKjrJFJ65dfCBu5AYFzFm3paIfnsynBFDnkO++jED8vTGDSQgMZ8wXtw 7jpH1VNIe2vjrrwQyglHD8OC0Vz+9JiPf0WWUSJ6SlUPJXy/lhTZ5EtTFgX3LzDWenqp R7kRr4y7s5mCrMZ75ebqzwzOyFxaoIlfAU6Oi2LV9YegCv3t/r04leeMQTozUrqHiImi /0hmiO6y/NwhNxl+TtFTlTlRYHax51ZHwxDgYt/BEIn5lbYuF6mEcPj8QXqtcVN3nMWA LiyQ== X-Received: by 10.67.7.195 with SMTP id de3mr66208727pad.79.1427795521475; Tue, 31 Mar 2015 02:52:01 -0700 (PDT) Received: from [10.62.54.24] ([202.55.20.10]) by mx.google.com with ESMTPSA id pa6sm12731146pac.45.2015.03.31.02.51.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 31 Mar 2015 02:52:00 -0700 (PDT) Date: Tue, 31 Mar 2015 17:51:49 +0800 From: Dapeng Liu To: "=?utf-8?Q?dmm=40ietf.org?=" Message-ID: <0FE6D2CA737841BD992AABCDE74C5ACB@gmail.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="551a6e35_7e0c57b1_8d8" Archived-At: Cc: weixinpeng@huawei.com Subject: [DMM] DMM API: http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 09:52:03 -0000 --551a6e35_7e0c57b1_8d8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46olks, I would like to reaffirm that the technical comments that I made is indiv= idual opinion (without co-chair=E2=80=99s hat). =20 To facilitate the discussion, I have the following suggestions: 1. If you are OK with the DMM API approach in general, but you have comme= nts to this specific proposal: 1.1 If you think the proposal can be improved: Then please suggest the changes that you think can improve the prop= osal (providing text changes) 1.2 If you think we need a new proposal: You can provide the reason why this proposal does not work. and probably = new idea that works. 2. Provide other comments if it not belongs to the above case. Thanks, -- =20 Dapeng Liu --551a6e35_7e0c57b1_8d8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=46olks,

I would like t= o reaffirm that the technical comments that I made is individual opinion = (without co-chair=E2=80=99s hat).

To facil= itate the discussion, I have the following suggestions:

1. If you are OK with the DMM API approach in general, but you ha= ve comments to this specific proposal:

1.1 If you thi= nk the proposal can be improved:
Then ple= ase suggest the changes that you think can improve the proposal (providin= g text changes)

1.2 If you think we need a new propo= sal:
You can provide the reason why this proposal does not wor= k. and probably new idea that works.

2. Provide othe= r comments if it not belongs to the above case.

=
Thanks,
--
Dapeng Liu
=
--551a6e35_7e0c57b1_8d8-- From nobody Tue Mar 31 05:23:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762581A9234 for ; Tue, 31 Mar 2015 05:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHlsDr6wk5-a for ; Tue, 31 Mar 2015 05:23:17 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 247C01A9154 for ; Tue, 31 Mar 2015 05:23:13 -0700 (PDT) Received: from [192.168.26.107] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77424836; Tue, 31 Mar 2015 13:23:12 +0100 From: "Seil Jeon" To: "'Moses, Danny'" References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> In-Reply-To: Date: Tue, 31 Mar 2015 13:23:12 +0100 Message-ID: <003901d06bad$75307a90$5f916fb0$@av.it.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01D06BB5.D6FC0E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/wIJAtYDAlqa+uabZ/LtgA== Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] Answer on raised questions for the proposed API X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 12:23:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003A_01D06BB5.D6FC0E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Danny, See the inline please. Seil Jeon From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Monday, March 30, 2015 4:44 PM To: Seil Jeon Cc: dmm@ietf.org Subject: RE: [DMM] Answer on raised questions for the proposed API Hi Seil, As to the potential of abuse: Yes, I see your point and you are correct. If the IP stack will not request a sustained IP address more than once after each movement to a new LAN (with a different prefix), than there will be no abuse. Seil -> Yes, it's true. Thanks for correction. As to the second comment, please let me elaborate: One potential implementation of the IP stack in the host, can be to request a Nomadic IP address and a Sustained IP address whenever connecting to a network, and whenever moving to a new LAN, regardless if there are any applications requesting any addresses. This way, whenever an application is launched and requests either a Nomadic or Sustained IP address, the stack can provide one without having to issue a request to the network. In this case, there is no need for this flag from the application. Seil -> Decision of which type of IP address by default will be depending on the IP pool management policy by operators. You case may correspond to one of them. What if only the Nomadic IP address is basically allocated upon a network attachment? That is, a lot of applications require mere Internet connectivity without session continuity support. So, the Sustained IP address will be requested on demand, and the proposed flag will be used to get a new Sustained IP address by expressing the explicit request by an application. Another potential implementation of the IP stack in the host is not to request IP addresses in advance. In that case, it will issue a request for a Nomadic IP address or a Sustained IP address the first time an application requests one and use it for subsequent requests as long as it is not moving to a different LAN. Once it moves, it will again request a new IP address (Nomadic or Sustained - according to what is required) after receiving the first request from any application. In this case as well, there is no need for this flag. Seil -> Another application requested just Sustained IP address while the IP stack has already a Sustained IP address. Why should the IP stack try to get a new one, though the application indicated simply "Sustained IP address type"? You case took a step towards a solution where you want to draw. I don't expect the action is generic when a Sustained IP address type is requested. Besides, you assumption on IP address allocation seems not valid. A mobile host would get an IP address whatever the allocated IP address type is when it attaches at a network, regardless of an application's IP address request. As a matter of fact, if such a flag is defined, I cannot think of an example where it will not be used. It seems to me that applications will always request a refreshed Sustained IP address (when requesting a Sustained IP address). If this is correct, the flag is redundant. Seil -> Some applications, e.g. email, that are not relatively restricted from optimal routing would consider a Sustained IP address without issuing the new flag. More applications based on such network characteristic can be thought more than expected. And such use of existing Sustained IP address is not extraordinary, since IP address is a resource, even in the consideration of IPv6 deployment. If as many as applications require new Sustained IP address, it will end up in a lot of network resource consumption in the mobility routers where the Sustained IP addresses are anchored as the terminal moves. Can you provide a scenario in which an application will not request to refresh the Sustained IP address? It was mentioned in the former comments. Regards, /Danny From: Seil Jeon [ mailto:seiljeon@av.it.pt] Sent: Monday, March 30, 2015 17:08 To: Moses, Danny Cc: dmm@ietf.org Subject: FW: [DMM] Answer on raised questions for the proposed API Hi Danny, Any comments? Regards, Seil Jeon From: dmm [ mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon Sent: Thursday, March 26, 2015 8:08 PM To: dmm@ietf.org Subject: [DMM] Answer on raised questions for the proposed API Hi, I could attend DMM Thursday meeting via MeetEcho. I could also hear some raised comments by Danny and Someone. Here goes answers to the raised questions. First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW), The use of the proposed API is suggested in the SUSTAINED IP address case in the draft. On receiving this API with the SUSTAINED IP address type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access network. So, actual obtaining of the IP address will be tried one time while attached at a specific access network. Even some applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse. Second question sounded to me like that this API is not needed because the host can get a new SUSTAINED IP address, right? If the question is right, I don't understand what the question is meant, that is how the host can get a new SUSTAINED IP address? Based on the definition of three types of IP address, an application should show its requirement with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address? Besides, the propsoed API is not used alone but with the three type APIs. Regards, Seil Jeon --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ------=_NextPart_000_003A_01D06BB5.D6FC0E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = Danny,

See the inline = please.

Seil Jeon =

From:= = Moses, Danny [mailto:danny.moses@intel.com]
Sent: Monday, = March 30, 2015 4:44 PM
To: Seil Jeon
Cc: = dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for = the proposed API

Hi Seil,

As to the potential of = abuse:
Yes, I see your point and you are correct. If = the IP stack will not request a sustained IP address more than once = after each movement to a new LAN (with a different prefix), than there = will be no abuse.

Seil = -> Yes, it’s true. Thanks for = correction.

As to the = second comment, please let me elaborate:
One potential = implementation of the IP stack in the host, can be to request a Nomadic = IP address and a Sustained IP address whenever connecting to a = network, and whenever moving to a new LAN, regardless if there are any = applications requesting any addresses. This way, whenever an application = is launched and requests either a Nomadic or Sustained IP address, the = stack can provide one without having to issue a request to the network. = In this case, there is no need for this flag from the = application.

Seil = -> Decision of which type of IP address by default will be depending = on the IP pool management policy by operators. You case may correspond = to one of them. What if only the Nomadic IP address is basically = allocated upon a network attachment? That is, a lot of applications = require mere Internet connectivity without session continuity support. = So, the Sustained IP address will be requested on demand, and the = proposed flag will be used to get a new Sustained IP address by = expressing the explicit request by an = application.

Another = potential implementation of the IP stack in the host is not to request = IP addresses in advance. In that case, it will issue a request for a = Nomadic IP address or a Sustained IP address the first time an = application requests one and use it for subsequent requests as long as = it is not moving to a different LAN. Once it moves, it will again = request a new IP address (Nomadic or Sustained – according to what = is required) after receiving the first request from any application. In = this case as well, there is no need for this = flag.

Seil = -> Another application requested just Sustained IP address while the = IP stack has already a Sustained IP address. Why should the IP stack try = to get a new one, though the application indicated simply = “Sustained IP address type”? You case took a step towards a = solution where you want to draw. I don’t expect the action is = generic when a Sustained IP address type is = requested.

Besides, you assumption on IP = address allocation seems not valid. A mobile host would get an IP = address whatever the allocated IP address type is when it attaches at a = network, regardless of an application’s IP address request.

As a = matter of fact, if such a flag is defined, I cannot think of an example = where it will not be used. It seems to me that applications will always = request a refreshed Sustained IP address (when requesting a Sustained IP = address). If this is correct, the flag is = redundant.

Seil = -> Some applications, e.g. email, that are not relatively restricted = from optimal routing would consider a Sustained IP address without = issuing the new flag. More applications based on such network = characteristic can be thought more than = expected.
And such use of existing = Sustained IP address is not extraordinary, since IP address is a = resource, even in the consideration of IPv6 deployment. If as many as = applications require new Sustained IP address, it will end up in a lot = of network resource consumption in the mobility routers where the = Sustained IP addresses are anchored as the terminal = moves.

Can you = provide a scenario in which an application will not request to refresh = the Sustained IP address?

It was mentioned in the = former comments.

Regards,
&= nbsp; = /Danny
From:= = Seil Jeon [mailto:seilj= eon@av.it.pt] =
Sent: Monday, March 30, 2015 17:08
To: Moses, = Danny
Cc: dmm@ietf.org=
Subje= ct: FW: [DMM] Answer on raised questions for the proposed = API

Hi = Danny,

Any = comments?

Regards,
Seil = Jeon

From:= = dmm [mailto:dmm-b= ounces@ietf.org] On = Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 = PM
To: dmm@ietf.org=
Subje= ct: [DMM] Answer on raised questions for the proposed = API

Hi,

I = could attend DMM Thursday meeting via MeetEcho.
I = could also hear some raised comments by Danny and Someone. Here goes = answers to the raised questions.

First, regarding the need of = the proposed API (IPV6_PREFER_SRC_NEW),

The = use of the proposed API is suggested in the SUSTAINED IP address case in = the draft. On receiving this API with the SUSTAINED IP address type at = the IP stack, it will try to get a new SUSTAINED IP address if there is = no available in the currently attached access network. So, actual = obtaining of the IP address will be tried one time while attached at a = specific access network. Even some applications put this API after, the = already obtained SUSTAINED IP will be used. So, no worries about = abuse.

Second question sounded to me = like that this API is not needed because the host can get a new = SUSTAINED IP address, right?
If = the question is right, I don’t understand what the question is = meant, that is how the host can get a new SUSTAINED IP = address?
Based on the definition of = three types of IP address, an application should show its requirement = with an API among them. If it is the SUSTAINED IP address, how do we = expect the IP stack will try to get a new SUSTAINED IP = address?

Besides, the propsoed API is = not used alone but with the three type APIs.

Regards,
=

Seil = Jeon

-------------------------------= --------------------------------------
A member of the Intel = Corporation group of companies
This e-mail and any = attachments may contain confidential material for
the sole use of the = intended recipient(s). Any review or distribution
by others is = strictly prohibited. If you are not the intended
recipient, please = contact the sender and delete all = copies.
------=_NextPart_000_003A_01D06BB5.D6FC0E80-- From nobody Tue Mar 31 10:08:04 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1821A00BF for ; Tue, 31 Mar 2015 10:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XCbUxj1c_CI for ; Tue, 31 Mar 2015 10:08:00 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73AD31A1A70 for ; Tue, 31 Mar 2015 10:08:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2VH7xQB025957; Tue, 31 Mar 2015 12:07:59 -0500 Received: from XCH-BLV-503.nw.nos.boeing.com (xch-blv-503.nw.nos.boeing.com [130.247.25.192]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2VH7nbR025837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 31 Mar 2015 12:07:50 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.21]) with mapi id 14.03.0210.002; Tue, 31 Mar 2015 10:07:49 -0700 From: "Templin, Fred L" To: h chan , "dmm@ietf.org" Thread-Topic: Enhanced mobility anchoring Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KAgAfMsQA= Date: Tue, 31 Mar 2015 17:07:48 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E2E9D3@XCH-BLV-504.nw.nos.boeing.com> References: <6E31144C030982429702B11D6746B98C521EFCA4@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C521EFCA4@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832E2E9D3XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [DMM] Enhanced mobility anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:08:03 -0000 --_000_2134F8430051B64F815C691A62D9831832E2E9D3XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW50aG9ueSwNCg0KV2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgd2VsbCBhZGRyZXNzZWQg YnkgQUVSTy4gQUVSTyBhbHNvIGFkZHJlc3Nlcw0Kc29tZSBnYXBzIGxpc3RlZCBpbiBSRkM3NDI5 IGJldHRlciB0aGFuIG90aGVyIGFwcHJvYWNoZXMsIGFuZCBJTUhPIGhhcw0KYSBtdWNoIGNsZWFu ZXIgbW9iaWxpdHkgYXJjaGl0ZWN0dXJlLiBQbGVhc2UgaW5jbHVkZSBBRVJPIGluIHlvdXIgbGlz dC4NCg0KVGhhbmtzIOKAkyBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCkZyb206 IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaCBjaGFuDQpT ZW50OiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTA6NTUgQU0NClRvOiBkbW1AaWV0Zi5vcmcN ClN1YmplY3Q6IFtETU1dIEVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZw0KDQpJIHdhcyBhc2tl ZCB0byBwcm92aWRlIG1vcmUgZXhwbGFuYXRpb24gYWJvdXQgYW5jaG9yaW5nLg0KDQpEaXN0cmli dXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IG1heSBoYXZlIGFuY2hvcmluZyBmdW5jdGlvbmFsaXR5 IGluIGRpZmZlcmVudCBuZXR3b3JrcyBzbyB0aGF0IHJvdXRlcyBkbyBub3QgbmVlZCB0byB0cmF2 ZXJzZSBhIGNlbnRyYWxpemVkIGFuY2hvci4NCg0KWWV0LCB0aGUgZGVmaW5pdGlvbiBvZiAiYW5j aG9yaW5nIGZ1bmN0aW9uIiAoQUYpIGluIFJGQyA3MzMzIGlzIGluIHRlcm1zIG9mIHJvdXRlIGFk dmVydGlzZW1lbnQgZm9yIHRoZSBJUCBhZGRyZXNzIG9ubHksIGFuZCBzdWNoIGZ1bmN0aW9uIGlz IGF2YWlsYWJsZSBpbiBtdWx0aXBsZSBuZXR3b3JrLg0KDQpTbyB3aGF0IGFyZSB0aGUgcmVzdCBv ZiB0aGUgZnVuY3Rpb25zPw0KDQpTdWNoIGZ1bmN0aW9ucyBtYXkgdGVuZCB0byBjYXVzZSB0aGUg cGFja2V0cyB0byB0cmF2ZXJzZSBjZXJ0YWluIG5vZGVzLg0KDQpDb25zaWRlciBhIHR5cGljYWwg aGFuZG92ZXIgc2NlbmFyaW86IE1OIG1vdmVzIGZyb20gTmV0MSBtb3ZlcyB0byBOZXQyLCBhbmQg Q04gaXMgaW4gTmV0Mw0KDQpUaGUgb2xkIEFSIChBUjEpIG9mIE1OIGluIE5ldDEgcGVyZm9ybXMg UkEgZm9yIElQMTsgdGhlIG5ldyBBUiAoQVIyKSBvZiBNTiBpbiBOZXQyIHBlcmZvcm1zIFJBIGZv ciBJUDI7IHRoZSBBUiAoQVIzKSBvZiBDTiBpbiBOZXQzIHBlcmZvcm1zIFJBIGZvciBJUDMuDQoN ClRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBhdCBBUjEgYW5kIEFSMiBib3RoIHRyeSB0byBjYXVz ZSB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyB0byB0cmF2ZXJzZSB0aGVtLiBJZiB3ZSBjYWxsIHRo ZXNlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHBhcnQgb2YgZGlzdHJpYnV0ZWQgYW5jaG9yaW5nIGZ1 bmN0aW9uLCB0aGUgcXVlc3Rpb24gaXMgd2hhdCB0aGV5IGFyZSBhbmNob3JpbmcuDQoNClNvIGFj Y29yZGluZyB0byB0aGUgZGVmaW5pdGlvbiBvZiBBRiwgQVIxIHBlcmZvcm1zIEFGIGZvciBJUDE7 IEFSMiBwZXJmb3JtcyBBRiBmb3IgSVAyIChub3QgSVAxKTsgYW5kIEFSMyBwZXJmb3JtcyBBRiBm b3IgSVAzLg0KDQpPbmUgYXBwcm9hY2ggaXMgdG8gYm9ycm93IHRoZSB3ZWxsIGtub3duIGNvbmNl cHQgb2Ygc2VwYXJhdGlvbiBvZiBzZXNzaW9uIElEIChTSUQpIGZyb20gcm91dGluZyBhZGRyZXNz LiBUaGVyZSBhcmUgdG9ucyBvZiBwYXBlcnMgYWRkcmVzc2luZyBzdWNoIHNlcGFyYXRpb24sIGFu ZCB0aGUgbGFjayBvZiBzdWNoIHNlcGFyYXRpb24gaXMgY29uc2lkZXJlZCB0aGUgZnVuZGFtZW50 YWwgcHJvYmxlbSBvZiBicmVha2luZyBzZXNzaW9uIGFzIGFuIElQIGFkZHJlc3MgY2hhbmdlcyBk dXJpbmcgaGFuZG92ZXIuDQoNCkluIGxpbmUgd2l0aCB0aGlzIHNlcGFyYXRpb24sIHRoZSBmdW5j dGlvbiBvZiBhbmNob3Jpbmcgb2YgYSBzZXNzaW9uL2Zsb3cgY2FuIGJlIHNlcGFyYXRlZCBmcm9t IHRoYXQgb2YgYW5jaG9yaW5nIGFuIElQIGFkZHJlc3MuDQoNClRoZSBzZXBhcmF0aW9uIG9mIHNl c3Npb24gSUQgYW5kIHJvdXRpbmcgYWRkcmVzcyBjYW4gYmUgY29uc2lkZXJlZCBhIGdlbmVyYWxp emF0aW9uLCBiZWNhdXNlIHRoZSBzZXNzaW9uIElEIGNhbiBiZSBhbnl0aGluZy4gQW4gZXhhbXBs ZSBpcyBISVQgaW4gdGhlIElFVEYgcHJvdG9jb2wgSElQLg0KDQpUaGUgdXNlIG9mIEhvQSBhbmQg Q29BIGNhbiBiZSBjb25zaWRlcmVkIGEgcGFydGljdWxhciBjYXNlIG9mIFNJRCBhbmQgcm91dGlu ZyBhZGRyZXNzIHNlcGFyYXRpb24uIEluIHVzaW5nIGluZGlyZWN0aW9uLCBvbmUgSVAgYWRkcmVz cyAoQ29BKSBpcyB1c2VkIGZvciByb3V0aW5nLCB3aGVyZWFzIGFub3RoZXIgSVAgYWRkcmVzcyAo SG9BKSBpcyB1c2VkIGluIHRoZSBzb2NrZXQgYXMgcGFydCBvZiB0aGUgU0lEIGlkZW50aWZpY2F0 aW9uLg0KDQpBbm90aGVyIElFVEYgcHJvdG9jb2wgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIExJU1Au DQoNCkluIG9uZSBleGFtcGxlIG9mIGhhbmRvdmVyIHNjZW5hcmlvIHRoZSBkZXNpcmVkIHBhdGgg Y2FuIGJlOg0KDQpwYWNrZXQgZnJvbSBDTiBmaXJzdCBnb2VzIHRvIEFSMywgdG8gd2hpY2ggSVAz IGlzIGFuY2hvcmVkLg0KDQppdCB0aGVuIGdvZXMgdG8gQVIxLCB0byB3aGljaCBJUDEgaXMgYW5j aG9yZWQuDQoNCml0IHRoZW4gZ29lcyB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBhbmNob3JlZC4N Cg0KV2hhdCBjYXVzZXMgdGhlIHBhY2tldHMgb2YgdGhlIGZsb3cgdG8gZ28gdGhpcyB3YXkgbWF5 IGJlOg0KDQpBUjIgaGFzIHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbjogdGhlIGJpbmRpbmcgb2Yg U0lEIG9mIHRoZSBmbG93IChJUDEpIHRvIElQIGFkZHJlc3Mgb2YgQVIyLiBJdCBzZW5kcyB0aGlz IGluZm9ybWF0aW9uIHRvIEFSMS4NCg0KU3VjaCBhZGRpdGlvbmFsIGZ1bmN0aW9uIGJhc2ljYWxs eSB0cmllcyB0byBjYXVzZSB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyAoSVAxKSB0byB0cmF2ZXJz ZSBBUjEgYW5kIEFSMi4NCg0KSW4gYW5vdGhlciBleGFtcGxlIG9mIHRoaXMgc2FtZSBzY2VuYXJp bywgdGhlIGRlc2lyZWQgcGF0aCBpczoNCg0KcGFja2V0IGZyb20gQ04gZmlyc3QgZ29lcyB0byBB UjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC4NCg0KaXQgdGhlbiBnb2VzIGRpcmVjdGx5IHRv IEFSMiwgdG8gd2hpY2ggSVAyIGlzIGFuY2hvcmVkLg0KDQpXaGF0IGNhdXNlcyB0aGUgcGFja2V0 cyBvZiB0aGUgZmxvdyB0byBnbyB0aGlzIHdheSBtYXkgYmU6DQoNCkFSMyBoYXMgdGhlIGxvY2F0 aW9uIGluZm9ybWF0aW9uOiB0aGUgYmluZGluZyBvZiBTSUQgb2YgdGhlIGZsb3cgKElQMSkgdG8g SVAgYWRkcmVzcyBvZiBBUjIuDQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiBhbnkgb2YgdGhlc2Ug aXMgbm90IGNsZWFyIGVub3VnaC4gVGhhbmsgeW91Lg0KDQpIIEFudGhvbnkgQ2hhbg0KDQoNCg0K DQoNCg0K --_000_2134F8430051B64F815C691A62D9831832E2E9D3XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSBBbnRob255LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ V2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgd2VsbCBhZGRyZXNzZWQgYnkgQUVSTy4gQUVSTyBh bHNvIGFkZHJlc3NlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zb21lIGdhcHMgbGlzdGVkIGluIFJGQzc0 MjkgYmV0dGVyIHRoYW4gb3RoZXIgYXBwcm9hY2hlcywgYW5kIElNSE8gaGFzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPmEgbXVjaCBjbGVhbmVyIG1vYmlsaXR5IGFyY2hpdGVjdHVyZS4gUGxlYXNlIGluY2x1 ZGUgQUVSTyBpbiB5b3VyIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGFua3Mg4oCTIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZnJlZC5sLnRlbXBsaW5A Ym9laW5nLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5oIGNoYW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1h cmNoIDI2LCAyMDE1IDEwOjU1IEFNPGJyPg0KPGI+VG86PC9iPiBkbW1AaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW0RNTV0gRW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2FzIGFza2Vk IHRvIHByb3ZpZGUgbW9yZSBleHBsYW5hdGlvbiBhYm91dCBhbmNob3Jpbmc8c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Ljwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1l bnQgbWF5IGhhdmUgYW5jaG9yaW5nIGZ1bmN0aW9uYWxpdHkgaW4gZGlmZmVyZW50IG5ldHdvcmtz IHNvIHRoYXQgcm91dGVzIGRvIG5vdCBuZWVkIHRvIHRyYXZlcnNlIGEgY2VudHJhbGl6ZWQgYW5j aG9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+WWV0LCB0aGUgZGVmaW5pdGlvbiBvZiAmcXVvdDthbmNob3JpbmcgZnVuY3Rpb24m cXVvdDsgKEFGKSZuYnNwO2luIFJGQyA3MzMzIGlzIGluIHRlcm1zIG9mIHJvdXRlIGFkdmVydGlz ZW1lbnQgZm9yIHRoZSBJUCBhZGRyZXNzIG9ubHksIGFuZCBzdWNoJm5ic3A7ZnVuY3Rpb24gaXMg YXZhaWxhYmxlIGluIG11bHRpcGxlIG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbyB3aGF0IGFyZSB0aGUgcmVzdCBv ZiB0aGUgZnVuY3Rpb25zPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWNoIGZ1bmN0aW9ucyBtYXkgdGVuZCB0byBjYXVzZSB0 aGUgcGFja2V0cyB0byB0cmF2ZXJzZSBjZXJ0YWluIG5vZGVzLg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db25zaWRlciBhIHR5 cGljYWwgaGFuZG92ZXImbmJzcDtzY2VuYXJpbzogTU4gbW92ZXMgZnJvbSBOZXQxIG1vdmVzIHRv IE5ldDIsIGFuZCBDTiBpcyBpbiBOZXQzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgb2xkIEFSIChBUjEpIG9mIE1OJm5ic3A7 aW4gTmV0MSBwZXJmb3JtcyBSQSBmb3IgSVAxOyB0aGUgbmV3IEFSIChBUjIpIG9mIE1OIGluIE5l dDIgcGVyZm9ybXMgUkEgZm9yIElQMjsgdGhlIEFSIChBUjMpIG9mIENOIGluIE5ldDMgcGVyZm9y bXMgUkEgZm9yIElQMy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBhdCBBUjEgYW5kIEFS MiBib3RoIHRyeSB0byBjYXVzZSB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyB0byB0cmF2ZXJzZSB0 aGVtLiBJZiB3ZSBjYWxsIHRoZXNlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHBhcnQgb2YgZGlzdHJp YnV0ZWQgYW5jaG9yaW5nIGZ1bmN0aW9uLCB0aGUgcXVlc3Rpb24NCiBpcyB3aGF0IHRoZXkgYXJl IGFuY2hvcmluZy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U28gYWNjb3JkaW5nIHRvIHRoZSZuYnNwO2RlZmluaXRp b24gb2YgQUYsIEFSMSBwZXJmb3JtcyBBRiBmb3IgSVAxOyBBUjIgcGVyZm9ybXMgQUYgZm9yIElQ MiAobm90IElQMSk7IGFuZCBBUjMgcGVyZm9ybXMgQUYgZm9yIElQMy4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T25lIGFwcHJv YWNoIGlzIHRvIGJvcnJvdyB0aGUgd2VsbCBrbm93biBjb25jZXB0IG9mIHNlcGFyYXRpb24gb2Yg c2Vzc2lvbiBJRCAoU0lEKSBmcm9tIHJvdXRpbmcgYWRkcmVzcy4gVGhlcmUgYXJlIHRvbnMgb2Yg cGFwZXJzIGFkZHJlc3Npbmcgc3VjaCBzZXBhcmF0aW9uLCBhbmQgdGhlIGxhY2sgb2Ygc3VjaCBz ZXBhcmF0aW9uDQogaXMgY29uc2lkZXJlZCB0aGUgZnVuZGFtZW50YWwgcHJvYmxlbSBvZiBicmVh a2luZyBzZXNzaW9uJm5ic3A7YXMgYW4gSVAgYWRkcmVzcyBjaGFuZ2VzIGR1cmluZyBoYW5kb3Zl ci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SW4gbGluZSB3aXRoIHRoaXMgc2VwYXJhdGlvbiwgdGhlIGZ1bmN0aW9uIG9mIGFu Y2hvcmluZyBvZiBhIHNlc3Npb24vZmxvdyBjYW4gYmUgc2VwYXJhdGVkIGZyb20gdGhhdCBvZiBh bmNob3JpbmcgYW4gSVAgYWRkcmVzcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHNlcGFyYXRpb24gb2Ygc2Vzc2lvbiBJ RCBhbmQgcm91dGluZyBhZGRyZXNzIGNhbiBiZSBjb25zaWRlcmVkIGEgZ2VuZXJhbGl6YXRpb24s IGJlY2F1c2UgdGhlIHNlc3Npb24gSUQgY2FuIGJlIGFueXRoaW5nLiBBbiBleGFtcGxlIGlzIEhJ VCBpbiB0aGUgSUVURiBwcm90b2NvbCBISVAuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSB1c2Ugb2YgSG9BIGFuZCBDb0Eg Y2FuIGJlIGNvbnNpZGVyZWQgYSBwYXJ0aWN1bGFyIGNhc2Ugb2YgU0lEIGFuZCByb3V0aW5nIGFk ZHJlc3Mgc2VwYXJhdGlvbi4gSW4gdXNpbmcgaW5kaXJlY3Rpb24sIG9uZSBJUCBhZGRyZXNzIChD b0EpIGlzIHVzZWQgZm9yIHJvdXRpbmcsIHdoZXJlYXMgYW5vdGhlciBJUCBhZGRyZXNzDQogKEhv QSkgaXMgdXNlZCBpbiB0aGUgc29ja2V0IGFzIHBhcnQgb2YgdGhlIFNJRCBpZGVudGlmaWNhdGlv bi4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Bbm90aGVyIElFVEYgcHJvdG9jb2wgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIExJU1Au DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkluIG9uZSBleGFtcGxlIG9mIGhhbmRvdmVyIHNjZW5hcmlvIHRoZSBkZXNpcmVkIHBh dGggY2FuIGJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+cGFja2V0IGZyb20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNo IElQMyBpcyBhbmNob3JlZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aXQgdGhlbiBnb2VzIHRvIEFSMSwgdG8gd2hpY2ggSVAx IGlzIGFuY2hvcmVkLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5pdCB0aGVuIGdvZXMgdG8gQVIyLCB0byB3aGljaCBJUDIgaXMg YW5jaG9yZWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IHRvIGdv IHRoaXMgd2F5IG1heSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFSMiBoYXMgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uOiB0 aGUgYmluZGluZyBvZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAoSVAxKSB0byBJUCBhZGRyZXNzIG9m IEFSMi4gSXQgc2VuZHMgdGhpcyBpbmZvcm1hdGlvbiB0byBBUjEuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWNoIGFkZGl0aW9u YWwgZnVuY3Rpb24gYmFzaWNhbGx5IHRyaWVzIHRvIGNhdXNlIHRoZSBwYWNrZXRzIG9mIHRoZSBm bG93IChJUDEpIHRvIHRyYXZlcnNlIEFSMSBhbmQgQVIyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiBhbm90aGVyIGV4YW1w bGUgb2YgdGhpcyBzYW1lIHNjZW5hcmlvLCB0aGUgZGVzaXJlZCBwYXRoIGlzOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+cGFja2V0 IGZyb20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pml0IHRoZW4gZ29lcyBkaXJlY3RseSB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBhbmNob3JlZC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IHRvIGdvIHRoaXMgd2F5IG1h eSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkFSMyBoYXMgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uOiB0aGUgYmluZGluZyBv ZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAoSVAxKSB0byBJUCBhZGRyZXNzIG9mIEFSMi4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ UGxlYXNlIGxldCBtZSBrbm93IGlmIGFueSBvZiB0aGVzZSBpcyBub3QgY2xlYXIgZW5vdWdoLiBU aGFuayB5b3UuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkggQW50aG9ueSBDaGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_2134F8430051B64F815C691A62D9831832E2E9D3XCHBLV504nwnosb_-- From nobody Tue Mar 31 22:04:59 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77FA1A886A for ; Tue, 31 Mar 2015 22:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeI-D4rVkjsg for ; Tue, 31 Mar 2015 22:04:56 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC971A8866 for ; Tue, 31 Mar 2015 22:04:56 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so62405481obc.2 for ; Tue, 31 Mar 2015 22:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=aDlS9Dybi4am0rm+z9Z19f817003lvTDUTgzMxGuIK8=; b=yhlhT9U4WKP96dZ5WEf5E17MWn83RcXpuXHTNK2refuhLZBxpaCqDgTwqdvsXGwZq3 bXh31qeR4vgQgBQQvC4nXtULOssHsRM7nHA7pfGT9R+CCo8i74nntcdXauMwsMoRr5gF Y5w1tsGqRrUWHy+GeFYBRC8QFj58jdZ/UaLh9704i9SATpI4gtIHS9Pi+WkpkQQGwz9e FEp/cm7rwtrFnBLobGERNV4Qm375oigUxKJSUTmvpu2eHEnGIQqjMbtcG8biAX0BY8vf Iif4iNxJVLkUEnOJv9VRo7C27RsVNtyzlE5NRa4xprZa4XahOFvIcz/tsCKSt7EStN7p JvBQ== X-Received: by 10.60.158.202 with SMTP id ww10mr38431610oeb.18.1427864695671; Tue, 31 Mar 2015 22:04:55 -0700 (PDT) Received: from [198.18.119.64] ([12.190.128.2]) by mx.google.com with ESMTPSA id vj2sm902527obb.10.2015.03.31.22.04.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 22:04:54 -0700 (PDT) Message-ID: <551B7C73.4080500@gmail.com> Date: Tue, 31 Mar 2015 22:04:51 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] IETF#92 meeting minutes available X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:04:57 -0000 The minutes are here: http://tools.ietf.org/wg/dmm/minutes?item=minutes-92-dmm.html Thanks to John for taking extensive minutes. - Jouni & dapeng