From brian@innovationslab.net Fri Jan 24 09:29:49 2014 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 3C1EB1A0069 for ; Fri, 24 Jan 2014 09:29:49 -0800 (PST) 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 kDA-yU2Xb-x6 for ; Fri, 24 Jan 2014 09:29:47 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4D1A0037 for ; Fri, 24 Jan 2014 09:29:47 -0800 (PST) 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 25991880F3; Fri, 24 Jan 2014 09:29:46 -0800 (PST) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8BD5C130003; Fri, 24 Jan 2014 09:29:45 -0800 (PST) Message-ID: <52E2A30A.1020705@innovationslab.net> Date: Fri, 24 Jan 2014 12:29:46 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: draft-ietf-dmm-requirements@tools.ietf.org, "dmm@ietf.org" , Peter McCann X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6ErilMJaLBUxLW5h46AIgnPxTaSNW1WEU" Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 24 Jan 2014 17:29:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6ErilMJaLBUxLW5h46AIgnPxTaSNW1WEU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I have performed my AD review, as a part of the publication process, of draft-ietf-dmm-requirements. The following issues should be addressed prior to moving this draft to IETF Last Call. Please let me know if you have any questions on these points. 1. I would suggest making sure that the Abstract and Introduction explicitly state that these requirements for for network (L3)-layer mobility management. 2. Introduction: - The EPC acronym needs to be expanded. - Do not reference the DMM charter within the document. - expand HA and LMA since you are using them before the Terminology secti= on. 3. Section 3: - It would be nice to ensure that all acronyms used in the figures are expanded somewhere prior to the figures. - I am curious as to why there is not any mention in this section about route optimization within the mobility protocols. This mention should describe why current route optimization is host-based in order to lead into PS1. 4. Section 4: - To be abundantly clear, I would re-word the start of PS3 to be "Lack of scalability". - I am not sure that it benefits the document to label PS6 and PS7 as related. Those issues are problematic on their own. If you remove the "(related problem)" label from them, make sure that REQ2 is updated to remove mention of "related problem". - Should PS7 mention mobility solutions that operated at other layers of the protocol stack? 5. Section 5: - Why does this section have sub-section numbers AND REQ numbers? - I am not sure I understand what REQ1 is saying when it talks about combining mobility anchors with CDNs. It *sounds* like mobility management needs to be maintained by CDN providers. - I am a little confused by REQ2. It says that a DMM solution should be transparent to the applications. However, the motivation talks about identifying applications that do (or do not) need mobility support from the network layer. That doesn't sound transparent to me. Am I reading this incorrectly? - I am wondering if the SHOULD in REQ4 ought to be a MUST. Why would anyone work on a new protocol without first determining the feasibility of the existing ones? - What is meant by co-exist in REQ5? Does this mean that a DMM solution does not break an existing one? Or does it mean that it must inter-operate with existing ones? Is this like IPv4 and IPv6 being incompatible, but can run concurrently on the same network? Or does this mean there needs to be some mechanism for interaction (i.e., like NAT64)? - I think REQ6 is incomplete. A DMM solution can introduce new vulnerabilities, but it needs to provide ways to cope with those vulnerabilities. 6. I would like to avoid issues further along the publication chain, so I would like the editors to look at how the contributing authors are identified in the draft. A good approach is described in the RFC Style Guide (https://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic. Regards, Brian --6ErilMJaLBUxLW5h46AIgnPxTaSNW1WEU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS4qMKAAoJEBOZRqCi7goqvCYH/iYy6W3hE3SRd52W4W7fXuCu lD11MuL4CuIU1vzfw9bswHlz3+veMkCKKEhzCmUXlQowcgdz/OQlyWNBM2gjL/ME hoNj2qm/n0HrsA6DgTj0wB7p/m1h3lSD0Z0EvLtSDIKKMaP1iqTsNzL+FWq38bul pcXDVB3yg/mVRVsjAhR+7FyrJgu+hF8TOmJGySbR0maIRjiJ9ZNIeEf6nT5CHzW6 YaNCcfz+MqC9Gif9czrKK3uiGl0LE2c/0fOGBaqIA/KPzO1mlMeJHlW2b05DCI/S sJ443T6X1Q6a9saWKKJavWLsWTNvjv8lGMtsuEaATS6bLY2tcs163gkk0G5Q9T8= =eiMv -----END PGP SIGNATURE----- --6ErilMJaLBUxLW5h46AIgnPxTaSNW1WEU-- From h.anthony.chan@huawei.com Fri Jan 24 16:38:49 2014 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 E255F1A0278 for ; Fri, 24 Jan 2014 16:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 OAh4zhllfalF for ; Fri, 24 Jan 2014 16:38:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59C1A0262 for ; Fri, 24 Jan 2014 16:38:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCX05598; Sat, 25 Jan 2014 00:38:44 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 25 Jan 2014 00:38:23 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 25 Jan 2014 00:38:43 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.03.0158.001; Sat, 25 Jan 2014 08:38:34 +0800 From: h chan To: Brian Haberman , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPGSnmR1nPMPdjp0Khf0EqkSOySJqUkskg Date: Sat, 25 Jan 2014 00:38:34 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> In-Reply-To: <52E2A30A.1020705@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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: Sat, 25 Jan 2014 00:38:50 -0000 4. Section 4: - I am not sure that it benefits the document to label PS6 and PS7 as relat= ed. Those issues are problematic on their own. If you remove the "(relate= d problem)" label from them, make sure that REQ2 is updated to remove menti= on of "related problem". The intention of the name "related problems" was not to suggest they are le= ss problematic, but rather to distinguish them from the other problems dire= ctly on mobility management. Although these problems are not directly on mo= bility management, the DMM solutions can solve these additional problems. T= hey are therefore included. So, as long as this section is not to be interp= reted as limited to problems directly on mobility management, we can drop t= he word "related." H Anthony Chan -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Friday, January 24, 2014 11:30 AM To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements All, I have performed my AD review, as a part of the publication process, o= f draft-ietf-dmm-requirements. The following issues should be addressed pr= ior to moving this draft to IETF Last Call. Please let me know if you have= any questions on these points. 1. I would suggest making sure that the Abstract and Introduction explicitl= y state that these requirements for for network (L3)-layer mobility managem= ent. 2. Introduction: - The EPC acronym needs to be expanded. - Do not reference the DMM charter within the document. - expand HA and LMA since you are using them before the Terminology section= . 3. Section 3: - It would be nice to ensure that all acronyms used in the figures are expa= nded somewhere prior to the figures. - I am curious as to why there is not any mention in this section about rou= te optimization within the mobility protocols. This mention should describ= e why current route optimization is host-based in order to lead into PS1. 4. Section 4: - To be abundantly clear, I would re-word the start of PS3 to be "Lack of s= calability". - I am not sure that it benefits the document to label PS6 and PS7 as relat= ed. Those issues are problematic on their own. If you remove the "(relate= d problem)" label from them, make sure that REQ2 is updated to remove menti= on of "related problem". - Should PS7 mention mobility solutions that operated at other layers of th= e protocol stack? 5. Section 5: - Why does this section have sub-section numbers AND REQ numbers? - I am not sure I understand what REQ1 is saying when it talks about combin= ing mobility anchors with CDNs. It *sounds* like mobility management needs= to be maintained by CDN providers. - I am a little confused by REQ2. It says that a DMM solution should be tr= ansparent to the applications. However, the motivation talks about identif= ying applications that do (or do not) need mobility support from the networ= k layer. That doesn't sound transparent to me. Am I reading this incorrec= tly? - I am wondering if the SHOULD in REQ4 ought to be a MUST. Why would anyon= e work on a new protocol without first determining the feasibility of the e= xisting ones? - What is meant by co-exist in REQ5? Does this mean that a DMM solution do= es not break an existing one? Or does it mean that it must inter-operate w= ith existing ones? Is this like IPv4 and IPv6 being incompatible, but can = run concurrently on the same network? Or does this mean there needs to be = some mechanism for interaction (i.e., like NAT64)? - I think REQ6 is incomplete. A DMM solution can introduce new vulnerabili= ties, but it needs to provide ways to cope with those vulnerabilities. 6. I would like to avoid issues further along the publication chain, so I w= ould like the editors to look at how the contributing authors are identifie= d in the draft. A good approach is described in the RFC Style Guide (https= ://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can = be problematic. Regards, Brian From brian@innovationslab.net Mon Jan 27 05:20:17 2014 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 5E3A31A0216 for ; Mon, 27 Jan 2014 05:20:17 -0800 (PST) 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 6N6NUT1oo3Ba for ; Mon, 27 Jan 2014 05:20:15 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id E518A1A0213 for ; Mon, 27 Jan 2014 05:20:15 -0800 (PST) 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 01536880ED; Mon, 27 Jan 2014 05:20:14 -0800 (PST) Received: from 102525136.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7ED4B136810B; Mon, 27 Jan 2014 05:20:13 -0800 (PST) Message-ID: <52E65D0E.9090109@innovationslab.net> Date: Mon, 27 Jan 2014 08:20:14 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vF9EAirGHhxLSEsDJUEmgVrJpno7rwppg" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 27 Jan 2014 13:20:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vF9EAirGHhxLSEsDJUEmgVrJpno7rwppg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/24/14 7:38 PM, h chan wrote: > 4. Section 4: - I am not sure that it benefits the document to label > PS6 and PS7 as related. Those issues are problematic on their own. > If you remove the "(related problem)" label from them, make sure that > REQ2 is updated to remove mention of "related problem". >=20 > The intention of the name "related problems" was not to suggest they > are less problematic, but rather to distinguish them from the other > problems directly on mobility management. Although these problems are > not directly on mobility management, the DMM solutions can solve > these additional problems. They are therefore included. So, as long > as this section is not to be interpreted as limited to problems > directly on mobility management, we can drop the word "related." >=20 I will leave it to the authors/WG, but I don't see a benefit to the "related" tag. Regards, Brian --vF9EAirGHhxLSEsDJUEmgVrJpno7rwppg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS5l0PAAoJEBOZRqCi7goqx7oIAK2VR4Zp7/o4tta1ZE64ksco 3vxmhL11lNMOW14UZVMB6/pinSkgfWtkX+Ua5O1+f6Hbl9ygT9UXEFq0IKwQXwBd 9f9bn19YYT0m61q7uYHNVmKwz2t9oLK/urxV/PVqNQssnV2qc9nhz0vZ/51TB46i BxF83IlywMl4sCzW8WapmL/+h6FAFHrpaxklB+S6ZQyhtKWnwGUzO7QkehUsHtpx 5i92g5aGfdQpzU9WcH+xasQafCK7vekDuJP2WxijwjD8nenfOg5PQMYSRGRfLHdK naNIAXtQY8N7ROPhm0dERC/lpMJ9QbilZ2Etn0o078CxfADqnFgvTqHxEWzTJtE= =XR45 -----END PGP SIGNATURE----- --vF9EAirGHhxLSEsDJUEmgVrJpno7rwppg-- From h.anthony.chan@huawei.com Mon Jan 27 17:46:05 2014 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 E685A1A0345 for ; Mon, 27 Jan 2014 17:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 D5Zo8TZsMOVp for ; Mon, 27 Jan 2014 17:46:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4681A016C for ; Mon, 27 Jan 2014 17:46:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAM65866; Tue, 28 Jan 2014 01:46:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 01:45:27 +0000 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 01:45:42 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 09:45:33 +0800 From: h chan To: Brian Haberman , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPGSnmR1nPMPdjp0Khf0EqkSOySJqUkskggAN5zQCAAU3msA== Date: Tue, 28 Jan 2014 01:45:33 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> In-Reply-To: <52E65D0E.9090109@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 28 Jan 2014 01:46:06 -0000 I will drop "related" Regarding the following 5. Section 5: - I am a little confused by REQ2. It says that a DMM solution should be tr= ansparent to the applications. However, the motivation talks about identif= ying applications that do (or do not) need mobility support from the networ= k layer. That doesn't sound transparent to me. Am I reading this incorrec= tly? It appears that unless the network can find out whether the application has= need of such support, the application indeed may need to invoke mobility s= upport or has to convey its need to the network.=20 The emphasis of requirement is on "when needed." So, I think it is better t= o drop the word "transparent" as follows: REQ2: Mobility support when needed DMM solutions MUST provide mobility support to above the IP layer when needed. Such support is needed, for example, when, upon change of point of attachment to the network, an application flow cannot cope with a change in the IP address. However, it is not always necessary to maintain a stable home IP address or prefix for every application or at all times for a mobile node. Motivation: The motivation of this requirement is to enable more efficient routing and more efficient use of network resources by selecting an IP address or prefix according to whether mobility support is needed and by not maintaining context at the mobility anchor when there is no such need. H Anthony Chan -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter= McCann Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements On 1/24/14 7:38 PM, h chan wrote: > 4. Section 4: - I am not sure that it benefits the document to label > PS6 and PS7 as related. Those issues are problematic on their own. > If you remove the "(related problem)" label from them, make sure that > REQ2 is updated to remove mention of "related problem". >=20 > The intention of the name "related problems" was not to suggest they=20 > are less problematic, but rather to distinguish them from the other=20 > problems directly on mobility management. Although these problems are=20 > not directly on mobility management, the DMM solutions can solve these=20 > additional problems. They are therefore included. So, as long as this=20 > section is not to be interpreted as limited to problems directly on=20 > mobility management, we can drop the word "related." >=20 I will leave it to the authors/WG, but I don't see a benefit to the "relate= d" tag. Regards, Brian From alexandru.petrescu@gmail.com Tue Jan 28 06:42:53 2014 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 73B421A041C for ; Tue, 28 Jan 2014 06:42:53 -0800 (PST) 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 HJ0atCaXsshW for ; Tue, 28 Jan 2014 06:42:51 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A6EC21A0418 for ; Tue, 28 Jan 2014 06:42:50 -0800 (PST) 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 s0SEglcr031463 for ; Tue, 28 Jan 2014 15:42:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C34FD2055A5 for ; Tue, 28 Jan 2014 15:42:55 +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 BB6FB20544D for ; Tue, 28 Jan 2014 15:42:55 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0SEghuI007535 for ; Tue, 28 Jan 2014 15:42:47 +0100 Message-ID: <52E7C1E1.2020705@gmail.com> Date: Tue, 28 Jan 2014 15:42:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dmm@ietf.org References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 28 Jan 2014 14:42:53 -0000 Le 28/01/2014 02:45, h chan a écrit : > I will drop "related" > > Regarding the following > > 5. Section 5: > - I am a little confused by REQ2. It says that a DMM solution should be transparent to the applications. This remark is typically true when we talk Mobile IP on a Mobile Host and an application like firefox runs above a BSD Socket interface. > However, the motivation talks about identifying applications that do (or do not) need mobility support from the network layer. That doesn't sound transparent to me. Am I reading this incorrectly? > > It appears that unless the network can find out whether the application has need of such support, the application indeed may need to invoke mobility support or has to convey its need to the network. > > The emphasis of requirement is on "when needed." So, I think it is better to drop the word "transparent" as follows: > > REQ2: Mobility support when needed > > DMM solutions MUST provide mobility support to above > the IP layer when needed. Such support is needed, for > example, when, upon change of point of attachment to the > network, an application flow cannot cope with a change in the > IP address. However, it is not always necessary to maintain a > stable home IP address or prefix for every application or at > all times for a mobile node. > > Motivation: The motivation of this requirement is to enable > more efficient routing and more efficient use of network > resources by selecting an IP address or prefix according to > whether mobility support is needed and by not maintaining > context at the mobility anchor when there is no such need. Whenever we discuss this 'transparency' paragraph I have again the same comments. First, I am not sure DMM is only about Mobile Hosts, or about Mobile Routers as well. Because, if we talk Mobile Routers, then rarely an application runs directly on it. Most applications would run on LFN. Transparency? If the applications run on the LFN, the change of the attachment of the MR is 'transparent' to them, regardless whether or not MR does something to maintain stability of that address (Mobile IP, other). Second, this transparency may depend on the direction, or more complex 'shape' of the application flows. Some IP flows of some applications have very complex 'shapes', with various sets of IP src and dst, and triangular or HA-less shapes. Take for example a video-call. The session establishment through an intermediary and behind NAT is followed by the ongoing 4 flows (2 audio 2 video)... they all take different paths... each may need or not need to go through the HA, and each has distinct behaviours when the IP address changes, hence each would have a distinct 'transparency' requirement. Is this _one_ application? Alex > > H Anthony Chan > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Monday, January 27, 2014 7:20 AM > To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements > > > > On 1/24/14 7:38 PM, h chan wrote: >> 4. Section 4: - I am not sure that it benefits the document to label >> PS6 and PS7 as related. Those issues are problematic on their own. >> If you remove the "(related problem)" label from them, make sure that >> REQ2 is updated to remove mention of "related problem". >> >> The intention of the name "related problems" was not to suggest they >> are less problematic, but rather to distinguish them from the other >> problems directly on mobility management. Although these problems are >> not directly on mobility management, the DMM solutions can solve these >> additional problems. They are therefore included. So, as long as this >> section is not to be interpreted as limited to problems directly on >> mobility management, we can drop the word "related." >> > > I will leave it to the authors/WG, but I don't see a benefit to the "related" tag. > > Regards, > Brian > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > From h.anthony.chan@huawei.com Tue Jan 28 10:58:40 2014 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 9CA9D1A0434 for ; Tue, 28 Jan 2014 10:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 oPHvyNoIqY0a for ; Tue, 28 Jan 2014 10:58:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 769271A044D for ; Tue, 28 Jan 2014 10:58:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAN63054; Tue, 28 Jan 2014 18:58:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 18:58:02 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 18:58:33 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 02:58:25 +0800 From: h chan To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPGSnmR1nPMPdjp0Khf0EqkSOySJqUkskggAN5zQCAAU3msIAAW3iAgAC16mA= Date: Tue, 28 Jan 2014 18:58:24 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> In-Reply-To: <52E7C1E1.2020705@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 28 Jan 2014 18:58:40 -0000 Let me try to understand the concern here.=20 What is new in this requirement is "when needed" in contrast to providing I= P mobility by default. Without this requirement, mobility support may be provided by default, whic= h is transparent to higher layers.=20 With this requirement, assume there are separate steps in the DMM solution.= =20 1. A decision is made whether network-layer mobility support is needed. 2. When the need is established, network-layer mobility support is invoked. 3. Then transparent support is provided and is transparent to layers above = IP. Transparency is clear in step 3 above. The question however is whether the preceding steps involve the application= , so that one may question whether the entire DMM solution (with all the st= eps) as a whole is transparent. So the intention of the requirement is that WHEN/AFTER the decision is made= to invoke mobility support, then the mobility support is transparent to th= e application. Then we may want to check and make sure the emphasis of this= requirement does mean transparency in this respect only.=20 Original wording: REQ2: Transparency to Upper Layers when needed =20 DMM solutions MUST provide transparent mobility support above the IP layer when needed. Such transparency is needed, for example, when, upon change of point of attachment to the network, an application flow cannot cope with a change in the IP address. However, it is not always necessary to maintain a stable home IP address or prefix for every application or at all times for a mobile node. I now tend to think the first sentence in this original wording may steer t= he emphasis on providing transparent support, which is not what the motivat= ion and the problems are talking about. The motivation and the problems are= talking about when they are not needed. The emphasis of this requirement t= herefore is on the capability to turn OFF unnecessary mobility support.=20 How about the following REQ2: Network-layer mobility support ONLY when needed =20 DMM solutions MUST NOT provide network-layer mobility support when NOT needed. (or if you don't like double negatives: (DMM solutions MUST provide network-layer=20 mobility support ONLY when needed) Such transparent mobility support above the IP layer is needed, f= or example, when, upon change of point of attachment to the network, an application flow cannot cope with a change in the IP address. However, it is not always necessary to maintain a stable home IP address or prefix for every application or at all times for a mobile node. Any comments/changes/corrections? H Anthony Chan -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Le 28/01/2014 02:45, h chan a =E9crit : > I will drop "related" > > Regarding the following > > 5. Section 5: > - I am a little confused by REQ2. It says that a DMM solution should be = transparent to the applications. This remark is typically true when we talk Mobile IP on a Mobile Host and a= n application like firefox runs above a BSD Socket interface. > However, the motivation talks about identifying applications that do (or = do not) need mobility support from the network layer. That doesn't sound t= ransparent to me. Am I reading this incorrectly? > > It appears that unless the network can find out whether the application h= as need of such support, the application indeed may need to invoke mobility= support or has to convey its need to the network. > > The emphasis of requirement is on "when needed." So, I think it is better= to drop the word "transparent" as follows: > > REQ2: Mobility support when needed > > DMM solutions MUST provide mobility support to above > the IP layer when needed. Such support is needed, for > example, when, upon change of point of attachment to the > network, an application flow cannot cope with a change in the > IP address. However, it is not always necessary to maintain a > stable home IP address or prefix for every application or at > all times for a mobile node. > > Motivation: The motivation of this requirement is to enable > more efficient routing and more efficient use of network > resources by selecting an IP address or prefix according to > whether mobility support is needed and by not maintaining > context at the mobility anchor when there is no such need. Whenever we discuss this 'transparency' paragraph I have again the same=20 comments. First, I am not sure DMM is only about Mobile Hosts, or about Mobile=20 Routers as well. Because, if we talk Mobile Routers, then rarely an application runs=20 directly on it. Most applications would run on LFN. Transparency? If the applications run on the LFN, the change of the attachment of the=20 MR is 'transparent' to them, regardless whether or not MR does something=20 to maintain stability of that address (Mobile IP, other). Second, this transparency may depend on the direction, or more complex=20 'shape' of the application flows. Some IP flows of some applications=20 have very complex 'shapes', with various sets of IP src and dst, and=20 triangular or HA-less shapes. Take for example a video-call. The session establishment through an=20 intermediary and behind NAT is followed by the ongoing 4 flows (2 audio=20 2 video)... they all take different paths... each may need or not need=20 to go through the HA, and each has distinct behaviours when the IP=20 address changes, hence each would have a distinct 'transparency'=20 requirement. Is this _one_ application? Alex > > H Anthony Chan > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Monday, January 27, 2014 7:20 AM > To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Pet= er McCann > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements > > > > On 1/24/14 7:38 PM, h chan wrote: >> 4. Section 4: - I am not sure that it benefits the document to label >> PS6 and PS7 as related. Those issues are problematic on their own. >> If you remove the "(related problem)" label from them, make sure that >> REQ2 is updated to remove mention of "related problem". >> >> The intention of the name "related problems" was not to suggest they >> are less problematic, but rather to distinguish them from the other >> problems directly on mobility management. Although these problems are >> not directly on mobility management, the DMM solutions can solve these >> additional problems. They are therefore included. So, as long as this >> section is not to be interpreted as limited to problems directly on >> mobility management, we can drop the word "related." >> > > I will leave it to the authors/WG, but I don't see a benefit to the "rela= ted" tag. > > 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 alexandru.petrescu@gmail.com Tue Jan 28 11:27:26 2014 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 635DE1A02D5 for ; Tue, 28 Jan 2014 11:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 wgFsh6Ue9-or for ; Tue, 28 Jan 2014 11:27:22 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFAC1A026C for ; Tue, 28 Jan 2014 11:27:21 -0800 (PST) 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 s0SJRDHe017630; Tue, 28 Jan 2014 20:27:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3D4162057C8; Tue, 28 Jan 2014 20:27:22 +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 305B32056CA; Tue, 28 Jan 2014 20:27:22 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0SJR36t026022; Tue, 28 Jan 2014 20:27:13 +0100 Message-ID: <52E80484.9020200@gmail.com> Date: Tue, 28 Jan 2014 20:27:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "dmm@ietf.org" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 28 Jan 2014 19:27:26 -0000 Le 28/01/2014 19:58, h chan a écrit : > Let me try to understand the concern here. > > What is new in this requirement is "when needed" in contrast to > providing IP mobility by default. First, providing mobility by default is not a black/white alternative to not providing mobility. It is very possible on the same machine to have Mobile IP enabled for some flows and disabled for others (depending what we call a 'flow'). It is also possible to have Mobile IP and NAT at the same time on the same Mobile Router. > Without this requirement, mobility support may be provided by > default, which is transparent to higher layers. Again, transparency to higher layers means we talk mobility management on a Mobile Host. Transparency to higher layers has little meaning if we talk mobility management provided on a Mobile Router (which is not a Mobile Host). > With this requirement, assume there are separate steps in the DMM > solution. 1. A decision is made whether network-layer mobility > support is needed. 2. When the need is established, network-layer > mobility support is invoked. 3. Then transparent support is provided > and is transparent to layers above IP. > > Transparency is clear in step 3 above. This looks like a trigger which enables mobility, or other times disables it. But one can have a Mobile IP daemon and a NAT run at the same time on the same machine. There is no decision in time. Some decision happens at packet based on IP destination address. > The question however is whether the preceding steps involve the > application, so that one may question whether the entire DMM solution > (with all the steps) as a whole is transparent. I agree. I am not aware of any application which talks to Mobile IP. Whenever it is there it is 'transparent'. > So the intention of the requirement is that WHEN/AFTER the decision > is made to invoke mobility support, then the mobility support is > transparent to the application. Then we may want to check and make > sure the emphasis of this requirement does mean transparency in this > respect only. I disagree. As I said above, the word 'transparency' is dubious. Some times it may mean 'non-existent', some times it may mean light goes through it but modified. If one wants to continue using it, then one should better qualify it with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'. Because a Mobile Router doing mobility management in a transparent manner on the Mobile Router for the LFN has nothing to do with applications, neither with upper layers. Also, a Mobile Router doing NAT and Mobile IP at the same time is 50%-transparent. > > Original wording: > > REQ2: Transparency to Upper Layers when needed > > DMM solutions MUST provide transparent mobility support above the IP > layer when needed. Such transparency is needed, for example, when, ^on a Mobile Host. > upon change of point of attachment to the network, an application > flow cannot cope with a change in the IP address. (it's not the application flow, it is a socket which some times may break [paste here the error from the screen]; the term 'application flow' in this context has little meaning) (an 'application flow' has no understandable meaning in practice). > However, it is not always necessary to maintain a stable home IP > address or prefix for every application or at all times for a mobile > node. ^a Mobile Host. I agree. > I now tend to think the first sentence in this original wording may > steer the emphasis on providing transparent support, which is not > what the motivation and the problems are talking about. I agree. > The motivation and the problems are talking about when they are not > needed. The emphasis of this requirement therefore is on the > capability to turn OFF unnecessary mobility support. In a sense I agree with the meaning. But when trying to turn off or on mobility support the things are not like if there were a knob on/off, not even like starting/stopping some daemon. It is a matter of always having the Mobile IP support on, and tweak the routing table with some particular entries, and the firewalling rules to NAT some addresses or not. > How about the following > > REQ2: Network-layer mobility support ONLY when needed If we understood better when it was needed... > DMM solutions MUST NOT provide network-layer mobility support when > NOT needed. I would say that Mobile IP MUST always be turned on on a Mobile Host. > (or if you don't like double negatives: (DMM solutions MUST provide > network-layer mobility support ONLY when needed) No, I would say to have it always on. If some applications don't want it then dont use it; realize that by inserting routing table entries. One may wonder when some applications dont want it. One answer is when some applications prefer to not go through the HA in order to take advantage of the 4G pure speed. When? For example if the HA link is too slow compared to 4G. (remark this is not the same as saying that the triangular route is longer than straight, because that is always true). This is not a request for Route Optimization. It is an invitation to analyze in deeper detail the application needs. One may have an application start via the HA (offer reachability) and continue straight, w/o HA. It's the same application. Consider a video-call like appli: you want to be reachable always at the same IP address (through HA) but once the session is ongoing you may not want to use it through HA if no handover in sight. Something like that. These things could be further refined if we really went into detail and understood what are the needs of applications, the distinctions MH-MR, etc. > Such transparent mobility support above the IP layer is needed, for > example, when, upon change of point of attachment to the network, an > application flow cannot cope with a change in the IP address. > However, it is not always necessary to maintain a stable home IP > address or prefix for every application or at all times for a mobile > node. A Mobile Host never maintains a stable prefix, only a stable address. A Mobile Router may maintain a stable address (its HoA) and may maintain a stable prefix (its MNP). It could also just maintain stable just its MNP, but not its HoA; and vice-versa. Is that mobility? For each of these there is an application :-) Alex > > Any comments/changes/corrections? > > H Anthony Chan > > -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On > Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM > To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: > draft-ietf-dmm-requirements > > Le 28/01/2014 02:45, h chan a écrit : >> I will drop "related" >> >> Regarding the following >> >> 5. Section 5: - I am a little confused by REQ2. It says that a DMM >> solution should be transparent to the applications. > > This remark is typically true when we talk Mobile IP on a Mobile Host > and an application like firefox runs above a BSD Socket interface. > > >> However, the motivation talks about identifying applications that >> do (or do not) need mobility support from the network layer. That >> doesn't sound transparent to me. Am I reading this incorrectly? >> >> It appears that unless the network can find out whether the >> application has need of such support, the application indeed may >> need to invoke mobility support or has to convey its need to the >> network. >> >> The emphasis of requirement is on "when needed." So, I think it is >> better to drop the word "transparent" as follows: >> >> REQ2: Mobility support when needed >> >> DMM solutions MUST provide mobility support to above the IP layer >> when needed. Such support is needed, for example, when, upon >> change of point of attachment to the network, an application flow >> cannot cope with a change in the IP address. However, it is not >> always necessary to maintain a stable home IP address or prefix for >> every application or at all times for a mobile node. >> >> Motivation: The motivation of this requirement is to enable more >> efficient routing and more efficient use of network resources by >> selecting an IP address or prefix according to whether mobility >> support is needed and by not maintaining context at the mobility >> anchor when there is no such need. > > Whenever we discuss this 'transparency' paragraph I have again the > same comments. > > First, I am not sure DMM is only about Mobile Hosts, or about Mobile > Routers as well. > > Because, if we talk Mobile Routers, then rarely an application runs > directly on it. Most applications would run on LFN. > > Transparency? > > If the applications run on the LFN, the change of the attachment of > the MR is 'transparent' to them, regardless whether or not MR does > something to maintain stability of that address (Mobile IP, other). > > Second, this transparency may depend on the direction, or more > complex 'shape' of the application flows. Some IP flows of some > applications have very complex 'shapes', with various sets of IP src > and dst, and triangular or HA-less shapes. > > Take for example a video-call. The session establishment through an > intermediary and behind NAT is followed by the ongoing 4 flows (2 > audio 2 video)... they all take different paths... each may need or > not need to go through the HA, and each has distinct behaviours when > the IP address changes, hence each would have a distinct > 'transparency' requirement. Is this _one_ application? > > Alex > >> >> H Anthony Chan >> >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 >> AM To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; >> dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: >> draft-ietf-dmm-requirements >> >> >> >> On 1/24/14 7:38 PM, h chan wrote: >>> 4. Section 4: - I am not sure that it benefits the document to >>> label PS6 and PS7 as related. Those issues are problematic on >>> their own. If you remove the "(related problem)" label from them, >>> make sure that REQ2 is updated to remove mention of "related >>> problem". >>> >>> The intention of the name "related problems" was not to suggest >>> they are less problematic, but rather to distinguish them from >>> the other problems directly on mobility management. Although >>> these problems are not directly on mobility management, the DMM >>> solutions can solve these additional problems. They are therefore >>> included. So, as long as this section is not to be interpreted as >>> limited to problems directly on mobility management, we can drop >>> the word "related." >>> >> >> I will leave it to the authors/WG, but I don't see a benefit to the >> "related" tag. >> >> 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 h.anthony.chan@huawei.com Tue Jan 28 12:31:48 2014 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 F17E71A044D for ; Tue, 28 Jan 2014 12:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 vLauuAx7hmey for ; Tue, 28 Jan 2014 12:31:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D7EA51A044C for ; Tue, 28 Jan 2014 12:31:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAN67111; Tue, 28 Jan 2014 20:31:39 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 20:31:19 +0000 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 20:31:37 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 04:31:28 +0800 From: h chan To: Brian Haberman , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPGSnmR1nPMPdjp0Khf0EqkSOySJqais0g Date: Tue, 28 Jan 2014 20:31:27 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB62E@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> In-Reply-To: <52E2A30A.1020705@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.88] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370EB62Eszxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 28 Jan 2014 20:31:48 -0000 --_000_6E31144C030982429702B11D6746B98C370EB62Eszxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REQ6: Security considerations A DMM solution MUST NOT introduce new security risks or amplify existing security risks against which the existing security mechanisms/protocols cannot offer sufficient protection. The intention of REQ6 is NOT that it cannot introduce new vulnerabilities a= t all. Rather the protection against such new vulnerablities can be limited to the= use of existing security protocols. It is okay to provide additional means= to protect against new risks as long as they do not require development of= new security protocols which are needed for DMM alone but are not needed o= therwise. Else a network deploying DMM versus a network not deploying DMM w= ill need additional security protocols which are not needed otherwise. So I think the word: "existing" security mechanisms/protocols is intended t= o exclude protocols that are not needed otherwise. We can clarify with the following: REQ6: Security considerations A DMM solution MUST NOT introduce new security risks or amplify existing security risks against which security means usin= g existing security mechanisms/protocols CANNOT offer sufficient protection. H Anthony Chan -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Friday, January 24, 2014 11:30 AM To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements All, I have performed my AD review, as a part of the publication process, o= f draft-ietf-dmm-requirements. The following issues should be addressed pr= ior to moving this draft to IETF Last Call. Please let me know if you have= any questions on these points. 1. I would suggest making sure that the Abstract and Introduction explicitl= y state that these requirements for for network (L3)-layer mobility managem= ent. 2. Introduction: - The EPC acronym needs to be expanded. - Do not reference the DMM charter within the document. - expand HA and LMA since you are using them before the Terminology section= . 3. Section 3: - It would be nice to ensure that all acronyms used in the figures are expa= nded somewhere prior to the figures. - I am curious as to why there is not any mention in this section about rou= te optimization within the mobility protocols. This mention should describ= e why current route optimization is host-based in order to lead into PS1. 4. Section 4: - To be abundantly clear, I would re-word the start of PS3 to be "Lack of s= calability". - I am not sure that it benefits the document to label PS6 and PS7 as relat= ed. Those issues are problematic on their own. If you remove the "(relate= d problem)" label from them, make sure that REQ2 is updated to remove menti= on of "related problem". - Should PS7 mention mobility solutions that operated at other layers of th= e protocol stack? 5. Section 5: - Why does this section have sub-section numbers AND REQ numbers? - I am not sure I understand what REQ1 is saying when it talks about combin= ing mobility anchors with CDNs. It *sounds* like mobility management needs= to be maintained by CDN providers. - I am a little confused by REQ2. It says that a DMM solution should be tr= ansparent to the applications. However, the motivation talks about identif= ying applications that do (or do not) need mobility support from the networ= k layer. That doesn't sound transparent to me. Am I reading this incorrec= tly? - I am wondering if the SHOULD in REQ4 ought to be a MUST. Why would anyon= e work on a new protocol without first determining the feasibility of the e= xisting ones? - What is meant by co-exist in REQ5? Does this mean that a DMM solution do= es not break an existing one? Or does it mean that it must inter-operate w= ith existing ones? Is this like IPv4 and IPv6 being incompatible, but can = run concurrently on the same network? Or does this mean there needs to be = some mechanism for interaction (i.e., like NAT64)? - I think REQ6 is incomplete. A DMM solution can introduce new vulnerabili= ties, but it needs to provide ways to cope with those vulnerabilities. 6. I would like to avoid issues further along the publication chain, so I w= ould like the editors to look at how the contributing authors are identifie= d in the draft. A good approach is described in the RFC Style Guide (https= ://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can = be problematic. Regards, Brian --_000_6E31144C030982429702B11D6746B98C370EB62Eszxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

   REQ6:  Security considerations<= o:p>

 

        &= nbsp; A DMM solution MUST NOT introduce new security risks or

        &= nbsp; amplify existing security risks against which the existing=

        &= nbsp; security mechanisms/protocols cannot offer sufficient

        &= nbsp; protection.

 

The intention of REQ6 is NOT that it cannot intro= duce new vulnerabilities at all.

Rather the protection against such new vulnerabli= ties can be limited to the use of existing security protocols. It is okay t= o provide additional means to protect against new risks as long as they do = not require development of new security protocols which are needed for DMM alone but are not needed otherwise. Els= e a network deploying DMM versus a network not deploying DMM will need addi= tional security protocols which are not needed otherwise.

 

So I think the word: "existing" securit= y mechanisms/protocols is intended to exclude protocols that are not needed= otherwise.

 

We can clarify with the following:

 

   REQ6:  Security considerations<= o:p>

 

        &= nbsp; A DMM solution MUST NOT introduce new security risks or

        &= nbsp; amplify existing security risks against which security means using existing

        &= nbsp; security mechanisms/protocols CANNOT offer sufficient

        &= nbsp; protection.

 

H Anthony Chan

 

-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann<= br> Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

 

All,

     I have performed my AD r= eview, as a part of the publication process, of draft-ietf-dmm-requirements= .  The following issues should be addressed prior to moving this draft= to IETF Last Call.  Please let me know if you have any questions on these points.

 

1. I would suggest making sure that the Abstract = and Introduction explicitly state that these requirements for for network (= L3)-layer mobility management.

 

2. Introduction:

 

- The EPC acronym needs to be expanded.

- Do not reference the DMM charter within the doc= ument.

- expand HA and LMA since you are using them befo= re the Terminology section.

 

3. Section 3:

 

- It would be nice to ensure that all acronyms us= ed in the figures are expanded somewhere prior to the figures.

 

- I am curious as to why there is not any mention= in this section about route optimization within the mobility protocols.&nb= sp; This mention should describe why current route optimization is host-bas= ed in order to lead into PS1.

 

4. Section 4:

 

- To be abundantly clear, I would re-word the sta= rt of PS3 to be "Lack of scalability".

 

- I am not sure that it benefits the document to = label PS6 and PS7 as related.  Those issues are problematic on their o= wn.  If you remove the "(related problem)" label from them, = make sure that REQ2 is updated to remove mention of "related problem".

 

- Should PS7 mention mobility solutions that oper= ated at other layers of the protocol stack?

 

5. Section 5:

 

- Why does this section have sub-section numbers = AND REQ numbers?

 

- I am not sure I understand what REQ1 is saying = when it talks about combining mobility anchors with CDNs.  It *sounds*= like mobility management needs to be maintained by CDN providers.

 

- I am a little confused by REQ2.  It says t= hat a DMM solution should be transparent to the applications.  However= , the motivation talks about identifying applications that do (or do not) n= eed mobility support from the network layer.  That doesn't sound transparent to me.  Am I reading this incorrectly?=

 

- I am wondering if the SHOULD in REQ4 ought to b= e a MUST.  Why would anyone work on a new protocol without first deter= mining the feasibility of the existing ones?

 

- What is meant by co-exist in REQ5?  Does t= his mean that a DMM solution does not break an existing one?  Or does = it mean that it must inter-operate with existing ones?  Is this like I= Pv4 and IPv6 being incompatible, but can run concurrently on the same network?  Or does this mean there needs to be some mechan= ism for interaction (i.e., like NAT64)?

 

- I think REQ6 is incomplete.  A DMM solutio= n can introduce new vulnerabilities, but it needs to provide ways to cope w= ith those vulnerabilities.

 

6. I would like to avoid issues further along the= publication chain, so I would like the editors to look at how the contribu= ting authors are identified in the draft.  A good approach is describe= d in the RFC Style Guide (https:/= /www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic.

 

Regards,

Brian

 

--_000_6E31144C030982429702B11D6746B98C370EB62Eszxeml557mbxchi_-- From h.anthony.chan@huawei.com Tue Jan 28 13:34:14 2014 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 5C1361A01A2 for ; Tue, 28 Jan 2014 13:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 82G75-9U3xSp for ; Tue, 28 Jan 2014 13:34:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 593D91A0056 for ; Tue, 28 Jan 2014 13:34:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDA55093; Tue, 28 Jan 2014 21:34:05 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 21:33:44 +0000 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 21:34:02 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 05:33:54 +0800 From: h chan To: Brian Haberman , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPGSnmR1nPMPdjp0Khf0EqkSOySJqaqOlA Date: Tue, 28 Jan 2014 21:33:54 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB641@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> In-Reply-To: <52E2A30A.1020705@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.88] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370EB641szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 28 Jan 2014 21:34:14 -0000 --_000_6E31144C030982429702B11D6746B98C370EB641szxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the following: - What is meant by co-exist in REQ5? Does this mean that a DMM solution do= es not break an existing one? Or does it mean that it must inter-operate w= ith existing ones? Is this like IPv4 and IPv6 being incompatible, but can = run concurrently on the same network? Or does this mean there needs to be = some mechanism for interaction (i.e., like NAT64)? I think the bottom line is that the existing ones do not break. Original REQ5: Co-existence with deployed networks and hosts The DMM solution MUST be able to co-exist with existing network deployments and end hosts. For example, depending on the environment in which DMM is deployed, DMM solutions may need to be compatible with other deployed mobility protocols or may need to co-exist with a network or mobile hosts/routers that do not support DMM protocols. The mobile node may also move between different access networks, where some of them may support neither DMM nor another mobility protocol. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. We can change to: REQ5: Co-existence with deployed networks and hosts The DMM solution MUST be able to co-exist with existing network deployments and end hosts without breaking them. For exa= mple, depending on the environment in which DMM is deployed, DMM solutions may need to be compatible with other deployed mobility protocols or may need to co-exist with a network or mobile hosts/routers that do not support DMM protocols. The mobile node may also move between different access networks, where some of them may support neither DMM nor another mobility protocol. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. H Anthony Chan -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Friday, January 24, 2014 11:30 AM To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements All, I have performed my AD review, as a part of the publication process, o= f draft-ietf-dmm-requirements. The following issues should be addressed pr= ior to moving this draft to IETF Last Call. Please let me know if you have= any questions on these points. 1. I would suggest making sure that the Abstract and Introduction explicitl= y state that these requirements for for network (L3)-layer mobility managem= ent. 2. Introduction: - The EPC acronym needs to be expanded. - Do not reference the DMM charter within the document. - expand HA and LMA since you are using them before the Terminology section= . 3. Section 3: - It would be nice to ensure that all acronyms used in the figures are expa= nded somewhere prior to the figures. - I am curious as to why there is not any mention in this section about rou= te optimization within the mobility protocols. This mention should describ= e why current route optimization is host-based in order to lead into PS1. 4. Section 4: - To be abundantly clear, I would re-word the start of PS3 to be "Lack of s= calability". - I am not sure that it benefits the document to label PS6 and PS7 as relat= ed. Those issues are problematic on their own. If you remove the "(relate= d problem)" label from them, make sure that REQ2 is updated to remove menti= on of "related problem". - Should PS7 mention mobility solutions that operated at other layers of th= e protocol stack? 5. Section 5: - Why does this section have sub-section numbers AND REQ numbers? - I am not sure I understand what REQ1 is saying when it talks about combin= ing mobility anchors with CDNs. It *sounds* like mobility management needs= to be maintained by CDN providers. - I am a little confused by REQ2. It says that a DMM solution should be tr= ansparent to the applications. However, the motivation talks about identif= ying applications that do (or do not) need mobility support from the networ= k layer. That doesn't sound transparent to me. Am I reading this incorrec= tly? - I am wondering if the SHOULD in REQ4 ought to be a MUST. Why would anyon= e work on a new protocol without first determining the feasibility of the e= xisting ones? - What is meant by co-exist in REQ5? Does this mean that a DMM solution do= es not break an existing one? Or does it mean that it must inter-operate w= ith existing ones? Is this like IPv4 and IPv6 being incompatible, but can = run concurrently on the same network? Or does this mean there needs to be = some mechanism for interaction (i.e., like NAT64)? - I think REQ6 is incomplete. A DMM solution can introduce new vulnerabili= ties, but it needs to provide ways to cope with those vulnerabilities. 6. I would like to avoid issues further along the publication chain, so I w= ould like the editors to look at how the contributing authors are identifie= d in the draft. A good approach is described in the RFC Style Guide (https= ://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can = be problematic. Regards, Brian --_000_6E31144C030982429702B11D6746B98C370EB641szxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding the following:

- What is meant by co-exist in REQ5?  Does t= his mean that a DMM solution does not break an existing one?  Or does = it mean that it must inter-operate with existing ones?  Is this like I= Pv4 and IPv6 being incompatible, but can run concurrently on the same network?  Or does this mean there needs to be some mechan= ism for interaction (i.e., like NAT64)?

 

I think the bottom line is that the existing ones= do not break.

 

Original

   REQ5:  Co-existence with deploy= ed networks and hosts

 

        &= nbsp; The DMM solution MUST be able to co-exist with existing

        &= nbsp; network deployments and end hosts.  For example, depending on

        &= nbsp; the environment in which DMM is deployed, DMM solutions may

        &= nbsp; need to be compatible with other deployed mobility protocols

        &= nbsp; or may need to co-exist with a network or mobile hosts/routers

        &= nbsp; that do not support DMM protocols.  The mobile node may also

        &= nbsp; move between different access networks, where some of them may

        &= nbsp; support neither DMM nor another mobility protocol.

        &= nbsp; Furthermore, a DMM solution SHOULD work across different

        &= nbsp; networks, possibly operated as separate administrative

        &= nbsp; domains, when allowed by the trust relationship between them.

 

We can change to:

   REQ5:  Co-existence with deploy= ed networks and hosts

 

        &= nbsp; The DMM solution MUST be able to co-exist with existing

        &= nbsp; network deployments and end hosts without breaking them.  For example, depending on

        &= nbsp; the environment in which DMM is deployed, DMM solutions may

        &= nbsp; need to be compatible with other deployed mobility protocols

        &= nbsp; or may need to co-exist with a network or mobile hosts/routers

        &= nbsp; that do not support DMM protocols.  The mobile node may also

        &= nbsp; move between different access networks, where some of them may

        &= nbsp; support neither DMM nor another mobility protocol.

        &= nbsp; Furthermore, a DMM solution SHOULD work across different

        &= nbsp; networks, possibly operated as separate administrative

        &= nbsp; domains, when allowed by the trust relationship between them.

 

H Anthony Chan

 

-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann<= br> Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

 

All,

     I have performed my AD r= eview, as a part of the publication process, of draft-ietf-dmm-requirements= .  The following issues should be addressed prior to moving this draft= to IETF Last Call.  Please let me know if you have any questions on these points.

 

1. I would suggest making sure that the Abstract = and Introduction explicitly state that these requirements for for network (= L3)-layer mobility management.

 

2. Introduction:

 

- The EPC acronym needs to be expanded.

- Do not reference the DMM charter within the doc= ument.

- expand HA and LMA since you are using them befo= re the Terminology section.

 

3. Section 3:

 

- It would be nice to ensure that all acronyms us= ed in the figures are expanded somewhere prior to the figures.

 

- I am curious as to why there is not any mention= in this section about route optimization within the mobility protocols.&nb= sp; This mention should describe why current route optimization is host-bas= ed in order to lead into PS1.

 

4. Section 4:

 

- To be abundantly clear, I would re-word the sta= rt of PS3 to be "Lack of scalability".

 

- I am not sure that it benefits the document to = label PS6 and PS7 as related.  Those issues are problematic on their o= wn.  If you remove the "(related problem)" label from them, = make sure that REQ2 is updated to remove mention of "related problem".

 

- Should PS7 mention mobility solutions that oper= ated at other layers of the protocol stack?

 

5. Section 5:

 

- Why does this section have sub-section numbers = AND REQ numbers?

 

- I am not sure I understand what REQ1 is saying = when it talks about combining mobility anchors with CDNs.  It *sounds*= like mobility management needs to be maintained by CDN providers.

 

- I am a little confused by REQ2.  It says t= hat a DMM solution should be transparent to the applications.  However= , the motivation talks about identifying applications that do (or do not) n= eed mobility support from the network layer.  That doesn't sound transparent to me.  Am I reading this incorrectly?=

 

- I am wondering if the SHOULD in REQ4 ought to b= e a MUST.  Why would anyone work on a new protocol without first deter= mining the feasibility of the existing ones?

 

- What is meant by co-exist in REQ5?  Does t= his mean that a DMM solution does not break an existing one?  Or does = it mean that it must inter-operate with existing ones?  Is this like I= Pv4 and IPv6 being incompatible, but can run concurrently on the same network?  Or does this mean there needs to be some mechan= ism for interaction (i.e., like NAT64)?

 

- I think REQ6 is incomplete.  A DMM solutio= n can introduce new vulnerabilities, but it needs to provide ways to cope w= ith those vulnerabilities.

 

6. I would like to avoid issues further along the= publication chain, so I would like the editors to look at how the contribu= ting authors are identified in the draft.  A good approach is describe= d in the RFC Style Guide (https:/= /www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic.

 

Regards,

Brian

 

--_000_6E31144C030982429702B11D6746B98C370EB641szxeml557mbxchi_-- From h.anthony.chan@huawei.com Tue Jan 28 13:59:03 2014 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 CED051A03AA for ; Tue, 28 Jan 2014 13:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 oH7Y1ZLpCa1J for ; Tue, 28 Jan 2014 13:58:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AD7C81A046D for ; Tue, 28 Jan 2014 13:58:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAN70856; Tue, 28 Jan 2014 21:58:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 21:58:17 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 21:58:48 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 05:58:39 +0800 From: h chan To: Brian Haberman , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPGSnmR1nPMPdjp0Khf0EqkSOySJqar9ig Date: Tue, 28 Jan 2014 21:58:38 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB647@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> In-Reply-To: <52E2A30A.1020705@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.88] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370EB647szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 28 Jan 2014 21:59:04 -0000 --_000_6E31144C030982429702B11D6746B98C370EB647szxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the following: - Should PS7 mention mobility solutions that operated at other layers of th= e protocol stack? Original PS7: Deployment with multiple mobility solutions There are already many variants and extensions of MIP. Deployment of new mobility management solutions can be challenging, and debugging difficult, when they co-exist with solutions already deployed in the field. We can change to PS7: Deployment with multiple mobility solutions There are already many variants and extensions of MIP as well mobility solutions at other layers. Deployment of new mobility management solutions can be challenging, and debugging difficult, when they co-exist with solutions already deployed in the field. H Anthony Chan -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Friday, January 24, 2014 11:30 AM To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements All, I have performed my AD review, as a part of the publication process, o= f draft-ietf-dmm-requirements. The following issues should be addressed pr= ior to moving this draft to IETF Last Call. Please let me know if you have= any questions on these points. 1. I would suggest making sure that the Abstract and Introduction explicitl= y state that these requirements for for network (L3)-layer mobility managem= ent. 2. Introduction: - The EPC acronym needs to be expanded. - Do not reference the DMM charter within the document. - expand HA and LMA since you are using them before the Terminology section= . 3. Section 3: - It would be nice to ensure that all acronyms used in the figures are expa= nded somewhere prior to the figures. - I am curious as to why there is not any mention in this section about rou= te optimization within the mobility protocols. This mention should describ= e why current route optimization is host-based in order to lead into PS1. 4. Section 4: - To be abundantly clear, I would re-word the start of PS3 to be "Lack of s= calability". - I am not sure that it benefits the document to label PS6 and PS7 as relat= ed. Those issues are problematic on their own. If you remove the "(relate= d problem)" label from them, make sure that REQ2 is updated to remove menti= on of "related problem". - Should PS7 mention mobility solutions that operated at other layers of th= e protocol stack? 5. Section 5: - Why does this section have sub-section numbers AND REQ numbers? - I am not sure I understand what REQ1 is saying when it talks about combin= ing mobility anchors with CDNs. It *sounds* like mobility management needs= to be maintained by CDN providers. - I am a little confused by REQ2. It says that a DMM solution should be tr= ansparent to the applications. However, the motivation talks about identif= ying applications that do (or do not) need mobility support from the networ= k layer. That doesn't sound transparent to me. Am I reading this incorrec= tly? - I am wondering if the SHOULD in REQ4 ought to be a MUST. Why would anyon= e work on a new protocol without first determining the feasibility of the e= xisting ones? - What is meant by co-exist in REQ5? Does this mean that a DMM solution do= es not break an existing one? Or does it mean that it must inter-operate w= ith existing ones? Is this like IPv4 and IPv6 being incompatible, but can = run concurrently on the same network? Or does this mean there needs to be = some mechanism for interaction (i.e., like NAT64)? - I think REQ6 is incomplete. A DMM solution can introduce new vulnerabili= ties, but it needs to provide ways to cope with those vulnerabilities. 6. I would like to avoid issues further along the publication chain, so I w= ould like the editors to look at how the contributing authors are identifie= d in the draft. A good approach is described in the RFC Style Guide (https= ://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can = be problematic. Regards, Brian --_000_6E31144C030982429702B11D6746B98C370EB647szxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding the following:

- Should PS7 mention mobility solutions that oper= ated at other layers of the protocol stack?

 

Original

   PS7:  Deployment with multiple = mobility solutions

 

         = There are already many variants and extensions of MIP.

         = Deployment of new mobility management solutions can be

         = challenging, and debugging difficult, when they co-exist with

         = solutions already deployed in the field.

 

We can change to

 

   PS7:  Deployment with multiple = mobility solutions

 

         = There are already many variants and extensions of MIP

         = as well mobility solutions at other layers= .

         = Deployment of new mobility management solutions can be

         = challenging, and debugging difficult, when they co-exist with

         = solutions already deployed in the field.

 

H Anthony Chan

 

 

-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman
Sent: Friday, January 24, 2014 11:30 AM
To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann<= br> Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements

 

All,

     I have performed my AD r= eview, as a part of the publication process, of draft-ietf-dmm-requirements= .  The following issues should be addressed prior to moving this draft= to IETF Last Call.  Please let me know if you have any questions on these points.

 

1. I would suggest making sure that the Abstract = and Introduction explicitly state that these requirements for for network (= L3)-layer mobility management.

 

2. Introduction:

 

- The EPC acronym needs to be expanded.

- Do not reference the DMM charter within the doc= ument.

- expand HA and LMA since you are using them befo= re the Terminology section.

 

3. Section 3:

 

- It would be nice to ensure that all acronyms us= ed in the figures are expanded somewhere prior to the figures.

 

- I am curious as to why there is not any mention= in this section about route optimization within the mobility protocols.&nb= sp; This mention should describe why current route optimization is host-bas= ed in order to lead into PS1.

 

4. Section 4:

 

- To be abundantly clear, I would re-word the sta= rt of PS3 to be "Lack of scalability".

 

- I am not sure that it benefits the document to = label PS6 and PS7 as related.  Those issues are problematic on their o= wn.  If you remove the "(related problem)" label from them, = make sure that REQ2 is updated to remove mention of "related problem".

 

- Should PS7 mention mobility solutions that oper= ated at other layers of the protocol stack?

 

5. Section 5:

 

- Why does this section have sub-section numbers = AND REQ numbers?

 

- I am not sure I understand what REQ1 is saying = when it talks about combining mobility anchors with CDNs.  It *sounds*= like mobility management needs to be maintained by CDN providers.

 

- I am a little confused by REQ2.  It says t= hat a DMM solution should be transparent to the applications.  However= , the motivation talks about identifying applications that do (or do not) n= eed mobility support from the network layer.  That doesn't sound transparent to me.  Am I reading this incorrectly?=

 

- I am wondering if the SHOULD in REQ4 ought to b= e a MUST.  Why would anyone work on a new protocol without first deter= mining the feasibility of the existing ones?

 

- What is meant by co-exist in REQ5?  Does t= his mean that a DMM solution does not break an existing one?  Or does = it mean that it must inter-operate with existing ones?  Is this like I= Pv4 and IPv6 being incompatible, but can run concurrently on the same network?  Or does this mean there needs to be some mechan= ism for interaction (i.e., like NAT64)?

 

- I think REQ6 is incomplete.  A DMM solutio= n can introduce new vulnerabilities, but it needs to provide ways to cope w= ith those vulnerabilities.

 

6. I would like to avoid issues further along the= publication chain, so I would like the editors to look at how the contribu= ting authors are identified in the draft.  A good approach is describe= d in the RFC Style Guide (https:/= /www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic.

 

Regards,

Brian

 

--_000_6E31144C030982429702B11D6746B98C370EB647szxeml557mbxchi_-- From h.anthony.chan@huawei.com Tue Jan 28 14:33:44 2014 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 442471A045F for ; Tue, 28 Jan 2014 14:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.736 X-Spam-Level: X-Spam-Status: No, score=-6.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 UO7d_wIvoOpF for ; Tue, 28 Jan 2014 14:33:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BFE161A03C4 for ; Tue, 28 Jan 2014 14:33:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDA57597; Tue, 28 Jan 2014 22:33:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 22:33:17 +0000 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 22:33:35 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 06:33:29 +0800 From: h chan To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHF73QQMirHAQZkGjq5HZgXdS15qasU2Q Date: Tue, 28 Jan 2014 22:33:28 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> In-Reply-To: <52E80484.9020200@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 28 Jan 2014 22:33:44 -0000 Let us try to include MR. =20 How about the following REQ2: Network-layer mobility support when needed =20 DMM solutions MUST enable network-layer=20 mobility when needed. Such mobility support is needed, for example, when an application or a host cannot cope with a change = in the IP address when a node moves. However, it is not always necessar= y to maintain a stable IP address or prefix. Here, the node can be a mobile host or a mobile router.=20 A host can be a mobile host or a host in a LFN.=20 An application can be running on a mobile host or a on a host in a LFN. A MR also does not need to maintain stable IP address or prefix when there = are no hosts attached to it or when there are no active applications runnin= g in the hosts of its network.=20 Any comments/changes/corrections? H Anthony Chan -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Tuesday, January 28, 2014 1:27 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Le 28/01/2014 19:58, h chan a =E9crit : > Let me try to understand the concern here. > > What is new in this requirement is "when needed" in contrast to=20 > providing IP mobility by default. First, providing mobility by default is not a black/white alternative to no= t providing mobility. It is very possible on the same machine to have Mobile IP enabled for some = flows and disabled for others (depending what we call a 'flow').=20 It is also possible to have Mobile IP and NAT at the same time on the same = Mobile Router. > Without this requirement, mobility support may be provided by default,=20 > which is transparent to higher layers. Again, transparency to higher layers means we talk mobility management on a= Mobile Host. Transparency to higher layers has little meaning if we talk mobility manage= ment provided on a Mobile Router (which is not a Mobile Host). > With this requirement, assume there are separate steps in the DMM=20 > solution. 1. A decision is made whether network-layer mobility support=20 > is needed. 2. When the need is established, network-layer mobility=20 > support is invoked. 3. Then transparent support is provided and is=20 > transparent to layers above IP. > > Transparency is clear in step 3 above. This looks like a trigger which enables mobility, or other times disables i= t. But one can have a Mobile IP daemon and a NAT run at the same time on the s= ame machine. There is no decision in time. Some decision happens at packet based on IP destination address. > The question however is whether the preceding steps involve the=20 > application, so that one may question whether the entire DMM solution=20 > (with all the steps) as a whole is transparent. I agree. I am not aware of any application which talks to Mobile IP.=20 Whenever it is there it is 'transparent'. > So the intention of the requirement is that WHEN/AFTER the decision is=20 > made to invoke mobility support, then the mobility support is=20 > transparent to the application. Then we may want to check and make=20 > sure the emphasis of this requirement does mean transparency in this =20 > respect only. I disagree. As I said above, the word 'transparency' is dubious. Some times it may mea= n 'non-existent', some times it may mean light goes through it but modified= . If one wants to continue using it, then one should better qualify it with '= Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'. Because a Mobile Router doing mobility management in a transparent manner o= n the Mobile Router for the LFN has nothing to do with applications, neithe= r with upper layers. Also, a Mobile Router doing NAT and Mobile IP at the same time is 50%-trans= parent. > > Original wording: > > REQ2: Transparency to Upper Layers when needed > > DMM solutions MUST provide transparent mobility support above the IP =20 > layer when needed. Such transparency is needed, for example, when, ^on a Mobile Host. > upon change of point of attachment to the network, an application flow=20 > cannot cope with a change in the IP address. (it's not the application flow, it is a socket which some times may break [= paste here the error from the screen]; the term 'application flow' in this = context has little meaning) (an 'application flow' has no understandable meaning in practice). > However, it is not always necessary to maintain a stable home IP=20 > address or prefix for every application or at all times for a mobile=20 > node. ^a Mobile Host. I agree. > I now tend to think the first sentence in this original wording may=20 > steer the emphasis on providing transparent support, which is not what=20 > the motivation and the problems are talking about. I agree. > The motivation and the problems are talking about when they are not=20 > needed. The emphasis of this requirement therefore is on the=20 > capability to turn OFF unnecessary mobility support. In a sense I agree with the meaning. But when trying to turn off or on mobility support the things are not like = if there were a knob on/off, not even like starting/stopping some daemon. = It is a matter of always having the Mobile IP support on, and tweak the rou= ting table with some particular entries, and the firewalling rules to NAT s= ome addresses or not. > How about the following > > REQ2: Network-layer mobility support ONLY when needed If we understood better when it was needed... > DMM solutions MUST NOT provide network-layer mobility support when NOT=20 > needed. I would say that Mobile IP MUST always be turned on on a Mobile Host. > (or if you don't like double negatives: (DMM solutions MUST provide=20 > network-layer mobility support ONLY when needed) No, I would say to have it always on. If some applications don't want it t= hen dont use it; realize that by inserting routing table entries. One may wonder when some applications dont want it. One answer is when som= e applications prefer to not go through the HA in order to take advantage o= f the 4G pure speed. When? For example if the HA link is too slow compared= to 4G. (remark this is not the same as saying that the triangular route i= s longer than straight, because that is always true). This is not a request for Route Optimization. It is an invitation to analy= ze in deeper detail the application needs. One may have an application start via the HA (offer reachability) and conti= nue straight, w/o HA. It's the same application. Consider a video-call like appli: you want to be reachable always at the sa= me IP address (through HA) but once the session is ongoing you may not want= to use it through HA if no handover in sight. Something like that. These things could be further refined if we really went into detail and und= erstood what are the needs of applications, the distinctions MH-MR, etc. > Such transparent mobility support above the IP layer is needed, for=20 > example, when, upon change of point of attachment to the network, an =20 > application flow cannot cope with a change in the IP address. > However, it is not always necessary to maintain a stable home IP=20 > address or prefix for every application or at all times for a mobile =20 > node. A Mobile Host never maintains a stable prefix, only a stable address. A Mobile Router may maintain a stable address (its HoA) and may maintain a = stable prefix (its MNP). It could also just maintain stable just its MNP,= but not its HoA; and vice-versa. Is that mobility? For each of these there is an application :-) Alex > > Any comments/changes/corrections? > > H Anthony Chan > > -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On=20 > Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM > To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: > draft-ietf-dmm-requirements > > Le 28/01/2014 02:45, h chan a =E9crit : >> I will drop "related" >> >> Regarding the following >> >> 5. Section 5: - I am a little confused by REQ2. It says that a DMM=20 >> solution should be transparent to the applications. > > This remark is typically true when we talk Mobile IP on a Mobile Host=20 > and an application like firefox runs above a BSD Socket interface. > > >> However, the motivation talks about identifying applications that do=20 >> (or do not) need mobility support from the network layer. That =20 >> doesn't sound transparent to me. Am I reading this incorrectly? >> >> It appears that unless the network can find out whether the=20 >> application has need of such support, the application indeed may need=20 >> to invoke mobility support or has to convey its need to the network. >> >> The emphasis of requirement is on "when needed." So, I think it is =20 >> better to drop the word "transparent" as follows: >> >> REQ2: Mobility support when needed >> >> DMM solutions MUST provide mobility support to above the IP layer=20 >> when needed. Such support is needed, for example, when, upon change=20 >> of point of attachment to the network, an application flow cannot=20 >> cope with a change in the IP address. However, it is not always=20 >> necessary to maintain a stable home IP address or prefix for every=20 >> application or at all times for a mobile node. >> >> Motivation: The motivation of this requirement is to enable more=20 >> efficient routing and more efficient use of network resources by=20 >> selecting an IP address or prefix according to whether mobility=20 >> support is needed and by not maintaining context at the mobility=20 >> anchor when there is no such need. > > Whenever we discuss this 'transparency' paragraph I have again the=20 > same comments. > > First, I am not sure DMM is only about Mobile Hosts, or about Mobile=20 > Routers as well. > > Because, if we talk Mobile Routers, then rarely an application runs=20 > directly on it. Most applications would run on LFN. > > Transparency? > > If the applications run on the LFN, the change of the attachment of=20 > the MR is 'transparent' to them, regardless whether or not MR does=20 > something to maintain stability of that address (Mobile IP, other). > > Second, this transparency may depend on the direction, or more complex=20 > 'shape' of the application flows. Some IP flows of some applications=20 > have very complex 'shapes', with various sets of IP src and dst, and=20 > triangular or HA-less shapes. > > Take for example a video-call. The session establishment through an=20 > intermediary and behind NAT is followed by the ongoing 4 flows (2=20 > audio 2 video)... they all take different paths... each may need or=20 > not need to go through the HA, and each has distinct behaviours when =20 > the IP address changes, hence each would have a distinct=20 > 'transparency' requirement. Is this _one_ application? > > Alex > >> >> H Anthony Chan >> >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] =20 >> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM=20 >> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; >> dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: >> draft-ietf-dmm-requirements >> >> >> >> On 1/24/14 7:38 PM, h chan wrote: >>> 4. Section 4: - I am not sure that it benefits the document to label=20 >>> PS6 and PS7 as related. Those issues are problematic on their own.=20 >>> If you remove the "(related problem)" label from them, make sure=20 >>> that REQ2 is updated to remove mention of "related problem". >>> >>> The intention of the name "related problems" was not to suggest they=20 >>> are less problematic, but rather to distinguish them from the other=20 >>> problems directly on mobility management. Although these problems=20 >>> are not directly on mobility management, the DMM solutions can solve=20 >>> these additional problems. They are therefore included. So, as long=20 >>> as this section is not to be interpreted as limited to problems=20 >>> directly on mobility management, we can drop the word "related." >>> >> >> I will leave it to the authors/WG, but I don't see a benefit to the=20 >> "related" tag. >> >> Regards, Brian >> >> _______________________________________________ dmm mailing list=20 >> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >> >> > > > _______________________________________________ dmm mailing list=20 > dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > From brian@innovationslab.net Wed Jan 29 05:56:43 2014 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 9B59C1A02C8 for ; Wed, 29 Jan 2014 05:56:43 -0800 (PST) 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 l8ZKYTo6c4kq for ; Wed, 29 Jan 2014 05:56:42 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 267071A037D for ; Wed, 29 Jan 2014 05:56:42 -0800 (PST) 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 84431880EE; Wed, 29 Jan 2014 05:56:39 -0800 (PST) Received: from 102524131.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1170C13680B7; Wed, 29 Jan 2014 05:56:38 -0800 (PST) Message-ID: <52E90898.6050604@innovationslab.net> Date: Wed, 29 Jan 2014 08:56:40 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB62E@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB62E@szxeml557-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WBwmdE1xfHcDbU1elF2esxoVWc0sNgObO" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 13:56:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WBwmdE1xfHcDbU1elF2esxoVWc0sNgObO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/28/14 3:31 PM, h chan wrote: > REQ6: Security considerations >=20 >=20 >=20 > A DMM solution MUST NOT introduce new security risks or >=20 > amplify existing security risks against which the existing >=20 > security mechanisms/protocols cannot offer sufficient >=20 > protection. >=20 >=20 >=20 > The intention of REQ6 is NOT that it cannot introduce new vulnerabiliti= es at all. >=20 > Rather the protection against such new vulnerablities can be limited to= the use of existing security protocols. It is okay to provide additional= means to protect against new risks as long as they do not require develo= pment of new security protocols which are needed for DMM alone but are no= t needed otherwise. Else a network deploying DMM versus a network not dep= loying DMM will need additional security protocols which are not needed o= therwise. >=20 >=20 >=20 > So I think the word: "existing" security mechanisms/protocols is intend= ed to exclude protocols that are not needed otherwise. >=20 >=20 >=20 > We can clarify with the following: >=20 >=20 >=20 > REQ6: Security considerations >=20 >=20 >=20 > A DMM solution MUST NOT introduce new security risks or >=20 > amplify existing security risks against which security means = using existing >=20 > security mechanisms/protocols CANNOT offer sufficient >=20 > protection. >=20 The above seems a little clunky. Does this work for everyone? A DMM solution MUST NOT introduce new security risks, or amplify existing security risks, that cannot be mitigated by existing security mechanisms or protocols. Regards, Brian --WBwmdE1xfHcDbU1elF2esxoVWc0sNgObO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS6QieAAoJEBOZRqCi7goqRTcIAM++uC5/qS8Pe+ykrn3bVKcx tmAtGzmPx9oanQJmkXp5HY4SllWHfHkM59GOTSVlmYgNwp99Rxo39yOQfVWDxL1T 4CIOGWX3R3C2pk3Tkm8w4mqegHeqG50ByZ1xlPNGghQ6mm0w4rGwi7i/6GD079Ua ++jXChoncQgGmATldmhTuNc27oR/VXmFMVhOCeRXz8dZrTIxjo+WUwR2dxfKToiI 7oB0pca1MjtKMvtW2oF4+HG3Olxm4sU4iEYTK+4cD9IuYKOxnJ9EJB2e2UkP0bi1 wEQgdJ6sA86xGW0NchlGSCQzX4Dp56RRhj7EjNU00nhNFpb7BgMwfOIvm8R+uR4= =IjcJ -----END PGP SIGNATURE----- --WBwmdE1xfHcDbU1elF2esxoVWc0sNgObO-- From brian@innovationslab.net Wed Jan 29 06:01:11 2014 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 2EAFC1A0375 for ; Wed, 29 Jan 2014 06:01:11 -0800 (PST) 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 oetoEbjLc6OA for ; Wed, 29 Jan 2014 06:01:06 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id BAC841A0371 for ; Wed, 29 Jan 2014 06:01:06 -0800 (PST) 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 09AF4880ED; Wed, 29 Jan 2014 06:01:04 -0800 (PST) Received: from 102524131.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5E54213680B7; Wed, 29 Jan 2014 06:01:03 -0800 (PST) Message-ID: <52E909A6.80008@innovationslab.net> Date: Wed, 29 Jan 2014 09:01:10 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB641@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB641@szxeml557-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t2cJJ07ihAVIVefrmmmbbCq6lUFkXI5PA" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 14:01:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t2cJJ07ihAVIVefrmmmbbCq6lUFkXI5PA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/28/14 4:33 PM, h chan wrote: > Regarding the following: >=20 > - What is meant by co-exist in REQ5? Does this mean that a DMM solutio= n does not break an existing one? Or does it mean that it must inter-ope= rate with existing ones? Is this like IPv4 and IPv6 being incompatible, = but can run concurrently on the same network? Or does this mean there ne= eds to be some mechanism for interaction (i.e., like NAT64)? >=20 >=20 >=20 > I think the bottom line is that the existing ones do not break. >=20 >=20 >=20 > Original >=20 > REQ5: Co-existence with deployed networks and hosts >=20 >=20 >=20 > The DMM solution MUST be able to co-exist with existing >=20 > network deployments and end hosts. For example, depending on= >=20 > the environment in which DMM is deployed, DMM solutions may >=20 > need to be compatible with other deployed mobility protocols >=20 > or may need to co-exist with a network or mobile hosts/router= s >=20 > that do not support DMM protocols. The mobile node may also >=20 > move between different access networks, where some of them ma= y >=20 > support neither DMM nor another mobility protocol. >=20 > Furthermore, a DMM solution SHOULD work across different >=20 > networks, possibly operated as separate administrative >=20 > domains, when allowed by the trust relationship between them.= >=20 >=20 >=20 > We can change to: >=20 > REQ5: Co-existence with deployed networks and hosts >=20 >=20 >=20 > The DMM solution MUST be able to co-exist with existing >=20 > network deployments and end hosts without breaking them. For= example, depending on >=20 > the environment in which DMM is deployed, DMM solutions may >=20 > need to be compatible with other deployed mobility protocols >=20 > or may need to co-exist with a network or mobile hosts/router= s >=20 > that do not support DMM protocols. The mobile node may also >=20 > move between different access networks, where some of them ma= y >=20 > support neither DMM nor another mobility protocol. >=20 > Furthermore, a DMM solution SHOULD work across different >=20 > networks, possibly operated as separate administrative >=20 > domains, when allowed by the trust relationship between them.= The "without breaking" is fine. However, the "need to be compatible with" phrasing is still problematic. Is that inferring that in some situations that a DMM solution would need to interact with, for example, PMIP? Regards, Brian --t2cJJ07ihAVIVefrmmmbbCq6lUFkXI5PA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS6QmmAAoJEBOZRqCi7goqxO0H/iP8s+LMwrUR/HcJGSYvvkN6 5Wr8MiuLqqCDTtx/iA3wQZNz5wuEz4qkfho00Z/QWIiWgqpAC9K9wD+WLCwBXHY7 QOB7t5E5ye0+npTCNpKWp1arOL1m+tqdsgJnQPXQjY8SABmAT+b2GF/dM5Q6fLRe h3/Yvs8556LvrBjzMyGJkGJsOEXwQ1zV4ydDZH+87FoKLlkBoyl7t7GQ0qEznG3o KLOa1ln6LMbkH1gcRu7CrFaAoBHGZz5ftLthaNh4IonQTpXoN62NoFIk5zS2vEQG RqCr/7RLcIzAkYpCSqHKcrVZrixDs8ee0J2KRdOc1A24L+sUQJfPOqze+9ztoO4= =nSi5 -----END PGP SIGNATURE----- --t2cJJ07ihAVIVefrmmmbbCq6lUFkXI5PA-- From brian@innovationslab.net Wed Jan 29 06:01:45 2014 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 5DC6D1A0375 for ; Wed, 29 Jan 2014 06:01:45 -0800 (PST) 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 HAmwFnkOSwME for ; Wed, 29 Jan 2014 06:01:43 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id CF3D61A0371 for ; Wed, 29 Jan 2014 06:01:43 -0800 (PST) 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 3D648880ED; Wed, 29 Jan 2014 06:01:41 -0800 (PST) Received: from 102524131.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A213913680B7; Wed, 29 Jan 2014 06:01:40 -0800 (PST) Message-ID: <52E909CC.4030208@innovationslab.net> Date: Wed, 29 Jan 2014 09:01:48 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB647@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB647@szxeml557-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mGshGJ5CAxlQCtHGpGb4grHgitjKl9390" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 14:01:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mGshGJ5CAxlQCtHGpGb4grHgitjKl9390 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That works for me. Brian On 1/28/14 4:58 PM, h chan wrote: > Regarding the following: >=20 > - Should PS7 mention mobility solutions that operated at other layers o= f the protocol stack? >=20 >=20 >=20 > Original >=20 > PS7: Deployment with multiple mobility solutions >=20 >=20 >=20 > There are already many variants and extensions of MIP. >=20 > Deployment of new mobility management solutions can be >=20 > challenging, and debugging difficult, when they co-exist with >=20 > solutions already deployed in the field. >=20 >=20 >=20 > We can change to >=20 >=20 >=20 > PS7: Deployment with multiple mobility solutions >=20 >=20 >=20 > There are already many variants and extensions of MIP >=20 > as well mobility solutions at other layers. >=20 > Deployment of new mobility management solutions can be >=20 > challenging, and debugging difficult, when they co-exist with >=20 > solutions already deployed in the field. >=20 >=20 >=20 > H Anthony Chan >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Friday, January 24, 2014 11:30 AM > To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McC= ann > Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements >=20 >=20 >=20 > All, >=20 > I have performed my AD review, as a part of the publication proces= s, of draft-ietf-dmm-requirements. The following issues should be addres= sed prior to moving this draft to IETF Last Call. Please let me know if = you have any questions on these points. >=20 >=20 >=20 > 1. I would suggest making sure that the Abstract and Introduction expli= citly state that these requirements for for network (L3)-layer mobility m= anagement. >=20 >=20 >=20 > 2. Introduction: >=20 >=20 >=20 > - The EPC acronym needs to be expanded. >=20 > - Do not reference the DMM charter within the document. >=20 > - expand HA and LMA since you are using them before the Terminology sec= tion. >=20 >=20 >=20 > 3. Section 3: >=20 >=20 >=20 > - It would be nice to ensure that all acronyms used in the figures are = expanded somewhere prior to the figures. >=20 >=20 >=20 > - I am curious as to why there is not any mention in this section about= route optimization within the mobility protocols. This mention should d= escribe why current route optimization is host-based in order to lead int= o PS1. >=20 >=20 >=20 > 4. Section 4: >=20 >=20 >=20 > - To be abundantly clear, I would re-word the start of PS3 to be "Lack = of scalability". >=20 >=20 >=20 > - I am not sure that it benefits the document to label PS6 and PS7 as r= elated. Those issues are problematic on their own. If you remove the "(= related problem)" label from them, make sure that REQ2 is updated to remo= ve mention of "related problem". >=20 >=20 >=20 > - Should PS7 mention mobility solutions that operated at other layers o= f the protocol stack? >=20 >=20 >=20 > 5. Section 5: >=20 >=20 >=20 > - Why does this section have sub-section numbers AND REQ numbers? >=20 >=20 >=20 > - I am not sure I understand what REQ1 is saying when it talks about co= mbining mobility anchors with CDNs. It *sounds* like mobility management= needs to be maintained by CDN providers. >=20 >=20 >=20 > - I am a little confused by REQ2. It says that a DMM solution should b= e transparent to the applications. However, the motivation talks about i= dentifying applications that do (or do not) need mobility support from th= e network layer. That doesn't sound transparent to me. Am I reading thi= s incorrectly? >=20 >=20 >=20 > - I am wondering if the SHOULD in REQ4 ought to be a MUST. Why would a= nyone work on a new protocol without first determining the feasibility of= the existing ones? >=20 >=20 >=20 > - What is meant by co-exist in REQ5? Does this mean that a DMM solutio= n does not break an existing one? Or does it mean that it must inter-ope= rate with existing ones? Is this like IPv4 and IPv6 being incompatible, = but can run concurrently on the same network? Or does this mean there ne= eds to be some mechanism for interaction (i.e., like NAT64)? >=20 >=20 >=20 > - I think REQ6 is incomplete. A DMM solution can introduce new vulnera= bilities, but it needs to provide ways to cope with those vulnerabilities= =2E >=20 >=20 >=20 > 6. I would like to avoid issues further along the publication chain, so= I would like the editors to look at how the contributing authors are ide= ntified in the draft. A good approach is described in the RFC Style Guid= e (https://www.rfc-editor.org/policy.html#policy.auth) and deviating from= that can be problematic. >=20 >=20 >=20 > Regards, >=20 > Brian >=20 >=20 >=20 --mGshGJ5CAxlQCtHGpGb4grHgitjKl9390 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS6QnMAAoJEBOZRqCi7goqyf4H/A4kC3hB8Yj5zKgj94xeNcf6 gT2tolmL8kUgKhgf8fk6a61AB5I4MFLDtySEC2vULaFVwDLfOxtPk/3tFWOzfwa5 7sMymdnjeJ4FLRXpWbP+y4C3KYkWk5jId8PbeShJak5IRBHpx2TFvn69G71IzJOE BD9bM8AaHTqDsaczw0hUcAiu5VYue/I5ylO7kjXX98GJyuSxa492Biu53TSp0Urq Hva0tS+lM1AiTt9dZs1dqQ9mvaMPkDAh5UX4eUhBnp3ExNP4fzsfJkZt1KEj6w6N uJhQN7ICXPvHVj3NYuGJuHumQRr4Uy+4BkSTaxGFneBA8SIuBPxpDyo25sTpgxs= =+/95 -----END PGP SIGNATURE----- --mGshGJ5CAxlQCtHGpGb4grHgitjKl9390-- From brian@innovationslab.net Wed Jan 29 06:26:01 2014 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 072971A0280 for ; Wed, 29 Jan 2014 06:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2] 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 Sv6DCQeQIFgl for ; Wed, 29 Jan 2014 06:25:58 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3F31A0372 for ; Wed, 29 Jan 2014 06:25:58 -0800 (PST) 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 E37D9880ED; Wed, 29 Jan 2014 06:25:55 -0800 (PST) Received: from 102524131.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 56CFD1368149; Wed, 29 Jan 2014 06:25:55 -0800 (PST) Message-ID: <52E90F7A.3050902@innovationslab.net> Date: Wed, 29 Jan 2014 09:26:02 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , Alexandru Petrescu , "dmm@ietf.org" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GP1DCXXnF0rAv8WVrf7CQkpROt5XxGV33" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 14:26:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GP1DCXXnF0rAv8WVrf7CQkpROt5XxGV33 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony, Does this requirement also include a way for the application (or transport protocol) to request/refuse mobility support? The "when needed" implies some type of knowledge that is either manually configured or signaled from the upper layer. Regards, Brian On 1/28/14 5:33 PM, h chan wrote: > Let us try to include MR. =20 >=20 > How about the following >=20 > REQ2: Network-layer mobility support when needed > =20 > DMM solutions MUST enable network-layer=20 > mobility when needed. > Such mobility support is needed, for > example, when an application or a host cannot cope with a cha= nge in the > IP address when a node moves. However, it is not always nece= ssary to maintain a > stable IP address or prefix. >=20 > Here, the node can be a mobile host or a mobile router.=20 > A host can be a mobile host or a host in a LFN.=20 > An application can be running on a mobile host or a on a host in a LFN.= > A MR also does not need to maintain stable IP address or prefix when th= ere are no hosts attached to it or when there are no active applications = running in the hosts of its network.=20 >=20 > Any comments/changes/corrections? >=20 > H Anthony Chan >=20 >=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Tuesday, January 28, 2014 1:27 PM > To: h chan; dmm@ietf.org > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements >=20 > Le 28/01/2014 19:58, h chan a =E9crit : >> Let me try to understand the concern here. >> >> What is new in this requirement is "when needed" in contrast to=20 >> providing IP mobility by default. >=20 > First, providing mobility by default is not a black/white alternative t= o not providing mobility. >=20 > It is very possible on the same machine to have Mobile IP enabled for s= ome flows and disabled for others (depending what we call a 'flow').=20 > It is also possible to have Mobile IP and NAT at the same time on the s= ame Mobile Router. >=20 >> Without this requirement, mobility support may be provided by default,= =20 >> which is transparent to higher layers. >=20 > Again, transparency to higher layers means we talk mobility management = on a Mobile Host. >=20 > Transparency to higher layers has little meaning if we talk mobility ma= nagement provided on a Mobile Router (which is not a Mobile Host). >=20 >> With this requirement, assume there are separate steps in the DMM=20 >> solution. 1. A decision is made whether network-layer mobility support= =20 >> is needed. 2. When the need is established, network-layer mobility=20 >> support is invoked. 3. Then transparent support is provided and is=20 >> transparent to layers above IP. >> >> Transparency is clear in step 3 above. >=20 > This looks like a trigger which enables mobility, or other times disabl= es it. >=20 > But one can have a Mobile IP daemon and a NAT run at the same time on t= he same machine. There is no decision in time. >=20 > Some decision happens at packet based on IP destination address. >=20 >> The question however is whether the preceding steps involve the=20 >> application, so that one may question whether the entire DMM solution = >> (with all the steps) as a whole is transparent. >=20 > I agree. I am not aware of any application which talks to Mobile IP.=20 > Whenever it is there it is 'transparent'. >=20 >> So the intention of the requirement is that WHEN/AFTER the decision is= =20 >> made to invoke mobility support, then the mobility support is=20 >> transparent to the application. Then we may want to check and make=20 >> sure the emphasis of this requirement does mean transparency in this = >> respect only. >=20 > I disagree. >=20 > As I said above, the word 'transparency' is dubious. Some times it may= mean 'non-existent', some times it may mean light goes through it but mo= dified. >=20 > If one wants to continue using it, then one should better qualify it wi= th 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'. >=20 > Because a Mobile Router doing mobility management in a transparent mann= er on the Mobile Router for the LFN has nothing to do with applications, = neither with upper layers. >=20 > Also, a Mobile Router doing NAT and Mobile IP at the same time is 50%-t= ransparent. >=20 >> >> Original wording: >> >> REQ2: Transparency to Upper Layers when needed >> >> DMM solutions MUST provide transparent mobility support above the IP = >> layer when needed. Such transparency is needed, for example, when, > ^on a Mobile Host. >> upon change of point of attachment to the network, an application flow= =20 >> cannot cope with a change in the IP address. >=20 > (it's not the application flow, it is a socket which some times may bre= ak [paste here the error from the screen]; the term 'application flow' in= this context has little meaning) >=20 > (an 'application flow' has no understandable meaning in practice). >=20 >> However, it is not always necessary to maintain a stable home IP=20 >> address or prefix for every application or at all times for a mobile=20 >> node. > ^a Mobile Host. >=20 > I agree. >=20 >> I now tend to think the first sentence in this original wording may=20 >> steer the emphasis on providing transparent support, which is not what= =20 >> the motivation and the problems are talking about. >=20 > I agree. >=20 >> The motivation and the problems are talking about when they are not=20 >> needed. The emphasis of this requirement therefore is on the=20 >> capability to turn OFF unnecessary mobility support. >=20 > In a sense I agree with the meaning. >=20 > But when trying to turn off or on mobility support the things are not l= ike if there were a knob on/off, not even like starting/stopping some dae= mon. It is a matter of always having the Mobile IP support on, and tweak= the routing table with some particular entries, and the firewalling rule= s to NAT some addresses or not. >=20 >> How about the following >> >> REQ2: Network-layer mobility support ONLY when needed >=20 > If we understood better when it was needed... >=20 >> DMM solutions MUST NOT provide network-layer mobility support when NOT= =20 >> needed. >=20 > I would say that Mobile IP MUST always be turned on on a Mobile Host. >=20 >> (or if you don't like double negatives: (DMM solutions MUST provide=20 >> network-layer mobility support ONLY when needed) >=20 > No, I would say to have it always on. If some applications don't want = it then dont use it; realize that by inserting routing table entries. >=20 > One may wonder when some applications dont want it. One answer is when= some applications prefer to not go through the HA in order to take advan= tage of the 4G pure speed. When? For example if the HA link is too slow = compared to 4G. (remark this is not the same as saying that the triangul= ar route is longer than straight, because that is always true). >=20 > This is not a request for Route Optimization. It is an invitation to a= nalyze in deeper detail the application needs. >=20 > One may have an application start via the HA (offer reachability) and c= ontinue straight, w/o HA. It's the same application. >=20 > Consider a video-call like appli: you want to be reachable always at th= e same IP address (through HA) but once the session is ongoing you may no= t want to use it through HA if no handover in sight. >=20 > Something like that. >=20 > These things could be further refined if we really went into detail and= understood what are the needs of applications, the distinctions MH-MR, e= tc. >=20 >> Such transparent mobility support above the IP layer is needed, for=20 >> example, when, upon change of point of attachment to the network, an = >> application flow cannot cope with a change in the IP address. >> However, it is not always necessary to maintain a stable home IP=20 >> address or prefix for every application or at all times for a mobile = >> node. >=20 > A Mobile Host never maintains a stable prefix, only a stable address. >=20 > A Mobile Router may maintain a stable address (its HoA) and may maintai= n a stable prefix (its MNP). It could also just maintain stable just it= s MNP, but not its HoA; and vice-versa. Is that mobility? >=20 > For each of these there is an application :-) >=20 > Alex >=20 >> >> Any comments/changes/corrections? >> >> H Anthony Chan >> >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On = >> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM >> To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: >> draft-ietf-dmm-requirements >> >> Le 28/01/2014 02:45, h chan a =E9crit : >>> I will drop "related" >>> >>> Regarding the following >>> >>> 5. Section 5: - I am a little confused by REQ2. It says that a DMM=20 >>> solution should be transparent to the applications. >> >> This remark is typically true when we talk Mobile IP on a Mobile Host = >> and an application like firefox runs above a BSD Socket interface. >> >> >>> However, the motivation talks about identifying applications that do = >>> (or do not) need mobility support from the network layer. That =20 >>> doesn't sound transparent to me. Am I reading this incorrectly? >>> >>> It appears that unless the network can find out whether the=20 >>> application has need of such support, the application indeed may need= =20 >>> to invoke mobility support or has to convey its need to the network. >>> >>> The emphasis of requirement is on "when needed." So, I think it is =20 >>> better to drop the word "transparent" as follows: >>> >>> REQ2: Mobility support when needed >>> >>> DMM solutions MUST provide mobility support to above the IP layer=20 >>> when needed. Such support is needed, for example, when, upon change = >>> of point of attachment to the network, an application flow cannot=20 >>> cope with a change in the IP address. However, it is not always=20 >>> necessary to maintain a stable home IP address or prefix for every=20 >>> application or at all times for a mobile node. >>> >>> Motivation: The motivation of this requirement is to enable more=20 >>> efficient routing and more efficient use of network resources by=20 >>> selecting an IP address or prefix according to whether mobility=20 >>> support is needed and by not maintaining context at the mobility=20 >>> anchor when there is no such need. >> >> Whenever we discuss this 'transparency' paragraph I have again the=20 >> same comments. >> >> First, I am not sure DMM is only about Mobile Hosts, or about Mobile=20 >> Routers as well. >> >> Because, if we talk Mobile Routers, then rarely an application runs=20 >> directly on it. Most applications would run on LFN. >> >> Transparency? >> >> If the applications run on the LFN, the change of the attachment of=20 >> the MR is 'transparent' to them, regardless whether or not MR does=20 >> something to maintain stability of that address (Mobile IP, other). >> >> Second, this transparency may depend on the direction, or more complex= =20 >> 'shape' of the application flows. Some IP flows of some applications = >> have very complex 'shapes', with various sets of IP src and dst, and = >> triangular or HA-less shapes. >> >> Take for example a video-call. The session establishment through an=20 >> intermediary and behind NAT is followed by the ongoing 4 flows (2=20 >> audio 2 video)... they all take different paths... each may need or=20 >> not need to go through the HA, and each has distinct behaviours when = >> the IP address changes, hence each would have a distinct=20 >> 'transparency' requirement. Is this _one_ application? >> >> Alex >> >>> >>> H Anthony Chan >>> >>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] =20 >>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM=20 >>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; >>> dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: >>> draft-ietf-dmm-requirements >>> >>> >>> >>> On 1/24/14 7:38 PM, h chan wrote: >>>> 4. Section 4: - I am not sure that it benefits the document to label= =20 >>>> PS6 and PS7 as related. Those issues are problematic on their own. = >>>> If you remove the "(related problem)" label from them, make sure=20 >>>> that REQ2 is updated to remove mention of "related problem". >>>> >>>> The intention of the name "related problems" was not to suggest they= =20 >>>> are less problematic, but rather to distinguish them from the other = >>>> problems directly on mobility management. Although these problems=20 >>>> are not directly on mobility management, the DMM solutions can solve= =20 >>>> these additional problems. They are therefore included. So, as long = >>>> as this section is not to be interpreted as limited to problems=20 >>>> directly on mobility management, we can drop the word "related." >>>> >>> >>> I will leave it to the authors/WG, but I don't see a benefit to the=20 >>> "related" tag. >>> >>> Regards, Brian >>> >>> _______________________________________________ dmm mailing list=20 >>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>> >>> >> >> >> _______________________________________________ dmm mailing list=20 >> 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 >=20 --GP1DCXXnF0rAv8WVrf7CQkpROt5XxGV33 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS6Q96AAoJEBOZRqCi7goqEPgH/1Es0Dus7PGihtYCRO5/0ld1 kUZDF6LlBFYEpkz3tMR6QILYTTdmGCPxcbM35xXgPFh+PrP3Lc3jutkDoZFpaSbu 0Y070OayZQGnlVvU/WVCxwG4HkSPGxPJ/oRzjiULTWtFaBdFtQiZ81HWXEjmALJt DXhvKIFosLUR8ejwoJezOJLD0VunvsrrRC/QFJH1KB67tyGLAB0NVzvIKHfp0VPX OrY1TBRBOpP23UUYHySFkVUFDPCOMPOldjmNmNMKMx3h25+nPNpFKUrHG7ms+0nN LK3Y3QOYyTEqtaWH4gQ7JIPgkP5lHWBv0/QUfmLO2zbWYDquDsC9vc8RcPODvJg= =0i0b -----END PGP SIGNATURE----- --GP1DCXXnF0rAv8WVrf7CQkpROt5XxGV33-- From hassan.aliahmad@telecom-bretagne.eu Wed Jan 29 09:17:56 2014 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 E59911A0355 for ; Wed, 29 Jan 2014 09:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, 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 rkjEBEluGZ9w for ; Wed, 29 Jan 2014 09:17:50 -0800 (PST) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id DA5BE1A02F2 for ; Wed, 29 Jan 2014 09:17:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id CEB914000B for ; Wed, 29 Jan 2014 18:17:45 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HheQ4vX8wWwT for ; Wed, 29 Jan 2014 18:17:43 +0100 (CET) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id B11BF40008 for ; Wed, 29 Jan 2014 18:17:42 +0100 (CET) Received: by mail-qa0-f42.google.com with SMTP id k4so2880352qaq.1 for ; Wed, 29 Jan 2014 09:17:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fSLKpMdNm64vYsMiOYjTzeHEja96EBAwCW+f1yRBjw4=; b=BuiSKh8STfU+dEOFZT/Z5sL8nh2AG3oLLWnnpV3I7gpjt5eFz7YqI1vl5YB44Ma+KG AVnZMgOTN2W5PnhJduVkjTWzBoGq5iY0/HxLlw1RWzjoXC2ZTrN9Zg5zA2dbwk2Op1pJ lMsbgLPySNTb7hGPW9sURvhABcymot2TM41DQZQBoOgcRlTAPqzvQyqIfS6yFiSQUwem jFGXzla55S90GeEctVpDHR5gCc1MHTHTiwITsy97YODsXjkriFL0YLwrR0yvU9c7DLhe 0yV83erWD9w39S29vaGNQ3tMwQ6kdoF2PYKtyyODhsmGJm+SWSFolG8scbr+qt9EmDmm Gi9w== MIME-Version: 1.0 X-Received: by 10.224.68.70 with SMTP id u6mr13902920qai.5.1391015861556; Wed, 29 Jan 2014 09:17:41 -0800 (PST) Received: by 10.140.86.38 with HTTP; Wed, 29 Jan 2014 09:17:41 -0800 (PST) In-Reply-To: <52E90F7A.3050902@innovationslab.net> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E90F7A.3050902@innovationslab.net> Date: Wed, 29 Jan 2014 18:17:41 +0100 Message-ID: From: Hassan ALI AHMAD To: Brian Haberman Content-Type: multipart/alternative; boundary=001a11c2f58e4e39dd04f11f1e8d Cc: "dmm@ietf.org" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 17:17:57 -0000 --001a11c2f58e4e39dd04f11f1e8d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I think that SIP is a good example to clarify the idea. SIP can support mobility for SIP-based sessions at the application layer. The sessions that are initiated by SIP signaling (the INVITE procedure) can refuse IP mobility support at the network layer (if the operator prefers this choice and configures it). Then, mobility will be handled by SIP signaling (re-INVITE) at the application layer. Some people may not agree to apply this, but it's still a simple and valid example. Best regards, Hassan On Wed, Jan 29, 2014 at 3:26 PM, Brian Haberman w= rote: > Anthony, > Does this requirement also include a way for the application (or > transport protocol) to request/refuse mobility support? The "when > needed" implies some type of knowledge that is either manually > configured or signaled from the upper layer. > > Regards, > Brian > > On 1/28/14 5:33 PM, h chan wrote: > > Let us try to include MR. > > > > How about the following > > > > REQ2: Network-layer mobility support when needed > > > > DMM solutions MUST enable network-layer > > mobility when needed. > > Such mobility support is needed, for > > example, when an application or a host cannot cope with a > change in the > > IP address when a node moves. However, it is not always > necessary to maintain a > > stable IP address or prefix. > > > > Here, the node can be a mobile host or a mobile router. > > A host can be a mobile host or a host in a LFN. > > An application can be running on a mobile host or a on a host in a LFN. > > A MR also does not need to maintain stable IP address or prefix when > there are no hosts attached to it or when there are no active application= s > running in the hosts of its network. > > > > Any comments/changes/corrections? > > > > H Anthony Chan > > > > > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: Tuesday, January 28, 2014 1:27 PM > > To: h chan; dmm@ietf.org > > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements > > > > Le 28/01/2014 19:58, h chan a =E9crit : > >> Let me try to understand the concern here. > >> > >> What is new in this requirement is "when needed" in contrast to > >> providing IP mobility by default. > > > > First, providing mobility by default is not a black/white alternative t= o > not providing mobility. > > > > It is very possible on the same machine to have Mobile IP enabled for > some flows and disabled for others (depending what we call a 'flow'). > > It is also possible to have Mobile IP and NAT at the same time on the > same Mobile Router. > > > >> Without this requirement, mobility support may be provided by default, > >> which is transparent to higher layers. > > > > Again, transparency to higher layers means we talk mobility management > on a Mobile Host. > > > > Transparency to higher layers has little meaning if we talk mobility > management provided on a Mobile Router (which is not a Mobile Host). > > > >> With this requirement, assume there are separate steps in the DMM > >> solution. 1. A decision is made whether network-layer mobility support > >> is needed. 2. When the need is established, network-layer mobility > >> support is invoked. 3. Then transparent support is provided and is > >> transparent to layers above IP. > >> > >> Transparency is clear in step 3 above. > > > > This looks like a trigger which enables mobility, or other times > disables it. > > > > But one can have a Mobile IP daemon and a NAT run at the same time on > the same machine. There is no decision in time. > > > > Some decision happens at packet based on IP destination address. > > > >> The question however is whether the preceding steps involve the > >> application, so that one may question whether the entire DMM solution > >> (with all the steps) as a whole is transparent. > > > > I agree. I am not aware of any application which talks to Mobile IP. > > Whenever it is there it is 'transparent'. > > > >> So the intention of the requirement is that WHEN/AFTER the decision is > >> made to invoke mobility support, then the mobility support is > >> transparent to the application. Then we may want to check and make > >> sure the emphasis of this requirement does mean transparency in this > >> respect only. > > > > I disagree. > > > > As I said above, the word 'transparency' is dubious. Some times it may > mean 'non-existent', some times it may mean light goes through it but > modified. > > > > If one wants to continue using it, then one should better qualify it > with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'. > > > > Because a Mobile Router doing mobility management in a transparent > manner on the Mobile Router for the LFN has nothing to do with > applications, neither with upper layers. > > > > Also, a Mobile Router doing NAT and Mobile IP at the same time is > 50%-transparent. > > > >> > >> Original wording: > >> > >> REQ2: Transparency to Upper Layers when needed > >> > >> DMM solutions MUST provide transparent mobility support above the IP > >> layer when needed. Such transparency is needed, for example, when, > > ^on a Mobile Host. > >> upon change of point of attachment to the network, an application flow > >> cannot cope with a change in the IP address. > > > > (it's not the application flow, it is a socket which some times may > break [paste here the error from the screen]; the term 'application flow' > in this context has little meaning) > > > > (an 'application flow' has no understandable meaning in practice). > > > >> However, it is not always necessary to maintain a stable home IP > >> address or prefix for every application or at all times for a mobile > >> node. > > ^a Mobile Host. > > > > I agree. > > > >> I now tend to think the first sentence in this original wording may > >> steer the emphasis on providing transparent support, which is not what > >> the motivation and the problems are talking about. > > > > I agree. > > > >> The motivation and the problems are talking about when they are not > >> needed. The emphasis of this requirement therefore is on the > >> capability to turn OFF unnecessary mobility support. > > > > In a sense I agree with the meaning. > > > > But when trying to turn off or on mobility support the things are not > like if there were a knob on/off, not even like starting/stopping some > daemon. It is a matter of always having the Mobile IP support on, and > tweak the routing table with some particular entries, and the firewalling > rules to NAT some addresses or not. > > > >> How about the following > >> > >> REQ2: Network-layer mobility support ONLY when needed > > > > If we understood better when it was needed... > > > >> DMM solutions MUST NOT provide network-layer mobility support when NOT > >> needed. > > > > I would say that Mobile IP MUST always be turned on on a Mobile Host. > > > >> (or if you don't like double negatives: (DMM solutions MUST provide > >> network-layer mobility support ONLY when needed) > > > > No, I would say to have it always on. If some applications don't want > it then dont use it; realize that by inserting routing table entries. > > > > One may wonder when some applications dont want it. One answer is when > some applications prefer to not go through the HA in order to take > advantage of the 4G pure speed. When? For example if the HA link is too > slow compared to 4G. (remark this is not the same as saying that the > triangular route is longer than straight, because that is always true). > > > > This is not a request for Route Optimization. It is an invitation to > analyze in deeper detail the application needs. > > > > One may have an application start via the HA (offer reachability) and > continue straight, w/o HA. It's the same application. > > > > Consider a video-call like appli: you want to be reachable always at th= e > same IP address (through HA) but once the session is ongoing you may not > want to use it through HA if no handover in sight. > > > > Something like that. > > > > These things could be further refined if we really went into detail and > understood what are the needs of applications, the distinctions MH-MR, et= c. > > > >> Such transparent mobility support above the IP layer is needed, for > >> example, when, upon change of point of attachment to the network, an > >> application flow cannot cope with a change in the IP address. > >> However, it is not always necessary to maintain a stable home IP > >> address or prefix for every application or at all times for a mobile > >> node. > > > > A Mobile Host never maintains a stable prefix, only a stable address. > > > > A Mobile Router may maintain a stable address (its HoA) and may maintai= n > a stable prefix (its MNP). It could also just maintain stable just its > MNP, but not its HoA; and vice-versa. Is that mobility? > > > > For each of these there is an application :-) > > > > Alex > > > >> > >> Any comments/changes/corrections? > >> > >> H Anthony Chan > >> > >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On > >> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM > >> To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: > >> draft-ietf-dmm-requirements > >> > >> Le 28/01/2014 02:45, h chan a =E9crit : > >>> I will drop "related" > >>> > >>> Regarding the following > >>> > >>> 5. Section 5: - I am a little confused by REQ2. It says that a DMM > >>> solution should be transparent to the applications. > >> > >> This remark is typically true when we talk Mobile IP on a Mobile Host > >> and an application like firefox runs above a BSD Socket interface. > >> > >> > >>> However, the motivation talks about identifying applications that do > >>> (or do not) need mobility support from the network layer. That > >>> doesn't sound transparent to me. Am I reading this incorrectly? > >>> > >>> It appears that unless the network can find out whether the > >>> application has need of such support, the application indeed may need > >>> to invoke mobility support or has to convey its need to the network. > >>> > >>> The emphasis of requirement is on "when needed." So, I think it is > >>> better to drop the word "transparent" as follows: > >>> > >>> REQ2: Mobility support when needed > >>> > >>> DMM solutions MUST provide mobility support to above the IP layer > >>> when needed. Such support is needed, for example, when, upon change > >>> of point of attachment to the network, an application flow cannot > >>> cope with a change in the IP address. However, it is not always > >>> necessary to maintain a stable home IP address or prefix for every > >>> application or at all times for a mobile node. > >>> > >>> Motivation: The motivation of this requirement is to enable more > >>> efficient routing and more efficient use of network resources by > >>> selecting an IP address or prefix according to whether mobility > >>> support is needed and by not maintaining context at the mobility > >>> anchor when there is no such need. > >> > >> Whenever we discuss this 'transparency' paragraph I have again the > >> same comments. > >> > >> First, I am not sure DMM is only about Mobile Hosts, or about Mobile > >> Routers as well. > >> > >> Because, if we talk Mobile Routers, then rarely an application runs > >> directly on it. Most applications would run on LFN. > >> > >> Transparency? > >> > >> If the applications run on the LFN, the change of the attachment of > >> the MR is 'transparent' to them, regardless whether or not MR does > >> something to maintain stability of that address (Mobile IP, other). > >> > >> Second, this transparency may depend on the direction, or more complex > >> 'shape' of the application flows. Some IP flows of some applications > >> have very complex 'shapes', with various sets of IP src and dst, and > >> triangular or HA-less shapes. > >> > >> Take for example a video-call. The session establishment through an > >> intermediary and behind NAT is followed by the ongoing 4 flows (2 > >> audio 2 video)... they all take different paths... each may need or > >> not need to go through the HA, and each has distinct behaviours when > >> the IP address changes, hence each would have a distinct > >> 'transparency' requirement. Is this _one_ application? > >> > >> Alex > >> > >>> > >>> H Anthony Chan > >>> > >>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] > >>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM > >>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; > >>> dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: > >>> draft-ietf-dmm-requirements > >>> > >>> > >>> > >>> On 1/24/14 7:38 PM, h chan wrote: > >>>> 4. Section 4: - I am not sure that it benefits the document to label > >>>> PS6 and PS7 as related. Those issues are problematic on their own. > >>>> If you remove the "(related problem)" label from them, make sure > >>>> that REQ2 is updated to remove mention of "related problem". > >>>> > >>>> The intention of the name "related problems" was not to suggest they > >>>> are less problematic, but rather to distinguish them from the other > >>>> problems directly on mobility management. Although these problems > >>>> are not directly on mobility management, the DMM solutions can solve > >>>> these additional problems. They are therefore included. So, as long > >>>> as this section is not to be interpreted as limited to problems > >>>> directly on mobility management, we can drop the word "related." > >>>> > >>> > >>> I will leave it to the authors/WG, but I don't see a benefit to the > >>> "related" tag. > >>> > >>> 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 > >> > >> > > > > > > _______________________________________________ > > 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 > > --001a11c2f58e4e39dd04f11f1e8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

I think that SIP is a good e= xample to clarify the idea. SIP can support mobility for SIP-based sessions= at the application layer. The sessions that are initiated by SIP signaling= (the INVITE procedure) can refuse IP mobility support at the network layer= (if the operator prefers this choice and configures it). Then, mobility wi= ll be handled by SIP signaling (re-INVITE) at the application layer.

Some people may not agree to apply this, but it's still a sim= ple and valid example.

Best regards,
Hassan


On Wed, Jan 29, 2014 at 3:26 PM, Brian Haberman <brian@innovationsl= ab.net> wrote:
Anthony,
=A0 =A0 =A0Does this requirement also include a way for the application (or=
transport protocol) to request/refuse mobility support? =A0The "when needed" implies some type of knowledge that is either manually
configured or signaled from the upper layer.

Regards,
Brian

On 1/28/14 5:33 PM, h chan wrote:
> Let us try to include MR= .
>
> How about the following
>
> =A0 =A0REQ2: =A0Network-layer mobility support when needed
>
> =A0 =A0 =A0 =A0 =A0 DMM solutions MUST enable network-layer
> =A0 =A0 =A0 =A0 =A0 mobility when needed.
> =A0 =A0 =A0 =A0 =A0 Such mobility support is needed, for
> =A0 =A0 =A0 =A0 =A0 example, when an application or a host cannot cope= with a change in the
> =A0 =A0 =A0 =A0 =A0 IP address when a node moves. =A0However, it is no= t always necessary to maintain a
> =A0 =A0 =A0 =A0 =A0 stable IP address or prefix.
>
> Here, the node can be a mobile host or a mobile router.
> A host can be a mobile host or a host in a LFN.
> An application can be running on a mobile host or a on a host in a LFN= .
> A MR also does not need to maintain stable IP address or prefix when t= here are no hosts attached to it or when there are no active applications r= unning in the hosts of its network.
>
> Any comments/changes/corrections?
>
> H Anthony Chan
>
>
> -----Original Message-----
> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
> Sent: Tuesday, January 28, 2014 1:27 PM
> To: h chan; dmm@ietf.org
> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
>
> Le 28/01/2014 19:58, h chan a =E9crit :
>> Let me try to understand the concern here.
>>
>> What is new in this requirement is "when needed" in cont= rast to
>> providing IP mobility by default.
>
> First, providing mobility by default is not a black/white alternative = to not providing mobility.
>
> It is very possible on the same machine to have Mobile IP enabled for = some flows and disabled for others (depending what we call a 'flow'= ).
> It is also possible to have Mobile IP and NAT at the same time on the = same Mobile Router.
>
>> Without this requirement, mobility support may be provided by defa= ult,
>> which is transparent to higher layers.
>
> Again, transparency to higher layers means we talk mobility management= on a Mobile Host.
>
> Transparency to higher layers has little meaning if we talk mobility m= anagement provided on a Mobile Router (which is not a Mobile Host).
>
>> With this requirement, assume there are separate steps in the DMM<= br> >> solution. 1. A decision is made whether network-layer mobility sup= port
>> is needed. 2. When the need is established, network-layer mobility=
>> support is invoked. 3. Then transparent support is provided =A0and= is
>> transparent to layers above IP.
>>
>> Transparency is clear in step 3 above.
>
> This looks like a trigger which enables mobility, or other times disab= les it.
>
> But one can have a Mobile IP daemon and a NAT run at the same time on = the same machine. =A0There is no decision in time.
>
> Some decision happens at packet based on IP destination address.
>
>> The question however is whether the preceding steps involve the >> application, so that one may question whether the entire DMM solut= ion
>> (with all the steps) as a whole is transparent.
>
> I agree. =A0I am not aware of any application which talks to Mobile IP= .
> Whenever it is there it is 'transparent'.
>
>> So the intention of the requirement is that WHEN/AFTER the decisio= n is
>> made to invoke mobility support, then the mobility support is
>> transparent to the application. Then we may want to check and make=
>> sure the emphasis of this requirement does mean transparency in th= is
>> respect only.
>
> I disagree.
>
> As I said above, the word 'transparency' is dubious. =A0Some t= imes it may mean 'non-existent', some times it may mean light goes = through it but modified.
>
> If one wants to continue using it, then one should better qualify it w= ith 'Mobile Host', with 'Upper Layers' and with 'BSD So= cket Interface'.
>
> Because a Mobile Router doing mobility management in a transparent man= ner on the Mobile Router for the LFN has nothing to do with applications, n= either with upper layers.
>
> Also, a Mobile Router doing NAT and Mobile IP at the same time is 50%-= transparent.
>
>>
>> Original wording:
>>
>> REQ2: =A0Transparency to Upper Layers when needed
>>
>> DMM solutions MUST provide transparent mobility support above the = IP
>> layer when needed. =A0Such transparency is needed, for example, wh= en,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^on a Mobile Host.
>> upon change of point of attachment to the network, an application = flow
>> cannot cope with a change in the IP address.
>
> (it's not the application flow, it is a socket which some times ma= y break [paste here the error from the screen]; the term 'application f= low' in this context has little meaning)
>
> (an 'application flow' has no understandable meaning in practi= ce).
>
>> However, it is not always necessary to maintain a stable home IP >> address or prefix for every application or at all times for a mobi= le
>> node.
> =A0 =A0 =A0 =A0^a Mobile Host.
>
> I agree.
>
>> I now tend to think the first sentence in this original wording ma= y
>> steer the emphasis on providing transparent support, which is not = what
>> the motivation and the problems are talking about.
>
> I agree.
>
>> The motivation and the problems are talking about when they are no= t
>> needed. The emphasis of this requirement therefore is on the
>> capability to turn OFF unnecessary mobility support.
>
> In a sense I agree with the meaning.
>
> But when trying to turn off or on mobility support the things are not = like if there were a knob on/off, not even like starting/stopping some daem= on. =A0It is a matter of always having the Mobile IP support on, and tweak = the routing table with some particular entries, and the firewalling rules t= o NAT some addresses or not.
>
>> How about the following
>>
>> REQ2: =A0Network-layer mobility support ONLY when needed
>
> If we understood better when it was needed...
>
>> DMM solutions MUST NOT provide network-layer mobility support when= NOT
>> needed.
>
> I would say that Mobile IP MUST always be turned on on a Mobile Host.<= br> >
>> (or if you don't like double negatives: (DMM solutions MUST pr= ovide
>> network-layer mobility support ONLY when needed)
>
> No, I would say to have it always on. =A0If some applications don'= t want it then dont use it; realize that by inserting routing table entries= .
>
> One may wonder when some applications dont want it. =A0One answer is w= hen some applications prefer to not go through the HA in order to take adva= ntage of the 4G pure speed. =A0When? For example if the HA link is too slow= compared to 4G. =A0(remark this is not the same as saying that the triangu= lar route is longer than straight, because that is always true).
>
> This is not a request for Route Optimization. =A0It is an invitation t= o analyze in deeper detail the application needs.
>
> One may have an application start via the HA (offer reachability) and = continue straight, w/o HA. =A0It's the same application.
>
> Consider a video-call like appli: you want to be reachable always at t= he same IP address (through HA) but once the session is ongoing you may not= want to use it through HA if no handover in sight.
>
> Something like that.
>
> These things could be further refined if we really went into detail an= d understood what are the needs of applications, the distinctions MH-MR, et= c.
>
>> Such transparent mobility support above the IP layer is needed, fo= r
>> example, when, upon change of point of attachment to the network, = an
>> application flow cannot cope with a change in the IP address.
>> However, it is not always necessary to maintain a stable home IP >> address or prefix for every application or at all times for a mobi= le
>> node.
>
> A Mobile Host never maintains a stable prefix, only a stable address.<= br> >
> A Mobile Router may maintain a stable address (its HoA) and may mainta= in a stable prefix =A0(its MNP). =A0It could also just maintain stable just= its MNP, but not its HoA; and vice-versa. =A0Is that mobility?
>
> For each of these there is an application :-)
>
> Alex
>
>>
>> Any comments/changes/corrections?
>>
>> H Anthony Chan
>>
>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On
>> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 = AM
>> To: dmm@ietf.org Subject: Re: = [DMM] AD Evaluation:
>> draft-ietf-dmm-requirements
>>
>> Le 28/01/2014 02:45, h chan a =E9crit :
>>> I will drop "related"
>>>
>>> Regarding the following
>>>
>>> 5. Section 5: - I am a little confused by REQ2. =A0It says tha= t a DMM
>>> solution should be transparent to the applications.
>>
>> This remark is typically true when we talk Mobile IP on a Mobile H= ost
>> and an application like firefox runs above a BSD Socket interface.=
>>
>>
>>> However, the motivation talks about identifying applications t= hat do
>>> (or do not) need mobility support from the network layer. =A0T= hat
>>> doesn't sound transparent to me. =A0Am I reading this inco= rrectly?
>>>
>>> It appears that unless the network can find out whether the >>> application has need of such support, the application indeed m= ay need
>>> to invoke mobility support or has to convey its need to the ne= twork.
>>>
>>> The emphasis of requirement is on "when needed." So,= I think it is
>>> better to drop the word "transparent" as follows: >>>
>>> REQ2: =A0Mobility support when needed
>>>
>>> DMM solutions MUST provide mobility support to above the IP la= yer
>>> when needed. =A0Such support is needed, for example, when, upo= n change
>>> of point of attachment to the network, an application flow can= not
>>> cope with a change in the IP address. =A0However, it is not al= ways
>>> necessary to maintain a stable home IP address or prefix for e= very
>>> application or at all times for a mobile node.
>>>
>>> Motivation: The motivation of this requirement is to enable mo= re
>>> efficient routing and more efficient use of network resources = by
>>> selecting an IP address or prefix according to whether mobilit= y
>>> support is needed and by not maintaining context at the mobili= ty
>>> anchor when there is no such need.
>>
>> Whenever we discuss this 'transparency' paragraph I have a= gain the
>> same comments.
>>
>> First, I am not sure DMM is only about Mobile Hosts, or about Mobi= le
>> Routers as well.
>>
>> Because, if we talk Mobile Routers, then rarely an application run= s
>> directly on it. =A0Most applications would run on LFN.
>>
>> Transparency?
>>
>> If the applications run on the LFN, the change of the attachment o= f
>> the MR is 'transparent' to them, regardless whether or not= MR does
>> something to maintain stability of that address (Mobile IP, other)= .
>>
>> Second, this transparency may depend on the direction, or more com= plex
>> 'shape' of the application flows. =A0Some IP flows of some= applications
>> have very complex 'shapes', with various sets of IP src = =A0and dst, and
>> triangular or HA-less shapes.
>>
>> Take for example a video-call. =A0The session establishment throug= h an
>> intermediary and behind NAT is followed by the ongoing 4 flows (2<= br> >> audio 2 video)... they all take different paths... each may need o= r
>> not need to go through the HA, and each has distinct behaviours wh= en
>> the IP address changes, hence each would have a distinct
>> 'transparency' requirement. =A0Is this _one_ application?<= br> >>
>> Alex
>>
>>>
>>> H Anthony Chan
>>>
>>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org]
>>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:2= 0 AM
>>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org;
>>> dmm@ietf.org; Peter McCann= Subject: Re: [DMM] AD Evaluation:
>>> draft-ietf-dmm-requirements
>>>
>>>
>>>
>>> On 1/24/14 7:38 PM, h chan wrote:
>>>> 4. Section 4: - I am not sure that it benefits the documen= t to label
>>>> PS6 and PS7 as related. =A0Those issues are problematic on= their own.
>>>> If you remove the "(related problem)" label from= them, make sure
>>>> that REQ2 is updated to remove mention of "related pr= oblem".
>>>>
>>>> The intention of the name "related problems" was= not to suggest they
>>>> are less problematic, but rather to distinguish them from = the other
>>>> problems directly on mobility management. Although these p= roblems
>>>> are not directly on mobility management, the DMM solutions= can solve
>>>> these additional problems. They are therefore included. So= , as long
>>>> as this section is not to be interpreted as limited to pro= blems
>>>> directly on mobility management, we can drop the word &quo= t;related."
>>>>
>>>
>>> I will leave it to the authors/WG, but I don't see a benef= it to the
>>> "related" tag.
>>>
>>> Regards, Brian
>>>
>>> _______________________________________________ dmm mailing li= st
>>> 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
htt= ps://www.ietf.org/mailman/listinfo/dmm


--001a11c2f58e4e39dd04f11f1e8d-- From alexandru.petrescu@gmail.com Wed Jan 29 10:30:30 2014 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 804891A029B for ; Wed, 29 Jan 2014 10:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 zSFCSNcEv2KM for ; Wed, 29 Jan 2014 10:30:25 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 523211A021B for ; Wed, 29 Jan 2014 10:30:24 -0800 (PST) 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 s0TIUGjs006759; Wed, 29 Jan 2014 19:30:16 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9E422205CA3; Wed, 29 Jan 2014 19:30: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 921E5205C9A; Wed, 29 Jan 2014 19:30:26 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0TIU8d5016138; Wed, 29 Jan 2014 19:30:16 +0100 Message-ID: <52E948AC.6030904@gmail.com> Date: Wed, 29 Jan 2014 19:30:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "dmm@ietf.org" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 18:30:30 -0000 Le 28/01/2014 23:33, h chan a écrit : > Let us try to include MR. > > How about the following > > REQ2: Network-layer mobility support when needed > > DMM solutions MUST enable network-layer > mobility when needed. > Such mobility support is needed, for > example, when an application or a host cannot cope with a change in the > IP address when a node moves. However, it is not always necessary to maintain a > stable IP address or prefix. > > Here, the node can be a mobile host or a mobile router. I am not sure the term 'node' is agreed to cover both an MH and an MR. I think in all descriptions it would be clearer if we just said MH when we meant Mobile Host and MR when we meant Mobile Router. Le me paraphrase this text in RFC6275: > This document specifies a protocol that allows nodes to remain > reachable while moving around in the IPv6 Internet. Without specific > support for mobility in IPv6 [6], packets destined to a mobile node > would not be able to reach it while the mobile node is away from its > home link. There is a clear ambiguity in the 'mobile node' used above. Because if we talk moving networks then often the packets are destined (the contents of the destination address) to a LFN, not to the MR. If that 'node' were a Mobile Router (not a Mobile Host) it completely misses the case when packets are destined to the LFN, which is not an MH nor an MR. The phrase should rather say: 'packets destined to a MH (or to a LFN behind a MR) would not be able to reach it while that MH (or the MR and LFN) is away from its home link.' This kind if expression would be clearer. Alex 'packets destined to a [LFN] or to the Mobile Host, or to the Mobile Router, would not be able to reach it while the Mobile Router is away from its home link'. > A host can be a mobile host or a host in a LFN. > An application can be running on a mobile host or a on a host in a LFN. > A MR also does not need to maintain stable IP address or prefix when there are no hosts attached to it or when there are no active applications running in the hosts of its network. > > Any comments/changes/corrections? > > H Anthony Chan > > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, January 28, 2014 1:27 PM > To: h chan; dmm@ietf.org > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements > > Le 28/01/2014 19:58, h chan a écrit : >> Let me try to understand the concern here. >> >> What is new in this requirement is "when needed" in contrast to >> providing IP mobility by default. > > First, providing mobility by default is not a black/white alternative to not providing mobility. > > It is very possible on the same machine to have Mobile IP enabled for some flows and disabled for others (depending what we call a 'flow'). > It is also possible to have Mobile IP and NAT at the same time on the same Mobile Router. > >> Without this requirement, mobility support may be provided by default, >> which is transparent to higher layers. > > Again, transparency to higher layers means we talk mobility management on a Mobile Host. > > Transparency to higher layers has little meaning if we talk mobility management provided on a Mobile Router (which is not a Mobile Host). > >> With this requirement, assume there are separate steps in the DMM >> solution. 1. A decision is made whether network-layer mobility support >> is needed. 2. When the need is established, network-layer mobility >> support is invoked. 3. Then transparent support is provided and is >> transparent to layers above IP. >> >> Transparency is clear in step 3 above. > > This looks like a trigger which enables mobility, or other times disables it. > > But one can have a Mobile IP daemon and a NAT run at the same time on the same machine. There is no decision in time. > > Some decision happens at packet based on IP destination address. > >> The question however is whether the preceding steps involve the >> application, so that one may question whether the entire DMM solution >> (with all the steps) as a whole is transparent. > > I agree. I am not aware of any application which talks to Mobile IP. > Whenever it is there it is 'transparent'. > >> So the intention of the requirement is that WHEN/AFTER the decision is >> made to invoke mobility support, then the mobility support is >> transparent to the application. Then we may want to check and make >> sure the emphasis of this requirement does mean transparency in this >> respect only. > > I disagree. > > As I said above, the word 'transparency' is dubious. Some times it may mean 'non-existent', some times it may mean light goes through it but modified. > > If one wants to continue using it, then one should better qualify it with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'. > > Because a Mobile Router doing mobility management in a transparent manner on the Mobile Router for the LFN has nothing to do with applications, neither with upper layers. > > Also, a Mobile Router doing NAT and Mobile IP at the same time is 50%-transparent. > >> >> Original wording: >> >> REQ2: Transparency to Upper Layers when needed >> >> DMM solutions MUST provide transparent mobility support above the IP >> layer when needed. Such transparency is needed, for example, when, > ^on a Mobile Host. >> upon change of point of attachment to the network, an application flow >> cannot cope with a change in the IP address. > > (it's not the application flow, it is a socket which some times may break [paste here the error from the screen]; the term 'application flow' in this context has little meaning) > > (an 'application flow' has no understandable meaning in practice). > >> However, it is not always necessary to maintain a stable home IP >> address or prefix for every application or at all times for a mobile >> node. > ^a Mobile Host. > > I agree. > >> I now tend to think the first sentence in this original wording may >> steer the emphasis on providing transparent support, which is not what >> the motivation and the problems are talking about. > > I agree. > >> The motivation and the problems are talking about when they are not >> needed. The emphasis of this requirement therefore is on the >> capability to turn OFF unnecessary mobility support. > > In a sense I agree with the meaning. > > But when trying to turn off or on mobility support the things are not like if there were a knob on/off, not even like starting/stopping some daemon. It is a matter of always having the Mobile IP support on, and tweak the routing table with some particular entries, and the firewalling rules to NAT some addresses or not. > >> How about the following >> >> REQ2: Network-layer mobility support ONLY when needed > > If we understood better when it was needed... > >> DMM solutions MUST NOT provide network-layer mobility support when NOT >> needed. > > I would say that Mobile IP MUST always be turned on on a Mobile Host. > >> (or if you don't like double negatives: (DMM solutions MUST provide >> network-layer mobility support ONLY when needed) > > No, I would say to have it always on. If some applications don't want it then dont use it; realize that by inserting routing table entries. > > One may wonder when some applications dont want it. One answer is when some applications prefer to not go through the HA in order to take advantage of the 4G pure speed. When? For example if the HA link is too slow compared to 4G. (remark this is not the same as saying that the triangular route is longer than straight, because that is always true). > > This is not a request for Route Optimization. It is an invitation to analyze in deeper detail the application needs. > > One may have an application start via the HA (offer reachability) and continue straight, w/o HA. It's the same application. > > Consider a video-call like appli: you want to be reachable always at the same IP address (through HA) but once the session is ongoing you may not want to use it through HA if no handover in sight. > > Something like that. > > These things could be further refined if we really went into detail and understood what are the needs of applications, the distinctions MH-MR, etc. > >> Such transparent mobility support above the IP layer is needed, for >> example, when, upon change of point of attachment to the network, an >> application flow cannot cope with a change in the IP address. >> However, it is not always necessary to maintain a stable home IP >> address or prefix for every application or at all times for a mobile >> node. > > A Mobile Host never maintains a stable prefix, only a stable address. > > A Mobile Router may maintain a stable address (its HoA) and may maintain a stable prefix (its MNP). It could also just maintain stable just its MNP, but not its HoA; and vice-versa. Is that mobility? > > For each of these there is an application :-) > > Alex > >> >> Any comments/changes/corrections? >> >> H Anthony Chan >> >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On >> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM >> To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: >> draft-ietf-dmm-requirements >> >> Le 28/01/2014 02:45, h chan a écrit : >>> I will drop "related" >>> >>> Regarding the following >>> >>> 5. Section 5: - I am a little confused by REQ2. It says that a DMM >>> solution should be transparent to the applications. >> >> This remark is typically true when we talk Mobile IP on a Mobile Host >> and an application like firefox runs above a BSD Socket interface. >> >> >>> However, the motivation talks about identifying applications that do >>> (or do not) need mobility support from the network layer. That >>> doesn't sound transparent to me. Am I reading this incorrectly? >>> >>> It appears that unless the network can find out whether the >>> application has need of such support, the application indeed may need >>> to invoke mobility support or has to convey its need to the network. >>> >>> The emphasis of requirement is on "when needed." So, I think it is >>> better to drop the word "transparent" as follows: >>> >>> REQ2: Mobility support when needed >>> >>> DMM solutions MUST provide mobility support to above the IP layer >>> when needed. Such support is needed, for example, when, upon change >>> of point of attachment to the network, an application flow cannot >>> cope with a change in the IP address. However, it is not always >>> necessary to maintain a stable home IP address or prefix for every >>> application or at all times for a mobile node. >>> >>> Motivation: The motivation of this requirement is to enable more >>> efficient routing and more efficient use of network resources by >>> selecting an IP address or prefix according to whether mobility >>> support is needed and by not maintaining context at the mobility >>> anchor when there is no such need. >> >> Whenever we discuss this 'transparency' paragraph I have again the >> same comments. >> >> First, I am not sure DMM is only about Mobile Hosts, or about Mobile >> Routers as well. >> >> Because, if we talk Mobile Routers, then rarely an application runs >> directly on it. Most applications would run on LFN. >> >> Transparency? >> >> If the applications run on the LFN, the change of the attachment of >> the MR is 'transparent' to them, regardless whether or not MR does >> something to maintain stability of that address (Mobile IP, other). >> >> Second, this transparency may depend on the direction, or more complex >> 'shape' of the application flows. Some IP flows of some applications >> have very complex 'shapes', with various sets of IP src and dst, and >> triangular or HA-less shapes. >> >> Take for example a video-call. The session establishment through an >> intermediary and behind NAT is followed by the ongoing 4 flows (2 >> audio 2 video)... they all take different paths... each may need or >> not need to go through the HA, and each has distinct behaviours when >> the IP address changes, hence each would have a distinct >> 'transparency' requirement. Is this _one_ application? >> >> Alex >> >>> >>> H Anthony Chan >>> >>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM >>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; >>> dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: >>> draft-ietf-dmm-requirements >>> >>> >>> >>> On 1/24/14 7:38 PM, h chan wrote: >>>> 4. Section 4: - I am not sure that it benefits the document to label >>>> PS6 and PS7 as related. Those issues are problematic on their own. >>>> If you remove the "(related problem)" label from them, make sure >>>> that REQ2 is updated to remove mention of "related problem". >>>> >>>> The intention of the name "related problems" was not to suggest they >>>> are less problematic, but rather to distinguish them from the other >>>> problems directly on mobility management. Although these problems >>>> are not directly on mobility management, the DMM solutions can solve >>>> these additional problems. They are therefore included. So, as long >>>> as this section is not to be interpreted as limited to problems >>>> directly on mobility management, we can drop the word "related." >>>> >>> >>> I will leave it to the authors/WG, but I don't see a benefit to the >>> "related" tag. >>> >>> 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 h.anthony.chan@huawei.com Wed Jan 29 10:52:04 2014 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 837FA1A0427 for ; Wed, 29 Jan 2014 10:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.736 X-Spam-Level: X-Spam-Status: No, score=-6.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 LD80IUeS3J7p for ; Wed, 29 Jan 2014 10:51:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE01A0349 for ; Wed, 29 Jan 2014 10:51:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDB47032; Wed, 29 Jan 2014 18:51:54 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 18:51:32 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 18:51:52 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Thu, 30 Jan 2014 02:51:47 +0800 From: h chan To: Brian Haberman , Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHP4JUDRM/D4D+0qcQX/R2VnzsJqb8H6w Date: Wed, 29 Jan 2014 18:51:46 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB829@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E90F7A.3050902@innovationslab.net> In-Reply-To: <52E90F7A.3050902@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 18:52:04 -0000 Brian, The requirement is intended to include a capability of not using network-la= yer mobility management, as opposed to using it by default. =20 I think it is sufficient to leave to the explanation (the sentences after t= he first sentence) to say that network-layer mobility support is not always= needed in order to justify this capability.=20 The alternative then is to say that network-layer mobility is provided but = it is possible to not use such support.=20 REQ2: Using and not Using Network-layer mobility support =20 DMM solutions MUST enable network-layer mobility but it MUST be possible to not invoke it. Mobility support is needed, for example,=20 when an application or a host=20 cannot cope with a change in the IP address when a node moves. =20 Yet a mobile node can often be stationary, and mobility support can also be provided at other layers. It is then not always necessary to maintain a stable IP address or prefix. Of cause "enable" does not mean it must be used. Yet explicitly say "it is = possible to not invoke it" is to draw the contrast to using it by default. H Anthony Chan -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: Wednesday, January 29, 2014 8:26 AM To: h chan; Alexandru Petrescu; dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Anthony, Does this requirement also include a way for the application (or trans= port protocol) to request/refuse mobility support? The "when needed" impli= es some type of knowledge that is either manually configured or signaled fr= om the upper layer. Regards, Brian On 1/28/14 5:33 PM, h chan wrote: > Let us try to include MR. =20 >=20 > How about the following >=20 > REQ2: Network-layer mobility support when needed > =20 > DMM solutions MUST enable network-layer=20 > mobility when needed. > Such mobility support is needed, for > example, when an application or a host cannot cope with a chang= e in the > IP address when a node moves. However, it is not always necess= ary to maintain a > stable IP address or prefix. >=20 > Here, the node can be a mobile host or a mobile router.=20 > A host can be a mobile host or a host in a LFN.=20 > An application can be running on a mobile host or a on a host in a LFN. > A MR also does not need to maintain stable IP address or prefix when ther= e are no hosts attached to it or when there are no active applications runn= ing in the hosts of its network.=20 >=20 > Any comments/changes/corrections? >=20 > H Anthony Chan >=20 >=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, January 28, 2014 1:27 PM > To: h chan; dmm@ietf.org > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements >=20 > Le 28/01/2014 19:58, h chan a =E9crit : >> Let me try to understand the concern here. >> >> What is new in this requirement is "when needed" in contrast to=20 >> providing IP mobility by default. >=20 > First, providing mobility by default is not a black/white alternative to = not providing mobility. >=20 > It is very possible on the same machine to have Mobile IP enabled for som= e flows and disabled for others (depending what we call a 'flow').=20 > It is also possible to have Mobile IP and NAT at the same time on the sam= e Mobile Router. >=20 >> Without this requirement, mobility support may be provided by=20 >> default, which is transparent to higher layers. >=20 > Again, transparency to higher layers means we talk mobility management on= a Mobile Host. >=20 > Transparency to higher layers has little meaning if we talk mobility mana= gement provided on a Mobile Router (which is not a Mobile Host). >=20 >> With this requirement, assume there are separate steps in the DMM=20 >> solution. 1. A decision is made whether network-layer mobility=20 >> support is needed. 2. When the need is established, network-layer=20 >> mobility support is invoked. 3. Then transparent support is provided =20 >> and is transparent to layers above IP. >> >> Transparency is clear in step 3 above. >=20 > This looks like a trigger which enables mobility, or other times disables= it. >=20 > But one can have a Mobile IP daemon and a NAT run at the same time on the= same machine. There is no decision in time. >=20 > Some decision happens at packet based on IP destination address. >=20 >> The question however is whether the preceding steps involve the=20 >> application, so that one may question whether the entire DMM solution=20 >> (with all the steps) as a whole is transparent. >=20 > I agree. I am not aware of any application which talks to Mobile IP.=20 > Whenever it is there it is 'transparent'. >=20 >> So the intention of the requirement is that WHEN/AFTER the decision=20 >> is made to invoke mobility support, then the mobility support is=20 >> transparent to the application. Then we may want to check and make=20 >> sure the emphasis of this requirement does mean transparency in this=20 >> respect only. >=20 > I disagree. >=20 > As I said above, the word 'transparency' is dubious. Some times it may m= ean 'non-existent', some times it may mean light goes through it but modifi= ed. >=20 > If one wants to continue using it, then one should better qualify it with= 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'. >=20 > Because a Mobile Router doing mobility management in a transparent manner= on the Mobile Router for the LFN has nothing to do with applications, neit= her with upper layers. >=20 > Also, a Mobile Router doing NAT and Mobile IP at the same time is 50%-tra= nsparent. >=20 >> >> Original wording: >> >> REQ2: Transparency to Upper Layers when needed >> >> DMM solutions MUST provide transparent mobility support above the IP=20 >> layer when needed. Such transparency is needed, for example, when, > ^on a Mobile Host. >> upon change of point of attachment to the network, an application=20 >> flow cannot cope with a change in the IP address. >=20 > (it's not the application flow, it is a socket which some times may=20 > break [paste here the error from the screen]; the term 'application=20 > flow' in this context has little meaning) >=20 > (an 'application flow' has no understandable meaning in practice). >=20 >> However, it is not always necessary to maintain a stable home IP=20 >> address or prefix for every application or at all times for a mobile=20 >> node. > ^a Mobile Host. >=20 > I agree. >=20 >> I now tend to think the first sentence in this original wording may=20 >> steer the emphasis on providing transparent support, which is not=20 >> what the motivation and the problems are talking about. >=20 > I agree. >=20 >> The motivation and the problems are talking about when they are not=20 >> needed. The emphasis of this requirement therefore is on the=20 >> capability to turn OFF unnecessary mobility support. >=20 > In a sense I agree with the meaning. >=20 > But when trying to turn off or on mobility support the things are not lik= e if there were a knob on/off, not even like starting/stopping some daemon.= It is a matter of always having the Mobile IP support on, and tweak the r= outing table with some particular entries, and the firewalling rules to NAT= some addresses or not. >=20 >> How about the following >> >> REQ2: Network-layer mobility support ONLY when needed >=20 > If we understood better when it was needed... >=20 >> DMM solutions MUST NOT provide network-layer mobility support when=20 >> NOT needed. >=20 > I would say that Mobile IP MUST always be turned on on a Mobile Host. >=20 >> (or if you don't like double negatives: (DMM solutions MUST provide=20 >> network-layer mobility support ONLY when needed) >=20 > No, I would say to have it always on. If some applications don't want it= then dont use it; realize that by inserting routing table entries. >=20 > One may wonder when some applications dont want it. One answer is when s= ome applications prefer to not go through the HA in order to take advantage= of the 4G pure speed. When? For example if the HA link is too slow compar= ed to 4G. (remark this is not the same as saying that the triangular route= is longer than straight, because that is always true). >=20 > This is not a request for Route Optimization. It is an invitation to ana= lyze in deeper detail the application needs. >=20 > One may have an application start via the HA (offer reachability) and con= tinue straight, w/o HA. It's the same application. >=20 > Consider a video-call like appli: you want to be reachable always at the = same IP address (through HA) but once the session is ongoing you may not wa= nt to use it through HA if no handover in sight. >=20 > Something like that. >=20 > These things could be further refined if we really went into detail and u= nderstood what are the needs of applications, the distinctions MH-MR, etc. >=20 >> Such transparent mobility support above the IP layer is needed, for=20 >> example, when, upon change of point of attachment to the network, an=20 >> application flow cannot cope with a change in the IP address. >> However, it is not always necessary to maintain a stable home IP=20 >> address or prefix for every application or at all times for a mobile=20 >> node. >=20 > A Mobile Host never maintains a stable prefix, only a stable address. >=20 > A Mobile Router may maintain a stable address (its HoA) and may maintain = a stable prefix (its MNP). It could also just maintain stable just its MN= P, but not its HoA; and vice-versa. Is that mobility? >=20 > For each of these there is an application :-) >=20 > Alex >=20 >> >> Any comments/changes/corrections? >> >> H Anthony Chan >> >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On=20 >> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM >> To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: >> draft-ietf-dmm-requirements >> >> Le 28/01/2014 02:45, h chan a =E9crit : >>> I will drop "related" >>> >>> Regarding the following >>> >>> 5. Section 5: - I am a little confused by REQ2. It says that a DMM=20 >>> solution should be transparent to the applications. >> >> This remark is typically true when we talk Mobile IP on a Mobile Host=20 >> and an application like firefox runs above a BSD Socket interface. >> >> >>> However, the motivation talks about identifying applications that do=20 >>> (or do not) need mobility support from the network layer. That=20 >>> doesn't sound transparent to me. Am I reading this incorrectly? >>> >>> It appears that unless the network can find out whether the=20 >>> application has need of such support, the application indeed may=20 >>> need to invoke mobility support or has to convey its need to the networ= k. >>> >>> The emphasis of requirement is on "when needed." So, I think it is=20 >>> better to drop the word "transparent" as follows: >>> >>> REQ2: Mobility support when needed >>> >>> DMM solutions MUST provide mobility support to above the IP layer=20 >>> when needed. Such support is needed, for example, when, upon change=20 >>> of point of attachment to the network, an application flow cannot=20 >>> cope with a change in the IP address. However, it is not always=20 >>> necessary to maintain a stable home IP address or prefix for every=20 >>> application or at all times for a mobile node. >>> >>> Motivation: The motivation of this requirement is to enable more=20 >>> efficient routing and more efficient use of network resources by=20 >>> selecting an IP address or prefix according to whether mobility=20 >>> support is needed and by not maintaining context at the mobility=20 >>> anchor when there is no such need. >> >> Whenever we discuss this 'transparency' paragraph I have again the=20 >> same comments. >> >> First, I am not sure DMM is only about Mobile Hosts, or about Mobile=20 >> Routers as well. >> >> Because, if we talk Mobile Routers, then rarely an application runs=20 >> directly on it. Most applications would run on LFN. >> >> Transparency? >> >> If the applications run on the LFN, the change of the attachment of=20 >> the MR is 'transparent' to them, regardless whether or not MR does=20 >> something to maintain stability of that address (Mobile IP, other). >> >> Second, this transparency may depend on the direction, or more=20 >> complex 'shape' of the application flows. Some IP flows of some=20 >> applications have very complex 'shapes', with various sets of IP src =20 >> and dst, and triangular or HA-less shapes. >> >> Take for example a video-call. The session establishment through an=20 >> intermediary and behind NAT is followed by the ongoing 4 flows (2=20 >> audio 2 video)... they all take different paths... each may need or=20 >> not need to go through the HA, and each has distinct behaviours when=20 >> the IP address changes, hence each would have a distinct=20 >> 'transparency' requirement. Is this _one_ application? >> >> Alex >> >>> >>> H Anthony Chan >>> >>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org]=20 >>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM >>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; >>> dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: >>> draft-ietf-dmm-requirements >>> >>> >>> >>> On 1/24/14 7:38 PM, h chan wrote: >>>> 4. Section 4: - I am not sure that it benefits the document to=20 >>>> label >>>> PS6 and PS7 as related. Those issues are problematic on their own.=20 >>>> If you remove the "(related problem)" label from them, make sure=20 >>>> that REQ2 is updated to remove mention of "related problem". >>>> >>>> The intention of the name "related problems" was not to suggest=20 >>>> they are less problematic, but rather to distinguish them from the=20 >>>> other problems directly on mobility management. Although these=20 >>>> problems are not directly on mobility management, the DMM solutions=20 >>>> can solve these additional problems. They are therefore included.=20 >>>> So, as long as this section is not to be interpreted as limited to=20 >>>> problems directly on mobility management, we can drop the word "relate= d." >>>> >>> >>> I will leave it to the authors/WG, but I don't see a benefit to the=20 >>> "related" tag. >>> >>> Regards, Brian >>> >>> _______________________________________________ dmm mailing list=20 >>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>> >>> >> >> >> _______________________________________________ dmm mailing list=20 >> 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 >=20 From h.anthony.chan@huawei.com Wed Jan 29 10:54:16 2014 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 D14751A0427 for ; Wed, 29 Jan 2014 10:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 zX0dgAQ21ufQ for ; Wed, 29 Jan 2014 10:54:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 802471A0442 for ; Wed, 29 Jan 2014 10:54:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAP51597; Wed, 29 Jan 2014 18:54:11 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 18:53:49 +0000 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 18:54:10 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Thu, 30 Jan 2014 02:53:57 +0800 From: h chan To: Brian Haberman , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHPqPUDRM/D4D+0qcQX/R2VnzsJqcDJMw Date: Wed, 29 Jan 2014 18:53:58 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB82F@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB641@szxeml557-mbx.china.huawei.com> <52E909A6.80008@innovationslab.net> In-Reply-To: <52E909A6.80008@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 18:54:17 -0000 Delete those explanatory sentences then. REQ5: Co-existence with deployed networks and hosts The DMM solution MUST be able to co-exist with existing network deployments and end hosts. =20 Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. H Anthony Chan -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: Wednesday, January 29, 2014 8:01 AM To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter= McCann Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements On 1/28/14 4:33 PM, h chan wrote: > Regarding the following: >=20 > - What is meant by co-exist in REQ5? Does this mean that a DMM solution = does not break an existing one? Or does it mean that it must inter-operate= with existing ones? Is this like IPv4 and IPv6 being incompatible, but ca= n run concurrently on the same network? Or does this mean there needs to b= e some mechanism for interaction (i.e., like NAT64)? >=20 >=20 >=20 > I think the bottom line is that the existing ones do not break. >=20 >=20 >=20 > Original >=20 > REQ5: Co-existence with deployed networks and hosts >=20 >=20 >=20 > The DMM solution MUST be able to co-exist with existing >=20 > network deployments and end hosts. For example, depending=20 > on >=20 > the environment in which DMM is deployed, DMM solutions may >=20 > need to be compatible with other deployed mobility protocols >=20 > or may need to co-exist with a network or mobile=20 > hosts/routers >=20 > that do not support DMM protocols. The mobile node may also >=20 > move between different access networks, where some of them=20 > may >=20 > support neither DMM nor another mobility protocol. >=20 > Furthermore, a DMM solution SHOULD work across different >=20 > networks, possibly operated as separate administrative >=20 > domains, when allowed by the trust relationship between them. >=20 >=20 >=20 > We can change to: >=20 > REQ5: Co-existence with deployed networks and hosts >=20 >=20 >=20 > The DMM solution MUST be able to co-exist with existing >=20 > network deployments and end hosts without breaking them. =20 > For example, depending on >=20 > the environment in which DMM is deployed, DMM solutions may >=20 > need to be compatible with other deployed mobility protocols >=20 > or may need to co-exist with a network or mobile=20 > hosts/routers >=20 > that do not support DMM protocols. The mobile node may also >=20 > move between different access networks, where some of them=20 > may >=20 > support neither DMM nor another mobility protocol. >=20 > Furthermore, a DMM solution SHOULD work across different >=20 > networks, possibly operated as separate administrative >=20 > domains, when allowed by the trust relationship between them. The "without breaking" is fine. However, the "need to be compatible with" = phrasing is still problematic. Is that inferring that in some situations t= hat a DMM solution would need to interact with, for example, PMIP? Regards, Brian From h.anthony.chan@huawei.com Wed Jan 29 11:45:44 2014 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 906B41A03CB for ; Wed, 29 Jan 2014 11:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.735 X-Spam-Level: X-Spam-Status: No, score=-6.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 7UVTtUtVgqZ2 for ; Wed, 29 Jan 2014 11:45:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDC51A02F2 for ; Wed, 29 Jan 2014 11:45:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDB49370; Wed, 29 Jan 2014 19:45:33 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 19:45:10 +0000 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 19:45:30 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.03.0158.001; Thu, 30 Jan 2014 03:45:27 +0800 From: h chan To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHSAzerijAOFCOEqVm7RJs+G8WJqcFyvw Date: Wed, 29 Jan 2014 19:45:27 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB866@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E948AC.6030904@gmail.com> In-Reply-To: <52E948AC.6030904@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.225] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370EB866szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 29 Jan 2014 19:45:44 -0000 --_000_6E31144C030982429702B11D6746B98C370EB866szxeml557mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex How about the following: REQ2: Using and not Using Network-layer mobility support DMM solutions MUST enable network-layer mobility but it MUST be possible to not invoke it. Mobility support is needed, for example, when an application (of a MN or a host in a mobile network of a = MR) cannot cope with a change in the IP address of the mobile node when the node moves. Yet a mobile node can often be stationary, and mobility support can also be provided at other layers. It is then not always necessary to maintain a stable IP address or prefix. Can the text in red be valid for both host or router? When the node is a router: an application (of a host in a mobile network) may not be able to cope with= a change in the IP address of the MR when the MR moves. When the node is a host an application (of a MN) may not be able to cope with a change in the IP ad= dress of the MN when the MN moves. H Anthony Chan -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January 29, 2014 12:30 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Le 28/01/2014 23:33, h chan a =E9crit : > Let us try to include MR. > > How about the following > > REQ2: Network-layer mobility support when needed > > DMM solutions MUST enable network-layer > mobility when needed. > Such mobility support is needed, for > example, when an application or a host cannot cope with a chan= ge in the > IP address when a node moves. However, it is not always neces= sary to maintain a > stable IP address or prefix. > > Here, the node can be a mobile host or a mobile router. I am not sure the term 'node' is agreed to cover both an MH and an MR. I think in all descriptions it would be clearer if we just said MH when we = meant Mobile Host and MR when we meant Mobile Router. Le me paraphrase this text in RFC6275: > This document specifies a protocol that allows nodes to remain > reachable while moving around in the IPv6 Internet. Without specific > support for mobility in IPv6 [6], packets destined to a mobile node > would not be able to reach it while the mobile node is away from its > home link. There is a clear ambiguity in the 'mobile node' used above. Because if we = talk moving networks then often the packets are destined (the contents of t= he destination address) to a LFN, not to the MR. If that 'node' were a Mobile Router (not a Mobile Host) it completely misse= s the case when packets are destined to the LFN, which is not an MH nor an = MR. The phrase should rather say: 'packets destined to a MH (or to a LFN behind a MR) would not be able to reach it while that MH (or the MR and LFN) is away from its home link.' This kind if expression would be clearer. Alex 'packets destined to a [LFN] or to the Mobile Host, or to the Mobile Router= , would not be able to reach it while the Mobile Router is away from its ho= me link'. > A host can be a mobile host or a host in a LFN. > An application can be running on a mobile host or a on a host in a LFN. > A MR also does not need to maintain stable IP address or prefix when ther= e are no hosts attached to it or when there are no active applications runn= ing in the hosts of its network. > > Any comments/changes/corrections? > > H Anthony Chan > > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, January 28, 2014 1:27 PM > To: h chan; dmm@ietf.org > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements > > Le 28/01/2014 19:58, h chan a =E9crit : >> Let me try to understand the concern here. >> >> What is new in this requirement is "when needed" in contrast to >> providing IP mobility by default. > > First, providing mobility by default is not a black/white alternative to = not providing mobility. > > It is very possible on the same machine to have Mobile IP enabled for som= e flows and disabled for others (depending what we call a 'flow'). > It is also possible to have Mobile IP and NAT at the same time on the sam= e Mobile Router. > >> Without this requirement, mobility support may be provided by >> default, which is transparent to higher layers. > > Again, transparency to higher layers means we talk mobility management on= a Mobile Host. > > Transparency to higher layers has little meaning if we talk mobility mana= gement provided on a Mobile Router (which is not a Mobile Host). > >> With this requirement, assume there are separate steps in the DMM >> solution. 1. A decision is made whether network-layer mobility >> support is needed. 2. When the need is established, network-layer >> mobility support is invoked. 3. Then transparent support is provided >> and is transparent to layers above IP. >> >> Transparency is clear in step 3 above. > > This looks like a trigger which enables mobility, or other times disables= it. > > But one can have a Mobile IP daemon and a NAT run at the same time on the= same machine. There is no decision in time. > > Some decision happens at packet based on IP destination address. > >> The question however is whether the preceding steps involve the >> application, so that one may question whether the entire DMM solution >> (with all the steps) as a whole is transparent. > > I agree. I am not aware of any application which talks to Mobile IP. > Whenever it is there it is 'transparent'. > >> So the intention of the requirement is that WHEN/AFTER the decision >> is made to invoke mobility support, then the mobility support is >> transparent to the application. Then we may want to check and make >> sure the emphasis of this requirement does mean transparency in this >> respect only. > > I disagree. > > As I said above, the word 'transparency' is dubious. Some times it may m= ean 'non-existent', some times it may mean light goes through it but modifi= ed. > > If one wants to continue using it, then one should better qualify it with= 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'. > > Because a Mobile Router doing mobility management in a transparent manner= on the Mobile Router for the LFN has nothing to do with applications, neit= her with upper layers. > > Also, a Mobile Router doing NAT and Mobile IP at the same time is 50%-tra= nsparent. > >> >> Original wording: >> >> REQ2: Transparency to Upper Layers when needed >> >> DMM solutions MUST provide transparent mobility support above the IP >> layer when needed. Such transparency is needed, for example, when, > ^on a Mobile Host. >> upon change of point of attachment to the network, an application >> flow cannot cope with a change in the IP address. > > (it's not the application flow, it is a socket which some times may > break [paste here the error from the screen]; the term 'application > flow' in this context has little meaning) > > (an 'application flow' has no understandable meaning in practice). > >> However, it is not always necessary to maintain a stable home IP >> address or prefix for every application or at all times for a mobile >> node. > ^a Mobile Host. > > I agree. > >> I now tend to think the first sentence in this original wording may >> steer the emphasis on providing transparent support, which is not >> what the motivation and the problems are talking about. > > I agree. > >> The motivation and the problems are talking about when they are not >> needed. The emphasis of this requirement therefore is on the >> capability to turn OFF unnecessary mobility support. > > In a sense I agree with the meaning. > > But when trying to turn off or on mobility support the things are not lik= e if there were a knob on/off, not even like starting/stopping some daemon.= It is a matter of always having the Mobile IP support on, and tweak the r= outing table with some particular entries, and the firewalling rules to NAT= some addresses or not. > >> How about the following >> >> REQ2: Network-layer mobility support ONLY when needed > > If we understood better when it was needed... > >> DMM solutions MUST NOT provide network-layer mobility support when >> NOT needed. > > I would say that Mobile IP MUST always be turned on on a Mobile Host. > >> (or if you don't like double negatives: (DMM solutions MUST provide >> network-layer mobility support ONLY when needed) > > No, I would say to have it always on. If some applications don't want it= then dont use it; realize that by inserting routing table entries. > > One may wonder when some applications dont want it. One answer is when s= ome applications prefer to not go through the HA in order to take advantage= of the 4G pure speed. When? For example if the HA link is too slow compar= ed to 4G. (remark this is not the same as saying that the triangular route= is longer than straight, because that is always true). > > This is not a request for Route Optimization. It is an invitation to ana= lyze in deeper detail the application needs. > > One may have an application start via the HA (offer reachability) and con= tinue straight, w/o HA. It's the same application. > > Consider a video-call like appli: you want to be reachable always at the = same IP address (through HA) but once the session is ongoing you may not wa= nt to use it through HA if no handover in sight. > > Something like that. > > These things could be further refined if we really went into detail and u= nderstood what are the needs of applications, the distinctions MH-MR, etc. > >> Such transparent mobility support above the IP layer is needed, for >> example, when, upon change of point of attachment to the network, an >> application flow cannot cope with a change in the IP address. >> However, it is not always necessary to maintain a stable home IP >> address or prefix for every application or at all times for a mobile >> node. > > A Mobile Host never maintains a stable prefix, only a stable address. > > A Mobile Router may maintain a stable address (its HoA) and may maintain = a stable prefix (its MNP). It could also just maintain stable just its MN= P, but not its HoA; and vice-versa. Is that mobility? > > For each of these there is an application :-) > > Alex > >> >> Any comments/changes/corrections? >> >> H Anthony Chan >> >> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On >> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM >> To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: >> draft-ietf-dmm-requirements >> >> Le 28/01/2014 02:45, h chan a =E9crit : >>> I will drop "related" >>> >>> Regarding the following >>> >>> 5. Section 5: - I am a little confused by REQ2. It says that a DMM >>> solution should be transparent to the applications. >> >> This remark is typically true when we talk Mobile IP on a Mobile Host >> and an application like firefox runs above a BSD Socket interface. >> >> >>> However, the motivation talks about identifying applications that do >>> (or do not) need mobility support from the network layer. That >>> doesn't sound transparent to me. Am I reading this incorrectly? >>> >>> It appears that unless the network can find out whether the >>> application has need of such support, the application indeed may >>> need to invoke mobility support or has to convey its need to the networ= k. >>> >>> The emphasis of requirement is on "when needed." So, I think it is >>> better to drop the word "transparent" as follows: >>> >>> REQ2: Mobility support when needed >>> >>> DMM solutions MUST provide mobility support to above the IP layer >>> when needed. Such support is needed, for example, when, upon change >>> of point of attachment to the network, an application flow cannot >>> cope with a change in the IP address. However, it is not always >>> necessary to maintain a stable home IP address or prefix for every >>> application or at all times for a mobile node. >>> >>> Motivation: The motivation of this requirement is to enable more >>> efficient routing and more efficient use of network resources by >>> selecting an IP address or prefix according to whether mobility >>> support is needed and by not maintaining context at the mobility >>> anchor when there is no such need. >> >> Whenever we discuss this 'transparency' paragraph I have again the >> same comments. >> >> First, I am not sure DMM is only about Mobile Hosts, or about Mobile >> Routers as well. >> >> Because, if we talk Mobile Routers, then rarely an application runs >> directly on it. Most applications would run on LFN. >> >> Transparency? >> >> If the applications run on the LFN, the change of the attachment of >> the MR is 'transparent' to them, regardless whether or not MR does >> something to maintain stability of that address (Mobile IP, other). >> >> Second, this transparency may depend on the direction, or more >> complex 'shape' of the application flows. Some IP flows of some >> applications have very complex 'shapes', with various sets of IP src >> and dst, and triangular or HA-less shapes. >> >> Take for example a video-call. The session establishment through an >> intermediary and behind NAT is followed by the ongoing 4 flows (2 >> audio 2 video)... they all take different paths... each may need or >> not need to go through the HA, and each has distinct behaviours when >> the IP address changes, hence each would have a distinct >> 'transparency' requirement. Is this _one_ application? >> >> Alex >> >>> >>> H Anthony Chan >>> >>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] >>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM >>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; >>> dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD E= valuation: >>> draft-ietf-dmm-requirements >>> >>> >>> >>> On 1/24/14 7:38 PM, h chan wrote: >>>> 4. Section 4: - I am not sure that it benefits the document to >>>> label >>>> PS6 and PS7 as related. Those issues are problematic on their own. >>>> If you remove the "(related problem)" label from them, make sure >>>> that REQ2 is updated to remove mention of "related problem". >>>> >>>> The intention of the name "related problems" was not to suggest >>>> they are less problematic, but rather to distinguish them from the >>>> other problems directly on mobility management. Although these >>>> problems are not directly on mobility management, the DMM solutions >>>> can solve these additional problems. They are therefore included. >>>> So, as long as this section is not to be interpreted as limited to >>>> problems directly on mobility management, we can drop the word "relate= d." >>>> >>> >>> I will leave it to the authors/WG, but I don't see a benefit to the >>> "related" tag. >>> >>> 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 >> >> > > > > --_000_6E31144C030982429702B11D6746B98C370EB866szxeml557mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Alex

 

How about the following:

 

    REQ2:  Using and not Usin= g Network-layer mobility support

 

        &= nbsp;  DMM solutions MUST enable network-layer mobility

        &= nbsp;  but it MUST be possible to not invoke it.

        &= nbsp;  Mobility support is needed, for examp= le,

    = ;       when an application (of a MN or = a host in a mobile network of a MR)

    = ;       cannot cope with a change in the=

    = ;       IP address of the mobile node when th= e node moves. 

        &= nbsp;  Yet a mobile node can often be stationary,

        &= nbsp;  and mobility support can also be provided at other layers.=

        &= nbsp;  It is then not always necessary to maintain a

        &= nbsp;  stable IP address or prefix.

 

Can the text in red be valid for both host or rou= ter?

 

When the node is a router:

an application (of a host in a mobile network) ma= y not be able to cope with a change in the IP address of the MR when the MR= moves.

 

When the node is a host

an application (of a MN) may not be able to cope = with a change in the IP address of the MN when the MN moves.

 

H Anthony Chan

 

 

-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
Sent: Wednesday, January 29, 2014 12:30 PM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements

 

Le 28/01/2014 23:33, h chan a =E9crit :

> Let us try to include MR.

> 

> How about the following

> 

>     REQ2:  Network-= layer mobility support when needed

> 

>       &nb= sp;    DMM solutions MUST enable network-layer

>       &nb= sp;    mobility when needed.

>       &nb= sp;    Such mobility support is needed, for

>       &nb= sp;    example, when an application or a host cannot cope wi= th a change in the

>       &nb= sp;    IP address when a node moves.  However, it is no= t always necessary to maintain a

>       &nb= sp;    stable IP address or prefix.

> 

> Here, the node can be a mobile host or a mob= ile router.

 

I am not sure the term 'node' is agreed to cover = both an MH and an MR.

 

I think in all descriptions it would be clearer i= f we just said MH when we meant Mobile Host and MR when we meant Mobile Rou= ter.

 

Le me paraphrase this text in RFC6275:=

 

>    This document specifies a = protocol that allows nodes to remain

>    reachable while moving aro= und in the IPv6 Internet.  Without specific

>    support for mobility in IP= v6 [6], packets destined to a mobile node

>    would not be able to reach= it while the mobile node is away from its

>    home link.

 

There is a clear ambiguity in the 'mobile node' u= sed above.  Because if we talk moving networks then often the packets = are destined (the contents of the destination address) to a LFN, not to the= MR.

 

If that 'node' were a Mobile Router (not a Mobile= Host) it completely misses the case when packets are destined to the LFN, = which is not an MH nor an MR.

 

The phrase should rather say:

 

'packets destined to a MH (or to a LFN behind a M= R) would not be able

  to reach it while that MH (or the MR and L= FN) is away from its home

  link.'

 

This kind if expression would be clearer.

 

Alex

 

'packets destined to a [LFN] or to the Mobile Hos= t, or to the Mobile Router, would not be able to reach it while the Mobile = Router is away from its home link'.

 

 

 

 

> A host can be a mobile host or a host in a L= FN.

> An application can be running on a mobile ho= st or a on a host in a LFN.

> A MR also does not need to maintain stable I= P address or prefix when there are no hosts attached to it or when there ar= e no active applications running in the hosts of its network.

> 

> Any comments/changes/corrections?=

> 

> H Anthony Chan

> 

> 

> -----Original Message-----

> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]

> Sent: Tuesday, January 28, 2014 1:27 PM=

> To: h chan; = dmm@ietf.org

> Subject: Re: [DMM] AD Evaluation: draft-ietf= -dmm-requirements

> 

> Le 28/01/2014 19:58, h chan a =E9crit :=

>> Let me try to understand the concern her= e.

>> 

>> What is new in this requirement is "= ;when needed" in contrast to

>> providing IP mobility by default.

> 

> First, providing mobility by default is not = a black/white alternative to not providing mobility.

> 

> It is very possible on the same machine to h= ave Mobile IP enabled for some flows and disabled for others (depending wha= t we call a 'flow').

> It is also possible to have Mobile IP and NA= T at the same time on the same Mobile Router.

> 

>> Without this requirement, mobility suppo= rt may be provided by

>> default, which is transparent to higher = layers.

> 

> Again, transparency to higher layers means w= e talk mobility management on a Mobile Host.

> 

> Transparency to higher layers has little mea= ning if we talk mobility management provided on a Mobile Router (which is n= ot a Mobile Host).

> 

>> With this requirement, assume there are = separate steps in the DMM

>> solution. 1. A decision is made whether = network-layer mobility

>> support is needed. 2. When the need is e= stablished, network-layer

>> mobility support is invoked. 3. Then tra= nsparent support is provided 

>> and is transparent to layers above IP.

>> 

>> Transparency is clear in step 3 above.

> 

> This looks like a trigger which enables mobi= lity, or other times disables it.

> 

> But one can have a Mobile IP daemon and a NA= T run at the same time on the same machine.  There is no decision in t= ime.

> 

> Some decision happens at packet based on IP = destination address.

> 

>> The question however is whether the prec= eding steps involve the

>> application, so that one may question wh= ether the entire DMM solution

>> (with all the steps) as a whole is trans= parent.

> 

> I agree.  I am not aware of any applica= tion which talks to Mobile IP.

> Whenever it is there it is 'transparent'.

> 

>> So the intention of the requirement is t= hat WHEN/AFTER the decision

>> is made to invoke mobility support, then= the mobility support is

>> transparent to the application. Then we = may want to check and make

>> sure the emphasis of this requirement do= es mean transparency in this

>> respect only.

> 

> I disagree.

> 

> As I said above, the word 'transparency' is = dubious.  Some times it may mean 'non-existent', some times it may mea= n light goes through it but modified.

> 

> If one wants to continue using it, then one = should better qualify it with 'Mobile Host', with 'Upper Layers' and with '= BSD Socket Interface'.

> 

> Because a Mobile Router doing mobility manag= ement in a transparent manner on the Mobile Router for the LFN has nothing = to do with applications, neither with upper layers.

> 

> Also, a Mobile Router doing NAT and Mobile I= P at the same time is 50%-transparent.

> 

>> 

>> Original wording:

>> 

>> REQ2:  Transparency to Upper Layers= when needed

>> 

>> DMM solutions MUST provide transparent m= obility support above the IP

>> layer when needed.  Such transparen= cy is needed, for example, when,

>       &nb= sp;            =   ^on a Mobile Host.

>> upon change of point of attachment to th= e network, an application

>> flow cannot cope with a change in the IP= address.

> 

> (it's not the application flow, it is a sock= et which some times may

> break [paste here the error from the screen]= ; the term 'application

> flow' in this context has little meaning)

> 

> (an 'application flow' has no understandable= meaning in practice).

> 

>> However, it is not always necessary to m= aintain a stable home IP

>> address or prefix for every application = or at all times for a mobile

>> node.

>       &nb= sp; ^a Mobile Host.

> 

> I agree.

> 

>> I now tend to think the first sentence i= n this original wording may

>> steer the emphasis on providing transpar= ent support, which is not

>> what the motivation and the problems are= talking about.

> 

> I agree.

> 

>> The motivation and the problems are talk= ing about when they are not

>> needed. The emphasis of this requirement= therefore is on the

>> capability to turn OFF unnecessary mobil= ity support.

> 

> In a sense I agree with the meaning.

> 

> But when trying to turn off or on mobility s= upport the things are not like if there were a knob on/off, not even like s= tarting/stopping some daemon.  It is a matter of always having the Mob= ile IP support on, and tweak the routing table with some particular entries, and the firewalling rules to NAT some addres= ses or not.

> 

>> How about the following

>> 

>> REQ2:  Network-layer mobility suppo= rt ONLY when needed

> 

> If we understood better when it was needed..= .

> 

>> DMM solutions MUST NOT provide network-l= ayer mobility support when

>> NOT needed.

> 

> I would say that Mobile IP MUST always be tu= rned on on a Mobile Host.

> 

>> (or if you don't like double negatives: = (DMM solutions MUST provide

>> network-layer mobility support ONLY when= needed)

> 

> No, I would say to have it always on.  = If some applications don't want it then dont use it; realize that by insert= ing routing table entries.

> 

> One may wonder when some applications dont w= ant it.  One answer is when some applications prefer to not go through= the HA in order to take advantage of the 4G pure speed.  When? For ex= ample if the HA link is too slow compared to 4G.  (remark this is not the same as saying that the triangular route is longer= than straight, because that is always true).

> 

> This is not a request for Route Optimization= .  It is an invitation to analyze in deeper detail the application nee= ds.

> 

> One may have an application start via the HA= (offer reachability) and continue straight, w/o HA.  It's the same ap= plication.

> 

> Consider a video-call like appli: you want t= o be reachable always at the same IP address (through HA) but once the sess= ion is ongoing you may not want to use it through HA if no handover in sigh= t.

> 

> Something like that.

> 

> These things could be further refined if we = really went into detail and understood what are the needs of applications, = the distinctions MH-MR, etc.

> 

>> Such transparent mobility support above = the IP layer is needed, for

>> example, when, upon change of point of a= ttachment to the network, an

>> application flow cannot cope with a chan= ge in the IP address.

>> However, it is not always necessary to m= aintain a stable home IP

>> address or prefix for every application = or at all times for a mobile

>> node.

> 

> A Mobile Host never maintains a stable prefi= x, only a stable address.

> 

> A Mobile Router may maintain a stable addres= s (its HoA) and may maintain a stable prefix  (its MNP).  It coul= d also just maintain stable just its MNP, but not its HoA; and vice-versa.&= nbsp; Is that mobility?

> 

> For each of these there is an application :-= )

> 

> Alex

> 

>> 

>> Any comments/changes/corrections?

>> 

>> H Anthony Chan

>> 

>> -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On

>> Behalf Of Alexandru Petrescu Sent: Tuesd= ay, January 28, 2014 8:43 AM

>> To: dmm@ietf.org S= ubject: Re: [DMM] AD Evaluation:

>> draft-ietf-dmm-requirements

>> 

>> Le 28/01/2014 02:45, h chan a =E9crit :<= o:p>

>>> I will drop "related"=

>>> 

>>> Regarding the following

>>> 

>>> 5. Section 5: - I am a little confus= ed by REQ2.  It says that a DMM

>>> solution should be transparent to th= e applications.

>> 

>> This remark is typically true when we ta= lk Mobile IP on a Mobile Host

>> and an application like firefox runs abo= ve a BSD Socket interface.

>> 

>> 

>>> However, the motivation talks about = identifying applications that do

>>> (or do not) need mobility support fr= om the network layer.  That

>>> doesn't sound transparent to me.&nbs= p; Am I reading this incorrectly?

>>> 

>>> It appears that unless the network c= an find out whether the

>>> application has need of such support= , the application indeed may

>>> need to invoke mobility support or h= as to convey its need to the network.

>>> 

>>> The emphasis of requirement is on &q= uot;when needed." So, I think it is

>>> better to drop the word "transp= arent" as follows:

>>> 

>>> REQ2:  Mobility support when ne= eded

>>> 

>>> DMM solutions MUST provide mobility = support to above the IP layer

>>> when needed.  Such support is n= eeded, for example, when, upon change

>>> of point of attachment to the networ= k, an application flow cannot

>>> cope with a change in the IP address= .  However, it is not always

>>> necessary to maintain a stable home = IP address or prefix for every

>>> application or at all times for a mo= bile node.

>>> 

>>> Motivation: The motivation of this r= equirement is to enable more

>>> efficient routing and more efficient= use of network resources by

>>> selecting an IP address or prefix ac= cording to whether mobility

>>> support is needed and by not maintai= ning context at the mobility

>>> anchor when there is no such need.

>> 

>> Whenever we discuss this 'transparency' = paragraph I have again the

>> same comments.

>> 

>> First, I am not sure DMM is only about M= obile Hosts, or about Mobile

>> Routers as well.

>> 

>> Because, if we talk Mobile Routers, then= rarely an application runs

>> directly on it.  Most applications = would run on LFN.

>> 

>> Transparency?

>> 

>> If the applications run on the LFN, the = change of the attachment of

>> the MR is 'transparent' to them, regardl= ess whether or not MR does

>> something to maintain stability of that = address (Mobile IP, other).

>> 

>> Second, this transparency may depend on = the direction, or more

>> complex 'shape' of the application flows= .  Some IP flows of some

>> applications have very complex 'shapes',= with various sets of IP src 

>> and dst, and triangular or HA-less shape= s.

>> 

>> Take for example a video-call.  The= session establishment through an

>> intermediary and behind NAT is followed = by the ongoing 4 flows (2

>> audio 2 video)... they all take differen= t paths... each may need or

>> not need to go through the HA, and each = has distinct behaviours when

>> the IP address changes, hence each would= have a distinct

>> 'transparency' requirement.  Is thi= s _one_ application?

>> 

>> Alex

>> 

>>> 

>>> H Anthony Chan

>>> 

>>> -----Original Message----- From: dmm= [mailto:dmm-bounces@ietf.org]

>>> On Behalf Of Brian Haberman Sent: Mo= nday, January 27, 2014 7:20 AM

>>> To: h chan; draft-ietf-dmm-requir= ements@tools.ietf.org;

>>> dmm@ietf.org; = Peter McCann Subject: Re: [DMM] AD Evaluation:

>>> draft-ietf-dmm-requirements

>>> 

>>> 

>>> 

>>> On 1/24/14 7:38 PM, h chan wrote:

>>>> 4. Section 4: - I am not sure th= at it benefits the document to

>>>> label

>>>> PS6 and PS7 as related.  Th= ose issues are problematic on their own.

>>>> If you remove the "(related= problem)" label from them, make sure

>>>> that REQ2 is updated to remove m= ention of "related problem".

>>>> 

>>>> The intention of the name "= related problems" was not to suggest

>>>> they are less problematic, but r= ather to distinguish them from the

>>>> other problems directly on mobil= ity management. Although these

>>>> problems are not directly on mob= ility management, the DMM solutions

>>>> can solve these additional probl= ems. They are therefore included.

>>>> So, as long as this section is n= ot to be interpreted as limited to

>>>> problems directly on mobility ma= nagement, we can drop the word "related."

>>>> 

>>> 

>>> I will leave it to the authors/WG, b= ut I don't see a benefit to the

>>> "related" tag.<= /p>

>>> 

>>> Regards, Brian

>>> 

>>> ____________________________________= ___________ dmm mailing list

>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm<= /span>

>>> 

>>> 

>> 

>> 

>> ________________________________________= _______ dmm mailing list

>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm<= /span>

>> 

>> 

> 

> 

> 

> 

 

 

--_000_6E31144C030982429702B11D6746B98C370EB866szxeml557mbxchi_-- From alexandru.petrescu@gmail.com Thu Jan 30 00:13:40 2014 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 5E5D31A0467 for ; Thu, 30 Jan 2014 00:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 HTrVKfyLT8Kh for ; Thu, 30 Jan 2014 00:13:36 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8D91A03DC for ; Thu, 30 Jan 2014 00:13:35 -0800 (PST) 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 s0U8DPoi000740; Thu, 30 Jan 2014 09:13:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AF00C200C1F; Thu, 30 Jan 2014 09:13:36 +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 A2C582010D1; Thu, 30 Jan 2014 09:13:36 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0U8DPYg014096; Thu, 30 Jan 2014 09:13:25 +0100 Message-ID: <52EA09A0.70109@gmail.com> Date: Thu, 30 Jan 2014 09:13:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "dmm@ietf.org" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E948AC.6030904@gmail.com> <6E31144C030982429702B11D6746B98C370EB866@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB866@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 08:13:40 -0000 Le 29/01/2014 20:45, h chan a écrit : > Alex > > How about the following: > > REQ2: Using and not Using Network-layer mobility support > > DMM solutions MUST enable network-layer mobility > > but it MUST be possible to not invoke it. > > Mobility support is needed, for example, > > when an application (of a MN or a host in a mobile network of a MR) ^a LFN (because just 'host' may be confused with Mobile Host; and also because within the moving network there is also one or several Routers - not hosts.) > cannot cope with a change in the > > IP address of the mobile node when the node moves. ^Mobile Host or of the Mobile Router moves (because when the 'node' moves it may mean that the 'host' in the moving network moves, and that doesn't change its IP address). > Yet a mobile node can often be stationary, > > and mobility support can also be provided at other layers. > > It is then not always necessary to maintain a > > stable IP address or prefix. > > Can the text in red be valid for both host or router? Yes and no. I agree with it, but I'd prefer the suggested modifications. Alex > > When the node is a router: > > an application (of a host in a mobile network) may not be able to > cope with a change in the IP address of the MR when the MR moves. > > When the node is a host > > an application (of a MN) may not be able to cope with a change in the > IP address of the MN when the MN moves. > > H Anthony Chan > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January 29, > 2014 12:30 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD > Evaluation: draft-ietf-dmm-requirements > > Le 28/01/2014 23:33, h chan a écrit : > >> Let us try to include MR. > >> > >> How about the following > >> > >> REQ2: Network-layer mobility support when needed > >> > >> DMM solutions MUST enable network-layer > >> mobility when needed. > >> Such mobility support is needed, for > >> example, when an application or a host cannot cope with a > change in the > >> IP address when a node moves. However, it is not always > necessary to maintain a > >> stable IP address or prefix. > >> > >> Here, the node can be a mobile host or a mobile router. > > I am not sure the term 'node' is agreed to cover both an MH and an > MR. > > I think in all descriptions it would be clearer if we just said MH > when we meant Mobile Host and MR when we meant Mobile Router. > > Le me paraphrase this text in RFC6275: > >> This document specifies a protocol that allows nodes to remain > >> reachable while moving around in the IPv6 Internet. Without >> specific > >> support for mobility in IPv6 [6], packets destined to a mobile >> node > >> would not be able to reach it while the mobile node is away from >> its > >> home link. > > There is a clear ambiguity in the 'mobile node' used above. Because > if we talk moving networks then often the packets are destined (the > contents of the destination address) to a LFN, not to the MR. > > If that 'node' were a Mobile Router (not a Mobile Host) it completely > misses the case when packets are destined to the LFN, which is not > an MH nor an MR. > > The phrase should rather say: > > 'packets destined to a MH (or to a LFN behind a MR) would not be > able > > to reach it while that MH (or the MR and LFN) is away from its home > > link.' > > This kind if expression would be clearer. > > Alex > > 'packets destined to a [LFN] or to the Mobile Host, or to the Mobile > Router, would not be able to reach it while the Mobile Router is > away from its home link'. > >> A host can be a mobile host or a host in a LFN. > >> An application can be running on a mobile host or a on a host in a >> LFN. > >> A MR also does not need to maintain stable IP address or prefix >> when > there are no hosts attached to it or when there are no active > applications running in the hosts of its network. > >> > >> Any comments/changes/corrections? > >> > >> H Anthony Chan > >> > >> > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Tuesday, January 28, 2014 1:27 PM > >> To: h chan; dmm@ietf.org > >> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements > >> > >> Le 28/01/2014 19:58, h chan a écrit : > >>> Let me try to understand the concern here. > >>> > >>> What is new in this requirement is "when needed" in contrast to > >>> providing IP mobility by default. > >> > >> First, providing mobility by default is not a black/white >> alternative > to not providing mobility. > >> > >> It is very possible on the same machine to have Mobile IP enabled >> for > some flows and disabled for others (depending what we call a > 'flow'). > >> It is also possible to have Mobile IP and NAT at the same time on >> the > same Mobile Router. > >> > >>> Without this requirement, mobility support may be provided by > >>> default, which is transparent to higher layers. > >> > >> Again, transparency to higher layers means we talk mobility > management on a Mobile Host. > >> > >> Transparency to higher layers has little meaning if we talk >> mobility > management provided on a Mobile Router (which is not a Mobile Host). > >> > >>> With this requirement, assume there are separate steps in the >>> DMM > >>> solution. 1. A decision is made whether network-layer mobility > >>> support is needed. 2. When the need is established, >>> network-layer > >>> mobility support is invoked. 3. Then transparent support is >>> provided > >>> and is transparent to layers above IP. > >>> > >>> Transparency is clear in step 3 above. > >> > >> This looks like a trigger which enables mobility, or other times > disables it. > >> > >> But one can have a Mobile IP daemon and a NAT run at the same time >> on > the same machine. There is no decision in time. > >> > >> Some decision happens at packet based on IP destination address. > >> > >>> The question however is whether the preceding steps involve the > >>> application, so that one may question whether the entire DMM >>> solution > >>> (with all the steps) as a whole is transparent. > >> > >> I agree. I am not aware of any application which talks to Mobile >> IP. > >> Whenever it is there it is 'transparent'. > >> > >>> So the intention of the requirement is that WHEN/AFTER the >>> decision > >>> is made to invoke mobility support, then the mobility support is > >>> transparent to the application. Then we may want to check and >>> make > >>> sure the emphasis of this requirement does mean transparency in >>> this > >>> respect only. > >> > >> I disagree. > >> > >> As I said above, the word 'transparency' is dubious. Some times it >> > may mean 'non-existent', some times it may mean light goes through it > but modified. > >> > >> If one wants to continue using it, then one should better qualify >> it > with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket > Interface'. > >> > >> Because a Mobile Router doing mobility management in a transparent >> > manner on the Mobile Router for the LFN has nothing to do with > applications, neither with upper layers. > >> > >> Also, a Mobile Router doing NAT and Mobile IP at the same time is > 50%-transparent. > >> > >>> > >>> Original wording: > >>> > >>> REQ2: Transparency to Upper Layers when needed > >>> > >>> DMM solutions MUST provide transparent mobility support above the >>> IP > >>> layer when needed. Such transparency is needed, for example, >>> when, > >> ^on a Mobile Host. > >>> upon change of point of attachment to the network, an >>> application > >>> flow cannot cope with a change in the IP address. > >> > >> (it's not the application flow, it is a socket which some times >> may > >> break [paste here the error from the screen]; the term >> 'application > >> flow' in this context has little meaning) > >> > >> (an 'application flow' has no understandable meaning in practice). > >> > >>> However, it is not always necessary to maintain a stable home IP > >>> address or prefix for every application or at all times for a >>> mobile > >>> node. > >> ^a Mobile Host. > >> > >> I agree. > >> > >>> I now tend to think the first sentence in this original wording >>> may > >>> steer the emphasis on providing transparent support, which is >>> not > >>> what the motivation and the problems are talking about. > >> > >> I agree. > >> > >>> The motivation and the problems are talking about when they are >>> not > >>> needed. The emphasis of this requirement therefore is on the > >>> capability to turn OFF unnecessary mobility support. > >> > >> In a sense I agree with the meaning. > >> > >> But when trying to turn off or on mobility support the things are >> not > like if there were a knob on/off, not even like starting/stopping > some daemon. It is a matter of always having the Mobile IP support > on, and tweak the routing table with some particular entries, and the > firewalling rules to NAT some addresses or not. > >> > >>> How about the following > >>> > >>> REQ2: Network-layer mobility support ONLY when needed > >> > >> If we understood better when it was needed... > >> > >>> DMM solutions MUST NOT provide network-layer mobility support >>> when > >>> NOT needed. > >> > >> I would say that Mobile IP MUST always be turned on on a Mobile >> Host. > >> > >>> (or if you don't like double negatives: (DMM solutions MUST >>> provide > >>> network-layer mobility support ONLY when needed) > >> > >> No, I would say to have it always on. If some applications don't > want it then dont use it; realize that by inserting routing table > entries. > >> > >> One may wonder when some applications dont want it. One answer is >> > when some applications prefer to not go through the HA in order to > take advantage of the 4G pure speed. When? For example if the HA > link is too slow compared to 4G. (remark this is not the same as > saying that the triangular route is longer than straight, because > that is always true). > >> > >> This is not a request for Route Optimization. It is an invitation >> to > analyze in deeper detail the application needs. > >> > >> One may have an application start via the HA (offer reachability) >> and > continue straight, w/o HA. It's the same application. > >> > >> Consider a video-call like appli: you want to be reachable always >> at > the same IP address (through HA) but once the session is ongoing you > may not want to use it through HA if no handover in sight. > >> > >> Something like that. > >> > >> These things could be further refined if we really went into detail >> > and understood what are the needs of applications, the distinctions > MH-MR, etc. > >> > >>> Such transparent mobility support above the IP layer is needed, >>> for > >>> example, when, upon change of point of attachment to the network, >>> an > >>> application flow cannot cope with a change in the IP address. > >>> However, it is not always necessary to maintain a stable home IP > >>> address or prefix for every application or at all times for a >>> mobile > >>> node. > >> > >> A Mobile Host never maintains a stable prefix, only a stable >> address. > >> > >> A Mobile Router may maintain a stable address (its HoA) and may > maintain a stable prefix (its MNP). It could also just maintain > stable just its MNP, but not its HoA; and vice-versa. Is that > mobility? > >> > >> For each of these there is an application :-) > >> > >> Alex > >> > >>> > >>> Any comments/changes/corrections? > >>> > >>> H Anthony Chan > >>> > >>> -----Original Message----- From: dmm >>> [mailto:dmm-bounces@ietf.org] On > >>> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 >>> AM > >>> To: dmm@ietf.org Subject: Re: [DMM] AD >>> Evaluation: > >>> draft-ietf-dmm-requirements > >>> > >>> Le 28/01/2014 02:45, h chan a écrit : > >>>> I will drop "related" > >>>> > >>>> Regarding the following > >>>> > >>>> 5. Section 5: - I am a little confused by REQ2. It says that a >>>> DMM > >>>> solution should be transparent to the applications. > >>> > >>> This remark is typically true when we talk Mobile IP on a Mobile >>> Host > >>> and an application like firefox runs above a BSD Socket >>> interface. > >>> > >>> > >>>> However, the motivation talks about identifying applications >>>> that do > >>>> (or do not) need mobility support from the network layer. >>>> That > >>>> doesn't sound transparent to me. Am I reading this >>>> incorrectly? > >>>> > >>>> It appears that unless the network can find out whether the > >>>> application has need of such support, the application indeed >>>> may > >>>> need to invoke mobility support or has to convey its need to >>>> the > network. > >>>> > >>>> The emphasis of requirement is on "when needed." So, I think it >>>> is > >>>> better to drop the word "transparent" as follows: > >>>> > >>>> REQ2: Mobility support when needed > >>>> > >>>> DMM solutions MUST provide mobility support to above the IP >>>> layer > >>>> when needed. Such support is needed, for example, when, upon >>>> change > >>>> of point of attachment to the network, an application flow >>>> cannot > >>>> cope with a change in the IP address. However, it is not >>>> always > >>>> necessary to maintain a stable home IP address or prefix for >>>> every > >>>> application or at all times for a mobile node. > >>>> > >>>> Motivation: The motivation of this requirement is to enable >>>> more > >>>> efficient routing and more efficient use of network resources >>>> by > >>>> selecting an IP address or prefix according to whether >>>> mobility > >>>> support is needed and by not maintaining context at the >>>> mobility > >>>> anchor when there is no such need. > >>> > >>> Whenever we discuss this 'transparency' paragraph I have again >>> the > >>> same comments. > >>> > >>> First, I am not sure DMM is only about Mobile Hosts, or about >>> Mobile > >>> Routers as well. > >>> > >>> Because, if we talk Mobile Routers, then rarely an application >>> runs > >>> directly on it. Most applications would run on LFN. > >>> > >>> Transparency? > >>> > >>> If the applications run on the LFN, the change of the attachment >>> of > >>> the MR is 'transparent' to them, regardless whether or not MR >>> does > >>> something to maintain stability of that address (Mobile IP, >>> other). > >>> > >>> Second, this transparency may depend on the direction, or more > >>> complex 'shape' of the application flows. Some IP flows of some > >>> applications have very complex 'shapes', with various sets of IP >>> src > >>> and dst, and triangular or HA-less shapes. > >>> > >>> Take for example a video-call. The session establishment through >>> an > >>> intermediary and behind NAT is followed by the ongoing 4 flows >>> (2 > >>> audio 2 video)... they all take different paths... each may need >>> or > >>> not need to go through the HA, and each has distinct behaviours >>> when > >>> the IP address changes, hence each would have a distinct > >>> 'transparency' requirement. Is this _one_ application? > >>> > >>> Alex > >>> > >>>> > >>>> H Anthony Chan > >>>> > >>>> -----Original Message----- From: dmm >>>> [mailto:dmm-bounces@ietf.org] > >>>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 >>>> AM > >>>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org > ; > >>>> dmm@ietf.org ; Peter McCann Subject: Re: >>>> [DMM] > AD Evaluation: > >>>> draft-ietf-dmm-requirements > >>>> > >>>> > >>>> > >>>> On 1/24/14 7:38 PM, h chan wrote: > >>>>> 4. Section 4: - I am not sure that it benefits the document >>>>> to > >>>>> label > >>>>> PS6 and PS7 as related. Those issues are problematic on >>>>> their own. > >>>>> If you remove the "(related problem)" label from them, make >>>>> sure > >>>>> that REQ2 is updated to remove mention of "related problem". > >>>>> > >>>>> The intention of the name "related problems" was not to >>>>> suggest > >>>>> they are less problematic, but rather to distinguish them >>>>> from the > >>>>> other problems directly on mobility management. Although >>>>> these > >>>>> problems are not directly on mobility management, the DMM >>>>> solutions > >>>>> can solve these additional problems. They are therefore >>>>> included. > >>>>> So, as long as this section is not to be interpreted as >>>>> limited to > >>>>> problems directly on mobility management, we can drop the >>>>> word > "related." > >>>>> > >>>> > >>>> I will leave it to the authors/WG, but I don't see a benefit to >>>> the > >>>> "related" tag. > >>>> > >>>> 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 brian@innovationslab.net Thu Jan 30 06:01:42 2014 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 CB4681A035D for ; Thu, 30 Jan 2014 06:01:42 -0800 (PST) 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 wKwR38Jsic1T for ; Thu, 30 Jan 2014 06:01:41 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 70C5D1A035B for ; Thu, 30 Jan 2014 06:01:41 -0800 (PST) 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 807D6880D1; Thu, 30 Jan 2014 06:01:38 -0800 (PST) Received: from 102524131.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2A8BE1368142; Thu, 30 Jan 2014 06:01:38 -0800 (PST) Message-ID: <52EA5B42.3050002@innovationslab.net> Date: Thu, 30 Jan 2014 09:01:38 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "dmm@ietf.org" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E90F7A.3050902@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB829@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB829@szxeml557-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7IbfTKvXV9NGTdSDMbXbqvlDkqjMWlEF6" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 14:01:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7IbfTKvXV9NGTdSDMbXbqvlDkqjMWlEF6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Anthony, On 1/29/14 1:51 PM, h chan wrote: > Brian, >=20 > The requirement is intended to include a capability of not using > network-layer mobility management, as opposed to using it by default. >=20 >=20 > I think it is sufficient to leave to the explanation (the sentences > after the first sentence) to say that network-layer mobility support > is not always needed in order to justify this capability. >=20 > The alternative then is to say that network-layer mobility is > provided but it is possible to not use such support. >=20 > REQ2: Using and not Using Network-layer mobility support >=20 > DMM solutions MUST enable network-layer mobility but it MUST be > possible to not invoke it. Mobility support is needed, for example,=20 > when an application or a host cannot cope with a change in the IP > address when a node moves. Yet a mobile node can often be > stationary, and mobility support can also be provided at other > layers. It is then not always necessary to maintain a stable IP > address or prefix. >=20 > Of cause "enable" does not mean it must be used. Yet explicitly say > "it is possible to not invoke it" is to draw the contrast to using it > by default. My only concern is that it is unclear *who* invokes the network-layer mobility support. Is it envisioned that the application can signal the need for mobility support? Does the user have to configure which applications get support? Regards, Brian --7IbfTKvXV9NGTdSDMbXbqvlDkqjMWlEF6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS6ltCAAoJEBOZRqCi7goqnCUH/3P+fEVg/u6LiUGmb0/emQu4 oQoI6+1M08d5dHM5RDpsZ3OuH45mRRC+gqhbgkxPubCxQVuB5ovK/4Ni50i6bVFz Mj+UOYl6JEuTUmPGT592EnTJVX70MkHcWGJ0+XwcU37HdiKCrBtYcMobmpiuF4yT Ak8PMKvVayaCEuZ4kmqgvJYOQC3BOfiRh0qIAkl/xoc8/yqxAgrJbCnV8YjtRWf9 lMuXg+HuRxDExOjFKs+8e5U8E1LAHS300xAG0eROvwPqLbQ1aRJHM1o5UWLACfR6 tMdIOPFaMb06M9AWWEP6js1xd5JbXPdgnlKKKQxe4+4LlQ7mdMSQpN3Mg1yMvEI= =6UlA -----END PGP SIGNATURE----- --7IbfTKvXV9NGTdSDMbXbqvlDkqjMWlEF6-- From brian@innovationslab.net Thu Jan 30 06:03:07 2014 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 CBE1C1A02F0 for ; Thu, 30 Jan 2014 06:03:07 -0800 (PST) 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 0xeFV7DNCfYS for ; Thu, 30 Jan 2014 06:03:06 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 243BC1A02DF for ; Thu, 30 Jan 2014 06:03:06 -0800 (PST) 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 30B34880D1; Thu, 30 Jan 2014 06:03:03 -0800 (PST) Received: from 102524131.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9D6A51368142; Thu, 30 Jan 2014 06:03:02 -0800 (PST) Message-ID: <52EA5B97.3090508@innovationslab.net> Date: Thu, 30 Jan 2014 09:03:03 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB641@szxeml557-mbx.china.huawei.com> <52E909A6.80008@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB82F@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB82F@szxeml557-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0407wLIKonEMsgFIUKxxNLFpNiOawB8Nt" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 14:03:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0407wLIKonEMsgFIUKxxNLFpNiOawB8Nt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony, I am fine with that. I would like feedback from the rest of the WG on these changes. Brian On 1/29/14 1:53 PM, h chan wrote: > Delete those explanatory sentences then. >=20 > REQ5: Co-existence with deployed networks and hosts >=20 > The DMM solution MUST be able to co-exist with existing > network deployments and end hosts. =20 > Furthermore, a DMM solution SHOULD work across different > networks, possibly operated as separate administrative > domains, when allowed by the trust relationship between them.= >=20 > H Anthony Chan >=20 >=20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: Wednesday, January 29, 2014 8:01 AM > To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; P= eter McCann > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements >=20 >=20 >=20 > On 1/28/14 4:33 PM, h chan wrote: >> Regarding the following: >> >> - What is meant by co-exist in REQ5? Does this mean that a DMM soluti= on does not break an existing one? Or does it mean that it must inter-op= erate with existing ones? Is this like IPv4 and IPv6 being incompatible,= but can run concurrently on the same network? Or does this mean there n= eeds to be some mechanism for interaction (i.e., like NAT64)? >> >> >> >> I think the bottom line is that the existing ones do not break. >> >> >> >> Original >> >> REQ5: Co-existence with deployed networks and hosts >> >> >> >> The DMM solution MUST be able to co-exist with existing >> >> network deployments and end hosts. For example, depending=20 >> on >> >> the environment in which DMM is deployed, DMM solutions may >> >> need to be compatible with other deployed mobility protocols= >> >> or may need to co-exist with a network or mobile=20 >> hosts/routers >> >> that do not support DMM protocols. The mobile node may also= >> >> move between different access networks, where some of them=20 >> may >> >> support neither DMM nor another mobility protocol. >> >> Furthermore, a DMM solution SHOULD work across different >> >> networks, possibly operated as separate administrative >> >> domains, when allowed by the trust relationship between them= =2E >> >> >> >> We can change to: >> >> REQ5: Co-existence with deployed networks and hosts >> >> >> >> The DMM solution MUST be able to co-exist with existing >> >> network deployments and end hosts without breaking them. =20 >> For example, depending on >> >> the environment in which DMM is deployed, DMM solutions may >> >> need to be compatible with other deployed mobility protocols= >> >> or may need to co-exist with a network or mobile=20 >> hosts/routers >> >> that do not support DMM protocols. The mobile node may also= >> >> move between different access networks, where some of them=20 >> may >> >> support neither DMM nor another mobility protocol. >> >> Furthermore, a DMM solution SHOULD work across different >> >> networks, possibly operated as separate administrative >> >> domains, when allowed by the trust relationship between them= =2E >=20 > The "without breaking" is fine. However, the "need to be compatible wi= th" phrasing is still problematic. Is that inferring that in some situat= ions that a DMM solution would need to interact with, for example, PMIP? >=20 > Regards, > Brian >=20 --0407wLIKonEMsgFIUKxxNLFpNiOawB8Nt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS6luXAAoJEBOZRqCi7goqDEgIAKC96wls6qBXWzELz6Lk4uWj VS2icnsAGELqnbImvN/Lfcvukz3peXY2J8X60664ZsOlp4d4WhdFYudiZ/Zf480e lnimbTbqgP0agC9DtHE39gKnc+CGah2oWH6pyZr8D1HqsLa5QLCh4c9/BSTq1HgL sPhL46AOfQvgpcg88H8oRlztUEuRGoqhQsHSKri+w+W0as65IMg//icvV7reS7uv ScpHacpdCd1nMus76qiiEthZtHI2kVrtVPLFmIW2k+oFMkiLhhPv3tYsmemWrIc2 ZGeQ/mjnvJjLIsr04YEJWI0KUcwLHKxVurGICh0Q4Wz4N39Ptw5/D0jES5yisbI= =3f37 -----END PGP SIGNATURE----- --0407wLIKonEMsgFIUKxxNLFpNiOawB8Nt-- From alexandru.petrescu@gmail.com Thu Jan 30 06:18:23 2014 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 55CF51A038C for ; Thu, 30 Jan 2014 06:18:23 -0800 (PST) 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 7IAU2nGthp3T for ; Thu, 30 Jan 2014 06:18:21 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 352DD1A036B for ; Thu, 30 Jan 2014 06:18:21 -0800 (PST) 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 s0UEIH5W017420 for ; Thu, 30 Jan 2014 15:18:17 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9C7F8203D2B for ; Thu, 30 Jan 2014 15:18:28 +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 94C62203BC0 for ; Thu, 30 Jan 2014 15:18:28 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0UEIDGf020021 for ; Thu, 30 Jan 2014 15:18:17 +0100 Message-ID: <52EA5F20.2020803@gmail.com> Date: Thu, 30 Jan 2014 15:18:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dmm@ietf.org References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB641@szxeml557-mbx.china.huawei.com> <52E909A6.80008@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB82F@szxeml557-mbx.china.huawei.com> <52EA5B97.3090508@innovationslab.net> In-Reply-To: <52EA5B97.3090508@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 14:18:23 -0000 Le 30/01/2014 15:03, Brian Haberman a écrit : > Anthony, > I am fine with that. I would like feedback from the rest of the WG > on these changes. > > Brian > > On 1/29/14 1:53 PM, h chan wrote: >> Delete those explanatory sentences then. >> >> REQ5: Co-existence with deployed networks and hosts >> >> The DMM solution MUST be able to co-exist with existing >> network deployments and end hosts. >> Furthermore, a DMM solution SHOULD work across different >> networks, possibly operated as separate administrative >> domains, when allowed by the trust relationship between them. I agree with this formulation of this requirement. If I take a route update mechanism (such as based on BGP), I think it could fulfill that requirement. Many network deployments involve BGP, so this would be compatible. When inter-connecting domains in a secure manner, BGP would also work. The problem would be, of course, not to disturb it too much, if I can say so. I suppose there is a requirement for this as well. Alex >> >> H Anthony Chan >> >> >> -----Original Message----- >> From: Brian Haberman [mailto:brian@innovationslab.net] >> Sent: Wednesday, January 29, 2014 8:01 AM >> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann >> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements >> >> >> >> On 1/28/14 4:33 PM, h chan wrote: >>> Regarding the following: >>> >>> - What is meant by co-exist in REQ5? Does this mean that a DMM solution does not break an existing one? Or does it mean that it must inter-operate with existing ones? Is this like IPv4 and IPv6 being incompatible, but can run concurrently on the same network? Or does this mean there needs to be some mechanism for interaction (i.e., like NAT64)? >>> >>> >>> >>> I think the bottom line is that the existing ones do not break. >>> >>> >>> >>> Original >>> >>> REQ5: Co-existence with deployed networks and hosts >>> >>> >>> >>> The DMM solution MUST be able to co-exist with existing >>> >>> network deployments and end hosts. For example, depending >>> on >>> >>> the environment in which DMM is deployed, DMM solutions may >>> >>> need to be compatible with other deployed mobility protocols >>> >>> or may need to co-exist with a network or mobile >>> hosts/routers >>> >>> that do not support DMM protocols. The mobile node may also >>> >>> move between different access networks, where some of them >>> may >>> >>> support neither DMM nor another mobility protocol. >>> >>> Furthermore, a DMM solution SHOULD work across different >>> >>> networks, possibly operated as separate administrative >>> >>> domains, when allowed by the trust relationship between them. >>> >>> >>> >>> We can change to: >>> >>> REQ5: Co-existence with deployed networks and hosts >>> >>> >>> >>> The DMM solution MUST be able to co-exist with existing >>> >>> network deployments and end hosts without breaking them. >>> For example, depending on >>> >>> the environment in which DMM is deployed, DMM solutions may >>> >>> need to be compatible with other deployed mobility protocols >>> >>> or may need to co-exist with a network or mobile >>> hosts/routers >>> >>> that do not support DMM protocols. The mobile node may also >>> >>> move between different access networks, where some of them >>> may >>> >>> support neither DMM nor another mobility protocol. >>> >>> Furthermore, a DMM solution SHOULD work across different >>> >>> networks, possibly operated as separate administrative >>> >>> domains, when allowed by the trust relationship between them. >> >> The "without breaking" is fine. However, the "need to be compatible with" phrasing is still problematic. Is that inferring that in some situations that a DMM solution would need to interact with, for example, PMIP? >> >> Regards, >> Brian >> > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From h.anthony.chan@huawei.com Thu Jan 30 09:08:50 2014 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 E4DE61A0431 for ; Thu, 30 Jan 2014 09:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.736 X-Spam-Level: X-Spam-Status: No, score=-6.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 mEQdICV0kPeW for ; Thu, 30 Jan 2014 09:08:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EECE91A0419 for ; Thu, 30 Jan 2014 09:08:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAQ36122; Thu, 30 Jan 2014 17:08:42 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 17:08:16 +0000 Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 17:08:39 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.03.0158.001; Fri, 31 Jan 2014 01:08:34 +0800 From: h chan To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHZMwbFS3MZ7cnEiWkYjZb/tqwZqdeWsg Date: Thu, 30 Jan 2014 17:08:33 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB9B3@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E948AC.6030904@gmail.com> <6E31144C030982429702B11D6746B98C370EB866@szxeml557-mbx.china.huawei.com> <52EA09A0.70109@gmail.com> In-Reply-To: <52EA09A0.70109@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 17:08:51 -0000 Alex, Is the following correct? Mobility support is needed, for example,=20 when a mobile host or a mobile router moves=20 and an application in the mobile host or=20 in a host that moves with the router=20 cannot cope with a change in the IP address of the mobile node. H Anthony Chan -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, January 30, 2014 2:13 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Le 29/01/2014 20:45, h chan a =E9crit : > Alex > > How about the following: > > REQ2: Using and not Using Network-layer mobility support > > DMM solutions MUST enable network-layer mobility > > but it MUST be possible to not invoke it. > > Mobility support is needed, for example, > > when an application (of a MN or a host in a mobile network of a MR) ^a LFN (because just 'host' may be confu= sed with Mobile Host; and also because within the moving network there is a= lso one or several Routers - not hosts.) > cannot cope with a change in the > > IP address of the mobile node when the node moves. ^Mobile Host or of the Mobile Router moves (because whe= n the 'node' moves it may mean that the 'host' in the moving network moves,= and that doesn't change its IP address). > Yet a mobile node can often be stationary, > > and mobility support can also be provided at other layers. > > It is then not always necessary to maintain a > > stable IP address or prefix. > > Can the text in red be valid for both host or router? Yes and no. I agree with it, but I'd prefer the suggested modifications. Alex > > When the node is a router: > > an application (of a host in a mobile network) may not be able to cope=20 > with a change in the IP address of the MR when the MR moves. > > When the node is a host > > an application (of a MN) may not be able to cope with a change in the=20 > IP address of the MN when the MN moves. > > H Anthony Chan > > -----Original Message----- From: Alexandru Petrescu=20 > [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January 29, > 2014 12:30 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD > Evaluation: draft-ietf-dmm-requirements > > Le 28/01/2014 23:33, h chan a =E9crit : > >> Let us try to include MR. > >> > >> How about the following > >> > >> REQ2: Network-layer mobility support when needed > >> > >> DMM solutions MUST enable network-layer > >> mobility when needed. > >> Such mobility support is needed, for > >> example, when an application or a host cannot cope with a > change in the > >> IP address when a node moves. However, it is not always > necessary to maintain a > >> stable IP address or prefix. > >> > >> Here, the node can be a mobile host or a mobile router. > > I am not sure the term 'node' is agreed to cover both an MH and an MR. > > I think in all descriptions it would be clearer if we just said MH=20 > when we meant Mobile Host and MR when we meant Mobile Router. > > Le me paraphrase this text in RFC6275: > >> This document specifies a protocol that allows nodes to remain > >> reachable while moving around in the IPv6 Internet. Without specific > >> support for mobility in IPv6 [6], packets destined to a mobile node > >> would not be able to reach it while the mobile node is away from its > >> home link. > > There is a clear ambiguity in the 'mobile node' used above. Because=20 > if we talk moving networks then often the packets are destined (the=20 > contents of the destination address) to a LFN, not to the MR. > > If that 'node' were a Mobile Router (not a Mobile Host) it completely =20 > misses the case when packets are destined to the LFN, which is not an=20 > MH nor an MR. > > The phrase should rather say: > > 'packets destined to a MH (or to a LFN behind a MR) would not be able > > to reach it while that MH (or the MR and LFN) is away from its home > > link.' > > This kind if expression would be clearer. > > Alex > > 'packets destined to a [LFN] or to the Mobile Host, or to the Mobile =20 > Router, would not be able to reach it while the Mobile Router is away=20 > from its home link'. > >> A host can be a mobile host or a host in a LFN. > >> An application can be running on a mobile host or a on a host in a=20 >> LFN. > >> A MR also does not need to maintain stable IP address or prefix when > there are no hosts attached to it or when there are no active=20 > applications running in the hosts of its network. > >> > >> Any comments/changes/corrections? > >> > >> H Anthony Chan > >> > >> > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Tuesday, January 28, 2014 1:27 PM > >> To: h chan; dmm@ietf.org > >> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements > >> > >> Le 28/01/2014 19:58, h chan a =E9crit : > >>> Let me try to understand the concern here. > >>> > >>> What is new in this requirement is "when needed" in contrast to > >>> providing IP mobility by default. > >> > >> First, providing mobility by default is not a black/white alternative > to not providing mobility. > >> > >> It is very possible on the same machine to have Mobile IP enabled for > some flows and disabled for others (depending what we call a 'flow'). > >> It is also possible to have Mobile IP and NAT at the same time on the > same Mobile Router. > >> > >>> Without this requirement, mobility support may be provided by > >>> default, which is transparent to higher layers. > >> > >> Again, transparency to higher layers means we talk mobility > management on a Mobile Host. > >> > >> Transparency to higher layers has little meaning if we talk mobility > management provided on a Mobile Router (which is not a Mobile Host). > >> > >>> With this requirement, assume there are separate steps in the DMM > >>> solution. 1. A decision is made whether network-layer mobility > >>> support is needed. 2. When the need is established, network-layer > >>> mobility support is invoked. 3. Then transparent support is provided > >>> and is transparent to layers above IP. > >>> > >>> Transparency is clear in step 3 above. > >> > >> This looks like a trigger which enables mobility, or other times > disables it. > >> > >> But one can have a Mobile IP daemon and a NAT run at the same time on > the same machine. There is no decision in time. > >> > >> Some decision happens at packet based on IP destination address. > >> > >>> The question however is whether the preceding steps involve the > >>> application, so that one may question whether the entire DMM=20 >>> solution > >>> (with all the steps) as a whole is transparent. > >> > >> I agree. I am not aware of any application which talks to Mobile IP. > >> Whenever it is there it is 'transparent'. > >> > >>> So the intention of the requirement is that WHEN/AFTER the decision > >>> is made to invoke mobility support, then the mobility support is > >>> transparent to the application. Then we may want to check and make > >>> sure the emphasis of this requirement does mean transparency in this > >>> respect only. > >> > >> I disagree. > >> > >> As I said above, the word 'transparency' is dubious. Some times it >> > may mean 'non-existent', some times it may mean light goes through it =20 > but modified. > >> > >> If one wants to continue using it, then one should better qualify it > with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket=20 > Interface'. > >> > >> Because a Mobile Router doing mobility management in a transparent >> > manner on the Mobile Router for the LFN has nothing to do with=20 > applications, neither with upper layers. > >> > >> Also, a Mobile Router doing NAT and Mobile IP at the same time is > 50%-transparent. > >> > >>> > >>> Original wording: > >>> > >>> REQ2: Transparency to Upper Layers when needed > >>> > >>> DMM solutions MUST provide transparent mobility support above the IP > >>> layer when needed. Such transparency is needed, for example, when, > >> ^on a Mobile Host. > >>> upon change of point of attachment to the network, an application > >>> flow cannot cope with a change in the IP address. > >> > >> (it's not the application flow, it is a socket which some times may > >> break [paste here the error from the screen]; the term 'application > >> flow' in this context has little meaning) > >> > >> (an 'application flow' has no understandable meaning in practice). > >> > >>> However, it is not always necessary to maintain a stable home IP > >>> address or prefix for every application or at all times for a mobile > >>> node. > >> ^a Mobile Host. > >> > >> I agree. > >> > >>> I now tend to think the first sentence in this original wording may > >>> steer the emphasis on providing transparent support, which is not > >>> what the motivation and the problems are talking about. > >> > >> I agree. > >> > >>> The motivation and the problems are talking about when they are not > >>> needed. The emphasis of this requirement therefore is on the > >>> capability to turn OFF unnecessary mobility support. > >> > >> In a sense I agree with the meaning. > >> > >> But when trying to turn off or on mobility support the things are not > like if there were a knob on/off, not even like starting/stopping some=20 > daemon. It is a matter of always having the Mobile IP support on, and=20 > tweak the routing table with some particular entries, and the =20 > firewalling rules to NAT some addresses or not. > >> > >>> How about the following > >>> > >>> REQ2: Network-layer mobility support ONLY when needed > >> > >> If we understood better when it was needed... > >> > >>> DMM solutions MUST NOT provide network-layer mobility support when > >>> NOT needed. > >> > >> I would say that Mobile IP MUST always be turned on on a Mobile Host. > >> > >>> (or if you don't like double negatives: (DMM solutions MUST >>> provide > >>> network-layer mobility support ONLY when needed) > >> > >> No, I would say to have it always on. If some applications don't > want it then dont use it; realize that by inserting routing table > entries. > >> > >> One may wonder when some applications dont want it. One answer is >> > when some applications prefer to not go through the HA in order to > take advantage of the 4G pure speed. When? For example if the HA > link is too slow compared to 4G. (remark this is not the same as > saying that the triangular route is longer than straight, because > that is always true). > >> > >> This is not a request for Route Optimization. It is an invitation >> to > analyze in deeper detail the application needs. > >> > >> One may have an application start via the HA (offer reachability) >> and > continue straight, w/o HA. It's the same application. > >> > >> Consider a video-call like appli: you want to be reachable always >> at > the same IP address (through HA) but once the session is ongoing you > may not want to use it through HA if no handover in sight. > >> > >> Something like that. > >> > >> These things could be further refined if we really went into detail >> > and understood what are the needs of applications, the distinctions > MH-MR, etc. > >> > >>> Such transparent mobility support above the IP layer is needed, >>> for > >>> example, when, upon change of point of attachment to the network, >>> an > >>> application flow cannot cope with a change in the IP address. > >>> However, it is not always necessary to maintain a stable home IP > >>> address or prefix for every application or at all times for a >>> mobile > >>> node. > >> > >> A Mobile Host never maintains a stable prefix, only a stable >> address. > >> > >> A Mobile Router may maintain a stable address (its HoA) and may > maintain a stable prefix (its MNP). It could also just maintain > stable just its MNP, but not its HoA; and vice-versa. Is that > mobility? > >> > >> For each of these there is an application :-) > >> > >> Alex > >> > >>> > >>> Any comments/changes/corrections? > >>> > >>> H Anthony Chan > >>> > >>> -----Original Message----- From: dmm >>> [mailto:dmm-bounces@ietf.org] On > >>> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 >>> AM > >>> To: dmm@ietf.org Subject: Re: [DMM] AD >>> Evaluation: > >>> draft-ietf-dmm-requirements > >>> > >>> Le 28/01/2014 02:45, h chan a =E9crit : > >>>> I will drop "related" > >>>> > >>>> Regarding the following > >>>> > >>>> 5. Section 5: - I am a little confused by REQ2. It says that a >>>> DMM > >>>> solution should be transparent to the applications. > >>> > >>> This remark is typically true when we talk Mobile IP on a Mobile >>> Host > >>> and an application like firefox runs above a BSD Socket >>> interface. > >>> > >>> > >>>> However, the motivation talks about identifying applications >>>> that do > >>>> (or do not) need mobility support from the network layer. >>>> That > >>>> doesn't sound transparent to me. Am I reading this >>>> incorrectly? > >>>> > >>>> It appears that unless the network can find out whether the > >>>> application has need of such support, the application indeed >>>> may > >>>> need to invoke mobility support or has to convey its need to >>>> the > network. > >>>> > >>>> The emphasis of requirement is on "when needed." So, I think it >>>> is > >>>> better to drop the word "transparent" as follows: > >>>> > >>>> REQ2: Mobility support when needed > >>>> > >>>> DMM solutions MUST provide mobility support to above the IP >>>> layer > >>>> when needed. Such support is needed, for example, when, upon >>>> change > >>>> of point of attachment to the network, an application flow >>>> cannot > >>>> cope with a change in the IP address. However, it is not >>>> always > >>>> necessary to maintain a stable home IP address or prefix for >>>> every > >>>> application or at all times for a mobile node. > >>>> > >>>> Motivation: The motivation of this requirement is to enable >>>> more > >>>> efficient routing and more efficient use of network resources >>>> by > >>>> selecting an IP address or prefix according to whether >>>> mobility > >>>> support is needed and by not maintaining context at the >>>> mobility > >>>> anchor when there is no such need. > >>> > >>> Whenever we discuss this 'transparency' paragraph I have again >>> the > >>> same comments. > >>> > >>> First, I am not sure DMM is only about Mobile Hosts, or about >>> Mobile > >>> Routers as well. > >>> > >>> Because, if we talk Mobile Routers, then rarely an application >>> runs > >>> directly on it. Most applications would run on LFN. > >>> > >>> Transparency? > >>> > >>> If the applications run on the LFN, the change of the attachment >>> of > >>> the MR is 'transparent' to them, regardless whether or not MR >>> does > >>> something to maintain stability of that address (Mobile IP, >>> other). > >>> > >>> Second, this transparency may depend on the direction, or more > >>> complex 'shape' of the application flows. Some IP flows of some > >>> applications have very complex 'shapes', with various sets of IP >>> src > >>> and dst, and triangular or HA-less shapes. > >>> > >>> Take for example a video-call. The session establishment through >>> an > >>> intermediary and behind NAT is followed by the ongoing 4 flows >>> (2 > >>> audio 2 video)... they all take different paths... each may need >>> or > >>> not need to go through the HA, and each has distinct behaviours >>> when > >>> the IP address changes, hence each would have a distinct > >>> 'transparency' requirement. Is this _one_ application? > >>> > >>> Alex > >>> > >>>> > >>>> H Anthony Chan > >>>> > >>>> -----Original Message----- From: dmm >>>> [mailto:dmm-bounces@ietf.org] > >>>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 >>>> AM > >>>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org > ; > >>>> dmm@ietf.org ; Peter McCann Subject: Re: >>>> [DMM] > AD Evaluation: > >>>> draft-ietf-dmm-requirements > >>>> > >>>> > >>>> > >>>> On 1/24/14 7:38 PM, h chan wrote: > >>>>> 4. Section 4: - I am not sure that it benefits the document >>>>> to > >>>>> label > >>>>> PS6 and PS7 as related. Those issues are problematic on >>>>> their own. > >>>>> If you remove the "(related problem)" label from them, make >>>>> sure > >>>>> that REQ2 is updated to remove mention of "related problem". > >>>>> > >>>>> The intention of the name "related problems" was not to >>>>> suggest > >>>>> they are less problematic, but rather to distinguish them >>>>> from the > >>>>> other problems directly on mobility management. Although >>>>> these > >>>>> problems are not directly on mobility management, the DMM >>>>> solutions > >>>>> can solve these additional problems. They are therefore >>>>> included. > >>>>> So, as long as this section is not to be interpreted as >>>>> limited to > >>>>> problems directly on mobility management, we can drop the >>>>> word > "related." > >>>>> > >>>> > >>>> I will leave it to the authors/WG, but I don't see a benefit to >>>> the > >>>> "related" tag. > >>>> > >>>> 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 alexandru.petrescu@gmail.com Thu Jan 30 09:39:49 2014 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 C6C8A1A03F3 for ; Thu, 30 Jan 2014 09:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 79SyV0Ij2sgX for ; Thu, 30 Jan 2014 09:39:44 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8140D1A0438 for ; Thu, 30 Jan 2014 09:39:43 -0800 (PST) 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 s0UHdZ2a008956; Thu, 30 Jan 2014 18:39:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 76010203C7E; Thu, 30 Jan 2014 18:39:46 +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 69E172011ED; Thu, 30 Jan 2014 18:39:46 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0UHdJiI014112; Thu, 30 Jan 2014 18:39:34 +0100 Message-ID: <52EA8E42.5000000@gmail.com> Date: Thu, 30 Jan 2014 18:39:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "dmm@ietf.org" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E948AC.6030904@gmail.com> <6E31144C030982429702B11D6746B98C370EB866@szxeml557-mbx.china.huawei.com> <52EA09A0.70109@gmail.com> <6E31144C030982429702B11D6746B98C370EB9B3@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB9B3@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 17:39:50 -0000 Le 30/01/2014 18:08, h chan a écrit : > Alex, > > Is the following correct? > > Mobility support is needed, for example, when a mobile host or a > mobile router moves and an application in the mobile host or in a > host that moves with the router cannot cope with a change in the IP > address of the mobile node. Makes better sense, thanks. But still uses that word 'Mobile Node' which is confusing. How about this: > Mobility support is needed, for example, when a Mobile Host or a > Mobile Router moves and an application in the Mobile Host or in a > host or router that moves with that Mobile Router cannot cope with a > change in the IP address of the mobile host or of that Mobile > Router. It would be more precise. But even then, it does not hold, because a Host that moves with the Mobile Router is not that much influenced by the change of IP address of that MR. When the MR changes its IP address, the Host feels it just like some other interruption in the path to another CN. These kinds of interruptions (link up/down) happen often in the fixed networks and yet Hosts continue to work. It is possible, for example, to have a Mobile Router move, have NAT (not mobility management), change IP address, and the Hosts and Routers in that moving network will continue working ok. It is also possible for MR to not have NAT, and forward packets with an address which is not topological correct in that network. These packets will reach their destinations (provided there's no ingress filtering), and the replies will not arrive. Some applications do not need packets to return. One can very well have a vehicle which streams the video of its front camera to some particular server in the Internet, and change its IP address at each access. This does not require Mobile IP nor NAT. I think it is impossible to stay meaningful in one phrase talking both Mobile Host and Mobile Router at the same time. I think we need maybe two phrases. > Mobility Support on a Mobile Host is needed, for example, when a > Mobile Host moves and an arbitrary application in the Mobile Host > cannot cope with a change in the IP address of that Mobile Host > [paste socket error message here]. > > Mobility Support on a Mobile Router is needed, for example, when a > Mobile Router moves together with a set of Hosts and Routers, and > arbitrary applications in the Hosts and Routers need to maintain > their IP address fixed regardless of the change of the IP address of > the Mobile Router, and the Access Router performs ingress filtering, > and reachability of these Hosts and Routers at a fixed IP address is > necessary. Alex > > H Anthony Chan > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, January 30, > 2014 2:13 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD > Evaluation: draft-ietf-dmm-requirements > > Le 29/01/2014 20:45, h chan a écrit : >> Alex >> >> How about the following: >> >> REQ2: Using and not Using Network-layer mobility support >> >> DMM solutions MUST enable network-layer mobility >> >> but it MUST be possible to not invoke it. >> >> Mobility support is needed, for example, >> >> when an application (of a MN or a host in a mobile network of a >> MR) > ^a LFN (because just 'host' may be confused with Mobile Host; and > also because within the moving network there is also one or several > Routers - not hosts.) > >> cannot cope with a change in the >> >> IP address of the mobile node when the node moves. > ^Mobile Host or of the Mobile Router moves (because when the 'node' > moves it may mean that the 'host' in the moving network moves, and > that doesn't change its IP address). > >> Yet a mobile node can often be stationary, >> >> and mobility support can also be provided at other layers. >> >> It is then not always necessary to maintain a >> >> stable IP address or prefix. >> >> Can the text in red be valid for both host or router? > > Yes and no. I agree with it, but I'd prefer the suggested > modifications. > > Alex > >> >> When the node is a router: >> >> an application (of a host in a mobile network) may not be able to >> cope with a change in the IP address of the MR when the MR moves. >> >> When the node is a host >> >> an application (of a MN) may not be able to cope with a change in >> the IP address of the MN when the MN moves. >> >> H Anthony Chan >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January 29, >> 2014 12:30 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD >> Evaluation: draft-ietf-dmm-requirements >> >> Le 28/01/2014 23:33, h chan a écrit : >> >>> Let us try to include MR. >> >>> >> >>> How about the following >> >>> >> >>> REQ2: Network-layer mobility support when needed >> >>> >> >>> DMM solutions MUST enable network-layer >> >>> mobility when needed. >> >>> Such mobility support is needed, for >> >>> example, when an application or a host cannot cope with a >> change in the >> >>> IP address when a node moves. However, it is not always >> necessary to maintain a >> >>> stable IP address or prefix. >> >>> >> >>> Here, the node can be a mobile host or a mobile router. >> >> I am not sure the term 'node' is agreed to cover both an MH and an >> MR. >> >> I think in all descriptions it would be clearer if we just said MH >> when we meant Mobile Host and MR when we meant Mobile Router. >> >> Le me paraphrase this text in RFC6275: >> >>> This document specifies a protocol that allows nodes to remain >> >>> reachable while moving around in the IPv6 Internet. Without >>> specific >> >>> support for mobility in IPv6 [6], packets destined to a mobile >>> node >> >>> would not be able to reach it while the mobile node is away from >>> its >> >>> home link. >> >> There is a clear ambiguity in the 'mobile node' used above. Because >> if we talk moving networks then often the packets are destined (the >> contents of the destination address) to a LFN, not to the MR. >> >> If that 'node' were a Mobile Router (not a Mobile Host) it >> completely misses the case when packets are destined to the LFN, >> which is not an MH nor an MR. >> >> The phrase should rather say: >> >> 'packets destined to a MH (or to a LFN behind a MR) would not be >> able >> >> to reach it while that MH (or the MR and LFN) is away from its >> home >> >> link.' >> >> This kind if expression would be clearer. >> >> Alex >> >> 'packets destined to a [LFN] or to the Mobile Host, or to the >> Mobile Router, would not be able to reach it while the Mobile >> Router is away from its home link'. >> >>> A host can be a mobile host or a host in a LFN. >> >>> An application can be running on a mobile host or a on a host in >>> a LFN. >> >>> A MR also does not need to maintain stable IP address or prefix >>> when >> there are no hosts attached to it or when there are no active >> applications running in the hosts of its network. >> >>> >> >>> Any comments/changes/corrections? >> >>> >> >>> H Anthony Chan >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> >>> Sent: Tuesday, January 28, 2014 1:27 PM >> >>> To: h chan; dmm@ietf.org >> >>> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements >> >>> >> >>> Le 28/01/2014 19:58, h chan a écrit : >> >>>> Let me try to understand the concern here. >> >>>> >> >>>> What is new in this requirement is "when needed" in contrast >>>> to >> >>>> providing IP mobility by default. >> >>> >> >>> First, providing mobility by default is not a black/white >>> alternative >> to not providing mobility. >> >>> >> >>> It is very possible on the same machine to have Mobile IP >>> enabled for >> some flows and disabled for others (depending what we call a >> 'flow'). >> >>> It is also possible to have Mobile IP and NAT at the same time >>> on the >> same Mobile Router. >> >>> >> >>>> Without this requirement, mobility support may be provided by >> >>>> default, which is transparent to higher layers. >> >>> >> >>> Again, transparency to higher layers means we talk mobility >> management on a Mobile Host. >> >>> >> >>> Transparency to higher layers has little meaning if we talk >>> mobility >> management provided on a Mobile Router (which is not a Mobile >> Host). >> >>> >> >>>> With this requirement, assume there are separate steps in the >>>> DMM >> >>>> solution. 1. A decision is made whether network-layer mobility >> >>>> support is needed. 2. When the need is established, >>>> network-layer >> >>>> mobility support is invoked. 3. Then transparent support is >>>> provided >> >>>> and is transparent to layers above IP. >> >>>> >> >>>> Transparency is clear in step 3 above. >> >>> >> >>> This looks like a trigger which enables mobility, or other times >> disables it. >> >>> >> >>> But one can have a Mobile IP daemon and a NAT run at the same >>> time on >> the same machine. There is no decision in time. >> >>> >> >>> Some decision happens at packet based on IP destination address. >> >>> >> >>>> The question however is whether the preceding steps involve >>>> the >> >>>> application, so that one may question whether the entire DMM >>>> solution >> >>>> (with all the steps) as a whole is transparent. >> >>> >> >>> I agree. I am not aware of any application which talks to >>> Mobile IP. >> >>> Whenever it is there it is 'transparent'. >> >>> >> >>>> So the intention of the requirement is that WHEN/AFTER the >>>> decision >> >>>> is made to invoke mobility support, then the mobility support >>>> is >> >>>> transparent to the application. Then we may want to check and >>>> make >> >>>> sure the emphasis of this requirement does mean transparency >>>> in this >> >>>> respect only. >> >>> >> >>> I disagree. >> >>> >> >>> As I said above, the word 'transparency' is dubious. Some times >>> it >>> >> may mean 'non-existent', some times it may mean light goes through >> it but modified. >> >>> >> >>> If one wants to continue using it, then one should better >>> qualify it >> with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket >> Interface'. >> >>> >> >>> Because a Mobile Router doing mobility management in a >>> transparent >>> >> manner on the Mobile Router for the LFN has nothing to do with >> applications, neither with upper layers. >> >>> >> >>> Also, a Mobile Router doing NAT and Mobile IP at the same time >>> is >> 50%-transparent. >> >>> >> >>>> >> >>>> Original wording: >> >>>> >> >>>> REQ2: Transparency to Upper Layers when needed >> >>>> >> >>>> DMM solutions MUST provide transparent mobility support above >>>> the IP >> >>>> layer when needed. Such transparency is needed, for example, >>>> when, >> >>> ^on a Mobile Host. >> >>>> upon change of point of attachment to the network, an >>>> application >> >>>> flow cannot cope with a change in the IP address. >> >>> >> >>> (it's not the application flow, it is a socket which some times >>> may >> >>> break [paste here the error from the screen]; the term >>> 'application >> >>> flow' in this context has little meaning) >> >>> >> >>> (an 'application flow' has no understandable meaning in >>> practice). >> >>> >> >>>> However, it is not always necessary to maintain a stable home >>>> IP >> >>>> address or prefix for every application or at all times for a >>>> mobile >> >>>> node. >> >>> ^a Mobile Host. >> >>> >> >>> I agree. >> >>> >> >>>> I now tend to think the first sentence in this original >>>> wording may >> >>>> steer the emphasis on providing transparent support, which is >>>> not >> >>>> what the motivation and the problems are talking about. >> >>> >> >>> I agree. >> >>> >> >>>> The motivation and the problems are talking about when they >>>> are not >> >>>> needed. The emphasis of this requirement therefore is on the >> >>>> capability to turn OFF unnecessary mobility support. >> >>> >> >>> In a sense I agree with the meaning. >> >>> >> >>> But when trying to turn off or on mobility support the things >>> are not >> like if there were a knob on/off, not even like starting/stopping >> some daemon. It is a matter of always having the Mobile IP >> support on, and tweak the routing table with some particular >> entries, and the firewalling rules to NAT some addresses or not. >> >>> >> >>>> How about the following >> >>>> >> >>>> REQ2: Network-layer mobility support ONLY when needed >> >>> >> >>> If we understood better when it was needed... >> >>> >> >>>> DMM solutions MUST NOT provide network-layer mobility support >>>> when >> >>>> NOT needed. >> >>> >> >>> I would say that Mobile IP MUST always be turned on on a Mobile >>> Host. >> >>> >> >>>> (or if you don't like double negatives: (DMM solutions MUST >>>> provide >> >>>> network-layer mobility support ONLY when needed) >> >>> >> >>> No, I would say to have it always on. If some applications >>> don't >> want it then dont use it; realize that by inserting routing table >> entries. >> >>> >> >>> One may wonder when some applications dont want it. One answer >>> is >>> >> when some applications prefer to not go through the HA in order to >> take advantage of the 4G pure speed. When? For example if the HA >> link is too slow compared to 4G. (remark this is not the same as >> saying that the triangular route is longer than straight, because >> that is always true). >> >>> >> >>> This is not a request for Route Optimization. It is an >>> invitation to >> analyze in deeper detail the application needs. >> >>> >> >>> One may have an application start via the HA (offer reachability) >>> and >> continue straight, w/o HA. It's the same application. >> >>> >> >>> Consider a video-call like appli: you want to be reachable always >>> at >> the same IP address (through HA) but once the session is ongoing >> you may not want to use it through HA if no handover in sight. >> >>> >> >>> Something like that. >> >>> >> >>> These things could be further refined if we really went into >>> detail >>> >> and understood what are the needs of applications, the distinctions >> MH-MR, etc. >> >>> >> >>>> Such transparent mobility support above the IP layer is needed, >>>> for >> >>>> example, when, upon change of point of attachment to the >>>> network, an >> >>>> application flow cannot cope with a change in the IP address. >> >>>> However, it is not always necessary to maintain a stable home >>>> IP >> >>>> address or prefix for every application or at all times for a >>>> mobile >> >>>> node. >> >>> >> >>> A Mobile Host never maintains a stable prefix, only a stable >>> address. >> >>> >> >>> A Mobile Router may maintain a stable address (its HoA) and may >> maintain a stable prefix (its MNP). It could also just maintain >> stable just its MNP, but not its HoA; and vice-versa. Is that >> mobility? >> >>> >> >>> For each of these there is an application :-) >> >>> >> >>> Alex >> >>> >> >>>> >> >>>> Any comments/changes/corrections? >> >>>> >> >>>> H Anthony Chan >> >>>> >> >>>> -----Original Message----- From: dmm >>>> [mailto:dmm-bounces@ietf.org] On >> >>>> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 >>>> 8:43 AM >> >>>> To: dmm@ietf.org Subject: Re: [DMM] AD >>>> Evaluation: >> >>>> draft-ietf-dmm-requirements >> >>>> >> >>>> Le 28/01/2014 02:45, h chan a écrit : >> >>>>> I will drop "related" >> >>>>> >> >>>>> Regarding the following >> >>>>> >> >>>>> 5. Section 5: - I am a little confused by REQ2. It says >>>>> that a DMM >> >>>>> solution should be transparent to the applications. >> >>>> >> >>>> This remark is typically true when we talk Mobile IP on a >>>> Mobile Host >> >>>> and an application like firefox runs above a BSD Socket >>>> interface. >> >>>> >> >>>> >> >>>>> However, the motivation talks about identifying applications >>>>> that do >> >>>>> (or do not) need mobility support from the network layer. >>>>> That >> >>>>> doesn't sound transparent to me. Am I reading this >>>>> incorrectly? >> >>>>> >> >>>>> It appears that unless the network can find out whether the >> >>>>> application has need of such support, the application indeed >>>>> may >> >>>>> need to invoke mobility support or has to convey its need to >>>>> the >> network. >> >>>>> >> >>>>> The emphasis of requirement is on "when needed." So, I think >>>>> it is >> >>>>> better to drop the word "transparent" as follows: >> >>>>> >> >>>>> REQ2: Mobility support when needed >> >>>>> >> >>>>> DMM solutions MUST provide mobility support to above the IP >>>>> layer >> >>>>> when needed. Such support is needed, for example, when, upon >>>>> change >> >>>>> of point of attachment to the network, an application flow >>>>> cannot >> >>>>> cope with a change in the IP address. However, it is not >>>>> always >> >>>>> necessary to maintain a stable home IP address or prefix for >>>>> every >> >>>>> application or at all times for a mobile node. >> >>>>> >> >>>>> Motivation: The motivation of this requirement is to enable >>>>> more >> >>>>> efficient routing and more efficient use of network resources >>>>> by >> >>>>> selecting an IP address or prefix according to whether >>>>> mobility >> >>>>> support is needed and by not maintaining context at the >>>>> mobility >> >>>>> anchor when there is no such need. >> >>>> >> >>>> Whenever we discuss this 'transparency' paragraph I have again >>>> the >> >>>> same comments. >> >>>> >> >>>> First, I am not sure DMM is only about Mobile Hosts, or about >>>> Mobile >> >>>> Routers as well. >> >>>> >> >>>> Because, if we talk Mobile Routers, then rarely an application >>>> runs >> >>>> directly on it. Most applications would run on LFN. >> >>>> >> >>>> Transparency? >> >>>> >> >>>> If the applications run on the LFN, the change of the >>>> attachment of >> >>>> the MR is 'transparent' to them, regardless whether or not MR >>>> does >> >>>> something to maintain stability of that address (Mobile IP, >>>> other). >> >>>> >> >>>> Second, this transparency may depend on the direction, or more >> >>>> complex 'shape' of the application flows. Some IP flows of >>>> some >> >>>> applications have very complex 'shapes', with various sets of >>>> IP src >> >>>> and dst, and triangular or HA-less shapes. >> >>>> >> >>>> Take for example a video-call. The session establishment >>>> through an >> >>>> intermediary and behind NAT is followed by the ongoing 4 flows >>>> (2 >> >>>> audio 2 video)... they all take different paths... each may >>>> need or >> >>>> not need to go through the HA, and each has distinct behaviours >>>> when >> >>>> the IP address changes, hence each would have a distinct >> >>>> 'transparency' requirement. Is this _one_ application? >> >>>> >> >>>> Alex >> >>>> >> >>>>> >> >>>>> H Anthony Chan >> >>>>> >> >>>>> -----Original Message----- From: dmm >>>>> [mailto:dmm-bounces@ietf.org] >> >>>>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 >>>>> 7:20 AM >> >>>>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org >> ; >> >>>>> dmm@ietf.org ; Peter McCann Subject: Re: >>>>> [DMM] >> AD Evaluation: >> >>>>> draft-ietf-dmm-requirements >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 1/24/14 7:38 PM, h chan wrote: >> >>>>>> 4. Section 4: - I am not sure that it benefits the document >>>>>> to >> >>>>>> label >> >>>>>> PS6 and PS7 as related. Those issues are problematic on >>>>>> their own. >> >>>>>> If you remove the "(related problem)" label from them, make >>>>>> sure >> >>>>>> that REQ2 is updated to remove mention of "related >>>>>> problem". >> >>>>>> >> >>>>>> The intention of the name "related problems" was not to >>>>>> suggest >> >>>>>> they are less problematic, but rather to distinguish them >>>>>> from the >> >>>>>> other problems directly on mobility management. Although >>>>>> these >> >>>>>> problems are not directly on mobility management, the DMM >>>>>> solutions >> >>>>>> can solve these additional problems. They are therefore >>>>>> included. >> >>>>>> So, as long as this section is not to be interpreted as >>>>>> limited to >> >>>>>> problems directly on mobility management, we can drop the >>>>>> word >> "related." >> >>>>>> >> >>>>> >> >>>>> I will leave it to the authors/WG, but I don't see a benefit >>>>> to the >> >>>>> "related" tag. >> >>>>> >> >>>>> 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 h.anthony.chan@huawei.com Thu Jan 30 10:46:33 2014 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 EB6B71A0435 for ; Thu, 30 Jan 2014 10:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 fSFMvoqt5Idj for ; Thu, 30 Jan 2014 10:46:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3A1A0072 for ; Thu, 30 Jan 2014 10:46:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDC36236; Thu, 30 Jan 2014 18:46:27 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 18:46:00 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 18:46:23 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.03.0158.001; Fri, 31 Jan 2014 02:46:19 +0800 From: h chan To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHcPLbFS3MZ7cnEiWkYjZb/tqwZqdgMOA Date: Thu, 30 Jan 2014 18:46:18 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB9EF@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E90F7A.3050902@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB829@szxeml557-mbx.china.huawei.com> <52EA5B42.3050002@innovationslab.net> In-Reply-To: <52EA5B42.3050002@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 18:46:34 -0000 The reason for this requirement is that in some existing mobility managemen= t deployment, in order to support those applications that does need network= -layer mobility support, the mobile host uses HoA so that all the applicati= ons must use the HoA. Then it does not make it possible for an application = to not use HoA. =20 So the bottom line in this revision is that the DMM solution only allows th= e possibility of not using the network-layer mobility support.=20 How to make use of this possibility is now not a part of this requirement. = Therefore the requirement should avoid implication of such mechanisms. When we called "when needed", there may be implication of a mechanism to de= termine/convey the need. When we call it "invoke", there may be implication of a mechanism to invoke= . Let me try the following: REQ2: Bypassable Network-layer mobility support =20 DMM solutions MUST enable network-layer mobility but it MUST be possible to bypass it. (plus other sentences on the need and the no need to serve as ex= planations only to justify the above) H Anthony Chan -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: Thursday, January 30, 2014 8:02 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Hi Anthony, On 1/29/14 1:51 PM, h chan wrote: > Brian, >=20 > The requirement is intended to include a capability of not using=20 > network-layer mobility management, as opposed to using it by default. >=20 >=20 > I think it is sufficient to leave to the explanation (the sentences=20 > after the first sentence) to say that network-layer mobility support=20 > is not always needed in order to justify this capability. >=20 > The alternative then is to say that network-layer mobility is provided=20 > but it is possible to not use such support. >=20 > REQ2: Using and not Using Network-layer mobility support >=20 > DMM solutions MUST enable network-layer mobility but it MUST be=20 > possible to not invoke it. Mobility support is needed, for example,=20 > when an application or a host cannot cope with a change in the IP=20 > address when a node moves. Yet a mobile node can often be stationary,=20 > and mobility support can also be provided at other layers. It is then=20 > not always necessary to maintain a stable IP address or prefix. >=20 > Of cause "enable" does not mean it must be used. Yet explicitly say=20 > "it is possible to not invoke it" is to draw the contrast to using it=20 > by default. My only concern is that it is unclear *who* invokes the network-layer mobil= ity support. Is it envisioned that the application can signal the need for= mobility support? Does the user have to configure which applications get = support? Regards, Brian From h.anthony.chan@huawei.com Thu Jan 30 11:53:33 2014 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 E8A651A046B for ; Thu, 30 Jan 2014 11:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.736 X-Spam-Level: X-Spam-Status: No, score=-6.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 P5oqsd-l2Uzv for ; Thu, 30 Jan 2014 11:53:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4448F1A0450 for ; Thu, 30 Jan 2014 11:53:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAQ43484; Thu, 30 Jan 2014 19:53:24 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 19:52:56 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Jan 2014 19:53:19 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.03.0158.001; Fri, 31 Jan 2014 03:53:15 +0800 From: h chan To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHeJCOcwZGfou5k2mKo8YEkHEcpqdnm4g Date: Thu, 30 Jan 2014 19:53:14 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EB9FD@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E948AC.6030904@gmail.com> <6E31144C030982429702B11D6746B98C370EB866@szxeml557-mbx.china.huawei.com> <52EA09A0.70109@gmail.com> <6E31144C030982429702B11D6746B98C370EB9B3@szxeml557-mbx.china.huawei.com> <52EA8E42.5000000@gmail.com> In-Reply-To: <52EA8E42.5000000@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 19:53:34 -0000 Alex, I think the applications which work without MIP are the applications that c= an cope with the change of IP address of the MR. Is that correct? Then mobi= lity support is needed only for those applications that cannot cope with th= e change of IP address of the MR. So, in the two separate sentences: > Mobility Support on a Mobile Host is needed, for example, when a=20 > Mobile Host moves and an arbitrary application in the Mobile Host=20 > cannot cope with a change in the IP address of that Mobile Host [paste=20 > socket error message here]. Is this MN sentence the same as: Mobility support is needed, for example,=20 when a mobile host moves and an application=20 cannot cope with a change in the IP address of the mobile host. > Mobility Support on a Mobile Router is needed, for example, when a=20 > Mobile Router moves together with a set of Hosts and Routers, and=20 > arbitrary applications in the Hosts and Routers need to maintain their=20 > IP address fixed regardless of the change of the IP address of the=20 > Mobile Router, and the Access Router performs ingress filtering, and=20 > reachability of these Hosts and Routers at a fixed IP address is =20 > necessary. When the MR carries a network of hosts and routers, doesn't these routers i= n turn carry network so that at the final level of hosts, the applications = are running there. If so, is it sufficient to state the applications in the= hosts? (which includes hosts in the network of routers which are in turn i= n the network of the mobile router) So a host in the network of a router, which in turn is in the network of an= other router, which .... in the network of the mobile router can be called = a host that moves with the mobile router.=20 Then is the MR sentence the above the same as Mobility support is also needed, for example,=20 when a mobile router moves together and an application in a host that moves with the mobile router=20 cannot cope with a change of IP address of the mobile router. REQ2: Bypassable Network-layer mobility support =20 DMM solutions MUST enable network-layer mobility but it MUST be possible to not use it. Mobility support is needed, for example,=20 when a mobile host moves and an application=20 cannot cope with a change in the IP address. Mobility support is also needed, for example,=20 when a mobile router moves together and an application in a host which moves with the mobile router= =20 cannot cope with a change of IP address of the mobile router. However mobility support at the network-layer is not always need= ed; a mobile node can often be stationary, and mobility support can also be provided at other layers. It is then not always necessary to maintain a stable IP address or prefix. One more alternative is to mention the "no need" case only without explaini= ng the "needed" case as in the following. Yet if it is possible to state th= e "needed" case more concisely, it will be more clear to spell that out as = in above.=20 REQ2: Bypassable Network-layer mobility support =20 DMM solutions MUST enable network-layer mobility but it MUST be possible to not use it. Mobility support at the network-layer is not always needed; a mobile node can often be stationary, and mobility support can also be provided at other layers. It is then not always necessary to maintain a stable IP address or prefix. H Anthony Chan -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, January 30, 2014 11:39 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Le 30/01/2014 18:08, h chan a =E9crit : > Alex, > > Is the following correct? > > Mobility support is needed, for example, when a mobile host or a=20 > mobile router moves and an application in the mobile host or in a host=20 > that moves with the router cannot cope with a change in the IP address=20 > of the mobile node. Makes better sense, thanks. But still uses that word 'Mobile Node' which is confusing. How about this: > Mobility support is needed, for example, when a Mobile Host or a=20 > Mobile Router moves and an application in the Mobile Host or in a host=20 > or router that moves with that Mobile Router cannot cope with a change=20 > in the IP address of the mobile host or of that Mobile Router. It would be more precise. But even then, it does not hold, because a Host that moves with the Mobile = Router is not that much influenced by the change of IP address of that MR. = When the MR changes its IP address, the Host feels it just like some other= interruption in the path to another CN. These kinds of interruptions (lin= k up/down) happen often in the fixed networks and yet Hosts continue to wor= k. It is possible, for example, to have a Mobile Router move, have NAT (not mo= bility management), change IP address, and the Hosts and Routers in that mo= ving network will continue working ok. It is also possible for MR to not have NAT, and forward packets with an add= ress which is not topological correct in that network. These packets will = reach their destinations (provided there's no ingress filtering), and the r= eplies will not arrive. Some applications do not need packets to return. = One can very well have a vehicle which streams the video of its front camer= a to some particular server in the Internet, and change its IP address at e= ach access. This does not require Mobile IP nor NAT. I think it is impossible to stay meaningful in one phrase talking both Mobi= le Host and Mobile Router at the same time. I think we need maybe two phra= ses. > Mobility Support on a Mobile Host is needed, for example, when a=20 > Mobile Host moves and an arbitrary application in the Mobile Host=20 > cannot cope with a change in the IP address of that Mobile Host [paste=20 > socket error message here]. > > Mobility Support on a Mobile Router is needed, for example, when a=20 > Mobile Router moves together with a set of Hosts and Routers, and=20 > arbitrary applications in the Hosts and Routers need to maintain their=20 > IP address fixed regardless of the change of the IP address of the=20 > Mobile Router, and the Access Router performs ingress filtering, and=20 > reachability of these Hosts and Routers at a fixed IP address is =20 > necessary. Alex > > H Anthony Chan > > -----Original Message----- From: Alexandru Petrescu=20 > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, January 30, > 2014 2:13 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD > Evaluation: draft-ietf-dmm-requirements > > Le 29/01/2014 20:45, h chan a =E9crit : >> Alex >> >> How about the following: >> >> REQ2: Using and not Using Network-layer mobility support >> >> DMM solutions MUST enable network-layer mobility >> >> but it MUST be possible to not invoke it. >> >> Mobility support is needed, for example, >> >> when an application (of a MN or a host in a mobile network of a >> MR) > ^a LFN (because just 'host' may be confused with Mobile Host; and also=20 > because within the moving network there is also one or several Routers=20 > - not hosts.) > >> cannot cope with a change in the >> >> IP address of the mobile node when the node moves. > ^Mobile Host or of the Mobile Router moves (because when the 'node' > moves it may mean that the 'host' in the moving network moves, and=20 > that doesn't change its IP address). > >> Yet a mobile node can often be stationary, >> >> and mobility support can also be provided at other layers. >> >> It is then not always necessary to maintain a >> >> stable IP address or prefix. >> >> Can the text in red be valid for both host or router? > > Yes and no. I agree with it, but I'd prefer the suggested=20 > modifications. > > Alex > >> >> When the node is a router: >> >> an application (of a host in a mobile network) may not be able to=20 >> cope with a change in the IP address of the MR when the MR moves. >> >> When the node is a host >> >> an application (of a MN) may not be able to cope with a change in the=20 >> IP address of the MN when the MN moves. >> >> H Anthony Chan >> >> -----Original Message----- From: Alexandru Petrescu=20 >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January 29, >> 2014 12:30 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD >> Evaluation: draft-ietf-dmm-requirements >> >> Le 28/01/2014 23:33, h chan a =E9crit : >> >>> Let us try to include MR. >> >>> >> >>> How about the following >> >>> >> >>> REQ2: Network-layer mobility support when needed >> >>> >> >>> DMM solutions MUST enable network-layer >> >>> mobility when needed. >> >>> Such mobility support is needed, for >> >>> example, when an application or a host cannot cope with a >> change in the >> >>> IP address when a node moves. However, it is not always >> necessary to maintain a >> >>> stable IP address or prefix. >> >>> >> >>> Here, the node can be a mobile host or a mobile router. >> >> I am not sure the term 'node' is agreed to cover both an MH and an=20 >> MR. >> >> I think in all descriptions it would be clearer if we just said MH =20 >> when we meant Mobile Host and MR when we meant Mobile Router. >> >> Le me paraphrase this text in RFC6275: >> >>> This document specifies a protocol that allows nodes to remain >> >>> reachable while moving around in the IPv6 Internet. Without=20 >>> specific >> >>> support for mobility in IPv6 [6], packets destined to a mobile node >> >>> would not be able to reach it while the mobile node is away from its >> >>> home link. >> >> There is a clear ambiguity in the 'mobile node' used above. Because=20 >> if we talk moving networks then often the packets are destined (the=20 >> contents of the destination address) to a LFN, not to the MR. >> >> If that 'node' were a Mobile Router (not a Mobile Host) it completely=20 >> misses the case when packets are destined to the LFN, which is not an=20 >> MH nor an MR. >> >> The phrase should rather say: >> >> 'packets destined to a MH (or to a LFN behind a MR) would not be able >> >> to reach it while that MH (or the MR and LFN) is away from its home >> >> link.' >> >> This kind if expression would be clearer. >> >> Alex >> >> 'packets destined to a [LFN] or to the Mobile Host, or to the Mobile=20 >> Router, would not be able to reach it while the Mobile Router is away=20 >> from its home link'. >> >>> A host can be a mobile host or a host in a LFN. >> >>> An application can be running on a mobile host or a on a host in a=20 >>> LFN. >> >>> A MR also does not need to maintain stable IP address or prefix when >> there are no hosts attached to it or when there are no active=20 >> applications running in the hosts of its network. >> >>> >> >>> Any comments/changes/corrections? >> >>> >> >>> H Anthony Chan >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> >>> Sent: Tuesday, January 28, 2014 1:27 PM >> >>> To: h chan; dmm@ietf.org >> >>> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements >> >>> >> >>> Le 28/01/2014 19:58, h chan a =E9crit : >> >>>> Let me try to understand the concern here. >> >>>> >> >>>> What is new in this requirement is "when needed" in contrast to >> >>>> providing IP mobility by default. >> >>> >> >>> First, providing mobility by default is not a black/white=20 >>> alternative >> to not providing mobility. >> >>> >> >>> It is very possible on the same machine to have Mobile IP enabled=20 >>> for >> some flows and disabled for others (depending what we call a 'flow'). >> >>> It is also possible to have Mobile IP and NAT at the same time on=20 >>> the >> same Mobile Router. >> >>> >> >>>> Without this requirement, mobility support may be provided by >> >>>> default, which is transparent to higher layers. >> >>> >> >>> Again, transparency to higher layers means we talk mobility >> management on a Mobile Host. >> >>> >> >>> Transparency to higher layers has little meaning if we talk mobility >> management provided on a Mobile Router (which is not a Mobile Host). >> >>> >> >>>> With this requirement, assume there are separate steps in the DMM >> >>>> solution. 1. A decision is made whether network-layer mobility >> >>>> support is needed. 2. When the need is established, network-layer >> >>>> mobility support is invoked. 3. Then transparent support is=20 >>>> provided >> >>>> and is transparent to layers above IP. >> >>>> >> >>>> Transparency is clear in step 3 above. >> >>> >> >>> This looks like a trigger which enables mobility, or other times >> disables it. >> >>> >> >>> But one can have a Mobile IP daemon and a NAT run at the same time=20 >>> on >> the same machine. There is no decision in time. >> >>> >> >>> Some decision happens at packet based on IP destination address. >> >>> >> >>>> The question however is whether the preceding steps involve the >> >>>> application, so that one may question whether the entire DMM=20 >>>> solution >> >>>> (with all the steps) as a whole is transparent. >> >>> >> >>> I agree. I am not aware of any application which talks to Mobile=20 >>> IP. >> >>> Whenever it is there it is 'transparent'. >> >>> >> >>>> So the intention of the requirement is that WHEN/AFTER the decision >> >>>> is made to invoke mobility support, then the mobility support is >> >>>> transparent to the application. Then we may want to check and make >> >>>> sure the emphasis of this requirement does mean transparency in=20 >>>> this >> >>>> respect only. >> >>> >> >>> I disagree. >> >>> >> >>> As I said above, the word 'transparency' is dubious. Some times it >>> >> may mean 'non-existent', some times it may mean light goes through it=20 >> but modified. >> >>> >> >>> If one wants to continue using it, then one should better qualify it >> with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket=20 >> Interface'. >> >>> >> >>> Because a Mobile Router doing mobility management in a transparent >>> >> manner on the Mobile Router for the LFN has nothing to do with=20 >> applications, neither with upper layers. >> >>> >> >>> Also, a Mobile Router doing NAT and Mobile IP at the same time is >> 50%-transparent. >> >>> >> >>>> >> >>>> Original wording: >> >>>> >> >>>> REQ2: Transparency to Upper Layers when needed >> >>>> >> >>>> DMM solutions MUST provide transparent mobility support above the=20 >>>> IP >> >>>> layer when needed. Such transparency is needed, for example, when, >> >>> ^on a Mobile Host. >> >>>> upon change of point of attachment to the network, an application >> >>>> flow cannot cope with a change in the IP address. >> >>> >> >>> (it's not the application flow, it is a socket which some times may >> >>> break [paste here the error from the screen]; the term 'application >> >>> flow' in this context has little meaning) >> >>> >> >>> (an 'application flow' has no understandable meaning in practice). >> >>> >> >>>> However, it is not always necessary to maintain a stable home >>>> IP >> >>>> address or prefix for every application or at all times for a >>>> mobile >> >>>> node. >> >>> ^a Mobile Host. >> >>> >> >>> I agree. >> >>> >> >>>> I now tend to think the first sentence in this original >>>> wording may >> >>>> steer the emphasis on providing transparent support, which is >>>> not >> >>>> what the motivation and the problems are talking about. >> >>> >> >>> I agree. >> >>> >> >>>> The motivation and the problems are talking about when they >>>> are not >> >>>> needed. The emphasis of this requirement therefore is on the >> >>>> capability to turn OFF unnecessary mobility support. >> >>> >> >>> In a sense I agree with the meaning. >> >>> >> >>> But when trying to turn off or on mobility support the things >>> are not >> like if there were a knob on/off, not even like starting/stopping >> some daemon. It is a matter of always having the Mobile IP >> support on, and tweak the routing table with some particular >> entries, and the firewalling rules to NAT some addresses or not. >> >>> >> >>>> How about the following >> >>>> >> >>>> REQ2: Network-layer mobility support ONLY when needed >> >>> >> >>> If we understood better when it was needed... >> >>> >> >>>> DMM solutions MUST NOT provide network-layer mobility support >>>> when >> >>>> NOT needed. >> >>> >> >>> I would say that Mobile IP MUST always be turned on on a Mobile >>> Host. >> >>> >> >>>> (or if you don't like double negatives: (DMM solutions MUST >>>> provide >> >>>> network-layer mobility support ONLY when needed) >> >>> >> >>> No, I would say to have it always on. If some applications >>> don't >> want it then dont use it; realize that by inserting routing table >> entries. >> >>> >> >>> One may wonder when some applications dont want it. One answer >>> is >>> >> when some applications prefer to not go through the HA in order to >> take advantage of the 4G pure speed. When? For example if the HA >> link is too slow compared to 4G. (remark this is not the same as >> saying that the triangular route is longer than straight, because >> that is always true). >> >>> >> >>> This is not a request for Route Optimization. It is an >>> invitation to >> analyze in deeper detail the application needs. >> >>> >> >>> One may have an application start via the HA (offer reachability) >>> and >> continue straight, w/o HA. It's the same application. >> >>> >> >>> Consider a video-call like appli: you want to be reachable always >>> at >> the same IP address (through HA) but once the session is ongoing >> you may not want to use it through HA if no handover in sight. >> >>> >> >>> Something like that. >> >>> >> >>> These things could be further refined if we really went into >>> detail >>> >> and understood what are the needs of applications, the distinctions >> MH-MR, etc. >> >>> >> >>>> Such transparent mobility support above the IP layer is needed, >>>> for >> >>>> example, when, upon change of point of attachment to the >>>> network, an >> >>>> application flow cannot cope with a change in the IP address. >> >>>> However, it is not always necessary to maintain a stable home >>>> IP >> >>>> address or prefix for every application or at all times for a >>>> mobile >> >>>> node. >> >>> >> >>> A Mobile Host never maintains a stable prefix, only a stable >>> address. >> >>> >> >>> A Mobile Router may maintain a stable address (its HoA) and may >> maintain a stable prefix (its MNP). It could also just maintain >> stable just its MNP, but not its HoA; and vice-versa. Is that >> mobility? >> >>> >> >>> For each of these there is an application :-) >> >>> >> >>> Alex >> >>> >> >>>> >> >>>> Any comments/changes/corrections? >> >>>> >> >>>> H Anthony Chan >> >>>> >> >>>> -----Original Message----- From: dmm >>>> [mailto:dmm-bounces@ietf.org] On >> >>>> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 >>>> 8:43 AM >> >>>> To: dmm@ietf.org Subject: Re: [DMM] AD >>>> Evaluation: >> >>>> draft-ietf-dmm-requirements >> >>>> >> >>>> Le 28/01/2014 02:45, h chan a =E9crit : >> >>>>> I will drop "related" >> >>>>> >> >>>>> Regarding the following >> >>>>> >> >>>>> 5. Section 5: - I am a little confused by REQ2. It says >>>>> that a DMM >> >>>>> solution should be transparent to the applications. >> >>>> >> >>>> This remark is typically true when we talk Mobile IP on a >>>> Mobile Host >> >>>> and an application like firefox runs above a BSD Socket >>>> interface. >> >>>> >> >>>> >> >>>>> However, the motivation talks about identifying applications >>>>> that do >> >>>>> (or do not) need mobility support from the network layer. >>>>> That >> >>>>> doesn't sound transparent to me. Am I reading this >>>>> incorrectly? >> >>>>> >> >>>>> It appears that unless the network can find out whether the >> >>>>> application has need of such support, the application indeed >>>>> may >> >>>>> need to invoke mobility support or has to convey its need to >>>>> the >> network. >> >>>>> >> >>>>> The emphasis of requirement is on "when needed." So, I think >>>>> it is >> >>>>> better to drop the word "transparent" as follows: >> >>>>> >> >>>>> REQ2: Mobility support when needed >> >>>>> >> >>>>> DMM solutions MUST provide mobility support to above the IP >>>>> layer >> >>>>> when needed. Such support is needed, for example, when, upon >>>>> change >> >>>>> of point of attachment to the network, an application flow >>>>> cannot >> >>>>> cope with a change in the IP address. However, it is not >>>>> always >> >>>>> necessary to maintain a stable home IP address or prefix for >>>>> every >> >>>>> application or at all times for a mobile node. >> >>>>> >> >>>>> Motivation: The motivation of this requirement is to enable >>>>> more >> >>>>> efficient routing and more efficient use of network resources >>>>> by >> >>>>> selecting an IP address or prefix according to whether >>>>> mobility >> >>>>> support is needed and by not maintaining context at the >>>>> mobility >> >>>>> anchor when there is no such need. >> >>>> >> >>>> Whenever we discuss this 'transparency' paragraph I have again >>>> the >> >>>> same comments. >> >>>> >> >>>> First, I am not sure DMM is only about Mobile Hosts, or about >>>> Mobile >> >>>> Routers as well. >> >>>> >> >>>> Because, if we talk Mobile Routers, then rarely an application >>>> runs >> >>>> directly on it. Most applications would run on LFN. >> >>>> >> >>>> Transparency? >> >>>> >> >>>> If the applications run on the LFN, the change of the >>>> attachment of >> >>>> the MR is 'transparent' to them, regardless whether or not MR >>>> does >> >>>> something to maintain stability of that address (Mobile IP, >>>> other). >> >>>> >> >>>> Second, this transparency may depend on the direction, or more >> >>>> complex 'shape' of the application flows. Some IP flows of >>>> some >> >>>> applications have very complex 'shapes', with various sets of >>>> IP src >> >>>> and dst, and triangular or HA-less shapes. >> >>>> >> >>>> Take for example a video-call. The session establishment >>>> through an >> >>>> intermediary and behind NAT is followed by the ongoing 4 flows >>>> (2 >> >>>> audio 2 video)... they all take different paths... each may >>>> need or >> >>>> not need to go through the HA, and each has distinct behaviours >>>> when >> >>>> the IP address changes, hence each would have a distinct >> >>>> 'transparency' requirement. Is this _one_ application? >> >>>> >> >>>> Alex >> >>>> >> >>>>> >> >>>>> H Anthony Chan >> >>>>> >> >>>>> -----Original Message----- From: dmm >>>>> [mailto:dmm-bounces@ietf.org] >> >>>>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 >>>>> 7:20 AM >> >>>>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org >> ; >> >>>>> dmm@ietf.org ; Peter McCann Subject: Re: >>>>> [DMM] >> AD Evaluation: >> >>>>> draft-ietf-dmm-requirements >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 1/24/14 7:38 PM, h chan wrote: >> >>>>>> 4. Section 4: - I am not sure that it benefits the document >>>>>> to >> >>>>>> label >> >>>>>> PS6 and PS7 as related. Those issues are problematic on >>>>>> their own. >> >>>>>> If you remove the "(related problem)" label from them, make >>>>>> sure >> >>>>>> that REQ2 is updated to remove mention of "related >>>>>> problem". >> >>>>>> >> >>>>>> The intention of the name "related problems" was not to >>>>>> suggest >> >>>>>> they are less problematic, but rather to distinguish them >>>>>> from the >> >>>>>> other problems directly on mobility management. Although >>>>>> these >> >>>>>> problems are not directly on mobility management, the DMM >>>>>> solutions >> >>>>>> can solve these additional problems. They are therefore >>>>>> included. >> >>>>>> So, as long as this section is not to be interpreted as >>>>>> limited to >> >>>>>> problems directly on mobility management, we can drop the >>>>>> word >> "related." >> >>>>>> >> >>>>> >> >>>>> I will leave it to the authors/WG, but I don't see a benefit >>>>> to the >> >>>>> "related" tag. >> >>>>> >> >>>>> 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 brian@innovationslab.net Thu Jan 30 14:47:58 2014 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 66CD61A04EE for ; Thu, 30 Jan 2014 14:47:58 -0800 (PST) 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 nr3GDTydR7wk for ; Thu, 30 Jan 2014 14:47:56 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6AD1A04DE for ; Thu, 30 Jan 2014 14:47:56 -0800 (PST) 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 741D3880A4; Thu, 30 Jan 2014 14:47:53 -0800 (PST) Received: from Littlejohn.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E75961368142; Thu, 30 Jan 2014 14:47:52 -0800 (PST) Message-ID: <52EAD697.3030006@innovationslab.net> Date: Thu, 30 Jan 2014 17:47:51 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "dmm@ietf.org" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E90F7A.3050902@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB829@szxeml557-mbx.china.huawei.com> <52EA5B42.3050002@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB9EF@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB9EF@szxeml557-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qKR3Ob1xO7adsBCTBpu3Cwjw8ItEM2Uo8" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 22:47:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qKR3Ob1xO7adsBCTBpu3Cwjw8ItEM2Uo8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony, That's fine. Regards, Brian On 1/30/14 1:46 PM, h chan wrote: > The reason for this requirement is that in some existing mobility > management deployment, in order to support those applications that > does need network-layer mobility support, the mobile host uses HoA so > that all the applications must use the HoA. Then it does not make it > possible for an application to not use HoA. >=20 > So the bottom line in this revision is that the DMM solution only > allows the possibility of not using the network-layer mobility > support. >=20 > How to make use of this possibility is now not a part of this > requirement. Therefore the requirement should avoid implication of > such mechanisms. >=20 > When we called "when needed", there may be implication of a mechanism > to determine/convey the need. >=20 > When we call it "invoke", there may be implication of a mechanism to > invoke. >=20 > Let me try the following: >=20 > REQ2: Bypassable Network-layer mobility support >=20 > DMM solutions MUST enable network-layer mobility but it MUST be > possible to bypass it. >=20 > (plus other sentences on the need and the no need to serve as > explanations only to justify the above) >=20 > H Anthony Chan >=20 >=20 > -----Original Message----- From: Brian Haberman > [mailto:brian@innovationslab.net] Sent: Thursday, January 30, 2014 > 8:02 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD Evaluation: > draft-ietf-dmm-requirements >=20 > Hi Anthony, >=20 > On 1/29/14 1:51 PM, h chan wrote: >> Brian, >>=20 >> The requirement is intended to include a capability of not using=20 >> network-layer mobility management, as opposed to using it by >> default. >>=20 >>=20 >> I think it is sufficient to leave to the explanation (the sentences >> after the first sentence) to say that network-layer mobility >> support is not always needed in order to justify this capability. >>=20 >> The alternative then is to say that network-layer mobility is >> provided but it is possible to not use such support. >>=20 >> REQ2: Using and not Using Network-layer mobility support >>=20 >> DMM solutions MUST enable network-layer mobility but it MUST be=20 >> possible to not invoke it. Mobility support is needed, for example, >> when an application or a host cannot cope with a change in the IP >> address when a node moves. Yet a mobile node can often be >> stationary, and mobility support can also be provided at other >> layers. It is then not always necessary to maintain a stable IP >> address or prefix. >>=20 >> Of cause "enable" does not mean it must be used. Yet explicitly say >> "it is possible to not invoke it" is to draw the contrast to using >> it by default. >=20 > My only concern is that it is unclear *who* invokes the network-layer > mobility support. Is it envisioned that the application can signal > the need for mobility support? Does the user have to configure which > applications get support? >=20 > Regards, Brian >=20 --qKR3Ob1xO7adsBCTBpu3Cwjw8ItEM2Uo8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS6taYAAoJEBOZRqCi7goq78AH/jZbZESQm12a9jfhVjVvoSzF 6L2qGDqZnwz/Eh/F4dL6xXv3UfflESaGyx+g8z0hoHq0UeDB3L2Z67irNbOJ3C1S P3LNjXENjbPYUeKj922M44t61s/XTLFkbWvoPn0ADh49tUyPVSzJK+gNkIMSPp5o n1Whs9EVU/34LNJeBn3QJKCZUbj3qmNxRMDN3xXFELFMhmFIN+kfunJzcplk53gl kuFZWQGzK9gE2ip/LZMfXtlnyEhfg1bQJSRnJdyyyRsxnqAAYVTVXAyMoT9tZZyg IL2JrAFSx6alITNP+0Kfoaes1KVDI4WY+QoVAGR08kq26LN0RtiJ/2w5LrAwg3o= =ckr0 -----END PGP SIGNATURE----- --qKR3Ob1xO7adsBCTBpu3Cwjw8ItEM2Uo8-- From jouni.nospam@gmail.com Thu Jan 30 15:18:30 2014 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 0C2BF1A04DD for ; Thu, 30 Jan 2014 15:18:30 -0800 (PST) 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 QR0AfZcYpW0M for ; Thu, 30 Jan 2014 15:18:28 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CEC7A1A04DB for ; Thu, 30 Jan 2014 15:18:28 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so3583092pde.6 for ; Thu, 30 Jan 2014 15:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rLd4zeWAH+qsh3aVVwnWPhU76DacmLyH2sYrwRCYerw=; b=D0QJo+NDwYAat3c/hqfd1yG7TrgPpJm7jGpdJL9osymm21qdtIfXrNcMupiwxU4CCc bnt+xDBK4si0RO9vAa7/X86L6Wij3+KJN4qE7vH9mgpRa3dQgs8BXPg391qgA1toUhuv JoXyQVpuyzRFj7zaxWJAJPGeuc97TnaiWVI3mA+g9ezuqzgzP6w6Idl+96cAi4y1dBm+ 4pl3xlvjEiB2XYM8FI7DVg04c/G2QfeIPRSXRuyCMVstHsr0A/fb77+V7AYif5SscvHX PqP0xGnEHv0NT70IUJXezOlTJe9K+nrIUmsR3ov4uwlNTerHJzG1+DIhxYh+uNha9Ri0 GEZQ== X-Received: by 10.68.237.133 with SMTP id vc5mr17311339pbc.92.1391123905511; Thu, 30 Jan 2014 15:18:25 -0800 (PST) Received: from [10.16.10.116] ([216.31.219.19]) by mx.google.com with ESMTPSA id xs1sm52004369pac.7.2014.01.30.15.18.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jan 2014 15:18:24 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <52E90898.6050604@innovationslab.net> Date: Thu, 30 Jan 2014 15:18:19 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB62E@szxeml557-mbx.china.huawei.com> <52E90898.6050604@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1510) Cc: Peter McCann , "dmm@ietf.org" , "draft-ietf-dmm-requirements@tools.ietf.org" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 30 Jan 2014 23:18:30 -0000 On Jan 29, 2014, at 5:56 AM, Brian Haberman wrote: [snip] > > The above seems a little clunky. Does this work for everyone? > > > A DMM solution MUST NOT introduce new security risks, or amplify > existing security risks, that cannot be mitigated by existing security > mechanisms or protocols. Would work for me. - Jouni > > > Regards, > Brian > From jouni.nospam@gmail.com Thu Jan 30 16:40:27 2014 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 14C0B1A04F1 for ; Thu, 30 Jan 2014 16:40:27 -0800 (PST) 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 Eu3FtK1Xuo8G for ; Thu, 30 Jan 2014 16:40:25 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 20F231A04EE for ; Thu, 30 Jan 2014 16:40:25 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so3811199pad.13 for ; Thu, 30 Jan 2014 16:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r6pE9rIqLsMzzagE78iLwnLRoUVkrLGDhi0FqtqG1uI=; b=w+HpxEN82fSAxm+zk/Sr2eIqRzghS8IJZu1Cl4zG3oFXa8ZWU0HzqTNaxKh7tt20bx e5IpGklBdv/z8zKc91Ae8pm80kJ0ZVjO6jUgRfc0Vo+ULL4izBPTpVvrG5LJgGgqaAE8 WdM1uEeg3ZDM7fffIOTSDxvmy+Ibrtg/Jfw23J47YDMNcsMHVf0Eu6bYKUjcsBpKj3db Q/HOlWIMPIbgNefvlOCha708KgJOFKyh2RQYqa5lT1Gan/Y0dMTIGlXWdK7y3vKYTJLl zre0IR6KF78YerRQvbZt3kPdVZXQUCy4CIZgrFyojLAaKUqZObWtqOmxv8Tow8ShUPxC SGjg== X-Received: by 10.66.164.70 with SMTP id yo6mr17757470pab.85.1391128821786; Thu, 30 Jan 2014 16:40:21 -0800 (PST) Received: from [10.16.10.116] ([216.31.219.19]) by mx.google.com with ESMTPSA id om6sm21561296pbc.43.2014.01.30.16.40.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jan 2014 16:40:20 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <52E909A6.80008@innovationslab.net> Date: Thu, 30 Jan 2014 16:40:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6FBDFC0E-2C85-46E3-99C9-8B468E7CA44B@gmail.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB641@szxeml557-mbx.china.huawei.com> <52E909A6.80008@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1510) Cc: Peter McCann , "dmm@ietf.org" , "draft-ietf-dmm-requirements@tools.ietf.org" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 31 Jan 2014 00:40:27 -0000 On Jan 29, 2014, at 6:01 AM, Brian Haberman = wrote: [snip] >> We can change to: >>=20 >> REQ5: Co-existence with deployed networks and hosts >>=20 >>=20 >>=20 >> The DMM solution MUST be able to co-exist with existing >> network deployments and end hosts without breaking them. = For example, depending on >> the environment in which DMM is deployed, DMM solutions may >> need to be compatible with other deployed mobility = protocols >> or may need to co-exist with a network or mobile = hosts/routers >> that do not support DMM protocols. The mobile node may = also >> move between different access networks, where some of them = may >> support neither DMM nor another mobility protocol. >> Furthermore, a DMM solution SHOULD work across different >> networks, possibly operated as separate administrative >> domains, when allowed by the trust relationship between = them. >=20 > The "without breaking" is fine. However, the "need to be compatible > with" phrasing is still problematic. Is that inferring that in some > situations that a DMM solution would need to interact with, for = example, > PMIP? Your observation is correct. Maybe slightly better wording would work: REQ5: Co-existence with deployed networks and hosts The DMM solution may require loose, tight or no integration = into existing mobility protocols and host IP stack. Independent of = the integration level, the DMM solution MUST be able to co-exist = with existing network deployments, end hosts and routers that may or may not implement existing mobility protocols. Furthermore, a = DMM solution SHOULD work across different networks, possibly = operated as separate administrative domains, when allowed by the trust relationship between them. - Jouni >=20 > Regards, > Brian >=20 >=20 From alexandru.petrescu@gmail.com Fri Jan 31 03:43:25 2014 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 01E351A059D for ; Fri, 31 Jan 2014 03:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 tPvDyOhl2LJW for ; Fri, 31 Jan 2014 03:43:19 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD21A0597 for ; Fri, 31 Jan 2014 03:43:18 -0800 (PST) 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 s0VBhAPV019873; Fri, 31 Jan 2014 12:43:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 91F582018CB; Fri, 31 Jan 2014 12:43:22 +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 84AFD200F6B; Fri, 31 Jan 2014 12:43:22 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0VBh6UH021745; Fri, 31 Jan 2014 12:43:09 +0100 Message-ID: <52EB8C4A.5060402@gmail.com> Date: Fri, 31 Jan 2014 12:43:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: h chan , "dmm@ietf.org" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E948AC.6030904@gmail.com> <6E31144C030982429702B11D6746B98C370EB866@szxeml557-mbx.china.huawei.com> <52EA09A0.70109@gmail.com> <6E31144C030982429702B11D6746B98C370EB9B3@szxeml557-mbx.china.huawei.com> <52EA8E42.5000000@gmail.com> <6E31144C030982429702B11D6746B98C370EB9FD@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370EB9FD@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 31 Jan 2014 11:43:25 -0000 Le 30/01/2014 20:53, h chan a écrit : > Alex, > > I think the applications which work without MIP are the applications > that can cope with the change of IP address of the MR. Is that > correct? Yes, that is correct for MH. For the MR cases, any application running on the Host can cope with that change (==TCP retransmits). > Then mobility support is needed only for those applications that > cannot cope with the change of IP address of the MR. No, that is wrong. IT depends what one means by 'mobility support' - on the MR or in the network? MR-based mobility support is needed on the MR for some kinds of applications on Host to continue working. Infrastructure-based mobility support is alternatively needed on the MR for some kinds of applications on Host to continue working. A mix of infrastructure-based mobility support and MR-based mobility support is needed for some kinds of applications on Host to continue working. The 3 statements are valid simultaneously. We can't just say that _only_ MR-based mobility support is needed. > So, in the two separate sentences: > >> Mobility Support on a Mobile Host is needed, for example, when a >> Mobile Host moves and an arbitrary application in the Mobile Host >> cannot cope with a change in the IP address of that Mobile Host >> [paste socket error message here]. > > Is this MN sentence the same as: Mobility support is needed, for > example, when a mobile host moves and an application cannot cope > with a change in the IP address of the mobile host. Right, same. >> Mobility Support on a Mobile Router is needed, for example, when a >> Mobile Router moves together with a set of Hosts and Routers, and >> arbitrary applications in the Hosts and Routers need to maintain >> their IP address fixed regardless of the change of the IP address >> of the Mobile Router, and the Access Router performs ingress >> filtering, and reachability of these Hosts and Routers at a fixed >> IP address is necessary. > > When the MR carries a network of hosts and routers, doesn't these > routers in turn carry network so that at the final level of hosts, > the applications are running there. If so, is it sufficient to state > the applications in the hosts? (which includes hosts in the network > of routers which are in turn in the network of the mobile router) YEs, it is sufficient. > So a host in the network of a router, which in turn is in the network > of another router, which .... in the network of the mobile router can > be called a host that moves with the mobile router. YEs. > Then is the MR sentence the above the same as > > Mobility support is also needed, for example, when a mobile router > moves together and an application in a host that moves with the ^ together with the Host > mobile router cannot cope with a change of IP address of the mobile > router. YEs. At this point we should say that [infrastructure-based, or MR-based, or a mix of the two] mobility support is needed, for example, when a Mobile Router moves together with the Host and an application on the latter is interrupted by the change of the IP address of the former. (because we don't want that Host to cope with it; if we say 'can not cope' it's like if we wanted it to). Alex > REQ2: Bypassable Network-layer mobility support > > DMM solutions MUST enable network-layer mobility but it MUST be > possible to not use it. > > Mobility support is needed, for example, when a mobile host moves > and an application cannot cope with a change in the IP address. > > Mobility support is also needed, for example, when a mobile router > moves together and an application in a host which moves with the > mobile router cannot cope with a change of IP address of the mobile > router. > > However mobility support at the network-layer is not always needed; > a mobile node can often be stationary, and mobility support can also > be provided at other layers. It is then not always necessary to > maintain a stable IP address or prefix. > > One more alternative is to mention the "no need" case only without > explaining the "needed" case as in the following. Yet if it is > possible to state the "needed" case more concisely, it will be more > clear to spell that out as in above. > > REQ2: Bypassable Network-layer mobility support > > DMM solutions MUST enable network-layer mobility but it MUST be > possible to not use it. Mobility support at the network-layer is not > always needed; a mobile node can often be stationary, and mobility > support can also be provided at other layers. It is then not always > necessary to maintain a stable IP address or prefix. > > H Anthony Chan > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, January 30, > 2014 11:39 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD > Evaluation: draft-ietf-dmm-requirements > > Le 30/01/2014 18:08, h chan a écrit : >> Alex, >> >> Is the following correct? >> >> Mobility support is needed, for example, when a mobile host or a >> mobile router moves and an application in the mobile host or in a >> host that moves with the router cannot cope with a change in the >> IP address of the mobile node. > > Makes better sense, thanks. > > But still uses that word 'Mobile Node' which is confusing. How > about this: > >> Mobility support is needed, for example, when a Mobile Host or a >> Mobile Router moves and an application in the Mobile Host or in a >> host or router that moves with that Mobile Router cannot cope with >> a change in the IP address of the mobile host or of that Mobile >> Router. > > It would be more precise. > > But even then, it does not hold, because a Host that moves with the > Mobile Router is not that much influenced by the change of IP > address of that MR. When the MR changes its IP address, the Host > feels it just like some other interruption in the path to another CN. > These kinds of interruptions (link up/down) happen often in the > fixed networks and yet Hosts continue to work. > > It is possible, for example, to have a Mobile Router move, have NAT > (not mobility management), change IP address, and the Hosts and > Routers in that moving network will continue working ok. > > It is also possible for MR to not have NAT, and forward packets with > an address which is not topological correct in that network. These > packets will reach their destinations (provided there's no ingress > filtering), and the replies will not arrive. Some applications do > not need packets to return. One can very well have a vehicle which > streams the video of its front camera to some particular server in > the Internet, and change its IP address at each access. This does > not require Mobile IP nor NAT. > > I think it is impossible to stay meaningful in one phrase talking > both Mobile Host and Mobile Router at the same time. I think we > need maybe two phrases. > >> Mobility Support on a Mobile Host is needed, for example, when a >> Mobile Host moves and an arbitrary application in the Mobile Host >> cannot cope with a change in the IP address of that Mobile Host >> [paste socket error message here]. >> >> Mobility Support on a Mobile Router is needed, for example, when a >> Mobile Router moves together with a set of Hosts and Routers, and >> arbitrary applications in the Hosts and Routers need to maintain >> their IP address fixed regardless of the change of the IP address >> of the Mobile Router, and the Access Router performs ingress >> filtering, and reachability of these Hosts and Routers at a fixed >> IP address is necessary. > > Alex > >> >> H Anthony Chan >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, January 30, >> 2014 2:13 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD >> Evaluation: draft-ietf-dmm-requirements >> >> Le 29/01/2014 20:45, h chan a écrit : >>> Alex >>> >>> How about the following: >>> >>> REQ2: Using and not Using Network-layer mobility support >>> >>> DMM solutions MUST enable network-layer mobility >>> >>> but it MUST be possible to not invoke it. >>> >>> Mobility support is needed, for example, >>> >>> when an application (of a MN or a host in a mobile network of a >>> MR) >> ^a LFN (because just 'host' may be confused with Mobile Host; and >> also because within the moving network there is also one or >> several Routers - not hosts.) >> >>> cannot cope with a change in the >>> >>> IP address of the mobile node when the node moves. >> ^Mobile Host or of the Mobile Router moves (because when the 'node' >> moves it may mean that the 'host' in the moving network moves, and >> that doesn't change its IP address). >> >>> Yet a mobile node can often be stationary, >>> >>> and mobility support can also be provided at other layers. >>> >>> It is then not always necessary to maintain a >>> >>> stable IP address or prefix. >>> >>> Can the text in red be valid for both host or router? >> >> Yes and no. I agree with it, but I'd prefer the suggested >> modifications. >> >> Alex >> >>> >>> When the node is a router: >>> >>> an application (of a host in a mobile network) may not be able to >>> cope with a change in the IP address of the MR when the MR >>> moves. >>> >>> When the node is a host >>> >>> an application (of a MN) may not be able to cope with a change >>> in the IP address of the MN when the MN moves. >>> >>> H Anthony Chan >>> >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January >>> 29, 2014 12:30 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD >>> Evaluation: draft-ietf-dmm-requirements >>> >>> Le 28/01/2014 23:33, h chan a écrit : >>> >>>> Let us try to include MR. >>> >>>> >>> >>>> How about the following >>> >>>> >>> >>>> REQ2: Network-layer mobility support when needed >>> >>>> >>> >>>> DMM solutions MUST enable network-layer >>> >>>> mobility when needed. >>> >>>> Such mobility support is needed, for >>> >>>> example, when an application or a host cannot cope with a >>> change in the >>> >>>> IP address when a node moves. However, it is not always >>> necessary to maintain a >>> >>>> stable IP address or prefix. >>> >>>> >>> >>>> Here, the node can be a mobile host or a mobile router. >>> >>> I am not sure the term 'node' is agreed to cover both an MH and >>> an MR. >>> >>> I think in all descriptions it would be clearer if we just said >>> MH when we meant Mobile Host and MR when we meant Mobile Router. >>> >>> Le me paraphrase this text in RFC6275: >>> >>>> This document specifies a protocol that allows nodes to remain >>> >>>> reachable while moving around in the IPv6 Internet. Without >>>> specific >>> >>>> support for mobility in IPv6 [6], packets destined to a mobile >>>> node >>> >>>> would not be able to reach it while the mobile node is away >>>> from its >>> >>>> home link. >>> >>> There is a clear ambiguity in the 'mobile node' used above. >>> Because if we talk moving networks then often the packets are >>> destined (the contents of the destination address) to a LFN, not >>> to the MR. >>> >>> If that 'node' were a Mobile Router (not a Mobile Host) it >>> completely misses the case when packets are destined to the LFN, >>> which is not an MH nor an MR. >>> >>> The phrase should rather say: >>> >>> 'packets destined to a MH (or to a LFN behind a MR) would not be >>> able >>> >>> to reach it while that MH (or the MR and LFN) is away from its >>> home >>> >>> link.' >>> >>> This kind if expression would be clearer. >>> >>> Alex >>> >>> 'packets destined to a [LFN] or to the Mobile Host, or to the >>> Mobile Router, would not be able to reach it while the Mobile >>> Router is away from its home link'. >>> >>>> A host can be a mobile host or a host in a LFN. >>> >>>> An application can be running on a mobile host or a on a host >>>> in a LFN. >>> >>>> A MR also does not need to maintain stable IP address or >>>> prefix when >>> there are no hosts attached to it or when there are no active >>> applications running in the hosts of its network. >>> >>>> >>> >>>> Any comments/changes/corrections? >>> >>>> >>> >>>> H Anthony Chan >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>> >>>> Sent: Tuesday, January 28, 2014 1:27 PM >>> >>>> To: h chan; dmm@ietf.org >>> >>>> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements >>> >>>> >>> >>>> Le 28/01/2014 19:58, h chan a écrit : >>> >>>>> Let me try to understand the concern here. >>> >>>>> >>> >>>>> What is new in this requirement is "when needed" in contrast >>>>> to >>> >>>>> providing IP mobility by default. >>> >>>> >>> >>>> First, providing mobility by default is not a black/white >>>> alternative >>> to not providing mobility. >>> >>>> >>> >>>> It is very possible on the same machine to have Mobile IP >>>> enabled for >>> some flows and disabled for others (depending what we call a >>> 'flow'). >>> >>>> It is also possible to have Mobile IP and NAT at the same time >>>> on the >>> same Mobile Router. >>> >>>> >>> >>>>> Without this requirement, mobility support may be provided >>>>> by >>> >>>>> default, which is transparent to higher layers. >>> >>>> >>> >>>> Again, transparency to higher layers means we talk mobility >>> management on a Mobile Host. >>> >>>> >>> >>>> Transparency to higher layers has little meaning if we talk >>>> mobility >>> management provided on a Mobile Router (which is not a Mobile >>> Host). >>> >>>> >>> >>>>> With this requirement, assume there are separate steps in >>>>> the DMM >>> >>>>> solution. 1. A decision is made whether network-layer >>>>> mobility >>> >>>>> support is needed. 2. When the need is established, >>>>> network-layer >>> >>>>> mobility support is invoked. 3. Then transparent support is >>>>> provided >>> >>>>> and is transparent to layers above IP. >>> >>>>> >>> >>>>> Transparency is clear in step 3 above. >>> >>>> >>> >>>> This looks like a trigger which enables mobility, or other >>>> times >>> disables it. >>> >>>> >>> >>>> But one can have a Mobile IP daemon and a NAT run at the same >>>> time on >>> the same machine. There is no decision in time. >>> >>>> >>> >>>> Some decision happens at packet based on IP destination >>>> address. >>> >>>> >>> >>>>> The question however is whether the preceding steps involve >>>>> the >>> >>>>> application, so that one may question whether the entire DMM >>>>> solution >>> >>>>> (with all the steps) as a whole is transparent. >>> >>>> >>> >>>> I agree. I am not aware of any application which talks to >>>> Mobile IP. >>> >>>> Whenever it is there it is 'transparent'. >>> >>>> >>> >>>>> So the intention of the requirement is that WHEN/AFTER the >>>>> decision >>> >>>>> is made to invoke mobility support, then the mobility >>>>> support is >>> >>>>> transparent to the application. Then we may want to check >>>>> and make >>> >>>>> sure the emphasis of this requirement does mean transparency >>>>> in this >>> >>>>> respect only. >>> >>>> >>> >>>> I disagree. >>> >>>> >>> >>>> As I said above, the word 'transparency' is dubious. Some >>>> times it >>>> >>> may mean 'non-existent', some times it may mean light goes >>> through it but modified. >>> >>>> >>> >>>> If one wants to continue using it, then one should better >>>> qualify it >>> with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket >>> Interface'. >>> >>>> >>> >>>> Because a Mobile Router doing mobility management in a >>>> transparent >>>> >>> manner on the Mobile Router for the LFN has nothing to do with >>> applications, neither with upper layers. >>> >>>> >>> >>>> Also, a Mobile Router doing NAT and Mobile IP at the same time >>>> is >>> 50%-transparent. >>> >>>> >>> >>>>> >>> >>>>> Original wording: >>> >>>>> >>> >>>>> REQ2: Transparency to Upper Layers when needed >>> >>>>> >>> >>>>> DMM solutions MUST provide transparent mobility support >>>>> above the IP >>> >>>>> layer when needed. Such transparency is needed, for >>>>> example, when, >>> >>>> ^on a Mobile Host. >>> >>>>> upon change of point of attachment to the network, an >>>>> application >>> >>>>> flow cannot cope with a change in the IP address. >>> >>>> >>> >>>> (it's not the application flow, it is a socket which some >>>> times may >>> >>>> break [paste here the error from the screen]; the term >>>> 'application >>> >>>> flow' in this context has little meaning) >>> >>>> >>> >>>> (an 'application flow' has no understandable meaning in >>>> practice). >>> >>>> >>> >>>>> However, it is not always necessary to maintain a stable home >>>>> IP >>> >>>>> address or prefix for every application or at all times for a >>>>> mobile >>> >>>>> node. >>> >>>> ^a Mobile Host. >>> >>>> >>> >>>> I agree. >>> >>>> >>> >>>>> I now tend to think the first sentence in this original >>>>> wording may >>> >>>>> steer the emphasis on providing transparent support, which is >>>>> not >>> >>>>> what the motivation and the problems are talking about. >>> >>>> >>> >>>> I agree. >>> >>>> >>> >>>>> The motivation and the problems are talking about when they >>>>> are not >>> >>>>> needed. The emphasis of this requirement therefore is on the >>> >>>>> capability to turn OFF unnecessary mobility support. >>> >>>> >>> >>>> In a sense I agree with the meaning. >>> >>>> >>> >>>> But when trying to turn off or on mobility support the things >>>> are not >>> like if there were a knob on/off, not even like starting/stopping >>> some daemon. It is a matter of always having the Mobile IP >>> support on, and tweak the routing table with some particular >>> entries, and the firewalling rules to NAT some addresses or not. >>> >>>> >>> >>>>> How about the following >>> >>>>> >>> >>>>> REQ2: Network-layer mobility support ONLY when needed >>> >>>> >>> >>>> If we understood better when it was needed... >>> >>>> >>> >>>>> DMM solutions MUST NOT provide network-layer mobility support >>>>> when >>> >>>>> NOT needed. >>> >>>> >>> >>>> I would say that Mobile IP MUST always be turned on on a Mobile >>>> Host. >>> >>>> >>> >>>>> (or if you don't like double negatives: (DMM solutions MUST >>>>> provide >>> >>>>> network-layer mobility support ONLY when needed) >>> >>>> >>> >>>> No, I would say to have it always on. If some applications >>>> don't >>> want it then dont use it; realize that by inserting routing table >>> entries. >>> >>>> >>> >>>> One may wonder when some applications dont want it. One answer >>>> is >>>> >>> when some applications prefer to not go through the HA in order >>> to take advantage of the 4G pure speed. When? For example if >>> the HA link is too slow compared to 4G. (remark this is not the >>> same as saying that the triangular route is longer than >>> straight, because that is always true). >>> >>>> >>> >>>> This is not a request for Route Optimization. It is an >>>> invitation to >>> analyze in deeper detail the application needs. >>> >>>> >>> >>>> One may have an application start via the HA (offer >>>> reachability) and >>> continue straight, w/o HA. It's the same application. >>> >>>> >>> >>>> Consider a video-call like appli: you want to be reachable >>>> always at >>> the same IP address (through HA) but once the session is ongoing >>> you may not want to use it through HA if no handover in sight. >>> >>>> >>> >>>> Something like that. >>> >>>> >>> >>>> These things could be further refined if we really went into >>>> detail >>>> >>> and understood what are the needs of applications, the >>> distinctions MH-MR, etc. >>> >>>> >>> >>>>> Such transparent mobility support above the IP layer is >>>>> needed, for >>> >>>>> example, when, upon change of point of attachment to the >>>>> network, an >>> >>>>> application flow cannot cope with a change in the IP >>>>> address. >>> >>>>> However, it is not always necessary to maintain a stable home >>>>> IP >>> >>>>> address or prefix for every application or at all times for a >>>>> mobile >>> >>>>> node. >>> >>>> >>> >>>> A Mobile Host never maintains a stable prefix, only a stable >>>> address. >>> >>>> >>> >>>> A Mobile Router may maintain a stable address (its HoA) and >>>> may >>> maintain a stable prefix (its MNP). It could also just maintain >>> stable just its MNP, but not its HoA; and vice-versa. Is that >>> mobility? >>> >>>> >>> >>>> For each of these there is an application :-) >>> >>>> >>> >>>> Alex >>> >>>> >>> >>>>> >>> >>>>> Any comments/changes/corrections? >>> >>>>> >>> >>>>> H Anthony Chan >>> >>>>> >>> >>>>> -----Original Message----- From: dmm >>>>> [mailto:dmm-bounces@ietf.org] On >>> >>>>> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 >>>>> 8:43 AM >>> >>>>> To: dmm@ietf.org Subject: Re: [DMM] AD >>>>> Evaluation: >>> >>>>> draft-ietf-dmm-requirements >>> >>>>> >>> >>>>> Le 28/01/2014 02:45, h chan a écrit : >>> >>>>>> I will drop "related" >>> >>>>>> >>> >>>>>> Regarding the following >>> >>>>>> >>> >>>>>> 5. Section 5: - I am a little confused by REQ2. It says >>>>>> that a DMM >>> >>>>>> solution should be transparent to the applications. >>> >>>>> >>> >>>>> This remark is typically true when we talk Mobile IP on a >>>>> Mobile Host >>> >>>>> and an application like firefox runs above a BSD Socket >>>>> interface. >>> >>>>> >>> >>>>> >>> >>>>>> However, the motivation talks about identifying >>>>>> applications that do >>> >>>>>> (or do not) need mobility support from the network layer. >>>>>> That >>> >>>>>> doesn't sound transparent to me. Am I reading this >>>>>> incorrectly? >>> >>>>>> >>> >>>>>> It appears that unless the network can find out whether >>>>>> the >>> >>>>>> application has need of such support, the application >>>>>> indeed may >>> >>>>>> need to invoke mobility support or has to convey its need >>>>>> to the >>> network. >>> >>>>>> >>> >>>>>> The emphasis of requirement is on "when needed." So, I >>>>>> think it is >>> >>>>>> better to drop the word "transparent" as follows: >>> >>>>>> >>> >>>>>> REQ2: Mobility support when needed >>> >>>>>> >>> >>>>>> DMM solutions MUST provide mobility support to above the IP >>>>>> layer >>> >>>>>> when needed. Such support is needed, for example, when, >>>>>> upon change >>> >>>>>> of point of attachment to the network, an application flow >>>>>> cannot >>> >>>>>> cope with a change in the IP address. However, it is not >>>>>> always >>> >>>>>> necessary to maintain a stable home IP address or prefix >>>>>> for every >>> >>>>>> application or at all times for a mobile node. >>> >>>>>> >>> >>>>>> Motivation: The motivation of this requirement is to enable >>>>>> more >>> >>>>>> efficient routing and more efficient use of network >>>>>> resources by >>> >>>>>> selecting an IP address or prefix according to whether >>>>>> mobility >>> >>>>>> support is needed and by not maintaining context at the >>>>>> mobility >>> >>>>>> anchor when there is no such need. >>> >>>>> >>> >>>>> Whenever we discuss this 'transparency' paragraph I have >>>>> again the >>> >>>>> same comments. >>> >>>>> >>> >>>>> First, I am not sure DMM is only about Mobile Hosts, or about >>>>> Mobile >>> >>>>> Routers as well. >>> >>>>> >>> >>>>> Because, if we talk Mobile Routers, then rarely an >>>>> application runs >>> >>>>> directly on it. Most applications would run on LFN. >>> >>>>> >>> >>>>> Transparency? >>> >>>>> >>> >>>>> If the applications run on the LFN, the change of the >>>>> attachment of >>> >>>>> the MR is 'transparent' to them, regardless whether or not MR >>>>> does >>> >>>>> something to maintain stability of that address (Mobile IP, >>>>> other). >>> >>>>> >>> >>>>> Second, this transparency may depend on the direction, or >>>>> more >>> >>>>> complex 'shape' of the application flows. Some IP flows of >>>>> some >>> >>>>> applications have very complex 'shapes', with various sets of >>>>> IP src >>> >>>>> and dst, and triangular or HA-less shapes. >>> >>>>> >>> >>>>> Take for example a video-call. The session establishment >>>>> through an >>> >>>>> intermediary and behind NAT is followed by the ongoing 4 >>>>> flows (2 >>> >>>>> audio 2 video)... they all take different paths... each may >>>>> need or >>> >>>>> not need to go through the HA, and each has distinct >>>>> behaviours when >>> >>>>> the IP address changes, hence each would have a distinct >>> >>>>> 'transparency' requirement. Is this _one_ application? >>> >>>>> >>> >>>>> Alex >>> >>>>> >>> >>>>>> >>> >>>>>> H Anthony Chan >>> >>>>>> >>> >>>>>> -----Original Message----- From: dmm >>>>>> [mailto:dmm-bounces@ietf.org] >>> >>>>>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 >>>>>> 7:20 AM >>> >>>>>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org >>> ; >>> >>>>>> dmm@ietf.org ; Peter McCann Subject: >>>>>> Re: [DMM] >>> AD Evaluation: >>> >>>>>> draft-ietf-dmm-requirements >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> On 1/24/14 7:38 PM, h chan wrote: >>> >>>>>>> 4. Section 4: - I am not sure that it benefits the >>>>>>> document to >>> >>>>>>> label >>> >>>>>>> PS6 and PS7 as related. Those issues are problematic on >>>>>>> their own. >>> >>>>>>> If you remove the "(related problem)" label from them, >>>>>>> make sure >>> >>>>>>> that REQ2 is updated to remove mention of "related >>>>>>> problem". >>> >>>>>>> >>> >>>>>>> The intention of the name "related problems" was not to >>>>>>> suggest >>> >>>>>>> they are less problematic, but rather to distinguish them >>>>>>> from the >>> >>>>>>> other problems directly on mobility management. Although >>>>>>> these >>> >>>>>>> problems are not directly on mobility management, the DMM >>>>>>> solutions >>> >>>>>>> can solve these additional problems. They are therefore >>>>>>> included. >>> >>>>>>> So, as long as this section is not to be interpreted as >>>>>>> limited to >>> >>>>>>> problems directly on mobility management, we can drop the >>>>>>> word >>> "related." >>> >>>>>>> >>> >>>>>> >>> >>>>>> I will leave it to the authors/WG, but I don't see a >>>>>> benefit to the >>> >>>>>> "related" tag. >>> >>>>>> >>> >>>>>> 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 alexandru.petrescu@gmail.com Fri Jan 31 03:44:43 2014 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 0F5AB1A059D for ; Fri, 31 Jan 2014 03:44:43 -0800 (PST) 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 53jCgDz6eRWU for ; Fri, 31 Jan 2014 03:44:41 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 824B81A0597 for ; Fri, 31 Jan 2014 03:44:41 -0800 (PST) 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 s0VBibTn020331 for ; Fri, 31 Jan 2014 12:44:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2366F2018CB for ; Fri, 31 Jan 2014 12:44:50 +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 11F252018C7 for ; Fri, 31 Jan 2014 12:44:50 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0VBia3r022426 for ; Fri, 31 Jan 2014 12:44:37 +0100 Message-ID: <52EB8CA4.9020200@gmail.com> Date: Fri, 31 Jan 2014 12:44:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dmm@ietf.org References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB62E@szxeml557-mbx.china.huawei.com> <52E90898.6050604@innovationslab.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 31 Jan 2014 11:44:43 -0000 Le 31/01/2014 00:18, Jouni Korhonen a écrit : > > On Jan 29, 2014, at 5:56 AM, Brian Haberman wrote: > > [snip] > >> >> The above seems a little clunky. Does this work for everyone? >> >> >> A DMM solution MUST NOT introduce new security risks, or amplify >> existing security risks, that cannot be mitigated by existing security >> mechanisms or protocols. > > > Would work for me. To me this is too hig-level. IT's a good principle that we apply everywhere and it works. But I wonder there is some detail about it. Like for example: any new DMM solution involving route updates will not allow rogue routes to be inserted in the system. Alex > > - Jouni > > >> >> >> Regards, >> Brian >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > From brian@innovationslab.net Fri Jan 31 05:22:20 2014 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 10AC81A0591 for ; Fri, 31 Jan 2014 05:22:20 -0800 (PST) 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 Blk6utr3snmv for ; Fri, 31 Jan 2014 05:22:18 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 105511A0522 for ; Fri, 31 Jan 2014 05:22:18 -0800 (PST) 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 A7F12880D1; Fri, 31 Jan 2014 05:22:14 -0800 (PST) Received: from 102524131.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 05D25136810B; Fri, 31 Jan 2014 05:22:13 -0800 (PST) Message-ID: <52EBA380.50301@innovationslab.net> Date: Fri, 31 Jan 2014 08:22:08 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jouni Korhonen References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB641@szxeml557-mbx.china.huawei.com> <52E909A6.80008@innovationslab.net> <6FBDFC0E-2C85-46E3-99C9-8B468E7CA44B@gmail.com> In-Reply-To: <6FBDFC0E-2C85-46E3-99C9-8B468E7CA44B@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uQqBmEGm2siMbWFNrSANNcMr6Kuu2iNov" Cc: Peter McCann , "dmm@ietf.org" , "draft-ietf-dmm-requirements@tools.ietf.org" Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 31 Jan 2014 13:22:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uQqBmEGm2siMbWFNrSANNcMr6Kuu2iNov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jouni, On 1/30/14 7:40 PM, Jouni Korhonen wrote: >=20 > On Jan 29, 2014, at 6:01 AM, Brian Haberman = wrote: >=20 > [snip] >=20 >>> We can change to: >>> >>> REQ5: Co-existence with deployed networks and hosts >>> >>> >>> >>> The DMM solution MUST be able to co-exist with existing >>> network deployments and end hosts without breaking them. F= or example, depending on >>> the environment in which DMM is deployed, DMM solutions may= >>> need to be compatible with other deployed mobility protocol= s >>> or may need to co-exist with a network or mobile hosts/rout= ers >>> that do not support DMM protocols. The mobile node may als= o >>> move between different access networks, where some of them = may >>> support neither DMM nor another mobility protocol. >>> Furthermore, a DMM solution SHOULD work across different >>> networks, possibly operated as separate administrative >>> domains, when allowed by the trust relationship between the= m. >> >> The "without breaking" is fine. However, the "need to be compatible >> with" phrasing is still problematic. Is that inferring that in some >> situations that a DMM solution would need to interact with, for exampl= e, >> PMIP? >=20 > Your observation is correct. Maybe slightly better wording would work: >=20 > REQ5: Co-existence with deployed networks and hosts >=20 > The DMM solution may require loose, tight or no integration in= to > existing mobility protocols and host IP stack. Independent of = the > integration level, the DMM solution MUST be able to co-exist w= ith > existing network deployments, end hosts and routers that may o= r > may not implement existing mobility protocols. Furthermore, a = DMM > solution SHOULD work across different networks, possibly opera= ted > as separate administrative domains, when allowed by the trust > relationship between them. I am fine with this formulation. Regards, Brian --uQqBmEGm2siMbWFNrSANNcMr6Kuu2iNov Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS66OGAAoJEBOZRqCi7goqVLQIAIHItJlLLhkPuab6mswZoL8H GRmuN3hvskvHsthVGpkTkfdZuYuDbutX4U4t/IvApfYZ8I3ObgV8LQqKgvx86o8m 4JKToODXwFZtnoHC9FCIlFJmro4AuLdbUnrI5d+hdNPFpzAVnd5LBWhzlYFrf5/R 54XmV453yzmAlwdplLjaePv+h0MdUDeizmit/fa1pOGqS74wSEVrKkSdtCLOBRCg qHy4evsfUIV7I0ME451lVbkW+Ujmt3aBJleyDiTHisPOy8Jy6FSLl3BLblYHfzmo JNdwrjgqXmWPvjqiqpkXGSdxuWB1Zl03Yc0fS7v2k8wgdOqURhfDNYYzNhZT1Jw= =eb5w -----END PGP SIGNATURE----- --uQqBmEGm2siMbWFNrSANNcMr6Kuu2iNov-- From liudapeng@chinamobile.com Fri Jan 31 05:29:14 2014 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 2BCA61A0522 for ; Fri, 31 Jan 2014 05:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.213 X-Spam-Level: X-Spam-Status: No, score=-0.213 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.535] 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 iKBcEJgbF6eP for ; Fri, 31 Jan 2014 05:29:12 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id CA9CE1A0193 for ; Fri, 31 Jan 2014 05:29:11 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee252eba49f481-cd481; Fri, 31 Jan 2014 21:26:56 +0800 (CST) X-RM-TRANSID: 2ee252eba49f481-cd481 Received: from cmccPC (unknown[27.190.124.82]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee352eba49fba8-049cb; Fri, 31 Jan 2014 21:26:56 +0800 (CST) X-RM-TRANSID: 2ee352eba49fba8-049cb From: "Dapeng Liu" To: "'Brian Haberman'" References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB62E@szxeml557-mbx.china.huawei.com> <52E90898.6050604@innovationslab.net> In-Reply-To: <52E90898.6050604@innovationslab.net> Date: Fri, 31 Jan 2014 21:28:57 +0800 Message-ID: <003c01cf1e88$654c79d0$2fe56d70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: Ac8c+a4TtqWwhM3OQdizjYtvEEYmLABjph+Q X-Mailman-Approved-At: Fri, 31 Jan 2014 07:33:39 -0800 Cc: 'Peter McCann' , dmm@ietf.org, draft-ietf-dmm-requirements@tools.ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 31 Jan 2014 13:29:14 -0000 -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net] Sent: Wednesday, January 29, 2014 9:57 PM To: h chan; draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements On 1/28/14 3:31 PM, h chan wrote: > REQ6: Security considerations > > > > A DMM solution MUST NOT introduce new security risks or > > amplify existing security risks against which the existing > > security mechanisms/protocols cannot offer sufficient > > protection. > > > > The intention of REQ6 is NOT that it cannot introduce new vulnerabilities at all. > > Rather the protection against such new vulnerablities can be limited to the use of existing security protocols. It is okay to provide additional means to protect against new risks as long as they do not require development of new security protocols which are needed for DMM alone but are not needed otherwise. Else a network deploying DMM versus a network not deploying DMM will need additional security protocols which are not needed otherwise. > > > > So I think the word: "existing" security mechanisms/protocols is intended to exclude protocols that are not needed otherwise. > > > > We can clarify with the following: > > > > REQ6: Security considerations > > > > A DMM solution MUST NOT introduce new security risks or > > amplify existing security risks against which security means > using existing > > security mechanisms/protocols CANNOT offer sufficient > > protection. > The above seems a little clunky. Does this work for everyone? A DMM solution MUST NOT introduce new security risks, or amplify existing security risks, that cannot be mitigated by existing security mechanisms or protocols. Works for me. Dapeng Regards, Brian From h.anthony.chan@huawei.com Fri Jan 31 13:12:25 2014 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 4CCEE1A0423 for ; Fri, 31 Jan 2014 13:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.736 X-Spam-Level: X-Spam-Status: No, score=-6.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 1xqz-jjz5S8l for ; Fri, 31 Jan 2014 13:12:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9484B1A03CC for ; Fri, 31 Jan 2014 13:12:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAR25679; Fri, 31 Jan 2014 21:12:14 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Jan 2014 21:11:32 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Jan 2014 21:12:12 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0158.001; Sat, 1 Feb 2014 05:12:10 +0800 From: h chan To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHnmbQ9RZ14LEnUqJhaclqPoou5qfU0KA Date: Fri, 31 Jan 2014 21:12:09 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EBAB8@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB2F0@szxeml557-mbx.china.huawei.com> <52E65D0E.9090109@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB4B5@szxeml557-mbx.china.huawei.com> <52E7C1E1.2020705@gmail.com> <6E31144C030982429702B11D6746B98C370EB5F0@szxeml557-mbx.china.huawei.com> <52E80484.9020200@gmail.com> <6E31144C030982429702B11D6746B98C370EB65D@szxeml557-mbx.china.huawei.com> <52E948AC.6030904@gmail.com> <6E31144C030982429702B11D6746B98C370EB866@szxeml557-mbx.china.huawei.com> <52EA09A0.70109@gmail.com> <6E31144C030982429702B11D6746B98C370EB9B3@szxeml557-mbx.china.huawei.com> <52EA8E42.5000000@gmail.com> <6E31144C030982429702B11D6746B98C370EB9FD@szxeml557-mbx.china.huawei.com> <52EB8C4A.5060402@gmail.com> In-Reply-To: <52EB8C4A.5060402@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.205] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 31 Jan 2014 21:12:25 -0000 How about the following to cut down the number of words: REQ2: Bypassable network-layer mobility support DMM solutions MUST enable network-layer mobility but it MUST be possible to not use it. Mobility support is needed, for example, when a mobile host moves and an application cannot cope with a change in the IP address. Mobility support is also needed, for example, when a mobile router moves together with a host and an application in the host is interrupted by a change of IP address of the mobile router. However mobility support at the network-layer is not always needed; a mobile node can often be stationary, and mobility support can also be provided at other layers. It is then not always necessary to maintain a stable IP address or prefix. H Anthony Chan -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Friday, January 31, 2014 5:43 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Le 30/01/2014 20:53, h chan a =E9crit : > Alex, > > I think the applications which work without MIP are the applications=20 > that can cope with the change of IP address of the MR. Is that=20 > correct? Yes, that is correct for MH. For the MR cases, any application running on the Host can cope with that ch= ange (=3D=3DTCP retransmits). > Then mobility support is needed only for those applications that=20 > cannot cope with the change of IP address of the MR. No, that is wrong. IT depends what one means by 'mobility support' - on the MR or in the netwo= rk? MR-based mobility support is needed on the MR for some kinds of application= s on Host to continue working. Infrastructure-based mobility support is alternatively needed on the MR for= some kinds of applications on Host to continue working. A mix of infrastructure-based mobility support and MR-based mobility suppor= t is needed for some kinds of applications on Host to continue working. The 3 statements are valid simultaneously. We can't just say that _only_ MR-based mobility support is needed. > So, in the two separate sentences: > >> Mobility Support on a Mobile Host is needed, for example, when a=20 >> Mobile Host moves and an arbitrary application in the Mobile Host=20 >> cannot cope with a change in the IP address of that Mobile Host=20 >> [paste socket error message here]. > > Is this MN sentence the same as: Mobility support is needed, for=20 > example, when a mobile host moves and an application cannot cope with=20 > a change in the IP address of the mobile host. Right, same. >> Mobility Support on a Mobile Router is needed, for example, when a =20 >> Mobile Router moves together with a set of Hosts and Routers, and =20 >> arbitrary applications in the Hosts and Routers need to maintain=20 >> their IP address fixed regardless of the change of the IP address of=20 >> the Mobile Router, and the Access Router performs ingress filtering,=20 >> and reachability of these Hosts and Routers at a fixed IP address is=20 >> necessary. > > When the MR carries a network of hosts and routers, doesn't these=20 > routers in turn carry network so that at the final level of hosts, the=20 > applications are running there. If so, is it sufficient to state the=20 > applications in the hosts? (which includes hosts in the network of=20 > routers which are in turn in the network of the mobile router) YEs, it is sufficient. > So a host in the network of a router, which in turn is in the network=20 > of another router, which .... in the network of the mobile router can=20 > be called a host that moves with the mobile router. YEs. > Then is the MR sentence the above the same as > > Mobility support is also needed, for example, when a mobile router=20 > moves together and an application in a host that moves with the ^ together with the Host > mobile router cannot cope with a change of IP address of the mobile=20 > router. YEs. At this point we should say that [infrastructure-based, or MR-based, or a m= ix of the two] mobility support is needed, for example, when a Mobile Route= r moves together with the Host and an application on the latter is interrup= ted by the change of the IP address of the former. (because we don't want that Host to cope with it; if we say 'can not cope' = it's like if we wanted it to). Alex > REQ2: Bypassable Network-layer mobility support > > DMM solutions MUST enable network-layer mobility but it MUST be=20 > possible to not use it. > > Mobility support is needed, for example, when a mobile host moves and=20 > an application cannot cope with a change in the IP address. > > Mobility support is also needed, for example, when a mobile router=20 > moves together and an application in a host which moves with the=20 > mobile router cannot cope with a change of IP address of the mobile=20 > router. > > However mobility support at the network-layer is not always needed; a=20 > mobile node can often be stationary, and mobility support can also be=20 > provided at other layers. It is then not always necessary to maintain=20 > a stable IP address or prefix. > > One more alternative is to mention the "no need" case only without=20 > explaining the "needed" case as in the following. Yet if it is=20 > possible to state the "needed" case more concisely, it will be more=20 > clear to spell that out as in above. > > REQ2: Bypassable Network-layer mobility support > > DMM solutions MUST enable network-layer mobility but it MUST be=20 > possible to not use it. Mobility support at the network-layer is not=20 > always needed; a mobile node can often be stationary, and mobility=20 > support can also be provided at other layers. It is then not always=20 > necessary to maintain a stable IP address or prefix. > > H Anthony Chan > > > -----Original Message----- From: Alexandru Petrescu=20 > [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, January 30, > 2014 11:39 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD > Evaluation: draft-ietf-dmm-requirements > > Le 30/01/2014 18:08, h chan a =E9crit : >> Alex, >> >> Is the following correct? >> >> Mobility support is needed, for example, when a mobile host or a=20 >> mobile router moves and an application in the mobile host or in a=20 >> host that moves with the router cannot cope with a change in the IP=20 >> address of the mobile node. > > Makes better sense, thanks. > > But still uses that word 'Mobile Node' which is confusing. How about=20 > this: > >> Mobility support is needed, for example, when a Mobile Host or a=20 >> Mobile Router moves and an application in the Mobile Host or in a=20 >> host or router that moves with that Mobile Router cannot cope with a=20 >> change in the IP address of the mobile host or of that Mobile Router. > > It would be more precise. > > But even then, it does not hold, because a Host that moves with the=20 > Mobile Router is not that much influenced by the change of IP address=20 > of that MR. When the MR changes its IP address, the Host feels it=20 > just like some other interruption in the path to another CN. > These kinds of interruptions (link up/down) happen often in the fixed=20 > networks and yet Hosts continue to work. > > It is possible, for example, to have a Mobile Router move, have NAT=20 > (not mobility management), change IP address, and the Hosts and=20 > Routers in that moving network will continue working ok. > > It is also possible for MR to not have NAT, and forward packets with=20 > an address which is not topological correct in that network. These=20 > packets will reach their destinations (provided there's no ingress=20 > filtering), and the replies will not arrive. Some applications do not=20 > need packets to return. One can very well have a vehicle which=20 > streams the video of its front camera to some particular server in the=20 > Internet, and change its IP address at each access. This does not=20 > require Mobile IP nor NAT. > > I think it is impossible to stay meaningful in one phrase talking both=20 > Mobile Host and Mobile Router at the same time. I think we need maybe=20 > two phrases. > >> Mobility Support on a Mobile Host is needed, for example, when a=20 >> Mobile Host moves and an arbitrary application in the Mobile Host=20 >> cannot cope with a change in the IP address of that Mobile Host=20 >> [paste socket error message here]. >> >> Mobility Support on a Mobile Router is needed, for example, when a =20 >> Mobile Router moves together with a set of Hosts and Routers, and =20 >> arbitrary applications in the Hosts and Routers need to maintain=20 >> their IP address fixed regardless of the change of the IP address of=20 >> the Mobile Router, and the Access Router performs ingress filtering,=20 >> and reachability of these Hosts and Routers at a fixed IP address is=20 >> necessary. > > Alex > >> >> H Anthony Chan >> >> -----Original Message----- From: Alexandru Petrescu=20 >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, January 30, >> 2014 2:13 AM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD >> Evaluation: draft-ietf-dmm-requirements >> >> Le 29/01/2014 20:45, h chan a =E9crit : >>> Alex >>> >>> How about the following: >>> >>> REQ2: Using and not Using Network-layer mobility support >>> >>> DMM solutions MUST enable network-layer mobility >>> >>> but it MUST be possible to not invoke it. >>> >>> Mobility support is needed, for example, >>> >>> when an application (of a MN or a host in a mobile network of a >>> MR) >> ^a LFN (because just 'host' may be confused with Mobile Host; and=20 >> also because within the moving network there is also one or several=20 >> Routers - not hosts.) >> >>> cannot cope with a change in the >>> >>> IP address of the mobile node when the node moves. >> ^Mobile Host or of the Mobile Router moves (because when the 'node' >> moves it may mean that the 'host' in the moving network moves, and=20 >> that doesn't change its IP address). >> >>> Yet a mobile node can often be stationary, >>> >>> and mobility support can also be provided at other layers. >>> >>> It is then not always necessary to maintain a >>> >>> stable IP address or prefix. >>> >>> Can the text in red be valid for both host or router? >> >> Yes and no. I agree with it, but I'd prefer the suggested=20 >> modifications. >> >> Alex >> >>> >>> When the node is a router: >>> >>> an application (of a host in a mobile network) may not be able to=20 >>> cope with a change in the IP address of the MR when the MR moves. >>> >>> When the node is a host >>> >>> an application (of a MN) may not be able to cope with a change in=20 >>> the IP address of the MN when the MN moves. >>> >>> H Anthony Chan >>> >>> -----Original Message----- From: Alexandru Petrescu=20 >>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, January 29,=20 >>> 2014 12:30 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] AD >>> Evaluation: draft-ietf-dmm-requirements >>> >>> Le 28/01/2014 23:33, h chan a =E9crit : >>> >>>> Let us try to include MR. >>> >>>> >>> >>>> How about the following >>> >>>> >>> >>>> REQ2: Network-layer mobility support when needed >>> >>>> >>> >>>> DMM solutions MUST enable network-layer >>> >>>> mobility when needed. >>> >>>> Such mobility support is needed, for >>> >>>> example, when an application or a host cannot cope with a >>> change in the >>> >>>> IP address when a node moves. However, it is not always >>> necessary to maintain a >>> >>>> stable IP address or prefix. >>> >>>> >>> >>>> Here, the node can be a mobile host or a mobile router. >>> >>> I am not sure the term 'node' is agreed to cover both an MH and an=20 >>> MR. >>> >>> I think in all descriptions it would be clearer if we just said MH=20 >>> when we meant Mobile Host and MR when we meant Mobile Router. >>> >>> Le me paraphrase this text in RFC6275: >>> >>>> This document specifies a protocol that allows nodes to remain >>> >>>> reachable while moving around in the IPv6 Internet. Without=20 >>>> specific >>> >>>> support for mobility in IPv6 [6], packets destined to a mobile node >>> >>>> would not be able to reach it while the mobile node is away from=20 >>>> its >>> >>>> home link. >>> >>> There is a clear ambiguity in the 'mobile node' used above. >>> Because if we talk moving networks then often the packets are=20 >>> destined (the contents of the destination address) to a LFN, not to=20 >>> the MR. >>> >>> If that 'node' were a Mobile Router (not a Mobile Host) it=20 >>> completely misses the case when packets are destined to the LFN,=20 >>> which is not an MH nor an MR. >>> >>> The phrase should rather say: >>> >>> 'packets destined to a MH (or to a LFN behind a MR) would not be=20 >>> able >>> >>> to reach it while that MH (or the MR and LFN) is away from its home >>> >>> link.' >>> >>> This kind if expression would be clearer. >>> >>> Alex >>> >>> 'packets destined to a [LFN] or to the Mobile Host, or to the Mobile=20 >>> Router, would not be able to reach it while the Mobile Router is=20 >>> away from its home link'. >>> >>>> A host can be a mobile host or a host in a LFN. >>> >>>> An application can be running on a mobile host or a on a host in a=20 >>>> LFN. >>> >>>> A MR also does not need to maintain stable IP address or prefix=20 >>>> when >>> there are no hosts attached to it or when there are no active=20 >>> applications running in the hosts of its network. >>> >>>> >>> >>>> Any comments/changes/corrections? >>> >>>> >>> >>>> H Anthony Chan >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>> >>>> Sent: Tuesday, January 28, 2014 1:27 PM >>> >>>> To: h chan; dmm@ietf.org >>> >>>> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements >>> >>>> >>> >>>> Le 28/01/2014 19:58, h chan a =E9crit : >>> >>>>> Let me try to understand the concern here. >>> >>>>> >>> >>>>> What is new in this requirement is "when needed" in contrast to >>> >>>>> providing IP mobility by default. >>> >>>> >>> >>>> First, providing mobility by default is not a black/white=20 >>>> alternative >>> to not providing mobility. >>> >>>> >>> >>>> It is very possible on the same machine to have Mobile IP enabled=20 >>>> for >>> some flows and disabled for others (depending what we call a=20 >>> 'flow'). >>> >>>> It is also possible to have Mobile IP and NAT at the same time on=20 >>>> the >>> same Mobile Router. >>> >>>> >>> >>>>> Without this requirement, mobility support may be provided by >>> >>>>> default, which is transparent to higher layers. >>> >>>> >>> >>>> Again, transparency to higher layers means we talk mobility >>> management on a Mobile Host. >>> >>>> >>> >>>> Transparency to higher layers has little meaning if we talk=20 >>>> mobility >>> management provided on a Mobile Router (which is not a Mobile Host). >>> >>>> >>> >>>>> With this requirement, assume there are separate steps in the DMM >>> >>>>> solution. 1. A decision is made whether network-layer mobility >>> >>>>> support is needed. 2. When the need is established, network-layer >>> >>>>> mobility support is invoked. 3. Then transparent support is=20 >>>>> provided >>> >>>>> and is transparent to layers above IP. >>> >>>>> >>> >>>>> Transparency is clear in step 3 above. >>> >>>> >>> >>>> This looks like a trigger which enables mobility, or other times >>> disables it. >>> >>>> >>> >>>> But one can have a Mobile IP daemon and a NAT run at the same time=20 >>>> on >>> the same machine. There is no decision in time. >>> >>>> >>> >>>> Some decision happens at packet based on IP destination address. >>> >>>> >>> >>>>> The question however is whether the preceding steps involve >>>>> the >>> >>>>> application, so that one may question whether the entire DMM >>>>> solution >>> >>>>> (with all the steps) as a whole is transparent. >>> >>>> >>> >>>> I agree. I am not aware of any application which talks to >>>> Mobile IP. >>> >>>> Whenever it is there it is 'transparent'. >>> >>>> >>> >>>>> So the intention of the requirement is that WHEN/AFTER the >>>>> decision >>> >>>>> is made to invoke mobility support, then the mobility >>>>> support is >>> >>>>> transparent to the application. Then we may want to check >>>>> and make >>> >>>>> sure the emphasis of this requirement does mean transparency >>>>> in this >>> >>>>> respect only. >>> >>>> >>> >>>> I disagree. >>> >>>> >>> >>>> As I said above, the word 'transparency' is dubious. Some >>>> times it >>>> >>> may mean 'non-existent', some times it may mean light goes >>> through it but modified. >>> >>>> >>> >>>> If one wants to continue using it, then one should better >>>> qualify it >>> with 'Mobile Host', with 'Upper Layers' and with 'BSD Socket >>> Interface'. >>> >>>> >>> >>>> Because a Mobile Router doing mobility management in a >>>> transparent >>>> >>> manner on the Mobile Router for the LFN has nothing to do with >>> applications, neither with upper layers. >>> >>>> >>> >>>> Also, a Mobile Router doing NAT and Mobile IP at the same time >>>> is >>> 50%-transparent. >>> >>>> >>> >>>>> >>> >>>>> Original wording: >>> >>>>> >>> >>>>> REQ2: Transparency to Upper Layers when needed >>> >>>>> >>> >>>>> DMM solutions MUST provide transparent mobility support >>>>> above the IP >>> >>>>> layer when needed. Such transparency is needed, for >>>>> example, when, >>> >>>> ^on a Mobile Host. >>> >>>>> upon change of point of attachment to the network, an >>>>> application >>> >>>>> flow cannot cope with a change in the IP address. >>> >>>> >>> >>>> (it's not the application flow, it is a socket which some >>>> times may >>> >>>> break [paste here the error from the screen]; the term >>>> 'application >>> >>>> flow' in this context has little meaning) >>> >>>> >>> >>>> (an 'application flow' has no understandable meaning in >>>> practice). >>> >>>> >>> >>>>> However, it is not always necessary to maintain a stable home >>>>> IP >>> >>>>> address or prefix for every application or at all times for a >>>>> mobile >>> >>>>> node. >>> >>>> ^a Mobile Host. >>> >>>> >>> >>>> I agree. >>> >>>> >>> >>>>> I now tend to think the first sentence in this original >>>>> wording may >>> >>>>> steer the emphasis on providing transparent support, which is >>>>> not >>> >>>>> what the motivation and the problems are talking about. >>> >>>> >>> >>>> I agree. >>> >>>> >>> >>>>> The motivation and the problems are talking about when they >>>>> are not >>> >>>>> needed. The emphasis of this requirement therefore is on the >>> >>>>> capability to turn OFF unnecessary mobility support. >>> >>>> >>> >>>> In a sense I agree with the meaning. >>> >>>> >>> >>>> But when trying to turn off or on mobility support the things >>>> are not >>> like if there were a knob on/off, not even like starting/stopping >>> some daemon. It is a matter of always having the Mobile IP >>> support on, and tweak the routing table with some particular >>> entries, and the firewalling rules to NAT some addresses or not. >>> >>>> >>> >>>>> How about the following >>> >>>>> >>> >>>>> REQ2: Network-layer mobility support ONLY when needed >>> >>>> >>> >>>> If we understood better when it was needed... >>> >>>> >>> >>>>> DMM solutions MUST NOT provide network-layer mobility support >>>>> when >>> >>>>> NOT needed. >>> >>>> >>> >>>> I would say that Mobile IP MUST always be turned on on a Mobile >>>> Host. >>> >>>> >>> >>>>> (or if you don't like double negatives: (DMM solutions MUST >>>>> provide >>> >>>>> network-layer mobility support ONLY when needed) >>> >>>> >>> >>>> No, I would say to have it always on. If some applications >>>> don't >>> want it then dont use it; realize that by inserting routing table >>> entries. >>> >>>> >>> >>>> One may wonder when some applications dont want it. One answer >>>> is >>>> >>> when some applications prefer to not go through the HA in order >>> to take advantage of the 4G pure speed. When? For example if >>> the HA link is too slow compared to 4G. (remark this is not the >>> same as saying that the triangular route is longer than >>> straight, because that is always true). >>> >>>> >>> >>>> This is not a request for Route Optimization. It is an >>>> invitation to >>> analyze in deeper detail the application needs. >>> >>>> >>> >>>> One may have an application start via the HA (offer >>>> reachability) and >>> continue straight, w/o HA. It's the same application. >>> >>>> >>> >>>> Consider a video-call like appli: you want to be reachable >>>> always at >>> the same IP address (through HA) but once the session is ongoing >>> you may not want to use it through HA if no handover in sight. >>> >>>> >>> >>>> Something like that. >>> >>>> >>> >>>> These things could be further refined if we really went into >>>> detail >>>> >>> and understood what are the needs of applications, the >>> distinctions MH-MR, etc. >>> >>>> >>> >>>>> Such transparent mobility support above the IP layer is >>>>> needed, for >>> >>>>> example, when, upon change of point of attachment to the >>>>> network, an >>> >>>>> application flow cannot cope with a change in the IP >>>>> address. >>> >>>>> However, it is not always necessary to maintain a stable home >>>>> IP >>> >>>>> address or prefix for every application or at all times for a >>>>> mobile >>> >>>>> node. >>> >>>> >>> >>>> A Mobile Host never maintains a stable prefix, only a stable >>>> address. >>> >>>> >>> >>>> A Mobile Router may maintain a stable address (its HoA) and >>>> may >>> maintain a stable prefix (its MNP). It could also just maintain >>> stable just its MNP, but not its HoA; and vice-versa. Is that >>> mobility? >>> >>>> >>> >>>> For each of these there is an application :-) >>> >>>> >>> >>>> Alex >>> >>>> >>> >>>>> >>> >>>>> Any comments/changes/corrections? >>> >>>>> >>> >>>>> H Anthony Chan >>> >>>>> >>> >>>>> -----Original Message----- From: dmm >>>>> [mailto:dmm-bounces@ietf.org] On >>> >>>>> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 >>>>> 8:43 AM >>> >>>>> To: dmm@ietf.org Subject: Re: [DMM] AD >>>>> Evaluation: >>> >>>>> draft-ietf-dmm-requirements >>> >>>>> >>> >>>>> Le 28/01/2014 02:45, h chan a =E9crit : >>> >>>>>> I will drop "related" >>> >>>>>> >>> >>>>>> Regarding the following >>> >>>>>> >>> >>>>>> 5. Section 5: - I am a little confused by REQ2. It says >>>>>> that a DMM >>> >>>>>> solution should be transparent to the applications. >>> >>>>> >>> >>>>> This remark is typically true when we talk Mobile IP on a >>>>> Mobile Host >>> >>>>> and an application like firefox runs above a BSD Socket >>>>> interface. >>> >>>>> >>> >>>>> >>> >>>>>> However, the motivation talks about identifying >>>>>> applications that do >>> >>>>>> (or do not) need mobility support from the network layer. >>>>>> That >>> >>>>>> doesn't sound transparent to me. Am I reading this >>>>>> incorrectly? >>> >>>>>> >>> >>>>>> It appears that unless the network can find out whether >>>>>> the >>> >>>>>> application has need of such support, the application >>>>>> indeed may >>> >>>>>> need to invoke mobility support or has to convey its need >>>>>> to the >>> network. >>> >>>>>> >>> >>>>>> The emphasis of requirement is on "when needed." So, I >>>>>> think it is >>> >>>>>> better to drop the word "transparent" as follows: >>> >>>>>> >>> >>>>>> REQ2: Mobility support when needed >>> >>>>>> >>> >>>>>> DMM solutions MUST provide mobility support to above the IP >>>>>> layer >>> >>>>>> when needed. Such support is needed, for example, when, >>>>>> upon change >>> >>>>>> of point of attachment to the network, an application flow >>>>>> cannot >>> >>>>>> cope with a change in the IP address. However, it is not >>>>>> always >>> >>>>>> necessary to maintain a stable home IP address or prefix >>>>>> for every >>> >>>>>> application or at all times for a mobile node. >>> >>>>>> >>> >>>>>> Motivation: The motivation of this requirement is to enable >>>>>> more >>> >>>>>> efficient routing and more efficient use of network >>>>>> resources by >>> >>>>>> selecting an IP address or prefix according to whether >>>>>> mobility >>> >>>>>> support is needed and by not maintaining context at the >>>>>> mobility >>> >>>>>> anchor when there is no such need. >>> >>>>> >>> >>>>> Whenever we discuss this 'transparency' paragraph I have >>>>> again the >>> >>>>> same comments. >>> >>>>> >>> >>>>> First, I am not sure DMM is only about Mobile Hosts, or about >>>>> Mobile >>> >>>>> Routers as well. >>> >>>>> >>> >>>>> Because, if we talk Mobile Routers, then rarely an >>>>> application runs >>> >>>>> directly on it. Most applications would run on LFN. >>> >>>>> >>> >>>>> Transparency? >>> >>>>> >>> >>>>> If the applications run on the LFN, the change of the >>>>> attachment of >>> >>>>> the MR is 'transparent' to them, regardless whether or not MR >>>>> does >>> >>>>> something to maintain stability of that address (Mobile IP, >>>>> other). >>> >>>>> >>> >>>>> Second, this transparency may depend on the direction, or >>>>> more >>> >>>>> complex 'shape' of the application flows. Some IP flows of >>>>> some >>> >>>>> applications have very complex 'shapes', with various sets of >>>>> IP src >>> >>>>> and dst, and triangular or HA-less shapes. >>> >>>>> >>> >>>>> Take for example a video-call. The session establishment >>>>> through an >>> >>>>> intermediary and behind NAT is followed by the ongoing 4 >>>>> flows (2 >>> >>>>> audio 2 video)... they all take different paths... each may >>>>> need or >>> >>>>> not need to go through the HA, and each has distinct >>>>> behaviours when >>> >>>>> the IP address changes, hence each would have a distinct >>> >>>>> 'transparency' requirement. Is this _one_ application? >>> >>>>> >>> >>>>> Alex >>> >>>>> >>> >>>>>> >>> >>>>>> H Anthony Chan >>> >>>>>> >>> >>>>>> -----Original Message----- From: dmm >>>>>> [mailto:dmm-bounces@ietf.org] >>> >>>>>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 >>>>>> 7:20 AM >>> >>>>>> To: h chan; draft-ietf-dmm-requirements@tools.ietf.org >>> ; >>> >>>>>> dmm@ietf.org ; Peter McCann Subject: >>>>>> Re: [DMM] >>> AD Evaluation: >>> >>>>>> draft-ietf-dmm-requirements >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> On 1/24/14 7:38 PM, h chan wrote: >>> >>>>>>> 4. Section 4: - I am not sure that it benefits the >>>>>>> document to >>> >>>>>>> label >>> >>>>>>> PS6 and PS7 as related. Those issues are problematic on >>>>>>> their own. >>> >>>>>>> If you remove the "(related problem)" label from them, >>>>>>> make sure >>> >>>>>>> that REQ2 is updated to remove mention of "related >>>>>>> problem". >>> >>>>>>> >>> >>>>>>> The intention of the name "related problems" was not to >>>>>>> suggest >>> >>>>>>> they are less problematic, but rather to distinguish them >>>>>>> from the >>> >>>>>>> other problems directly on mobility management. Although >>>>>>> these >>> >>>>>>> problems are not directly on mobility management, the DMM >>>>>>> solutions >>> >>>>>>> can solve these additional problems. They are therefore >>>>>>> included. >>> >>>>>>> So, as long as this section is not to be interpreted as >>>>>>> limited to >>> >>>>>>> problems directly on mobility management, we can drop the >>>>>>> word >>> "related." >>> >>>>>>> >>> >>>>>> >>> >>>>>> I will leave it to the authors/WG, but I don't see a >>>>>> benefit to the >>> >>>>>> "related" tag. >>> >>>>>> >>> >>>>>> 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 internet-drafts@ietf.org Fri Jan 31 13:25:05 2014 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 C42C01A04B3; Fri, 31 Jan 2014 13:25:05 -0800 (PST) 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 Jp0Fca59jhfF; Fri, 31 Jan 2014 13:25:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 155D71A03CC; Fri, 31 Jan 2014 13:25:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140131212503.25462.84436.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 13:25:03 -0800 Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-13.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 21:25:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management Working Group of the IETF. Title : Requirements for Distributed Mobility Management Authors : H Anthony Chan Dapeng Liu Pierrick Seite Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-dmm-requirements-13.txt Pages : 19 Date : 2014-01-31 Abstract: This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centralized deployment models. As some wireless networks are evolving away from the hierarchical structure, a distributed model for mobility management can be useful to them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-requirements-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-requirements-13 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From h.anthony.chan@huawei.com Fri Jan 31 14:25:18 2014 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 AEFAC1A04E8 for ; Fri, 31 Jan 2014 14:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 3WORdTCMbWld for ; Fri, 31 Jan 2014 14:25:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3A3E1A04DF for ; Fri, 31 Jan 2014 14:25:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAR28386; Fri, 31 Jan 2014 22:25:08 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Jan 2014 22:24:26 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Jan 2014 22:25:06 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.03.0158.001; Sat, 1 Feb 2014 06:24:55 +0800 From: h chan To: Brian Haberman , "draft-ietf-dmm-requirements@tools.ietf.org" , "dmm@ietf.org" , Peter McCann Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPGSnmR1nPMPdjp0Khf0EqkSOySJqfa2sw Date: Fri, 31 Jan 2014 22:24:54 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EBAE5@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> In-Reply-To: <52E2A30A.1020705@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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, 31 Jan 2014 22:25:18 -0000 Regarding the following: 6. I would like to avoid issues further along the publication chain, so I w= ould like the editors to look at how the contributing authors are identifie= d in the draft. A good approach is described in the RFC Style Guide (https= ://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can = be problematic. ------------------ I have now read the guidelines that the list of authors refer to those on t= he front page only. This draft had benefited from very valuable inputs from= many people, so that I had in the past tried to give the deserved recognit= ion to name more co-authors by listing their names inside. I managed to get= around with the ietf template so that I thought it was possible. Yet I now= found that it is not in compliance with the rfc guidelines. The relevant s= ections of the guidelines are pasted at the end.=20 I apologize for not having read these guidelines before. In the future revi= sion, other than the authors in the front page, I can only acknowledge the = valuable inputs from all the rest as contributors together with contact inf= ormation, and I am sorry for having caused the misunderstanding and especia= lly if it hurts anyone's feeling now. As the work of the requirements draft is drawing close to completion now, I= thank everyone again for the very helpful and useful work.=20 H Anthony Chan ---------------- Authors vs. Contributors=20 Questions are still arising about the editorial policies on RFC authorship,= and the contents of the first page, of the Contributors section, and of th= e Authors' Address section. We will attempt to clarify.=20 1. When the RFC Editor refers to "authors", we mean exactly the set of name= s listed on the first page of an RFC. These people are considered to be equ= ally responsible for the contents of the document, and all will be asked to= read and approve the RFC before publication.=20 2. When the RFC Editor refers to "contributors", we mean people, other than= the authors, who also contributed significantly to the RFC. They should be= listed in a Contributors section of the body of the document.=20 3. The last section of the document has traditionally been a section listin= g contact information for authors. The intent of this section is to tell re= aders how to get in touch with those people responsible for the document, t= o seek clarification, make comments, etc. This section should include conta= ct information for all authors. This section has been titled "Author's Addr= ess" (or "Authors' Addresses").=20 4. The issue has arisen: can/should the Contributors section include contac= t information? The answer is yes, it may include contact information at the= authors' discretion.=20 19 August 2003. Updated 18 October 2006. Updated 14 June 2011. -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Friday, January 24, 2014 11:30 AM To: draft-ietf-dmm-requirements@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements All, I have performed my AD review, as a part of the publication process, o= f draft-ietf-dmm-requirements. The following issues should be addressed pr= ior to moving this draft to IETF Last Call. Please let me know if you have= any questions on these points. 1. I would suggest making sure that the Abstract and Introduction explicitl= y state that these requirements for for network (L3)-layer mobility managem= ent. 2. Introduction: - The EPC acronym needs to be expanded. - Do not reference the DMM charter within the document. - expand HA and LMA since you are using them before the Terminology section= . 3. Section 3: - It would be nice to ensure that all acronyms used in the figures are expa= nded somewhere prior to the figures. - I am curious as to why there is not any mention in this section about rou= te optimization within the mobility protocols. This mention should describ= e why current route optimization is host-based in order to lead into PS1. 4. Section 4: - To be abundantly clear, I would re-word the start of PS3 to be "Lack of s= calability". - I am not sure that it benefits the document to label PS6 and PS7 as relat= ed. Those issues are problematic on their own. If you remove the "(relate= d problem)" label from them, make sure that REQ2 is updated to remove menti= on of "related problem". - Should PS7 mention mobility solutions that operated at other layers of th= e protocol stack? 5. Section 5: - Why does this section have sub-section numbers AND REQ numbers? - I am not sure I understand what REQ1 is saying when it talks about combin= ing mobility anchors with CDNs. It *sounds* like mobility management needs= to be maintained by CDN providers. - I am a little confused by REQ2. It says that a DMM solution should be tr= ansparent to the applications. However, the motivation talks about identif= ying applications that do (or do not) need mobility support from the networ= k layer. That doesn't sound transparent to me. Am I reading this incorrec= tly? - I am wondering if the SHOULD in REQ4 ought to be a MUST. Why would anyon= e work on a new protocol without first determining the feasibility of the e= xisting ones? - What is meant by co-exist in REQ5? Does this mean that a DMM solution do= es not break an existing one? Or does it mean that it must inter-operate w= ith existing ones? Is this like IPv4 and IPv6 being incompatible, but can = run concurrently on the same network? Or does this mean there needs to be = some mechanism for interaction (i.e., like NAT64)? - I think REQ6 is incomplete. A DMM solution can introduce new vulnerabili= ties, but it needs to provide ways to cope with those vulnerabilities. 6. I would like to avoid issues further along the publication chain, so I w= ould like the editors to look at how the contributing authors are identifie= d in the draft. A good approach is described in the RFC Style Guide (https= ://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can = be problematic. Regards, Brian From h.anthony.chan@huawei.com Fri Jan 31 16:14:02 2014 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 257F31AC7EE for ; Fri, 31 Jan 2014 16:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 Ahr86Js_6EUo for ; Fri, 31 Jan 2014 16:14:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6401A04F6 for ; Fri, 31 Jan 2014 16:14:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDD28262; Sat, 01 Feb 2014 00:13:55 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 1 Feb 2014 00:13:27 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 1 Feb 2014 00:13:54 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0158.001; Sat, 1 Feb 2014 08:13:48 +0800 From: h chan To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] AD Evaluation: draft-ietf-dmm-requirements Thread-Index: AQHPHnnQQ9RZ14LEnUqJhaclqPoou5qfho1w Date: Sat, 1 Feb 2014 00:13:48 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370EBAFD@szxeml557-mbx.china.huawei.com> References: <52E2A30A.1020705@innovationslab.net> <6E31144C030982429702B11D6746B98C370EB62E@szxeml557-mbx.china.huawei.com> <52E90898.6050604@innovationslab.net> <52EB8CA4.9020200@gmail.com> In-Reply-To: <52EB8CA4.9020200@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.205] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements 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: Sat, 01 Feb 2014 00:14:02 -0000 Alex, There are some examples in the motivation following REQ6. Do you think the = rouge route example is included in the "redirecting traffic from its legiti= mate path" or should it be added as a separate example? REQ6: Security considerations A DMM solution MUST NOT introduce new security risks, or amplify existing security risks, that cannot be mitigated by existing security mechanisms or protocols. Motivation: Various attacks such as impersonation, denial of service, man-in-the-middle attacks, and so on, may be launched in a DMM deployment. For instance, an illegitimate node may attempt to access a network providing DMM. Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node is under a denial of service attack, whereas other nodes do not receive their traffic. Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. can be used to protect the DMM entities as they are already used to protect against existing networks and existing mobility protocols defined in IETF. This requirement prevents a DMM solution from introducing uncontrollable problems of potentially insecure mobility management protocols which make deployment infeasible because platforms conforming to the protocols are at risk for data loss and numerous other dangers, including financial harm to the users. H Anthony Chan -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, January 31, 2014 5:45 AM To: dmm@ietf.org Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements Le 31/01/2014 00:18, Jouni Korhonen a =E9crit : > > On Jan 29, 2014, at 5:56 AM, Brian Haberman wr= ote: > > [snip] > >> >> The above seems a little clunky. Does this work for everyone? >> >> >> A DMM solution MUST NOT introduce new security risks, or amplify=20 >> existing security risks, that cannot be mitigated by existing=20 >> security mechanisms or protocols. > > > Would work for me. To me this is too hig-level. IT's a good principle that we apply everywhere and it works. But I wonder there is some detail about it. Like for example: any new DMM solution involving route updates will not all= ow rogue routes to be inserted in the system. Alex > > - Jouni > > >> >> >> 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