From nemo-admin@ietf.org Mon Mar 1 00:18:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04890 for ; Mon, 1 Mar 2004 00:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfoX-00044G-Ny; Mon, 01 Mar 2004 00:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfnx-00042W-7c for nemo@optimus.ietf.org; Mon, 01 Mar 2004 00:17:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04816 for ; Mon, 1 Mar 2004 00:17:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfnu-00015H-00 for nemo@ietf.org; Mon, 01 Mar 2004 00:17:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axfn1-0000zt-00 for nemo@ietf.org; Mon, 01 Mar 2004 00:16:28 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxfmE-0000tp-00 for nemo@ietf.org; Mon, 01 Mar 2004 00:15:38 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i215Fbha024806 for ; Sun, 29 Feb 2004 21:15:37 -0800 (PST) Message-ID: <4042C703.5090901@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 21:15:47 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Subject: Re: [nemo] a special discussion session for threat analysis and security requirements References: <4042B535.5010003@cs.ucdavis.edu> In-Reply-To: <4042B535.5010003@cs.ucdavis.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I forgot to mention in my earlier message -- if you can not attend the meeting or the discussion meeting, you are very welcome to submit your opinions and comments regarding the security issue in NEMO. -Felix S. Felix Wu wrote: > Hi, > > It seems to me that we have many folks are interested in working on > security/threat related issues under NEMO, while, as TJ concluded > today, we still need a good external review for security issues. > > In order for us to work together more effectively as a team and > to consolidate different efforts, I proposed to TJ that maybe we > should have a special meeting this week in Seoul to discuss about > security issue. This special discussion will be open to any one > who is interested in the security issue under NEMO. > > I propose two options for the meeting time: > (1). 11-12 on Wed morning > (2). 11-12 on Thu morning > > For those of you who are indeed interested in joining us, please > let me know in emails whether any one of the propsed time is good > for you. And, then, after I collect all the inputs, I will announce > tomorrow around 4:00 p.m. to the NEMO mailing list. > > Draft Agenda: > (1). Introduce ourselves > (2). status of all current drafts > (3). what should we really achieve regarding the security issue > in NEMO? > (4). "how to achieve that goal" and hopefully some action items > before the next IETF. > > Thanks. Any comments will be welcome. > -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 00:20:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05028 for ; Mon, 1 Mar 2004 00:20:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfq1-0004Dr-Hx for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 00:19:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215JX1v016225 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 00:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfq1-0004Dc-DW for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:19:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04955 for ; Mon, 1 Mar 2004 00:19:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfpz-0001IC-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 00:19:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axfp0-0001Ce-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 00:18:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfoY-00017G-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 00:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfoX-00044G-Ny; Mon, 01 Mar 2004 00:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfnx-00042W-7c for nemo@optimus.ietf.org; Mon, 01 Mar 2004 00:17:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04816 for ; Mon, 1 Mar 2004 00:17:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfnu-00015H-00 for nemo@ietf.org; Mon, 01 Mar 2004 00:17:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axfn1-0000zt-00 for nemo@ietf.org; Mon, 01 Mar 2004 00:16:28 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxfmE-0000tp-00 for nemo@ietf.org; Mon, 01 Mar 2004 00:15:38 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i215Fbha024806 for ; Sun, 29 Feb 2004 21:15:37 -0800 (PST) Message-ID: <4042C703.5090901@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 21:15:47 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Subject: Re: [nemo] a special discussion session for threat analysis and security requirements References: <4042B535.5010003@cs.ucdavis.edu> In-Reply-To: <4042B535.5010003@cs.ucdavis.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I forgot to mention in my earlier message -- if you can not attend the meeting or the discussion meeting, you are very welcome to submit your opinions and comments regarding the security issue in NEMO. -Felix S. Felix Wu wrote: > Hi, > > It seems to me that we have many folks are interested in working on > security/threat related issues under NEMO, while, as TJ concluded > today, we still need a good external review for security issues. > > In order for us to work together more effectively as a team and > to consolidate different efforts, I proposed to TJ that maybe we > should have a special meeting this week in Seoul to discuss about > security issue. This special discussion will be open to any one > who is interested in the security issue under NEMO. > > I propose two options for the meeting time: > (1). 11-12 on Wed morning > (2). 11-12 on Thu morning > > For those of you who are indeed interested in joining us, please > let me know in emails whether any one of the propsed time is good > for you. And, then, after I collect all the inputs, I will announce > tomorrow around 4:00 p.m. to the NEMO mailing list. > > Draft Agenda: > (1). Introduce ourselves > (2). status of all current drafts > (3). what should we really achieve regarding the security issue > in NEMO? > (4). "how to achieve that goal" and hopefully some action items > before the next IETF. > > Thanks. Any comments will be welcome. > -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Mon Mar 1 04:54:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05979 for ; Mon, 1 Mar 2004 04:54:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axk7d-0007c0-8r; Mon, 01 Mar 2004 04:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axk7K-0007bH-Ag for nemo@optimus.ietf.org; Mon, 01 Mar 2004 04:53:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05969 for ; Mon, 1 Mar 2004 04:53:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axk7H-0006LG-00 for nemo@ietf.org; Mon, 01 Mar 2004 04:53:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axk6Q-0006GE-00 for nemo@ietf.org; Mon, 01 Mar 2004 04:52:46 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1Axk5s-0006A8-00 for nemo@ietf.org; Mon, 01 Mar 2004 04:52:12 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i219po5h007059; Mon, 1 Mar 2004 02:52:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i219phjT027990; Mon, 1 Mar 2004 03:51:44 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6A6A685272E; Mon, 1 Mar 2004 10:51:43 +0100 (CET) Message-ID: <404307AE.60701@motorola.com> Date: Mon, 01 Mar 2004 10:51:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "S. Felix Wu" Cc: IETF NEMO WG , Hong-Yon Lach Subject: Re: [nemo] a special discussion session for threat analysis and security requirements References: <4042B535.5010003@cs.ucdavis.edu> <4042C703.5090901@cs.ucdavis.edu> In-Reply-To: <4042C703.5090901@cs.ucdavis.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit S. Felix Wu wrote: > > I forgot to mention in my earlier message -- if you can not attend > the meeting or the discussion meeting, you are very welcome to submit > your opinions and comments regarding the security issue in NEMO. > >> In order for us to work together more effectively as a team and to >> consolidate different efforts, I proposed to TJ that maybe we >> should have a special meeting this week in Seoul to discuss about >> security issue. This special discussion will be open to any one who >> is interested in the security issue under NEMO. Hello Felix, I'm interested in the security discussion of the NEMO base protocol now, and maybe later in other security aspects related to NEMO. I've tried to summarize most important aspects of the security threats for NEMO base protocol, as we understand them, in draft-petrescu-nemo-threats-01.txt. The document benefitted from one NEMO WG member review. While we're not sure at this time whether we can attend the meeting you're proposing (I personally can not) I'm interested in participating in the eventual online discussion. If the meeting produces some informal minutes, I'm interested to see them, thank you. > you are very welcome to submit your opinions and comments regarding > the security issue in NEMO. Where would one start? I think the only two issues are: (1) location privacy and (2) threats induced by the insecure NEMO dynamic HA discovery. Alex From exim@www1.ietf.org Mon Mar 1 04:56:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06063 for ; Mon, 1 Mar 2004 04:56:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axk9G-0007lw-3U for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 04:55:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i219tgpI029875 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 04:55:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axk9F-0007lm-Gi for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 04:55:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06057 for ; Mon, 1 Mar 2004 04:55:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axk9C-0006XQ-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 04:55:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axk8I-0006S1-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 04:54:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axk7e-0006ML-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 04:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axk7d-0007c0-8r; Mon, 01 Mar 2004 04:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axk7K-0007bH-Ag for nemo@optimus.ietf.org; Mon, 01 Mar 2004 04:53:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05969 for ; Mon, 1 Mar 2004 04:53:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axk7H-0006LG-00 for nemo@ietf.org; Mon, 01 Mar 2004 04:53:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axk6Q-0006GE-00 for nemo@ietf.org; Mon, 01 Mar 2004 04:52:46 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1Axk5s-0006A8-00 for nemo@ietf.org; Mon, 01 Mar 2004 04:52:12 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i219po5h007059; Mon, 1 Mar 2004 02:52:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i219phjT027990; Mon, 1 Mar 2004 03:51:44 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6A6A685272E; Mon, 1 Mar 2004 10:51:43 +0100 (CET) Message-ID: <404307AE.60701@motorola.com> Date: Mon, 01 Mar 2004 10:51:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "S. Felix Wu" Cc: IETF NEMO WG , Hong-Yon Lach Subject: Re: [nemo] a special discussion session for threat analysis and security requirements References: <4042B535.5010003@cs.ucdavis.edu> <4042C703.5090901@cs.ucdavis.edu> In-Reply-To: <4042C703.5090901@cs.ucdavis.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit S. Felix Wu wrote: > > I forgot to mention in my earlier message -- if you can not attend > the meeting or the discussion meeting, you are very welcome to submit > your opinions and comments regarding the security issue in NEMO. > >> In order for us to work together more effectively as a team and to >> consolidate different efforts, I proposed to TJ that maybe we >> should have a special meeting this week in Seoul to discuss about >> security issue. This special discussion will be open to any one who >> is interested in the security issue under NEMO. Hello Felix, I'm interested in the security discussion of the NEMO base protocol now, and maybe later in other security aspects related to NEMO. I've tried to summarize most important aspects of the security threats for NEMO base protocol, as we understand them, in draft-petrescu-nemo-threats-01.txt. The document benefitted from one NEMO WG member review. While we're not sure at this time whether we can attend the meeting you're proposing (I personally can not) I'm interested in participating in the eventual online discussion. If the meeting produces some informal minutes, I'm interested to see them, thank you. > you are very welcome to submit your opinions and comments regarding > the security issue in NEMO. Where would one start? I think the only two issues are: (1) location privacy and (2) threats induced by the insecure NEMO dynamic HA discovery. Alex From nemo-admin@ietf.org Mon Mar 1 05:59:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09713 for ; Mon, 1 Mar 2004 05:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl8X-0005pr-Ag; Mon, 01 Mar 2004 05:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl8P-0005ok-Dr for nemo@optimus.ietf.org; Mon, 01 Mar 2004 05:58:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09688 for ; Mon, 1 Mar 2004 05:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axl8L-0005gP-00 for nemo@ietf.org; Mon, 01 Mar 2004 05:58:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axl7b-0005ZR-00 for nemo@ietf.org; Mon, 01 Mar 2004 05:58:04 -0500 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1Axl6g-0005RC-00 for nemo@ietf.org; Mon, 01 Mar 2004 05:57:06 -0500 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i21Aolq6031707; Mon, 1 Mar 2004 19:50:47 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i21AolBf031706; Mon, 1 Mar 2004 19:50:47 +0900 Date: Mon, 1 Mar 2004 19:50:47 +0900 From: Seongho Cho To: Alexandru Petrescu Cc: "S. Felix Wu" , IETF NEMO WG , Hong-Yon Lach Subject: Re: [nemo] a special discussion session for threat analysis and security requirements Message-ID: <20040301195047.A31674@popeye.snu.ac.kr> References: <4042B535.5010003@cs.ucdavis.edu> <4042C703.5090901@cs.ucdavis.edu> <404307AE.60701@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <404307AE.60701@motorola.com>; from Alexandru.Petrescu@motorola.com on Mon, Mar 01, 2004 at 10:51:42AM +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Alex, Also, there are some NEMO Basic support threat issues in new draft, draft-jung-nemo-threat-analysis-02.txt. 1) Threats to the MRHA tunnel 2) BU spoofing 3) DoS for BU processing 4) multihoming threats in case of MR failure (also, in my draft) IMO, 1) and 2) are not possible if the SA is checked by the HA when it receives BU requests. (especially, with IPSec AH) We can discuss on these topics including location privacy (NEMO or MIP specific?) and R bits spoofing of HA discovery messages, which are considered in Alex's draft. So, 6 or more issues can be treated in this off-line meeting. Bests, Seongho > > you are very welcome to submit your opinions and comments regarding > > the security issue in NEMO. > > Where would one start? I think the only two issues are: (1) location > privacy and (2) threats induced by the insecure NEMO dynamic HA discovery. > > Alex -- ------------------------------------------------------------------------ Cho, Seongho (Ph.D. candidate) Information Networking & Computing Laboratory, School of Computer Science and Engineering, Seoul National University San 56-1, Shillim dong, Gwanak gu, Seoul, Korea, 151-744. TEL: +82-2-884-3936 FAX: +82-2-871-4912 http://popeye.snu.ac.kr/~shcho ; mailto:shcho@popeye.snu.ac.kr ------------------------------------------------------------------------ From exim@www1.ietf.org Mon Mar 1 06:01:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09799 for ; Mon, 1 Mar 2004 06:01:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlAA-0005yR-2P for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 06:00:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21B0g2A022957 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 06:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlA9-0005yC-R8 for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 06:00:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09791 for ; Mon, 1 Mar 2004 06:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlA6-0005rf-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 06:00:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axl9F-0005n3-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 05:59:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axl8U-0005hX-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 05:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl8X-0005pr-Ag; Mon, 01 Mar 2004 05:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl8P-0005ok-Dr for nemo@optimus.ietf.org; Mon, 01 Mar 2004 05:58:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09688 for ; Mon, 1 Mar 2004 05:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axl8L-0005gP-00 for nemo@ietf.org; Mon, 01 Mar 2004 05:58:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axl7b-0005ZR-00 for nemo@ietf.org; Mon, 01 Mar 2004 05:58:04 -0500 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1Axl6g-0005RC-00 for nemo@ietf.org; Mon, 01 Mar 2004 05:57:06 -0500 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i21Aolq6031707; Mon, 1 Mar 2004 19:50:47 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i21AolBf031706; Mon, 1 Mar 2004 19:50:47 +0900 Date: Mon, 1 Mar 2004 19:50:47 +0900 From: Seongho Cho To: Alexandru Petrescu Cc: "S. Felix Wu" , IETF NEMO WG , Hong-Yon Lach Subject: Re: [nemo] a special discussion session for threat analysis and security requirements Message-ID: <20040301195047.A31674@popeye.snu.ac.kr> References: <4042B535.5010003@cs.ucdavis.edu> <4042C703.5090901@cs.ucdavis.edu> <404307AE.60701@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <404307AE.60701@motorola.com>; from Alexandru.Petrescu@motorola.com on Mon, Mar 01, 2004 at 10:51:42AM +0100 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Alex, Also, there are some NEMO Basic support threat issues in new draft, draft-jung-nemo-threat-analysis-02.txt. 1) Threats to the MRHA tunnel 2) BU spoofing 3) DoS for BU processing 4) multihoming threats in case of MR failure (also, in my draft) IMO, 1) and 2) are not possible if the SA is checked by the HA when it receives BU requests. (especially, with IPSec AH) We can discuss on these topics including location privacy (NEMO or MIP specific?) and R bits spoofing of HA discovery messages, which are considered in Alex's draft. So, 6 or more issues can be treated in this off-line meeting. Bests, Seongho > > you are very welcome to submit your opinions and comments regarding > > the security issue in NEMO. > > Where would one start? I think the only two issues are: (1) location > privacy and (2) threats induced by the insecure NEMO dynamic HA discovery. > > Alex -- ------------------------------------------------------------------------ Cho, Seongho (Ph.D. candidate) Information Networking & Computing Laboratory, School of Computer Science and Engineering, Seoul National University San 56-1, Shillim dong, Gwanak gu, Seoul, Korea, 151-744. TEL: +82-2-884-3936 FAX: +82-2-871-4912 http://popeye.snu.ac.kr/~shcho ; mailto:shcho@popeye.snu.ac.kr ------------------------------------------------------------------------ From nemo-admin@ietf.org Mon Mar 1 06:03:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09890 for ; Mon, 1 Mar 2004 06:03:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlCP-00067n-32; Mon, 01 Mar 2004 06:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlC2-00066F-J8 for nemo@optimus.ietf.org; Mon, 01 Mar 2004 06:02:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09878 for ; Mon, 1 Mar 2004 06:02:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlBy-00062r-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:02:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxlB5-0005xm-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:01:39 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AxlAH-0005ss-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:00:49 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i21B0o27001449; Mon, 1 Mar 2004 04:00:50 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i21AvXnx002664; Mon, 1 Mar 2004 04:57:34 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8C40285272D; Mon, 1 Mar 2004 12:00:46 +0100 (CET) Message-ID: <404317DE.408@motorola.com> Date: Mon, 01 Mar 2004 12:00:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <403B4083.5080501@ericsson.com> <20040226180557.37e4571d.ernst@sfc.wide.ad.jp> In-Reply-To: <20040226180557.37e4571d.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > I would appreciate if you could read through the multihoming section > in draft-ietf-nemo-terminology and comment on the definition. Side note on this. Matthias uses MH to stand for Multi-Homing, I use it to stand for Mobile Host and others use it to stand for Mobility Header. A MHMH sends multiple MH's (a Multi-Homed Mobile Host sends multiple Mobility Headers)... Alex From exim@www1.ietf.org Mon Mar 1 06:05:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09995 for ; Mon, 1 Mar 2004 06:05:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlE1-0006VD-F3 for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 06:04:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21B4fuE024989 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 06:04:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlE1-0006Uy-9P for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 06:04:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09981 for ; Mon, 1 Mar 2004 06:04:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlDx-0006G6-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 06:04:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxlD7-0006B2-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 06:03:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxlCN-00065J-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 06:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlCP-00067n-32; Mon, 01 Mar 2004 06:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlC2-00066F-J8 for nemo@optimus.ietf.org; Mon, 01 Mar 2004 06:02:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09878 for ; Mon, 1 Mar 2004 06:02:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlBy-00062r-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:02:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxlB5-0005xm-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:01:39 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AxlAH-0005ss-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:00:49 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i21B0o27001449; Mon, 1 Mar 2004 04:00:50 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i21AvXnx002664; Mon, 1 Mar 2004 04:57:34 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8C40285272D; Mon, 1 Mar 2004 12:00:46 +0100 (CET) Message-ID: <404317DE.408@motorola.com> Date: Mon, 01 Mar 2004 12:00:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <403B4083.5080501@ericsson.com> <20040226180557.37e4571d.ernst@sfc.wide.ad.jp> In-Reply-To: <20040226180557.37e4571d.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > I would appreciate if you could read through the multihoming section > in draft-ietf-nemo-terminology and comment on the definition. Side note on this. Matthias uses MH to stand for Multi-Homing, I use it to stand for Mobile Host and others use it to stand for Mobility Header. A MHMH sends multiple MH's (a Multi-Homed Mobile Host sends multiple Mobility Headers)... Alex From nemo-admin@ietf.org Mon Mar 1 06:52:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12608 for ; Mon, 1 Mar 2004 06:52:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axlxp-00029n-41; Mon, 01 Mar 2004 06:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlxW-00028m-Mo for nemo@optimus.ietf.org; Mon, 01 Mar 2004 06:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12597 for ; Mon, 1 Mar 2004 06:51:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlxS-0003gk-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:51:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axlwb-0003bd-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:50:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AxlwA-0003Ve-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:50:18 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 03:50:20 -0800 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i21Bn00o003255; Mon, 1 Mar 2004 12:49:09 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Mar 2004 11:47:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Mar 2004 11:47:55 -0000 Message-ID: Thread-Topic: FW: checking the Nemo tunnel Thread-Index: AcP9lXzzCyNOI7/bRf2zd5PFFlw7ogB6tLew From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: , "Alexandru Petrescu" , X-OriginalArrivalTime: 01 Mar 2004 11:47:57.0331 (UTC) FILETIME=[0A315630:01C3FF83] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: FW: checking the Nemo tunnel Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > the current text says >=20 > The source address > of the inner IPv6 header MUST be a topologically correct address with > respect to the IPv6 prefixes used in the mobile network. >=20 > this text covers all three (a), (b) and (c) from the text you > are proposing below. it does not exclude any of them. >=20 Vijay: the whole paragraph text is not crisp enough to my taste, but I do agree that it's not wrong either. I think it should say that the HA enforces that MUST you are quoting, at the expense of a reverse route lookup. Also, this is a way for the HA to find the BCE and identify which MRHA tunnel the packet is coming from.=20 Pascal From exim@www1.ietf.org Mon Mar 1 06:54:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12684 for ; Mon, 1 Mar 2004 06:54:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlzV-0002I3-Ux for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 06:53:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21BrjPw008799 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 06:53:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlzV-0002Hq-Gs for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 06:53:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12676 for ; Mon, 1 Mar 2004 06:53:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlzR-0003sF-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 06:53:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxlyU-0003nK-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 06:52:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axlxo-0003i1-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 06:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axlxp-00029n-41; Mon, 01 Mar 2004 06:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlxW-00028m-Mo for nemo@optimus.ietf.org; Mon, 01 Mar 2004 06:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12597 for ; Mon, 1 Mar 2004 06:51:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlxS-0003gk-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:51:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axlwb-0003bd-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:50:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AxlwA-0003Ve-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:50:18 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 03:50:20 -0800 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i21Bn00o003255; Mon, 1 Mar 2004 12:49:09 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Mar 2004 11:47:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Mar 2004 11:47:55 -0000 Message-ID: Thread-Topic: FW: checking the Nemo tunnel Thread-Index: AcP9lXzzCyNOI7/bRf2zd5PFFlw7ogB6tLew From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: , "Alexandru Petrescu" , X-OriginalArrivalTime: 01 Mar 2004 11:47:57.0331 (UTC) FILETIME=[0A315630:01C3FF83] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: FW: checking the Nemo tunnel Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > the current text says >=20 > The source address > of the inner IPv6 header MUST be a topologically correct address with > respect to the IPv6 prefixes used in the mobile network. >=20 > this text covers all three (a), (b) and (c) from the text you > are proposing below. it does not exclude any of them. >=20 Vijay: the whole paragraph text is not crisp enough to my taste, but I do agree that it's not wrong either. I think it should say that the HA enforces that MUST you are quoting, at the expense of a reverse route lookup. Also, this is a way for the HA to find the BCE and identify which MRHA tunnel the packet is coming from.=20 Pascal From nemo-admin@ietf.org Mon Mar 1 07:00:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12858 for ; Mon, 1 Mar 2004 07:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm5c-0002SM-3C; Mon, 01 Mar 2004 07:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm5F-0002RJ-AA for nemo@optimus.ietf.org; Mon, 01 Mar 2004 06:59:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12816 for ; Mon, 1 Mar 2004 06:59:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axm5B-0004Lo-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:59:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axm4I-0004HV-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:58:42 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1Axm3S-0004Ci-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:57:50 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i21BvoFU018194; Mon, 1 Mar 2004 04:57:51 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i21BsYtu012129; Mon, 1 Mar 2004 05:54:35 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7FC8385272D; Mon, 1 Mar 2004 12:57:47 +0100 (CET) Message-ID: <4043253B.3060105@motorola.com> Date: Mon, 01 Mar 2004 12:57:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] MNP in the explicit BU when returning home? References: <3FF15879.4010404@motorola.com> <403FE662.70708@iprg.nokia.com> In-Reply-To: <403FE662.70708@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> The existing section 5.8 Returning Home of basic support 02 is silent >> about this. Or maybe it is understood that when MR comes back home >> _all_ MNP's must be deregistered? If yes, this is IMHO a feature of >> implicit mode, and for the explicit mode it should be stated. > > > if the BU is a de-registration BU, the HA is not going to > process any Mobile Network Prefix options in the BU. once > it sees the lifetime set to 0, it just removes the binding > cache entry for the MN and all the associated MNP routes > for a particular MR. > > so there is no need for the MR to include MNPs in the BU > in the explicit mode. the HA is going to ignore them > anyway. I was wondering whether _any_ Mobility Options sub-header should be present in the de-registering BU (for my threat analysis doc and stack), maybe I can find it in the MIP6 draft, but if you know by heart, please let me know. Alex From exim@www1.ietf.org Mon Mar 1 07:02:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12944 for ; Mon, 1 Mar 2004 07:02:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm7H-00030K-00 for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 07:01:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21C1kMT011542 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 07:01:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm7G-000303-MW for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 07:01:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12924 for ; Mon, 1 Mar 2004 07:01:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axm7C-0004XJ-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 07:01:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axm6C-0004R1-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 07:00:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axm5a-0004MY-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 07:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm5c-0002SM-3C; Mon, 01 Mar 2004 07:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axm5F-0002RJ-AA for nemo@optimus.ietf.org; Mon, 01 Mar 2004 06:59:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12816 for ; Mon, 1 Mar 2004 06:59:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axm5B-0004Lo-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:59:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axm4I-0004HV-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:58:42 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1Axm3S-0004Ci-00 for nemo@ietf.org; Mon, 01 Mar 2004 06:57:50 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i21BvoFU018194; Mon, 1 Mar 2004 04:57:51 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i21BsYtu012129; Mon, 1 Mar 2004 05:54:35 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7FC8385272D; Mon, 1 Mar 2004 12:57:47 +0100 (CET) Message-ID: <4043253B.3060105@motorola.com> Date: Mon, 01 Mar 2004 12:57:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] MNP in the explicit BU when returning home? References: <3FF15879.4010404@motorola.com> <403FE662.70708@iprg.nokia.com> In-Reply-To: <403FE662.70708@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> The existing section 5.8 Returning Home of basic support 02 is silent >> about this. Or maybe it is understood that when MR comes back home >> _all_ MNP's must be deregistered? If yes, this is IMHO a feature of >> implicit mode, and for the explicit mode it should be stated. > > > if the BU is a de-registration BU, the HA is not going to > process any Mobile Network Prefix options in the BU. once > it sees the lifetime set to 0, it just removes the binding > cache entry for the MN and all the associated MNP routes > for a particular MR. > > so there is no need for the MR to include MNPs in the BU > in the explicit mode. the HA is going to ignore them > anyway. I was wondering whether _any_ Mobility Options sub-header should be present in the de-registering BU (for my threat analysis doc and stack), maybe I can find it in the MIP6 draft, but if you know by heart, please let me know. Alex From mailman-admin@ietf.org Mon Mar 1 09:12:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20713 for ; Mon, 1 Mar 2004 09:12:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axo9H-0002ki-8b for nemo-archive@lists.ietf.org; Mon, 01 Mar 2004 09:11:59 -0500 Date: Mon, 01 Mar 2004 09:11:59 -0500 Message-ID: <20040301141159.27462.71691.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From exim@www1.ietf.org Mon Mar 1 09:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22760 for ; Mon, 1 Mar 2004 09:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoK0-0005nw-5k for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 09:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21EN4rn022306 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 09:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoK0-0005nh-0G for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 09:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22580 for ; Mon, 1 Mar 2004 09:23:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxoJx-0000Bg-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 09:23:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axo74-0004i2-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 09:09:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axo20-0003L0-02 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 09:04:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axo0S-0007PR-IC for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 09:02:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axo0Q-0001ta-UW for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 09:02:50 -0500 Date: Mon, 01 Mar 2004 09:02:50 -0500 Message-ID: <20040301140250.27462.50470.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-web-archive@ietf.org: List Password // URL ---- -------- nemo@ietf.org dawauv https://www1.ietf.org/mailman/options/nemo/nemo-web-archive%40ietf.org From nemo-admin@ietf.org Mon Mar 1 13:09:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25787 for ; Mon, 1 Mar 2004 13:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrqf-0006b4-E7; Mon, 01 Mar 2004 13:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrpk-0006Tw-JO for nemo@optimus.ietf.org; Mon, 01 Mar 2004 13:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25609 for ; Mon, 1 Mar 2004 13:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrpi-0003qi-00 for nemo@ietf.org; Mon, 01 Mar 2004 13:08:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axrok-0003h1-00 for nemo@ietf.org; Mon, 01 Mar 2004 13:07:03 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Axrnz-0003Qn-00 for nemo@ietf.org; Mon, 01 Mar 2004 13:06:16 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i21I5R826616; Mon, 1 Mar 2004 10:05:27 -0800 X-mProtect: <200403011805> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdslPxWu; Mon, 01 Mar 2004 10:05:23 PST Message-ID: <40437E4D.2070902@iprg.nokia.com> Date: Mon, 01 Mar 2004 10:17:49 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org Subject: Re: [nemo] MNP in the explicit BU when returning home? References: <3FF15879.4010404@motorola.com> <403FE662.70708@iprg.nokia.com> <4043253B.3060105@motorola.com> In-Reply-To: <4043253B.3060105@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > >>> The existing section 5.8 Returning Home of basic support 02 is silent >>> about this. Or maybe it is understood that when MR comes back home >>> _all_ MNP's must be deregistered? If yes, this is IMHO a feature of >>> implicit mode, and for the explicit mode it should be stated. >> >> >> >> if the BU is a de-registration BU, the HA is not going to >> process any Mobile Network Prefix options in the BU. once >> it sees the lifetime set to 0, it just removes the binding >> cache entry for the MN and all the associated MNP routes >> for a particular MR. >> >> so there is no need for the MR to include MNPs in the BU >> in the explicit mode. the HA is going to ignore them >> anyway. > > > I was wondering whether _any_ Mobility Options sub-header should be > present in the de-registering BU (for my threat analysis doc and stack), > maybe I can find it in the MIP6 draft, but if you know by heart, please > let me know. in a Binding Update sent to a HA, only altCoA option is valid. the HA could ignore the altCoA option if it sees a zero lifetime in the BU. Vijay From exim@www1.ietf.org Mon Mar 1 13:11:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25925 for ; Mon, 1 Mar 2004 13:11:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrsf-0006iw-Vx for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 13:11:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21IB5RU025840 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 13:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrsf-0006ih-RJ for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 13:11:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25863 for ; Mon, 1 Mar 2004 13:11:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrse-0004Ia-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 13:11:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axrre-00049V-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 13:10:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axrqg-00040v-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 13:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrqf-0006b4-E7; Mon, 01 Mar 2004 13:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrpk-0006Tw-JO for nemo@optimus.ietf.org; Mon, 01 Mar 2004 13:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25609 for ; Mon, 1 Mar 2004 13:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrpi-0003qi-00 for nemo@ietf.org; Mon, 01 Mar 2004 13:08:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axrok-0003h1-00 for nemo@ietf.org; Mon, 01 Mar 2004 13:07:03 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Axrnz-0003Qn-00 for nemo@ietf.org; Mon, 01 Mar 2004 13:06:16 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i21I5R826616; Mon, 1 Mar 2004 10:05:27 -0800 X-mProtect: <200403011805> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdslPxWu; Mon, 01 Mar 2004 10:05:23 PST Message-ID: <40437E4D.2070902@iprg.nokia.com> Date: Mon, 01 Mar 2004 10:17:49 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org Subject: Re: [nemo] MNP in the explicit BU when returning home? References: <3FF15879.4010404@motorola.com> <403FE662.70708@iprg.nokia.com> <4043253B.3060105@motorola.com> In-Reply-To: <4043253B.3060105@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > >>> The existing section 5.8 Returning Home of basic support 02 is silent >>> about this. Or maybe it is understood that when MR comes back home >>> _all_ MNP's must be deregistered? If yes, this is IMHO a feature of >>> implicit mode, and for the explicit mode it should be stated. >> >> >> >> if the BU is a de-registration BU, the HA is not going to >> process any Mobile Network Prefix options in the BU. once >> it sees the lifetime set to 0, it just removes the binding >> cache entry for the MN and all the associated MNP routes >> for a particular MR. >> >> so there is no need for the MR to include MNPs in the BU >> in the explicit mode. the HA is going to ignore them >> anyway. > > > I was wondering whether _any_ Mobility Options sub-header should be > present in the de-registering BU (for my threat analysis doc and stack), > maybe I can find it in the MIP6 draft, but if you know by heart, please > let me know. in a Binding Update sent to a HA, only altCoA option is valid. the HA could ignore the altCoA option if it sees a zero lifetime in the BU. Vijay From nemo-admin@ietf.org Mon Mar 1 21:22:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23533 for ; Mon, 1 Mar 2004 21:22:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzXl-0006Pq-MR; Mon, 01 Mar 2004 21:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzWz-0006NS-Lp for nemo@optimus.ietf.org; Mon, 01 Mar 2004 21:21:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23455 for ; Mon, 1 Mar 2004 21:21:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzWx-0006pc-00 for nemo@ietf.org; Mon, 01 Mar 2004 21:21:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzVq-0006h3-00 for nemo@ietf.org; Mon, 01 Mar 2004 21:20:03 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxzUr-0006Gg-00 for nemo@ietf.org; Mon, 01 Mar 2004 21:19:01 -0500 Received: from [218.37.224.72] (wideload.wireless.ietf59.or.kr [218.37.224.72]) by multihop.net (8.12.10/8.12.10) with ESMTP id i222Jqr4018098 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 1 Mar 2004 18:19:54 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v612) To: IETF NEMO WG Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--1045119276; protocol="application/pkcs7-signature" From: "T.J. Kniveton" Date: Tue, 2 Mar 2004 11:16:52 +0900 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] Presentations online Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --Apple-Mail-1--1045119276 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit The NEMO web site is now populated with all of the presentations. Presenters: Please make sure your slides are present, *AND* that they are the most current version. If not, e-mail me your latest slides. .ppt = Powerpoint .pdf = Portable Document Format .key.tgz = Keynote (Mac only, tar/gzipped) Shortcut to all slide files (tar/gzipped): http://www.mobilenetworks.org/nemo/ietf59/slides/nemo-ietf59-all- slides.tgz --Apple-Mail-1--1045119276 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMwMjAyMTY1 MlowIwYJKoZIhvcNAQkEMRYEFFpVbByM6QOBCX2yCxIUx8dgjmosMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgJtNvwNkoJjL2IH8ns2ciAFbDzGDQc3dwmF5nBQU55ly XDMikXX7WlYuUp1hIp+LQzh3monwMifHyffCrnfqqDfJTzKy0OFnp87qwG1PEVe4Dk43TfPmRv/d jQN9FeiT9ZO91m8wrCD8QIdFSBFwNkqJSHKrJ5J+aUvapB2gbUJBAAAAAAAA --Apple-Mail-1--1045119276-- From exim@www1.ietf.org Mon Mar 1 21:24:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23711 for ; Mon, 1 Mar 2004 21:24:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzZm-0006qw-TZ for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 21:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i222O6lK026336 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 21:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzZm-0006qh-Od for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 21:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23630 for ; Mon, 1 Mar 2004 21:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzZk-0007JN-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 21:24:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzYl-00078P-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 21:23:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxzXl-0006uW-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 21:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzXl-0006Pq-MR; Mon, 01 Mar 2004 21:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzWz-0006NS-Lp for nemo@optimus.ietf.org; Mon, 01 Mar 2004 21:21:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23455 for ; Mon, 1 Mar 2004 21:21:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzWx-0006pc-00 for nemo@ietf.org; Mon, 01 Mar 2004 21:21:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzVq-0006h3-00 for nemo@ietf.org; Mon, 01 Mar 2004 21:20:03 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxzUr-0006Gg-00 for nemo@ietf.org; Mon, 01 Mar 2004 21:19:01 -0500 Received: from [218.37.224.72] (wideload.wireless.ietf59.or.kr [218.37.224.72]) by multihop.net (8.12.10/8.12.10) with ESMTP id i222Jqr4018098 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 1 Mar 2004 18:19:54 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v612) To: IETF NEMO WG Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--1045119276; protocol="application/pkcs7-signature" From: "T.J. Kniveton" Date: Tue, 2 Mar 2004 11:16:52 +0900 X-Mailer: Apple Mail (2.612) Subject: [nemo] Presentations online Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-1--1045119276 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit The NEMO web site is now populated with all of the presentations. Presenters: Please make sure your slides are present, *AND* that they are the most current version. If not, e-mail me your latest slides. .ppt = Powerpoint .pdf = Portable Document Format .key.tgz = Keynote (Mac only, tar/gzipped) Shortcut to all slide files (tar/gzipped): http://www.mobilenetworks.org/nemo/ietf59/slides/nemo-ietf59-all- slides.tgz --Apple-Mail-1--1045119276 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMwMjAyMTY1 MlowIwYJKoZIhvcNAQkEMRYEFFpVbByM6QOBCX2yCxIUx8dgjmosMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgJtNvwNkoJjL2IH8ns2ciAFbDzGDQc3dwmF5nBQU55ly XDMikXX7WlYuUp1hIp+LQzh3monwMifHyffCrnfqqDfJTzKy0OFnp87qwG1PEVe4Dk43TfPmRv/d jQN9FeiT9ZO91m8wrCD8QIdFSBFwNkqJSHKrJ5J+aUvapB2gbUJBAAAAAAAA --Apple-Mail-1--1045119276-- From nemo-admin@ietf.org Mon Mar 1 23:44:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00385 for ; Mon, 1 Mar 2004 23:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1lB-0002V7-AW; Mon, 01 Mar 2004 23:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1kW-0002Sb-6R for nemo@optimus.ietf.org; Mon, 01 Mar 2004 23:43:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00338 for ; Mon, 1 Mar 2004 23:43:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1kU-0000pa-00 for nemo@ietf.org; Mon, 01 Mar 2004 23:43:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1jd-0000j3-00 for nemo@ietf.org; Mon, 01 Mar 2004 23:42:25 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1j7-0000bG-00 for nemo@ietf.org; Mon, 01 Mar 2004 23:41:53 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i224fQha002644; Mon, 1 Mar 2004 20:41:28 -0800 (PST) Message-ID: <40441083.6020908@cs.ucdavis.edu> Date: Mon, 01 Mar 2004 20:41:39 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG CC: "S. Felix Wu" Subject: Re: [nemo] a special discussion session for threat analysis and security requirements References: <4042B535.5010003@cs.ucdavis.edu> In-Reply-To: <4042B535.5010003@cs.ucdavis.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have received a few responses for the special meeting. It looks to me that more folks will be available on Thursday (than Wednesday). (I am sorry for those who told me that they prefer Wednesday.) So, here it is: Special NEMO security/threat analysis meeting time: 11-12 on Thursday place: Let's meet outside of the Emerald room BTW, I found one document related to threat analysis for multi- homing: http://www.ietf.org/internet-drafts/draft-ohta-multi6-threats-00.txt -Felix S. Felix Wu wrote: > Hi, > > It seems to me that we have many folks are interested in working on > security/threat related issues under NEMO, while, as TJ concluded > today, we still need a good external review for security issues. > > In order for us to work together more effectively as a team and > to consolidate different efforts, I proposed to TJ that maybe we > should have a special meeting this week in Seoul to discuss about > security issue. This special discussion will be open to any one > who is interested in the security issue under NEMO. > > I propose two options for the meeting time: > (1). 11-12 on Wed morning > (2). 11-12 on Thu morning > > For those of you who are indeed interested in joining us, please > let me know in emails whether any one of the propsed time is good > for you. And, then, after I collect all the inputs, I will announce > tomorrow around 4:00 p.m. to the NEMO mailing list. > > Draft Agenda: > (1). Introduce ourselves > (2). status of all current drafts > (3). what should we really achieve regarding the security issue > in NEMO? > (4). "how to achieve that goal" and hopefully some action items > before the next IETF. > > Thanks. Any comments will be welcome. > -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 23:45:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00532 for ; Mon, 1 Mar 2004 23:45:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1mT-0002dX-0g for nemo-archive@odin.ietf.org; Mon, 01 Mar 2004 23:45:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i224jKBH010131 for nemo-archive@odin.ietf.org; Mon, 1 Mar 2004 23:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1mS-0002dK-Sr for nemo-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 23:45:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00506 for ; Mon, 1 Mar 2004 23:45:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1mQ-00014u-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 23:45:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1la-0000yd-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 23:44:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1lA-0000rC-00 for nemo-web-archive@ietf.org; Mon, 01 Mar 2004 23:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1lB-0002V7-AW; Mon, 01 Mar 2004 23:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1kW-0002Sb-6R for nemo@optimus.ietf.org; Mon, 01 Mar 2004 23:43:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00338 for ; Mon, 1 Mar 2004 23:43:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1kU-0000pa-00 for nemo@ietf.org; Mon, 01 Mar 2004 23:43:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1jd-0000j3-00 for nemo@ietf.org; Mon, 01 Mar 2004 23:42:25 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1j7-0000bG-00 for nemo@ietf.org; Mon, 01 Mar 2004 23:41:53 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i224fQha002644; Mon, 1 Mar 2004 20:41:28 -0800 (PST) Message-ID: <40441083.6020908@cs.ucdavis.edu> Date: Mon, 01 Mar 2004 20:41:39 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG CC: "S. Felix Wu" Subject: Re: [nemo] a special discussion session for threat analysis and security requirements References: <4042B535.5010003@cs.ucdavis.edu> In-Reply-To: <4042B535.5010003@cs.ucdavis.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have received a few responses for the special meeting. It looks to me that more folks will be available on Thursday (than Wednesday). (I am sorry for those who told me that they prefer Wednesday.) So, here it is: Special NEMO security/threat analysis meeting time: 11-12 on Thursday place: Let's meet outside of the Emerald room BTW, I found one document related to threat analysis for multi- homing: http://www.ietf.org/internet-drafts/draft-ohta-multi6-threats-00.txt -Felix S. Felix Wu wrote: > Hi, > > It seems to me that we have many folks are interested in working on > security/threat related issues under NEMO, while, as TJ concluded > today, we still need a good external review for security issues. > > In order for us to work together more effectively as a team and > to consolidate different efforts, I proposed to TJ that maybe we > should have a special meeting this week in Seoul to discuss about > security issue. This special discussion will be open to any one > who is interested in the security issue under NEMO. > > I propose two options for the meeting time: > (1). 11-12 on Wed morning > (2). 11-12 on Thu morning > > For those of you who are indeed interested in joining us, please > let me know in emails whether any one of the propsed time is good > for you. And, then, after I collect all the inputs, I will announce > tomorrow around 4:00 p.m. to the NEMO mailing list. > > Draft Agenda: > (1). Introduce ourselves > (2). status of all current drafts > (3). what should we really achieve regarding the security issue > in NEMO? > (4). "how to achieve that goal" and hopefully some action items > before the next IETF. > > Thanks. Any comments will be welcome. > -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Tue Mar 2 00:58:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04429 for ; Tue, 2 Mar 2004 00:58:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2un-0002og-9J; Tue, 02 Mar 2004 00:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2uF-0002hp-BU for nemo@optimus.ietf.org; Tue, 02 Mar 2004 00:57:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04366 for ; Tue, 2 Mar 2004 00:57:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2uC-0001eS-00 for nemo@ietf.org; Tue, 02 Mar 2004 00:57:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2tL-0001YN-00 for nemo@ietf.org; Tue, 02 Mar 2004 00:56:32 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2su-0001Qb-00 for nemo@ietf.org; Tue, 02 Mar 2004 00:56:04 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 88BAA10AC6; Tue, 2 Mar 2004 06:55:34 +0100 (CET) Received: from lolo (vpn-252-215.uc3m.es [163.117.252.215]) by smtp01.uc3m.es (Postfix) with SMTP id BE85A10AD4; Tue, 2 Mar 2004 06:55:32 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "S. Felix Wu" , "IETF NEMO WG" Subject: RE: [nemo] a special discussion session for threat analysis and security requirements Date: Tue, 2 Mar 2004 14:53:30 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40441083.6020908@cs.ucdavis.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Felix, > BTW, I found one document related to threat analysis for multi- > homing: > > http://www.ietf.org/internet-drafts/draft-ohta-multi6-threats-00.txt I don't know how usefull you'll find this draft... it is mainly focused in transport layer solutions (as its tittle states ;-) "Threats Relating to Transport Layer Protocols Handling Multiple Addresses" Probably, if you want to have a more broader view of multihoming threats, i would recommend reading Erik Nordmark, Tony Li, "Threats relating to IPv6 multihoming solutions" http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-00.txt Another important reading for this, IMHO, would be P. Nikander et al., "Mobile IP version 6 Route Optimization Security Design Background" http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-02.txt regards, marcelo > > -Felix > > > S. Felix Wu wrote: > > > Hi, > > > > It seems to me that we have many folks are interested in working on > > security/threat related issues under NEMO, while, as TJ concluded > > today, we still need a good external review for security issues. > > > > In order for us to work together more effectively as a team and > > to consolidate different efforts, I proposed to TJ that maybe we > > should have a special meeting this week in Seoul to discuss about > > security issue. This special discussion will be open to any one > > who is interested in the security issue under NEMO. > > > > I propose two options for the meeting time: > > (1). 11-12 on Wed morning > > (2). 11-12 on Thu morning > > > > For those of you who are indeed interested in joining us, please > > let me know in emails whether any one of the propsed time is good > > for you. And, then, after I collect all the inputs, I will announce > > tomorrow around 4:00 p.m. to the NEMO mailing list. > > > > Draft Agenda: > > (1). Introduce ourselves > > (2). status of all current drafts > > (3). what should we really achieve regarding the security issue > > in NEMO? > > (4). "how to achieve that goal" and hopefully some action items > > before the next IETF. > > > > Thanks. Any comments will be welcome. > > -Felix > > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- > > From exim@www1.ietf.org Tue Mar 2 01:00:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04484 for ; Tue, 2 Mar 2004 01:00:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2wN-0003DN-BU for nemo-archive@odin.ietf.org; Tue, 02 Mar 2004 00:59:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225xdQ7012358 for nemo-archive@odin.ietf.org; Tue, 2 Mar 2004 00:59:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2wM-0003DF-IJ for nemo-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 00:59:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04463 for ; Tue, 2 Mar 2004 00:59:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2wJ-0001xr-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 00:59:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2vK-0001p1-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 00:58:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2un-0001gf-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 00:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2un-0002og-9J; Tue, 02 Mar 2004 00:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2uF-0002hp-BU for nemo@optimus.ietf.org; Tue, 02 Mar 2004 00:57:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04366 for ; Tue, 2 Mar 2004 00:57:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2uC-0001eS-00 for nemo@ietf.org; Tue, 02 Mar 2004 00:57:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2tL-0001YN-00 for nemo@ietf.org; Tue, 02 Mar 2004 00:56:32 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2su-0001Qb-00 for nemo@ietf.org; Tue, 02 Mar 2004 00:56:04 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 88BAA10AC6; Tue, 2 Mar 2004 06:55:34 +0100 (CET) Received: from lolo (vpn-252-215.uc3m.es [163.117.252.215]) by smtp01.uc3m.es (Postfix) with SMTP id BE85A10AD4; Tue, 2 Mar 2004 06:55:32 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "S. Felix Wu" , "IETF NEMO WG" Subject: RE: [nemo] a special discussion session for threat analysis and security requirements Date: Tue, 2 Mar 2004 14:53:30 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40441083.6020908@cs.ucdavis.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Felix, > BTW, I found one document related to threat analysis for multi- > homing: > > http://www.ietf.org/internet-drafts/draft-ohta-multi6-threats-00.txt I don't know how usefull you'll find this draft... it is mainly focused in transport layer solutions (as its tittle states ;-) "Threats Relating to Transport Layer Protocols Handling Multiple Addresses" Probably, if you want to have a more broader view of multihoming threats, i would recommend reading Erik Nordmark, Tony Li, "Threats relating to IPv6 multihoming solutions" http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-00.txt Another important reading for this, IMHO, would be P. Nikander et al., "Mobile IP version 6 Route Optimization Security Design Background" http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-02.txt regards, marcelo > > -Felix > > > S. Felix Wu wrote: > > > Hi, > > > > It seems to me that we have many folks are interested in working on > > security/threat related issues under NEMO, while, as TJ concluded > > today, we still need a good external review for security issues. > > > > In order for us to work together more effectively as a team and > > to consolidate different efforts, I proposed to TJ that maybe we > > should have a special meeting this week in Seoul to discuss about > > security issue. This special discussion will be open to any one > > who is interested in the security issue under NEMO. > > > > I propose two options for the meeting time: > > (1). 11-12 on Wed morning > > (2). 11-12 on Thu morning > > > > For those of you who are indeed interested in joining us, please > > let me know in emails whether any one of the propsed time is good > > for you. And, then, after I collect all the inputs, I will announce > > tomorrow around 4:00 p.m. to the NEMO mailing list. > > > > Draft Agenda: > > (1). Introduce ourselves > > (2). status of all current drafts > > (3). what should we really achieve regarding the security issue > > in NEMO? > > (4). "how to achieve that goal" and hopefully some action items > > before the next IETF. > > > > Thanks. Any comments will be welcome. > > -Felix > > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- > > From nemo-admin@ietf.org Tue Mar 2 02:05:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14046 for ; Tue, 2 Mar 2004 02:05:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3xf-0005k8-TT; Tue, 02 Mar 2004 02:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3x8-0005YB-0Z for nemo@optimus.ietf.org; Tue, 02 Mar 2004 02:04:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12686 for ; Tue, 2 Mar 2004 02:04:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3x4-0002EA-00 for nemo@ietf.org; Tue, 02 Mar 2004 02:04:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3wJ-000272-00 for nemo@ietf.org; Tue, 02 Mar 2004 02:03:39 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3vS-0001yp-00 for nemo@ietf.org; Tue, 02 Mar 2004 02:02:46 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i2272BgP012954; Tue, 2 Mar 2004 00:02:12 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2272XQ13397; Tue, 2 Mar 2004 08:02:33 +0100 (MET) Date: Mon, 1 Mar 2004 23:02:37 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] a special discussion session for threat analysis and security requirements To: "S. Felix Wu" Cc: IETF NEMO WG In-Reply-To: "Your message with ID" <40441083.6020908@cs.ucdavis.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > BTW, I found one document related to threat analysis for multi- > homing: > > http://www.ietf.org/internet-drafts/draft-ohta-multi6-threats-00.txt There is also draft-nordmark-multi6-threats-00.txt Erik From exim@www1.ietf.org Tue Mar 2 02:07:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16522 for ; Tue, 2 Mar 2004 02:07:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3zq-0006ow-Me for nemo-archive@odin.ietf.org; Tue, 02 Mar 2004 02:07:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2277I2t026201 for nemo-archive@odin.ietf.org; Tue, 2 Mar 2004 02:07:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3zp-0006oC-RI for nemo-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 02:07:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15853 for ; Tue, 2 Mar 2004 02:07:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3zm-0002ZW-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 02:07:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3ym-0002RE-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 02:06:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3xp-0002Jt-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 02:05:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3xf-0005k8-TT; Tue, 02 Mar 2004 02:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3x8-0005YB-0Z for nemo@optimus.ietf.org; Tue, 02 Mar 2004 02:04:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12686 for ; Tue, 2 Mar 2004 02:04:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3x4-0002EA-00 for nemo@ietf.org; Tue, 02 Mar 2004 02:04:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3wJ-000272-00 for nemo@ietf.org; Tue, 02 Mar 2004 02:03:39 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3vS-0001yp-00 for nemo@ietf.org; Tue, 02 Mar 2004 02:02:46 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i2272BgP012954; Tue, 2 Mar 2004 00:02:12 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2272XQ13397; Tue, 2 Mar 2004 08:02:33 +0100 (MET) Date: Mon, 1 Mar 2004 23:02:37 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] a special discussion session for threat analysis and security requirements To: "S. Felix Wu" Cc: IETF NEMO WG In-Reply-To: "Your message with ID" <40441083.6020908@cs.ucdavis.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > BTW, I found one document related to threat analysis for multi- > homing: > > http://www.ietf.org/internet-drafts/draft-ohta-multi6-threats-00.txt There is also draft-nordmark-multi6-threats-00.txt Erik From nemo-admin@ietf.org Tue Mar 2 03:12:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24960 for ; Tue, 2 Mar 2004 03:12:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay50S-0004yT-6n; Tue, 02 Mar 2004 03:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4zp-0004wE-Rw for nemo@optimus.ietf.org; Tue, 02 Mar 2004 03:11:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24888 for ; Tue, 2 Mar 2004 03:11:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4zl-0003hg-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4yp-0003bH-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:10:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4xu-0003Pa-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:09:22 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2004 00:15:17 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i228812N011645; Tue, 2 Mar 2004 09:08:25 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Mar 2004 08:08:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] can an HA itself be an MNN under NEMO? Date: Tue, 2 Mar 2004 08:08:50 -0000 Message-ID: Thread-Topic: [nemo] can an HA itself be an MNN under NEMO? Thread-Index: AcP+zRm9V39nC/HfQ5iNfUz4M2FAmgBZxMPw From: "Pascal Thubert (pthubert)" To: "T.J. Kniveton" , "S. Felix Wu" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 02 Mar 2004 08:08:51.0244 (UTC) FILETIME=[98ED66C0:01C4002D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: If Felix's case is what the nemo basic usages draft = (http://www.ietf.org/mail-archive/ietf-announce/Current/msg28703.html)ref= ers to as (hierarchical) Mobile Home, then IMHO, yes, it makes a lot of = sense, for the reasons explained in the draft. Actually the bottom MR = advertises X' which is only a subnet of X... =20 To recap (from my presentation at the WG:) * A bitwise hierarchy of Home Networks=20 ->MRs are recursively Home Agent(s) for their NEMO-prefixes * A head HA advertises the global Home to the infrastructure=20 ->Head HA gets packets from the infrastructure=20 ->tunnels them to the MR that is responsible of the next level of = hierarchy * Home is further subnetted in NEMO-prefixes that are Home Networks as = well=20 ->MRs decapsulate the packets as MR and reencapsulate them as HA ->MRs are recursively Home Agent(s) for their NEMO-prefixes Advantages: * Easier Network Management for IT ->Preconfiguration and testing of regional (branch) offices ->Deployment with no reconfiguration ->Easier to move an office every so often * if Mobile Home Agent is root-MR of a mobile cloud of its MRs: ->Nested Route Optimization=20 ->No pinball routing ->Nemo-network to Nemo-network communication confined within mobile = cloud=20 Opinions? Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = T.J. Kniveton > Sent: dimanche 29 f=E9vrier 2004 15:00 > To: S. Felix Wu > Cc: IETF NEMO WG > Subject: Re: [nemo] can an HA itself be an MNN under NEMO? >=20 > I still don't get it.. Why would there be HAs on two different links > supporting the same prefix?? In the fixed case, it's analogous to two > routers on different links, advertising the same global prefix. >=20 > On Feb 29, 2004, at 10:53 PM, S. Felix Wu wrote: >=20 > > > > I was really thinking about the MR for prefix Y moving into > > another network (prefix X) without knowing that one of its own > > MNN is actually the HA for that network. > > > > I agree that, for fixed topology/configuration, this doesn't > > make sense. But, I am not sure about the "moving" case (plus > > nested). > > -Felix > > > > > > T.J. Kniveton wrote: > > > >> I don't get why you would have a Parent HA advertising prefix X, = and > >> then a Mobile HA and MNN inside the top MR's prefix X... doesn't = seem > >> like a topologically correct arrangement of routers. The Mobile HA = is > >> under MR with prefix Y, so why is it advertising prefix X. > >> Think about the fixed case, would you have this arrangement? > >> Router > >> | prefix X > >> | > >> | > >> Router > >> | prefix Y > >> | > >> | > >> Router > >> | prefix X > >> | > >> | > >> Fixed node with prefix X > >> it wouldn't make sense, right? It seems the scenario in the slide = is > >> just taking this case, and nesting it inside MRs. > >> On Feb 29, 2004, at 4:11 PM, S. Felix Wu wrote: > >>> > >>> Hi, > >>> > >>> During our analysis of multi-homing and nested NEMO cases, we > >>> have encountered a question, hopefully get some clarifications > >>> from the NEMO working group: > >>> > >>> -- Can an HA itself be an MNN under the NEMO context? > >>> > >>> Please see our attached PDF file for our preliminary analysis on > >>> this issue. It seems to us that this can be allowed for MIPv6, but > >>> should NOT be allowed for NEMO (otherwise, we might have a loop, > >>> and the multi-homing issue might be more complex). > >>> > >>> -Felix > >>> -- > >>> = --------------------------------------------------------------------- > >>> - > >>> Dr. S. (Shyhtsun) Felix Wu > >>> wu@cs.ucdavis.edu > >>> Associate Professor > >>> http://www.cs.ucdavis.edu/~wu > >>> Computer Science Department office: > >>> 1-530-754-7070 > >>> University of California at Davis fax: > >>> 1-530-752-4767 > >>> = --------------------------------------------------------------------- > >>> - > >>> > > > > -- > > = ---------------------------------------------------------------------- > > Dr. S. (Shyhtsun) Felix Wu = wu@cs.ucdavis.edu > > Associate Professor = http://www.cs.ucdavis.edu/~wu > > Computer Science Department office: = 1-530-754-7070 > > University of California at Davis fax: = 1-530-752-4767 > > = ---------------------------------------------------------------------- > > From exim@www1.ietf.org Tue Mar 2 03:13:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25032 for ; Tue, 2 Mar 2004 03:13:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay51m-0005H2-N0 for nemo-archive@odin.ietf.org; Tue, 02 Mar 2004 03:13:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i228DMKY020268 for nemo-archive@odin.ietf.org; Tue, 2 Mar 2004 03:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay51m-0005Gp-Bn for nemo-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:13:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25018 for ; Tue, 2 Mar 2004 03:13:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay51k-0003yV-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 03:13:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay50w-0003rn-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 03:12:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay50X-0003kt-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 03:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay50S-0004yT-6n; Tue, 02 Mar 2004 03:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4zp-0004wE-Rw for nemo@optimus.ietf.org; Tue, 02 Mar 2004 03:11:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24888 for ; Tue, 2 Mar 2004 03:11:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4zl-0003hg-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4yp-0003bH-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:10:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4xu-0003Pa-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:09:22 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2004 00:15:17 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i228812N011645; Tue, 2 Mar 2004 09:08:25 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Mar 2004 08:08:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] can an HA itself be an MNN under NEMO? Date: Tue, 2 Mar 2004 08:08:50 -0000 Message-ID: Thread-Topic: [nemo] can an HA itself be an MNN under NEMO? Thread-Index: AcP+zRm9V39nC/HfQ5iNfUz4M2FAmgBZxMPw From: "Pascal Thubert (pthubert)" To: "T.J. Kniveton" , "S. Felix Wu" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 02 Mar 2004 08:08:51.0244 (UTC) FILETIME=[98ED66C0:01C4002D] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi: If Felix's case is what the nemo basic usages draft = (http://www.ietf.org/mail-archive/ietf-announce/Current/msg28703.html)ref= ers to as (hierarchical) Mobile Home, then IMHO, yes, it makes a lot of = sense, for the reasons explained in the draft. Actually the bottom MR = advertises X' which is only a subnet of X... =20 To recap (from my presentation at the WG:) * A bitwise hierarchy of Home Networks=20 ->MRs are recursively Home Agent(s) for their NEMO-prefixes * A head HA advertises the global Home to the infrastructure=20 ->Head HA gets packets from the infrastructure=20 ->tunnels them to the MR that is responsible of the next level of = hierarchy * Home is further subnetted in NEMO-prefixes that are Home Networks as = well=20 ->MRs decapsulate the packets as MR and reencapsulate them as HA ->MRs are recursively Home Agent(s) for their NEMO-prefixes Advantages: * Easier Network Management for IT ->Preconfiguration and testing of regional (branch) offices ->Deployment with no reconfiguration ->Easier to move an office every so often * if Mobile Home Agent is root-MR of a mobile cloud of its MRs: ->Nested Route Optimization=20 ->No pinball routing ->Nemo-network to Nemo-network communication confined within mobile = cloud=20 Opinions? Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = T.J. Kniveton > Sent: dimanche 29 f=E9vrier 2004 15:00 > To: S. Felix Wu > Cc: IETF NEMO WG > Subject: Re: [nemo] can an HA itself be an MNN under NEMO? >=20 > I still don't get it.. Why would there be HAs on two different links > supporting the same prefix?? In the fixed case, it's analogous to two > routers on different links, advertising the same global prefix. >=20 > On Feb 29, 2004, at 10:53 PM, S. Felix Wu wrote: >=20 > > > > I was really thinking about the MR for prefix Y moving into > > another network (prefix X) without knowing that one of its own > > MNN is actually the HA for that network. > > > > I agree that, for fixed topology/configuration, this doesn't > > make sense. But, I am not sure about the "moving" case (plus > > nested). > > -Felix > > > > > > T.J. Kniveton wrote: > > > >> I don't get why you would have a Parent HA advertising prefix X, = and > >> then a Mobile HA and MNN inside the top MR's prefix X... doesn't = seem > >> like a topologically correct arrangement of routers. The Mobile HA = is > >> under MR with prefix Y, so why is it advertising prefix X. > >> Think about the fixed case, would you have this arrangement? > >> Router > >> | prefix X > >> | > >> | > >> Router > >> | prefix Y > >> | > >> | > >> Router > >> | prefix X > >> | > >> | > >> Fixed node with prefix X > >> it wouldn't make sense, right? It seems the scenario in the slide = is > >> just taking this case, and nesting it inside MRs. > >> On Feb 29, 2004, at 4:11 PM, S. Felix Wu wrote: > >>> > >>> Hi, > >>> > >>> During our analysis of multi-homing and nested NEMO cases, we > >>> have encountered a question, hopefully get some clarifications > >>> from the NEMO working group: > >>> > >>> -- Can an HA itself be an MNN under the NEMO context? > >>> > >>> Please see our attached PDF file for our preliminary analysis on > >>> this issue. It seems to us that this can be allowed for MIPv6, but > >>> should NOT be allowed for NEMO (otherwise, we might have a loop, > >>> and the multi-homing issue might be more complex). > >>> > >>> -Felix > >>> -- > >>> = --------------------------------------------------------------------- > >>> - > >>> Dr. S. (Shyhtsun) Felix Wu > >>> wu@cs.ucdavis.edu > >>> Associate Professor > >>> http://www.cs.ucdavis.edu/~wu > >>> Computer Science Department office: > >>> 1-530-754-7070 > >>> University of California at Davis fax: > >>> 1-530-752-4767 > >>> = --------------------------------------------------------------------- > >>> - > >>> > > > > -- > > = ---------------------------------------------------------------------- > > Dr. S. (Shyhtsun) Felix Wu = wu@cs.ucdavis.edu > > Associate Professor = http://www.cs.ucdavis.edu/~wu > > Computer Science Department office: = 1-530-754-7070 > > University of California at Davis fax: = 1-530-752-4767 > > = ---------------------------------------------------------------------- > > From nemo-admin@ietf.org Tue Mar 2 03:22:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25784 for ; Tue, 2 Mar 2004 03:22:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5AE-00065K-96; Tue, 02 Mar 2004 03:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay59e-00061Q-6r for nemo@optimus.ietf.org; Tue, 02 Mar 2004 03:21:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25746 for ; Tue, 2 Mar 2004 03:21:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay59b-0005KA-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:21:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay58n-0005CI-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:20:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1Ay587-00050j-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:19:55 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2004 00:25:49 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i228Is1x014529; Tue, 2 Mar 2004 09:18:57 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Mar 2004 08:19:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] can an HA itself be an MNN under NEMO? Date: Tue, 2 Mar 2004 08:19:22 -0000 Message-ID: Thread-Topic: [nemo] can an HA itself be an MNN under NEMO? Thread-Index: AcP+og94zPqH1e96S0Gf0FTMtqf1bgBk7oTA From: "Pascal Thubert (pthubert)" To: "S. Felix Wu" , "IETF NEMO WG" Cc: "Fan Zhao" , "Souhwan Jung" X-OriginalArrivalTime: 02 Mar 2004 08:19:23.0229 (UTC) FILETIME=[119EA8D0:01C4002F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable "Option# 1: - do NOT allow HA as MNN" * Option# 2: - An HA can be an MNN, but it can never be "included" by its own MR. - But, how about those eight cases in Multi- homing? Disagree. With nemo basic there's a limitation on how this can work as = you present and as HY Lach presented last IETF (Mobile Home must be = Root-MRs). Note that one application of Mobile Home is a 'quasi fixed' Home or = branch office gateway. Usage is preconfiguration by IT or ISP, and plug = and play deployment (and moving when office is displaced). Note: With RRH support, any configuration works (even a HA attached to = its own MRs). Reason is MR forward RRH up the tree to the AR even when = not bound (note: DHAAD is issued with a all zeroes RRH and it traverses = too). As a result, the fixed 'super' HA can answer by echoing the RRH, = then mobile Home binds, and then MRs bind via the fixed 'super' HA. Demo = available :) This is not the only advantage of RRH since it's mostly aimed at RO, but = it's pretty neat.=20 Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of S. = Felix Wu > Sent: dimanche 29 f=E9vrier 2004 08:12 > To: IETF NEMO WG > Cc: Fan Zhao; Souhwan Jung; wu@cs.ucdavis.edu > Subject: [nemo] can an HA itself be an MNN under NEMO? >=20 >=20 > Hi, >=20 > During our analysis of multi-homing and nested NEMO cases, we > have encountered a question, hopefully get some clarifications > from the NEMO working group: >=20 > -- Can an HA itself be an MNN under the NEMO context? >=20 > Please see our attached PDF file for our preliminary analysis on > this issue. It seems to us that this can be allowed for MIPv6, but > should NOT be allowed for NEMO (otherwise, we might have a loop, > and the multi-homing issue might be more complex). >=20 > -Felix > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- From nemo-admin@ietf.org Tue Mar 2 19:32:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13205 for ; Tue, 2 Mar 2004 19:32:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKIq-0000Ds-Rs; Tue, 02 Mar 2004 19:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKI2-0008Sa-Hb for nemo@optimus.ietf.org; Tue, 02 Mar 2004 19:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13145 for ; Tue, 2 Mar 2004 19:31:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKI0-0004pH-00 for nemo@ietf.org; Tue, 02 Mar 2004 19:31:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKHA-0004gv-00 for nemo@ietf.org; Tue, 02 Mar 2004 19:30:16 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AyKGW-0004Sg-00 for nemo@ietf.org; Tue, 02 Mar 2004 19:29:36 -0500 Received: from localhost.localdomain (MAC-0-2-2d-b0-f2-f4.wireless.ietf59.or.kr [218.37.227.33]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 0ECEE5D312 for ; Wed, 3 Mar 2004 09:29:05 +0900 (JST) Date: Wed, 3 Mar 2004 09:29:56 +0900 From: Thierry Ernst To: nemo Message-Id: <20040303092956.77f4230b.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Milestones update Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please check out the charter, the milestones have been updated. Thierry. From exim@www1.ietf.org Tue Mar 2 19:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13417 for ; Tue, 2 Mar 2004 19:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKKm-0000Q0-5h for nemo-archive@odin.ietf.org; Tue, 02 Mar 2004 19:34:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230Y0h6001602 for nemo-archive@odin.ietf.org; Tue, 2 Mar 2004 19:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKKl-0000Pa-Lx for nemo-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 19:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13392 for ; Tue, 2 Mar 2004 19:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKKj-0005HG-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 19:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKJr-000589-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 19:33:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyKIs-0004yK-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 19:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKIq-0000Ds-Rs; Tue, 02 Mar 2004 19:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKI2-0008Sa-Hb for nemo@optimus.ietf.org; Tue, 02 Mar 2004 19:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13145 for ; Tue, 2 Mar 2004 19:31:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKI0-0004pH-00 for nemo@ietf.org; Tue, 02 Mar 2004 19:31:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKHA-0004gv-00 for nemo@ietf.org; Tue, 02 Mar 2004 19:30:16 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AyKGW-0004Sg-00 for nemo@ietf.org; Tue, 02 Mar 2004 19:29:36 -0500 Received: from localhost.localdomain (MAC-0-2-2d-b0-f2-f4.wireless.ietf59.or.kr [218.37.227.33]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 0ECEE5D312 for ; Wed, 3 Mar 2004 09:29:05 +0900 (JST) Date: Wed, 3 Mar 2004 09:29:56 +0900 From: Thierry Ernst To: nemo Message-Id: <20040303092956.77f4230b.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Milestones update Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please check out the charter, the milestones have been updated. Thierry. From nemo-admin@ietf.org Wed Mar 3 20:32:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12913 for ; Wed, 3 Mar 2004 20:32:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhiT-0006oi-AM; Wed, 03 Mar 2004 20:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhiN-0006oH-Uq for nemo@optimus.ietf.org; Wed, 03 Mar 2004 20:31:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12878 for ; Wed, 3 Mar 2004 20:31:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhiL-0006hu-00 for nemo@ietf.org; Wed, 03 Mar 2004 20:31:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhhO-0006XX-00 for nemo@ietf.org; Wed, 03 Mar 2004 20:30:55 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AyhgQ-0006GC-00 for nemo@ietf.org; Wed, 03 Mar 2004 20:29:54 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i241Tlha016026 for ; Wed, 3 Mar 2004 17:29:48 -0800 (PST) Message-ID: <40468688.4020405@cs.ucdavis.edu> Date: Wed, 03 Mar 2004 17:29:44 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Subject: [nemo] a special NEMO open session for security/threats analysis X-Priority: 1 (highest) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We will meeting in about 40 minutes in front of the Emerald meeting room in 59th IETF, Seoul. I am sitting here (wearing a dark blue shirt and milky yellow pants) right outside the Emerald room near the stairs. BTW, my laptop is Fujitsu life book (just for you to identify me). We will discuss mainly about two issues: (1). why/what do we need (for this security/threat analysis works)? (2). how to coordinate and collaborate to cover the uncover & to reduce/consolidate the duplicates? I feel, while email communication is great in general, face2face meeting (get acquainted with each other) will help a lot in kicking-off. Hope that you could join, and I will send a special meeting minutes after the meeting. Thanks. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 20:34:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13018 for ; Wed, 3 Mar 2004 20:34:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhkU-00076J-0t for nemo-archive@odin.ietf.org; Wed, 03 Mar 2004 20:34:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i241Y5Fs027289 for nemo-archive@odin.ietf.org; Wed, 3 Mar 2004 20:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhkT-000764-S5 for nemo-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 20:34:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12991 for ; Wed, 3 Mar 2004 20:34:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhkR-00075t-00 for nemo-web-archive@ietf.org; Wed, 03 Mar 2004 20:34:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhjT-0006uo-00 for nemo-web-archive@ietf.org; Wed, 03 Mar 2004 20:33:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyhiW-0006ji-00 for nemo-web-archive@ietf.org; Wed, 03 Mar 2004 20:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhiT-0006oi-AM; Wed, 03 Mar 2004 20:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhiN-0006oH-Uq for nemo@optimus.ietf.org; Wed, 03 Mar 2004 20:31:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12878 for ; Wed, 3 Mar 2004 20:31:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhiL-0006hu-00 for nemo@ietf.org; Wed, 03 Mar 2004 20:31:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhhO-0006XX-00 for nemo@ietf.org; Wed, 03 Mar 2004 20:30:55 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AyhgQ-0006GC-00 for nemo@ietf.org; Wed, 03 Mar 2004 20:29:54 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i241Tlha016026 for ; Wed, 3 Mar 2004 17:29:48 -0800 (PST) Message-ID: <40468688.4020405@cs.ucdavis.edu> Date: Wed, 03 Mar 2004 17:29:44 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Subject: [nemo] a special NEMO open session for security/threats analysis X-Priority: 1 (highest) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We will meeting in about 40 minutes in front of the Emerald meeting room in 59th IETF, Seoul. I am sitting here (wearing a dark blue shirt and milky yellow pants) right outside the Emerald room near the stairs. BTW, my laptop is Fujitsu life book (just for you to identify me). We will discuss mainly about two issues: (1). why/what do we need (for this security/threat analysis works)? (2). how to coordinate and collaborate to cover the uncover & to reduce/consolidate the duplicates? I feel, while email communication is great in general, face2face meeting (get acquainted with each other) will help a lot in kicking-off. Hope that you could join, and I will send a special meeting minutes after the meeting. Thanks. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Fri Mar 5 04:24:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27652 for ; Fri, 5 Mar 2004 04:24:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBYp-00070e-Qm; Fri, 05 Mar 2004 04:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzASJ-0000Id-0z for nemo@optimus.ietf.org; Fri, 05 Mar 2004 03:13:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25292 for ; Fri, 5 Mar 2004 03:13:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzASG-0002BM-00 for nemo@ietf.org; Fri, 05 Mar 2004 03:13:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzARI-00020U-00 for nemo@ietf.org; Fri, 05 Mar 2004 03:12:12 -0500 Received: from [147.6.42.146] (helo=filter2.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AzAQH-0001gN-00 for nemo@ietf.org; Fri, 05 Mar 2004 03:11:09 -0500 Received: from external ([147.6.24.123]) by filter2 (1.0) id i2589qL09214; Fri, 05 Mar 2004 17:09:52 +0900 Message-ID: <008601c40289$545099c0$7b180693@yjtcha> From: "Yongjoo Tcha" To: Date: Fri, 5 Mar 2004 17:10:32 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01C402D4.C43386D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=2.60 Subject: [nemo] Posting to nemo mailing list Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0083_01C402D4.C43386D0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSB3YW50IHRvIHBvc3QgdG8gbWFpbGluZyBsaXN0Lg0KSSBhbHJlYWR5IHN1YnNjcmliZWQgdG8g bWlwNCBXRy4NCg0KY29uZmlybSA0NjE2NDQNClRoYW5rIHlvdS4= ------=_NextPart_000_0083_01C402D4.C43386D0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTQwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48 Rk9OVCBzaXplPTI+SSB3YW50IHRvIHBvc3QgdG8gbWFpbGluZyBsaXN0LjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPkkgYWxyZWFkeSBzdWJzY3JpYmVkIHRvIG1pcDQgV0cuPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5jb25m aXJtIDQ2MTY0NDwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmsgeW91LjwvRk9OVD48L0RJ Vj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0083_01C402D4.C43386D0-- From nemo-admin@ietf.org Mon Mar 8 04:47:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21764 for ; Mon, 8 Mar 2004 04:47:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HLj-0003em-3l; Mon, 08 Mar 2004 04:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HLA-0003cJ-Kp for nemo@optimus.ietf.org; Mon, 08 Mar 2004 04:46:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21749 for ; Mon, 8 Mar 2004 04:46:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0HL7-0002Xm-00 for nemo@ietf.org; Mon, 08 Mar 2004 04:46:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0HKA-0002PR-00 for nemo@ietf.org; Mon, 08 Mar 2004 04:45:27 -0500 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1B0HJf-0002Gr-00 for nemo@ietf.org; Mon, 08 Mar 2004 04:44:55 -0500 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i289clq6031454 for ; Mon, 8 Mar 2004 18:38:47 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i289cl2F031453 for nemo@ietf.org; Mon, 8 Mar 2004 18:38:47 +0900 Date: Mon, 8 Mar 2004 18:38:47 +0900 From: Seongho Cho To: NEMO WG Message-ID: <20040308183847.A31053@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] (Threat) Security Problems/Issues Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi folks, I think Prof. Wu will send an e-mail on the previous face2face meeting. For the first step, we will discuss on security issues on NEMO basic support. As a start, I will briefly describe listed issues of Security Consideration of NEMO Basic Support draft and some threats from threat analysis drafts. Followings are my own view/opinion, not discussed in the last meeting. Any kinds of comments are welcomed. First, from the Security Consideration Section 1.1 Signaling messages between the MR and the HA - all signaling messages MUST be authenticated by IPsec * problem/issue: 1. The HA Discovery Request message using anycast address can (or may) not use IPsec. Therefore, it can be vulnerable to R-bit spoofing attack. 2. any other signaling messages should be considered? 1.2. MR operations - Ingress filtering scope: 1. the IP spoofed bi-directional tunnel from nodes in the Mobile Network -> the MR SHOULD check the IP source address whether it belongs to the own MNP 2. IP-in-IP tunneled packet from nodes in the Mobile Network -> the MR has to forward the decapsulated packet and SHOULD check the source address of the inner packet. * problem/issue: MR operations are considered enough? 1.3 HA operations - Verifying bi-directional tunnel packets scope: 1. the source address of tunnel packets MUST be the MR's CoA 2. the source address of the inner header MUST be a correct address - Routing updates injected from the MR into the Home Link scope: 1. routing updates MUST be verified before processing. * problem/issue: HA operations are considered enough? 1.4 Mobile Host operations - refer to the Mobile IPv6 specification for security considerations Second, from some threat analysis drafts 2.1 BU spoofing - an attacker MNN in the Mobile Network can send spoofed BU. -> IMO, ingress filtering and IPsec AH can solve, considering 1.1 and 1.2. 2.2 DoS attack due to error processing - a malicious MR sends a BU on the explicit mode to its HA claiming a MNP belonging to another MR -> IMO, this BU would not be authenticated. 2.3 Location privacy - the desire of a Mobile Host (or Router) not to reveal its current CoA. * problem/issue: Is it MIP specific or NEMO specific? 2.4 R bit spoofing of HA discovery Request - mentioned above at 1.1. Bests, Seongho -- ------------------------------------------------------------------------ Cho, Seongho (Ph.D. candidate) Information Networking & Computing Laboratory, School of Computer Science and Engineering, Seoul National University San 56-1, Shillim dong, Gwanak gu, Seoul, Korea, 151-744. TEL: +82-2-884-3936 FAX: +82-2-871-4912 http://popeye.snu.ac.kr/~shcho ; mailto:shcho@popeye.snu.ac.kr ------------------------------------------------------------------------ From exim@www1.ietf.org Mon Mar 8 04:49:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21843 for ; Mon, 8 Mar 2004 04:49:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HNw-0003mD-QS for nemo-archive@odin.ietf.org; Mon, 08 Mar 2004 04:49:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i289nKQM014518 for nemo-archive@odin.ietf.org; Mon, 8 Mar 2004 04:49:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HNv-0003m5-UF for nemo-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 04:49:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21810 for ; Mon, 8 Mar 2004 04:49:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0HNt-0002yq-00 for nemo-web-archive@ietf.org; Mon, 08 Mar 2004 04:49:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0HMu-0002od-00 for nemo-web-archive@ietf.org; Mon, 08 Mar 2004 04:48:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0HLt-0002Zi-00 for nemo-web-archive@ietf.org; Mon, 08 Mar 2004 04:47:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HLj-0003em-3l; Mon, 08 Mar 2004 04:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HLA-0003cJ-Kp for nemo@optimus.ietf.org; Mon, 08 Mar 2004 04:46:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21749 for ; Mon, 8 Mar 2004 04:46:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0HL7-0002Xm-00 for nemo@ietf.org; Mon, 08 Mar 2004 04:46:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0HKA-0002PR-00 for nemo@ietf.org; Mon, 08 Mar 2004 04:45:27 -0500 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1B0HJf-0002Gr-00 for nemo@ietf.org; Mon, 08 Mar 2004 04:44:55 -0500 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i289clq6031454 for ; Mon, 8 Mar 2004 18:38:47 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i289cl2F031453 for nemo@ietf.org; Mon, 8 Mar 2004 18:38:47 +0900 Date: Mon, 8 Mar 2004 18:38:47 +0900 From: Seongho Cho To: NEMO WG Message-ID: <20040308183847.A31053@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [nemo] (Threat) Security Problems/Issues Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi folks, I think Prof. Wu will send an e-mail on the previous face2face meeting. For the first step, we will discuss on security issues on NEMO basic support. As a start, I will briefly describe listed issues of Security Consideration of NEMO Basic Support draft and some threats from threat analysis drafts. Followings are my own view/opinion, not discussed in the last meeting. Any kinds of comments are welcomed. First, from the Security Consideration Section 1.1 Signaling messages between the MR and the HA - all signaling messages MUST be authenticated by IPsec * problem/issue: 1. The HA Discovery Request message using anycast address can (or may) not use IPsec. Therefore, it can be vulnerable to R-bit spoofing attack. 2. any other signaling messages should be considered? 1.2. MR operations - Ingress filtering scope: 1. the IP spoofed bi-directional tunnel from nodes in the Mobile Network -> the MR SHOULD check the IP source address whether it belongs to the own MNP 2. IP-in-IP tunneled packet from nodes in the Mobile Network -> the MR has to forward the decapsulated packet and SHOULD check the source address of the inner packet. * problem/issue: MR operations are considered enough? 1.3 HA operations - Verifying bi-directional tunnel packets scope: 1. the source address of tunnel packets MUST be the MR's CoA 2. the source address of the inner header MUST be a correct address - Routing updates injected from the MR into the Home Link scope: 1. routing updates MUST be verified before processing. * problem/issue: HA operations are considered enough? 1.4 Mobile Host operations - refer to the Mobile IPv6 specification for security considerations Second, from some threat analysis drafts 2.1 BU spoofing - an attacker MNN in the Mobile Network can send spoofed BU. -> IMO, ingress filtering and IPsec AH can solve, considering 1.1 and 1.2. 2.2 DoS attack due to error processing - a malicious MR sends a BU on the explicit mode to its HA claiming a MNP belonging to another MR -> IMO, this BU would not be authenticated. 2.3 Location privacy - the desire of a Mobile Host (or Router) not to reveal its current CoA. * problem/issue: Is it MIP specific or NEMO specific? 2.4 R bit spoofing of HA discovery Request - mentioned above at 1.1. Bests, Seongho -- ------------------------------------------------------------------------ Cho, Seongho (Ph.D. candidate) Information Networking & Computing Laboratory, School of Computer Science and Engineering, Seoul National University San 56-1, Shillim dong, Gwanak gu, Seoul, Korea, 151-744. TEL: +82-2-884-3936 FAX: +82-2-871-4912 http://popeye.snu.ac.kr/~shcho ; mailto:shcho@popeye.snu.ac.kr ------------------------------------------------------------------------ From nemo-admin@ietf.org Tue Mar 9 15:09:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19394 for ; Tue, 9 Mar 2004 15:09:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nXE-00059s-0q; Tue, 09 Mar 2004 15:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nWD-0004Qx-BQ for nemo@optimus.ietf.org; Tue, 09 Mar 2004 15:08:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19194 for ; Tue, 9 Mar 2004 15:07:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nWA-0001z1-00 for nemo@ietf.org; Tue, 09 Mar 2004 15:07:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nVI-0001oW-00 for nemo@ietf.org; Tue, 09 Mar 2004 15:07:05 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B0nUg-0001e0-00 for nemo@ietf.org; Tue, 09 Mar 2004 15:06:27 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i29K6QAh028158 for ; Tue, 9 Mar 2004 21:06:26 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 21:06:26 +0100 Received: from ericsson.com (arael27m51.eu.ericsson.se [153.88.95.52]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFQB6KH; Tue, 9 Mar 2004 21:07:30 +0100 Message-ID: <404E23B8.1070809@ericsson.com> Date: Tue, 09 Mar 2004 21:06:16 +0100 X-Sybari-Trust: 4f4ea3fa 2c4885b5 39802fef 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> <20040225143439.29254724.ernst@sfc.wide.ad.jp> <403C6A63.50401@ericsson.com> <20040226175259.10846d05.ernst@sfc.wide.ad.jp> In-Reply-To: <20040226175259.10846d05.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2004 20:06:26.0179 (UTC) FILETIME=[008F5D30:01C40612] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Thierry, Thierry Ernst wrote: > Hi Mattias, > > >>>>> o (N,1,N) Mobile Network > > >>Thierry, Chan-Wah [I answer you both here], >> >>It is a question on what entities should carry out the dirty work. >>Either the MRs or the MNNs. > > > It's not the same dirty work. > > On the MR, it's about registering several prefixes, or synchronisation > > On the MNN, it's about source address selection. Any host is considered > to implement some source address selection mechanism. Or, is there > anything else dirty to do ? Yes, some form of source address selection mechanism. But e.g. RFC3484 would not help (enough) here. > > >>To me it is important that legacy IPv6 hosts can still get connectivity >>in a moving network without having to implement new proposals such as >>draft-huitema-multi6-hosts-xx. >> >>So what is most important: to support standard IPv6 hosts or to simplify >>the MR? It seems like in order to simplify the MR we are proposing to >>introduce a NEMO scenario that was considered "broken" in the IPv6 WG >>earlier. All routers on a link are equal, from the host's point of view! >>The ND model builds on that. I agree that we have arguments both in NEMO >>and in multi6 to question that model, but we do we want to change that >>model just to allow a variant of a scenario? > > > I personaly wish to support standard IPv6 hosts. But I've never heard > that advertising multiple prefixes would break the model. Do you have > any reference to a possible decision made by the IPv6 WG to disallow > such scenario ? Any document where this is documented ? I've been looking for that old discussion but I can't find it. Attached below is a similar old conversation (from 2002-06-06) on this ML. I've posted a clarification request on IPv6 ML so we'll have to see if someone else remembers it all. /Mattias ---- >>> We have two cases of multihoming: >>> a. a single MR with 2 interfaces >>> b. 2 or more MRs >>> >>> For a), the problem is trivial, the MR needs to >>> decide which packets should be forwarded to which >>> egress interface. >>> >>> For b) the problem is less trivial, but certainly >>> solveable without too much complexity. In fact, I'm >>> hoping we can do that without any new protocols. >>> The problem is mainly for LFNs. Somehow, we need to >>> make sure that LFNs continue to operate as standard >>> IPv6 nodes that are neither MIPv6-aware, nor nemo-aware. >>> This can be done with some cooperation between MRs. >>> I don't have a solution written up, but anyway let's >>> not dwell on the solution so much right now, let's >>> think on a 'requirements' level and the possible consequences >>> of our decisions. > > > I think the issue is really whether we assume cooperation and coordination > between the two MRs. From the hosts (LFN or anything else) there > is no difference between a single MR advertising N prefixes (N can be one or > more than one) and multiple MR's advertising N prefixes. > > However, if anybody is thinking that one can have 2 uncoordinated MRs e.g. > MR1 advertising prefix P1 and MR2 advertising prefix P2, *and* there is > an assumption that MR1 can only handle packets with P1 as the source prefix > and vice versa, then we don't fit well in the current architecture. > This is because hosts don't assume any relationship between which > source address they use and which of the default routers they use. > > Thus I suspect that if we avoid the can of worms associated with > uncoordinated MRs, then the multiple MR case is just as easy as the > single MR case. > But it sure wouldn't hurt to right this down in some document > about model/assumptions. > > Erik > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From exim@www1.ietf.org Tue Mar 9 15:11:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19659 for ; Tue, 9 Mar 2004 15:11:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nZI-00066e-DH for nemo-archive@odin.ietf.org; Tue, 09 Mar 2004 15:11:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29KBCOL023465 for nemo-archive@odin.ietf.org; Tue, 9 Mar 2004 15:11:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nZI-00066H-6v for nemo-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 15:11:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19591 for ; Tue, 9 Mar 2004 15:11:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nZF-0002a4-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 15:11:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nYH-0002Nx-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 15:10:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0nXX-0002CG-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 15:09:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nXE-00059s-0q; Tue, 09 Mar 2004 15:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nWD-0004Qx-BQ for nemo@optimus.ietf.org; Tue, 09 Mar 2004 15:08:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19194 for ; Tue, 9 Mar 2004 15:07:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nWA-0001z1-00 for nemo@ietf.org; Tue, 09 Mar 2004 15:07:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nVI-0001oW-00 for nemo@ietf.org; Tue, 09 Mar 2004 15:07:05 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B0nUg-0001e0-00 for nemo@ietf.org; Tue, 09 Mar 2004 15:06:27 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i29K6QAh028158 for ; Tue, 9 Mar 2004 21:06:26 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 21:06:26 +0100 Received: from ericsson.com (arael27m51.eu.ericsson.se [153.88.95.52]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFQB6KH; Tue, 9 Mar 2004 21:07:30 +0100 Message-ID: <404E23B8.1070809@ericsson.com> Date: Tue, 09 Mar 2004 21:06:16 +0100 X-Sybari-Trust: 4f4ea3fa 2c4885b5 39802fef 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> <20040225143439.29254724.ernst@sfc.wide.ad.jp> <403C6A63.50401@ericsson.com> <20040226175259.10846d05.ernst@sfc.wide.ad.jp> In-Reply-To: <20040226175259.10846d05.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2004 20:06:26.0179 (UTC) FILETIME=[008F5D30:01C40612] Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thierry, Thierry Ernst wrote: > Hi Mattias, > > >>>>> o (N,1,N) Mobile Network > > >>Thierry, Chan-Wah [I answer you both here], >> >>It is a question on what entities should carry out the dirty work. >>Either the MRs or the MNNs. > > > It's not the same dirty work. > > On the MR, it's about registering several prefixes, or synchronisation > > On the MNN, it's about source address selection. Any host is considered > to implement some source address selection mechanism. Or, is there > anything else dirty to do ? Yes, some form of source address selection mechanism. But e.g. RFC3484 would not help (enough) here. > > >>To me it is important that legacy IPv6 hosts can still get connectivity >>in a moving network without having to implement new proposals such as >>draft-huitema-multi6-hosts-xx. >> >>So what is most important: to support standard IPv6 hosts or to simplify >>the MR? It seems like in order to simplify the MR we are proposing to >>introduce a NEMO scenario that was considered "broken" in the IPv6 WG >>earlier. All routers on a link are equal, from the host's point of view! >>The ND model builds on that. I agree that we have arguments both in NEMO >>and in multi6 to question that model, but we do we want to change that >>model just to allow a variant of a scenario? > > > I personaly wish to support standard IPv6 hosts. But I've never heard > that advertising multiple prefixes would break the model. Do you have > any reference to a possible decision made by the IPv6 WG to disallow > such scenario ? Any document where this is documented ? I've been looking for that old discussion but I can't find it. Attached below is a similar old conversation (from 2002-06-06) on this ML. I've posted a clarification request on IPv6 ML so we'll have to see if someone else remembers it all. /Mattias ---- >>> We have two cases of multihoming: >>> a. a single MR with 2 interfaces >>> b. 2 or more MRs >>> >>> For a), the problem is trivial, the MR needs to >>> decide which packets should be forwarded to which >>> egress interface. >>> >>> For b) the problem is less trivial, but certainly >>> solveable without too much complexity. In fact, I'm >>> hoping we can do that without any new protocols. >>> The problem is mainly for LFNs. Somehow, we need to >>> make sure that LFNs continue to operate as standard >>> IPv6 nodes that are neither MIPv6-aware, nor nemo-aware. >>> This can be done with some cooperation between MRs. >>> I don't have a solution written up, but anyway let's >>> not dwell on the solution so much right now, let's >>> think on a 'requirements' level and the possible consequences >>> of our decisions. > > > I think the issue is really whether we assume cooperation and coordination > between the two MRs. From the hosts (LFN or anything else) there > is no difference between a single MR advertising N prefixes (N can be one or > more than one) and multiple MR's advertising N prefixes. > > However, if anybody is thinking that one can have 2 uncoordinated MRs e.g. > MR1 advertising prefix P1 and MR2 advertising prefix P2, *and* there is > an assumption that MR1 can only handle packets with P1 as the source prefix > and vice versa, then we don't fit well in the current architecture. > This is because hosts don't assume any relationship between which > source address they use and which of the default routers they use. > > Thus I suspect that if we avoid the can of worms associated with > uncoordinated MRs, then the multiple MR case is just as easy as the > single MR case. > But it sure wouldn't hurt to right this down in some document > about model/assumptions. > > Erik > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From nemo-admin@ietf.org Tue Mar 9 21:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13312 for ; Tue, 9 Mar 2004 21:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0tO4-0004UM-UC; Tue, 09 Mar 2004 21:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0tNL-0004Tf-Da for nemo@optimus.ietf.org; Tue, 09 Mar 2004 21:23:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13267 for ; Tue, 9 Mar 2004 21:23:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0tNI-00009z-00 for nemo@ietf.org; Tue, 09 Mar 2004 21:23:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0tMI-0007nO-00 for nemo@ietf.org; Tue, 09 Mar 2004 21:22:10 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B0tLx-0007eE-00 for nemo@ietf.org; Tue, 09 Mar 2004 21:21:49 -0500 content-class: urn:content-classes:message Date: Tue, 9 Mar 2004 21:21:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] (Threat) Security Problems/Issues X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQE8l2JcYv5XxgTQE2E29K0JNrtUABUnBEA From: "Soliman Hesham" To: "NEMO WG" Cc: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] nemo extensions of BU - problem in Basic solution and HMIPv6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Folks,=20 It looks like nemo has added a new flag in=20 the BU that overwrites the HMIPv6 flag that's been in the BU for quite some time. The nemo BU includes the R flag in the same place as HMIPv6's M flag. Both drafts have finished WG=20 LC... ideas? ADs? Hesham From exim@www1.ietf.org Tue Mar 9 21:26:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13353 for ; Tue, 9 Mar 2004 21:26:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0tQD-0004c4-Is for nemo-archive@odin.ietf.org; Tue, 09 Mar 2004 21:26:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A2QDo7017725 for nemo-archive@odin.ietf.org; Tue, 9 Mar 2004 21:26:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0tQC-0004bo-Ot for nemo-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 21:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13342 for ; Tue, 9 Mar 2004 21:26:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0tQA-0000cY-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 21:26:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0tP4-0000Sp-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 21:25:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0tO8-0000JX-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 21:24:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0tO4-0004UM-UC; Tue, 09 Mar 2004 21:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0tNL-0004Tf-Da for nemo@optimus.ietf.org; Tue, 09 Mar 2004 21:23:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13267 for ; Tue, 9 Mar 2004 21:23:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0tNI-00009z-00 for nemo@ietf.org; Tue, 09 Mar 2004 21:23:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0tMI-0007nO-00 for nemo@ietf.org; Tue, 09 Mar 2004 21:22:10 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B0tLx-0007eE-00 for nemo@ietf.org; Tue, 09 Mar 2004 21:21:49 -0500 content-class: urn:content-classes:message Date: Tue, 9 Mar 2004 21:21:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] (Threat) Security Problems/Issues X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQE8l2JcYv5XxgTQE2E29K0JNrtUABUnBEA From: "Soliman Hesham" To: "NEMO WG" Cc: , Content-Transfer-Encoding: quoted-printable Subject: [nemo] nemo extensions of BU - problem in Basic solution and HMIPv6 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Folks,=20 It looks like nemo has added a new flag in=20 the BU that overwrites the HMIPv6 flag that's been in the BU for quite some time. The nemo BU includes the R flag in the same place as HMIPv6's M flag. Both drafts have finished WG=20 LC... ideas? ADs? Hesham From nemo-admin@ietf.org Tue Mar 9 22:05:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14395 for ; Tue, 9 Mar 2004 22:05:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u1p-0006PG-6Q; Tue, 09 Mar 2004 22:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u1G-0006Ng-Vm for nemo@optimus.ietf.org; Tue, 09 Mar 2004 22:04:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14361 for ; Tue, 9 Mar 2004 22:04:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0u1E-0006bg-00 for nemo@ietf.org; Tue, 09 Mar 2004 22:04:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0u0N-0006Qo-00 for nemo@ietf.org; Tue, 09 Mar 2004 22:03:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B0tzi-0006EK-00 for nemo@ietf.org; Tue, 09 Mar 2004 22:02:55 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2A32Ia22980; Tue, 9 Mar 2004 19:02:18 -0800 X-mProtect: <200403100302> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJoY6Tl; Tue, 09 Mar 2004 19:02:17 PST Message-ID: <404E884A.3070705@iprg.nokia.com> Date: Tue, 09 Mar 2004 19:15:22 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: NEMO WG , narten@us.ibm.com, margaret@thingmagic.com Subject: Re: [nemo] nemo extensions of BU - problem in Basic solution and HMIPv6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I guess whichever draft is approved by the IESG first gets the flag. :) just kidding, its my fault. I didnt check. we can change the position of the flag in the NEMO basic support if needed. Vijay Soliman Hesham wrote: > Folks, > > It looks like nemo has added a new flag in > the BU that overwrites the HMIPv6 flag that's > been in the BU for quite some time. The nemo > BU includes the R flag in the same place as > HMIPv6's M flag. Both drafts have finished WG > LC... > > ideas? ADs? > > Hesham > From exim@www1.ietf.org Tue Mar 9 22:07:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14499 for ; Tue, 9 Mar 2004 22:07:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u3n-0006oQ-TT for nemo-archive@odin.ietf.org; Tue, 09 Mar 2004 22:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A3774Y026171 for nemo-archive@odin.ietf.org; Tue, 9 Mar 2004 22:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u3n-0006o1-Bl for nemo-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 22:07:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14456 for ; Tue, 9 Mar 2004 22:07:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0u3k-00074k-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 22:07:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0u2l-0006u4-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 22:06:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0u1o-0006jy-00 for nemo-web-archive@ietf.org; Tue, 09 Mar 2004 22:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u1p-0006PG-6Q; Tue, 09 Mar 2004 22:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u1G-0006Ng-Vm for nemo@optimus.ietf.org; Tue, 09 Mar 2004 22:04:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14361 for ; Tue, 9 Mar 2004 22:04:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0u1E-0006bg-00 for nemo@ietf.org; Tue, 09 Mar 2004 22:04:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0u0N-0006Qo-00 for nemo@ietf.org; Tue, 09 Mar 2004 22:03:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B0tzi-0006EK-00 for nemo@ietf.org; Tue, 09 Mar 2004 22:02:55 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2A32Ia22980; Tue, 9 Mar 2004 19:02:18 -0800 X-mProtect: <200403100302> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJoY6Tl; Tue, 09 Mar 2004 19:02:17 PST Message-ID: <404E884A.3070705@iprg.nokia.com> Date: Tue, 09 Mar 2004 19:15:22 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: NEMO WG , narten@us.ibm.com, margaret@thingmagic.com Subject: Re: [nemo] nemo extensions of BU - problem in Basic solution and HMIPv6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I guess whichever draft is approved by the IESG first gets the flag. :) just kidding, its my fault. I didnt check. we can change the position of the flag in the NEMO basic support if needed. Vijay Soliman Hesham wrote: > Folks, > > It looks like nemo has added a new flag in > the BU that overwrites the HMIPv6 flag that's > been in the BU for quite some time. The nemo > BU includes the R flag in the same place as > HMIPv6's M flag. Both drafts have finished WG > LC... > > ideas? ADs? > > Hesham > From nemo-admin@ietf.org Wed Mar 10 03:40:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26324 for ; Wed, 10 Mar 2004 03:40:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zFy-00033v-Lv; Wed, 10 Mar 2004 03:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zFQ-0002yd-8z for nemo@optimus.ietf.org; Wed, 10 Mar 2004 03:39:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26090 for ; Wed, 10 Mar 2004 03:39:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zFN-0000c9-00 for nemo@ietf.org; Wed, 10 Mar 2004 03:39:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zEW-0000NV-00 for nemo@ietf.org; Wed, 10 Mar 2004 03:38:33 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B0zDc-00000t-00 for nemo@ietf.org; Wed, 10 Mar 2004 03:37:36 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] nemo extensions of BU - problem in Basic solution and HMIPv6 Date: Wed, 10 Mar 2004 03:37:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] nemo extensions of BU - problem in Basic solution and HMIPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQGTB2FvYxo6nuGSLCgRCXOneARIAALaL5Q From: "Soliman Hesham" To: "Vijay Devarapalli" , "Soliman Hesham" Cc: "NEMO WG" , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks Vijay, that would be helpful.=20 Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Tuesday, March 09, 2004 10:15 PM > To: Soliman Hesham > Cc: NEMO WG; narten@us.ibm.com; margaret@thingmagic.com > Subject: Re: [nemo] nemo extensions of BU - problem in Basic solution > and HMIPv6 >=20 >=20 > I guess whichever draft is approved by the IESG > first gets the flag. :) >=20 > just kidding, its my fault. I didnt check. we can > change the position of the flag in the NEMO basic > support if needed. >=20 > Vijay >=20 > Soliman Hesham wrote: > > Folks,=20 > >=20 > > It looks like nemo has added a new flag in=20 > > the BU that overwrites the HMIPv6 flag that's > > been in the BU for quite some time. The nemo > > BU includes the R flag in the same place as > > HMIPv6's M flag. Both drafts have finished WG=20 > > LC... > >=20 > > ideas? ADs? > >=20 > > Hesham > >=20 >=20 >=20 From exim@www1.ietf.org Wed Mar 10 03:42:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26435 for ; Wed, 10 Mar 2004 03:42:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zHp-0003IZ-G9 for nemo-archive@odin.ietf.org; Wed, 10 Mar 2004 03:41:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A8fvCg012678 for nemo-archive@odin.ietf.org; Wed, 10 Mar 2004 03:41:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zHo-0003IP-TR for nemo-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 03:41:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26398 for ; Wed, 10 Mar 2004 03:41:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zHm-00016w-00 for nemo-web-archive@ietf.org; Wed, 10 Mar 2004 03:41:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zGf-0000t3-00 for nemo-web-archive@ietf.org; Wed, 10 Mar 2004 03:40:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0zG2-0000hO-00 for nemo-web-archive@ietf.org; Wed, 10 Mar 2004 03:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zFy-00033v-Lv; Wed, 10 Mar 2004 03:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zFQ-0002yd-8z for nemo@optimus.ietf.org; Wed, 10 Mar 2004 03:39:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26090 for ; Wed, 10 Mar 2004 03:39:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zFN-0000c9-00 for nemo@ietf.org; Wed, 10 Mar 2004 03:39:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zEW-0000NV-00 for nemo@ietf.org; Wed, 10 Mar 2004 03:38:33 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B0zDc-00000t-00 for nemo@ietf.org; Wed, 10 Mar 2004 03:37:36 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] nemo extensions of BU - problem in Basic solution and HMIPv6 Date: Wed, 10 Mar 2004 03:37:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] nemo extensions of BU - problem in Basic solution and HMIPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQGTB2FvYxo6nuGSLCgRCXOneARIAALaL5Q From: "Soliman Hesham" To: "Vijay Devarapalli" , "Soliman Hesham" Cc: "NEMO WG" , , Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Vijay, that would be helpful.=20 Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Tuesday, March 09, 2004 10:15 PM > To: Soliman Hesham > Cc: NEMO WG; narten@us.ibm.com; margaret@thingmagic.com > Subject: Re: [nemo] nemo extensions of BU - problem in Basic solution > and HMIPv6 >=20 >=20 > I guess whichever draft is approved by the IESG > first gets the flag. :) >=20 > just kidding, its my fault. I didnt check. we can > change the position of the flag in the NEMO basic > support if needed. >=20 > Vijay >=20 > Soliman Hesham wrote: > > Folks,=20 > >=20 > > It looks like nemo has added a new flag in=20 > > the BU that overwrites the HMIPv6 flag that's > > been in the BU for quite some time. The nemo > > BU includes the R flag in the same place as > > HMIPv6's M flag. Both drafts have finished WG=20 > > LC... > >=20 > > ideas? ADs? > >=20 > > Hesham > >=20 >=20 >=20 From nemo-admin@ietf.org Fri Mar 12 15:11:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15795 for ; Fri, 12 Mar 2004 15:11:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1szm-0003E9-5A; Fri, 12 Mar 2004 15:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1syq-00031s-RJ for nemo@optimus.ietf.org; Fri, 12 Mar 2004 15:10:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15628 for ; Fri, 12 Mar 2004 15:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1syn-0006WE-00 for nemo@ietf.org; Fri, 12 Mar 2004 15:10:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sxr-0006N6-00 for nemo@ietf.org; Fri, 12 Mar 2004 15:09:03 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1B1sx8-0006EF-00 for nemo@ietf.org; Fri, 12 Mar 2004 15:08:18 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2CK8Gvf003343 for ; Fri, 12 Mar 2004 12:08:16 -0800 (PST) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2CK8BVL016500 for ; Fri, 12 Mar 2004 12:08:14 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.61]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 12:08:13 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4086D.BF566300" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-terminology-01.txt Date: Fri, 12 Mar 2004 12:08:12 -0800 Message-ID: <0320111483D8B84AAAB437215BBDA5264361B0@NAEX01.na.qualcomm.com> X-MS-Has-Attach: yes Thread-Topic: Re: [nemo] I-D ACTION:draft-ietf-nemo-terminology-01.txt Thread-Index: AcP2MD2mz4HzKGIwSlWLZZqu+rYQrgSNUHfQ From: "Craig, Dave" To: X-OriginalArrivalTime: 12 Mar 2004 20:08:13.0620 (UTC) FILETIME=[BFD6CF40:01C4086D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C4086D.BF566300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a typo in Page 14, Scenario 1, the first bullet? "* NEMO-2 becomes a subservient of NEMO-11" instead is: "* NEMO-2 becomes a subservient of NEMO-1" It also may be helpful to explain the priority shown in Section 5.5 Scenario 1, in Section 4. I am guessing that it may be something along the lines of, "A NEMO has the nesting depth of the largest mobile nesting depth of its attached MRs." To me that would explain why in Scenario 1 NEMO-2 becomes subservient to NEMO-1 even though NEMO-2 only has one level of nesting to the Internet through MR2b. Thanks for the draft that helps get folks up to speed on NEMO, Dave Craig -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, February 18, 2004 7:01 AM Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-terminology-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Terminology Author(s) : T. Ernst, H. Lach Filename : draft-ietf-nemo-terminology-01.txt Pages : 21 Date : 2004-2-18 =09 This document defines a terminology for discussing network mobility problems and solution requirements. Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-terminology-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-terminology-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C4086D.BF566300 Content-Type: application/octet-stream; name="draft-ietf-nemo-terminology-01.URL" Content-Description: draft-ietf-nemo-terminology-01.URL Content-Disposition: attachment; filename="draft-ietf-nemo-terminology-01.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW5lbW8tdGVybWlub2xvZ3ktMDEudHh0DQo= ------_=_NextPart_001_01C4086D.BF566300-- From exim@www1.ietf.org Fri Mar 12 15:13:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16019 for ; Fri, 12 Mar 2004 15:13:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1t1V-0003u9-4Y for nemo-archive@odin.ietf.org; Fri, 12 Mar 2004 15:12:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CKCnWX015005 for nemo-archive@odin.ietf.org; Fri, 12 Mar 2004 15:12:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1t1U-0003tu-Ss for nemo-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 15:12:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15968 for ; Fri, 12 Mar 2004 15:12:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1t1T-0006uA-00 for nemo-web-archive@ietf.org; Fri, 12 Mar 2004 15:12:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1t0X-0006mY-00 for nemo-web-archive@ietf.org; Fri, 12 Mar 2004 15:11:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1szt-0006fL-00 for nemo-web-archive@ietf.org; Fri, 12 Mar 2004 15:11:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1szm-0003E9-5A; Fri, 12 Mar 2004 15:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1syq-00031s-RJ for nemo@optimus.ietf.org; Fri, 12 Mar 2004 15:10:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15628 for ; Fri, 12 Mar 2004 15:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1syn-0006WE-00 for nemo@ietf.org; Fri, 12 Mar 2004 15:10:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sxr-0006N6-00 for nemo@ietf.org; Fri, 12 Mar 2004 15:09:03 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1B1sx8-0006EF-00 for nemo@ietf.org; Fri, 12 Mar 2004 15:08:18 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2CK8Gvf003343 for ; Fri, 12 Mar 2004 12:08:16 -0800 (PST) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2CK8BVL016500 for ; Fri, 12 Mar 2004 12:08:14 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.61]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 12:08:13 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4086D.BF566300" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-terminology-01.txt Date: Fri, 12 Mar 2004 12:08:12 -0800 Message-ID: <0320111483D8B84AAAB437215BBDA5264361B0@NAEX01.na.qualcomm.com> X-MS-Has-Attach: yes Thread-Topic: Re: [nemo] I-D ACTION:draft-ietf-nemo-terminology-01.txt Thread-Index: AcP2MD2mz4HzKGIwSlWLZZqu+rYQrgSNUHfQ From: "Craig, Dave" To: X-OriginalArrivalTime: 12 Mar 2004 20:08:13.0620 (UTC) FILETIME=[BFD6CF40:01C4086D] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4086D.BF566300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a typo in Page 14, Scenario 1, the first bullet? "* NEMO-2 becomes a subservient of NEMO-11" instead is: "* NEMO-2 becomes a subservient of NEMO-1" It also may be helpful to explain the priority shown in Section 5.5 Scenario 1, in Section 4. I am guessing that it may be something along the lines of, "A NEMO has the nesting depth of the largest mobile nesting depth of its attached MRs." To me that would explain why in Scenario 1 NEMO-2 becomes subservient to NEMO-1 even though NEMO-2 only has one level of nesting to the Internet through MR2b. Thanks for the draft that helps get folks up to speed on NEMO, Dave Craig -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, February 18, 2004 7:01 AM Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-terminology-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Terminology Author(s) : T. Ernst, H. Lach Filename : draft-ietf-nemo-terminology-01.txt Pages : 21 Date : 2004-2-18 =09 This document defines a terminology for discussing network mobility problems and solution requirements. Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-terminology-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-terminology-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C4086D.BF566300 Content-Type: application/octet-stream; name="draft-ietf-nemo-terminology-01.URL" Content-Description: draft-ietf-nemo-terminology-01.URL Content-Disposition: attachment; filename="draft-ietf-nemo-terminology-01.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW5lbW8tdGVybWlub2xvZ3ktMDEudHh0DQo= ------_=_NextPart_001_01C4086D.BF566300-- From nemo-admin@ietf.org Mon Mar 15 21:37:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16140 for ; Mon, 15 Mar 2004 21:37:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34Rx-0000Ea-3c; Mon, 15 Mar 2004 21:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34RQ-0000DU-6u for nemo@optimus.ietf.org; Mon, 15 Mar 2004 21:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16054 for ; Mon, 15 Mar 2004 21:36:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B34RN-0000nI-00 for nemo@ietf.org; Mon, 15 Mar 2004 21:36:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B34QM-0000iL-00 for nemo@ietf.org; Mon, 15 Mar 2004 21:35:23 -0500 Received: from netmon.cs.usm.my ([161.142.8.104] helo=network2.cs.usm.my) by ietf-mx with esmtp (Exim 4.12) id 1B34PV-0000b5-00 for nemo@ietf.org; Mon, 15 Mar 2004 21:34:30 -0500 Received: from wafaa (unknown [10.207.140.85]) by network2.cs.usm.my (Postfix) with SMTP id A5DB5F459 for ; Tue, 16 Mar 2004 10:33:48 +0800 (MYT) Message-ID: <001001c40aff$1225c560$558ccf0a@wafaa> From: "Wafaa Al-Salihy" To: Date: Tue, 16 Mar 2004 10:33:30 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C40B42.20386390" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,CLICK_BELOW,HTML_50_60, HTML_IMAGE_ONLY_10,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Subject: [nemo] RO between Cn and MR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C40B42.20386390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi There, i'm just started to review the Nemo drafts, and i have and i = understood that after the MR move the big issue is the route = optimization between Cn and Mnn if i'm not mistaken, my question is = after MR move to new link and HA intercept packets for MR' HoA, is there = will be any route optimization between Cn and MR? and is this will = improve the communication? thanks=20 wafaa=20 -------------------------------------------------------------------------= - =20 ------=_NextPart_000_000D_01C40B42.20386390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi There,
i'm just started to review the Nemo drafts, and i have and i=20 understood that after the MR move the big issue is the route = optimization=20 between Cn and Mnn if i'm not mistaken, my question is after MR = move to=20 new link and HA intercept packets for MR' HoA, is there will be = any route=20 optimization between Cn and MR? and is this will improve the=20 communication?
 
thanks
wafaa

------=_NextPart_000_000D_01C40B42.20386390-- From exim@www1.ietf.org Mon Mar 15 21:39:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16298 for ; Mon, 15 Mar 2004 21:39:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34Tf-0000dn-W9 for nemo-archive@odin.ietf.org; Mon, 15 Mar 2004 21:38:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G2cl1x002459 for nemo-archive@odin.ietf.org; Mon, 15 Mar 2004 21:38:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34Tf-0000da-Qf for nemo-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 21:38:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16280 for ; Mon, 15 Mar 2004 21:38:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B34Td-000130-00 for nemo-web-archive@ietf.org; Mon, 15 Mar 2004 21:38:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B34Sk-0000xB-00 for nemo-web-archive@ietf.org; Mon, 15 Mar 2004 21:37:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B34Rx-0000qE-00 for nemo-web-archive@ietf.org; Mon, 15 Mar 2004 21:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34Rx-0000Ea-3c; Mon, 15 Mar 2004 21:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34RQ-0000DU-6u for nemo@optimus.ietf.org; Mon, 15 Mar 2004 21:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16054 for ; Mon, 15 Mar 2004 21:36:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B34RN-0000nI-00 for nemo@ietf.org; Mon, 15 Mar 2004 21:36:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B34QM-0000iL-00 for nemo@ietf.org; Mon, 15 Mar 2004 21:35:23 -0500 Received: from netmon.cs.usm.my ([161.142.8.104] helo=network2.cs.usm.my) by ietf-mx with esmtp (Exim 4.12) id 1B34PV-0000b5-00 for nemo@ietf.org; Mon, 15 Mar 2004 21:34:30 -0500 Received: from wafaa (unknown [10.207.140.85]) by network2.cs.usm.my (Postfix) with SMTP id A5DB5F459 for ; Tue, 16 Mar 2004 10:33:48 +0800 (MYT) Message-ID: <001001c40aff$1225c560$558ccf0a@wafaa> From: "Wafaa Al-Salihy" To: Date: Tue, 16 Mar 2004 10:33:30 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C40B42.20386390" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [nemo] RO between Cn and MR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=CLICK_BELOW,HTML_50_60, HTML_IMAGE_ONLY_10,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C40B42.20386390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi There, i'm just started to review the Nemo drafts, and i have and i = understood that after the MR move the big issue is the route = optimization between Cn and Mnn if i'm not mistaken, my question is = after MR move to new link and HA intercept packets for MR' HoA, is there = will be any route optimization between Cn and MR? and is this will = improve the communication? thanks=20 wafaa=20 -------------------------------------------------------------------------= - =20 ------=_NextPart_000_000D_01C40B42.20386390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi There,
i'm just started to review the Nemo drafts, and i have and i=20 understood that after the MR move the big issue is the route = optimization=20 between Cn and Mnn if i'm not mistaken, my question is after MR = move to=20 new link and HA intercept packets for MR' HoA, is there will be = any route=20 optimization between Cn and MR? and is this will improve the=20 communication?
 
thanks
wafaa

------=_NextPart_000_000D_01C40B42.20386390-- From nemo-admin@ietf.org Mon Mar 15 22:16:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18627 for ; Mon, 15 Mar 2004 22:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B353h-00030e-PW; Mon, 15 Mar 2004 22:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3536-0002zJ-8C for nemo@optimus.ietf.org; Mon, 15 Mar 2004 22:15:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18539 for ; Mon, 15 Mar 2004 22:15:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3533-0004NP-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:15:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B352A-0004K7-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:14:27 -0500 Received: from netmon.cs.usm.my ([161.142.8.104] helo=network2.cs.usm.my) by ietf-mx with esmtp (Exim 4.12) id 1B351i-0004GS-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:14:05 -0500 Received: from wafaa (unknown [10.207.140.85]) by network2.cs.usm.my (Postfix) with SMTP id B9305F459 for ; Tue, 16 Mar 2004 11:13:28 +0800 (MYT) Message-ID: <002901c40b04$9d341f30$558ccf0a@wafaa> From: "Wafaa Al-Salihy" To: Date: Tue, 16 Mar 2004 11:13:11 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C40B47.AB52A440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,CLICK_BELOW,HTML_60_70, HTML_IMAGE_ONLY_06,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Subject: [nemo] Ro beteween Cn and MR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C40B47.AB52A440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, i'm still thinking about the RO between Cn and MR, if we have this = kind of RO so we don't have problem of HA routing packets to Mnn, it = will be from CN to MR and to Mnn if i'm not mistaken. wafaa=20 -------------------------------------------------------------------------= - =20 ------=_NextPart_000_0026_01C40B47.AB52A440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
i'm still thinking about the RO between Cn and MR, if we have = this=20 kind of RO so we don't have problem of HA routing packets to Mnn, = it will=20 be from CN to MR and to Mnn if i'm not mistaken.
 
 
 
wafaa

------=_NextPart_000_0026_01C40B47.AB52A440-- From exim@www1.ietf.org Mon Mar 15 22:28:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19037 for ; Mon, 15 Mar 2004 22:28:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B35Fn-0003ul-FU for nemo-archive@odin.ietf.org; Mon, 15 Mar 2004 22:28:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G3SVuE015042 for nemo-archive@odin.ietf.org; Mon, 15 Mar 2004 22:28:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B35Fn-0003uW-AM for nemo-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 22:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18867 for ; Mon, 15 Mar 2004 22:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B35Fj-0005N9-00 for nemo-web-archive@ietf.org; Mon, 15 Mar 2004 22:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B35DE-0004tZ-00 for nemo-web-archive@ietf.org; Mon, 15 Mar 2004 22:25:53 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B35CF-0004lk-04 for nemo-web-archive@ietf.org; Mon, 15 Mar 2004 22:24:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B353j-0007oD-Ew for nemo-web-archive@ietf.org; Mon, 15 Mar 2004 22:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B353h-00030e-PW; Mon, 15 Mar 2004 22:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3536-0002zJ-8C for nemo@optimus.ietf.org; Mon, 15 Mar 2004 22:15:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18539 for ; Mon, 15 Mar 2004 22:15:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3533-0004NP-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:15:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B352A-0004K7-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:14:27 -0500 Received: from netmon.cs.usm.my ([161.142.8.104] helo=network2.cs.usm.my) by ietf-mx with esmtp (Exim 4.12) id 1B351i-0004GS-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:14:05 -0500 Received: from wafaa (unknown [10.207.140.85]) by network2.cs.usm.my (Postfix) with SMTP id B9305F459 for ; Tue, 16 Mar 2004 11:13:28 +0800 (MYT) Message-ID: <002901c40b04$9d341f30$558ccf0a@wafaa> From: "Wafaa Al-Salihy" To: Date: Tue, 16 Mar 2004 11:13:11 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C40B47.AB52A440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [nemo] Ro beteween Cn and MR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,CLICK_BELOW,HTML_60_70, HTML_IMAGE_ONLY_06,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C40B47.AB52A440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, i'm still thinking about the RO between Cn and MR, if we have this = kind of RO so we don't have problem of HA routing packets to Mnn, it = will be from CN to MR and to Mnn if i'm not mistaken. wafaa=20 -------------------------------------------------------------------------= - =20 ------=_NextPart_000_0026_01C40B47.AB52A440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
i'm still thinking about the RO between Cn and MR, if we have = this=20 kind of RO so we don't have problem of HA routing packets to Mnn, = it will=20 be from CN to MR and to Mnn if i'm not mistaken.
 
 
 
wafaa

------=_NextPart_000_0026_01C40B47.AB52A440-- From nemo-admin@ietf.org Tue Mar 16 02:34:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14537 for ; Tue, 16 Mar 2004 02:34:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B395P-00012z-8u; Tue, 16 Mar 2004 02:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3956-00010e-PL for nemo@optimus.ietf.org; Tue, 16 Mar 2004 02:33:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14472 for ; Tue, 16 Mar 2004 02:33:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3953-0003je-00 for nemo@ietf.org; Tue, 16 Mar 2004 02:33:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B393z-0003eb-00 for nemo@ietf.org; Tue, 16 Mar 2004 02:32:36 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1B393Q-0003Y1-00 for nemo@ietf.org; Tue, 16 Mar 2004 02:32:01 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i2G7NF7X017577; Tue, 16 Mar 2004 15:23:15 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id F3E91B23B00; Tue, 16 Mar 2004 15:25:15 +0800 (SGT) Subject: Re: [nemo] Ro beteween Cn and MR From: Chan-Wah NG To: Wafaa Al-Salihy Cc: IETF NEMO WG In-Reply-To: <002901c40b04$9d341f30$558ccf0a@wafaa> References: <002901c40b04$9d341f30$558ccf0a@wafaa> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1079421915.6825.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 16 Mar 2004 15:25:15 +0800 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,CLICK_BELOW autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Wafaa, RO in NEMO has been explored into by a lot of people, and NEMO WG is chartered to do an analysis of such a RO solution. I suggest you take a look at draft-thubert-nemo-ro-taxonomy as a starting point. /rgds /cwng On Tue, 2004-03-16 at 11:13, Wafaa Al-Salihy wrote: > > Hi, > > i'm still thinking about the RO between Cn and MR, if we have this > kind of RO so we don't have problem of HA routing packets to Mnn, it > will be from CN to MR and to Mnn if i'm not mistaken. > > > > wafaa > > > ______________________________________________________________________ > Upgrade Your Email - Click here! > From exim@www1.ietf.org Tue Mar 16 02:36:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14861 for ; Tue, 16 Mar 2004 02:36:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3975-0001kT-B6 for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 02:35:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G7Zlgm006708 for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 02:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3974-0001jj-In for nemo-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 02:35:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14703 for ; Tue, 16 Mar 2004 02:35:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3970-0003v5-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 02:35:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3965-0003qn-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 02:34:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B395O-0003ln-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 02:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B395P-00012z-8u; Tue, 16 Mar 2004 02:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3956-00010e-PL for nemo@optimus.ietf.org; Tue, 16 Mar 2004 02:33:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14472 for ; Tue, 16 Mar 2004 02:33:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3953-0003je-00 for nemo@ietf.org; Tue, 16 Mar 2004 02:33:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B393z-0003eb-00 for nemo@ietf.org; Tue, 16 Mar 2004 02:32:36 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1B393Q-0003Y1-00 for nemo@ietf.org; Tue, 16 Mar 2004 02:32:01 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i2G7NF7X017577; Tue, 16 Mar 2004 15:23:15 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id F3E91B23B00; Tue, 16 Mar 2004 15:25:15 +0800 (SGT) Subject: Re: [nemo] Ro beteween Cn and MR From: Chan-Wah NG To: Wafaa Al-Salihy Cc: IETF NEMO WG In-Reply-To: <002901c40b04$9d341f30$558ccf0a@wafaa> References: <002901c40b04$9d341f30$558ccf0a@wafaa> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1079421915.6825.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 16 Mar 2004 15:25:15 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,CLICK_BELOW autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Wafaa, RO in NEMO has been explored into by a lot of people, and NEMO WG is chartered to do an analysis of such a RO solution. I suggest you take a look at draft-thubert-nemo-ro-taxonomy as a starting point. /rgds /cwng On Tue, 2004-03-16 at 11:13, Wafaa Al-Salihy wrote: > > Hi, > > i'm still thinking about the RO between Cn and MR, if we have this > kind of RO so we don't have problem of HA routing packets to Mnn, it > will be from CN to MR and to Mnn if i'm not mistaken. > > > > wafaa > > > ______________________________________________________________________ > Upgrade Your Email - Click here! > From nemo-admin@ietf.org Tue Mar 16 02:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16365 for ; Tue, 16 Mar 2004 02:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39TZ-0003uJ-7I; Tue, 16 Mar 2004 02:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34qQ-0001qD-4C for nemo@optimus.ietf.org; Mon, 15 Mar 2004 22:02:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17406 for ; Mon, 15 Mar 2004 22:02:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B34qN-0002rd-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:02:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B34pQ-0002mi-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:01:17 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B34oW-0002Zk-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:00:21 -0500 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id CC2265D119; Tue, 16 Mar 2004 11:59:49 +0900 (JST) Date: Tue, 16 Mar 2004 11:58:57 +0900 (JST) Message-Id: <20040316.115857.116415696.watari@sfc.wide.ad.jp> To: wafaa@network2.cs.usm.my Cc: nemo@ietf.org Subject: Re: [nemo] RO between Cn and MR From: Masafumi Watari In-Reply-To: <001001c40aff$1225c560$558ccf0a@wafaa> References: <001001c40aff$1225c560$558ccf0a@wafaa> Organization: Keio University X-Mailer: Mew version 4.0.65 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, You might want to take look at the Taxonomy draft and the WG charter, if you haven't already. Whether it improve the communication or not depend on the topology and the environment. watari On Tue, 16 Mar 2004 10:33:30 +0800, "Wafaa Al-Salihy" wrote: > > > Hi There, > i'm just started to review the Nemo drafts, and i have and i understood that after the MR move the big issue is the route optimization between Cn and Mnn if i'm not mistaken, my question is after MR move to new link and HA intercept packets for MR' HoA, is there will be any route optimization between Cn and MR? and is this will improve the communication? > > thanks > wafaa > > > -------------------------------------------------------------------------- > > From exim@www1.ietf.org Tue Mar 16 03:01:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16574 for ; Tue, 16 Mar 2004 03:01:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39VU-00045o-5n for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 03:01:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G810Q5015732 for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 03:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39VT-00045f-Ta for nemo-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 03:00:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16550 for ; Tue, 16 Mar 2004 03:00:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B39VQ-0006W0-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 03:00:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B39UZ-0006O7-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 03:00:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B39TY-0006GA-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 02:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B39TZ-0003uJ-7I; Tue, 16 Mar 2004 02:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34qQ-0001qD-4C for nemo@optimus.ietf.org; Mon, 15 Mar 2004 22:02:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17406 for ; Mon, 15 Mar 2004 22:02:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B34qN-0002rd-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:02:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B34pQ-0002mi-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:01:17 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B34oW-0002Zk-00 for nemo@ietf.org; Mon, 15 Mar 2004 22:00:21 -0500 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id CC2265D119; Tue, 16 Mar 2004 11:59:49 +0900 (JST) Date: Tue, 16 Mar 2004 11:58:57 +0900 (JST) Message-Id: <20040316.115857.116415696.watari@sfc.wide.ad.jp> To: wafaa@network2.cs.usm.my Cc: nemo@ietf.org Subject: Re: [nemo] RO between Cn and MR From: Masafumi Watari In-Reply-To: <001001c40aff$1225c560$558ccf0a@wafaa> References: <001001c40aff$1225c560$558ccf0a@wafaa> Organization: Keio University X-Mailer: Mew version 4.0.65 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, You might want to take look at the Taxonomy draft and the WG charter, if you haven't already. Whether it improve the communication or not depend on the topology and the environment. watari On Tue, 16 Mar 2004 10:33:30 +0800, "Wafaa Al-Salihy" wrote: > > > Hi There, > i'm just started to review the Nemo drafts, and i have and i understood that after the MR move the big issue is the route optimization between Cn and Mnn if i'm not mistaken, my question is after MR move to new link and HA intercept packets for MR' HoA, is there will be any route optimization between Cn and MR? and is this will improve the communication? > > thanks > wafaa > > > -------------------------------------------------------------------------- > > From nemo-admin@ietf.org Tue Mar 16 05:10:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21964 for ; Tue, 16 Mar 2004 05:10:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3BWQ-0006x0-E8; Tue, 16 Mar 2004 05:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3BVy-0006ti-OS for nemo@optimus.ietf.org; Tue, 16 Mar 2004 05:09:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21928 for ; Tue, 16 Mar 2004 05:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3BVv-0001nv-00 for nemo@ietf.org; Tue, 16 Mar 2004 05:09:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3BV7-0001kC-00 for nemo@ietf.org; Tue, 16 Mar 2004 05:08:46 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3BU8-0001bo-00 for nemo@ietf.org; Tue, 16 Mar 2004 05:07:44 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2004 02:11:47 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GA5qij008958 for ; Tue, 16 Mar 2004 11:06:44 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Mar 2004 10:06:44 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [nemo] Ro beteween Cn and MR Date: Tue, 16 Mar 2004 10:06:44 -0000 Message-ID: Thread-Topic: [nemo] Ro beteween Cn and MR Thread-Index: AcQLBRHwLoyKrozrQlmeYRRdsWp1hgAIkf/wAAWUA0A= From: "Pascal Thubert \(pthubert\)" To: "IETF NEMO WG" X-OriginalArrivalTime: 16 Mar 2004 10:06:44.0674 (UTC) FILETIME=[62CDAA20:01C40B3E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Wafaa 1) It would be nice if you could stick to plain text... 2) There's a lot to say about RO in the infrastructure. Please have a look at http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.tx t The RO you are talking about may take several forms: - a better selection of HA so that the triangle (CN-HA-MR) surface is limited (HAHA protocol) - MR-CR tunnel, CR being a Correspondent Router - MR-CN though I doubt it since this is about routes to MNPs - MNN-CN, if Nemo is extended to MNNs. The RRH draft has an example of that: see A.1 Path Optimization with RRH in: http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-04.txt I hope this helps :) Pascal -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Wafaa Al-Salihy Sent: mardi 16 mars 2004 04:13 To: nemo@ietf.org Subject: [nemo] Ro beteween Cn and MR Hi, i'm still thinking about the RO between Cn and MR, if we have this kind of RO so we don't have problem of HA routing packets to Mnn, it will be from CN to MR and to Mnn if i'm not mistaken. wafaa From exim@www1.ietf.org Tue Mar 16 05:12:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22025 for ; Tue, 16 Mar 2004 05:12:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3BY0-0007A9-J8 for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 05:11:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GABhkr027512 for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 05:11:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3BXw-00079U-Bd for nemo-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 05:11:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22015 for ; Tue, 16 Mar 2004 05:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3BXt-0001xQ-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 05:11:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3BX3-0001tY-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 05:10:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3BWU-0001pN-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 05:10:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3BWQ-0006x0-E8; Tue, 16 Mar 2004 05:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3BVy-0006ti-OS for nemo@optimus.ietf.org; Tue, 16 Mar 2004 05:09:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21928 for ; Tue, 16 Mar 2004 05:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3BVv-0001nv-00 for nemo@ietf.org; Tue, 16 Mar 2004 05:09:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3BV7-0001kC-00 for nemo@ietf.org; Tue, 16 Mar 2004 05:08:46 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3BU8-0001bo-00 for nemo@ietf.org; Tue, 16 Mar 2004 05:07:44 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2004 02:11:47 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2GA5qij008958 for ; Tue, 16 Mar 2004 11:06:44 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Mar 2004 10:06:44 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [nemo] Ro beteween Cn and MR Date: Tue, 16 Mar 2004 10:06:44 -0000 Message-ID: Thread-Topic: [nemo] Ro beteween Cn and MR Thread-Index: AcQLBRHwLoyKrozrQlmeYRRdsWp1hgAIkf/wAAWUA0A= From: "Pascal Thubert \(pthubert\)" To: "IETF NEMO WG" X-OriginalArrivalTime: 16 Mar 2004 10:06:44.0674 (UTC) FILETIME=[62CDAA20:01C40B3E] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Wafaa 1) It would be nice if you could stick to plain text... 2) There's a lot to say about RO in the infrastructure. Please have a look at http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.tx t The RO you are talking about may take several forms: - a better selection of HA so that the triangle (CN-HA-MR) surface is limited (HAHA protocol) - MR-CR tunnel, CR being a Correspondent Router - MR-CN though I doubt it since this is about routes to MNPs - MNN-CN, if Nemo is extended to MNNs. The RRH draft has an example of that: see A.1 Path Optimization with RRH in: http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-04.txt I hope this helps :) Pascal -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Wafaa Al-Salihy Sent: mardi 16 mars 2004 04:13 To: nemo@ietf.org Subject: [nemo] Ro beteween Cn and MR Hi, i'm still thinking about the RO between Cn and MR, if we have this kind of RO so we don't have problem of HA routing packets to Mnn, it will be from CN to MR and to Mnn if i'm not mistaken. wafaa From nemo-admin@ietf.org Tue Mar 16 09:42:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03097 for ; Tue, 16 Mar 2004 09:42:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FlZ-00067i-EN; Tue, 16 Mar 2004 09:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FlE-00067O-FD for nemo@optimus.ietf.org; Tue, 16 Mar 2004 09:41:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03070 for ; Tue, 16 Mar 2004 09:41:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FlC-0001AG-00 for nemo@ietf.org; Tue, 16 Mar 2004 09:41:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FkE-00016E-00 for nemo@ietf.org; Tue, 16 Mar 2004 09:40:39 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B3FjI-0000zN-00 for nemo@ietf.org; Tue, 16 Mar 2004 09:39:41 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUO00901BD3ML@mailout1.samsung.com> for nemo@ietf.org; Tue, 16 Mar 2004 23:39:03 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUO005BZBD29U@mailout1.samsung.com> for nemo@ietf.org; Tue, 16 Mar 2004 23:39:02 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUO008RSBD0XN@mmp1.samsung.com> for nemo@ietf.org; Tue, 16 Mar 2004 23:39:02 +0900 (KST) Date: Tue, 16 Mar 2004 20:04:50 +0530 From: "O.L.N.Rao" To: nemo@ietf.org Message-id: <025601c40b63$d7fa27e0$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: multipart/alternative; boundary="Boundary_(ID_aDxAo0aTkUdciRFkUU9VJg)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Subject: [nemo] Any Implementations to Test Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_aDxAo0aTkUdciRFkUU9VJg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi All, Recently i have gone through the NEMO Basic Support protocol and it is very much interesting to me. I really wanted to see the scenarios in working. Are there any open implementations available for me to go with ? I would be very thankful for the pointers in this regard. Thanks in advance. Regards, O.L.N.Rao --Boundary_(ID_aDxAo0aTkUdciRFkUU9VJg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi All,
 
    Recently i have gone through the NEMO Basic Support protocol
    and it is very much interesting to me.  I really wanted to see the
    scenarios in working. 
 
    Are there any open implementations available for me to go with ?
   
    I would be very thankful for the pointers in this regard.
 
    Thanks in advance.
 
Regards,
O.L.N.Rao
 
--Boundary_(ID_aDxAo0aTkUdciRFkUU9VJg)-- From exim@www1.ietf.org Tue Mar 16 09:44:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03196 for ; Tue, 16 Mar 2004 09:44:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FnD-0006Iz-Gv for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 09:43:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GEhhVH024233 for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 09:43:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FnD-0006Im-5u for nemo-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 09:43:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03178 for ; Tue, 16 Mar 2004 09:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FnB-0001NA-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 09:43:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FmG-0001F6-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 09:42:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Fla-0001BS-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 09:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FlZ-00067i-EN; Tue, 16 Mar 2004 09:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FlE-00067O-FD for nemo@optimus.ietf.org; Tue, 16 Mar 2004 09:41:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03070 for ; Tue, 16 Mar 2004 09:41:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FlC-0001AG-00 for nemo@ietf.org; Tue, 16 Mar 2004 09:41:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FkE-00016E-00 for nemo@ietf.org; Tue, 16 Mar 2004 09:40:39 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B3FjI-0000zN-00 for nemo@ietf.org; Tue, 16 Mar 2004 09:39:41 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUO00901BD3ML@mailout1.samsung.com> for nemo@ietf.org; Tue, 16 Mar 2004 23:39:03 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUO005BZBD29U@mailout1.samsung.com> for nemo@ietf.org; Tue, 16 Mar 2004 23:39:02 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUO008RSBD0XN@mmp1.samsung.com> for nemo@ietf.org; Tue, 16 Mar 2004 23:39:02 +0900 (KST) Date: Tue, 16 Mar 2004 20:04:50 +0530 From: "O.L.N.Rao" To: nemo@ietf.org Message-id: <025601c40b63$d7fa27e0$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: multipart/alternative; boundary="Boundary_(ID_aDxAo0aTkUdciRFkUU9VJg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [nemo] Any Implementations to Test Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_aDxAo0aTkUdciRFkUU9VJg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi All, Recently i have gone through the NEMO Basic Support protocol and it is very much interesting to me. I really wanted to see the scenarios in working. Are there any open implementations available for me to go with ? I would be very thankful for the pointers in this regard. Thanks in advance. Regards, O.L.N.Rao --Boundary_(ID_aDxAo0aTkUdciRFkUU9VJg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi All,
 
    Recently i have gone through the NEMO Basic Support protocol
    and it is very much interesting to me.  I really wanted to see the
    scenarios in working. 
 
    Are there any open implementations available for me to go with ?
   
    I would be very thankful for the pointers in this regard.
 
    Thanks in advance.
 
Regards,
O.L.N.Rao
 
--Boundary_(ID_aDxAo0aTkUdciRFkUU9VJg)-- From nemo-admin@ietf.org Tue Mar 16 13:16:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14791 for ; Tue, 16 Mar 2004 13:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J6f-0006UF-Et; Tue, 16 Mar 2004 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J6V-0006TC-Gr for nemo@optimus.ietf.org; Tue, 16 Mar 2004 13:15:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14689 for ; Tue, 16 Mar 2004 13:15:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3J6T-0006dQ-00 for nemo@ietf.org; Tue, 16 Mar 2004 13:15:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3J5X-0006Ww-00 for nemo@ietf.org; Tue, 16 Mar 2004 13:14:51 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1B3J4e-0006QT-00 for nemo@ietf.org; Tue, 16 Mar 2004 13:13:56 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i2GIAUBI000425; Tue, 16 Mar 2004 11:10:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2GICxMg022296; Tue, 16 Mar 2004 12:13:01 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 42E2185552F; Tue, 16 Mar 2004 19:13:47 +0100 (CET) Message-ID: <405743DA.9070700@motorola.com> Date: Tue, 16 Mar 2004 19:13:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: IETF NEMO WG Subject: Re: FW: [nemo] Ro beteween CN and MR References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000905090408070708050604" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms000905090408070708050604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > 2) There's a lot to say about RO in the infrastructure. Please have a > look at > http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.tx > t Yes, I think one of the first things to be said about RO in the infrastructure is that it's called "routing" and that is often unstable because of link failures and we don't want even more instability due to mobility. And only then comes RO into picture. > - a better selection of HA so that the triangle (CN-HA-MR) surface is > limited (HAHA protocol) - MR-CR tunnel, CR being a Correspondent > Router The term CR might look new, but it is not, and there is the ORC paper and the BPA paper/report. (Optimized Route Cache and Binding Proxy Agent) to get an idea about what it is about. > - MR-CN though I doubt it since this is about routes to MNPs Depends, it is possible to have CN do RR tests for the Home Address of an LFN and MR's CoA (the LFN that actually talks to that CN); it is not absolutely necessary to have MR trying to convince CN about the entire MNP, at least I don't see why. > - MNN-CN, if Nemo is extended to MNNs. The RRH draft has an example > of that: see A.1 Path Optimization with RRH in: > http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h > eader-04.txt Yes, that's another way. Alex --------------ms000905090408070708050604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA/MwggNcoAMCAQICAwp9BjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwNjEwMDU0M1oX DTA0MDgwNTEwMDU0M1owgdkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIDAe BgkqhkiG9w0BCQEWEXBldHJlc2N1QGllZWUub3JnMR8wHQYJKoZIhvcNAQkBFhBwZXRyZXNj dUBhY20ub3JnMSIwIAYJKoZIhvcNAQkBFhNwZXRyZXNjdUBhbHRlcm4ub3JnMR8wHQYJKoZI hvcNAQkBFhBwZXRyZXNjdUBmcmVlLmZyMS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0 cmVzY3VAbW90b3JvbGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9GSD rMCK1KspPruK+tgZspBkqVT5ScPS1CEgOr2MVSvbWP+GbZxYK8k87/y5vJ40OifBr9m56Hio zk7pmqffAEGSGy9ettQD9xocBQkA7bJFRLeOCdM6UXqjmwPstIBao0wQkOJTo39MliRGrS3a YUpA6/s7FtuhzPFLd7B4UV3e6fqNVWQvptNHCndWDv9o4EDcntzj7f3EHlHSl+hHukBSoDlL s02b+az8n47tq4nIyfOYMvF2EmOACFGJGWJ7hDz9SmjqEzNgSjUD68rOdBMcs2yRX8hSFuJE vqSTAJ69AMy7GGWaA326mxD4mu53fniPFOfFd6BuFnIGne0KCwIDAQABo4GJMIGGMHYGA1Ud EQRvMG2BEXBldHJlc2N1QGllZWUub3JngRBwZXRyZXNjdUBhY20ub3JngRNwZXRyZXNjdUBh bHRlcm4ub3JngRBwZXRyZXNjdUBmcmVlLmZygR9hbGV4YW5kcnUucGV0cmVzY3VAbW90b3Jv bGEuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAzh0dPi0yv2hYyuqjEbzM UgbSqTG/sdV1NblLLiZUxaNHtY3+dPOI8NduSvxPqGHhCd494vJQEa1MmUceKDMpmAod68SQ rocYRY95k8crU/47zpbkar3P56OgW6NbARhBhHkqGemB5b2q+zGZJresGpz2W/LZ+2hX8DvU HQgvgywwggPzMIIDXKADAgECAgMKfQYwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29u YWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA4MDYxMDA1NDNaFw0wNDA4MDUxMDA1 NDNaMIHZMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSAwHgYJKoZIhvcNAQkB FhFwZXRyZXNjdUBpZWVlLm9yZzEfMB0GCSqGSIb3DQEJARYQcGV0cmVzY3VAYWNtLm9yZzEi MCAGCSqGSIb3DQEJARYTcGV0cmVzY3VAYWx0ZXJuLm9yZzEfMB0GCSqGSIb3DQEJARYQcGV0 cmVzY3VAZnJlZS5mcjEuMCwGCSqGSIb3DQEJARYfYWxleGFuZHJ1LnBldHJlc2N1QG1vdG9y b2xhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPRkg6zAitSrKT67ivrY GbKQZKlU+UnD0tQhIDq9jFUr21j/hm2cWCvJPO/8ubyeNDonwa/Zueh4qM5O6Zqn3wBBkhsv XrbUA/caHAUJAO2yRUS3jgnTOlF6o5sD7LSAWqNMEJDiU6N/TJYkRq0t2mFKQOv7Oxbboczx S3eweFFd3un6jVVkL6bTRwp3Vg7/aOBA3J7c4+39xB5R0pfoR7pAUqA5S7NNm/ms/J+O7auJ yMnzmDLxdhJjgAhRiRlie4Q8/Upo6hMzYEo1A+vKznQTHLNskV/IUhbiRL6kkwCevQDMuxhl mgN9upsQ+Jrud354jxTnxXegbhZyBp3tCgsCAwEAAaOBiTCBhjB2BgNVHREEbzBtgRFwZXRy ZXNjdUBpZWVlLm9yZ4EQcGV0cmVzY3VAYWNtLm9yZ4ETcGV0cmVzY3VAYWx0ZXJuLm9yZ4EQ cGV0cmVzY3VAZnJlZS5mcoEfYWxleGFuZHJ1LnBldHJlc2N1QG1vdG9yb2xhLmNvbTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAM4dHT4tMr9oWMrqoxG8zFIG0qkxv7HVdTW5 Sy4mVMWjR7WN/nTziPDXbkr8T6hh4QnePeLyUBGtTJlHHigzKZgKHevEkK6HGEWPeZPHK1P+ O86W5Gq9z+ejoFujWwEYQYR5KhnpgeW9qvsxmSa3rBqc9lvy2ftoV/A71B0IL4MsMYID1TCC A9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCn0G MAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA0MDMxNjE4MTM0NlowIwYJKoZIhvcNAQkEMRYEFDy7c26WxjsKLTmKYst85+2GIgNs MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCn0GMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMK fQYwDQYJKoZIhvcNAQEBBQAEggEAwgsygE4n1+pGiNsqgIq0mfOjC0I2UNWThmAHXJktzVXI 4wnPUspGD4WVNwgeNkwqDDa8f00tGthiat8sZ9Qq2ImNPRkJ3wsfSphOmSteXSm3AUUYTlb9 d+Js9qFEjpEI8Mp47gbKP3WUJlm3sa06fJOEZM46QhVnZT/5F2r3tNYoNlGgJPyTpWzfIL4m Pfjc2lOdpgyC7GSr/Vi+yObXpK6uaF53GELyAAST2F5X5crID1U2c3unzyTIUth5wGz53b0r J6b3HuJ7v8y1PodVit59GF5zbkjkHToLyFUTFxQXvOiiTh9EDogPobnMMejwD4ZMLjvbmw06 Bzyj/AWkUAAAAAAAAA== --------------ms000905090408070708050604-- From exim@www1.ietf.org Tue Mar 16 13:18:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14952 for ; Tue, 16 Mar 2004 13:18:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J8P-0006et-4H for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 13:17:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GIHnQj025591 for nemo-archive@odin.ietf.org; Tue, 16 Mar 2004 13:17:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J8O-0006ee-Up for nemo-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 13:17:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14926 for ; Tue, 16 Mar 2004 13:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3J8N-0006ok-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 13:17:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3J7W-0006kV-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 13:16:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3J6i-0006fZ-00 for nemo-web-archive@ietf.org; Tue, 16 Mar 2004 13:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J6f-0006UF-Et; Tue, 16 Mar 2004 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J6V-0006TC-Gr for nemo@optimus.ietf.org; Tue, 16 Mar 2004 13:15:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14689 for ; Tue, 16 Mar 2004 13:15:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3J6T-0006dQ-00 for nemo@ietf.org; Tue, 16 Mar 2004 13:15:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3J5X-0006Ww-00 for nemo@ietf.org; Tue, 16 Mar 2004 13:14:51 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1B3J4e-0006QT-00 for nemo@ietf.org; Tue, 16 Mar 2004 13:13:56 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i2GIAUBI000425; Tue, 16 Mar 2004 11:10:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2GICxMg022296; Tue, 16 Mar 2004 12:13:01 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 42E2185552F; Tue, 16 Mar 2004 19:13:47 +0100 (CET) Message-ID: <405743DA.9070700@motorola.com> Date: Tue, 16 Mar 2004 19:13:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: IETF NEMO WG Subject: Re: FW: [nemo] Ro beteween CN and MR References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000905090408070708050604" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms000905090408070708050604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > 2) There's a lot to say about RO in the infrastructure. Please have a > look at > http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.tx > t Yes, I think one of the first things to be said about RO in the infrastructure is that it's called "routing" and that is often unstable because of link failures and we don't want even more instability due to mobility. And only then comes RO into picture. > - a better selection of HA so that the triangle (CN-HA-MR) surface is > limited (HAHA protocol) - MR-CR tunnel, CR being a Correspondent > Router The term CR might look new, but it is not, and there is the ORC paper and the BPA paper/report. (Optimized Route Cache and Binding Proxy Agent) to get an idea about what it is about. > - MR-CN though I doubt it since this is about routes to MNPs Depends, it is possible to have CN do RR tests for the Home Address of an LFN and MR's CoA (the LFN that actually talks to that CN); it is not absolutely necessary to have MR trying to convince CN about the entire MNP, at least I don't see why. > - MNN-CN, if Nemo is extended to MNNs. The RRH draft has an example > of that: see A.1 Path Optimization with RRH in: > http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h > eader-04.txt Yes, that's another way. Alex --------------ms000905090408070708050604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA/MwggNcoAMCAQICAwp9BjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwNjEwMDU0M1oX DTA0MDgwNTEwMDU0M1owgdkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIDAe BgkqhkiG9w0BCQEWEXBldHJlc2N1QGllZWUub3JnMR8wHQYJKoZIhvcNAQkBFhBwZXRyZXNj dUBhY20ub3JnMSIwIAYJKoZIhvcNAQkBFhNwZXRyZXNjdUBhbHRlcm4ub3JnMR8wHQYJKoZI hvcNAQkBFhBwZXRyZXNjdUBmcmVlLmZyMS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0 cmVzY3VAbW90b3JvbGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9GSD rMCK1KspPruK+tgZspBkqVT5ScPS1CEgOr2MVSvbWP+GbZxYK8k87/y5vJ40OifBr9m56Hio zk7pmqffAEGSGy9ettQD9xocBQkA7bJFRLeOCdM6UXqjmwPstIBao0wQkOJTo39MliRGrS3a YUpA6/s7FtuhzPFLd7B4UV3e6fqNVWQvptNHCndWDv9o4EDcntzj7f3EHlHSl+hHukBSoDlL s02b+az8n47tq4nIyfOYMvF2EmOACFGJGWJ7hDz9SmjqEzNgSjUD68rOdBMcs2yRX8hSFuJE vqSTAJ69AMy7GGWaA326mxD4mu53fniPFOfFd6BuFnIGne0KCwIDAQABo4GJMIGGMHYGA1Ud EQRvMG2BEXBldHJlc2N1QGllZWUub3JngRBwZXRyZXNjdUBhY20ub3JngRNwZXRyZXNjdUBh bHRlcm4ub3JngRBwZXRyZXNjdUBmcmVlLmZygR9hbGV4YW5kcnUucGV0cmVzY3VAbW90b3Jv bGEuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAzh0dPi0yv2hYyuqjEbzM UgbSqTG/sdV1NblLLiZUxaNHtY3+dPOI8NduSvxPqGHhCd494vJQEa1MmUceKDMpmAod68SQ rocYRY95k8crU/47zpbkar3P56OgW6NbARhBhHkqGemB5b2q+zGZJresGpz2W/LZ+2hX8DvU HQgvgywwggPzMIIDXKADAgECAgMKfQYwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29u YWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA4MDYxMDA1NDNaFw0wNDA4MDUxMDA1 NDNaMIHZMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSAwHgYJKoZIhvcNAQkB FhFwZXRyZXNjdUBpZWVlLm9yZzEfMB0GCSqGSIb3DQEJARYQcGV0cmVzY3VAYWNtLm9yZzEi MCAGCSqGSIb3DQEJARYTcGV0cmVzY3VAYWx0ZXJuLm9yZzEfMB0GCSqGSIb3DQEJARYQcGV0 cmVzY3VAZnJlZS5mcjEuMCwGCSqGSIb3DQEJARYfYWxleGFuZHJ1LnBldHJlc2N1QG1vdG9y b2xhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPRkg6zAitSrKT67ivrY GbKQZKlU+UnD0tQhIDq9jFUr21j/hm2cWCvJPO/8ubyeNDonwa/Zueh4qM5O6Zqn3wBBkhsv XrbUA/caHAUJAO2yRUS3jgnTOlF6o5sD7LSAWqNMEJDiU6N/TJYkRq0t2mFKQOv7Oxbboczx S3eweFFd3un6jVVkL6bTRwp3Vg7/aOBA3J7c4+39xB5R0pfoR7pAUqA5S7NNm/ms/J+O7auJ yMnzmDLxdhJjgAhRiRlie4Q8/Upo6hMzYEo1A+vKznQTHLNskV/IUhbiRL6kkwCevQDMuxhl mgN9upsQ+Jrud354jxTnxXegbhZyBp3tCgsCAwEAAaOBiTCBhjB2BgNVHREEbzBtgRFwZXRy ZXNjdUBpZWVlLm9yZ4EQcGV0cmVzY3VAYWNtLm9yZ4ETcGV0cmVzY3VAYWx0ZXJuLm9yZ4EQ cGV0cmVzY3VAZnJlZS5mcoEfYWxleGFuZHJ1LnBldHJlc2N1QG1vdG9yb2xhLmNvbTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAM4dHT4tMr9oWMrqoxG8zFIG0qkxv7HVdTW5 Sy4mVMWjR7WN/nTziPDXbkr8T6hh4QnePeLyUBGtTJlHHigzKZgKHevEkK6HGEWPeZPHK1P+ O86W5Gq9z+ejoFujWwEYQYR5KhnpgeW9qvsxmSa3rBqc9lvy2ftoV/A71B0IL4MsMYID1TCC A9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCn0G MAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA0MDMxNjE4MTM0NlowIwYJKoZIhvcNAQkEMRYEFDy7c26WxjsKLTmKYst85+2GIgNs MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCn0GMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMK fQYwDQYJKoZIhvcNAQEBBQAEggEAwgsygE4n1+pGiNsqgIq0mfOjC0I2UNWThmAHXJktzVXI 4wnPUspGD4WVNwgeNkwqDDa8f00tGthiat8sZ9Qq2ImNPRkJ3wsfSphOmSteXSm3AUUYTlb9 d+Js9qFEjpEI8Mp47gbKP3WUJlm3sa06fJOEZM46QhVnZT/5F2r3tNYoNlGgJPyTpWzfIL4m Pfjc2lOdpgyC7GSr/Vi+yObXpK6uaF53GELyAAST2F5X5crID1U2c3unzyTIUth5wGz53b0r J6b3HuJ7v8y1PodVit59GF5zbkjkHToLyFUTFxQXvOiiTh9EDogPobnMMejwD4ZMLjvbmw06 Bzyj/AWkUAAAAAAAAA== --------------ms000905090408070708050604-- From nemo-admin@ietf.org Wed Mar 17 05:27:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29118 for ; Wed, 17 Mar 2004 05:27:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3YGL-0007HI-80; Wed, 17 Mar 2004 05:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3YFn-0007Fk-4K for nemo@optimus.ietf.org; Wed, 17 Mar 2004 05:26:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29076 for ; Wed, 17 Mar 2004 05:26:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3YFj-0006K8-00 for nemo@ietf.org; Wed, 17 Mar 2004 05:26:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3YEl-0006DE-00 for nemo@ietf.org; Wed, 17 Mar 2004 05:25:23 -0500 Received: from ipoutme5.wanadoo.fr ([193.252.22.21] helo=mwinf1002.wanadoo.fr) by ietf-mx with esmtp (Exim 4.12) id 1B3YDq-00060z-00 for nemo@ietf.org; Wed, 17 Mar 2004 05:24:26 -0500 Received: from wwinf1001 (wwinf1001 [172.22.141.28]) by mwinf1002.wanadoo.fr (SMTP Server) with ESMTP id 8CC061C00117 for ; Wed, 17 Mar 2004 11:23:55 +0100 (CET) Message-ID: <4225881.1079519035562.JavaMail.www@wwinf1001> From: Ines BEN HAMIDA Reply-To: ines.ben-hamida@wanadoo.fr To: nemo@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Date: Wed, 17 Mar 2004 11:23:55 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] resource reservation for NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I'm interested by resource reservation for NEMO (how an MR can reserve badwidth in wireless network for all the mobile network). For me, since the MR does the reservation for all the MNN behind it, there is no difference between NEMO and a mobile host in resource reservation. Can some one give me any help or any useful documentation about this subject? thank you Ines From nemo-admin@ietf.org Wed Mar 17 07:39:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03587 for ; Wed, 17 Mar 2004 07:39:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aK7-0006I9-8l; Wed, 17 Mar 2004 07:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aJa-0006D4-6Z for nemo@optimus.ietf.org; Wed, 17 Mar 2004 07:38:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03543 for ; Wed, 17 Mar 2004 07:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aJZ-00063Z-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aIl-0005xl-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:37:40 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3aIF-0005pn-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:37:07 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 04:41:27 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HCa0id029452 for ; Wed, 17 Mar 2004 13:36:03 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 12:36:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2004 12:36:32 -0000 Message-ID: Thread-Topic: Multiple DRs on a link Thread-Index: AcQL+mkjDFOUdM3bRvC2mwMiI5TrrQAANHuQAAgt2pA= From: "Pascal Thubert \(pthubert\)" To: "IETF NEMO WG" X-OriginalArrivalTime: 17 Mar 2004 12:36:32.0767 (UTC) FILETIME=[7A8990F0:01C40C1C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] FW: Multiple DRs on a link Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: This discussion happened at IPV6 WG, I thought it was relevant to copy Nemo... Pascal > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: mercredi 17 mars 2004 09:38 > To: Pascal Thubert (pthubert); Jari Arkko > Cc: ipv6@ietf.org > Subject: RE: Multiple DRs on a link >=20 >=20 > > > =3D> There are many different reasons. I sent a verly long > > > email about this to nemo (monet back then). One simple > > > scenario is that you might be walking around with a PAN > > > that happens to have 2 MRs on a single link (e.g. a laptop > > > and a mobile phone). The two MRs could share the same ingress > > > link and have different egress links. For instance your laptop > > > might have a WLAN card and your mobile might have a cellular > > > interface. Once you walk into an airport lounge or starbucks > > > you'll suddenly have a multihomed PAN. By definition, each MR > > > must have a separate home prefix. So each will advertise > > > a different prefix on the ingress side. > > > > Hi Hesham: > > > > I fail to understand the "by definition" here. Nemo does not > > prevent 2 > > different MRs from registering the same MNP. It's like > > multiple parallel > > routes. What's not duplicated is the Home address... In > > fact, I proposed > > a test to check that both registrations actually end up in a > > same link, > > otherwise there's a problem equivalent to the DAD problem in > > MIP6. Not > > much success on that proposal, though >=20 > =3D> Hmm, that's interesting. I must have missed that in the > spec. So, my concern is similar to yours, how does the HA > check whether the MRs are in the same place?? Seems like > a dangerous feature to have. I'm surprised this wasn't discussed > during LC. >=20 > Hesham From exim@www1.ietf.org Wed Mar 17 07:41:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03669 for ; Wed, 17 Mar 2004 07:41:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aLa-0006TT-3a for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 07:40:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HCeYPA024881 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 07:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aLZ-0006TE-VC for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 07:40:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03643 for ; Wed, 17 Mar 2004 07:40:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aLZ-0006HS-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:40:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aKa-0006B3-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:39:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3aKH-00064g-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:39:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aK7-0006I9-8l; Wed, 17 Mar 2004 07:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aJa-0006D4-6Z for nemo@optimus.ietf.org; Wed, 17 Mar 2004 07:38:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03543 for ; Wed, 17 Mar 2004 07:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aJZ-00063Z-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aIl-0005xl-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:37:40 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3aIF-0005pn-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:37:07 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 04:41:27 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HCa0id029452 for ; Wed, 17 Mar 2004 13:36:03 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 12:36:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2004 12:36:32 -0000 Message-ID: Thread-Topic: Multiple DRs on a link Thread-Index: AcQL+mkjDFOUdM3bRvC2mwMiI5TrrQAANHuQAAgt2pA= From: "Pascal Thubert \(pthubert\)" To: "IETF NEMO WG" X-OriginalArrivalTime: 17 Mar 2004 12:36:32.0767 (UTC) FILETIME=[7A8990F0:01C40C1C] Content-Transfer-Encoding: quoted-printable Subject: [nemo] FW: Multiple DRs on a link Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi: This discussion happened at IPV6 WG, I thought it was relevant to copy Nemo... Pascal > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: mercredi 17 mars 2004 09:38 > To: Pascal Thubert (pthubert); Jari Arkko > Cc: ipv6@ietf.org > Subject: RE: Multiple DRs on a link >=20 >=20 > > > =3D> There are many different reasons. I sent a verly long > > > email about this to nemo (monet back then). One simple > > > scenario is that you might be walking around with a PAN > > > that happens to have 2 MRs on a single link (e.g. a laptop > > > and a mobile phone). The two MRs could share the same ingress > > > link and have different egress links. For instance your laptop > > > might have a WLAN card and your mobile might have a cellular > > > interface. Once you walk into an airport lounge or starbucks > > > you'll suddenly have a multihomed PAN. By definition, each MR > > > must have a separate home prefix. So each will advertise > > > a different prefix on the ingress side. > > > > Hi Hesham: > > > > I fail to understand the "by definition" here. Nemo does not > > prevent 2 > > different MRs from registering the same MNP. It's like > > multiple parallel > > routes. What's not duplicated is the Home address... In > > fact, I proposed > > a test to check that both registrations actually end up in a > > same link, > > otherwise there's a problem equivalent to the DAD problem in > > MIP6. Not > > much success on that proposal, though >=20 > =3D> Hmm, that's interesting. I must have missed that in the > spec. So, my concern is similar to yours, how does the HA > check whether the MRs are in the same place?? Seems like > a dangerous feature to have. I'm surprised this wasn't discussed > during LC. >=20 > Hesham From nemo-admin@ietf.org Wed Mar 17 07:46:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03796 for ; Wed, 17 Mar 2004 07:46:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aQs-0006dG-JD; Wed, 17 Mar 2004 07:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aQO-0006cH-OV for nemo@optimus.ietf.org; Wed, 17 Mar 2004 07:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03761 for ; Wed, 17 Mar 2004 07:45:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aQO-0006lc-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:45:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aPR-0006fQ-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:44:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3aP6-0006Yp-00; Wed, 17 Mar 2004 07:44:13 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 04:48:32 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HCh7iZ001361; Wed, 17 Mar 2004 13:43:08 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 12:43:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 12:43:37 -0000 Message-ID: Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQL+mkjDFOUdM3bRvC2mwMiI5TrrQAANHuQAAgt2pAAADCxUA== From: "Pascal Thubert \(pthubert\)" To: "IETF NEMO WG" Cc: , X-OriginalArrivalTime: 17 Mar 2004 12:43:37.0780 (UTC) FILETIME=[77DD6740:01C40C1D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: mercredi 17 mars 2004 09:38 > To: Pascal Thubert (pthubert); Jari Arkko > Cc: ipv6@ietf.org > Subject: RE: Multiple DRs on a link > > > > =3D> There are many different reasons. I sent a verly long > > email about this to nemo (monet back then). One simple > > scenario is that you might be walking around with a PAN > > that happens to have 2 MRs on a single link (e.g. a laptop > > and a mobile phone). The two MRs could share the same ingress > > link and have different egress links. For instance your laptop > > might have a WLAN card and your mobile might have a cellular > > interface. Once you walk into an airport lounge or starbucks > > you'll suddenly have a multihomed PAN. By definition, each MR > > must have a separate home prefix. So each will advertise > > a different prefix on the ingress side. > > > > Hi Hesham: > > > > I fail to understand the "by definition" here. Nemo does not > > prevent 2 > > different MRs from registering the same MNP. It's like > > multiple parallel > > routes. What's not duplicated is the Home address... In > > fact, I proposed > > a test to check that both registrations actually end up in a > > same link, > > otherwise there's a problem equivalent to the DAD problem in > > MIP6. Not > > much success on that proposal, though > > =3D> Hmm, that's interesting. I must have missed that in the > spec. So, my concern is similar to yours, how does the HA > check whether the MRs are in the same place?? Seems like > a dangerous feature to have. I'm surprised this wasn't discussed > during LC. > Well, Nemo requires that some authorization be run, that's not described in the spec. Such a test could take place there, or the authorization could bar a second registration for a same prefix, I guess. Pascal From exim@www1.ietf.org Wed Mar 17 07:48:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03871 for ; Wed, 17 Mar 2004 07:48:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aSM-0006sd-8f for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 07:47:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HClYTG026441 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 07:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aSM-0006sO-0Z for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 07:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03868 for ; Wed, 17 Mar 2004 07:47:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aSL-000701-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:47:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aRQ-0006tH-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:46:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3aQx-0006mJ-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aQs-0006dG-JD; Wed, 17 Mar 2004 07:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aQO-0006cH-OV for nemo@optimus.ietf.org; Wed, 17 Mar 2004 07:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03761 for ; Wed, 17 Mar 2004 07:45:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aQO-0006lc-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:45:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aPR-0006fQ-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:44:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3aP6-0006Yp-00; Wed, 17 Mar 2004 07:44:13 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 04:48:32 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HCh7iZ001361; Wed, 17 Mar 2004 13:43:08 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 12:43:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 12:43:37 -0000 Message-ID: Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQL+mkjDFOUdM3bRvC2mwMiI5TrrQAANHuQAAgt2pAAADCxUA== From: "Pascal Thubert \(pthubert\)" To: "IETF NEMO WG" Cc: , X-OriginalArrivalTime: 17 Mar 2004 12:43:37.0780 (UTC) FILETIME=[77DD6740:01C40C1D] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: mercredi 17 mars 2004 09:38 > To: Pascal Thubert (pthubert); Jari Arkko > Cc: ipv6@ietf.org > Subject: RE: Multiple DRs on a link > > > > =3D> There are many different reasons. I sent a verly long > > email about this to nemo (monet back then). One simple > > scenario is that you might be walking around with a PAN > > that happens to have 2 MRs on a single link (e.g. a laptop > > and a mobile phone). The two MRs could share the same ingress > > link and have different egress links. For instance your laptop > > might have a WLAN card and your mobile might have a cellular > > interface. Once you walk into an airport lounge or starbucks > > you'll suddenly have a multihomed PAN. By definition, each MR > > must have a separate home prefix. So each will advertise > > a different prefix on the ingress side. > > > > Hi Hesham: > > > > I fail to understand the "by definition" here. Nemo does not > > prevent 2 > > different MRs from registering the same MNP. It's like > > multiple parallel > > routes. What's not duplicated is the Home address... In > > fact, I proposed > > a test to check that both registrations actually end up in a > > same link, > > otherwise there's a problem equivalent to the DAD problem in > > MIP6. Not > > much success on that proposal, though > > =3D> Hmm, that's interesting. I must have missed that in the > spec. So, my concern is similar to yours, how does the HA > check whether the MRs are in the same place?? Seems like > a dangerous feature to have. I'm surprised this wasn't discussed > during LC. > Well, Nemo requires that some authorization be run, that's not described in the spec. Such a test could take place there, or the authorization could bar a second registration for a same prefix, I guess. Pascal From nemo-admin@ietf.org Wed Mar 17 07:53:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04170 for ; Wed, 17 Mar 2004 07:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aXd-0007GG-4E; Wed, 17 Mar 2004 07:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aX6-0007CX-UN for nemo@optimus.ietf.org; Wed, 17 Mar 2004 07:52:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04122 for ; Wed, 17 Mar 2004 07:52:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aX6-0007cJ-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:52:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aWB-0007WH-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:51:31 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3aVt-0007Pw-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:51:14 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 07:50:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQMHXk5dc569a/PSwWuqbrQUKpomQAAMbJQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> Hmm, that's interesting. I must have missed that in the > > spec. So, my concern is similar to yours, how does the HA > > check whether the MRs are in the same place?? Seems like > > a dangerous feature to have. I'm surprised this wasn't discussed > > during LC. > > > Well, Nemo requires that some authorization be run, that's=20 > not described > in the spec. Such a test could take place there, or the authorization > could bar a second registration for a same prefix, I guess. =3D> That seems too handwavy for a standards track doc. What=20 is the point of having the same prefix for more than one MR=20 anyway? Is it a quick fix for multihoming ? I'm not sure that this is even true because even the MR might not always know if it should send a BU or not for its own prefix. Perhaps this (I'm reluctant to call it feature)=20 capability should be removed and only have 1 prefix per MR.=20 Hesham >=20 > Pascal >=20 From exim@www1.ietf.org Wed Mar 17 07:55:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04233 for ; Wed, 17 Mar 2004 07:55:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aZA-0007N2-6i for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 07:54:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HCsaa9028332 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 07:54:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aZ9-0007Mt-VB for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 07:54:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04224 for ; Wed, 17 Mar 2004 07:54:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aZ9-000044-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:54:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aYc-0007kn-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:54:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3aXl-0007dy-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 07:53:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aXd-0007GG-4E; Wed, 17 Mar 2004 07:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aX6-0007CX-UN for nemo@optimus.ietf.org; Wed, 17 Mar 2004 07:52:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04122 for ; Wed, 17 Mar 2004 07:52:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aX6-0007cJ-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:52:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aWB-0007WH-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:51:31 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3aVt-0007Pw-00 for nemo@ietf.org; Wed, 17 Mar 2004 07:51:14 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 07:50:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQMHXk5dc569a/PSwWuqbrQUKpomQAAMbJQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> Hmm, that's interesting. I must have missed that in the > > spec. So, my concern is similar to yours, how does the HA > > check whether the MRs are in the same place?? Seems like > > a dangerous feature to have. I'm surprised this wasn't discussed > > during LC. > > > Well, Nemo requires that some authorization be run, that's=20 > not described > in the spec. Such a test could take place there, or the authorization > could bar a second registration for a same prefix, I guess. =3D> That seems too handwavy for a standards track doc. What=20 is the point of having the same prefix for more than one MR=20 anyway? Is it a quick fix for multihoming ? I'm not sure that this is even true because even the MR might not always know if it should send a BU or not for its own prefix. Perhaps this (I'm reluctant to call it feature)=20 capability should be removed and only have 1 prefix per MR.=20 Hesham >=20 > Pascal >=20 From nemo-admin@ietf.org Wed Mar 17 08:51:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06493 for ; Wed, 17 Mar 2004 08:51:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bRm-00023G-9m; Wed, 17 Mar 2004 08:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bRF-00022b-Ol for nemo@optimus.ietf.org; Wed, 17 Mar 2004 08:50:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06478 for ; Wed, 17 Mar 2004 08:50:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3bRE-0006sp-00 for nemo@ietf.org; Wed, 17 Mar 2004 08:50:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3bQL-0006mx-00 for nemo@ietf.org; Wed, 17 Mar 2004 08:49:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3bPb-0006Zs-00 for nemo@ietf.org; Wed, 17 Mar 2004 08:48:48 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 05:53:08 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HDlhiZ018369; Wed, 17 Mar 2004 14:47:43 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 13:48:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 13:48:12 -0000 Message-ID: Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQMHXk5dc569a/PSwWuqbrQUKpomQAAMbJQAAG8tyA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 17 Mar 2004 13:48:13.0622 (UTC) FILETIME=[7E0BF560:01C40C26] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: mercredi 17 mars 2004 13:51 > To: Pascal Thubert (pthubert); IETF NEMO WG > Subject: RE: [nemo] FW: Multiple DRs on a link >=20 >=20 >=20 > > > =3D> Hmm, that's interesting. I must have missed that in the > > > spec. So, my concern is similar to yours, how does the HA > > > check whether the MRs are in the same place?? Seems like > > > a dangerous feature to have. I'm surprised this wasn't discussed > > > during LC. > > > > > Well, Nemo requires that some authorization be run, that's > > not described > > in the spec. Such a test could take place there, or the authorization > > could bar a second registration for a same prefix, I guess. >=20 > =3D> That seems too handwavy for a standards track doc. What > is the point of having the same prefix for more than one MR > anyway? Is it a quick fix for multihoming ? I'm not sure > that this is even true because even the MR might not always > know if it should send a BU or not for its own prefix. >=20 > Perhaps this (I'm reluctant to call it feature) > capability should be removed and only have 1 prefix per MR. I'm not sure it's a quick fix. But it's an opening for sure. Multihoming will have a harder time if we bar that situation blindly. In fact, the Nemo spec is very open to future add-ons, and was wanted that way. Taking the train case, I see it as a value to be able to configure the 2 MRs with the same mobile prefix. If the configuration is controlled properly then that's no problem. Seems nicer to me to probe for error as opposed to forbid... Now, whether you support this configuration or not, you may want to check for it anyway. DAD is not wanted in MIP but it's checked for.=20 And if the check is added and finds that the situation is OK, why bar it? Pascal From exim@www1.ietf.org Wed Mar 17 08:53:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06528 for ; Wed, 17 Mar 2004 08:53:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bTI-00029j-Aj for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 08:52:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HDqapn008285 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 08:52:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bTH-00029Y-88 for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 08:52:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06525 for ; Wed, 17 Mar 2004 08:52:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3bTF-000779-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 08:52:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3bSI-00070I-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 08:51:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3bRu-0006tt-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 08:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bRm-00023G-9m; Wed, 17 Mar 2004 08:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bRF-00022b-Ol for nemo@optimus.ietf.org; Wed, 17 Mar 2004 08:50:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06478 for ; Wed, 17 Mar 2004 08:50:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3bRE-0006sp-00 for nemo@ietf.org; Wed, 17 Mar 2004 08:50:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3bQL-0006mx-00 for nemo@ietf.org; Wed, 17 Mar 2004 08:49:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3bPb-0006Zs-00 for nemo@ietf.org; Wed, 17 Mar 2004 08:48:48 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 05:53:08 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HDlhiZ018369; Wed, 17 Mar 2004 14:47:43 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 13:48:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 13:48:12 -0000 Message-ID: Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQMHXk5dc569a/PSwWuqbrQUKpomQAAMbJQAAG8tyA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 17 Mar 2004 13:48:13.0622 (UTC) FILETIME=[7E0BF560:01C40C26] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: mercredi 17 mars 2004 13:51 > To: Pascal Thubert (pthubert); IETF NEMO WG > Subject: RE: [nemo] FW: Multiple DRs on a link >=20 >=20 >=20 > > > =3D> Hmm, that's interesting. I must have missed that in the > > > spec. So, my concern is similar to yours, how does the HA > > > check whether the MRs are in the same place?? Seems like > > > a dangerous feature to have. I'm surprised this wasn't discussed > > > during LC. > > > > > Well, Nemo requires that some authorization be run, that's > > not described > > in the spec. Such a test could take place there, or the authorization > > could bar a second registration for a same prefix, I guess. >=20 > =3D> That seems too handwavy for a standards track doc. What > is the point of having the same prefix for more than one MR > anyway? Is it a quick fix for multihoming ? I'm not sure > that this is even true because even the MR might not always > know if it should send a BU or not for its own prefix. >=20 > Perhaps this (I'm reluctant to call it feature) > capability should be removed and only have 1 prefix per MR. I'm not sure it's a quick fix. But it's an opening for sure. Multihoming will have a harder time if we bar that situation blindly. In fact, the Nemo spec is very open to future add-ons, and was wanted that way. Taking the train case, I see it as a value to be able to configure the 2 MRs with the same mobile prefix. If the configuration is controlled properly then that's no problem. Seems nicer to me to probe for error as opposed to forbid... Now, whether you support this configuration or not, you may want to check for it anyway. DAD is not wanted in MIP but it's checked for.=20 And if the check is added and finds that the situation is OK, why bar it? Pascal From nemo-admin@ietf.org Wed Mar 17 09:02:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06967 for ; Wed, 17 Mar 2004 09:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bcP-000336-7z; Wed, 17 Mar 2004 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bbu-000320-J5 for nemo@optimus.ietf.org; Wed, 17 Mar 2004 09:01:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06846 for ; Wed, 17 Mar 2004 09:01:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3bbt-0000Q1-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:01:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3bb0-0000Ib-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:00:35 -0500 Received: from smtp1.wanadoo.fr ([193.252.22.30] helo=mwinf0103.wanadoo.fr) by ietf-mx with esmtp (Exim 4.12) id 1B3ba7-00003u-00 for nemo@ietf.org; Wed, 17 Mar 2004 08:59:39 -0500 Received: from wwinf0101 (wwinf0101 [172.22.132.28]) by mwinf0103.wanadoo.fr (SMTP Server) with ESMTP id 7AEA31BFFFCF for ; Wed, 17 Mar 2004 14:59:05 +0100 (CET) Message-ID: <25078170.1079531941835.JavaMail.www@wwinf0101> From: Ines BEN HAMIDA Reply-To: ines.ben-hamida@wanadoo.fr To: nemo@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Date: Wed, 17 Mar 2004 14:59:05 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Resource reservation for NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I still thinking about resources reservation for NEMO. Is there any difference between a mobile host and a mobile network in the reservation procedure? thank you for any help Ines From exim@www1.ietf.org Wed Mar 17 09:04:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07020 for ; Wed, 17 Mar 2004 09:04:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bdu-0003Au-QR for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 09:03:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HE3Ygw012198 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 09:03:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bdt-0003Af-EJ for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 09:03:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07017 for ; Wed, 17 Mar 2004 09:03:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3bds-0000f2-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 09:03:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3bcy-0000Yl-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 09:02:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3bcR-0000Rp-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 09:02:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bcP-000336-7z; Wed, 17 Mar 2004 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3bbu-000320-J5 for nemo@optimus.ietf.org; Wed, 17 Mar 2004 09:01:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06846 for ; Wed, 17 Mar 2004 09:01:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3bbt-0000Q1-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:01:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3bb0-0000Ib-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:00:35 -0500 Received: from smtp1.wanadoo.fr ([193.252.22.30] helo=mwinf0103.wanadoo.fr) by ietf-mx with esmtp (Exim 4.12) id 1B3ba7-00003u-00 for nemo@ietf.org; Wed, 17 Mar 2004 08:59:39 -0500 Received: from wwinf0101 (wwinf0101 [172.22.132.28]) by mwinf0103.wanadoo.fr (SMTP Server) with ESMTP id 7AEA31BFFFCF for ; Wed, 17 Mar 2004 14:59:05 +0100 (CET) Message-ID: <25078170.1079531941835.JavaMail.www@wwinf0101> From: Ines BEN HAMIDA Reply-To: ines.ben-hamida@wanadoo.fr To: nemo@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Date: Wed, 17 Mar 2004 14:59:05 +0100 (CET) Content-Transfer-Encoding: 7bit Subject: [nemo] Resource reservation for NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I still thinking about resources reservation for NEMO. Is there any difference between a mobile host and a mobile network in the reservation procedure? thank you for any help Ines From nemo-admin@ietf.org Wed Mar 17 09:29:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07797 for ; Wed, 17 Mar 2004 09:29:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3c2X-0004jh-Ow; Wed, 17 Mar 2004 09:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3c2B-0004jI-TJ for nemo@optimus.ietf.org; Wed, 17 Mar 2004 09:28:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07717 for ; Wed, 17 Mar 2004 09:28:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3c2A-0003c2-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:28:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3c19-0003VB-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:27:35 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3c0a-0003Nw-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:27:00 -0500 content-class: urn:content-classes:message Date: Wed, 17 Mar 2004 09:26:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQMJn6/PPK0JwZ5QUeVSAP/QnpDLwAAr2mg From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable =20 > > =3D> That seems too handwavy for a standards track doc. What > > is the point of having the same prefix for more than one MR > > anyway? Is it a quick fix for multihoming ? I'm not sure > > that this is even true because even the MR might not always > > know if it should send a BU or not for its own prefix. > >=20 > > Perhaps this (I'm reluctant to call it feature) > > capability should be removed and only have 1 prefix per MR. >=20 > I'm not sure it's a quick fix. But it's an opening for sure.=20 > Multihoming > will have a harder time if we bar that situation blindly.=20 =3D> I think this capability is added blindly actually. I don't think we'll do much for the multihoming problem compared with potentials bugs. More on this below. > Taking the train case, I see it as a value to be able to=20 > configure the 2 > MRs with the same mobile prefix. If the configuration is controlled > properly then that's no problem. Seems nicer to me to probe=20 > for error as > opposed to forbid... =3D> How can you probe for error? This is a general=20 solution I presume and not limited for the train case. a network with more than one MR assigned the same home prefix can become unreachable if the 2 MRs are in different places. Id the two MRs are separated for whatever reason none of them will know who should register the prefix. In fact, they won't even know if they are separated.=20 So I don't think this is a good idea. At least not=20 without several cautions and very specific use cases. >=20 > Now, whether you support this configuration or not, you may want to > check for it anyway. DAD is not wanted in MIP but it's checked for.=20 =3D> DAD is wanted of course, but it needs to be faster. In any case, DAD is part of IPv6, MIP didn't add it. This is a new thing added by nemo, for what seems to be a limited gain. The least we could do is add "CAREFUL" all over it to make sure that people understand what this=20 means. Personally, I'd prefer to remove this and have it=20 studied properly as part of a multihoming scenario. >=20 > And if the check is added and finds that the situation is OK, why bar > it? =3D> I haven't seen the check you refer to so I can't tell. But independently of the check, there needs=20 to be a rigorous analysis of the impacts. For example, what happens if the check fails? which MR gets the lucky tunnel ;) what happens when an MR boots or part of the network moves away for any reason (failures or mobility) ?=20 Hesham From nemo-admin@ietf.org Wed Mar 17 10:34:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12276 for ; Wed, 17 Mar 2004 10:34:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3d3R-000734-EQ; Wed, 17 Mar 2004 10:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3d35-00072J-SW for nemo@optimus.ietf.org; Wed, 17 Mar 2004 10:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12205 for ; Wed, 17 Mar 2004 10:33:35 -0500 (EST) From: smida@infres.enst.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3d33-0003v6-00 for nemo@ietf.org; Wed, 17 Mar 2004 10:33:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3d26-0003nH-00 for nemo@ietf.org; Wed, 17 Mar 2004 10:32:38 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3d1F-0003fp-00 for nemo@ietf.org; Wed, 17 Mar 2004 10:31:45 -0500 Received: from infres2.enst.fr (infres2.enst.fr [137.194.200.18]) by infres.enst.fr (Postfix) with ESMTP id F24432FC7 for ; Wed, 17 Mar 2004 16:31:43 +0100 (MET) Received: from www.infres.enst.fr (localhost [127.0.0.1]) by infres2.enst.fr (8.11.6+Sun/8.11.6) with SMTP id i2HFVhY12585 for ; Wed, 17 Mar 2004 16:31:43 +0100 (MET) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user smida) by www.infres.enst.fr with HTTP; Wed, 17 Mar 2004 16:31:43 +0100 (MET) Message-ID: <50600.127.0.0.1.1079537503.squirrel@www.infres.enst.fr> Date: Wed, 17 Mar 2004 16:31:43 +0100 (MET) To: nemo@ietf.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [nemo] need help to simulate a nemo Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi all, I'm lookin for a platform to test and implement NEMO concepts ( an extension to NS or something like ), have you any suggestions about this topic please ? Think's ! From exim@www1.ietf.org Wed Mar 17 10:36:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12392 for ; Wed, 17 Mar 2004 10:36:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3d55-0007Ab-VO for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 10:35:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HFZhK4027557 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 10:35:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3d55-0007AO-N3 for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 10:35:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12380 for ; Wed, 17 Mar 2004 10:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3d53-0004Cq-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 10:35:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3d49-00044t-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 10:34:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3d3U-0003x3-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 10:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3d3R-000734-EQ; Wed, 17 Mar 2004 10:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3d35-00072J-SW for nemo@optimus.ietf.org; Wed, 17 Mar 2004 10:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12205 for ; Wed, 17 Mar 2004 10:33:35 -0500 (EST) From: smida@infres.enst.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3d33-0003v6-00 for nemo@ietf.org; Wed, 17 Mar 2004 10:33:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3d26-0003nH-00 for nemo@ietf.org; Wed, 17 Mar 2004 10:32:38 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3d1F-0003fp-00 for nemo@ietf.org; Wed, 17 Mar 2004 10:31:45 -0500 Received: from infres2.enst.fr (infres2.enst.fr [137.194.200.18]) by infres.enst.fr (Postfix) with ESMTP id F24432FC7 for ; Wed, 17 Mar 2004 16:31:43 +0100 (MET) Received: from www.infres.enst.fr (localhost [127.0.0.1]) by infres2.enst.fr (8.11.6+Sun/8.11.6) with SMTP id i2HFVhY12585 for ; Wed, 17 Mar 2004 16:31:43 +0100 (MET) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user smida) by www.infres.enst.fr with HTTP; Wed, 17 Mar 2004 16:31:43 +0100 (MET) Message-ID: <50600.127.0.0.1.1079537503.squirrel@www.infres.enst.fr> Date: Wed, 17 Mar 2004 16:31:43 +0100 (MET) To: nemo@ietf.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: [nemo] need help to simulate a nemo Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Hi all, I'm lookin for a platform to test and implement NEMO concepts ( an extension to NS or something like ), have you any suggestions about this topic please ? Think's ! From nemo-admin@ietf.org Wed Mar 17 12:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23425 for ; Wed, 17 Mar 2004 12:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3elw-0000Ll-0C; Wed, 17 Mar 2004 12:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ele-0000Hc-1r for nemo@optimus.ietf.org; Wed, 17 Mar 2004 12:23:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23371 for ; Wed, 17 Mar 2004 12:23:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3elS-0000SJ-00 for nemo@ietf.org; Wed, 17 Mar 2004 12:23:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ekW-0000Kf-00 for nemo@ietf.org; Wed, 17 Mar 2004 12:22:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3ejm-00007n-00 for nemo@ietf.org; Wed, 17 Mar 2004 12:21:50 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 09:26:16 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HHKmiZ024437; Wed, 17 Mar 2004 18:20:48 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 17:21:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2004 17:21:17 -0000 Message-ID: Thread-Topic: Assigning the same prefix to multiple MRs Thread-Index: AcQMJn6/PPK0JwZ5QUeVSAP/QnpDLwAAr2mgAAXAMhA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 17 Mar 2004 17:21:18.0098 (UTC) FILETIME=[42302F20:01C40C44] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > Taking the train case, I see it as a value to be able to > > configure the 2 > > MRs with the same mobile prefix. If the configuration is controlled > > properly then that's no problem. Seems nicer to me to probe > > for error as > > opposed to forbid... >=20 > =3D> How can you probe for error? This is a general > solution I presume and not limited for the train case. > a network with more than one MR assigned the same home > prefix can become unreachable if the 2 MRs are in different > places. Id the two MRs are separated for whatever reason > none of them will know who should register the prefix. > In fact, they won't even know if they are separated. > So I don't think this is a good idea. At least not > without several cautions and very specific use cases. Say MR1 and MR2 own a same MNP. MR1 registers to HA1 including explicit prefix for MNP. The MR2 registers to HA2 including the same prefix. Say that either HA1 and HA2 are the same or that there's a backend protocol between the 2, such as HAHA or an existing IGP, that would hint HA2 that HA1 has already a binding for MNP.=20 The idea for 'DND' is for HA2 to test the connectivity to MR1 via MR2. For instance, a probe to MR2 that'd be tunneled via MR1's MRHA tunnel, maybe with a TTL of 1 for the inner packet, that ensures that it would not go any further but onlink. In particular, Nemo allows that the MR uses an address from its MNP to register Home. So say that MR1's home address is MNP::1 and MR2's is MNP::2. So if HA2 simply pings MNP::2 before accepting the registration, it means that the MR1 and MR2 share the same link (because the packet will be attracted by HA1, tunneled to MR1, and MR1 will deliver it on the ingress interface to the MNP, or drop it if MR2 is not there. >=20 >=20 > > > > Now, whether you support this configuration or not, you may want to > > check for it anyway. DAD is not wanted in MIP but it's checked for. >=20 > =3D> DAD is wanted of course, but it needs to be faster. > In any case, DAD is part of IPv6, MIP didn't add it. > This is a new thing added by nemo, for what seems to > be a limited gain. The least we could do is add "CAREFUL" > all over it to make sure that people understand what this > means. Personally, I'd prefer to remove this and have it > studied properly as part of a multihoming scenario. What do you mean remove? Saying it is unlawful does not prevent it. Only a runtime test will say if we end up in that situation. This is what I tried to mean with the analogy, sorry if I failed. > > > > And if the check is added and finds that the situation is OK, why bar > > it? >=20 > =3D> I haven't seen the check you refer to so I can't > tell. But independently of the check, there needs > to be a rigorous analysis of the impacts. For example, > what happens if the check fails? which MR gets the lucky > tunnel ;) what happens when an MR boots or part of the network > moves away for any reason (failures or mobility) ? >=20 Agreed. We need to give it more thoughts to it and we knew it. We started an effort on multihoming and HAHA in part for that purpose. But I'm still convinced that Nemo should stay as it is, simple and open.=20 Today we cover by that case by deployment recommendations, and tomorrow we'll add protocol elements to allow more flexibility. Eg: today in works in a train because the train moves as a single piece. But the operational constraint for the time being is that the routers in the train are paired or something, never to be separated unless they are reconfigured. It is expected that the MRs that share a MNP move together. Because they are LINKed by their back end. In the absence of a DND test, there's nothing but words to prevent MNP duplication anyway. And the words should be in the deployment recommendations, not in the draft, IMHO. Note that the initial discussion is about multiple DRs in IPv6 on a same link, and the problems if they are incoherently deployed. This did not prevent IPv6 from moving forward, but yes, there's room for enhancements. Pascal From exim@www1.ietf.org Wed Mar 17 12:26:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23577 for ; Wed, 17 Mar 2004 12:26:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3enb-0000jt-8a for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 12:25:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HHPl0O002835 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 12:25:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3enb-0000je-3m for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 12:25:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23534 for ; Wed, 17 Mar 2004 12:25:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3enZ-0000n8-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 12:25:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3emg-0000dj-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 12:24:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3elz-0000VM-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 12:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3elw-0000Ll-0C; Wed, 17 Mar 2004 12:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ele-0000Hc-1r for nemo@optimus.ietf.org; Wed, 17 Mar 2004 12:23:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23371 for ; Wed, 17 Mar 2004 12:23:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3elS-0000SJ-00 for nemo@ietf.org; Wed, 17 Mar 2004 12:23:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ekW-0000Kf-00 for nemo@ietf.org; Wed, 17 Mar 2004 12:22:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3ejm-00007n-00 for nemo@ietf.org; Wed, 17 Mar 2004 12:21:50 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 09:26:16 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HHKmiZ024437; Wed, 17 Mar 2004 18:20:48 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 17:21:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2004 17:21:17 -0000 Message-ID: Thread-Topic: Assigning the same prefix to multiple MRs Thread-Index: AcQMJn6/PPK0JwZ5QUeVSAP/QnpDLwAAr2mgAAXAMhA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 17 Mar 2004 17:21:18.0098 (UTC) FILETIME=[42302F20:01C40C44] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Taking the train case, I see it as a value to be able to > > configure the 2 > > MRs with the same mobile prefix. If the configuration is controlled > > properly then that's no problem. Seems nicer to me to probe > > for error as > > opposed to forbid... >=20 > =3D> How can you probe for error? This is a general > solution I presume and not limited for the train case. > a network with more than one MR assigned the same home > prefix can become unreachable if the 2 MRs are in different > places. Id the two MRs are separated for whatever reason > none of them will know who should register the prefix. > In fact, they won't even know if they are separated. > So I don't think this is a good idea. At least not > without several cautions and very specific use cases. Say MR1 and MR2 own a same MNP. MR1 registers to HA1 including explicit prefix for MNP. The MR2 registers to HA2 including the same prefix. Say that either HA1 and HA2 are the same or that there's a backend protocol between the 2, such as HAHA or an existing IGP, that would hint HA2 that HA1 has already a binding for MNP.=20 The idea for 'DND' is for HA2 to test the connectivity to MR1 via MR2. For instance, a probe to MR2 that'd be tunneled via MR1's MRHA tunnel, maybe with a TTL of 1 for the inner packet, that ensures that it would not go any further but onlink. In particular, Nemo allows that the MR uses an address from its MNP to register Home. So say that MR1's home address is MNP::1 and MR2's is MNP::2. So if HA2 simply pings MNP::2 before accepting the registration, it means that the MR1 and MR2 share the same link (because the packet will be attracted by HA1, tunneled to MR1, and MR1 will deliver it on the ingress interface to the MNP, or drop it if MR2 is not there. >=20 >=20 > > > > Now, whether you support this configuration or not, you may want to > > check for it anyway. DAD is not wanted in MIP but it's checked for. >=20 > =3D> DAD is wanted of course, but it needs to be faster. > In any case, DAD is part of IPv6, MIP didn't add it. > This is a new thing added by nemo, for what seems to > be a limited gain. The least we could do is add "CAREFUL" > all over it to make sure that people understand what this > means. Personally, I'd prefer to remove this and have it > studied properly as part of a multihoming scenario. What do you mean remove? Saying it is unlawful does not prevent it. Only a runtime test will say if we end up in that situation. This is what I tried to mean with the analogy, sorry if I failed. > > > > And if the check is added and finds that the situation is OK, why bar > > it? >=20 > =3D> I haven't seen the check you refer to so I can't > tell. But independently of the check, there needs > to be a rigorous analysis of the impacts. For example, > what happens if the check fails? which MR gets the lucky > tunnel ;) what happens when an MR boots or part of the network > moves away for any reason (failures or mobility) ? >=20 Agreed. We need to give it more thoughts to it and we knew it. We started an effort on multihoming and HAHA in part for that purpose. But I'm still convinced that Nemo should stay as it is, simple and open.=20 Today we cover by that case by deployment recommendations, and tomorrow we'll add protocol elements to allow more flexibility. Eg: today in works in a train because the train moves as a single piece. But the operational constraint for the time being is that the routers in the train are paired or something, never to be separated unless they are reconfigured. It is expected that the MRs that share a MNP move together. Because they are LINKed by their back end. In the absence of a DND test, there's nothing but words to prevent MNP duplication anyway. And the words should be in the deployment recommendations, not in the draft, IMHO. Note that the initial discussion is about multiple DRs in IPv6 on a same link, and the problems if they are incoherently deployed. This did not prevent IPv6 from moving forward, but yes, there's room for enhancements. Pascal From nemo-admin@ietf.org Wed Mar 17 19:43:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20157 for ; Wed, 17 Mar 2004 19:43:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3lci-0000EA-Li; Wed, 17 Mar 2004 19:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3lcc-0000Dc-7m for nemo@optimus.ietf.org; Wed, 17 Mar 2004 19:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20147 for ; Wed, 17 Mar 2004 19:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3lca-0001LF-00 for nemo@ietf.org; Wed, 17 Mar 2004 19:42:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3lbh-0001Eh-00 for nemo@ietf.org; Wed, 17 Mar 2004 19:41:58 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3laz-00010J-00 for nemo@ietf.org; Wed, 17 Mar 2004 19:41:13 -0500 content-class: urn:content-classes:message Date: Wed, 17 Mar 2004 19:40:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Assigning the same prefix to multiple MRs Thread-Index: AcQMRENBEzHxJKDsSB69j+UDHMKwywAOjLhg From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> How can you probe for error? This is a general > > solution I presume and not limited for the train case. > > a network with more than one MR assigned the same home > > prefix can become unreachable if the 2 MRs are in different > > places. Id the two MRs are separated for whatever reason > > none of them will know who should register the prefix. > > In fact, they won't even know if they are separated. > > So I don't think this is a good idea. At least not > > without several cautions and very specific use cases. >=20 > Say MR1 and MR2 own a same MNP. MR1 registers to HA1=20 > including explicit > prefix for MNP. > The MR2 registers to HA2 including the same prefix. Say that=20 > either HA1 > and HA2 are the same or that there's a backend protocol=20 > between the 2, > such as HAHA or an existing IGP, that would hint HA2 that HA1 has > already a binding for MNP.=20 >=20 > The idea for 'DND' is for HA2 to test the connectivity to=20 > MR1 via MR2. > For instance, a probe to MR2 that'd be tunneled via MR1's=20 > MRHA tunnel, > maybe with a TTL of 1 for the inner packet, that ensures=20 > that it would > not go any further but onlink. =3D> And what happens when the test doesn't work? Which MR do packets get tunnelled to? Of course there is no such interaction defined today between HAs. > > > Now, whether you support this configuration or not, you=20 > may want to > > > check for it anyway. DAD is not wanted in MIP but it's=20 > checked for. > >=20 > > =3D> DAD is wanted of course, but it needs to be faster. > > In any case, DAD is part of IPv6, MIP didn't add it. > > This is a new thing added by nemo, for what seems to > > be a limited gain. The least we could do is add "CAREFUL" > > all over it to make sure that people understand what this > > means. Personally, I'd prefer to remove this and have it > > studied properly as part of a multihoming scenario. >=20 > What do you mean remove? Saying it is unlawful does not=20 > prevent it.=20 =3D> How do we stop a MN from registering with 2 CoAs in MIPv6? The spec states that one BU overwrites an existing one. Simple! I see no reason why this=20 spec should allow that when it's explicitly disallowed=20 in MIPv6. Especially when the issue has not been sufficiently addressed in the spec. Of course we can address it in another spec (or in this one if people think it's really=20 urgent), but none of this is happening now. So I think we got the worste of both worlds in the current spec. Only > a runtime test will say if we end up in that situation. This=20 > is what I > tried to mean with the analogy, sorry if I failed. =3D> That's ok, but if the spec disallows it and some=20 implementer decides to do it anyway that's their problem. > Agreed. We need to give it more thoughts to it and we knew it. We > started an effort on multihoming and HAHA in part for that=20 > purpose. But > I'm still convinced that Nemo should stay as it is, simple and open.=20 =3D> Open to bugs? Without a complete solution this thing is a bug. I think we should either hold the spec until it's fixed or explicity disallow it like MIPv6. Either solution is fine with me. >=20 > Today we cover by that case by deployment recommendations,=20 =3D> Not enough IMO. BTW, having re-read the HA operations section, there is not even a hint at allowing two MRs to have the same prefix. There is also not a hint about disallowing this case. I think that, given this discussion, it's necessary to add something to that section to explicitly get it off the fence! Hesham From exim@www1.ietf.org Wed Mar 17 19:45:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20241 for ; Wed, 17 Mar 2004 19:45:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3leY-0000PK-Qf for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 19:44:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I0isoY001563 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 19:44:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3leY-0000P8-Kq for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 19:44:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20213 for ; Wed, 17 Mar 2004 19:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3leW-0001a8-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 19:44:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ldb-0001Sp-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 19:43:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3lcm-0001MA-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 19:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3lci-0000EA-Li; Wed, 17 Mar 2004 19:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3lcc-0000Dc-7m for nemo@optimus.ietf.org; Wed, 17 Mar 2004 19:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20147 for ; Wed, 17 Mar 2004 19:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3lca-0001LF-00 for nemo@ietf.org; Wed, 17 Mar 2004 19:42:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3lbh-0001Eh-00 for nemo@ietf.org; Wed, 17 Mar 2004 19:41:58 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3laz-00010J-00 for nemo@ietf.org; Wed, 17 Mar 2004 19:41:13 -0500 content-class: urn:content-classes:message Date: Wed, 17 Mar 2004 19:40:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Assigning the same prefix to multiple MRs Thread-Index: AcQMRENBEzHxJKDsSB69j+UDHMKwywAOjLhg From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> How can you probe for error? This is a general > > solution I presume and not limited for the train case. > > a network with more than one MR assigned the same home > > prefix can become unreachable if the 2 MRs are in different > > places. Id the two MRs are separated for whatever reason > > none of them will know who should register the prefix. > > In fact, they won't even know if they are separated. > > So I don't think this is a good idea. At least not > > without several cautions and very specific use cases. >=20 > Say MR1 and MR2 own a same MNP. MR1 registers to HA1=20 > including explicit > prefix for MNP. > The MR2 registers to HA2 including the same prefix. Say that=20 > either HA1 > and HA2 are the same or that there's a backend protocol=20 > between the 2, > such as HAHA or an existing IGP, that would hint HA2 that HA1 has > already a binding for MNP.=20 >=20 > The idea for 'DND' is for HA2 to test the connectivity to=20 > MR1 via MR2. > For instance, a probe to MR2 that'd be tunneled via MR1's=20 > MRHA tunnel, > maybe with a TTL of 1 for the inner packet, that ensures=20 > that it would > not go any further but onlink. =3D> And what happens when the test doesn't work? Which MR do packets get tunnelled to? Of course there is no such interaction defined today between HAs. > > > Now, whether you support this configuration or not, you=20 > may want to > > > check for it anyway. DAD is not wanted in MIP but it's=20 > checked for. > >=20 > > =3D> DAD is wanted of course, but it needs to be faster. > > In any case, DAD is part of IPv6, MIP didn't add it. > > This is a new thing added by nemo, for what seems to > > be a limited gain. The least we could do is add "CAREFUL" > > all over it to make sure that people understand what this > > means. Personally, I'd prefer to remove this and have it > > studied properly as part of a multihoming scenario. >=20 > What do you mean remove? Saying it is unlawful does not=20 > prevent it.=20 =3D> How do we stop a MN from registering with 2 CoAs in MIPv6? The spec states that one BU overwrites an existing one. Simple! I see no reason why this=20 spec should allow that when it's explicitly disallowed=20 in MIPv6. Especially when the issue has not been sufficiently addressed in the spec. Of course we can address it in another spec (or in this one if people think it's really=20 urgent), but none of this is happening now. So I think we got the worste of both worlds in the current spec. Only > a runtime test will say if we end up in that situation. This=20 > is what I > tried to mean with the analogy, sorry if I failed. =3D> That's ok, but if the spec disallows it and some=20 implementer decides to do it anyway that's their problem. > Agreed. We need to give it more thoughts to it and we knew it. We > started an effort on multihoming and HAHA in part for that=20 > purpose. But > I'm still convinced that Nemo should stay as it is, simple and open.=20 =3D> Open to bugs? Without a complete solution this thing is a bug. I think we should either hold the spec until it's fixed or explicity disallow it like MIPv6. Either solution is fine with me. >=20 > Today we cover by that case by deployment recommendations,=20 =3D> Not enough IMO. BTW, having re-read the HA operations section, there is not even a hint at allowing two MRs to have the same prefix. There is also not a hint about disallowing this case. I think that, given this discussion, it's necessary to add something to that section to explicitly get it off the fence! Hesham From nemo-admin@ietf.org Wed Mar 17 21:51:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26560 for ; Wed, 17 Mar 2004 21:51:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ncc-0007vF-Lu; Wed, 17 Mar 2004 21:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3nbl-0007uB-7G for nemo@optimus.ietf.org; Wed, 17 Mar 2004 21:50:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26501 for ; Wed, 17 Mar 2004 21:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3nbi-0003bi-00 for nemo@ietf.org; Wed, 17 Mar 2004 21:50:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3nap-0003TC-00 for nemo@ietf.org; Wed, 17 Mar 2004 21:49:11 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B3na0-0003Ea-00 for nemo@ietf.org; Wed, 17 Mar 2004 21:48:20 -0500 Received: from localhost.localdomain (dhcp-wireless-a463.camp.wide.ad.jp [203.178.157.227]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 3AE855D0AC; Thu, 18 Mar 2004 11:47:47 +0900 (JST) Date: Thu, 18 Mar 2004 11:48:44 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Cc: H.Soliman@flarion.com, nemo@ietf.org Subject: Re: [nemo] FW: Multiple DRs on a link Message-Id: <20040318114844.360daa74.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, This is a good item for the multihoming problem statement document. Back to the point, this probably requires a delegation mechanism between the 2 MRs, this could be explained in a separate document, but dis-allowing it in NEMO Basic Support would break the spirit of R12: The solution MUST function for multihomed MR and multihomed mobile networks as defined in [NEMO-TERMS]). draft-ietf-nemo-requirements-02.txt So, I'm against removing this capability (several MRs on the link) and the like. What the NEMO Basic Support specification should say is that configuration other than one single mobile subnet (i.e. not multihomed or nested) or not guaranteed to work properly without additional mechanisms. Thierry. > > => That seems too handwavy for a standards track doc. What > > is the point of having the same prefix for more than one MR > > anyway? Is it a quick fix for multihoming ? I'm not sure > > that this is even true because even the MR might not always > > know if it should send a BU or not for its own prefix. > > > > Perhaps this (I'm reluctant to call it feature) > > capability should be removed and only have 1 prefix per MR. > > I'm not sure it's a quick fix. But it's an opening for sure. Multihoming > will have a harder time if we bar that situation blindly. In fact, the > Nemo spec is very open to future add-ons, and was wanted that way. > > Taking the train case, I see it as a value to be able to configure the 2 > MRs with the same mobile prefix. If the configuration is controlled > properly then that's no problem. Seems nicer to me to probe for error as > opposed to forbid... > > Now, whether you support this configuration or not, you may want to > check for it anyway. DAD is not wanted in MIP but it's checked for. > > And if the check is added and finds that the situation is OK, why bar > it? > > Pascal > > From exim@www1.ietf.org Wed Mar 17 21:53:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26616 for ; Wed, 17 Mar 2004 21:53:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3neW-00083N-7X for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 21:53:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I2r0dn030951 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 21:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3neV-000838-T2 for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 21:52:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26600 for ; Wed, 17 Mar 2004 21:52:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3neT-0003yb-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 21:52:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ndZ-0003rt-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 21:52:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ncf-0003kp-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 21:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ncc-0007vF-Lu; Wed, 17 Mar 2004 21:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3nbl-0007uB-7G for nemo@optimus.ietf.org; Wed, 17 Mar 2004 21:50:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26501 for ; Wed, 17 Mar 2004 21:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3nbi-0003bi-00 for nemo@ietf.org; Wed, 17 Mar 2004 21:50:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3nap-0003TC-00 for nemo@ietf.org; Wed, 17 Mar 2004 21:49:11 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B3na0-0003Ea-00 for nemo@ietf.org; Wed, 17 Mar 2004 21:48:20 -0500 Received: from localhost.localdomain (dhcp-wireless-a463.camp.wide.ad.jp [203.178.157.227]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 3AE855D0AC; Thu, 18 Mar 2004 11:47:47 +0900 (JST) Date: Thu, 18 Mar 2004 11:48:44 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Cc: H.Soliman@flarion.com, nemo@ietf.org Subject: Re: [nemo] FW: Multiple DRs on a link Message-Id: <20040318114844.360daa74.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, This is a good item for the multihoming problem statement document. Back to the point, this probably requires a delegation mechanism between the 2 MRs, this could be explained in a separate document, but dis-allowing it in NEMO Basic Support would break the spirit of R12: The solution MUST function for multihomed MR and multihomed mobile networks as defined in [NEMO-TERMS]). draft-ietf-nemo-requirements-02.txt So, I'm against removing this capability (several MRs on the link) and the like. What the NEMO Basic Support specification should say is that configuration other than one single mobile subnet (i.e. not multihomed or nested) or not guaranteed to work properly without additional mechanisms. Thierry. > > => That seems too handwavy for a standards track doc. What > > is the point of having the same prefix for more than one MR > > anyway? Is it a quick fix for multihoming ? I'm not sure > > that this is even true because even the MR might not always > > know if it should send a BU or not for its own prefix. > > > > Perhaps this (I'm reluctant to call it feature) > > capability should be removed and only have 1 prefix per MR. > > I'm not sure it's a quick fix. But it's an opening for sure. Multihoming > will have a harder time if we bar that situation blindly. In fact, the > Nemo spec is very open to future add-ons, and was wanted that way. > > Taking the train case, I see it as a value to be able to configure the 2 > MRs with the same mobile prefix. If the configuration is controlled > properly then that's no problem. Seems nicer to me to probe for error as > opposed to forbid... > > Now, whether you support this configuration or not, you may want to > check for it anyway. DAD is not wanted in MIP but it's checked for. > > And if the check is added and finds that the situation is OK, why bar > it? > > Pascal > > From nemo-admin@ietf.org Wed Mar 17 22:39:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27960 for ; Wed, 17 Mar 2004 22:39:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3oN6-0001c3-7N; Wed, 17 Mar 2004 22:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3oN2-0001bg-Go for nemo@optimus.ietf.org; Wed, 17 Mar 2004 22:39:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27957 for ; Wed, 17 Mar 2004 22:38:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3oMz-0001sA-00 for nemo@ietf.org; Wed, 17 Mar 2004 22:38:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3oM3-0001lG-00 for nemo@ietf.org; Wed, 17 Mar 2004 22:38:00 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3oLN-0001Yd-00 for nemo@ietf.org; Wed, 17 Mar 2004 22:37:17 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 22:36:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQMk2pDXQ/AN0hgR6ez0NlbaCtlQQABUY0A From: "Soliman Hesham" To: "Thierry Ernst" , "Pascal Thubert (pthubert)" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thierry, > Back to the point, this probably requires a delegation=20 > mechanism between > the 2 MRs, this could be explained in a separate document, but > dis-allowing it in NEMO Basic Support would break the spirit of=20 >=20 > R12: The solution MUST function for multihomed MR and multihomed > mobile networks as defined in [NEMO-TERMS]). =3D> I didn't suggest that. >=20 > draft-ietf-nemo-requirements-02.txt >=20 > So, I'm against removing this capability (several MRs on the=20 > link) and > the like. =3D> Me too. I am suggesting that if there is more than one MR they should advertise different prefixes. I.e. one prefix per MR. No anycast prefixes. This has its own problems but it needs to be solved=20 for multihoming in general. >=20 > What the NEMO Basic Support specification should say is that > configuration other than one single mobile subnet (i.e. not=20 > multihomed > or nested) or not guaranteed to work properly without additional > mechanisms. >=20 =3D> I think this is orthogonal to my suggestion but I agree with adding this to the spec. Hesham From exim@www1.ietf.org Wed Mar 17 22:42:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28205 for ; Wed, 17 Mar 2004 22:42:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3oPa-0001jm-K2 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 22:42:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I3fSKe006671 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 22:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3oPM-0001ix-89 for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 22:41:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28024 for ; Wed, 17 Mar 2004 22:41:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3oP4-0002Bb-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 22:41:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3oO4-00021d-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 22:40:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3oN9-0001tc-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 22:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3oN6-0001c3-7N; Wed, 17 Mar 2004 22:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3oN2-0001bg-Go for nemo@optimus.ietf.org; Wed, 17 Mar 2004 22:39:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27957 for ; Wed, 17 Mar 2004 22:38:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3oMz-0001sA-00 for nemo@ietf.org; Wed, 17 Mar 2004 22:38:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3oM3-0001lG-00 for nemo@ietf.org; Wed, 17 Mar 2004 22:38:00 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3oLN-0001Yd-00 for nemo@ietf.org; Wed, 17 Mar 2004 22:37:17 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 22:36:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQMk2pDXQ/AN0hgR6ez0NlbaCtlQQABUY0A From: "Soliman Hesham" To: "Thierry Ernst" , "Pascal Thubert (pthubert)" Cc: Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thierry, > Back to the point, this probably requires a delegation=20 > mechanism between > the 2 MRs, this could be explained in a separate document, but > dis-allowing it in NEMO Basic Support would break the spirit of=20 >=20 > R12: The solution MUST function for multihomed MR and multihomed > mobile networks as defined in [NEMO-TERMS]). =3D> I didn't suggest that. >=20 > draft-ietf-nemo-requirements-02.txt >=20 > So, I'm against removing this capability (several MRs on the=20 > link) and > the like. =3D> Me too. I am suggesting that if there is more than one MR they should advertise different prefixes. I.e. one prefix per MR. No anycast prefixes. This has its own problems but it needs to be solved=20 for multihoming in general. >=20 > What the NEMO Basic Support specification should say is that > configuration other than one single mobile subnet (i.e. not=20 > multihomed > or nested) or not guaranteed to work properly without additional > mechanisms. >=20 =3D> I think this is orthogonal to my suggestion but I agree with adding this to the spec. Hesham From nemo-admin@ietf.org Thu Mar 18 03:44:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27418 for ; Thu, 18 Mar 2004 03:44:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3t8F-0003Ik-IA; Thu, 18 Mar 2004 03:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3t7T-0003Ft-7q for nemo@optimus.ietf.org; Thu, 18 Mar 2004 03:43:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27373 for ; Thu, 18 Mar 2004 03:43:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3t7Q-0007Kq-00 for nemo@ietf.org; Thu, 18 Mar 2004 03:43:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3t6V-0007Dz-00 for nemo@ietf.org; Thu, 18 Mar 2004 03:42:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3t6F-00077L-00 for nemo@ietf.org; Thu, 18 Mar 2004 03:42:00 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 00:46:39 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2I8ewiZ013887; Thu, 18 Mar 2004 09:40:59 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 08:41:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 08:41:27 -0000 Message-ID: Thread-Topic: Assigning the same prefix to multiple MRs Thread-Index: AcQMRENBEzHxJKDsSB69j+UDHMKwywAOjLhgABCQ8CA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 08:41:28.0786 (UTC) FILETIME=[CE529B20:01C40CC4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: jeudi 18 mars 2004 01:41 > To: Pascal Thubert (pthubert); IETF NEMO WG > Subject: RE: Assigning the same prefix to multiple MRs >=20 >=20 > > > =3D> How can you probe for error? This is a general > > > solution I presume and not limited for the train case. > > > a network with more than one MR assigned the same home > > > prefix can become unreachable if the 2 MRs are in different > > > places. Id the two MRs are separated for whatever reason > > > none of them will know who should register the prefix. > > > In fact, they won't even know if they are separated. > > > So I don't think this is a good idea. At least not > > > without several cautions and very specific use cases. > > > > Say MR1 and MR2 own a same MNP. MR1 registers to HA1 > > including explicit > > prefix for MNP. > > The MR2 registers to HA2 including the same prefix. Say that > > either HA1 > > and HA2 are the same or that there's a backend protocol > > between the 2, > > such as HAHA or an existing IGP, that would hint HA2 that HA1 has > > already a binding for MNP. > > > > The idea for 'DND' is for HA2 to test the connectivity to > > MR1 via MR2. > > For instance, a probe to MR2 that'd be tunneled via MR1's > > MRHA tunnel, > > maybe with a TTL of 1 for the inner packet, that ensures > > that it would > > not go any further but onlink. >=20 > =3D> And what happens when the test doesn't work? Which > MR do packets get tunnelled to? > Of course there is no such interaction defined today > between HAs. A type above, I meant "The idea for 'DND' is for HA2 to test the connectivity to MR2 via MR1". The test is done prior to accepting MR2's binding. If the test does not work, MR2 registration fails. Like DAD. >=20 > > > > Now, whether you support this configuration or not, you > > may want to > > > > check for it anyway. DAD is not wanted in MIP but it's > > checked for. > > > > > > =3D> DAD is wanted of course, but it needs to be faster. > > > In any case, DAD is part of IPv6, MIP didn't add it. > > > This is a new thing added by nemo, for what seems to > > > be a limited gain. The least we could do is add "CAREFUL" > > > all over it to make sure that people understand what this > > > means. Personally, I'd prefer to remove this and have it > > > studied properly as part of a multihoming scenario. > > > > What do you mean remove? Saying it is unlawful does not > > prevent it. >=20 > =3D> How do we stop a MN from registering with 2 CoAs > in MIPv6? The spec states that one BU overwrites > an existing one. Simple! I see no reason why this > spec should allow that when it's explicitly disallowed > in MIPv6. Especially when the issue has not been sufficiently > addressed in the spec. Of course we can address it in another > spec (or in this one if people think it's really > urgent), but none of this is happening now. So I think > we got the worste of both worlds in the current spec. >=20 Yes and no: it works as you say if the 2 regs come to the same HA. But if there are 2 HAs, the second looses just like in the test I propose; also if the node is at home and there's a second binding for the same Home address, the binding looses. MIPv6 is not consistent in that case and Nemo is not worse either.=20 Also, a Nemo prefix registration is a route updating. There can be parallel routes, this is nothing new and actually very useful for path redundancy. You can not compare a MIPv6 registration of a Mobile Host, which is a nothing but a remote ND operation, with the Nemo explicit registration of a prefix, which is a routing action. So we apply MIPv6 thinking to the Home Address of the MR, but we apply routing thinking to the prefix. This happens every day with your favorite ISP. If the net admin has configured a same prefix in 2 different places, shit happens... >=20 > Only > > a runtime test will say if we end up in that situation. This > > is what I > > tried to mean with the analogy, sorry if I failed. >=20 > =3D> That's ok, but if the spec disallows it and some > implementer decides to do it anyway that's their problem. I think it should not prevent anything. Against the spirit. Maybe words in the usage draft or something to discourage uncontrolled behaviours or something? >=20 > > Agreed. We need to give it more thoughts to it and we knew it. We > > started an effort on multihoming and HAHA in part for that > > purpose. But > > I'm still convinced that Nemo should stay as it is, simple and open. >=20 > =3D> Open to bugs? Without a complete solution this thing > is a bug. I think we should either hold the spec until > it's fixed or explicity disallow it like MIPv6. > Either solution is fine with me. Do you mean OSPF is a bug? OSPF by itself will not prevent a prefix duplication. Actually some very controlled deployments use that for site redundancy. If I remember well, the Nagano Olympics site worked that way a few years ago, but I may be wrong on that specific one. Leave something for deployment guys, they know their job. >=20 > > > > Today we cover by that case by deployment recommendations, >=20 > =3D> Not enough IMO. BTW, having re-read the HA operations > section, there is not even a hint at allowing two MRs to > have the same prefix. There is also not a hint about disallowing > this case. I think that, given this discussion, it's necessary > to add something to that section to explicitly get it off the fence! >=20 Well, the hint was there in version 00. I was asked to remove it. Also please look at slide 9 of 11 (looks like a borg thing now) of http://www.mobilenetworks.org/nemo/ietf57/slides/nemo-ietf57-basic.pdf=20 Pascal From exim@www1.ietf.org Thu Mar 18 03:46:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27544 for ; Thu, 18 Mar 2004 03:46:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tAK-0003T3-Io for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 03:46:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I8kCE7013328 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 03:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tAK-0003St-1Y for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 03:46:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27482 for ; Thu, 18 Mar 2004 03:46:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tAH-0007iy-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 03:46:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3t9K-0007aM-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 03:45:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3t8P-0007Sh-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 03:44:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3t8F-0003Ik-IA; Thu, 18 Mar 2004 03:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3t7T-0003Ft-7q for nemo@optimus.ietf.org; Thu, 18 Mar 2004 03:43:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27373 for ; Thu, 18 Mar 2004 03:43:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3t7Q-0007Kq-00 for nemo@ietf.org; Thu, 18 Mar 2004 03:43:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3t6V-0007Dz-00 for nemo@ietf.org; Thu, 18 Mar 2004 03:42:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3t6F-00077L-00 for nemo@ietf.org; Thu, 18 Mar 2004 03:42:00 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 00:46:39 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2I8ewiZ013887; Thu, 18 Mar 2004 09:40:59 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 08:41:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 08:41:27 -0000 Message-ID: Thread-Topic: Assigning the same prefix to multiple MRs Thread-Index: AcQMRENBEzHxJKDsSB69j+UDHMKwywAOjLhgABCQ8CA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 08:41:28.0786 (UTC) FILETIME=[CE529B20:01C40CC4] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: jeudi 18 mars 2004 01:41 > To: Pascal Thubert (pthubert); IETF NEMO WG > Subject: RE: Assigning the same prefix to multiple MRs >=20 >=20 > > > =3D> How can you probe for error? This is a general > > > solution I presume and not limited for the train case. > > > a network with more than one MR assigned the same home > > > prefix can become unreachable if the 2 MRs are in different > > > places. Id the two MRs are separated for whatever reason > > > none of them will know who should register the prefix. > > > In fact, they won't even know if they are separated. > > > So I don't think this is a good idea. At least not > > > without several cautions and very specific use cases. > > > > Say MR1 and MR2 own a same MNP. MR1 registers to HA1 > > including explicit > > prefix for MNP. > > The MR2 registers to HA2 including the same prefix. Say that > > either HA1 > > and HA2 are the same or that there's a backend protocol > > between the 2, > > such as HAHA or an existing IGP, that would hint HA2 that HA1 has > > already a binding for MNP. > > > > The idea for 'DND' is for HA2 to test the connectivity to > > MR1 via MR2. > > For instance, a probe to MR2 that'd be tunneled via MR1's > > MRHA tunnel, > > maybe with a TTL of 1 for the inner packet, that ensures > > that it would > > not go any further but onlink. >=20 > =3D> And what happens when the test doesn't work? Which > MR do packets get tunnelled to? > Of course there is no such interaction defined today > between HAs. A type above, I meant "The idea for 'DND' is for HA2 to test the connectivity to MR2 via MR1". The test is done prior to accepting MR2's binding. If the test does not work, MR2 registration fails. Like DAD. >=20 > > > > Now, whether you support this configuration or not, you > > may want to > > > > check for it anyway. DAD is not wanted in MIP but it's > > checked for. > > > > > > =3D> DAD is wanted of course, but it needs to be faster. > > > In any case, DAD is part of IPv6, MIP didn't add it. > > > This is a new thing added by nemo, for what seems to > > > be a limited gain. The least we could do is add "CAREFUL" > > > all over it to make sure that people understand what this > > > means. Personally, I'd prefer to remove this and have it > > > studied properly as part of a multihoming scenario. > > > > What do you mean remove? Saying it is unlawful does not > > prevent it. >=20 > =3D> How do we stop a MN from registering with 2 CoAs > in MIPv6? The spec states that one BU overwrites > an existing one. Simple! I see no reason why this > spec should allow that when it's explicitly disallowed > in MIPv6. Especially when the issue has not been sufficiently > addressed in the spec. Of course we can address it in another > spec (or in this one if people think it's really > urgent), but none of this is happening now. So I think > we got the worste of both worlds in the current spec. >=20 Yes and no: it works as you say if the 2 regs come to the same HA. But if there are 2 HAs, the second looses just like in the test I propose; also if the node is at home and there's a second binding for the same Home address, the binding looses. MIPv6 is not consistent in that case and Nemo is not worse either.=20 Also, a Nemo prefix registration is a route updating. There can be parallel routes, this is nothing new and actually very useful for path redundancy. You can not compare a MIPv6 registration of a Mobile Host, which is a nothing but a remote ND operation, with the Nemo explicit registration of a prefix, which is a routing action. So we apply MIPv6 thinking to the Home Address of the MR, but we apply routing thinking to the prefix. This happens every day with your favorite ISP. If the net admin has configured a same prefix in 2 different places, shit happens... >=20 > Only > > a runtime test will say if we end up in that situation. This > > is what I > > tried to mean with the analogy, sorry if I failed. >=20 > =3D> That's ok, but if the spec disallows it and some > implementer decides to do it anyway that's their problem. I think it should not prevent anything. Against the spirit. Maybe words in the usage draft or something to discourage uncontrolled behaviours or something? >=20 > > Agreed. We need to give it more thoughts to it and we knew it. We > > started an effort on multihoming and HAHA in part for that > > purpose. But > > I'm still convinced that Nemo should stay as it is, simple and open. >=20 > =3D> Open to bugs? Without a complete solution this thing > is a bug. I think we should either hold the spec until > it's fixed or explicity disallow it like MIPv6. > Either solution is fine with me. Do you mean OSPF is a bug? OSPF by itself will not prevent a prefix duplication. Actually some very controlled deployments use that for site redundancy. If I remember well, the Nagano Olympics site worked that way a few years ago, but I may be wrong on that specific one. Leave something for deployment guys, they know their job. >=20 > > > > Today we cover by that case by deployment recommendations, >=20 > =3D> Not enough IMO. BTW, having re-read the HA operations > section, there is not even a hint at allowing two MRs to > have the same prefix. There is also not a hint about disallowing > this case. I think that, given this discussion, it's necessary > to add something to that section to explicitly get it off the fence! >=20 Well, the hint was there in version 00. I was asked to remove it. Also please look at slide 9 of 11 (looks like a borg thing now) of http://www.mobilenetworks.org/nemo/ietf57/slides/nemo-ietf57-basic.pdf=20 Pascal From nemo-admin@ietf.org Thu Mar 18 04:02:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28263 for ; Thu, 18 Mar 2004 04:02:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tPd-0004VI-PT; Thu, 18 Mar 2004 04:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tP2-0004UP-V9 for nemo@optimus.ietf.org; Thu, 18 Mar 2004 04:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28217 for ; Thu, 18 Mar 2004 04:01:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tP0-0001z2-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:01:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3tO7-0001rH-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:00:28 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3tNj-0001ic-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:00:03 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 03:59:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Assigning the same prefix to multiple MRs Thread-Index: AcQMxNChCye+bQyHQ7uwn1cg3lREcAAAABTQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable =20 > > =3D> And what happens when the test doesn't work? Which > > MR do packets get tunnelled to? > > Of course there is no such interaction defined today > > between HAs. >=20 > A type above, I meant "The idea for 'DND' is for HA2 to test the > connectivity to MR2 via MR1". > The test is done prior to accepting MR2's binding. If the=20 > test does not > work, MR2 registration fails. Like DAD. =3D> Right so MR2 and the network behind it become unreachable because MR1 is possible down! That's not good. > > =3D> How do we stop a MN from registering with 2 CoAs > > in MIPv6? The spec states that one BU overwrites > > an existing one. Simple! I see no reason why this > > spec should allow that when it's explicitly disallowed > > in MIPv6. Especially when the issue has not been sufficiently > > addressed in the spec. Of course we can address it in another > > spec (or in this one if people think it's really > > urgent), but none of this is happening now. So I think > > we got the worste of both worlds in the current spec. > >=20 > Yes and no: it works as you say if the 2 regs come to the=20 > same HA.=20 =3D> That's the only case we have now. One HoA, one CoA, one HA. But > if there are 2 HAs,=20 =3D> There is never 2 HAs visible on the IP layer. > also if the node is at home and there's a second binding for the same > Home address, the binding looses. MIPv6 is not consistent in=20 > that case =3D> Because this case does not exist in MIPv6. > Also, a Nemo prefix registration is a route updating. There can be > parallel routes, this is nothing new and actually very=20 > useful for path > redundancy.=20 =3D> Sure if parallel paths lead to the same destination. This is the whole point, they may not lead to the same destination. You're basically asking for anycast prefixes.=20 Anycast is not useful if you want to have reliable=20 communication with the same host (i.e. a reachable host). You can not compare a MIPv6 registration of a=20 > Mobile Host, > which is a nothing but a remote ND operation, with the Nemo explicit > registration of a prefix, which is a routing action. So we=20 > apply MIPv6 > thinking to the Home Address of the MR, but we apply routing=20 > thinking to > the prefix.=20 =3D> I'm saying that if you want to do that then apply it properly. At the moment it's not applied properly. It seems like this feature was not agreed on and things were left hanging in the air. I suggest that we either fix it or make it clear that it's not allowed. This happens every day with your favorite ISP. If the net > admin has configured a same prefix in 2 different places, shit > happens... =3D> I don't know what you' rereferring to here. None of this happens today. I think you have parallel redundant paths mixed up with this. They're not the same thing. ISP routers don't move while advertising a prefix which cannot be reached through them... > > =3D> Open to bugs? Without a complete solution this thing > > is a bug. I think we should either hold the spec until > > it's fixed or explicity disallow it like MIPv6. > > Either solution is fine with me. > Do you mean OSPF is a bug? OSPF by itself will not prevent a prefix > duplication. Actually some very controlled deployments use=20 > that for site > redundancy. If I remember well, the Nagano Olympics site=20 > worked that way > a few years ago, but I may be wrong on that specific one. Leave > something for deployment guys, they know their job. =3D> See my comments above. > Well, the hint was there in version 00. I was asked to=20 > remove it.=20 =3D> So it seems like it's not agreed on. In this case I'd just add something in the draft that makes it clear that you can't do that. Maybe another draft is needed to add this. Hesham From nemo-admin@ietf.org Thu Mar 18 05:01:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00384 for ; Thu, 18 Mar 2004 05:01:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uKm-0008B2-ML; Thu, 18 Mar 2004 05:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uK1-00088R-CD for nemo@optimus.ietf.org; Thu, 18 Mar 2004 05:00:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00245 for ; Thu, 18 Mar 2004 05:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uJy-0001UI-00 for nemo@ietf.org; Thu, 18 Mar 2004 05:00:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uIz-0001K5-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:59:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3uI5-00015v-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:58:17 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 02:02:58 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2I9vDif009858; Thu, 18 Mar 2004 10:57:17 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 09:57:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 09:57:45 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQMxNChCye+bQyHQ7uwn1cg3lREcAAAABTQAAC/wVA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 09:57:46.0372 (UTC) FILETIME=[76C6CC40:01C40CCF] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > > =3D> And what happens when the test doesn't work? Which > > > MR do packets get tunnelled to? > > > Of course there is no such interaction defined today > > > between HAs. > > > > A type above, I meant "The idea for 'DND' is for HA2 to test the > > connectivity to MR2 via MR1". > > The test is done prior to accepting MR2's binding. If the > > test does not > > work, MR2 registration fails. Like DAD. >=20 > =3D> Right so MR2 and the network behind it become > unreachable because MR1 is possible down! That's not > good. If the test works, the registration is accepted and you get the redundancy you want.=20 If MR1 is down, the registration for MR1 was cleaned up so the test is not even run for MR2. If that's your point, I do agree that there's a window if MR2 binds just at the time MR1 dies and before the BCE for MR1 is cleaned up. There's also a risk of collision like MR1 and MR2 startup at the same time (I think that that one is a bit more realistic, like you start the entertainment power in a train or a plane). It's possible to make the test a bit more complex if the list finds it worthwhile. HA2 pings MR1 first and then pings MR2 via MR1. If MR1 does not answer, then accept the registration for MR2. IF MR1 answers but MR2 does not, reject the registration.=20 It's also possible to run the test in runtime to check the active registrations and alert the net admin if something's wrong. The test can even be run by net admin using existing probes, if they care to do so. Anyway DND is just a check on whether the net admin did their job correctly, knowing that since the routers are mobile, there's a slightly higher risk that something has moved overtime. The test was not never deemed MANDATORY. Pascal From exim@www1.ietf.org Thu Mar 18 05:03:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00442 for ; Thu, 18 Mar 2004 05:03:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uMz-0008OA-NK for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 05:03:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IA3L0m032230 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 05:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uMz-0008Nl-4q for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 05:03:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00433 for ; Thu, 18 Mar 2004 05:03:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uMw-0001sa-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 05:03:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uLz-0001lc-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 05:02:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3uL6-0001eq-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 05:01:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3uL6-0006aV-Py for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 05:01:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uKm-0008B2-ML; Thu, 18 Mar 2004 05:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uK1-00088R-CD for nemo@optimus.ietf.org; Thu, 18 Mar 2004 05:00:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00245 for ; Thu, 18 Mar 2004 05:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uJy-0001UI-00 for nemo@ietf.org; Thu, 18 Mar 2004 05:00:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uIz-0001K5-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:59:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3uI5-00015v-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:58:17 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 02:02:58 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2I9vDif009858; Thu, 18 Mar 2004 10:57:17 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 09:57:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 09:57:45 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQMxNChCye+bQyHQ7uwn1cg3lREcAAAABTQAAC/wVA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 09:57:46.0372 (UTC) FILETIME=[76C6CC40:01C40CCF] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > > =3D> And what happens when the test doesn't work? Which > > > MR do packets get tunnelled to? > > > Of course there is no such interaction defined today > > > between HAs. > > > > A type above, I meant "The idea for 'DND' is for HA2 to test the > > connectivity to MR2 via MR1". > > The test is done prior to accepting MR2's binding. If the > > test does not > > work, MR2 registration fails. Like DAD. >=20 > =3D> Right so MR2 and the network behind it become > unreachable because MR1 is possible down! That's not > good. If the test works, the registration is accepted and you get the redundancy you want.=20 If MR1 is down, the registration for MR1 was cleaned up so the test is not even run for MR2. If that's your point, I do agree that there's a window if MR2 binds just at the time MR1 dies and before the BCE for MR1 is cleaned up. There's also a risk of collision like MR1 and MR2 startup at the same time (I think that that one is a bit more realistic, like you start the entertainment power in a train or a plane). It's possible to make the test a bit more complex if the list finds it worthwhile. HA2 pings MR1 first and then pings MR2 via MR1. If MR1 does not answer, then accept the registration for MR2. IF MR1 answers but MR2 does not, reject the registration.=20 It's also possible to run the test in runtime to check the active registrations and alert the net admin if something's wrong. The test can even be run by net admin using existing probes, if they care to do so. Anyway DND is just a check on whether the net admin did their job correctly, knowing that since the routers are mobile, there's a slightly higher risk that something has moved overtime. The test was not never deemed MANDATORY. Pascal From nemo-admin@ietf.org Thu Mar 18 05:17:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00936 for ; Thu, 18 Mar 2004 05:17:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uaG-0000d3-RV; Thu, 18 Mar 2004 05:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uXW-0000Zu-I6 for nemo@optimus.ietf.org; Thu, 18 Mar 2004 05:14:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00893 for ; Thu, 18 Mar 2004 05:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uXT-00037u-00 for nemo@ietf.org; Thu, 18 Mar 2004 05:14:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uWb-00031g-00 for nemo@ietf.org; Thu, 18 Mar 2004 05:13:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3uVr-0002nx-00 for nemo@ietf.org; Thu, 18 Mar 2004 05:12:31 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 02:17:12 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IABUiZ014862; Thu, 18 Mar 2004 11:11:30 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 10:12:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Thu, 18 Mar 2004 10:11:59 -0000 Message-ID: Thread-Topic: RE: [nemo] FW: Multiple DRs on a link Thread-Index: AcQM0PxBySjLuLVRTAqorJofSlH1AQ== From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 10:12:00.0175 (UTC) FILETIME=[73AECBF0:01C40CD1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > > =3D> How do we stop a MN from registering with 2 CoAs > > > in MIPv6? The spec states that one BU overwrites > > > an existing one. Simple! I see no reason why this > > > spec should allow that when it's explicitly disallowed > > > in MIPv6. Especially when the issue has not been sufficiently > > > addressed in the spec. Of course we can address it in another > > > spec (or in this one if people think it's really > > > urgent), but none of this is happening now. So I think > > > we got the worste of both worlds in the current spec. > > > > > Yes and no: it works as you say if the 2 regs come to the > > same HA. >=20 > =3D> That's the only case we have now. One HoA, one CoA, one HA. >=20 > But > > if there are 2 HAs, >=20 > =3D> There is never 2 HAs visible on the IP layer. >=20 >=20 What do you mean? If there are 2 MNs configured with a same Home = Address, they MAY or MAY not get the same answer from DHAAD. They MAY be = registering to different HAs. It can simply depend on which HA gets the = DHAAD from the Internet, and whatever load balancing algorithm they = have. Do I miss something?=20 And like I said, If 2 MNs have a same Home Address, MIP will react = differently whether they register to a same HA of to different ones. Or = if one is at home and the other attempts to register.=20 Nemo will act as MIP for the Home Address, and if that test is passed, = Nemo will accept the duplicate prefixes, insert both routes, and leave = it up to the routing protocols and the traffic splitting in place to get = the packets forwarded. As a result, in most cases, you'll see packets = over both tunnels. If there's no misconfiguration, the packets will end = up in the same link anyway. As usual. > > also if the node is at home and there's a second binding for the = same > > Home address, the binding looses. MIPv6 is not consistent in > > that case >=20 > =3D> Because this case does not exist in MIPv6. >=20 Seems you are more optimistic then I am :) I would not pretend that such = a thing as misconfiguration does not exist in MIPv6. Just configure the = same Home Address on 2 MNs and look? Then plug one at home and try = binding the other one. Or the other way around? > > Also, a Nemo prefix registration is a route updating. There can be > > parallel routes, this is nothing new and actually very > > useful for path > > redundancy. >=20 > =3D> Sure if parallel paths lead to the same destination. > This is the whole point, they may not lead to the same > destination. You're basically asking for anycast prefixes. > Anycast is not useful if you want to have reliable > communication with the same host (i.e. a reachable host). I think we agree on that. Hopefully the 2 registrations do lead to the = same place, since we want the 2 MRs to share the same ingress link; or = else, it's a misconfiguration - or the net admin knows that he is doing = some fine trick and whatever words we put in the spec he is on his own = -.=20 Again, Nemo gives you the same level of service as OSPF or ISIS. After = that it is about the professional skill of deployment people. >=20 > You can not compare a MIPv6 registration of a > > Mobile Host, > > which is a nothing but a remote ND operation, with the Nemo = explicit > > registration of a prefix, which is a routing action. So we > > apply MIPv6 > > thinking to the Home Address of the MR, but we apply routing > > thinking to > > the prefix. >=20 > =3D> I'm saying that if you want to do that then apply > it properly. At the moment it's not applied properly. > It seems like this feature was not agreed on and things > were left hanging in the air. I suggest that we either > fix it or make it clear that it's not allowed. Disagree. It was discussed at the WG. It's skill OK to voice your = opposition but it was discussed. It was even specifically voiced at IETF = 57, as I pointed out, and was part of nemo basic draft 00. =20 >=20 > This happens every day with your favorite ISP. If the net > > admin has configured a same prefix in 2 different places, shit > > happens... >=20 > =3D> I don't know what you' rereferring to here. None > of this happens today. I think you have parallel > redundant paths mixed up with this. They're not the > same thing. ISP routers don't move while advertising > a prefix which cannot be reached through them... All I'm saying is that if a network administrator of your ISP configures = a same prefix on 2 different link, you'll reach the closest one, or, if = you're in the middle, you may end up reaching them alternatively. Shit = happens, and the IGP in place does not prevent that at all. Should Nemo do more? If so, why? Maybe all this discussion is because of a misunderstanding in the = initial statement. I have in mind a configuration where an MNP is = co-owned by 2 MRs that share an ingress link. The set = (MR1+ingresslink+MR2) moves together as a whole. They are an atomic = system. Link a plane with a wire between the 2 MRs. Maybe for you the = ingress link is a fixed AP, like a hotspot at a Caf=E9, in which case = the connectivity between the 2 MRs would be occasional? In that case, = giving those MRs a same MNP is a misconfiguration, of course. And my = point here is that the classical IGPs do not actively check for such a = misconfiguration, either. >=20 > > Well, the hint was there in version 00. I was asked to > > remove it. >=20 > =3D> So it seems like it's not agreed on. In this case Not because it's not agreed upon, because it's not normative. The text = was judged complex and not part of the protocol. There was no specific = behaviour associated to it... > I'd just add something in the draft that makes it clear > that you can't do that. Maybe another draft is needed > to add this. Well I believe that the plane case I gave as example is perfectly = legitimate. It's enough for me to say that Nemo, as any routing = protocol, should not bar anything like that. But yes, I agree that = there's room for a multihoming usage draft that would details the can's = and can'ts. Pascal Pascal From exim@www1.ietf.org Thu Mar 18 05:33:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01328 for ; Thu, 18 Mar 2004 05:33:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uq9-000178-RO for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 05:33:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IAXTj4004274 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 05:33:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uq8-00016r-Am for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 05:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01236 for ; Thu, 18 Mar 2004 05:33:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uq4-0005HB-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 05:33:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3upC-00054y-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 05:32:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3uaW-0003Sf-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 05:17:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uaG-0000d3-RV; Thu, 18 Mar 2004 05:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uXW-0000Zu-I6 for nemo@optimus.ietf.org; Thu, 18 Mar 2004 05:14:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00893 for ; Thu, 18 Mar 2004 05:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uXT-00037u-00 for nemo@ietf.org; Thu, 18 Mar 2004 05:14:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uWb-00031g-00 for nemo@ietf.org; Thu, 18 Mar 2004 05:13:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3uVr-0002nx-00 for nemo@ietf.org; Thu, 18 Mar 2004 05:12:31 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 02:17:12 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IABUiZ014862; Thu, 18 Mar 2004 11:11:30 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 10:12:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Thu, 18 Mar 2004 10:11:59 -0000 Message-ID: Thread-Topic: RE: [nemo] FW: Multiple DRs on a link Thread-Index: AcQM0PxBySjLuLVRTAqorJofSlH1AQ== From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 10:12:00.0175 (UTC) FILETIME=[73AECBF0:01C40CD1] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > > =3D> How do we stop a MN from registering with 2 CoAs > > > in MIPv6? The spec states that one BU overwrites > > > an existing one. Simple! I see no reason why this > > > spec should allow that when it's explicitly disallowed > > > in MIPv6. Especially when the issue has not been sufficiently > > > addressed in the spec. Of course we can address it in another > > > spec (or in this one if people think it's really > > > urgent), but none of this is happening now. So I think > > > we got the worste of both worlds in the current spec. > > > > > Yes and no: it works as you say if the 2 regs come to the > > same HA. >=20 > =3D> That's the only case we have now. One HoA, one CoA, one HA. >=20 > But > > if there are 2 HAs, >=20 > =3D> There is never 2 HAs visible on the IP layer. >=20 >=20 What do you mean? If there are 2 MNs configured with a same Home = Address, they MAY or MAY not get the same answer from DHAAD. They MAY be = registering to different HAs. It can simply depend on which HA gets the = DHAAD from the Internet, and whatever load balancing algorithm they = have. Do I miss something?=20 And like I said, If 2 MNs have a same Home Address, MIP will react = differently whether they register to a same HA of to different ones. Or = if one is at home and the other attempts to register.=20 Nemo will act as MIP for the Home Address, and if that test is passed, = Nemo will accept the duplicate prefixes, insert both routes, and leave = it up to the routing protocols and the traffic splitting in place to get = the packets forwarded. As a result, in most cases, you'll see packets = over both tunnels. If there's no misconfiguration, the packets will end = up in the same link anyway. As usual. > > also if the node is at home and there's a second binding for the = same > > Home address, the binding looses. MIPv6 is not consistent in > > that case >=20 > =3D> Because this case does not exist in MIPv6. >=20 Seems you are more optimistic then I am :) I would not pretend that such = a thing as misconfiguration does not exist in MIPv6. Just configure the = same Home Address on 2 MNs and look? Then plug one at home and try = binding the other one. Or the other way around? > > Also, a Nemo prefix registration is a route updating. There can be > > parallel routes, this is nothing new and actually very > > useful for path > > redundancy. >=20 > =3D> Sure if parallel paths lead to the same destination. > This is the whole point, they may not lead to the same > destination. You're basically asking for anycast prefixes. > Anycast is not useful if you want to have reliable > communication with the same host (i.e. a reachable host). I think we agree on that. Hopefully the 2 registrations do lead to the = same place, since we want the 2 MRs to share the same ingress link; or = else, it's a misconfiguration - or the net admin knows that he is doing = some fine trick and whatever words we put in the spec he is on his own = -.=20 Again, Nemo gives you the same level of service as OSPF or ISIS. After = that it is about the professional skill of deployment people. >=20 > You can not compare a MIPv6 registration of a > > Mobile Host, > > which is a nothing but a remote ND operation, with the Nemo = explicit > > registration of a prefix, which is a routing action. So we > > apply MIPv6 > > thinking to the Home Address of the MR, but we apply routing > > thinking to > > the prefix. >=20 > =3D> I'm saying that if you want to do that then apply > it properly. At the moment it's not applied properly. > It seems like this feature was not agreed on and things > were left hanging in the air. I suggest that we either > fix it or make it clear that it's not allowed. Disagree. It was discussed at the WG. It's skill OK to voice your = opposition but it was discussed. It was even specifically voiced at IETF = 57, as I pointed out, and was part of nemo basic draft 00. =20 >=20 > This happens every day with your favorite ISP. If the net > > admin has configured a same prefix in 2 different places, shit > > happens... >=20 > =3D> I don't know what you' rereferring to here. None > of this happens today. I think you have parallel > redundant paths mixed up with this. They're not the > same thing. ISP routers don't move while advertising > a prefix which cannot be reached through them... All I'm saying is that if a network administrator of your ISP configures = a same prefix on 2 different link, you'll reach the closest one, or, if = you're in the middle, you may end up reaching them alternatively. Shit = happens, and the IGP in place does not prevent that at all. Should Nemo do more? If so, why? Maybe all this discussion is because of a misunderstanding in the = initial statement. I have in mind a configuration where an MNP is = co-owned by 2 MRs that share an ingress link. The set = (MR1+ingresslink+MR2) moves together as a whole. They are an atomic = system. Link a plane with a wire between the 2 MRs. Maybe for you the = ingress link is a fixed AP, like a hotspot at a Caf=E9, in which case = the connectivity between the 2 MRs would be occasional? In that case, = giving those MRs a same MNP is a misconfiguration, of course. And my = point here is that the classical IGPs do not actively check for such a = misconfiguration, either. >=20 > > Well, the hint was there in version 00. I was asked to > > remove it. >=20 > =3D> So it seems like it's not agreed on. In this case Not because it's not agreed upon, because it's not normative. The text = was judged complex and not part of the protocol. There was no specific = behaviour associated to it... > I'd just add something in the draft that makes it clear > that you can't do that. Maybe another draft is needed > to add this. Well I believe that the plane case I gave as example is perfectly = legitimate. It's enough for me to say that Nemo, as any routing = protocol, should not bar anything like that. But yes, I agree that = there's room for a multihoming usage draft that would details the can's = and can'ts. Pascal Pascal From nemo-admin@ietf.org Thu Mar 18 06:13:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03251 for ; Thu, 18 Mar 2004 06:13:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vSO-0003d4-Ol; Thu, 18 Mar 2004 06:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vRi-0003b1-0u for nemo@optimus.ietf.org; Thu, 18 Mar 2004 06:12:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03177 for ; Thu, 18 Mar 2004 06:12:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vRe-0002WP-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:12:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vQj-0002Pv-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:11:18 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3vQ2-0002DI-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:10:34 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] FW: Multiple DRs on a link Date: Thu, 18 Mar 2004 06:10:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQM0XU6Xo54IxVWTfKjyGJU4uUmlQABTilQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Thierry Ernst" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> There is never 2 HAs visible on the IP layer. > >=20 > >=20 > What do you mean? If there are 2 MNs configured with a same=20 > Home Address,=20 =3D> That's a bug of course and is **_detectable_** because: A. There SAs should not both match the same HoA B. If they (SAs) do someone will complain and the misconfig will be rectified. they MAY or MAY not get the same answer from=20 > DHAAD. They MAY be registering to different HAs. It can=20 > simply depend on which HA gets the DHAAD from the Internet,=20 > and whatever load balancing algorithm they have. Do I miss=20 > something?=20 =3D> I think you are talking about a misconfig case. I'm talking about what the protocol is designed to do. And of course if people misconfig things will not work as planned. This goes for every protocol. > Nemo will act as MIP for the Home Address, and if that test=20 > is passed, Nemo will accept the duplicate prefixes, insert=20 > both routes, and leave it up to the routing protocols and=20 > the traffic splitting in place to get the packets forwarded.=20 > As a result, in most cases, you'll see packets over both=20 > tunnels. If there's no misconfiguration, the packets will=20 > end up in the same link anyway. As usual. =3D> I understand what you're saying for the "fixed" MR case. But, if the MR moves this will cause problems. Do you agree with that?=20 > > > also if the node is at home and there's a second=20 > binding for the same > > > Home address, the binding looses. MIPv6 is not consistent in > > > that case > >=20 > > =3D> Because this case does not exist in MIPv6. > >=20 > Seems you are more optimistic then I am :) I would not=20 > pretend that such a thing as misconfiguration does not exist=20 > in MIPv6. Just configure the same Home Address on 2 MNs and=20 > look? Then plug one at home and try binding the other one.=20 > Or the other way around? =3D> You mean configure the _same_ SA for both MNs? I hope not! Of course that will cause problems. I can't see how this is an analogy to what we're talking about. > > =3D> Sure if parallel paths lead to the same destination. > > This is the whole point, they may not lead to the same > > destination. You're basically asking for anycast prefixes. > > Anycast is not useful if you want to have reliable > > communication with the same host (i.e. a reachable host). > I think we agree on that. Hopefully the 2 registrations do=20 > lead to the same place, since we want the 2 MRs to share the=20 > same ingress link; or else, it's a misconfiguration - or=20 > the net admin knows that he is doing some fine trick and=20 > whatever words we put in the spec he is on his own -.=20 > Again, Nemo gives you the same level of service as OSPF or=20 > ISIS. After that it is about the professional skill of=20 > deployment people. =3D> Where is what you're saying reflected in the spec? Please point me to a reference that an admin will read. > > =3D> I'm saying that if you want to do that then apply > > it properly. At the moment it's not applied properly. > > It seems like this feature was not agreed on and things > > were left hanging in the air. I suggest that we either > > fix it or make it clear that it's not allowed. > Disagree. It was discussed at the WG. It's skill OK to voice=20 > your opposition but it was discussed. It was even=20 > specifically voiced at IETF 57, as I pointed out, and was=20 > part of nemo basic draft 00. > =20 > > =3D> I don't know what you' rereferring to here. None > > of this happens today. I think you have parallel > > redundant paths mixed up with this. They're not the > > same thing. ISP routers don't move while advertising > > a prefix which cannot be reached through them... > All I'm saying is that if a network administrator of your=20 > ISP configures a same prefix on 2 different link, you'll=20 > reach the closest one, or, if you're in the middle, you may=20 > end up reaching them alternatively. Shit happens, and the=20 > IGP in place does not prevent that at all. =3D> Huh ?? It sounds like you're talking about anycast. Please name one case where this can happen to unicast. If this happens, then if Host_A tries to talk to Host_B then sometimes it will end up talking to Host_C in the=20 middle of the connection. > Maybe all this discussion is because of a misunderstanding=20 > in the initial statement. I have in mind a configuration=20 > where an MNP is co-owned by 2 MRs that share an ingress=20 > link. The set (MR1+ingresslink+MR2) moves together as a=20 > whole. They are an atomic system. Link a plane with a wire=20 > between the 2 MRs. Maybe for you the ingress link is a fixed=20 > AP, like a hotspot at a Caf=E9, in which case the connectivity=20 > between the 2 MRs would be occasional? In that case, giving=20 > those MRs a same MNP is a misconfiguration, of course.=20 =3D> Again, I can't see any of this in the spec. I don't=20 think it's unreasonable to expect the spec to clarify this. This is something in your head and is not explained anywhere. There is a BIG difference between fixed routers using IGPs and MRs (in the general case). I know that MRs can be fixed in relation to each other but I don't expect everyone reading the spec to guess this. > > =3D> So it seems like it's not agreed on. In this case > Not because it's not agreed upon, because it's not=20 > normative. The text was judged complex and not part of the=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =20 > protocol. There was no specific behaviour associated to it... ^^^^^^^^ =3D> If you really believe the underlined text then why=20 are you insisting on not making sure that it's explicily stated in the spec that this is not supported by the protocol? Hesham From exim@www1.ietf.org Thu Mar 18 06:14:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03294 for ; Thu, 18 Mar 2004 06:14:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vTt-0003js-Ph for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 06:14:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IBEXen014362 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 06:14:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vTt-0003jZ-JC for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 06:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03286 for ; Thu, 18 Mar 2004 06:14:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vTp-0002m7-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 06:14:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vSk-0002ez-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 06:13:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3vSO-0002Y9-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 06:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vSO-0003d4-Ol; Thu, 18 Mar 2004 06:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vRi-0003b1-0u for nemo@optimus.ietf.org; Thu, 18 Mar 2004 06:12:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03177 for ; Thu, 18 Mar 2004 06:12:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vRe-0002WP-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:12:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vQj-0002Pv-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:11:18 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3vQ2-0002DI-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:10:34 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] FW: Multiple DRs on a link Date: Thu, 18 Mar 2004 06:10:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQM0XU6Xo54IxVWTfKjyGJU4uUmlQABTilQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Thierry Ernst" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> There is never 2 HAs visible on the IP layer. > >=20 > >=20 > What do you mean? If there are 2 MNs configured with a same=20 > Home Address,=20 =3D> That's a bug of course and is **_detectable_** because: A. There SAs should not both match the same HoA B. If they (SAs) do someone will complain and the misconfig will be rectified. they MAY or MAY not get the same answer from=20 > DHAAD. They MAY be registering to different HAs. It can=20 > simply depend on which HA gets the DHAAD from the Internet,=20 > and whatever load balancing algorithm they have. Do I miss=20 > something?=20 =3D> I think you are talking about a misconfig case. I'm talking about what the protocol is designed to do. And of course if people misconfig things will not work as planned. This goes for every protocol. > Nemo will act as MIP for the Home Address, and if that test=20 > is passed, Nemo will accept the duplicate prefixes, insert=20 > both routes, and leave it up to the routing protocols and=20 > the traffic splitting in place to get the packets forwarded.=20 > As a result, in most cases, you'll see packets over both=20 > tunnels. If there's no misconfiguration, the packets will=20 > end up in the same link anyway. As usual. =3D> I understand what you're saying for the "fixed" MR case. But, if the MR moves this will cause problems. Do you agree with that?=20 > > > also if the node is at home and there's a second=20 > binding for the same > > > Home address, the binding looses. MIPv6 is not consistent in > > > that case > >=20 > > =3D> Because this case does not exist in MIPv6. > >=20 > Seems you are more optimistic then I am :) I would not=20 > pretend that such a thing as misconfiguration does not exist=20 > in MIPv6. Just configure the same Home Address on 2 MNs and=20 > look? Then plug one at home and try binding the other one.=20 > Or the other way around? =3D> You mean configure the _same_ SA for both MNs? I hope not! Of course that will cause problems. I can't see how this is an analogy to what we're talking about. > > =3D> Sure if parallel paths lead to the same destination. > > This is the whole point, they may not lead to the same > > destination. You're basically asking for anycast prefixes. > > Anycast is not useful if you want to have reliable > > communication with the same host (i.e. a reachable host). > I think we agree on that. Hopefully the 2 registrations do=20 > lead to the same place, since we want the 2 MRs to share the=20 > same ingress link; or else, it's a misconfiguration - or=20 > the net admin knows that he is doing some fine trick and=20 > whatever words we put in the spec he is on his own -.=20 > Again, Nemo gives you the same level of service as OSPF or=20 > ISIS. After that it is about the professional skill of=20 > deployment people. =3D> Where is what you're saying reflected in the spec? Please point me to a reference that an admin will read. > > =3D> I'm saying that if you want to do that then apply > > it properly. At the moment it's not applied properly. > > It seems like this feature was not agreed on and things > > were left hanging in the air. I suggest that we either > > fix it or make it clear that it's not allowed. > Disagree. It was discussed at the WG. It's skill OK to voice=20 > your opposition but it was discussed. It was even=20 > specifically voiced at IETF 57, as I pointed out, and was=20 > part of nemo basic draft 00. > =20 > > =3D> I don't know what you' rereferring to here. None > > of this happens today. I think you have parallel > > redundant paths mixed up with this. They're not the > > same thing. ISP routers don't move while advertising > > a prefix which cannot be reached through them... > All I'm saying is that if a network administrator of your=20 > ISP configures a same prefix on 2 different link, you'll=20 > reach the closest one, or, if you're in the middle, you may=20 > end up reaching them alternatively. Shit happens, and the=20 > IGP in place does not prevent that at all. =3D> Huh ?? It sounds like you're talking about anycast. Please name one case where this can happen to unicast. If this happens, then if Host_A tries to talk to Host_B then sometimes it will end up talking to Host_C in the=20 middle of the connection. > Maybe all this discussion is because of a misunderstanding=20 > in the initial statement. I have in mind a configuration=20 > where an MNP is co-owned by 2 MRs that share an ingress=20 > link. The set (MR1+ingresslink+MR2) moves together as a=20 > whole. They are an atomic system. Link a plane with a wire=20 > between the 2 MRs. Maybe for you the ingress link is a fixed=20 > AP, like a hotspot at a Caf=E9, in which case the connectivity=20 > between the 2 MRs would be occasional? In that case, giving=20 > those MRs a same MNP is a misconfiguration, of course.=20 =3D> Again, I can't see any of this in the spec. I don't=20 think it's unreasonable to expect the spec to clarify this. This is something in your head and is not explained anywhere. There is a BIG difference between fixed routers using IGPs and MRs (in the general case). I know that MRs can be fixed in relation to each other but I don't expect everyone reading the spec to guess this. > > =3D> So it seems like it's not agreed on. In this case > Not because it's not agreed upon, because it's not=20 > normative. The text was judged complex and not part of the=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =20 > protocol. There was no specific behaviour associated to it... ^^^^^^^^ =3D> If you really believe the underlined text then why=20 are you insisting on not making sure that it's explicily stated in the spec that this is not supported by the protocol? Hesham From nemo-admin@ietf.org Thu Mar 18 06:17:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03417 for ; Thu, 18 Mar 2004 06:17:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vWF-0003oH-O3; Thu, 18 Mar 2004 06:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vVX-0003lf-Nu for nemo@optimus.ietf.org; Thu, 18 Mar 2004 06:16:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03378 for ; Thu, 18 Mar 2004 06:16:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vVT-0002z0-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:16:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vUi-0002t1-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:15:25 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3vTn-0002fW-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:14:27 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 06:14:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQMz3go4YnFtCsrTriZI4VynQNhtAACRiyA From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable =20 > > =3D> Right so MR2 and the network behind it become > > unreachable because MR1 is possible down! That's not > > good. > If the test works, the registration is accepted and you get the > redundancy you want.=20 > If MR1 is down, the registration for MR1 was cleaned up so=20 > the test is > not even run for MR2. > If that's your point, I do agree that there's a window if=20 > MR2 binds just > at the time MR1 dies and before the BCE for MR1 is cleaned=20 > up.=20 =3D> Thanks you! There's > also a risk of collision like MR1 and MR2 startup at the same time (I > think that that one is a bit more realistic, like you start the > entertainment power in a train or a plane). =3D> Exactly. And we're only just discussing this on email. I'd imagine that there is a few more cases than that. > It's possible to make the test a bit more complex if the=20 > list finds it > worthwhile. HA2 pings MR1 first and then pings MR2 via MR1.=20 > If MR1 does > not answer, then accept the registration for MR2. IF MR1=20 > answers but MR2 > does not, reject the registration.=20 =3D> I didn't intend to try to design a solution right now, I was trying to show that there are several problems that are not addressed in this case. Thanks, Hesham From exim@www1.ietf.org Thu Mar 18 06:18:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03455 for ; Thu, 18 Mar 2004 06:18:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vXX-0003v1-Sr for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 06:18:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IBIJuE015057 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 06:18:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vXX-0003um-J8 for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 06:18:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03451 for ; Thu, 18 Mar 2004 06:18:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vXT-0003CG-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 06:18:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vWY-00036P-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 06:17:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3vWC-00030N-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 06:16:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vWF-0003oH-O3; Thu, 18 Mar 2004 06:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vVX-0003lf-Nu for nemo@optimus.ietf.org; Thu, 18 Mar 2004 06:16:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03378 for ; Thu, 18 Mar 2004 06:16:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vVT-0002z0-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:16:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vUi-0002t1-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:15:25 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3vTn-0002fW-00 for nemo@ietf.org; Thu, 18 Mar 2004 06:14:27 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 06:14:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQMz3go4YnFtCsrTriZI4VynQNhtAACRiyA From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 > > =3D> Right so MR2 and the network behind it become > > unreachable because MR1 is possible down! That's not > > good. > If the test works, the registration is accepted and you get the > redundancy you want.=20 > If MR1 is down, the registration for MR1 was cleaned up so=20 > the test is > not even run for MR2. > If that's your point, I do agree that there's a window if=20 > MR2 binds just > at the time MR1 dies and before the BCE for MR1 is cleaned=20 > up.=20 =3D> Thanks you! There's > also a risk of collision like MR1 and MR2 startup at the same time (I > think that that one is a bit more realistic, like you start the > entertainment power in a train or a plane). =3D> Exactly. And we're only just discussing this on email. I'd imagine that there is a few more cases than that. > It's possible to make the test a bit more complex if the=20 > list finds it > worthwhile. HA2 pings MR1 first and then pings MR2 via MR1.=20 > If MR1 does > not answer, then accept the registration for MR2. IF MR1=20 > answers but MR2 > does not, reject the registration.=20 =3D> I didn't intend to try to design a solution right now, I was trying to show that there are several problems that are not addressed in this case. Thanks, Hesham From nemo-admin@ietf.org Thu Mar 18 07:55:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07352 for ; Thu, 18 Mar 2004 07:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x38-0001pm-00; Thu, 18 Mar 2004 07:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x2S-0001of-I2 for nemo@optimus.ietf.org; Thu, 18 Mar 2004 07:54:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07309 for ; Thu, 18 Mar 2004 07:54:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3x2R-0007Oa-00 for nemo@ietf.org; Thu, 18 Mar 2004 07:54:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3x1V-0007Hh-00 for nemo@ietf.org; Thu, 18 Mar 2004 07:53:21 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3x0Y-00075V-00 for nemo@ietf.org; Thu, 18 Mar 2004 07:52:22 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 04:57:03 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2ICpJib000871; Thu, 18 Mar 2004 13:51:20 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 12:51:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 12:51:49 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQMz3go4YnFtCsrTriZI4VynQNhtAACRiyAAAOZNwA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 12:51:50.0436 (UTC) FILETIME=[C7EC7E40:01C40CE7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: jeudi 18 mars 2004 12:14 > To: Pascal Thubert (pthubert); IETF NEMO WG > Subject: RE: DND test [was Assigning the same prefix to multiple MRs] >=20 >=20 >=20 > > > =3D> Right so MR2 and the network behind it become > > > unreachable because MR1 is possible down! That's not > > > good. >=20 > > If the test works, the registration is accepted and you get the > > redundancy you want. >=20 > > If MR1 is down, the registration for MR1 was cleaned up so > > the test is > > not even run for MR2. > > If that's your point, I do agree that there's a window if > > MR2 binds just > > at the time MR1 dies and before the BCE for MR1 is cleaned > > up. >=20 > =3D> Thanks you! >=20 >=20 > There's > > also a risk of collision like MR1 and MR2 startup at the same time (I > > think that that one is a bit more realistic, like you start the > > entertainment power in a train or a plane). >=20 > =3D> Exactly. And we're only just discussing this on email. > I'd imagine that there is a few more cases than that. >=20 > > It's possible to make the test a bit more complex if the > > list finds it > > worthwhile. HA2 pings MR1 first and then pings MR2 via MR1. > > If MR1 does > > not answer, then accept the registration for MR2. IF MR1 > > answers but MR2 > > does not, reject the registration. >=20 > =3D> I didn't intend to try to design a solution right now, > I was trying to show that there are several problems that > are not addressed in this case. >=20 Agreed: The test was not designed yet. The requirement for the test is still not agreed upon. So if this thread ends up anywhere, maybe it's to an answer to that question: Is there a need for a Duplicate Network Detection test that would check that when a prefix is registered twice, you end up on the same link for both registrations? Pascal From exim@www1.ietf.org Thu Mar 18 07:57:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07410 for ; Thu, 18 Mar 2004 07:57:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x4b-00027L-Ic for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 07:56:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ICuXTX008133 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 07:56:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x4b-000276-BS for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 07:56:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07404 for ; Thu, 18 Mar 2004 07:56:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3x4a-0007fA-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 07:56:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3x3a-0007Y7-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 07:55:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3x3B-0007Qz-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 07:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x38-0001pm-00; Thu, 18 Mar 2004 07:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x2S-0001of-I2 for nemo@optimus.ietf.org; Thu, 18 Mar 2004 07:54:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07309 for ; Thu, 18 Mar 2004 07:54:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3x2R-0007Oa-00 for nemo@ietf.org; Thu, 18 Mar 2004 07:54:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3x1V-0007Hh-00 for nemo@ietf.org; Thu, 18 Mar 2004 07:53:21 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3x0Y-00075V-00 for nemo@ietf.org; Thu, 18 Mar 2004 07:52:22 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 04:57:03 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2ICpJib000871; Thu, 18 Mar 2004 13:51:20 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 12:51:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 12:51:49 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQMz3go4YnFtCsrTriZI4VynQNhtAACRiyAAAOZNwA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 12:51:50.0436 (UTC) FILETIME=[C7EC7E40:01C40CE7] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: jeudi 18 mars 2004 12:14 > To: Pascal Thubert (pthubert); IETF NEMO WG > Subject: RE: DND test [was Assigning the same prefix to multiple MRs] >=20 >=20 >=20 > > > =3D> Right so MR2 and the network behind it become > > > unreachable because MR1 is possible down! That's not > > > good. >=20 > > If the test works, the registration is accepted and you get the > > redundancy you want. >=20 > > If MR1 is down, the registration for MR1 was cleaned up so > > the test is > > not even run for MR2. > > If that's your point, I do agree that there's a window if > > MR2 binds just > > at the time MR1 dies and before the BCE for MR1 is cleaned > > up. >=20 > =3D> Thanks you! >=20 >=20 > There's > > also a risk of collision like MR1 and MR2 startup at the same time (I > > think that that one is a bit more realistic, like you start the > > entertainment power in a train or a plane). >=20 > =3D> Exactly. And we're only just discussing this on email. > I'd imagine that there is a few more cases than that. >=20 > > It's possible to make the test a bit more complex if the > > list finds it > > worthwhile. HA2 pings MR1 first and then pings MR2 via MR1. > > If MR1 does > > not answer, then accept the registration for MR2. IF MR1 > > answers but MR2 > > does not, reject the registration. >=20 > =3D> I didn't intend to try to design a solution right now, > I was trying to show that there are several problems that > are not addressed in this case. >=20 Agreed: The test was not designed yet. The requirement for the test is still not agreed upon. So if this thread ends up anywhere, maybe it's to an answer to that question: Is there a need for a Duplicate Network Detection test that would check that when a prefix is registered twice, you end up on the same link for both registrations? Pascal From nemo-admin@ietf.org Thu Mar 18 08:07:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08020 for ; Thu, 18 Mar 2004 08:07:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xEi-0002pe-B1; Thu, 18 Mar 2004 08:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xE2-0002oW-Gw for nemo@optimus.ietf.org; Thu, 18 Mar 2004 08:06:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07982 for ; Thu, 18 Mar 2004 08:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xE1-00016A-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:06:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xD4-0000z8-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:05:18 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3xCC-0000lz-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:04:24 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 08:03:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM58ima5IlfCYQQfaaS/P4WSJfswAAH64w From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Agreed: > The test was not designed yet. The requirement for the=20 > test is still > not agreed upon. So if this thread ends up anywhere, maybe it's to an > answer to that question: Is there a need for a Duplicate Network > Detection test that would check that when a prefix is=20 > registered twice, > you end up on the same link for both registrations? =3D> Hmmm, interesting question. However, I think we're skipping a few steps in attempting to answer this question. Your question is assuming that the preferred solution for=20 a multihome monet (sorry I just don't thing nemo makes english sense in this sentence) is to assign the same MNP to all MRs. Given this assumption, it's natural to ask the question above.=20 On the other hand, if we ask: What is the best interim=20 step for multihoming in nemo, we might end up with a different solution and consequently a different set of=20 questions. I preferred to ask the latter question than the first.=20 Personally, I think it's a lot cleaner to have one prefix per MR and somehow solve the ingress filtering problem. This is not so difficult in the case where the 2 MRs belong to the same home domain/link. For instance, an=20 ISP might not filter (in the MR's HA) on any of the=20 prefixes that are assigned to its domain. So basically it forwards any packet coming from any prefix derived from ISP_PREFIX::/26. This would solve the simple multihoming case where 2 MRs belong to the same home admin domain. I think this will solve the problem with the scenarios=20 that you mention, i.e. plane, train, bus ...etc. Do you think this will work? This requires hardly any changes to the spec. We can clearly do without changing anything, except for mentioning that 2 MRs do not share=20 the same prefix. I misstated that before to say 1 prefix per MR, when what I really meant was two MRs do not share the same prefix. Hesham >=20 > Pascal >=20 From exim@www1.ietf.org Thu Mar 18 08:08:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08080 for ; Thu, 18 Mar 2004 08:08:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xG8-0003C6-4v for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 08:08:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ID8SmM012272 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 08:08:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xG7-0003Br-UW for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 08:08:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08077 for ; Thu, 18 Mar 2004 08:08:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xG7-0001L9-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 08:08:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xFF-0001Eg-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 08:07:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3xEl-00017t-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 08:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xEi-0002pe-B1; Thu, 18 Mar 2004 08:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xE2-0002oW-Gw for nemo@optimus.ietf.org; Thu, 18 Mar 2004 08:06:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07982 for ; Thu, 18 Mar 2004 08:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xE1-00016A-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:06:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xD4-0000z8-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:05:18 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3xCC-0000lz-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:04:24 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 08:03:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM58ima5IlfCYQQfaaS/P4WSJfswAAH64w From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Agreed: > The test was not designed yet. The requirement for the=20 > test is still > not agreed upon. So if this thread ends up anywhere, maybe it's to an > answer to that question: Is there a need for a Duplicate Network > Detection test that would check that when a prefix is=20 > registered twice, > you end up on the same link for both registrations? =3D> Hmmm, interesting question. However, I think we're skipping a few steps in attempting to answer this question. Your question is assuming that the preferred solution for=20 a multihome monet (sorry I just don't thing nemo makes english sense in this sentence) is to assign the same MNP to all MRs. Given this assumption, it's natural to ask the question above.=20 On the other hand, if we ask: What is the best interim=20 step for multihoming in nemo, we might end up with a different solution and consequently a different set of=20 questions. I preferred to ask the latter question than the first.=20 Personally, I think it's a lot cleaner to have one prefix per MR and somehow solve the ingress filtering problem. This is not so difficult in the case where the 2 MRs belong to the same home domain/link. For instance, an=20 ISP might not filter (in the MR's HA) on any of the=20 prefixes that are assigned to its domain. So basically it forwards any packet coming from any prefix derived from ISP_PREFIX::/26. This would solve the simple multihoming case where 2 MRs belong to the same home admin domain. I think this will solve the problem with the scenarios=20 that you mention, i.e. plane, train, bus ...etc. Do you think this will work? This requires hardly any changes to the spec. We can clearly do without changing anything, except for mentioning that 2 MRs do not share=20 the same prefix. I misstated that before to say 1 prefix per MR, when what I really meant was two MRs do not share the same prefix. Hesham >=20 > Pascal >=20 From nemo-admin@ietf.org Thu Mar 18 08:13:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08247 for ; Thu, 18 Mar 2004 08:13:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xKW-0003ci-Ty; Thu, 18 Mar 2004 08:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xJx-0003Rp-Uz for nemo@optimus.ietf.org; Thu, 18 Mar 2004 08:12:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08192 for ; Thu, 18 Mar 2004 08:12:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xJw-0001oW-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:12:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xJ0-0001iG-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:11:26 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1B3xIh-0001br-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:11:07 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i2ID7bHV008286; Thu, 18 Mar 2004 06:07:38 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2ID71Mg008884; Thu, 18 Mar 2004 07:07:02 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B606585552F; Thu, 18 Mar 2004 14:07:49 +0100 (CET) Message-ID: <40599F24.6000602@motorola.com> Date: Thu, 18 Mar 2004 14:07:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Soliman Hesham , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080009080604000605090503" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms080009080604000605090503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Agreed: > The test was not designed yet. The requirement for the test is still > not agreed upon. So if this thread ends up anywhere, maybe it's to an > answer to that question: Is there a need for a Duplicate Network > Detection test that would check that when a prefix is registered twice, > you end up on the same link for both registrations? Good question. Today, I can manually enter two routing table entries towards the same prefix but through different next-hops. Is there a need for the system to check when a prefix is registered twice and warn me I did so, or ban me from doing so? Alex --------------ms080009080604000605090503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA/MwggNcoAMCAQICAwp9BjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwNjEwMDU0M1oX DTA0MDgwNTEwMDU0M1owgdkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIDAe BgkqhkiG9w0BCQEWEXBldHJlc2N1QGllZWUub3JnMR8wHQYJKoZIhvcNAQkBFhBwZXRyZXNj dUBhY20ub3JnMSIwIAYJKoZIhvcNAQkBFhNwZXRyZXNjdUBhbHRlcm4ub3JnMR8wHQYJKoZI hvcNAQkBFhBwZXRyZXNjdUBmcmVlLmZyMS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0 cmVzY3VAbW90b3JvbGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9GSD rMCK1KspPruK+tgZspBkqVT5ScPS1CEgOr2MVSvbWP+GbZxYK8k87/y5vJ40OifBr9m56Hio zk7pmqffAEGSGy9ettQD9xocBQkA7bJFRLeOCdM6UXqjmwPstIBao0wQkOJTo39MliRGrS3a YUpA6/s7FtuhzPFLd7B4UV3e6fqNVWQvptNHCndWDv9o4EDcntzj7f3EHlHSl+hHukBSoDlL s02b+az8n47tq4nIyfOYMvF2EmOACFGJGWJ7hDz9SmjqEzNgSjUD68rOdBMcs2yRX8hSFuJE vqSTAJ69AMy7GGWaA326mxD4mu53fniPFOfFd6BuFnIGne0KCwIDAQABo4GJMIGGMHYGA1Ud EQRvMG2BEXBldHJlc2N1QGllZWUub3JngRBwZXRyZXNjdUBhY20ub3JngRNwZXRyZXNjdUBh bHRlcm4ub3JngRBwZXRyZXNjdUBmcmVlLmZygR9hbGV4YW5kcnUucGV0cmVzY3VAbW90b3Jv bGEuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAzh0dPi0yv2hYyuqjEbzM UgbSqTG/sdV1NblLLiZUxaNHtY3+dPOI8NduSvxPqGHhCd494vJQEa1MmUceKDMpmAod68SQ rocYRY95k8crU/47zpbkar3P56OgW6NbARhBhHkqGemB5b2q+zGZJresGpz2W/LZ+2hX8DvU HQgvgywwggPzMIIDXKADAgECAgMKfQYwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29u YWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA4MDYxMDA1NDNaFw0wNDA4MDUxMDA1 NDNaMIHZMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSAwHgYJKoZIhvcNAQkB FhFwZXRyZXNjdUBpZWVlLm9yZzEfMB0GCSqGSIb3DQEJARYQcGV0cmVzY3VAYWNtLm9yZzEi MCAGCSqGSIb3DQEJARYTcGV0cmVzY3VAYWx0ZXJuLm9yZzEfMB0GCSqGSIb3DQEJARYQcGV0 cmVzY3VAZnJlZS5mcjEuMCwGCSqGSIb3DQEJARYfYWxleGFuZHJ1LnBldHJlc2N1QG1vdG9y b2xhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPRkg6zAitSrKT67ivrY GbKQZKlU+UnD0tQhIDq9jFUr21j/hm2cWCvJPO/8ubyeNDonwa/Zueh4qM5O6Zqn3wBBkhsv XrbUA/caHAUJAO2yRUS3jgnTOlF6o5sD7LSAWqNMEJDiU6N/TJYkRq0t2mFKQOv7Oxbboczx S3eweFFd3un6jVVkL6bTRwp3Vg7/aOBA3J7c4+39xB5R0pfoR7pAUqA5S7NNm/ms/J+O7auJ yMnzmDLxdhJjgAhRiRlie4Q8/Upo6hMzYEo1A+vKznQTHLNskV/IUhbiRL6kkwCevQDMuxhl mgN9upsQ+Jrud354jxTnxXegbhZyBp3tCgsCAwEAAaOBiTCBhjB2BgNVHREEbzBtgRFwZXRy ZXNjdUBpZWVlLm9yZ4EQcGV0cmVzY3VAYWNtLm9yZ4ETcGV0cmVzY3VAYWx0ZXJuLm9yZ4EQ cGV0cmVzY3VAZnJlZS5mcoEfYWxleGFuZHJ1LnBldHJlc2N1QG1vdG9yb2xhLmNvbTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAM4dHT4tMr9oWMrqoxG8zFIG0qkxv7HVdTW5 Sy4mVMWjR7WN/nTziPDXbkr8T6hh4QnePeLyUBGtTJlHHigzKZgKHevEkK6HGEWPeZPHK1P+ O86W5Gq9z+ejoFujWwEYQYR5KhnpgeW9qvsxmSa3rBqc9lvy2ftoV/A71B0IL4MsMYID1TCC A9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCn0G MAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA0MDMxODEzMDc0OFowIwYJKoZIhvcNAQkEMRYEFJKgNXsOwRNY3C1ksRxSePvriBSt MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCn0GMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMK fQYwDQYJKoZIhvcNAQEBBQAEggEAXU9fu2uhgZ6/QAWY7/kVhdPkRJFKT8v8U6i3I6AmRYcV fdwJzPP6XHGYPRGhjHfxAPI08yAcm5/WzOQbcetv8zXrXh0qb02QU1E7Pmn3HrS0ykD+a9e+ 3+gmDot9VS2wTBVvtN1JIT+fcj4tX8378FfHhl3pyWRueO7H5m8EdkyBlDgElzWR/kqCl6yH uf1k+cuoYwimZAdvZzBvpszyvNX4JlXjS8TlU2ECohbsnH9m7EbyeavqFsM3XBgCjYqG9+0f PIh0w1FNl2yhdVp8Ae8/slE0Yop967IdnFzlBUr1IHCp6o6dT/nq7qcslPDog/GJslp3b1SD 89jIDBaH0gAAAAAAAA== --------------ms080009080604000605090503-- From exim@www1.ietf.org Thu Mar 18 08:15:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08342 for ; Thu, 18 Mar 2004 08:15:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xM1-0003pV-Ov for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 08:14:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IDEXFw014715 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 08:14:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xM1-0003pG-JK for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 08:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08313 for ; Thu, 18 Mar 2004 08:14:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xM0-00025D-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 08:14:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xL6-0001xr-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 08:13:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3xKY-0001px-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 08:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xKW-0003ci-Ty; Thu, 18 Mar 2004 08:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xJx-0003Rp-Uz for nemo@optimus.ietf.org; Thu, 18 Mar 2004 08:12:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08192 for ; Thu, 18 Mar 2004 08:12:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xJw-0001oW-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:12:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xJ0-0001iG-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:11:26 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1B3xIh-0001br-00 for nemo@ietf.org; Thu, 18 Mar 2004 08:11:07 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i2ID7bHV008286; Thu, 18 Mar 2004 06:07:38 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2ID71Mg008884; Thu, 18 Mar 2004 07:07:02 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B606585552F; Thu, 18 Mar 2004 14:07:49 +0100 (CET) Message-ID: <40599F24.6000602@motorola.com> Date: Thu, 18 Mar 2004 14:07:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Soliman Hesham , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080009080604000605090503" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms080009080604000605090503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Agreed: > The test was not designed yet. The requirement for the test is still > not agreed upon. So if this thread ends up anywhere, maybe it's to an > answer to that question: Is there a need for a Duplicate Network > Detection test that would check that when a prefix is registered twice, > you end up on the same link for both registrations? Good question. Today, I can manually enter two routing table entries towards the same prefix but through different next-hops. Is there a need for the system to check when a prefix is registered twice and warn me I did so, or ban me from doing so? Alex --------------ms080009080604000605090503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCA/MwggNcoAMCAQICAwp9BjANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwNjEwMDU0M1oX DTA0MDgwNTEwMDU0M1owgdkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIDAe BgkqhkiG9w0BCQEWEXBldHJlc2N1QGllZWUub3JnMR8wHQYJKoZIhvcNAQkBFhBwZXRyZXNj dUBhY20ub3JnMSIwIAYJKoZIhvcNAQkBFhNwZXRyZXNjdUBhbHRlcm4ub3JnMR8wHQYJKoZI hvcNAQkBFhBwZXRyZXNjdUBmcmVlLmZyMS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0 cmVzY3VAbW90b3JvbGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9GSD rMCK1KspPruK+tgZspBkqVT5ScPS1CEgOr2MVSvbWP+GbZxYK8k87/y5vJ40OifBr9m56Hio zk7pmqffAEGSGy9ettQD9xocBQkA7bJFRLeOCdM6UXqjmwPstIBao0wQkOJTo39MliRGrS3a YUpA6/s7FtuhzPFLd7B4UV3e6fqNVWQvptNHCndWDv9o4EDcntzj7f3EHlHSl+hHukBSoDlL s02b+az8n47tq4nIyfOYMvF2EmOACFGJGWJ7hDz9SmjqEzNgSjUD68rOdBMcs2yRX8hSFuJE vqSTAJ69AMy7GGWaA326mxD4mu53fniPFOfFd6BuFnIGne0KCwIDAQABo4GJMIGGMHYGA1Ud EQRvMG2BEXBldHJlc2N1QGllZWUub3JngRBwZXRyZXNjdUBhY20ub3JngRNwZXRyZXNjdUBh bHRlcm4ub3JngRBwZXRyZXNjdUBmcmVlLmZygR9hbGV4YW5kcnUucGV0cmVzY3VAbW90b3Jv bGEuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAzh0dPi0yv2hYyuqjEbzM UgbSqTG/sdV1NblLLiZUxaNHtY3+dPOI8NduSvxPqGHhCd494vJQEa1MmUceKDMpmAod68SQ rocYRY95k8crU/47zpbkar3P56OgW6NbARhBhHkqGemB5b2q+zGZJresGpz2W/LZ+2hX8DvU HQgvgywwggPzMIIDXKADAgECAgMKfQYwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29u YWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA4MDYxMDA1NDNaFw0wNDA4MDUxMDA1 NDNaMIHZMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSAwHgYJKoZIhvcNAQkB FhFwZXRyZXNjdUBpZWVlLm9yZzEfMB0GCSqGSIb3DQEJARYQcGV0cmVzY3VAYWNtLm9yZzEi MCAGCSqGSIb3DQEJARYTcGV0cmVzY3VAYWx0ZXJuLm9yZzEfMB0GCSqGSIb3DQEJARYQcGV0 cmVzY3VAZnJlZS5mcjEuMCwGCSqGSIb3DQEJARYfYWxleGFuZHJ1LnBldHJlc2N1QG1vdG9y b2xhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPRkg6zAitSrKT67ivrY GbKQZKlU+UnD0tQhIDq9jFUr21j/hm2cWCvJPO/8ubyeNDonwa/Zueh4qM5O6Zqn3wBBkhsv XrbUA/caHAUJAO2yRUS3jgnTOlF6o5sD7LSAWqNMEJDiU6N/TJYkRq0t2mFKQOv7Oxbboczx S3eweFFd3un6jVVkL6bTRwp3Vg7/aOBA3J7c4+39xB5R0pfoR7pAUqA5S7NNm/ms/J+O7auJ yMnzmDLxdhJjgAhRiRlie4Q8/Upo6hMzYEo1A+vKznQTHLNskV/IUhbiRL6kkwCevQDMuxhl mgN9upsQ+Jrud354jxTnxXegbhZyBp3tCgsCAwEAAaOBiTCBhjB2BgNVHREEbzBtgRFwZXRy ZXNjdUBpZWVlLm9yZ4EQcGV0cmVzY3VAYWNtLm9yZ4ETcGV0cmVzY3VAYWx0ZXJuLm9yZ4EQ cGV0cmVzY3VAZnJlZS5mcoEfYWxleGFuZHJ1LnBldHJlc2N1QG1vdG9yb2xhLmNvbTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAM4dHT4tMr9oWMrqoxG8zFIG0qkxv7HVdTW5 Sy4mVMWjR7WN/nTziPDXbkr8T6hh4QnePeLyUBGtTJlHHigzKZgKHevEkK6HGEWPeZPHK1P+ O86W5Gq9z+ejoFujWwEYQYR5KhnpgeW9qvsxmSa3rBqc9lvy2ftoV/A71B0IL4MsMYID1TCC A9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCn0G MAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA0MDMxODEzMDc0OFowIwYJKoZIhvcNAQkEMRYEFJKgNXsOwRNY3C1ksRxSePvriBSt MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYG A1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCn0GMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMK fQYwDQYJKoZIhvcNAQEBBQAEggEAXU9fu2uhgZ6/QAWY7/kVhdPkRJFKT8v8U6i3I6AmRYcV fdwJzPP6XHGYPRGhjHfxAPI08yAcm5/WzOQbcetv8zXrXh0qb02QU1E7Pmn3HrS0ykD+a9e+ 3+gmDot9VS2wTBVvtN1JIT+fcj4tX8378FfHhl3pyWRueO7H5m8EdkyBlDgElzWR/kqCl6yH uf1k+cuoYwimZAdvZzBvpszyvNX4JlXjS8TlU2ECohbsnH9m7EbyeavqFsM3XBgCjYqG9+0f PIh0w1FNl2yhdVp8Ae8/slE0Yop967IdnFzlBUr1IHCp6o6dT/nq7qcslPDog/GJslp3b1SD 89jIDBaH0gAAAAAAAA== --------------ms080009080604000605090503-- From nemo-admin@ietf.org Thu Mar 18 09:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11697 for ; Thu, 18 Mar 2004 09:06:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y9q-0008OK-Qb; Thu, 18 Mar 2004 09:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y9F-0008NC-Nh for nemo@optimus.ietf.org; Thu, 18 Mar 2004 09:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11637 for ; Thu, 18 Mar 2004 09:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3y9E-0001zr-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:05:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3y8K-0001sm-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:04:29 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3y7c-0001eG-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:03:44 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 06:08:26 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IE2eib025936; Thu, 18 Mar 2004 15:02:42 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 14:03:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Thu, 18 Mar 2004 14:03:11 -0000 Message-ID: Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQM0XU6Xo54IxVWTfKjyGJU4uUmlQABTilQAAQz9zA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Thierry Ernst" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 14:03:11.0934 (UTC) FILETIME=[BFE53DE0:01C40CF1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable =20 =20 > > > =3D> There is never 2 HAs visible on the IP layer. Still disagree, see later > > > > > > > > What do you mean? If there are 2 MNs configured with a same > > Home Address, >=20 > =3D> That's a bug of course and is **_detectable_** because: > A. There SAs should not both match the same HoA > B. If they (SAs) do someone will complain and the misconfig will > be rectified. >=20 > they MAY or MAY not get the same answer from > > DHAAD. They MAY be registering to different HAs. It can > > simply depend on which HA gets the DHAAD from the Internet, > > and whatever load balancing algorithm they have. Do I miss > > something? >=20 > =3D> I think you are talking about a misconfig case. I'm > talking about what the protocol is designed to do. And I'm not sure about what you mean MIP is designed to do here. I see DHAAD = as a potential way to load balance bindings between HAs. I believe that = MIPv6 is meant for that (3rd bullet page 103 asks for an randomization = that actively load balances BCEs over HAs of equal preference). When you = have multiple HAs, it is most probable that overtime, the BCEs will be = distributed somehow between the HAs of equal highest preference. If you = disagree with this statement, I'd wish to discuss that on the MIP6 ML. = If you agree with this statement, then you see how a binding for a same = Home Address is accepted by the same HA and rejected by a second HA.=20 > of course if people misconfig things will not work > as planned. This goes for every protocol. >=20 Sure.=20 MRs with a same prefix and moving relatively to each other is a = misconfiguration. >From plain common sense, isn't it? And yes, long as we're talking misconfiguration, I'm happy with the MIP6 = protocol as it is, if there's a way to detect the situation and alert. = Thus my proposal for an optional DND test for Nemo. But at the end of = the day, your case B above applies to Nemo if the prefix is duplicated, = "someone will complain and the misconfig will be rectified". So Nemo is = nothing better or worse than MIP6 or IGPs, it inherits from them. > > Nemo will act as MIP for the Home Address, and if that test > > is passed, Nemo will accept the duplicate prefixes, insert > > both routes, and leave it up to the routing protocols and > > the traffic splitting in place to get the packets forwarded. > > As a result, in most cases, you'll see packets over both > > tunnels. If there's no misconfiguration, the packets will > > end up in the same link anyway. As usual. >=20 > =3D> I understand what you're saying for the "fixed" MR case. > But, if the MR moves this will cause problems. Do you agree > with that? I meant as I said that the MR-link-MR is an atomic system moving = together relative to the infrastructure. Like in a plane. And they MUST = NOT split, otherwise I do agree it's a misconfiguration -or a very very = specific trick-. > > > > also if the node is at home and there's a second > > binding for the same > > > > Home address, the binding looses. MIPv6 is not consistent in > > > > that case > > > > > > =3D> Because this case does not exist in MIPv6. > > > > > Seems you are more optimistic then I am :) I would not > > pretend that such a thing as misconfiguration does not exist > > in MIPv6. Just configure the same Home Address on 2 MNs and > > look? Then plug one at home and try binding the other one. > > Or the other way around? >=20 > =3D> You mean configure the _same_ SA for both MNs? I hope > not! Of course that will cause problems. I can't see how > this is an analogy to what we're talking about. No, because the SA is associated to the Home Address. Nemo does not = change MIP for this. The 2 MRs have 2 different Home Addresses. But The = MNP is authorized for one or more Home Addresses. The 2 Home Addresses = can be from the same MNP, but they should have different SAs. >=20 > > > =3D> Sure if parallel paths lead to the same destination. > > > This is the whole point, they may not lead to the same > > > destination. You're basically asking for anycast prefixes. > > > Anycast is not useful if you want to have reliable > > > communication with the same host (i.e. a reachable host). >=20 > > I think we agree on that. Hopefully the 2 registrations do > > lead to the same place, since we want the 2 MRs to share the > > same ingress link; or else, it's a misconfiguration - or > > the net admin knows that he is doing some fine trick and > > whatever words we put in the spec he is on his own -. > > Again, Nemo gives you the same level of service as OSPF or > > ISIS. After that it is about the professional skill of > > deployment people. >=20 > =3D> Where is what you're saying reflected in the spec? Please > point me to a reference that an admin will read. Can I say common sense? Part of the nemo way is to split the purely = normative part (to become standard track) and the usage recommendations = (aimed at informational) in separate drafts. I understand that you = recommend a usage draft for Nemo multihoming. I do agree. Maybe it's a = bit early because we are missing the full picture. But maybe also it's = good to document what we already know... >=20 > > > =3D> I'm saying that if you want to do that then apply > > > it properly. At the moment it's not applied properly. > > > It seems like this feature was not agreed on and things > > > were left hanging in the air. I suggest that we either > > > fix it or make it clear that it's not allowed. > > Disagree. It was discussed at the WG. It's skill OK to voice > > your opposition but it was discussed. It was even > > specifically voiced at IETF 57, as I pointed out, and was > > part of nemo basic draft 00. > > >=20 > > > =3D> I don't know what you' rereferring to here. None > > > of this happens today. I think you have parallel > > > redundant paths mixed up with this. They're not the > > > same thing. ISP routers don't move while advertising > > > a prefix which cannot be reached through them... >=20 > > All I'm saying is that if a network administrator of your > > ISP configures a same prefix on 2 different link, you'll > > reach the closest one, or, if you're in the middle, you may > > end up reaching them alternatively. Shit happens, and the > > IGP in place does not prevent that at all. >=20 > =3D> Huh ?? It sounds like you're talking about anycast. > Please name one case where this can happen to unicast. > If this happens, then if Host_A tries to talk to Host_B > then sometimes it will end up talking to Host_C in the > middle of the connection. I was trying to say that IGPs do not generally include configuration = error detection. And that it is already possible to misconfigure a = network and cause such a situation that a subnetwork is seen at 2 = different places, so Nemo is nothing new, and that does not mean that = Nemo is incomplete.=20 There are some rules and these rules are not necessarily enforced by the = protocols. Rather, they are part of the know how of network designers. = Duplication of a subnet is avoided in general, and can be done is very = particular cases. And this happens outside of the scope of the IGP. This = is a deployment issue. >=20 > > Maybe all this discussion is because of a misunderstanding > > in the initial statement. I have in mind a configuration > > where an MNP is co-owned by 2 MRs that share an ingress > > link. The set (MR1+ingresslink+MR2) moves together as a > > whole. They are an atomic system. Link a plane with a wire > > between the 2 MRs. Maybe for you the ingress link is a fixed > > AP, like a hotspot at a Caf=E9, in which case the connectivity > > between the 2 MRs would be occasional? In that case, giving > > those MRs a same MNP is a misconfiguration, of course. >=20 > =3D> Again, I can't see any of this in the spec. I don't > think it's unreasonable to expect the spec to clarify > this. This is something in your head and is not explained > anywhere. There is a BIG difference between fixed routers > using IGPs and MRs (in the general case). I know that > MRs can be fixed in relation to each other but I > don't expect everyone reading the spec to guess this. Well seems that the authors collectively guessed otherwise. Ubiquity of = a prefix is a very specific thing. But then again, I'm not against a = usage draft on multihoming that would word that giving how the protocol = is expected to be used. We already did that for the home network = configuration. That's part of the spirit. >=20 > > > =3D> So it seems like it's not agreed on. In this case >=20 > > Not because it's not agreed upon, because it's not > > normative. The text was judged complex and not part of the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > protocol. There was no specific behaviour associated to it... > ^^^^^^^^ > =3D> If you really believe the underlined text then why > are you insisting on not making sure that it's explicily > stated in the spec that this is not supported by the protocol? >=20 Well, I'm happy with the nemo text the way it stands. I agreed to remove = the original text that said that nemo is open to multihoming. Because it = is, even if you do not write it down. That's what I meant here. What's = not part of the protocol was removed from the draft, but can be place in = usage drafts. Pascal From exim@www1.ietf.org Thu Mar 18 09:07:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11741 for ; Thu, 18 Mar 2004 09:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yBD-00005g-24 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 09:07:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IE7QW4000342 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 09:07:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yBB-00005R-Hy for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 09:07:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11735 for ; Thu, 18 Mar 2004 09:07:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yBA-0002Dw-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 09:07:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yAI-000286-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 09:06:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3y9s-00021R-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 09:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y9q-0008OK-Qb; Thu, 18 Mar 2004 09:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y9F-0008NC-Nh for nemo@optimus.ietf.org; Thu, 18 Mar 2004 09:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11637 for ; Thu, 18 Mar 2004 09:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3y9E-0001zr-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:05:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3y8K-0001sm-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:04:29 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3y7c-0001eG-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:03:44 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 06:08:26 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IE2eib025936; Thu, 18 Mar 2004 15:02:42 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 14:03:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Thu, 18 Mar 2004 14:03:11 -0000 Message-ID: Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQM0XU6Xo54IxVWTfKjyGJU4uUmlQABTilQAAQz9zA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Thierry Ernst" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 14:03:11.0934 (UTC) FILETIME=[BFE53DE0:01C40CF1] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 =20 > > > =3D> There is never 2 HAs visible on the IP layer. Still disagree, see later > > > > > > > > What do you mean? If there are 2 MNs configured with a same > > Home Address, >=20 > =3D> That's a bug of course and is **_detectable_** because: > A. There SAs should not both match the same HoA > B. If they (SAs) do someone will complain and the misconfig will > be rectified. >=20 > they MAY or MAY not get the same answer from > > DHAAD. They MAY be registering to different HAs. It can > > simply depend on which HA gets the DHAAD from the Internet, > > and whatever load balancing algorithm they have. Do I miss > > something? >=20 > =3D> I think you are talking about a misconfig case. I'm > talking about what the protocol is designed to do. And I'm not sure about what you mean MIP is designed to do here. I see DHAAD = as a potential way to load balance bindings between HAs. I believe that = MIPv6 is meant for that (3rd bullet page 103 asks for an randomization = that actively load balances BCEs over HAs of equal preference). When you = have multiple HAs, it is most probable that overtime, the BCEs will be = distributed somehow between the HAs of equal highest preference. If you = disagree with this statement, I'd wish to discuss that on the MIP6 ML. = If you agree with this statement, then you see how a binding for a same = Home Address is accepted by the same HA and rejected by a second HA.=20 > of course if people misconfig things will not work > as planned. This goes for every protocol. >=20 Sure.=20 MRs with a same prefix and moving relatively to each other is a = misconfiguration. >From plain common sense, isn't it? And yes, long as we're talking misconfiguration, I'm happy with the MIP6 = protocol as it is, if there's a way to detect the situation and alert. = Thus my proposal for an optional DND test for Nemo. But at the end of = the day, your case B above applies to Nemo if the prefix is duplicated, = "someone will complain and the misconfig will be rectified". So Nemo is = nothing better or worse than MIP6 or IGPs, it inherits from them. > > Nemo will act as MIP for the Home Address, and if that test > > is passed, Nemo will accept the duplicate prefixes, insert > > both routes, and leave it up to the routing protocols and > > the traffic splitting in place to get the packets forwarded. > > As a result, in most cases, you'll see packets over both > > tunnels. If there's no misconfiguration, the packets will > > end up in the same link anyway. As usual. >=20 > =3D> I understand what you're saying for the "fixed" MR case. > But, if the MR moves this will cause problems. Do you agree > with that? I meant as I said that the MR-link-MR is an atomic system moving = together relative to the infrastructure. Like in a plane. And they MUST = NOT split, otherwise I do agree it's a misconfiguration -or a very very = specific trick-. > > > > also if the node is at home and there's a second > > binding for the same > > > > Home address, the binding looses. MIPv6 is not consistent in > > > > that case > > > > > > =3D> Because this case does not exist in MIPv6. > > > > > Seems you are more optimistic then I am :) I would not > > pretend that such a thing as misconfiguration does not exist > > in MIPv6. Just configure the same Home Address on 2 MNs and > > look? Then plug one at home and try binding the other one. > > Or the other way around? >=20 > =3D> You mean configure the _same_ SA for both MNs? I hope > not! Of course that will cause problems. I can't see how > this is an analogy to what we're talking about. No, because the SA is associated to the Home Address. Nemo does not = change MIP for this. The 2 MRs have 2 different Home Addresses. But The = MNP is authorized for one or more Home Addresses. The 2 Home Addresses = can be from the same MNP, but they should have different SAs. >=20 > > > =3D> Sure if parallel paths lead to the same destination. > > > This is the whole point, they may not lead to the same > > > destination. You're basically asking for anycast prefixes. > > > Anycast is not useful if you want to have reliable > > > communication with the same host (i.e. a reachable host). >=20 > > I think we agree on that. Hopefully the 2 registrations do > > lead to the same place, since we want the 2 MRs to share the > > same ingress link; or else, it's a misconfiguration - or > > the net admin knows that he is doing some fine trick and > > whatever words we put in the spec he is on his own -. > > Again, Nemo gives you the same level of service as OSPF or > > ISIS. After that it is about the professional skill of > > deployment people. >=20 > =3D> Where is what you're saying reflected in the spec? Please > point me to a reference that an admin will read. Can I say common sense? Part of the nemo way is to split the purely = normative part (to become standard track) and the usage recommendations = (aimed at informational) in separate drafts. I understand that you = recommend a usage draft for Nemo multihoming. I do agree. Maybe it's a = bit early because we are missing the full picture. But maybe also it's = good to document what we already know... >=20 > > > =3D> I'm saying that if you want to do that then apply > > > it properly. At the moment it's not applied properly. > > > It seems like this feature was not agreed on and things > > > were left hanging in the air. I suggest that we either > > > fix it or make it clear that it's not allowed. > > Disagree. It was discussed at the WG. It's skill OK to voice > > your opposition but it was discussed. It was even > > specifically voiced at IETF 57, as I pointed out, and was > > part of nemo basic draft 00. > > >=20 > > > =3D> I don't know what you' rereferring to here. None > > > of this happens today. I think you have parallel > > > redundant paths mixed up with this. They're not the > > > same thing. ISP routers don't move while advertising > > > a prefix which cannot be reached through them... >=20 > > All I'm saying is that if a network administrator of your > > ISP configures a same prefix on 2 different link, you'll > > reach the closest one, or, if you're in the middle, you may > > end up reaching them alternatively. Shit happens, and the > > IGP in place does not prevent that at all. >=20 > =3D> Huh ?? It sounds like you're talking about anycast. > Please name one case where this can happen to unicast. > If this happens, then if Host_A tries to talk to Host_B > then sometimes it will end up talking to Host_C in the > middle of the connection. I was trying to say that IGPs do not generally include configuration = error detection. And that it is already possible to misconfigure a = network and cause such a situation that a subnetwork is seen at 2 = different places, so Nemo is nothing new, and that does not mean that = Nemo is incomplete.=20 There are some rules and these rules are not necessarily enforced by the = protocols. Rather, they are part of the know how of network designers. = Duplication of a subnet is avoided in general, and can be done is very = particular cases. And this happens outside of the scope of the IGP. This = is a deployment issue. >=20 > > Maybe all this discussion is because of a misunderstanding > > in the initial statement. I have in mind a configuration > > where an MNP is co-owned by 2 MRs that share an ingress > > link. The set (MR1+ingresslink+MR2) moves together as a > > whole. They are an atomic system. Link a plane with a wire > > between the 2 MRs. Maybe for you the ingress link is a fixed > > AP, like a hotspot at a Caf=E9, in which case the connectivity > > between the 2 MRs would be occasional? In that case, giving > > those MRs a same MNP is a misconfiguration, of course. >=20 > =3D> Again, I can't see any of this in the spec. I don't > think it's unreasonable to expect the spec to clarify > this. This is something in your head and is not explained > anywhere. There is a BIG difference between fixed routers > using IGPs and MRs (in the general case). I know that > MRs can be fixed in relation to each other but I > don't expect everyone reading the spec to guess this. Well seems that the authors collectively guessed otherwise. Ubiquity of = a prefix is a very specific thing. But then again, I'm not against a = usage draft on multihoming that would word that giving how the protocol = is expected to be used. We already did that for the home network = configuration. That's part of the spirit. >=20 > > > =3D> So it seems like it's not agreed on. In this case >=20 > > Not because it's not agreed upon, because it's not > > normative. The text was judged complex and not part of the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > protocol. There was no specific behaviour associated to it... > ^^^^^^^^ > =3D> If you really believe the underlined text then why > are you insisting on not making sure that it's explicily > stated in the spec that this is not supported by the protocol? >=20 Well, I'm happy with the nemo text the way it stands. I agreed to remove = the original text that said that nemo is open to multihoming. Because it = is, even if you do not write it down. That's what I meant here. What's = not part of the protocol was removed from the draft, but can be place in = usage drafts. Pascal From nemo-admin@ietf.org Thu Mar 18 09:15:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12159 for ; Thu, 18 Mar 2004 09:15:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yIZ-0000uN-OV; Thu, 18 Mar 2004 09:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yHx-0000oB-6t for nemo@optimus.ietf.org; Thu, 18 Mar 2004 09:14:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11985 for ; Thu, 18 Mar 2004 09:14:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yHv-000347-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:14:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yH1-0002ve-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:13:28 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3yG6-0002fu-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:12:30 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] FW: Multiple DRs on a link Date: Thu, 18 Mar 2004 09:11:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQM8cHH8ZO6X1EhSgCQ+VUlgQUcGwAADXrw From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Thierry Ernst" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Pascal,=20 I believe I answered your scenarios in the other email (the last email I sent) which discussed the questions=20 that need to be asked and how multihoming (for the=20 scenarios you mentioned) can already be handled today without any ambiguity. So I suggest that we take it from there instead of arguing the points below. As to the clarity of the spec, I don't think "it's clear to the authors" is a good way to go. I sure hope that every spec is clear to the authors! but obviously that's not a benchmark.=20 Hesham > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Thursday, March 18, 2004 9:03 AM > To: Soliman Hesham; Thierry Ernst > Cc: IETF NEMO WG > Subject: RE: [nemo] FW: Multiple DRs on a link >=20 >=20 >=20 > =20 > =20 > > > > =3D> There is never 2 HAs visible on the IP layer. > Still disagree, see later >=20 > > > > > > > > > > > What do you mean? If there are 2 MNs configured with a same > > > Home Address, > >=20 > > =3D> That's a bug of course and is **_detectable_** because: > > A. There SAs should not both match the same HoA > > B. If they (SAs) do someone will complain and the misconfig will > > be rectified. >=20 > > they MAY or MAY not get the same answer from > > > DHAAD. They MAY be registering to different HAs. It can > > > simply depend on which HA gets the DHAAD from the Internet, > > > and whatever load balancing algorithm they have. Do I miss > > > something? > >=20 > > =3D> I think you are talking about a misconfig case. I'm > > talking about what the protocol is designed to do. And >=20 > I'm not sure about what you mean MIP is designed to do here.=20 > I see DHAAD as a potential way to load balance bindings=20 > between HAs. I believe that MIPv6 is meant for that (3rd=20 > bullet page 103 asks for an randomization that actively load=20 > balances BCEs over HAs of equal preference). When you have=20 > multiple HAs, it is most probable that overtime, the BCEs=20 > will be distributed somehow between the HAs of equal highest=20 > preference. If you disagree with this statement, I'd wish to=20 > discuss that on the MIP6 ML. If you agree with this=20 > statement, then you see how a binding for a same Home=20 > Address is accepted by the same HA and rejected by a second HA.=20 >=20 >=20 > > of course if people misconfig things will not work > > as planned. This goes for every protocol. > >=20 > Sure.=20 > MRs with a same prefix and moving relatively to each other=20 > is a misconfiguration. > From plain common sense, isn't it? > And yes, long as we're talking misconfiguration, I'm happy=20 > with the MIP6 protocol as it is, if there's a way to detect=20 > the situation and alert. Thus my proposal for an optional=20 > DND test for Nemo. But at the end of the day, your case B=20 > above applies to Nemo if the prefix is duplicated, "someone=20 > will complain and the misconfig will be rectified". So Nemo=20 > is nothing better or worse than MIP6 or IGPs, it inherits from them. >=20 > > > Nemo will act as MIP for the Home Address, and if that test > > > is passed, Nemo will accept the duplicate prefixes, insert > > > both routes, and leave it up to the routing protocols and > > > the traffic splitting in place to get the packets forwarded. > > > As a result, in most cases, you'll see packets over both > > > tunnels. If there's no misconfiguration, the packets will > > > end up in the same link anyway. As usual. > >=20 > > =3D> I understand what you're saying for the "fixed" MR case. > > But, if the MR moves this will cause problems. Do you agree > > with that? > I meant as I said that the MR-link-MR is an atomic system=20 > moving together relative to the infrastructure. Like in a=20 > plane. And they MUST NOT split, otherwise I do agree it's a=20 > misconfiguration -or a very very specific trick-. >=20 >=20 > > > > > also if the node is at home and there's a second > > > binding for the same > > > > > Home address, the binding looses. MIPv6 is not=20 > consistent in > > > > > that case > > > > > > > > =3D> Because this case does not exist in MIPv6. > > > > > > > Seems you are more optimistic then I am :) I would not > > > pretend that such a thing as misconfiguration does not exist > > > in MIPv6. Just configure the same Home Address on 2 MNs and > > > look? Then plug one at home and try binding the other one. > > > Or the other way around? > >=20 > > =3D> You mean configure the _same_ SA for both MNs? I hope > > not! Of course that will cause problems. I can't see how > > this is an analogy to what we're talking about. >=20 > No, because the SA is associated to the Home Address. Nemo=20 > does not change MIP for this. The 2 MRs have 2 different=20 > Home Addresses. But The MNP is authorized for one or more=20 > Home Addresses. The 2 Home Addresses can be from the same=20 > MNP, but they should have different SAs. >=20 > >=20 > > > > =3D> Sure if parallel paths lead to the same destination. > > > > This is the whole point, they may not lead to the same > > > > destination. You're basically asking for anycast prefixes. > > > > Anycast is not useful if you want to have reliable > > > > communication with the same host (i.e. a reachable host). > >=20 > > > I think we agree on that. Hopefully the 2 registrations do > > > lead to the same place, since we want the 2 MRs to share the > > > same ingress link; or else, it's a misconfiguration - or > > > the net admin knows that he is doing some fine trick and > > > whatever words we put in the spec he is on his own -. > > > Again, Nemo gives you the same level of service as OSPF or > > > ISIS. After that it is about the professional skill of > > > deployment people. > >=20 > > =3D> Where is what you're saying reflected in the spec? Please > > point me to a reference that an admin will read. >=20 > Can I say common sense? Part of the nemo way is to split the=20 > purely normative part (to become standard track) and the=20 > usage recommendations (aimed at informational) in separate=20 > drafts. I understand that you recommend a usage draft for=20 > Nemo multihoming. I do agree. Maybe it's a bit early because=20 > we are missing the full picture. But maybe also it's good to=20 > document what we already know... >=20 > >=20 > > > > =3D> I'm saying that if you want to do that then apply > > > > it properly. At the moment it's not applied properly. > > > > It seems like this feature was not agreed on and things > > > > were left hanging in the air. I suggest that we either > > > > fix it or make it clear that it's not allowed. > > > Disagree. It was discussed at the WG. It's skill OK to voice > > > your opposition but it was discussed. It was even > > > specifically voiced at IETF 57, as I pointed out, and was > > > part of nemo basic draft 00. > > > > >=20 > > > > =3D> I don't know what you' rereferring to here. None > > > > of this happens today. I think you have parallel > > > > redundant paths mixed up with this. They're not the > > > > same thing. ISP routers don't move while advertising > > > > a prefix which cannot be reached through them... > >=20 > > > All I'm saying is that if a network administrator of your > > > ISP configures a same prefix on 2 different link, you'll > > > reach the closest one, or, if you're in the middle, you may > > > end up reaching them alternatively. Shit happens, and the > > > IGP in place does not prevent that at all. > >=20 > > =3D> Huh ?? It sounds like you're talking about anycast. > > Please name one case where this can happen to unicast. > > If this happens, then if Host_A tries to talk to Host_B > > then sometimes it will end up talking to Host_C in the > > middle of the connection. >=20 > I was trying to say that IGPs do not generally include=20 > configuration error detection. And that it is already=20 > possible to misconfigure a network and cause such a=20 > situation that a subnetwork is seen at 2 different places,=20 > so Nemo is nothing new, and that does not mean that Nemo is=20 > incomplete.=20 >=20 > There are some rules and these rules are not necessarily=20 > enforced by the protocols. Rather, they are part of the know=20 > how of network designers. Duplication of a subnet is avoided=20 > in general, and can be done is very particular cases. And=20 > this happens outside of the scope of the IGP. This is a=20 > deployment issue. >=20 > >=20 > > > Maybe all this discussion is because of a misunderstanding > > > in the initial statement. I have in mind a configuration > > > where an MNP is co-owned by 2 MRs that share an ingress > > > link. The set (MR1+ingresslink+MR2) moves together as a > > > whole. They are an atomic system. Link a plane with a wire > > > between the 2 MRs. Maybe for you the ingress link is a fixed > > > AP, like a hotspot at a Caf=E9, in which case the connectivity > > > between the 2 MRs would be occasional? In that case, giving > > > those MRs a same MNP is a misconfiguration, of course. > >=20 > > =3D> Again, I can't see any of this in the spec. I don't > > think it's unreasonable to expect the spec to clarify > > this. This is something in your head and is not explained > > anywhere. There is a BIG difference between fixed routers > > using IGPs and MRs (in the general case). I know that > > MRs can be fixed in relation to each other but I > > don't expect everyone reading the spec to guess this. >=20 > Well seems that the authors collectively guessed otherwise.=20 > Ubiquity of a prefix is a very specific thing. But then=20 > again, I'm not against a usage draft on multihoming that=20 > would word that giving how the protocol is expected to be=20 > used. We already did that for the home network=20 > configuration. That's part of the spirit. >=20 > >=20 > > > > =3D> So it seems like it's not agreed on. In this case > >=20 > > > Not because it's not agreed upon, because it's not > > > normative. The text was judged complex and not part of the > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > protocol. There was no specific behaviour associated to it... > > ^^^^^^^^ > > =3D> If you really believe the underlined text then why > > are you insisting on not making sure that it's explicily > > stated in the spec that this is not supported by the protocol? > >=20 > Well, I'm happy with the nemo text the way it stands. I=20 > agreed to remove the original text that said that nemo is=20 > open to multihoming. Because it is, even if you do not write=20 > it down. That's what I meant here. What's not part of the=20 > protocol was removed from the draft, but can be place in=20 > usage drafts. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Pascal >=20 From exim@www1.ietf.org Thu Mar 18 09:16:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12263 for ; Thu, 18 Mar 2004 09:16:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yJw-00011L-L8 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 09:16:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IEGSMo003917 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 09:16:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yJw-000116-Eq for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 09:16:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12244 for ; Thu, 18 Mar 2004 09:16:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yJu-0003Oe-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 09:16:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yJJ-0003IX-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 09:15:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3yIl-00039I-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 09:15:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yIZ-0000uN-OV; Thu, 18 Mar 2004 09:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yHx-0000oB-6t for nemo@optimus.ietf.org; Thu, 18 Mar 2004 09:14:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11985 for ; Thu, 18 Mar 2004 09:14:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yHv-000347-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:14:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yH1-0002ve-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:13:28 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3yG6-0002fu-00 for nemo@ietf.org; Thu, 18 Mar 2004 09:12:30 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] FW: Multiple DRs on a link Date: Thu, 18 Mar 2004 09:11:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQM8cHH8ZO6X1EhSgCQ+VUlgQUcGwAADXrw From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Thierry Ernst" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pascal,=20 I believe I answered your scenarios in the other email (the last email I sent) which discussed the questions=20 that need to be asked and how multihoming (for the=20 scenarios you mentioned) can already be handled today without any ambiguity. So I suggest that we take it from there instead of arguing the points below. As to the clarity of the spec, I don't think "it's clear to the authors" is a good way to go. I sure hope that every spec is clear to the authors! but obviously that's not a benchmark.=20 Hesham > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Thursday, March 18, 2004 9:03 AM > To: Soliman Hesham; Thierry Ernst > Cc: IETF NEMO WG > Subject: RE: [nemo] FW: Multiple DRs on a link >=20 >=20 >=20 > =20 > =20 > > > > =3D> There is never 2 HAs visible on the IP layer. > Still disagree, see later >=20 > > > > > > > > > > > What do you mean? If there are 2 MNs configured with a same > > > Home Address, > >=20 > > =3D> That's a bug of course and is **_detectable_** because: > > A. There SAs should not both match the same HoA > > B. If they (SAs) do someone will complain and the misconfig will > > be rectified. >=20 > > they MAY or MAY not get the same answer from > > > DHAAD. They MAY be registering to different HAs. It can > > > simply depend on which HA gets the DHAAD from the Internet, > > > and whatever load balancing algorithm they have. Do I miss > > > something? > >=20 > > =3D> I think you are talking about a misconfig case. I'm > > talking about what the protocol is designed to do. And >=20 > I'm not sure about what you mean MIP is designed to do here.=20 > I see DHAAD as a potential way to load balance bindings=20 > between HAs. I believe that MIPv6 is meant for that (3rd=20 > bullet page 103 asks for an randomization that actively load=20 > balances BCEs over HAs of equal preference). When you have=20 > multiple HAs, it is most probable that overtime, the BCEs=20 > will be distributed somehow between the HAs of equal highest=20 > preference. If you disagree with this statement, I'd wish to=20 > discuss that on the MIP6 ML. If you agree with this=20 > statement, then you see how a binding for a same Home=20 > Address is accepted by the same HA and rejected by a second HA.=20 >=20 >=20 > > of course if people misconfig things will not work > > as planned. This goes for every protocol. > >=20 > Sure.=20 > MRs with a same prefix and moving relatively to each other=20 > is a misconfiguration. > From plain common sense, isn't it? > And yes, long as we're talking misconfiguration, I'm happy=20 > with the MIP6 protocol as it is, if there's a way to detect=20 > the situation and alert. Thus my proposal for an optional=20 > DND test for Nemo. But at the end of the day, your case B=20 > above applies to Nemo if the prefix is duplicated, "someone=20 > will complain and the misconfig will be rectified". So Nemo=20 > is nothing better or worse than MIP6 or IGPs, it inherits from them. >=20 > > > Nemo will act as MIP for the Home Address, and if that test > > > is passed, Nemo will accept the duplicate prefixes, insert > > > both routes, and leave it up to the routing protocols and > > > the traffic splitting in place to get the packets forwarded. > > > As a result, in most cases, you'll see packets over both > > > tunnels. If there's no misconfiguration, the packets will > > > end up in the same link anyway. As usual. > >=20 > > =3D> I understand what you're saying for the "fixed" MR case. > > But, if the MR moves this will cause problems. Do you agree > > with that? > I meant as I said that the MR-link-MR is an atomic system=20 > moving together relative to the infrastructure. Like in a=20 > plane. And they MUST NOT split, otherwise I do agree it's a=20 > misconfiguration -or a very very specific trick-. >=20 >=20 > > > > > also if the node is at home and there's a second > > > binding for the same > > > > > Home address, the binding looses. MIPv6 is not=20 > consistent in > > > > > that case > > > > > > > > =3D> Because this case does not exist in MIPv6. > > > > > > > Seems you are more optimistic then I am :) I would not > > > pretend that such a thing as misconfiguration does not exist > > > in MIPv6. Just configure the same Home Address on 2 MNs and > > > look? Then plug one at home and try binding the other one. > > > Or the other way around? > >=20 > > =3D> You mean configure the _same_ SA for both MNs? I hope > > not! Of course that will cause problems. I can't see how > > this is an analogy to what we're talking about. >=20 > No, because the SA is associated to the Home Address. Nemo=20 > does not change MIP for this. The 2 MRs have 2 different=20 > Home Addresses. But The MNP is authorized for one or more=20 > Home Addresses. The 2 Home Addresses can be from the same=20 > MNP, but they should have different SAs. >=20 > >=20 > > > > =3D> Sure if parallel paths lead to the same destination. > > > > This is the whole point, they may not lead to the same > > > > destination. You're basically asking for anycast prefixes. > > > > Anycast is not useful if you want to have reliable > > > > communication with the same host (i.e. a reachable host). > >=20 > > > I think we agree on that. Hopefully the 2 registrations do > > > lead to the same place, since we want the 2 MRs to share the > > > same ingress link; or else, it's a misconfiguration - or > > > the net admin knows that he is doing some fine trick and > > > whatever words we put in the spec he is on his own -. > > > Again, Nemo gives you the same level of service as OSPF or > > > ISIS. After that it is about the professional skill of > > > deployment people. > >=20 > > =3D> Where is what you're saying reflected in the spec? Please > > point me to a reference that an admin will read. >=20 > Can I say common sense? Part of the nemo way is to split the=20 > purely normative part (to become standard track) and the=20 > usage recommendations (aimed at informational) in separate=20 > drafts. I understand that you recommend a usage draft for=20 > Nemo multihoming. I do agree. Maybe it's a bit early because=20 > we are missing the full picture. But maybe also it's good to=20 > document what we already know... >=20 > >=20 > > > > =3D> I'm saying that if you want to do that then apply > > > > it properly. At the moment it's not applied properly. > > > > It seems like this feature was not agreed on and things > > > > were left hanging in the air. I suggest that we either > > > > fix it or make it clear that it's not allowed. > > > Disagree. It was discussed at the WG. It's skill OK to voice > > > your opposition but it was discussed. It was even > > > specifically voiced at IETF 57, as I pointed out, and was > > > part of nemo basic draft 00. > > > > >=20 > > > > =3D> I don't know what you' rereferring to here. None > > > > of this happens today. I think you have parallel > > > > redundant paths mixed up with this. They're not the > > > > same thing. ISP routers don't move while advertising > > > > a prefix which cannot be reached through them... > >=20 > > > All I'm saying is that if a network administrator of your > > > ISP configures a same prefix on 2 different link, you'll > > > reach the closest one, or, if you're in the middle, you may > > > end up reaching them alternatively. Shit happens, and the > > > IGP in place does not prevent that at all. > >=20 > > =3D> Huh ?? It sounds like you're talking about anycast. > > Please name one case where this can happen to unicast. > > If this happens, then if Host_A tries to talk to Host_B > > then sometimes it will end up talking to Host_C in the > > middle of the connection. >=20 > I was trying to say that IGPs do not generally include=20 > configuration error detection. And that it is already=20 > possible to misconfigure a network and cause such a=20 > situation that a subnetwork is seen at 2 different places,=20 > so Nemo is nothing new, and that does not mean that Nemo is=20 > incomplete.=20 >=20 > There are some rules and these rules are not necessarily=20 > enforced by the protocols. Rather, they are part of the know=20 > how of network designers. Duplication of a subnet is avoided=20 > in general, and can be done is very particular cases. And=20 > this happens outside of the scope of the IGP. This is a=20 > deployment issue. >=20 > >=20 > > > Maybe all this discussion is because of a misunderstanding > > > in the initial statement. I have in mind a configuration > > > where an MNP is co-owned by 2 MRs that share an ingress > > > link. The set (MR1+ingresslink+MR2) moves together as a > > > whole. They are an atomic system. Link a plane with a wire > > > between the 2 MRs. Maybe for you the ingress link is a fixed > > > AP, like a hotspot at a Caf=E9, in which case the connectivity > > > between the 2 MRs would be occasional? In that case, giving > > > those MRs a same MNP is a misconfiguration, of course. > >=20 > > =3D> Again, I can't see any of this in the spec. I don't > > think it's unreasonable to expect the spec to clarify > > this. This is something in your head and is not explained > > anywhere. There is a BIG difference between fixed routers > > using IGPs and MRs (in the general case). I know that > > MRs can be fixed in relation to each other but I > > don't expect everyone reading the spec to guess this. >=20 > Well seems that the authors collectively guessed otherwise.=20 > Ubiquity of a prefix is a very specific thing. But then=20 > again, I'm not against a usage draft on multihoming that=20 > would word that giving how the protocol is expected to be=20 > used. We already did that for the home network=20 > configuration. That's part of the spirit. >=20 > >=20 > > > > =3D> So it seems like it's not agreed on. In this case > >=20 > > > Not because it's not agreed upon, because it's not > > > normative. The text was judged complex and not part of the > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > protocol. There was no specific behaviour associated to it... > > ^^^^^^^^ > > =3D> If you really believe the underlined text then why > > are you insisting on not making sure that it's explicily > > stated in the spec that this is not supported by the protocol? > >=20 > Well, I'm happy with the nemo text the way it stands. I=20 > agreed to remove the original text that said that nemo is=20 > open to multihoming. Because it is, even if you do not write=20 > it down. That's what I meant here. What's not part of the=20 > protocol was removed from the draft, but can be place in=20 > usage drafts. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Pascal >=20 From nemo-admin@ietf.org Thu Mar 18 10:06:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16092 for ; Thu, 18 Mar 2004 10:06:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3z5O-00076G-9N; Thu, 18 Mar 2004 10:05:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3z41-0006J9-8C for nemo@optimus.ietf.org; Thu, 18 Mar 2004 10:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15961 for ; Thu, 18 Mar 2004 10:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3z3y-0002V8-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:04:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3z2v-0002J5-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:02:58 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B3z2B-00027p-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:02:12 -0500 Received: from MobileGravity.local.sfc.wide.ad.jp (pdd8bc6.tkyoac00.ap.so-net.ne.jp [218.221.139.198]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2IF1IUV000831; Fri, 19 Mar 2004 00:01:21 +0900 Date: Fri, 19 Mar 2004 00:01:26 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello Hesham There is a draft draft-ng-nemo-multihoming-issues-03 about multihomed NEMO pb statement. During the Seoul meeting, we all agreed on the scenarios described in the slide. And two of scenarios are actually (N MRs, 1 HA, and 1 Prefix) and (N MRs, N HA, and 1 Prefix). I want to keep the above two scenarios. It is too restrict to remove one of scenario at this time. I don't know whether ISP wants the below configuration for ingress filtering. How does each HA know which prefixes are assigned to a mobile network(i.e. two MRs in your case)? Do you assume using prefix table? ISP can not stop a malicious MNN sending packets with a wrong prefix which is within ISP-prefix. The example scenario is that a mobile network has ISP_PREFIX-A,-B, but MNN send DoS packet with the source address of ISP_PREFIX-C. Even we remove the case where 2 MRs share the same mobile network prefix, we still need to confirm whether there is duplicated MR for the prefix or not, like MIP6 has DAD mechanism for HoA. It is worth to clear this part, but I want to keep multihoming scenarios open. regards, ryuji At Thu, 18 Mar 2004 08:03:45 -0500, Soliman Hesham wrote: > > > > > Agreed: > > The test was not designed yet. The requirement for the > > test is still > > not agreed upon. So if this thread ends up anywhere, maybe it's to an > > answer to that question: Is there a need for a Duplicate Network > > Detection test that would check that when a prefix is > > registered twice, > > you end up on the same link for both registrations? > > => Hmmm, interesting question. However, I think we're > skipping a few steps in attempting to answer this question. > Your question is assuming that the preferred solution for > a multihome monet (sorry I just don't thing nemo makes english > sense in this sentence) is to assign the same MNP to > all MRs. Given this assumption, it's natural to ask the > question above. > > On the other hand, if we ask: What is the best interim > step for multihoming in nemo, we might end up with > a different solution and consequently a different set of > questions. I preferred to ask the latter question than > the first. > > Personally, I think it's a lot cleaner to have one prefix > per MR and somehow solve the ingress filtering problem. > This is not so difficult in the case where the 2 MRs > belong to the same home domain/link. For instance, an > ISP might not filter (in the MR's HA) on any of the > prefixes that are assigned to its domain. So basically > it forwards any packet coming from any prefix derived > from ISP_PREFIX::/26. This would solve the simple multihoming > case where 2 MRs belong to the same home admin domain. > I think this will solve the problem with the scenarios > that you mention, i.e. plane, train, bus ...etc. > > Do you think this will work? This requires hardly any > changes to the spec. We can clearly do without changing > anything, except for mentioning that 2 MRs do not share > the same prefix. I misstated that before to say 1 prefix > per MR, when what I really meant was two MRs do not share > the same prefix. > > Hesham > > > > > > Pascal > > > From exim@www1.ietf.org Thu Mar 18 10:09:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16657 for ; Thu, 18 Mar 2004 10:09:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3z8S-0000Fb-3A for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 10:08:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IF8dub000901 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 10:08:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3z8O-0000EB-Im for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 10:08:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16490 for ; Thu, 18 Mar 2004 10:08:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3z8M-0003Zu-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:08:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3z6u-0003CO-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:07:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3z5Z-0002uI-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:05:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3z5O-00076G-9N; Thu, 18 Mar 2004 10:05:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3z41-0006J9-8C for nemo@optimus.ietf.org; Thu, 18 Mar 2004 10:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15961 for ; Thu, 18 Mar 2004 10:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3z3y-0002V8-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:04:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3z2v-0002J5-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:02:58 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B3z2B-00027p-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:02:12 -0500 Received: from MobileGravity.local.sfc.wide.ad.jp (pdd8bc6.tkyoac00.ap.so-net.ne.jp [218.221.139.198]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2IF1IUV000831; Fri, 19 Mar 2004 00:01:21 +0900 Date: Fri, 19 Mar 2004 00:01:26 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hello Hesham There is a draft draft-ng-nemo-multihoming-issues-03 about multihomed NEMO pb statement. During the Seoul meeting, we all agreed on the scenarios described in the slide. And two of scenarios are actually (N MRs, 1 HA, and 1 Prefix) and (N MRs, N HA, and 1 Prefix). I want to keep the above two scenarios. It is too restrict to remove one of scenario at this time. I don't know whether ISP wants the below configuration for ingress filtering. How does each HA know which prefixes are assigned to a mobile network(i.e. two MRs in your case)? Do you assume using prefix table? ISP can not stop a malicious MNN sending packets with a wrong prefix which is within ISP-prefix. The example scenario is that a mobile network has ISP_PREFIX-A,-B, but MNN send DoS packet with the source address of ISP_PREFIX-C. Even we remove the case where 2 MRs share the same mobile network prefix, we still need to confirm whether there is duplicated MR for the prefix or not, like MIP6 has DAD mechanism for HoA. It is worth to clear this part, but I want to keep multihoming scenarios open. regards, ryuji At Thu, 18 Mar 2004 08:03:45 -0500, Soliman Hesham wrote: > > > > > Agreed: > > The test was not designed yet. The requirement for the > > test is still > > not agreed upon. So if this thread ends up anywhere, maybe it's to an > > answer to that question: Is there a need for a Duplicate Network > > Detection test that would check that when a prefix is > > registered twice, > > you end up on the same link for both registrations? > > => Hmmm, interesting question. However, I think we're > skipping a few steps in attempting to answer this question. > Your question is assuming that the preferred solution for > a multihome monet (sorry I just don't thing nemo makes english > sense in this sentence) is to assign the same MNP to > all MRs. Given this assumption, it's natural to ask the > question above. > > On the other hand, if we ask: What is the best interim > step for multihoming in nemo, we might end up with > a different solution and consequently a different set of > questions. I preferred to ask the latter question than > the first. > > Personally, I think it's a lot cleaner to have one prefix > per MR and somehow solve the ingress filtering problem. > This is not so difficult in the case where the 2 MRs > belong to the same home domain/link. For instance, an > ISP might not filter (in the MR's HA) on any of the > prefixes that are assigned to its domain. So basically > it forwards any packet coming from any prefix derived > from ISP_PREFIX::/26. This would solve the simple multihoming > case where 2 MRs belong to the same home admin domain. > I think this will solve the problem with the scenarios > that you mention, i.e. plane, train, bus ...etc. > > Do you think this will work? This requires hardly any > changes to the spec. We can clearly do without changing > anything, except for mentioning that 2 MRs do not share > the same prefix. I misstated that before to say 1 prefix > per MR, when what I really meant was two MRs do not share > the same prefix. > > Hesham > > > > > > Pascal > > > From nemo-admin@ietf.org Thu Mar 18 10:17:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18315 for ; Thu, 18 Mar 2004 10:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zGU-0002Er-Ke; Thu, 18 Mar 2004 10:16:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zF6-0001sl-VT for nemo@optimus.ietf.org; Thu, 18 Mar 2004 10:15:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18019 for ; Thu, 18 Mar 2004 10:15:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zF4-0004fm-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:15:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zEH-0004cl-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:14:42 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zDm-0004Vp-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:14:10 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Thu, 18 Mar 2004 10:13:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM+enSOb1/Wx9URyOH0cdAc/HkXwAAK/UA From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > There is a draft draft-ng-nemo-multihoming-issues-03 about multihomed > NEMO pb statement. During the Seoul meeting, we all agreed on the > scenarios described in the slide. And two of scenarios are=20 > actually (N > MRs, 1 HA, and 1 Prefix) and (N MRs, N HA, and 1 Prefix). I want to > keep the above two scenarios. It is too restrict to remove one of > scenario at this time. =3D> That's fine, so keep it in the draft. I assume=20 a solution will come up to solve this case. But that doesn't mean that we leave it open in the spec. >=20 > I don't know whether ISP wants the below configuration for ingress > filtering. How does each HA know which prefixes are assigned to a > mobile network(i.e. two MRs in your case)?=20 =3D> I don't see any problem here. Here is a simplified address plan for a small fictitious ISP: ISP acquires PREFIX::/26 ISP allocates prefixes from SUB-PREFIX::/48 to MRs Now there are two options:=20 A. Any prefix derived from SUB-PREFIX::/48 is allowed by any HA, or,=20 B. There is a specific entry in the HA's ACL for those=20 special MRs on trains busses...etc that allows this.=20 Both can work. There are other factors to consider when building a system, e.g. whether access control is done by MRs ...etc, which will affect which choice you make. But none of this=20 affects the current solution or the protocol. This will also work when the network is divided between the MRs. The point is, we can't assume a restrictive solution and underspecify it without careful cautions. Either we solve it properly or use existing practices to solve it in the=20 same way it's done today. > Do you assume using prefix table? =20 > ISP can not stop a malicious MNN sending packets with a wrong prefix > which is within ISP-prefix. The example scenario is that a mobile > network has ISP_PREFIX-A,-B, but MNN send DoS packet with the source > address of ISP_PREFIX-C. =3D> See above. > Even we remove the case where 2 MRs share the same mobile network > prefix, we still need to confirm whether there is duplicated MR for > the prefix or not, like MIP6 has DAD mechanism for HoA.=20 =3D> But that can be addressed with the current spec, i.e. the prefix table. It=20 > is worth to > clear this part, but I want to keep multihoming scenarios open. =3D> Me too. But there is a difference between open an=20 ambiguous. In a standards doc I think we need to be clear. This doesn't mean we have to solve everything, but we have to clearly state what works and what doesn't, and why. Hesham From nemo-admin@ietf.org Thu Mar 18 10:26:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19202 for ; Thu, 18 Mar 2004 10:26:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zOP-0004kw-06; Thu, 18 Mar 2004 10:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zNt-0004bI-C0 for nemo@optimus.ietf.org; Thu, 18 Mar 2004 10:24:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19036 for ; Thu, 18 Mar 2004 10:24:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zNr-0005H2-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:24:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zMu-0005EI-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:23:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3zMI-00059e-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:22:58 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 07:27:40 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IFLtiZ024650; Thu, 18 Mar 2004 16:21:55 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 15:22:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 15:22:24 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM58ima5IlfCYQQfaaS/P4WSJfswAAH64wAAOi8iA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 15:22:25.0262 (UTC) FILETIME=[D11988E0:01C40CFC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Personally, I think it's a lot cleaner to have one prefix > per MR and somehow solve the ingress filtering problem. > This is not so difficult in the case where the 2 MRs > belong to the same home domain/link. For instance, an > ISP might not filter (in the MR's HA) on any of the > prefixes that are assigned to its domain. So basically > it forwards any packet coming from any prefix derived > from ISP_PREFIX::/26. This would solve the simple multihoming > case where 2 MRs belong to the same home admin domain. > I think this will solve the problem with the scenarios > that you mention, i.e. plane, train, bus ...etc. >=20 > Do you think this will work? Well, here's one problem that I see: MIPv6 has the following (p100) " the home agent MUST verify that the Source Address in the tunnel IP header is the mobile node's primary care-of address. " Our implementation of that text is (high level, there's more to it): =20 1) take source of inner packet 2) find BCE for source. If not found drop packet 3) check primary care of in BCE against tunnel source. If equal decapsulate else drop. This compares to Nemo (P27)=20 "The Home Agent has to verify that packets received through the bi-directional tunnel belong to the mobile network. (...) The source address of the inner IPv6 header MUST be a topologically correct address with respect to the IPv6 prefixes used in the mobile network." The topological correctness normally means that packets to the source of the inner packets would be routed via MRHA the tunnel. This is important because it's one way to find the BCE to perform rge mandated checkings -Alternate would be to index the BCE by CareOf and hope that there's a single registration for a given CareOf, which is not guaranteed while generally true be it to make SA determination simpler-. Anyway, our current implementation is like: 1) take source of inner packet.=20 2) resolve via_gateway (should be MR Home Address) by reverse lookup in routing table (there can be more than one IPv6 adjacency) 3) find BCE for via_gateway(s). If none found drop packet 4) check primary care of in BCE against tunnel source.=20 If equal for at least one adjacency decapsulate else drop. There is no Home Address Option with the tunnel... You see that if the source of the inner packet can be anything in a /26, it's not only the topological correctness that can not be checked properly anymore, it's finding the BCE in the first place that becomes a problem and you have to fall back to CoA indexing.=20 >=20 > Do you think this will work? This requires hardly any > changes to the spec. We can clearly do without changing > anything, except for mentioning that 2 MRs do not share > the same prefix. I misstated that before to say 1 prefix > per MR, when what I really meant was two MRs do not share > the same prefix. >=20 Sorry, I disagree, and I would appreciate other advices on this. My take is that we should not forbid something to everybody just because some people might do it wrong - if they fail to apply what is commonplace for fixed network, i.e. subnets are generally not ubiquitous -.=20 If it's done wrong, it's a config issue that can be found and fixed. If it's done right, you get the redundancy you want, so there's a real benefit that is guaranteed for all LFNs with no change in their stack. Hopefully I made my position clear and so did you. Let's see if someone else is willing to give his own view? Pascal From exim@www1.ietf.org Thu Mar 18 10:30:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19493 for ; Thu, 18 Mar 2004 10:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zT6-0005to-OQ for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 10:30:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IFU0cj022649 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 10:30:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zT5-0005sW-0n for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 10:29:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19417 for ; Thu, 18 Mar 2004 10:29:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zSv-0005af-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:29:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zRp-0005Qq-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:28:42 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zR3-0005Op-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:27:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3zP3-0006Dn-Tz for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:25:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zOP-0004kw-06; Thu, 18 Mar 2004 10:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zNt-0004bI-C0 for nemo@optimus.ietf.org; Thu, 18 Mar 2004 10:24:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19036 for ; Thu, 18 Mar 2004 10:24:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zNr-0005H2-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:24:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zMu-0005EI-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:23:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3zMI-00059e-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:22:58 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 07:27:40 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IFLtiZ024650; Thu, 18 Mar 2004 16:21:55 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 15:22:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 15:22:24 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM58ima5IlfCYQQfaaS/P4WSJfswAAH64wAAOi8iA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 15:22:25.0262 (UTC) FILETIME=[D11988E0:01C40CFC] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Personally, I think it's a lot cleaner to have one prefix > per MR and somehow solve the ingress filtering problem. > This is not so difficult in the case where the 2 MRs > belong to the same home domain/link. For instance, an > ISP might not filter (in the MR's HA) on any of the > prefixes that are assigned to its domain. So basically > it forwards any packet coming from any prefix derived > from ISP_PREFIX::/26. This would solve the simple multihoming > case where 2 MRs belong to the same home admin domain. > I think this will solve the problem with the scenarios > that you mention, i.e. plane, train, bus ...etc. >=20 > Do you think this will work? Well, here's one problem that I see: MIPv6 has the following (p100) " the home agent MUST verify that the Source Address in the tunnel IP header is the mobile node's primary care-of address. " Our implementation of that text is (high level, there's more to it): =20 1) take source of inner packet 2) find BCE for source. If not found drop packet 3) check primary care of in BCE against tunnel source. If equal decapsulate else drop. This compares to Nemo (P27)=20 "The Home Agent has to verify that packets received through the bi-directional tunnel belong to the mobile network. (...) The source address of the inner IPv6 header MUST be a topologically correct address with respect to the IPv6 prefixes used in the mobile network." The topological correctness normally means that packets to the source of the inner packets would be routed via MRHA the tunnel. This is important because it's one way to find the BCE to perform rge mandated checkings -Alternate would be to index the BCE by CareOf and hope that there's a single registration for a given CareOf, which is not guaranteed while generally true be it to make SA determination simpler-. Anyway, our current implementation is like: 1) take source of inner packet.=20 2) resolve via_gateway (should be MR Home Address) by reverse lookup in routing table (there can be more than one IPv6 adjacency) 3) find BCE for via_gateway(s). If none found drop packet 4) check primary care of in BCE against tunnel source.=20 If equal for at least one adjacency decapsulate else drop. There is no Home Address Option with the tunnel... You see that if the source of the inner packet can be anything in a /26, it's not only the topological correctness that can not be checked properly anymore, it's finding the BCE in the first place that becomes a problem and you have to fall back to CoA indexing.=20 >=20 > Do you think this will work? This requires hardly any > changes to the spec. We can clearly do without changing > anything, except for mentioning that 2 MRs do not share > the same prefix. I misstated that before to say 1 prefix > per MR, when what I really meant was two MRs do not share > the same prefix. >=20 Sorry, I disagree, and I would appreciate other advices on this. My take is that we should not forbid something to everybody just because some people might do it wrong - if they fail to apply what is commonplace for fixed network, i.e. subnets are generally not ubiquitous -.=20 If it's done wrong, it's a config issue that can be found and fixed. If it's done right, you get the redundancy you want, so there's a real benefit that is guaranteed for all LFNs with no change in their stack. Hopefully I made my position clear and so did you. Let's see if someone else is willing to give his own view? Pascal From exim@www1.ietf.org Thu Mar 18 10:32:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19755 for ; Thu, 18 Mar 2004 10:32:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zUe-00060B-99 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 10:31:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IFVa0a023065 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 10:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zUe-0005zw-4d for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 10:31:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19636 for ; Thu, 18 Mar 2004 10:31:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zUb-0005rA-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:31:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zSi-0005YQ-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:29:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zRk-0005Op-02 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:28:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3zGe-0005ww-5g for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:17:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zGU-0002Er-Ke; Thu, 18 Mar 2004 10:16:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zF6-0001sl-VT for nemo@optimus.ietf.org; Thu, 18 Mar 2004 10:15:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18019 for ; Thu, 18 Mar 2004 10:15:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zF4-0004fm-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:15:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zEH-0004cl-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:14:42 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zDm-0004Vp-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:14:10 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Thu, 18 Mar 2004 10:13:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM+enSOb1/Wx9URyOH0cdAc/HkXwAAK/UA From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: , Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > There is a draft draft-ng-nemo-multihoming-issues-03 about multihomed > NEMO pb statement. During the Seoul meeting, we all agreed on the > scenarios described in the slide. And two of scenarios are=20 > actually (N > MRs, 1 HA, and 1 Prefix) and (N MRs, N HA, and 1 Prefix). I want to > keep the above two scenarios. It is too restrict to remove one of > scenario at this time. =3D> That's fine, so keep it in the draft. I assume=20 a solution will come up to solve this case. But that doesn't mean that we leave it open in the spec. >=20 > I don't know whether ISP wants the below configuration for ingress > filtering. How does each HA know which prefixes are assigned to a > mobile network(i.e. two MRs in your case)?=20 =3D> I don't see any problem here. Here is a simplified address plan for a small fictitious ISP: ISP acquires PREFIX::/26 ISP allocates prefixes from SUB-PREFIX::/48 to MRs Now there are two options:=20 A. Any prefix derived from SUB-PREFIX::/48 is allowed by any HA, or,=20 B. There is a specific entry in the HA's ACL for those=20 special MRs on trains busses...etc that allows this.=20 Both can work. There are other factors to consider when building a system, e.g. whether access control is done by MRs ...etc, which will affect which choice you make. But none of this=20 affects the current solution or the protocol. This will also work when the network is divided between the MRs. The point is, we can't assume a restrictive solution and underspecify it without careful cautions. Either we solve it properly or use existing practices to solve it in the=20 same way it's done today. > Do you assume using prefix table? =20 > ISP can not stop a malicious MNN sending packets with a wrong prefix > which is within ISP-prefix. The example scenario is that a mobile > network has ISP_PREFIX-A,-B, but MNN send DoS packet with the source > address of ISP_PREFIX-C. =3D> See above. > Even we remove the case where 2 MRs share the same mobile network > prefix, we still need to confirm whether there is duplicated MR for > the prefix or not, like MIP6 has DAD mechanism for HoA.=20 =3D> But that can be addressed with the current spec, i.e. the prefix table. It=20 > is worth to > clear this part, but I want to keep multihoming scenarios open. =3D> Me too. But there is a difference between open an=20 ambiguous. In a standards doc I think we need to be clear. This doesn't mean we have to solve everything, but we have to clearly state what works and what doesn't, and why. Hesham From nemo-admin@ietf.org Thu Mar 18 10:44:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20878 for ; Thu, 18 Mar 2004 10:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zgf-000790-FT; Thu, 18 Mar 2004 10:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zfv-000707-GD for nemo@optimus.ietf.org; Thu, 18 Mar 2004 10:43:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20819 for ; Thu, 18 Mar 2004 10:43:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zft-00073d-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:43:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zfP-00071Z-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:42:44 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zej-0006vY-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:42:01 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 10:41:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM/NJnNO/oRlg7TFWR20ZUnB+VhQAAJ0QA From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Well, here's one problem that I see: >=20 > MIPv6 has the following (p100) " the home agent MUST verify that the > Source > Address in the tunnel IP header is the mobile node's primary > care-of address. " >=20 > Our implementation of that text is (high level, there's more to it): > =20 > 1) take source of inner packet > 2) find BCE for source. If not found drop packet > 3) check primary care of in BCE against tunnel source. If equal > decapsulate else drop. =3D> ok. >=20 > This compares to Nemo (P27)=20 > "The Home Agent has to verify that packets received through the > bi-directional tunnel belong to the mobile network. (...)=20 > The source > address > of the inner IPv6 header MUST be a topologically correct=20 > address with > respect to the IPv6 prefixes used in the mobile network." >=20 > The topological correctness normally means that packets to=20 > the source of > the inner packets would be routed via MRHA the tunnel. This=20 > is important > because it's one way to find the BCE to perform rge mandated=20 > checkings =3D> Right, and this is where you have a range to play with. You could either have a specific entry for that MR, or allow a larger range of prefixes into the network (e.g. if the MR on the train or plane does access control) > -Alternate would be to index the BCE by CareOf and hope that=20 > there's a > single registration for a given CareOf, which is not guaranteed while > generally true be it to make SA determination simpler-.=20 =3D> Right, so there should only be one CoA. But I agree that this might add some complexity to the process of accepting the BU from the MR in the first place (need to make sure that the MR is not stealing another MR's CoA). However,=20 in MIPv6 the assumption was made that there is no need for a CoA test when sending a BU to the HA. Whether this is=20 right or not, since nemo is based on MIPv6 we can follow the same assumption? Basically any vulnerability would apply to MIPv6 anyway so I wonder if we need to make nemo more secure than MIPv6. > 1) take source of inner packet.=20 > 2) resolve via_gateway (should be MR Home Address) by=20 > reverse lookup in > routing table > (there can be more than one IPv6 adjacency) > 3) find BCE for via_gateway(s). If none found drop packet > 4) check primary care of in BCE against tunnel source.=20 > If equal for at least one adjacency decapsulate else drop. =3D> Ok. Hesham From exim@www1.ietf.org Thu Mar 18 10:45:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20913 for ; Thu, 18 Mar 2004 10:45:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zi1-0007Ge-Nu for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 10:45:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IFjPD3027935 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 10:45:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zi0-0007GU-UO for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 10:45:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20906 for ; Thu, 18 Mar 2004 10:45:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zhy-00078R-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:45:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zh3-00076q-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:44:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3zgi-00075v-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 10:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zgf-000790-FT; Thu, 18 Mar 2004 10:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zfv-000707-GD for nemo@optimus.ietf.org; Thu, 18 Mar 2004 10:43:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20819 for ; Thu, 18 Mar 2004 10:43:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zft-00073d-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:43:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zfP-00071Z-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:42:44 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zej-0006vY-00 for nemo@ietf.org; Thu, 18 Mar 2004 10:42:01 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 10:41:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM/NJnNO/oRlg7TFWR20ZUnB+VhQAAJ0QA From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Well, here's one problem that I see: >=20 > MIPv6 has the following (p100) " the home agent MUST verify that the > Source > Address in the tunnel IP header is the mobile node's primary > care-of address. " >=20 > Our implementation of that text is (high level, there's more to it): > =20 > 1) take source of inner packet > 2) find BCE for source. If not found drop packet > 3) check primary care of in BCE against tunnel source. If equal > decapsulate else drop. =3D> ok. >=20 > This compares to Nemo (P27)=20 > "The Home Agent has to verify that packets received through the > bi-directional tunnel belong to the mobile network. (...)=20 > The source > address > of the inner IPv6 header MUST be a topologically correct=20 > address with > respect to the IPv6 prefixes used in the mobile network." >=20 > The topological correctness normally means that packets to=20 > the source of > the inner packets would be routed via MRHA the tunnel. This=20 > is important > because it's one way to find the BCE to perform rge mandated=20 > checkings =3D> Right, and this is where you have a range to play with. You could either have a specific entry for that MR, or allow a larger range of prefixes into the network (e.g. if the MR on the train or plane does access control) > -Alternate would be to index the BCE by CareOf and hope that=20 > there's a > single registration for a given CareOf, which is not guaranteed while > generally true be it to make SA determination simpler-.=20 =3D> Right, so there should only be one CoA. But I agree that this might add some complexity to the process of accepting the BU from the MR in the first place (need to make sure that the MR is not stealing another MR's CoA). However,=20 in MIPv6 the assumption was made that there is no need for a CoA test when sending a BU to the HA. Whether this is=20 right or not, since nemo is based on MIPv6 we can follow the same assumption? Basically any vulnerability would apply to MIPv6 anyway so I wonder if we need to make nemo more secure than MIPv6. > 1) take source of inner packet.=20 > 2) resolve via_gateway (should be MR Home Address) by=20 > reverse lookup in > routing table > (there can be more than one IPv6 adjacency) > 3) find BCE for via_gateway(s). If none found drop packet > 4) check primary care of in BCE against tunnel source.=20 > If equal for at least one adjacency decapsulate else drop. =3D> Ok. Hesham From nemo-admin@ietf.org Thu Mar 18 11:11:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22175 for ; Thu, 18 Mar 2004 11:11:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B406o-0000My-KS; Thu, 18 Mar 2004 11:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B406L-0000I5-9S for nemo@optimus.ietf.org; Thu, 18 Mar 2004 11:10:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22134 for ; Thu, 18 Mar 2004 11:10:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4069-0000fP-00 for nemo@ietf.org; Thu, 18 Mar 2004 11:10:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B405M-0000dh-00 for nemo@ietf.org; Thu, 18 Mar 2004 11:09:33 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B404g-0000Yf-00 for nemo@ietf.org; Thu, 18 Mar 2004 11:08:50 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 08:13:33 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IG7liZ010663; Thu, 18 Mar 2004 17:07:47 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 16:08:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 16:08:15 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM/NJnNO/oRlg7TFWR20ZUnB+VhQAAJ0QAAAEnTQA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 16:08:17.0004 (UTC) FILETIME=[39440AC0:01C40D03] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > =3D> Right, and this is where you have a range to play with. > You could either have a specific entry for that MR, or allow > a larger range of prefixes into the network (e.g. if the MR > on the train or plane does access control) >=20 > > -Alternate would be to index the BCE by CareOf and hope that > > there's a > > single registration for a given CareOf, which is not guaranteed while > > generally true be it to make SA determination simpler-. >=20 > =3D> Right, so there should only be one CoA. But I agree that > this might add some complexity to the process of accepting > the BU from the MR in the first place (need to make sure > that the MR is not stealing another MR's CoA). However, > in MIPv6 the assumption was made that there is no need for > a CoA test when sending a BU to the HA. Whether this is > right or not, since nemo is based on MIPv6 we can follow > the same assumption? Basically any vulnerability would > apply to MIPv6 anyway so I wonder if we need to make nemo > more secure than MIPv6. >=20 >=20 You know, the problem is when detunnelling a packet. At that time, the home address is not the source of the packet like in MIP6. MIPv6 does not mandate that the BCE be indexed by CareOf and it's not needed in terms of implementation, since we have the home address in the packet anyway. Today Nemo does not make any assumption on whether the CareOf is used to index the BCE, either. But if the reverse lookup of the inner source can not be used, now you are making that assumption. I see the cost, but fail to see the value? Pascal From exim@www1.ietf.org Thu Mar 18 11:13:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22257 for ; Thu, 18 Mar 2004 11:13:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B408K-0000Wp-7U for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 11:12:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IGCa8d002032 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 11:12:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B408K-0000Wh-1J for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 11:12:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22242 for ; Thu, 18 Mar 2004 11:12:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B408J-0000m0-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 11:12:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B407J-0000jP-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 11:11:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B406z-0000gs-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 11:11:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B406o-0000My-KS; Thu, 18 Mar 2004 11:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B406L-0000I5-9S for nemo@optimus.ietf.org; Thu, 18 Mar 2004 11:10:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22134 for ; Thu, 18 Mar 2004 11:10:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4069-0000fP-00 for nemo@ietf.org; Thu, 18 Mar 2004 11:10:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B405M-0000dh-00 for nemo@ietf.org; Thu, 18 Mar 2004 11:09:33 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B404g-0000Yf-00 for nemo@ietf.org; Thu, 18 Mar 2004 11:08:50 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 08:13:33 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IG7liZ010663; Thu, 18 Mar 2004 17:07:47 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Mar 2004 16:08:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2004 16:08:15 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM/NJnNO/oRlg7TFWR20ZUnB+VhQAAJ0QAAAEnTQA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 18 Mar 2004 16:08:17.0004 (UTC) FILETIME=[39440AC0:01C40D03] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > =3D> Right, and this is where you have a range to play with. > You could either have a specific entry for that MR, or allow > a larger range of prefixes into the network (e.g. if the MR > on the train or plane does access control) >=20 > > -Alternate would be to index the BCE by CareOf and hope that > > there's a > > single registration for a given CareOf, which is not guaranteed while > > generally true be it to make SA determination simpler-. >=20 > =3D> Right, so there should only be one CoA. But I agree that > this might add some complexity to the process of accepting > the BU from the MR in the first place (need to make sure > that the MR is not stealing another MR's CoA). However, > in MIPv6 the assumption was made that there is no need for > a CoA test when sending a BU to the HA. Whether this is > right or not, since nemo is based on MIPv6 we can follow > the same assumption? Basically any vulnerability would > apply to MIPv6 anyway so I wonder if we need to make nemo > more secure than MIPv6. >=20 >=20 You know, the problem is when detunnelling a packet. At that time, the home address is not the source of the packet like in MIP6. MIPv6 does not mandate that the BCE be indexed by CareOf and it's not needed in terms of implementation, since we have the home address in the packet anyway. Today Nemo does not make any assumption on whether the CareOf is used to index the BCE, either. But if the reverse lookup of the inner source can not be used, now you are making that assumption. I see the cost, but fail to see the value? Pascal From nemo-admin@ietf.org Thu Mar 18 13:22:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28890 for ; Thu, 18 Mar 2004 13:22:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B429Y-0007ZT-SS; Thu, 18 Mar 2004 13:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4297-0007Yz-Lk for nemo@optimus.ietf.org; Thu, 18 Mar 2004 13:21:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28839 for ; Thu, 18 Mar 2004 13:21:31 -0500 (EST) From: ernst@sfc.wide.ad.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4295-0000vA-00 for nemo@ietf.org; Thu, 18 Mar 2004 13:21:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B428F-0000sg-00 for nemo@ietf.org; Thu, 18 Mar 2004 13:20:39 -0500 Received: from [203.237.53.129] (helo=SANGHOON.org) by ietf-mx with smtp (Exim 4.12) id 1B427X-0000q9-00 for nemo@ietf.org; Thu, 18 Mar 2004 13:19:55 -0500 Date: Fri, 19 Mar 2004 03:11:04 +0900 To: nemo@ietf.org Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.6 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_EMBEDS,HTML_MESSAGE, MIME_HTML_ONLY,NORMAL_HTTP_TO_IP,NO_REAL_NAME,WEIRD_PORT autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.9 WEIRD_PORT URI: Uses non-standard port number for HTTP * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [nemo] Request response Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From exim@www1.ietf.org Thu Mar 18 13:23:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28924 for ; Thu, 18 Mar 2004 13:23:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42AE-0007fI-UB for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 13:22:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IIMgBj029463 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 13:22:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42AE-0007f8-Oq for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 13:22:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28919 for ; Thu, 18 Mar 2004 13:22:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42AC-000103-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 13:22:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B429b-0000wy-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 13:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B429Y-0007ZT-SS; Thu, 18 Mar 2004 13:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4297-0007Yz-Lk for nemo@optimus.ietf.org; Thu, 18 Mar 2004 13:21:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28839 for ; Thu, 18 Mar 2004 13:21:31 -0500 (EST) From: ernst@sfc.wide.ad.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4295-0000vA-00 for nemo@ietf.org; Thu, 18 Mar 2004 13:21:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B428F-0000sg-00 for nemo@ietf.org; Thu, 18 Mar 2004 13:20:39 -0500 Received: from [203.237.53.129] (helo=SANGHOON.org) by ietf-mx with smtp (Exim 4.12) id 1B427X-0000q9-00 for nemo@ietf.org; Thu, 18 Mar 2004 13:19:55 -0500 Date: Fri, 19 Mar 2004 03:11:04 +0900 To: nemo@ietf.org Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.6 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_EMBEDS,HTML_MESSAGE, MIME_HTML_ONLY,NORMAL_HTTP_TO_IP,NO_REAL_NAME,WEIRD_PORT autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.9 WEIRD_PORT URI: Uses non-standard port number for HTTP * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [nemo] Request response Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit From nemo-admin@ietf.org Thu Mar 18 21:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23375 for ; Thu, 18 Mar 2004 21:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49XK-00007V-AE; Thu, 18 Mar 2004 21:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49X7-00006r-Ha for nemo@optimus.ietf.org; Thu, 18 Mar 2004 21:14:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23360 for ; Thu, 18 Mar 2004 21:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49X4-0002eC-00 for nemo@ietf.org; Thu, 18 Mar 2004 21:14:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49WA-0002bI-00 for nemo@ietf.org; Thu, 18 Mar 2004 21:13:51 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B49VN-0002Ur-00 for nemo@ietf.org; Thu, 18 Mar 2004 21:13:01 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 21:12:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQNAzvTsW0gKqVDRKuIny167pOu6gAUytWA From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Today Nemo does not make any assumption on whether the=20 > CareOf is used to > index the BCE, either. But if the reverse lookup of the=20 > inner source can > not be used, now you are making that assumption. I see the cost, =3D> Yes that's the assumption for this scenario to work. What is the cost?=20 Hesham From exim@www1.ietf.org Thu Mar 18 21:17:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23443 for ; Thu, 18 Mar 2004 21:17:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49Z1-0000HO-Fj for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 21:16:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J2GlBl001072 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 21:16:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49Z1-0000HD-7T for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 21:16:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23423 for ; Thu, 18 Mar 2004 21:16:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49Yy-0002kn-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 21:16:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49Y1-0002i6-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 21:15:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B49XN-0002fk-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 21:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49XK-00007V-AE; Thu, 18 Mar 2004 21:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49X7-00006r-Ha for nemo@optimus.ietf.org; Thu, 18 Mar 2004 21:14:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23360 for ; Thu, 18 Mar 2004 21:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49X4-0002eC-00 for nemo@ietf.org; Thu, 18 Mar 2004 21:14:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49WA-0002bI-00 for nemo@ietf.org; Thu, 18 Mar 2004 21:13:51 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B49VN-0002Ur-00 for nemo@ietf.org; Thu, 18 Mar 2004 21:13:01 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 21:12:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQNAzvTsW0gKqVDRKuIny167pOu6gAUytWA From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Today Nemo does not make any assumption on whether the=20 > CareOf is used to > index the BCE, either. But if the reverse lookup of the=20 > inner source can > not be used, now you are making that assumption. I see the cost, =3D> Yes that's the assumption for this scenario to work. What is the cost?=20 Hesham From nemo-admin@ietf.org Fri Mar 19 07:33:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29200 for ; Fri, 19 Mar 2004 07:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JBN-0005Z7-3R; Fri, 19 Mar 2004 07:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JAb-0005Xz-JG for nemo@optimus.ietf.org; Fri, 19 Mar 2004 07:32:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29180 for ; Fri, 19 Mar 2004 07:32:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JAa-0003IN-00 for nemo@ietf.org; Fri, 19 Mar 2004 07:32:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4J9t-0003CX-00 for nemo@ietf.org; Fri, 19 Mar 2004 07:31:32 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B4J8j-00032T-00 for nemo@ietf.org; Fri, 19 Mar 2004 07:30:17 -0500 Received: from wanwan.sfc.wide.ad.jp (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 7D7FE5D114; Fri, 19 Mar 2004 21:29:45 +0900 (JST) Date: Fri, 19 Mar 2004 21:29:45 +0900 Message-ID: From: Koshiro MITSUYA To: "O.L.N.Rao" Cc: nemo@ietf.org Subject: Re: [nemo] Any Implementations to Test In-Reply-To: <025601c40b63$d7fa27e0$7a476c6b@sisodomain.com> References: <025601c40b63$d7fa27e0$7a476c6b@sisodomain.com> User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi O.L.N.Rao, My name is Koshiro MITSUYA from Nautilus Project in Japan. http://www.nautilus6.org/ We have own implementation based on draft-02. We want to release our implementation as soon as possible, but the IPR problem from CISCO and NOKIA is still unclear for me, and we are asking our lawyer about it. By the way, there is no problem you use our implementation only for a testing uses. If you has interesting on this, plese ask me! regards, Koshiro At Tue, 16 Mar 2004 20:04:50 +0530, O.L.N.Rao wrote: > > [1 ] > Hi All, > > Recently i have gone through the NEMO Basic Support protocol > and it is very much interesting to me. I really wanted to see the > scenarios in working. > > Are there any open implementations available for me to go with ? > > I would be very thankful for the pointers in this regard. > > Thanks in advance. > > Regards, > O.L.N.Rao > [2 ] > From exim@www1.ietf.org Fri Mar 19 07:35:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29315 for ; Fri, 19 Mar 2004 07:35:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JDM-0005fs-8J for nemo-archive@odin.ietf.org; Fri, 19 Mar 2004 07:35:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JCZ4Il021808 for nemo-archive@odin.ietf.org; Fri, 19 Mar 2004 07:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JDM-0005ff-25 for nemo-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 07:35:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29255 for ; Fri, 19 Mar 2004 07:35:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JDL-0003Vt-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 07:35:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4JCS-0003RM-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 07:34:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4JBP-0003MQ-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 07:33:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JBN-0005Z7-3R; Fri, 19 Mar 2004 07:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JAb-0005Xz-JG for nemo@optimus.ietf.org; Fri, 19 Mar 2004 07:32:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29180 for ; Fri, 19 Mar 2004 07:32:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JAa-0003IN-00 for nemo@ietf.org; Fri, 19 Mar 2004 07:32:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4J9t-0003CX-00 for nemo@ietf.org; Fri, 19 Mar 2004 07:31:32 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B4J8j-00032T-00 for nemo@ietf.org; Fri, 19 Mar 2004 07:30:17 -0500 Received: from wanwan.sfc.wide.ad.jp (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 7D7FE5D114; Fri, 19 Mar 2004 21:29:45 +0900 (JST) Date: Fri, 19 Mar 2004 21:29:45 +0900 Message-ID: From: Koshiro MITSUYA To: "O.L.N.Rao" Cc: nemo@ietf.org Subject: Re: [nemo] Any Implementations to Test In-Reply-To: <025601c40b63$d7fa27e0$7a476c6b@sisodomain.com> References: <025601c40b63$d7fa27e0$7a476c6b@sisodomain.com> User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi O.L.N.Rao, My name is Koshiro MITSUYA from Nautilus Project in Japan. http://www.nautilus6.org/ We have own implementation based on draft-02. We want to release our implementation as soon as possible, but the IPR problem from CISCO and NOKIA is still unclear for me, and we are asking our lawyer about it. By the way, there is no problem you use our implementation only for a testing uses. If you has interesting on this, plese ask me! regards, Koshiro At Tue, 16 Mar 2004 20:04:50 +0530, O.L.N.Rao wrote: > > [1 ] > Hi All, > > Recently i have gone through the NEMO Basic Support protocol > and it is very much interesting to me. I really wanted to see the > scenarios in working. > > Are there any open implementations available for me to go with ? > > I would be very thankful for the pointers in this regard. > > Thanks in advance. > > Regards, > O.L.N.Rao > [2 ] > From nemo-admin@ietf.org Fri Mar 19 12:59:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12944 for ; Fri, 19 Mar 2004 12:59:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OH1-0002Ly-LK; Fri, 19 Mar 2004 12:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OG7-0002J3-MO for nemo@optimus.ietf.org; Fri, 19 Mar 2004 12:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12899 for ; Fri, 19 Mar 2004 12:58:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OG5-000742-00 for nemo@ietf.org; Fri, 19 Mar 2004 12:58:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OFF-00070U-00 for nemo@ietf.org; Fri, 19 Mar 2004 12:57:22 -0500 Received: from baton.cs.ucdavis.edu ([169.237.6.6]) by ietf-mx with esmtp (Exim 4.12) id 1B4OEk-0006vf-00 for nemo@ietf.org; Fri, 19 Mar 2004 12:56:51 -0500 Received: from baton.cs.ucdavis.edu (localhost [127.0.0.1]) by baton.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i2JHunDC009738 for ; Fri, 19 Mar 2004 09:56:49 -0800 (PST) Received: from soda.cs.ucdavis.edu (soda.cs.ucdavis.edu [169.237.6.187]) by baton.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i2JHune6009736; Fri, 19 Mar 2004 09:56:49 -0800 (PST) Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i2JHul7S014371; Fri, 19 Mar 2004 09:56:48 -0800 (PST) Message-ID: <405B345A.5070106@cs.ucdavis.edu> Date: Fri, 19 Mar 2004 09:56:42 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG CC: Thierry Ernst , tj@kniveton.com, hscho@mmlab.snu.ac.kr, shcho@popeye.snu.ac.kr, souhwanj@ssu.ac.kr, Hong-Yon.Lach@motorola.com, montavont@lsiit.u-strasbg.fr, cwng@psl.com.sg, wu@cs.ucdavis.edu Subject: [nemo] meeting minutes for the special NEMO security session References: <404FF0F5.7060306@cs.ucdavis.edu> <20040319181752.5f9cf157.ernst@sfc.wide.ad.jp> In-Reply-To: <20040319181752.5f9cf157.ernst@sfc.wide.ad.jp> Content-Type: multipart/mixed; boundary="------------050800000606060102050802" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------050800000606060102050802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------050800000606060102050802 Content-Type: text/plain; name="NEMO-security-special-meeting-IETF59.txt" Content-Disposition: inline; filename="NEMO-security-special-meeting-IETF59.txt" Content-Transfer-Encoding: 7bit The meeting minutes for the special NEMO security session in 59th IETF Attendee: Hosik Cho Seoul National University hscho@mmlab.snu.ac.kr Seongho Cho Seoul National University shcho@popeye.snu.ac.kr Thierry Ernst WIDE/Keio University ernst@sfc.wide.ad.jp Souhwan Jung Soongsil University souhwanj@ssu.ac.kr T.J. Kniveton Nokia tj@kniveton.com Hong-Yon Lach Motorola Labs Hong-Yon.Lach@motorola.com Nicolas Montavont ULP-LSIIT montavont@lsiit.u-strasbg.fr Chan Wah Ng Panasonic Singapore Lab. cwng@psl.com.sg S. Felix Wu University of California,Davis wu@cs.ucdavis.edu (the minute taker) Purpose of this meeting: Many NEMO contributors have recognized the importance of security analysis for the standards being developed under this working group. To avoid any significant duplication as well as to cover the security space completely, a few of us got together at 11:00 a.m. on March 4th, 2004 during the Seoul IETF meeting. This document tries to catch the issues as well as the rough consensus among the participants. TJ: >From our experience in dealing with security issues in MIPv6 (which still has security problems unsolved), it is better and important to consider the security issues under NEMO from the beginning. Please note that the scope of the security analysis works under NEMO can be broader to cover the general security issues in mobility in today's Internet. Felix: I feel that the security analysis task is important for several reasons. It certainly can help to analyze the potential weaknesses in the current drafts. But also, a good document about the security analysis work will help us later to expand and to re-evaluate the security related issues. Hongyon: The Motorola group is very interested in the security protection issues related to mobility, such as protocol protection and DDoS. We are examining the security issues in the basic NEMO support. Felix: Maybe we should first study the "security requirements" for the protection results in the basic NEMO support such as "what should the NEMO basic support achieve related to security." TJ: "Requirement" may not be the best term to describe what we are trying to do here, and maybe we should use the term "philosophy". We need to clearly clarify the general approach ("philosophy") for securing the NEMO basic support. Felix: I suggest that, under NEMO, we have four different areas related to security: basic support (including MIPv6 and IPsec related issues), Nested NEMO, Multi-homing, and operational consideration. Thierry: We should first consider, explicitly, scenarios for the most basic NEMO configuration. I.e., no nested and no multihoming. ???: (need a confirmation from TJ) IRTF might have a group (or is forming a working group) covering cover the subject for mobile network security. The first step for us (NEMO) is to cover the "basic" security issues, and then later we can worry about more advanced issues. Immediately, this is what we need to do: (1). We need to have "one pass" to examine whether the current basic support draft is self-contained and sufficient for the security protection. (2). If there are issues not being covered in the basic support draft (such as the multi-homing issue), then we need to explicitly mention it in the draft. This is very important for the IESG to evaluate the NEMO basic support. These should be done very soon (within a week hopefully). Whether to have a separate draft to document this task depends on whether the basic support draft can cover the issues sufficiently. Souhwan: There are several interesting security cases in our new draft. Conclusions: (1). We need to examine the security issues for the basic support very quickly (one week), and we need to make the document explicit regarding the security issues for IESG. We would like to emphasize that security in NEMO Basic Support MUST BE proof-checked ***ASAP*** (for the 'most basic configurations'). (2). Alex/S. Cho/TJ/Souhwan are all interested to analyze the security of NEMO basic support (one more pass), while, somewhat implicitly, Felix (??) or others will find somebody in the security area (as an outsider) to help the NEMO group for this task as well. --------------050800000606060102050802-- From exim@www1.ietf.org Fri Mar 19 13:01:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13133 for ; Fri, 19 Mar 2004 13:01:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OJB-0002Xl-Mb for nemo-archive@odin.ietf.org; Fri, 19 Mar 2004 13:01:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JI1PVO009776 for nemo-archive@odin.ietf.org; Fri, 19 Mar 2004 13:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OJB-0002Xb-BB for nemo-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 13:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13027 for ; Fri, 19 Mar 2004 13:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OJ8-0007Sn-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 13:01:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OI7-0007Ii-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 13:00:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4OHB-0007Bi-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 12:59:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OH1-0002Ly-LK; Fri, 19 Mar 2004 12:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OG7-0002J3-MO for nemo@optimus.ietf.org; Fri, 19 Mar 2004 12:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12899 for ; Fri, 19 Mar 2004 12:58:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OG5-000742-00 for nemo@ietf.org; Fri, 19 Mar 2004 12:58:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OFF-00070U-00 for nemo@ietf.org; Fri, 19 Mar 2004 12:57:22 -0500 Received: from baton.cs.ucdavis.edu ([169.237.6.6]) by ietf-mx with esmtp (Exim 4.12) id 1B4OEk-0006vf-00 for nemo@ietf.org; Fri, 19 Mar 2004 12:56:51 -0500 Received: from baton.cs.ucdavis.edu (localhost [127.0.0.1]) by baton.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i2JHunDC009738 for ; Fri, 19 Mar 2004 09:56:49 -0800 (PST) Received: from soda.cs.ucdavis.edu (soda.cs.ucdavis.edu [169.237.6.187]) by baton.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i2JHune6009736; Fri, 19 Mar 2004 09:56:49 -0800 (PST) Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i2JHul7S014371; Fri, 19 Mar 2004 09:56:48 -0800 (PST) Message-ID: <405B345A.5070106@cs.ucdavis.edu> Date: Fri, 19 Mar 2004 09:56:42 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG CC: Thierry Ernst , tj@kniveton.com, hscho@mmlab.snu.ac.kr, shcho@popeye.snu.ac.kr, souhwanj@ssu.ac.kr, Hong-Yon.Lach@motorola.com, montavont@lsiit.u-strasbg.fr, cwng@psl.com.sg, wu@cs.ucdavis.edu Subject: [nemo] meeting minutes for the special NEMO security session References: <404FF0F5.7060306@cs.ucdavis.edu> <20040319181752.5f9cf157.ernst@sfc.wide.ad.jp> In-Reply-To: <20040319181752.5f9cf157.ernst@sfc.wide.ad.jp> Content-Type: multipart/mixed; boundary="------------050800000606060102050802" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050800000606060102050802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------050800000606060102050802 Content-Type: text/plain; name="NEMO-security-special-meeting-IETF59.txt" Content-Disposition: inline; filename="NEMO-security-special-meeting-IETF59.txt" Content-Transfer-Encoding: 7bit The meeting minutes for the special NEMO security session in 59th IETF Attendee: Hosik Cho Seoul National University hscho@mmlab.snu.ac.kr Seongho Cho Seoul National University shcho@popeye.snu.ac.kr Thierry Ernst WIDE/Keio University ernst@sfc.wide.ad.jp Souhwan Jung Soongsil University souhwanj@ssu.ac.kr T.J. Kniveton Nokia tj@kniveton.com Hong-Yon Lach Motorola Labs Hong-Yon.Lach@motorola.com Nicolas Montavont ULP-LSIIT montavont@lsiit.u-strasbg.fr Chan Wah Ng Panasonic Singapore Lab. cwng@psl.com.sg S. Felix Wu University of California,Davis wu@cs.ucdavis.edu (the minute taker) Purpose of this meeting: Many NEMO contributors have recognized the importance of security analysis for the standards being developed under this working group. To avoid any significant duplication as well as to cover the security space completely, a few of us got together at 11:00 a.m. on March 4th, 2004 during the Seoul IETF meeting. This document tries to catch the issues as well as the rough consensus among the participants. TJ: >From our experience in dealing with security issues in MIPv6 (which still has security problems unsolved), it is better and important to consider the security issues under NEMO from the beginning. Please note that the scope of the security analysis works under NEMO can be broader to cover the general security issues in mobility in today's Internet. Felix: I feel that the security analysis task is important for several reasons. It certainly can help to analyze the potential weaknesses in the current drafts. But also, a good document about the security analysis work will help us later to expand and to re-evaluate the security related issues. Hongyon: The Motorola group is very interested in the security protection issues related to mobility, such as protocol protection and DDoS. We are examining the security issues in the basic NEMO support. Felix: Maybe we should first study the "security requirements" for the protection results in the basic NEMO support such as "what should the NEMO basic support achieve related to security." TJ: "Requirement" may not be the best term to describe what we are trying to do here, and maybe we should use the term "philosophy". We need to clearly clarify the general approach ("philosophy") for securing the NEMO basic support. Felix: I suggest that, under NEMO, we have four different areas related to security: basic support (including MIPv6 and IPsec related issues), Nested NEMO, Multi-homing, and operational consideration. Thierry: We should first consider, explicitly, scenarios for the most basic NEMO configuration. I.e., no nested and no multihoming. ???: (need a confirmation from TJ) IRTF might have a group (or is forming a working group) covering cover the subject for mobile network security. The first step for us (NEMO) is to cover the "basic" security issues, and then later we can worry about more advanced issues. Immediately, this is what we need to do: (1). We need to have "one pass" to examine whether the current basic support draft is self-contained and sufficient for the security protection. (2). If there are issues not being covered in the basic support draft (such as the multi-homing issue), then we need to explicitly mention it in the draft. This is very important for the IESG to evaluate the NEMO basic support. These should be done very soon (within a week hopefully). Whether to have a separate draft to document this task depends on whether the basic support draft can cover the issues sufficiently. Souhwan: There are several interesting security cases in our new draft. Conclusions: (1). We need to examine the security issues for the basic support very quickly (one week), and we need to make the document explicit regarding the security issues for IESG. We would like to emphasize that security in NEMO Basic Support MUST BE proof-checked ***ASAP*** (for the 'most basic configurations'). (2). Alex/S. Cho/TJ/Souhwan are all interested to analyze the security of NEMO basic support (one more pass), while, somewhat implicitly, Felix (??) or others will find somebody in the security area (as an outsider) to help the NEMO group for this task as well. --------------050800000606060102050802-- From nemo-admin@ietf.org Fri Mar 19 13:31:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14284 for ; Fri, 19 Mar 2004 13:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Olq-0004g1-4W; Fri, 19 Mar 2004 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OlC-0004eb-Ga for nemo@optimus.ietf.org; Fri, 19 Mar 2004 13:30:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14241 for ; Fri, 19 Mar 2004 13:30:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OlA-0002LZ-00 for nemo@ietf.org; Fri, 19 Mar 2004 13:30:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OkE-0002Ha-00 for nemo@ietf.org; Fri, 19 Mar 2004 13:29:23 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1B4OjY-0001tL-00 for nemo@ietf.org; Fri, 19 Mar 2004 13:28:40 -0500 Received: from [64.36.73.246] (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id i2JIPuEg094386 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 19 Mar 2004 10:25:58 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <405B345A.5070106@cs.ucdavis.edu> References: <404FF0F5.7060306@cs.ucdavis.edu> <20040319181752.5f9cf157.ernst@sfc.wide.ad.jp> <405B345A.5070106@cs.ucdavis.edu> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-481766575; protocol="application/pkcs7-signature" Message-Id: From: "T.J. Kniveton" Subject: Re: [nemo] meeting minutes for the special NEMO security session Date: Fri, 19 Mar 2004 10:24:57 -0800 To: IETF NEMO WG X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --Apple-Mail-1-481766575 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 19, 2004, at 9:56 AM, S. Felix Wu wrote: > ???: (need a confirmation from TJ) > IRTF might have a group (or is forming a working group) covering cover > the subject for mobile network security. The first step for us (NEMO) > is to cover the "basic" security issues, and then later we can > worry about more advanced issues. > This was a comment about the MOBOPTS group, which is looking at mobility research issues within the IRTF. It is already formed and met for the first time at IETF 59. They may be interested in that group to look at more general and longer-term security problems. TJ --Apple-Mail-1-481766575 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxOTE4MjQ1 OFowIwYJKoZIhvcNAQkEMRYEFN/4tEfSsTLdGJzJuPRMqrvk40dNMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgFGu17V49WIWfz2EH0R/xMqM7AG3JMdvAzRVxImbzcs3 +f58bTqxb3UzOsv91sEeRQTHG7Di8e2q3/1wSzodJFj4Uzt+a7bGdPznQ231nqX34cnSJY/lBE5q a93IInG/cqwlUyfUdPBUZNESBbGlfy4attRWpYtbgD3w+obqDOxpAAAAAAAA --Apple-Mail-1-481766575-- From exim@www1.ietf.org Fri Mar 19 13:32:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14463 for ; Fri, 19 Mar 2004 13:32:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4On5-0004rD-QE for nemo-archive@odin.ietf.org; Fri, 19 Mar 2004 13:32:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JIWJ2I018670 for nemo-archive@odin.ietf.org; Fri, 19 Mar 2004 13:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4On5-0004r3-F1 for nemo-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 13:32:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14308 for ; Fri, 19 Mar 2004 13:32:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4On3-0002Vi-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 13:32:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OmC-0002Qz-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 13:31:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Olr-0002N7-00 for nemo-web-archive@ietf.org; Fri, 19 Mar 2004 13:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Olq-0004g1-4W; Fri, 19 Mar 2004 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4OlC-0004eb-Ga for nemo@optimus.ietf.org; Fri, 19 Mar 2004 13:30:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14241 for ; Fri, 19 Mar 2004 13:30:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4OlA-0002LZ-00 for nemo@ietf.org; Fri, 19 Mar 2004 13:30:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OkE-0002Ha-00 for nemo@ietf.org; Fri, 19 Mar 2004 13:29:23 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1B4OjY-0001tL-00 for nemo@ietf.org; Fri, 19 Mar 2004 13:28:40 -0500 Received: from [64.36.73.246] (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id i2JIPuEg094386 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 19 Mar 2004 10:25:58 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <405B345A.5070106@cs.ucdavis.edu> References: <404FF0F5.7060306@cs.ucdavis.edu> <20040319181752.5f9cf157.ernst@sfc.wide.ad.jp> <405B345A.5070106@cs.ucdavis.edu> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-481766575; protocol="application/pkcs7-signature" Message-Id: From: "T.J. Kniveton" Subject: Re: [nemo] meeting minutes for the special NEMO security session Date: Fri, 19 Mar 2004 10:24:57 -0800 To: IETF NEMO WG X-Mailer: Apple Mail (2.613) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-1-481766575 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 19, 2004, at 9:56 AM, S. Felix Wu wrote: > ???: (need a confirmation from TJ) > IRTF might have a group (or is forming a working group) covering cover > the subject for mobile network security. The first step for us (NEMO) > is to cover the "basic" security issues, and then later we can > worry about more advanced issues. > This was a comment about the MOBOPTS group, which is looking at mobility research issues within the IRTF. It is already formed and met for the first time at IETF 59. They may be interested in that group to look at more general and longer-term security problems. TJ --Apple-Mail-1-481766575 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxOTE4MjQ1 OFowIwYJKoZIhvcNAQkEMRYEFN/4tEfSsTLdGJzJuPRMqrvk40dNMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgFGu17V49WIWfz2EH0R/xMqM7AG3JMdvAzRVxImbzcs3 +f58bTqxb3UzOsv91sEeRQTHG7Di8e2q3/1wSzodJFj4Uzt+a7bGdPznQ231nqX34cnSJY/lBE5q a93IInG/cqwlUyfUdPBUZNESBbGlfy4attRWpYtbgD3w+obqDOxpAAAAAAAA --Apple-Mail-1-481766575-- From nemo-admin@ietf.org Mon Mar 22 02:58:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08980 for ; Mon, 22 Mar 2004 02:58:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KJt-0005uG-Mu; Mon, 22 Mar 2004 02:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KJA-0005oG-BO for nemo@optimus.ietf.org; Mon, 22 Mar 2004 02:57:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08948 for ; Mon, 22 Mar 2004 02:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5KJ6-0003ag-00 for nemo@ietf.org; Mon, 22 Mar 2004 02:57:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5KI9-0003Ue-00 for nemo@ietf.org; Mon, 22 Mar 2004 02:56:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B5KHJ-0003KJ-00 for nemo@ietf.org; Mon, 22 Mar 2004 02:55:22 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2004 00:01:06 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2M7sAib013801; Mon, 22 Mar 2004 08:54:12 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Mar 2004 07:54:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Mon, 22 Mar 2004 07:54:41 -0000 Message-ID: Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM6n/CWt0grJZBQC2dct73Pr8rEQC9i+nw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 22 Mar 2004 07:54:42.0041 (UTC) FILETIME=[EF064E90:01C40FE2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Pascal Thubert (pthubert) wrote: > > Agreed: > > The test was not designed yet. The requirement for the test is still > > not agreed upon. So if this thread ends up anywhere, maybe it's to an > > answer to that question: Is there a need for a Duplicate Network > > Detection test that would check that when a prefix is registered twice, > > you end up on the same link for both registrations? >=20 > Good question. Today, I can manually enter two routing table entries > towards the same prefix but through different next-hops. Is there a need > for the system to check when a prefix is registered twice and warn me I > did so, or ban me from doing so? >=20 Agreed again :) I'm still unsure whether I missed something but my summary of all this discussion is that Nemo basic support inherits the current capabilities and limitations of the existing technology that it derives from. It's neither better nor worse. Nemo is an hybrid technology, half L2 centric as MIP and half L3 since routes are discovered an installed. Yet, since the routers are mobile, it may happen that for some reasons, router pairs that are expected and configured to share an ingress link and an ingress prefix actually split over time. It may be helpful to provide an optional test with Nemo to help discover such a situation. Note that existing management tooling can also be used, so it's all a matter of having the test automated, built in the protocol, versus leaving it externalized. An analogy is whether it is helpful to detect that a Home Address is duplicated in MIP, which is a configuration error for most cases that I can see as of today, and which, as was pointed out in the thread with Hesham, is only partially done, depending on whether the duplication affects the SAs and whether the duplicated MNs bind remotely to a same HA (in which case the protocol fails to detect the problem) or not. Pascal From exim@www1.ietf.org Mon Mar 22 03:00:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09033 for ; Mon, 22 Mar 2004 03:00:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KLN-000667-1i for nemo-archive@odin.ietf.org; Mon, 22 Mar 2004 02:59:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M7xW27023439 for nemo-archive@odin.ietf.org; Mon, 22 Mar 2004 02:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KLK-00065x-4W for nemo-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 02:59:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09021 for ; Mon, 22 Mar 2004 02:59:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5KLG-0003pN-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 02:59:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5KKd-0003jt-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 02:58:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5KJv-0003cU-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 02:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KJt-0005uG-Mu; Mon, 22 Mar 2004 02:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KJA-0005oG-BO for nemo@optimus.ietf.org; Mon, 22 Mar 2004 02:57:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08948 for ; Mon, 22 Mar 2004 02:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5KJ6-0003ag-00 for nemo@ietf.org; Mon, 22 Mar 2004 02:57:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5KI9-0003Ue-00 for nemo@ietf.org; Mon, 22 Mar 2004 02:56:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B5KHJ-0003KJ-00 for nemo@ietf.org; Mon, 22 Mar 2004 02:55:22 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2004 00:01:06 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2M7sAib013801; Mon, 22 Mar 2004 08:54:12 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Mar 2004 07:54:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Mon, 22 Mar 2004 07:54:41 -0000 Message-ID: Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQM6n/CWt0grJZBQC2dct73Pr8rEQC9i+nw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 22 Mar 2004 07:54:42.0041 (UTC) FILETIME=[EF064E90:01C40FE2] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Pascal Thubert (pthubert) wrote: > > Agreed: > > The test was not designed yet. The requirement for the test is still > > not agreed upon. So if this thread ends up anywhere, maybe it's to an > > answer to that question: Is there a need for a Duplicate Network > > Detection test that would check that when a prefix is registered twice, > > you end up on the same link for both registrations? >=20 > Good question. Today, I can manually enter two routing table entries > towards the same prefix but through different next-hops. Is there a need > for the system to check when a prefix is registered twice and warn me I > did so, or ban me from doing so? >=20 Agreed again :) I'm still unsure whether I missed something but my summary of all this discussion is that Nemo basic support inherits the current capabilities and limitations of the existing technology that it derives from. It's neither better nor worse. Nemo is an hybrid technology, half L2 centric as MIP and half L3 since routes are discovered an installed. Yet, since the routers are mobile, it may happen that for some reasons, router pairs that are expected and configured to share an ingress link and an ingress prefix actually split over time. It may be helpful to provide an optional test with Nemo to help discover such a situation. Note that existing management tooling can also be used, so it's all a matter of having the test automated, built in the protocol, versus leaving it externalized. An analogy is whether it is helpful to detect that a Home Address is duplicated in MIP, which is a configuration error for most cases that I can see as of today, and which, as was pointed out in the thread with Hesham, is only partially done, depending on whether the duplication affects the SAs and whether the duplicated MNs bind remotely to a same HA (in which case the protocol fails to detect the problem) or not. Pascal From nemo-admin@ietf.org Mon Mar 22 03:04:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09145 for ; Mon, 22 Mar 2004 03:04:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KPh-0006pF-9c; Mon, 22 Mar 2004 03:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KP0-0006oA-US for nemo@optimus.ietf.org; Mon, 22 Mar 2004 03:03:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09113 for ; Mon, 22 Mar 2004 03:03:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5KOx-00049c-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:03:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5KO2-00044X-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:02:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B5KNa-0003yQ-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:01:50 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2004 00:07:43 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2M80miZ015877; Mon, 22 Mar 2004 09:00:48 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Mar 2004 08:01:19 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2004 08:01:18 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQNAzvTsW0gKqVDRKuIny167pOu6gAUytWAAKMLkWA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 22 Mar 2004 08:01:19.0395 (UTC) FILETIME=[DBDDB730:01C40FE3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > Today Nemo does not make any assumption on whether the > > CareOf is used to > > index the BCE, either. But if the reverse lookup of the > > inner source can > > not be used, now you are making that assumption. I see the cost, >=20 > =3D> Yes that's the assumption for this scenario to work. > What is the cost? Broken ingress filtering, CaO indexing (which I suspect yields a number of problematic race conditions), broken existing implementations... I believe the draft is properly balanced for that matter. I personally would have left the text that said that Nemo does not bar multihoming (amongst other things) but there's clearly no protocol action designed to prevent it and I'm happy with that. I'm very positive on your suggestion to document the potential caveats related to multihoming. This could happen in the problem statement or in a later usage draft, either one I guess. Pascal From exim@www1.ietf.org Mon Mar 22 03:05:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09188 for ; Mon, 22 Mar 2004 03:05:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KR0-0006w5-4y for nemo-archive@odin.ietf.org; Mon, 22 Mar 2004 03:05:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M85Mwx026654 for nemo-archive@odin.ietf.org; Mon, 22 Mar 2004 03:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KQz-0006vp-SY for nemo-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 03:05:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09184 for ; Mon, 22 Mar 2004 03:05:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5KQv-0004KV-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 03:05:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5KQ9-0004Fu-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 03:04:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5KPg-0004Ap-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 03:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KPh-0006pF-9c; Mon, 22 Mar 2004 03:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5KP0-0006oA-US for nemo@optimus.ietf.org; Mon, 22 Mar 2004 03:03:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09113 for ; Mon, 22 Mar 2004 03:03:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5KOx-00049c-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:03:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5KO2-00044X-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:02:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B5KNa-0003yQ-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:01:50 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2004 00:07:43 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2M80miZ015877; Mon, 22 Mar 2004 09:00:48 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Mar 2004 08:01:19 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2004 08:01:18 -0000 Message-ID: Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQNAzvTsW0gKqVDRKuIny167pOu6gAUytWAAKMLkWA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: "IETF NEMO WG" X-OriginalArrivalTime: 22 Mar 2004 08:01:19.0395 (UTC) FILETIME=[DBDDB730:01C40FE3] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Today Nemo does not make any assumption on whether the > > CareOf is used to > > index the BCE, either. But if the reverse lookup of the > > inner source can > > not be used, now you are making that assumption. I see the cost, >=20 > =3D> Yes that's the assumption for this scenario to work. > What is the cost? Broken ingress filtering, CaO indexing (which I suspect yields a number of problematic race conditions), broken existing implementations... I believe the draft is properly balanced for that matter. I personally would have left the text that said that Nemo does not bar multihoming (amongst other things) but there's clearly no protocol action designed to prevent it and I'm happy with that. I'm very positive on your suggestion to document the potential caveats related to multihoming. This could happen in the problem statement or in a later usage draft, either one I guess. Pascal From nemo-admin@ietf.org Mon Mar 22 03:36:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10167 for ; Mon, 22 Mar 2004 03:36:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Kug-000248-Hq; Mon, 22 Mar 2004 03:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ktv-0001yO-Ih for nemo@optimus.ietf.org; Mon, 22 Mar 2004 03:35:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10110 for ; Mon, 22 Mar 2004 03:35:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ktt-0007Lc-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:35:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ksv-0007FG-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:34:13 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Kry-00075M-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:33:14 -0500 content-class: urn:content-classes:message Date: Mon, 22 Mar 2004 03:32:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQP49yZZrwFVTUuTJKTCzfwxUqzLgAAknyg From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > > Today Nemo does not make any assumption on whether the > > > CareOf is used to > > > index the BCE, either. But if the reverse lookup of the > > > inner source can > > > not be used, now you are making that assumption. I see the cost, > >=20 > > =3D> Yes that's the assumption for this scenario to work. > > What is the cost? >=20 > Broken ingress filtering,=20 =3D> I've showed two ways of doing ingress filtering. I don't think that was broken. I think the current solution is=20 more broken actually since it doesn't clearly state the=20 applicability of the "anycast prefix". CaO indexing (which I suspect=20 > yields a number > of problematic race conditions),=20 =3D> I don't think so. You get the same performance as MIPv6, which is your base anyway.=20 broken existing implementations... =3D> That shouldn't be a reason for a draft... >=20 > I believe the draft is properly balanced for that matter.=20 =3D> I think it's buggy. I=20 > personally > would have left the text that said that Nemo does not bar multihoming > (amongst other things) but there's clearly no protocol=20 > action designed > to prevent it and I'm happy with that. =3D> I think the draft needs to clearly state the cases where the current solution will not work. >=20 > I'm very positive on your suggestion to document the=20 > potential caveats > related to multihoming.=20 =3D> Great. So why are you against putting this in the draft? This could happen in the problem=20 > statement or in > a later usage draft, either one I guess. =3D> This would be ok if the draft didn't already include a semi solution for the problem. But since it does,=20 I think this should be addressed in the current draft. I've already said all I have on this issue, so I think it's up to the WG to decide how this should be addressed. Hesham From exim@www1.ietf.org Mon Mar 22 03:37:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10216 for ; Mon, 22 Mar 2004 03:37:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Kvy-0002E9-EQ for nemo-archive@odin.ietf.org; Mon, 22 Mar 2004 03:37:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M8bLWn008549 for nemo-archive@odin.ietf.org; Mon, 22 Mar 2004 03:37:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Kvv-0002Df-CE for nemo-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 03:37:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10209 for ; Mon, 22 Mar 2004 03:37:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Kvt-0007YB-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 03:37:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Kuy-0007TH-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 03:36:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Kuk-0007Nw-00 for nemo-web-archive@ietf.org; Mon, 22 Mar 2004 03:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Kug-000248-Hq; Mon, 22 Mar 2004 03:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ktv-0001yO-Ih for nemo@optimus.ietf.org; Mon, 22 Mar 2004 03:35:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10110 for ; Mon, 22 Mar 2004 03:35:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ktt-0007Lc-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:35:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ksv-0007FG-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:34:13 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Kry-00075M-00 for nemo@ietf.org; Mon, 22 Mar 2004 03:33:14 -0500 content-class: urn:content-classes:message Date: Mon, 22 Mar 2004 03:32:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQP49yZZrwFVTUuTJKTCzfwxUqzLgAAknyg From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > > Today Nemo does not make any assumption on whether the > > > CareOf is used to > > > index the BCE, either. But if the reverse lookup of the > > > inner source can > > > not be used, now you are making that assumption. I see the cost, > >=20 > > =3D> Yes that's the assumption for this scenario to work. > > What is the cost? >=20 > Broken ingress filtering,=20 =3D> I've showed two ways of doing ingress filtering. I don't think that was broken. I think the current solution is=20 more broken actually since it doesn't clearly state the=20 applicability of the "anycast prefix". CaO indexing (which I suspect=20 > yields a number > of problematic race conditions),=20 =3D> I don't think so. You get the same performance as MIPv6, which is your base anyway.=20 broken existing implementations... =3D> That shouldn't be a reason for a draft... >=20 > I believe the draft is properly balanced for that matter.=20 =3D> I think it's buggy. I=20 > personally > would have left the text that said that Nemo does not bar multihoming > (amongst other things) but there's clearly no protocol=20 > action designed > to prevent it and I'm happy with that. =3D> I think the draft needs to clearly state the cases where the current solution will not work. >=20 > I'm very positive on your suggestion to document the=20 > potential caveats > related to multihoming.=20 =3D> Great. So why are you against putting this in the draft? This could happen in the problem=20 > statement or in > a later usage draft, either one I guess. =3D> This would be ok if the draft didn't already include a semi solution for the problem. But since it does,=20 I think this should be addressed in the current draft. I've already said all I have on this issue, so I think it's up to the WG to decide how this should be addressed. Hesham From nemo-admin@ietf.org Wed Mar 24 06:56:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16508 for ; Wed, 24 Mar 2004 06:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66zK-0001oc-Ig; Wed, 24 Mar 2004 06:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66yb-0001eE-6p for nemo@optimus.ietf.org; Wed, 24 Mar 2004 06:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16444 for ; Wed, 24 Mar 2004 06:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66yX-0001DH-00 for nemo@ietf.org; Wed, 24 Mar 2004 06:55:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66xk-00010e-00 for nemo@ietf.org; Wed, 24 Mar 2004 06:54:24 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B66wo-0000aQ-00 for nemo@ietf.org; Wed, 24 Mar 2004 06:53:26 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 09C9D1BDD4; Wed, 24 Mar 2004 12:52:57 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id E67AC1BDD1; Wed, 24 Mar 2004 12:52:56 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 12:50:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hesham, [...] > Personally, I think it's a lot cleaner to have one prefix > per MR and somehow solve the ingress filtering problem. If i understand the scenario that you are proposing, there are more problems, not only ingress filtering. Let me see if i get this right: The scenario that you are proposing would be the following P::/26 ----|-------------- Home network | +---+ |HA | +---+ route | \ route to P:P1:: | \ P:P2:: | \ +---+ +---+ |MR1| |MR2| +---+ +---+ P:P1::| |P:P2:: ---------------------- Mobile network So, each of the MR of the NEMO has one prefix assigned and announces it in the NEMO. The HA has one prefix registered per each MR, so this means that it forwards packets addressed to P:P1:: only through MR1 and the HA forwards packets addressed to P:P2:: only through MR2 Is this the configuration that you are proposing? If this is so, this presents all the problems of multiaddressing, i guess. In order to be reachable through both MR, the hosts within the NEMO will have to configure two addresses, one with P:P1:: and another one with P:P2. This is so because if they only configure an address with P:P1:: they will be only be reachable through MR1, since the HA only has MR1 registered for this prefix. Well this multiaddressing configuration presents complex challenges, for instance how do you preserve established communications when the MR that you were using fails. Also, in case that one of the MR is down, you need a smart way to select the source address that is working on the reverse path, which imposes new mechanisms in the MNN So, in brief, if i understand correctly, this configuration poses the full multihoming problem in a configuration that didn't suffered it before. I am sure that i don't fully grasp the complete problem of detecting a duplicate prefix in the same HA that you are discussing, so i cannot make any consideration about the solution for this problem, but the proposed configuration really presents complex issues. Of course, once that multi6 develops a solution for the general case, it should also cover this case too. Regards, marcelo > This is not so difficult in the case where the 2 MRs > belong to the same home domain/link. For instance, an > ISP might not filter (in the MR's HA) on any of the > prefixes that are assigned to its domain. So basically > it forwards any packet coming from any prefix derived > from ISP_PREFIX::/26. This would solve the simple multihoming > case where 2 MRs belong to the same home admin domain. > I think this will solve the problem with the scenarios > that you mention, i.e. plane, train, bus ...etc. > > Do you think this will work? This requires hardly any > changes to the spec. We can clearly do without changing > anything, except for mentioning that 2 MRs do not share > the same prefix. I misstated that before to say 1 prefix > per MR, when what I really meant was two MRs do not share > the same prefix. > > Hesham > > > > > > Pascal > > > From exim@www1.ietf.org Wed Mar 24 06:58:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16685 for ; Wed, 24 Mar 2004 06:58:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B671T-000287-Ue for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 06:58:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OBwFCx008187 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 06:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B671T-00027y-Lh for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 06:58:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16632 for ; Wed, 24 Mar 2004 06:58:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B671P-0001u6-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 06:58:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B670N-0001dq-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 06:57:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B66zO-0001Q8-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 06:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66zK-0001oc-Ig; Wed, 24 Mar 2004 06:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66yb-0001eE-6p for nemo@optimus.ietf.org; Wed, 24 Mar 2004 06:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16444 for ; Wed, 24 Mar 2004 06:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66yX-0001DH-00 for nemo@ietf.org; Wed, 24 Mar 2004 06:55:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66xk-00010e-00 for nemo@ietf.org; Wed, 24 Mar 2004 06:54:24 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B66wo-0000aQ-00 for nemo@ietf.org; Wed, 24 Mar 2004 06:53:26 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 09C9D1BDD4; Wed, 24 Mar 2004 12:52:57 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id E67AC1BDD1; Wed, 24 Mar 2004 12:52:56 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 12:50:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hesham, [...] > Personally, I think it's a lot cleaner to have one prefix > per MR and somehow solve the ingress filtering problem. If i understand the scenario that you are proposing, there are more problems, not only ingress filtering. Let me see if i get this right: The scenario that you are proposing would be the following P::/26 ----|-------------- Home network | +---+ |HA | +---+ route | \ route to P:P1:: | \ P:P2:: | \ +---+ +---+ |MR1| |MR2| +---+ +---+ P:P1::| |P:P2:: ---------------------- Mobile network So, each of the MR of the NEMO has one prefix assigned and announces it in the NEMO. The HA has one prefix registered per each MR, so this means that it forwards packets addressed to P:P1:: only through MR1 and the HA forwards packets addressed to P:P2:: only through MR2 Is this the configuration that you are proposing? If this is so, this presents all the problems of multiaddressing, i guess. In order to be reachable through both MR, the hosts within the NEMO will have to configure two addresses, one with P:P1:: and another one with P:P2. This is so because if they only configure an address with P:P1:: they will be only be reachable through MR1, since the HA only has MR1 registered for this prefix. Well this multiaddressing configuration presents complex challenges, for instance how do you preserve established communications when the MR that you were using fails. Also, in case that one of the MR is down, you need a smart way to select the source address that is working on the reverse path, which imposes new mechanisms in the MNN So, in brief, if i understand correctly, this configuration poses the full multihoming problem in a configuration that didn't suffered it before. I am sure that i don't fully grasp the complete problem of detecting a duplicate prefix in the same HA that you are discussing, so i cannot make any consideration about the solution for this problem, but the proposed configuration really presents complex issues. Of course, once that multi6 develops a solution for the general case, it should also cover this case too. Regards, marcelo > This is not so difficult in the case where the 2 MRs > belong to the same home domain/link. For instance, an > ISP might not filter (in the MR's HA) on any of the > prefixes that are assigned to its domain. So basically > it forwards any packet coming from any prefix derived > from ISP_PREFIX::/26. This would solve the simple multihoming > case where 2 MRs belong to the same home admin domain. > I think this will solve the problem with the scenarios > that you mention, i.e. plane, train, bus ...etc. > > Do you think this will work? This requires hardly any > changes to the spec. We can clearly do without changing > anything, except for mentioning that 2 MRs do not share > the same prefix. I misstated that before to say 1 prefix > per MR, when what I really meant was two MRs do not share > the same prefix. > > Hesham > > > > > > Pascal > > > From nemo-admin@ietf.org Wed Mar 24 07:16:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17698 for ; Wed, 24 Mar 2004 07:16:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67Ig-00052T-6D; Wed, 24 Mar 2004 07:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67Hr-0004yc-Mx for nemo@optimus.ietf.org; Wed, 24 Mar 2004 07:15:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17662 for ; Wed, 24 Mar 2004 07:15:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B67Hr-00066N-00 for nemo@ietf.org; Wed, 24 Mar 2004 07:15:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B67Gr-0005t9-00 for nemo@ietf.org; Wed, 24 Mar 2004 07:14:10 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B67Fq-0005TG-00 for nemo@ietf.org; Wed, 24 Mar 2004 07:13:06 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 07:12:33 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQRlo00AxRAKwdbQNSkwWw9v+hUIQAAFJwQ From: "Soliman Hesham" To: , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Marcelo,=20 > If i understand the scenario that you are proposing, there are more > problems, not only ingress filtering. =3D> First of all, I want to be clear on what I'm proposing. I suggested two options: a. Clean up the spec by either explicitly stating when the=20 current solution fails, or,=20 b. Provide another option like the one below.=20 As I stated in an earlier response to Thierry, my proposal has its own problems, however, I don't think any of=20 those problems are nemo-specific. >=20 > Let me see if i get this right: > The scenario that you are proposing would be the following >=20 > P::/26 > ----|-------------- Home network > | > +---+ > |HA | > +---+ > route | \ route to > P:P1:: | \ P:P2:: > | \ > +---+ +---+ > |MR1| |MR2| > +---+ +---+ > P:P1::| |P:P2:: > ---------------------- Mobile network >=20 > So, each of the MR of the NEMO has one prefix assigned and=20 > announces it in > the NEMO. > The HA has one prefix registered per each MR, so this means=20 > that it forwards > packets addressed to P:P1:: only through MR1 and the HA=20 > forwards packets > addressed to P:P2:: only through MR2 > Is this the configuration that you are proposing? =3D> Correct. >=20 > If this is so, this presents all the problems of=20 > multiaddressing, i guess. =3D> Yes. > In order to be reachable through both MR, the hosts within=20 > the NEMO will > have to configure two addresses, one with P:P1:: and another=20 > one with P:P2. > This is so because if they only configure an address with=20 > P:P1:: they will > be only be reachable through MR1, since the HA only has MR1=20 > registered for > this prefix. =3D> Correct. This also brings up another issue: are=20 we considering the case where hosts want to have a stable=20 address in the DNS ? This is another interesting restriction and I'm not sure that this is currently addressed. >=20 > Well this multiaddressing configuration presents complex=20 > challenges, for > instance how do you preserve established communications when=20 > the MR that you > were using fails. =3D> I don't think this is a requirement on the basic spec.=20 I think this is useful in many cases but I could also ask the question: How do you preserve communication=20 when the HA fails ? I think this is a general problem with MIP solutions when the communication goes through the=20 HA. There is no good way of detecting such failure and when it happens, there is no way (other than providing a redundant HA) to preserve communication in a timely manner. > Also, in case that one of the MR is down, you need a smart=20 > way to select the > source address that is working on the reverse path, which imposes new > mechanisms in the MNN =3D> If redundancy is a requirement, yes. But I don't think this would solve the problem because we still need to deal with the HA. >=20 > So, in brief, if i understand correctly, this configuration=20 > poses the full > multihoming problem in a configuration that didn't suffered=20 > it before. =3D> I'm not sure what you mean by "didn't suffer it before"? These problems apply already, some apply to IPv6 in general,=20 and others to using MIPv6 through an HA, which is what this=20 spec is doing. In the configuration that Pascal proposed, redundancy is=20 achievable, but there are other problems.=20 >=20 > I am sure that i don't fully grasp the complete problem of=20 > detecting a > duplicate prefix in the same HA that you are discussing, so=20 > i cannot make > any consideration about the solution for this problem, but=20 > the proposed > configuration really presents complex issues. > Of course, once that multi6 develops a solution for the=20 > general case, it > should also cover this case too. =3D> I think that either way a generic solution for multihoming is needed to address both cases, i.e. when two DRs are advertising the same prefixes or different ones. Both scenarios are real and affect multihomed hosts and mobile networks.=20 What we're doing here is band aiding the "easier" case and the question is how we do that. But whatever solution you pick (out of the ones discussed on this thread) falls short in many multihoming cases.=20 Hesham >=20 > Regards, marcelo >=20 >=20 >=20 > > This is not so difficult in the case where the 2 MRs > > belong to the same home domain/link. For instance, an > > ISP might not filter (in the MR's HA) on any of the > > prefixes that are assigned to its domain. So basically > > it forwards any packet coming from any prefix derived > > from ISP_PREFIX::/26. This would solve the simple multihoming > > case where 2 MRs belong to the same home admin domain. > > I think this will solve the problem with the scenarios > > that you mention, i.e. plane, train, bus ...etc. > > > > Do you think this will work? This requires hardly any > > changes to the spec. We can clearly do without changing > > anything, except for mentioning that 2 MRs do not share > > the same prefix. I misstated that before to say 1 prefix > > per MR, when what I really meant was two MRs do not share > > the same prefix. > > > > Hesham > > > > > > > > > > Pascal > > > > > >=20 From exim@www1.ietf.org Wed Mar 24 07:18:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17812 for ; Wed, 24 Mar 2004 07:18:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67Ki-0005CH-CE for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 07:18:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OCI8kA019971 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 07:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67Ki-0005C2-5g for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 07:18:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17749 for ; Wed, 24 Mar 2004 07:18:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B67Kh-0006lV-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 07:18:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B67Ji-0006Wg-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 07:17:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B67Ih-0006Ff-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 07:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67Ig-00052T-6D; Wed, 24 Mar 2004 07:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67Hr-0004yc-Mx for nemo@optimus.ietf.org; Wed, 24 Mar 2004 07:15:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17662 for ; Wed, 24 Mar 2004 07:15:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B67Hr-00066N-00 for nemo@ietf.org; Wed, 24 Mar 2004 07:15:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B67Gr-0005t9-00 for nemo@ietf.org; Wed, 24 Mar 2004 07:14:10 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B67Fq-0005TG-00 for nemo@ietf.org; Wed, 24 Mar 2004 07:13:06 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 07:12:33 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQRlo00AxRAKwdbQNSkwWw9v+hUIQAAFJwQ From: "Soliman Hesham" To: , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Marcelo,=20 > If i understand the scenario that you are proposing, there are more > problems, not only ingress filtering. =3D> First of all, I want to be clear on what I'm proposing. I suggested two options: a. Clean up the spec by either explicitly stating when the=20 current solution fails, or,=20 b. Provide another option like the one below.=20 As I stated in an earlier response to Thierry, my proposal has its own problems, however, I don't think any of=20 those problems are nemo-specific. >=20 > Let me see if i get this right: > The scenario that you are proposing would be the following >=20 > P::/26 > ----|-------------- Home network > | > +---+ > |HA | > +---+ > route | \ route to > P:P1:: | \ P:P2:: > | \ > +---+ +---+ > |MR1| |MR2| > +---+ +---+ > P:P1::| |P:P2:: > ---------------------- Mobile network >=20 > So, each of the MR of the NEMO has one prefix assigned and=20 > announces it in > the NEMO. > The HA has one prefix registered per each MR, so this means=20 > that it forwards > packets addressed to P:P1:: only through MR1 and the HA=20 > forwards packets > addressed to P:P2:: only through MR2 > Is this the configuration that you are proposing? =3D> Correct. >=20 > If this is so, this presents all the problems of=20 > multiaddressing, i guess. =3D> Yes. > In order to be reachable through both MR, the hosts within=20 > the NEMO will > have to configure two addresses, one with P:P1:: and another=20 > one with P:P2. > This is so because if they only configure an address with=20 > P:P1:: they will > be only be reachable through MR1, since the HA only has MR1=20 > registered for > this prefix. =3D> Correct. This also brings up another issue: are=20 we considering the case where hosts want to have a stable=20 address in the DNS ? This is another interesting restriction and I'm not sure that this is currently addressed. >=20 > Well this multiaddressing configuration presents complex=20 > challenges, for > instance how do you preserve established communications when=20 > the MR that you > were using fails. =3D> I don't think this is a requirement on the basic spec.=20 I think this is useful in many cases but I could also ask the question: How do you preserve communication=20 when the HA fails ? I think this is a general problem with MIP solutions when the communication goes through the=20 HA. There is no good way of detecting such failure and when it happens, there is no way (other than providing a redundant HA) to preserve communication in a timely manner. > Also, in case that one of the MR is down, you need a smart=20 > way to select the > source address that is working on the reverse path, which imposes new > mechanisms in the MNN =3D> If redundancy is a requirement, yes. But I don't think this would solve the problem because we still need to deal with the HA. >=20 > So, in brief, if i understand correctly, this configuration=20 > poses the full > multihoming problem in a configuration that didn't suffered=20 > it before. =3D> I'm not sure what you mean by "didn't suffer it before"? These problems apply already, some apply to IPv6 in general,=20 and others to using MIPv6 through an HA, which is what this=20 spec is doing. In the configuration that Pascal proposed, redundancy is=20 achievable, but there are other problems.=20 >=20 > I am sure that i don't fully grasp the complete problem of=20 > detecting a > duplicate prefix in the same HA that you are discussing, so=20 > i cannot make > any consideration about the solution for this problem, but=20 > the proposed > configuration really presents complex issues. > Of course, once that multi6 develops a solution for the=20 > general case, it > should also cover this case too. =3D> I think that either way a generic solution for multihoming is needed to address both cases, i.e. when two DRs are advertising the same prefixes or different ones. Both scenarios are real and affect multihomed hosts and mobile networks.=20 What we're doing here is band aiding the "easier" case and the question is how we do that. But whatever solution you pick (out of the ones discussed on this thread) falls short in many multihoming cases.=20 Hesham >=20 > Regards, marcelo >=20 >=20 >=20 > > This is not so difficult in the case where the 2 MRs > > belong to the same home domain/link. For instance, an > > ISP might not filter (in the MR's HA) on any of the > > prefixes that are assigned to its domain. So basically > > it forwards any packet coming from any prefix derived > > from ISP_PREFIX::/26. This would solve the simple multihoming > > case where 2 MRs belong to the same home admin domain. > > I think this will solve the problem with the scenarios > > that you mention, i.e. plane, train, bus ...etc. > > > > Do you think this will work? This requires hardly any > > changes to the spec. We can clearly do without changing > > anything, except for mentioning that 2 MRs do not share > > the same prefix. I misstated that before to say 1 prefix > > per MR, when what I really meant was two MRs do not share > > the same prefix. > > > > Hesham > > > > > > > > > > Pascal > > > > > >=20 From nemo-admin@ietf.org Wed Mar 24 09:32:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24513 for ; Wed, 24 Mar 2004 09:32:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69QI-0000Tv-3w; Wed, 24 Mar 2004 09:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69Pj-0000Rf-Jz for nemo@optimus.ietf.org; Wed, 24 Mar 2004 09:31:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24444 for ; Wed, 24 Mar 2004 09:31:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69Ph-0000aF-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:31:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69Ot-0000Ju-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:30:36 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B69O2-00001O-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:29:42 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OETeJO022126; Wed, 24 Mar 2004 07:29:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2OETWUK007353; Wed, 24 Mar 2004 08:29:33 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 09ABE85C46E; Wed, 24 Mar 2004 15:29:32 +0100 (CET) Message-ID: <40619B45.4020104@motorola.com> Date: Wed, 24 Mar 2004 15:29:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000700070700080300060306" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] Re: Multi-homed MR at home (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms000700070700080300060306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think I agree with Marcelo's interpretation of multi-homing for MR (below) and with the conclusion. I also think that it is important to stress that the picture he depicted only shows MR at home and by considering MR at home there are already some problems as he mentioned. My addition is that only when we know how to solve these problems of multi-homed MRs at home can we look into what NEMO brings new. Alex marcelo bagnulo wrote: >>Personally, I think it's a lot cleaner to have one prefix >>per MR and somehow solve the ingress filtering problem. > > > If i understand the scenario that you are proposing, there are more > problems, not only ingress filtering. > > Let me see if i get this right: The scenario that you are proposing > would be the following > > P::/26 > ----|-------------- Home network > | > +---+ > |HA | > +---+ > route | \ route to > P:P1:: | \ P:P2:: > | \ > +---+ +---+ > |MR1| |MR2| > +---+ +---+ > P:P1::| |P:P2:: > ---------------------- Mobile network > > So, each of the MR of the NEMO has one prefix assigned and announces > it in the NEMO. The HA has one prefix registered per each MR, so > this means that it forwards packets addressed to P:P1:: only through > MR1 and the HA forwards packets addressed to P:P2:: only through MR2 > Is this the configuration that you are proposing? > > If this is so, this presents all the problems of multiaddressing, i > guess. In order to be reachable through both MR, the hosts within the > NEMO will have to configure two addresses, one with P:P1:: and > another one with P:P2. > > This is so because if they only configure an address with P:P1:: they > will be only be reachable through MR1, since the HA only has MR1 > registered for this prefix. > > Well this multiaddressing configuration presents complex challenges, > for instance how do you preserve established communications when the > MR that youwere using fails. Also, in case that one of the MR is > down, you need a smart way to select the source address that is > working on the reverse path, which imposes new mechanisms in the MNN > > So, in brief, if i understand correctly, this configuration poses the > full multihoming problem in a configuration that didn't suffered it > before. > > I am sure that i don't fully grasp the complete problem of detecting > a duplicate prefix in the same HA that you are discussing, so i > cannot make any consideration about the solution for this problem, > but the proposed configuration really presents complex issues. Of > course, once that multi6 develops a solution for the general case, it > should also cover this case too. > > Regards, marcelo --------------ms000700070700080300060306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNDI5MjVaMCMGCSqGSIb3DQEJBDEWBBRroIwAMwITkWHmZn8YhkxXA+ffhTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYC055Va7aJv/QoN0cNDuzFB737dnRHBydSYwtzI WU5LC/TMpmAjEaPRABJnFeV6huqOYg5DJ6TgbDICxEgmiSVvGGSHHd2kyufg8OHJDZPGH6im b57EQZd005tZ7NBgJhVUvjIoMpGzWe0DxL7luvKRqT/YMkr9l5zF1LM8yt9y4gAAAAAAAA== --------------ms000700070700080300060306-- From exim@www1.ietf.org Wed Mar 24 09:34:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24645 for ; Wed, 24 Mar 2004 09:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69SE-0000cK-Fx for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 09:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OEY2kB002372 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 09:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69SD-0000cA-Lq for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 09:34:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24617 for ; Wed, 24 Mar 2004 09:33:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69SB-0001FJ-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 09:33:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69R4-0000vY-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 09:32:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B69QJ-0000ca-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 09:32:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69QI-0000Tv-3w; Wed, 24 Mar 2004 09:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69Pj-0000Rf-Jz for nemo@optimus.ietf.org; Wed, 24 Mar 2004 09:31:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24444 for ; Wed, 24 Mar 2004 09:31:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69Ph-0000aF-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:31:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69Ot-0000Ju-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:30:36 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B69O2-00001O-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:29:42 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OETeJO022126; Wed, 24 Mar 2004 07:29:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2OETWUK007353; Wed, 24 Mar 2004 08:29:33 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 09ABE85C46E; Wed, 24 Mar 2004 15:29:32 +0100 (CET) Message-ID: <40619B45.4020104@motorola.com> Date: Wed, 24 Mar 2004 15:29:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000700070700080300060306" Subject: [nemo] Re: Multi-homed MR at home (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms000700070700080300060306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think I agree with Marcelo's interpretation of multi-homing for MR (below) and with the conclusion. I also think that it is important to stress that the picture he depicted only shows MR at home and by considering MR at home there are already some problems as he mentioned. My addition is that only when we know how to solve these problems of multi-homed MRs at home can we look into what NEMO brings new. Alex marcelo bagnulo wrote: >>Personally, I think it's a lot cleaner to have one prefix >>per MR and somehow solve the ingress filtering problem. > > > If i understand the scenario that you are proposing, there are more > problems, not only ingress filtering. > > Let me see if i get this right: The scenario that you are proposing > would be the following > > P::/26 > ----|-------------- Home network > | > +---+ > |HA | > +---+ > route | \ route to > P:P1:: | \ P:P2:: > | \ > +---+ +---+ > |MR1| |MR2| > +---+ +---+ > P:P1::| |P:P2:: > ---------------------- Mobile network > > So, each of the MR of the NEMO has one prefix assigned and announces > it in the NEMO. The HA has one prefix registered per each MR, so > this means that it forwards packets addressed to P:P1:: only through > MR1 and the HA forwards packets addressed to P:P2:: only through MR2 > Is this the configuration that you are proposing? > > If this is so, this presents all the problems of multiaddressing, i > guess. In order to be reachable through both MR, the hosts within the > NEMO will have to configure two addresses, one with P:P1:: and > another one with P:P2. > > This is so because if they only configure an address with P:P1:: they > will be only be reachable through MR1, since the HA only has MR1 > registered for this prefix. > > Well this multiaddressing configuration presents complex challenges, > for instance how do you preserve established communications when the > MR that youwere using fails. Also, in case that one of the MR is > down, you need a smart way to select the source address that is > working on the reverse path, which imposes new mechanisms in the MNN > > So, in brief, if i understand correctly, this configuration poses the > full multihoming problem in a configuration that didn't suffered it > before. > > I am sure that i don't fully grasp the complete problem of detecting > a duplicate prefix in the same HA that you are discussing, so i > cannot make any consideration about the solution for this problem, > but the proposed configuration really presents complex issues. Of > course, once that multi6 develops a solution for the general case, it > should also cover this case too. > > Regards, marcelo --------------ms000700070700080300060306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNDI5MjVaMCMGCSqGSIb3DQEJBDEWBBRroIwAMwITkWHmZn8YhkxXA+ffhTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYC055Va7aJv/QoN0cNDuzFB737dnRHBydSYwtzI WU5LC/TMpmAjEaPRABJnFeV6huqOYg5DJ6TgbDICxEgmiSVvGGSHHd2kyufg8OHJDZPGH6im b57EQZd005tZ7NBgJhVUvjIoMpGzWe0DxL7luvKRqT/YMkr9l5zF1LM8yt9y4gAAAAAAAA== --------------ms000700070700080300060306-- From nemo-admin@ietf.org Wed Mar 24 09:53:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25584 for ; Wed, 24 Mar 2004 09:53:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69ka-00032f-SA; Wed, 24 Mar 2004 09:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69jv-00031X-Dj for nemo@optimus.ietf.org; Wed, 24 Mar 2004 09:52:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25530 for ; Wed, 24 Mar 2004 09:52:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69jt-0006Lt-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:52:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69j1-00066s-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:51:24 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1B69iA-0005pd-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:50:30 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i2OEoFa0001806; Wed, 24 Mar 2004 07:50:15 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2OEkcdl010848; Wed, 24 Mar 2004 08:46:52 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 127A0855530; Wed, 24 Mar 2004 15:46:46 +0100 (CET) Message-ID: <40619F4B.8050201@motorola.com> Date: Wed, 24 Mar 2004 15:46:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: mbagnulo@ing.uc3m.es, "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080304090005010105020803" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms080304090005010105020803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > I suggested two options: > a. Clean up the spec by either explicitly stating when the > current solution fails, or, Do you know when the current solution fails? Maybe we can make it an issue and track it. I don't think that the scenario depicted by Marcelo fails in any NEMO way; it might fail in another multi-homing way, but not a NEMO way. > b. Provide another option like the one below. > > As I stated in an earlier response to Thierry, my proposal has its > own problems, however, I don't think any of those problems are > nemo-specific. Yes. > > If this is so, this presents all the problems of > > multiaddressing, i guess. > > => Yes. Yes. > => Correct. This also brings up another issue: are we considering the > case where hosts want to have a stable address in the DNS ? This is > another interesting restriction and I'm not sure that this is > currently addressed. I think that hosts that have stable addresses in the DNS are LFN's and probably MH's but in no case MR's. So I would say we don't necessarily want MR's to have a unique single address in the DNS because a router usually does not host e2e applications of the sort a human user would use (like web browsing, or like being reachable). So the issue mentioned would be a Mobile IPv6 for MH issue, or a multi6 for hosts(?) issue, no? > => I don't think this is a requirement on the basic spec. I think > this is useful in many cases but I could also ask the question: How > do you preserve communication when the HA fails ? I think this is a > general problem with MIP solutions when the communication goes > through the HA. There is no good way of detecting such failure and > when it happens, there is no way (other than providing a redundant > HA) to preserve communication in a timely manner. Right, when HA fails there is no way to preserve reachability at permanent home address and this is again, not a NEMO problem since NEMO assumes there's always an HA (from a set of HA's on the hom elink) and since NEMO reqs/goals say NEMO tries to preserve reachability at a permanent HoAddress. Providing redundant HA's, as you say, can be done in many different ways, like HMIPv6, or like HAHA, or like other micro-mobility protocols, and I think none of those is a competitor to NEMO base support, they _may_ base upon it, no? Removing the HA from the conceptual picture of NEMO is removing Mobile IPv6 altogether; but seems that the goal of multi-homing activities in NEMO is just to make sure that NEMO does not prohibit mutli-homing; I don't think that multi-homed moving networks can be used with anything else than Mobile IP, no? Do you think a logic like: "NEMO does not support multi-homing, so get rid of Mobile IPv6" is valid? Alex --------------ms080304090005010105020803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNDQ2MzVaMCMGCSqGSIb3DQEJBDEWBBTo34tUUgee8MaDXr9uHXOp9NbmBzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBrEYxeTK/64XCfNHI99kGnHde4SRKclpgFxulG m3NJm7f0ZjkuZ2EcuAmqortaWJFOZ+SD6Jz/AclKPOzxlVN/gyGwZtu1kU0Jy5gPWdkGrxcm Y+0Wj28hinbl5R5QppUYSQY6efD1wnBBKamON8g/TziVu019c6cb8+16Tjd1aQAAAAAAAA== --------------ms080304090005010105020803-- From exim@www1.ietf.org Wed Mar 24 09:55:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25693 for ; Wed, 24 Mar 2004 09:55:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69mI-0003CZ-4u for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 09:54:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OEskGW012301 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 09:54:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69mH-0003CK-VV for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 09:54:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25676 for ; Wed, 24 Mar 2004 09:54:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69mG-0006zY-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 09:54:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69lM-0006hv-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 09:53:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B69kb-0006Pf-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 09:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69ka-00032f-SA; Wed, 24 Mar 2004 09:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69jv-00031X-Dj for nemo@optimus.ietf.org; Wed, 24 Mar 2004 09:52:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25530 for ; Wed, 24 Mar 2004 09:52:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69jt-0006Lt-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:52:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69j1-00066s-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:51:24 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1B69iA-0005pd-00 for nemo@ietf.org; Wed, 24 Mar 2004 09:50:30 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i2OEoFa0001806; Wed, 24 Mar 2004 07:50:15 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2OEkcdl010848; Wed, 24 Mar 2004 08:46:52 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 127A0855530; Wed, 24 Mar 2004 15:46:46 +0100 (CET) Message-ID: <40619F4B.8050201@motorola.com> Date: Wed, 24 Mar 2004 15:46:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: mbagnulo@ing.uc3m.es, "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080304090005010105020803" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms080304090005010105020803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > I suggested two options: > a. Clean up the spec by either explicitly stating when the > current solution fails, or, Do you know when the current solution fails? Maybe we can make it an issue and track it. I don't think that the scenario depicted by Marcelo fails in any NEMO way; it might fail in another multi-homing way, but not a NEMO way. > b. Provide another option like the one below. > > As I stated in an earlier response to Thierry, my proposal has its > own problems, however, I don't think any of those problems are > nemo-specific. Yes. > > If this is so, this presents all the problems of > > multiaddressing, i guess. > > => Yes. Yes. > => Correct. This also brings up another issue: are we considering the > case where hosts want to have a stable address in the DNS ? This is > another interesting restriction and I'm not sure that this is > currently addressed. I think that hosts that have stable addresses in the DNS are LFN's and probably MH's but in no case MR's. So I would say we don't necessarily want MR's to have a unique single address in the DNS because a router usually does not host e2e applications of the sort a human user would use (like web browsing, or like being reachable). So the issue mentioned would be a Mobile IPv6 for MH issue, or a multi6 for hosts(?) issue, no? > => I don't think this is a requirement on the basic spec. I think > this is useful in many cases but I could also ask the question: How > do you preserve communication when the HA fails ? I think this is a > general problem with MIP solutions when the communication goes > through the HA. There is no good way of detecting such failure and > when it happens, there is no way (other than providing a redundant > HA) to preserve communication in a timely manner. Right, when HA fails there is no way to preserve reachability at permanent home address and this is again, not a NEMO problem since NEMO assumes there's always an HA (from a set of HA's on the hom elink) and since NEMO reqs/goals say NEMO tries to preserve reachability at a permanent HoAddress. Providing redundant HA's, as you say, can be done in many different ways, like HMIPv6, or like HAHA, or like other micro-mobility protocols, and I think none of those is a competitor to NEMO base support, they _may_ base upon it, no? Removing the HA from the conceptual picture of NEMO is removing Mobile IPv6 altogether; but seems that the goal of multi-homing activities in NEMO is just to make sure that NEMO does not prohibit mutli-homing; I don't think that multi-homed moving networks can be used with anything else than Mobile IP, no? Do you think a logic like: "NEMO does not support multi-homing, so get rid of Mobile IPv6" is valid? Alex --------------ms080304090005010105020803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNDQ2MzVaMCMGCSqGSIb3DQEJBDEWBBTo34tUUgee8MaDXr9uHXOp9NbmBzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBrEYxeTK/64XCfNHI99kGnHde4SRKclpgFxulG m3NJm7f0ZjkuZ2EcuAmqortaWJFOZ+SD6Jz/AclKPOzxlVN/gyGwZtu1kU0Jy5gPWdkGrxcm Y+0Wj28hinbl5R5QppUYSQY6efD1wnBBKamON8g/TziVu019c6cb8+16Tjd1aQAAAAAAAA== --------------ms080304090005010105020803-- From nemo-admin@ietf.org Wed Mar 24 10:57:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02675 for ; Wed, 24 Mar 2004 10:57:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6AkX-0007KE-2E; Wed, 24 Mar 2004 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ajj-0007FI-Rb for nemo@optimus.ietf.org; Wed, 24 Mar 2004 10:56:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02537 for ; Wed, 24 Mar 2004 10:56:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ajh-0005zx-00 for nemo@ietf.org; Wed, 24 Mar 2004 10:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Aim-0005tn-00 for nemo@ietf.org; Wed, 24 Mar 2004 10:55:13 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ahn-0005jo-00 for nemo@ietf.org; Wed, 24 Mar 2004 10:54:11 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E9E231BDEE; Wed, 24 Mar 2004 16:53:40 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id BED5A1BDED; Wed, 24 Mar 2004 16:53:40 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 16:51:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Well this multiaddressing configuration presents complex > > challenges, for > > instance how do you preserve established communications when > > the MR that you > > were using fails. > > => I don't think this is a requirement on the basic spec. > I think this is useful in many cases but I could also > ask the question: How do you preserve communication > when the HA fails ? I think this is a general problem > with MIP solutions when the communication goes through the > HA. There is no good way of detecting such failure and when > it happens, there is no way (other than providing a redundant > HA) to preserve communication in a timely manner. So i guess that current spec doesn't provides support for multiple HAs, is this correct? > > > Also, in case that one of the MR is down, you need a smart > > way to select the > > source address that is working on the reverse path, which imposes new > > mechanisms in the MNN > > => If redundancy is a requirement, yes. But I don't > think this would solve the problem because we still > need to deal with the HA. Well, redundancy is the main goal for multihoming, so if you don't get redundancy probably you don't need multihoming i guess. > > > > > So, in brief, if i understand correctly, this configuration > > poses the full > > multihoming problem in a configuration that didn't suffered > > it before. > > => I'm not sure what you mean by "didn't suffer it before"? I mean that the multihoming problem occurs when a site has multiple exterior connections and not when an interior subnet has multiple routers connecting to the rest of the local site. It is basically related to how far you can inject routing information related to your subnetwork. In multihoming you are assuming that you can inject routing information in your site, but you cannot inject it in your isps. If you adopt this restriction that a HA only forwards packets to one of the prefixes, you are basically partitioning the scope of the intra site routing information. In brief, when the nemo has two different home networks with different prefixes, the problem is already there, since it is just like a multihomed site with two isps However, if there is only one home network that has only one prefix, you are artificially adding a new prefix to solve this multiple MR issue, and this solution introduces all the problems related to multiaddressing to this configuration that didn't have it previously. > These problems apply already, some apply to IPv6 in general, > and others to using MIPv6 through an HA, which is what this > spec is doing. > In the configuration that Pascal proposed, redundancy is > achievable, but there are other problems. > > > > > I am sure that i don't fully grasp the complete problem of > > detecting a > > duplicate prefix in the same HA that you are discussing, so > > i cannot make > > any consideration about the solution for this problem, but > > the proposed > > configuration really presents complex issues. > > Of course, once that multi6 develops a solution for the > > general case, it > > should also cover this case too. > > => I think that either way a generic solution for multihoming > is needed to address both cases, i.e. when two DRs are advertising > the same prefixes or different ones. Both scenarios are real > and affect multihomed hosts and mobile networks. > > What we're doing here is band aiding the "easier" case > and the question is how we do that. But whatever solution > you pick (out of the ones discussed on this thread) falls > short in many multihoming cases. I guess that i fully agree with your conclusion here. My comments are: - First: wouldn't be useful to at least some of the multihomed configurations without waiting for a general multihoming solution to be deployed? At least this may be useful because the deployment of a general multihoming solution will take some time, i guess. For instance, all the cases where there is only one prefix seems to me that can be solved locally i.e. within the scope of the home network and nemo. I think that we could try to solve all this cases within nemo, and to provide local solutions for this. Perhaps not in the basic spec, though When there are several prefixes, this probably will require some support from the CN node, i.e. the general multihoming case - Second: from what i understand, all of the multihomed configurations fail in some way at this stage with the current spec, is this correct? whether this is because of the general multihoming problem or because MIP problems or nemo specific issues, i am concluding that the only configuration that works properly is the one with one MR , one prefix and one HA, is this correct? If this is so, perhaps an option would be to, as i think you are suggesting, explicitly state that only the 1 MR, 1 HA and 1 Prefix is expected to work fine in the spec. Regards, marcelo > > Hesham > > > > > Regards, marcelo > > > > > > > > > This is not so difficult in the case where the 2 MRs > > > belong to the same home domain/link. For instance, an > > > ISP might not filter (in the MR's HA) on any of the > > > prefixes that are assigned to its domain. So basically > > > it forwards any packet coming from any prefix derived > > > from ISP_PREFIX::/26. This would solve the simple multihoming > > > case where 2 MRs belong to the same home admin domain. > > > I think this will solve the problem with the scenarios > > > that you mention, i.e. plane, train, bus ...etc. > > > > > > Do you think this will work? This requires hardly any > > > changes to the spec. We can clearly do without changing > > > anything, except for mentioning that 2 MRs do not share > > > the same prefix. I misstated that before to say 1 prefix > > > per MR, when what I really meant was two MRs do not share > > > the same prefix. > > > > > > Hesham > > > > > > > > > > > > > > Pascal > > > > > > > > > > From exim@www1.ietf.org Wed Mar 24 10:59:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02770 for ; Wed, 24 Mar 2004 10:59:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Amv-0007dm-Rr for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 10:59:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OFxTK3029370 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 10:59:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Amv-0007db-3Q for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 10:59:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02737 for ; Wed, 24 Mar 2004 10:59:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ams-0006QJ-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 10:59:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Alp-0006Gu-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 10:58:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Akv-00069B-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 10:57:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6AkX-0007KE-2E; Wed, 24 Mar 2004 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ajj-0007FI-Rb for nemo@optimus.ietf.org; Wed, 24 Mar 2004 10:56:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02537 for ; Wed, 24 Mar 2004 10:56:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ajh-0005zx-00 for nemo@ietf.org; Wed, 24 Mar 2004 10:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Aim-0005tn-00 for nemo@ietf.org; Wed, 24 Mar 2004 10:55:13 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ahn-0005jo-00 for nemo@ietf.org; Wed, 24 Mar 2004 10:54:11 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E9E231BDEE; Wed, 24 Mar 2004 16:53:40 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id BED5A1BDED; Wed, 24 Mar 2004 16:53:40 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 16:51:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Well this multiaddressing configuration presents complex > > challenges, for > > instance how do you preserve established communications when > > the MR that you > > were using fails. > > => I don't think this is a requirement on the basic spec. > I think this is useful in many cases but I could also > ask the question: How do you preserve communication > when the HA fails ? I think this is a general problem > with MIP solutions when the communication goes through the > HA. There is no good way of detecting such failure and when > it happens, there is no way (other than providing a redundant > HA) to preserve communication in a timely manner. So i guess that current spec doesn't provides support for multiple HAs, is this correct? > > > Also, in case that one of the MR is down, you need a smart > > way to select the > > source address that is working on the reverse path, which imposes new > > mechanisms in the MNN > > => If redundancy is a requirement, yes. But I don't > think this would solve the problem because we still > need to deal with the HA. Well, redundancy is the main goal for multihoming, so if you don't get redundancy probably you don't need multihoming i guess. > > > > > So, in brief, if i understand correctly, this configuration > > poses the full > > multihoming problem in a configuration that didn't suffered > > it before. > > => I'm not sure what you mean by "didn't suffer it before"? I mean that the multihoming problem occurs when a site has multiple exterior connections and not when an interior subnet has multiple routers connecting to the rest of the local site. It is basically related to how far you can inject routing information related to your subnetwork. In multihoming you are assuming that you can inject routing information in your site, but you cannot inject it in your isps. If you adopt this restriction that a HA only forwards packets to one of the prefixes, you are basically partitioning the scope of the intra site routing information. In brief, when the nemo has two different home networks with different prefixes, the problem is already there, since it is just like a multihomed site with two isps However, if there is only one home network that has only one prefix, you are artificially adding a new prefix to solve this multiple MR issue, and this solution introduces all the problems related to multiaddressing to this configuration that didn't have it previously. > These problems apply already, some apply to IPv6 in general, > and others to using MIPv6 through an HA, which is what this > spec is doing. > In the configuration that Pascal proposed, redundancy is > achievable, but there are other problems. > > > > > I am sure that i don't fully grasp the complete problem of > > detecting a > > duplicate prefix in the same HA that you are discussing, so > > i cannot make > > any consideration about the solution for this problem, but > > the proposed > > configuration really presents complex issues. > > Of course, once that multi6 develops a solution for the > > general case, it > > should also cover this case too. > > => I think that either way a generic solution for multihoming > is needed to address both cases, i.e. when two DRs are advertising > the same prefixes or different ones. Both scenarios are real > and affect multihomed hosts and mobile networks. > > What we're doing here is band aiding the "easier" case > and the question is how we do that. But whatever solution > you pick (out of the ones discussed on this thread) falls > short in many multihoming cases. I guess that i fully agree with your conclusion here. My comments are: - First: wouldn't be useful to at least some of the multihomed configurations without waiting for a general multihoming solution to be deployed? At least this may be useful because the deployment of a general multihoming solution will take some time, i guess. For instance, all the cases where there is only one prefix seems to me that can be solved locally i.e. within the scope of the home network and nemo. I think that we could try to solve all this cases within nemo, and to provide local solutions for this. Perhaps not in the basic spec, though When there are several prefixes, this probably will require some support from the CN node, i.e. the general multihoming case - Second: from what i understand, all of the multihomed configurations fail in some way at this stage with the current spec, is this correct? whether this is because of the general multihoming problem or because MIP problems or nemo specific issues, i am concluding that the only configuration that works properly is the one with one MR , one prefix and one HA, is this correct? If this is so, perhaps an option would be to, as i think you are suggesting, explicitly state that only the 1 MR, 1 HA and 1 Prefix is expected to work fine in the spec. Regards, marcelo > > Hesham > > > > > Regards, marcelo > > > > > > > > > This is not so difficult in the case where the 2 MRs > > > belong to the same home domain/link. For instance, an > > > ISP might not filter (in the MR's HA) on any of the > > > prefixes that are assigned to its domain. So basically > > > it forwards any packet coming from any prefix derived > > > from ISP_PREFIX::/26. This would solve the simple multihoming > > > case where 2 MRs belong to the same home admin domain. > > > I think this will solve the problem with the scenarios > > > that you mention, i.e. plane, train, bus ...etc. > > > > > > Do you think this will work? This requires hardly any > > > changes to the spec. We can clearly do without changing > > > anything, except for mentioning that 2 MRs do not share > > > the same prefix. I misstated that before to say 1 prefix > > > per MR, when what I really meant was two MRs do not share > > > the same prefix. > > > > > > Hesham > > > > > > > > > > > > > > Pascal > > > > > > > > > > From nemo-admin@ietf.org Wed Mar 24 11:17:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03874 for ; Wed, 24 Mar 2004 11:17:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6B3s-0001K8-Vj; Wed, 24 Mar 2004 11:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6B3E-0001J4-BI for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:16:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03813 for ; Wed, 24 Mar 2004 11:16:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6B3D-00007T-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:16:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6B2l-00003v-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:15:52 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6B1L-0007kO-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:14:23 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 77AB51BEA6; Wed, 24 Mar 2004 17:13:53 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 5FF3C1BDEE; Wed, 24 Mar 2004 17:13:53 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Date: Wed, 24 Mar 2004 17:11:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40619B45.4020104@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] RE: Multi-homed MR at home (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Alex > I think I agree with Marcelo's interpretation of multi-homing for MR > (below) and with the conclusion. I also think that it is important to > stress that the picture he depicted only shows MR at home and by Actually, the links between the HA and the MRs were supposed to be the tunnels, so i was not considering that the nemo is at home. The problems that i was describing exist when the nemo is away form home, i am not sure that they also occur when the nemo is at home, i guess this will depend on the configuration of the home netwrok. I mean , if the nemo is at home, it doens't use the HA to communicate, right? Sorry for my poor drawing, that may have generated the confusion Regards, marcelo > considering MR at home there are already some problems as he > mentioned. My addition is that only when we know how to solve these > problems of multi-homed MRs at home can we look into what NEMO brings new. > > Alex > > marcelo bagnulo wrote: > >>Personally, I think it's a lot cleaner to have one prefix > >>per MR and somehow solve the ingress filtering problem. > > > > > > If i understand the scenario that you are proposing, there are more > > problems, not only ingress filtering. > > > > Let me see if i get this right: The scenario that you are proposing > > would be the following > > > > P::/26 > > ----|-------------- Home network > > | > > +---+ > > |HA | > > +---+ > > route | \ route to > > P:P1:: | \ P:P2:: > > | \ > > +---+ +---+ > > |MR1| |MR2| > > +---+ +---+ > > P:P1::| |P:P2:: > > ---------------------- Mobile network > > > > So, each of the MR of the NEMO has one prefix assigned and announces > > it in the NEMO. The HA has one prefix registered per each MR, so > > this means that it forwards packets addressed to P:P1:: only through > > MR1 and the HA forwards packets addressed to P:P2:: only through MR2 > > Is this the configuration that you are proposing? > > > > If this is so, this presents all the problems of multiaddressing, i > > guess. In order to be reachable through both MR, the hosts within the > > NEMO will have to configure two addresses, one with P:P1:: and > > another one with P:P2. > > > > This is so because if they only configure an address with P:P1:: they > > will be only be reachable through MR1, since the HA only has MR1 > > registered for this prefix. > > > > Well this multiaddressing configuration presents complex challenges, > > for instance how do you preserve established communications when the > > MR that youwere using fails. Also, in case that one of the MR is > > down, you need a smart way to select the source address that is > > working on the reverse path, which imposes new mechanisms in the MNN > > > > So, in brief, if i understand correctly, this configuration poses the > > full multihoming problem in a configuration that didn't suffered it > > before. > > > > I am sure that i don't fully grasp the complete problem of detecting > > a duplicate prefix in the same HA that you are discussing, so i > > cannot make any consideration about the solution for this problem, > > but the proposed configuration really presents complex issues. Of > > course, once that multi6 develops a solution for the general case, it > > should also cover this case too. > > > > Regards, marcelo > > From exim@www1.ietf.org Wed Mar 24 11:18:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03980 for ; Wed, 24 Mar 2004 11:18:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6B5E-0001U9-Cv for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:18:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGIO0r005707 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:18:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6B5D-0001Tu-Qc for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:18:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03939 for ; Wed, 24 Mar 2004 11:18:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6B5D-0000H7-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:18:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6B4M-0000Dk-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:17:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6B3v-0000A7-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6B3s-0001K8-Vj; Wed, 24 Mar 2004 11:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6B3E-0001J4-BI for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:16:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03813 for ; Wed, 24 Mar 2004 11:16:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6B3D-00007T-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:16:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6B2l-00003v-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:15:52 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6B1L-0007kO-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:14:23 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 77AB51BEA6; Wed, 24 Mar 2004 17:13:53 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 5FF3C1BDEE; Wed, 24 Mar 2004 17:13:53 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Date: Wed, 24 Mar 2004 17:11:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40619B45.4020104@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [nemo] RE: Multi-homed MR at home (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alex > I think I agree with Marcelo's interpretation of multi-homing for MR > (below) and with the conclusion. I also think that it is important to > stress that the picture he depicted only shows MR at home and by Actually, the links between the HA and the MRs were supposed to be the tunnels, so i was not considering that the nemo is at home. The problems that i was describing exist when the nemo is away form home, i am not sure that they also occur when the nemo is at home, i guess this will depend on the configuration of the home netwrok. I mean , if the nemo is at home, it doens't use the HA to communicate, right? Sorry for my poor drawing, that may have generated the confusion Regards, marcelo > considering MR at home there are already some problems as he > mentioned. My addition is that only when we know how to solve these > problems of multi-homed MRs at home can we look into what NEMO brings new. > > Alex > > marcelo bagnulo wrote: > >>Personally, I think it's a lot cleaner to have one prefix > >>per MR and somehow solve the ingress filtering problem. > > > > > > If i understand the scenario that you are proposing, there are more > > problems, not only ingress filtering. > > > > Let me see if i get this right: The scenario that you are proposing > > would be the following > > > > P::/26 > > ----|-------------- Home network > > | > > +---+ > > |HA | > > +---+ > > route | \ route to > > P:P1:: | \ P:P2:: > > | \ > > +---+ +---+ > > |MR1| |MR2| > > +---+ +---+ > > P:P1::| |P:P2:: > > ---------------------- Mobile network > > > > So, each of the MR of the NEMO has one prefix assigned and announces > > it in the NEMO. The HA has one prefix registered per each MR, so > > this means that it forwards packets addressed to P:P1:: only through > > MR1 and the HA forwards packets addressed to P:P2:: only through MR2 > > Is this the configuration that you are proposing? > > > > If this is so, this presents all the problems of multiaddressing, i > > guess. In order to be reachable through both MR, the hosts within the > > NEMO will have to configure two addresses, one with P:P1:: and > > another one with P:P2. > > > > This is so because if they only configure an address with P:P1:: they > > will be only be reachable through MR1, since the HA only has MR1 > > registered for this prefix. > > > > Well this multiaddressing configuration presents complex challenges, > > for instance how do you preserve established communications when the > > MR that youwere using fails. Also, in case that one of the MR is > > down, you need a smart way to select the source address that is > > working on the reverse path, which imposes new mechanisms in the MNN > > > > So, in brief, if i understand correctly, this configuration poses the > > full multihoming problem in a configuration that didn't suffered it > > before. > > > > I am sure that i don't fully grasp the complete problem of detecting > > a duplicate prefix in the same HA that you are discussing, so i > > cannot make any consideration about the solution for this problem, > > but the proposed configuration really presents complex issues. Of > > course, once that multi6 develops a solution for the general case, it > > should also cover this case too. > > > > Regards, marcelo > > From nemo-admin@ietf.org Wed Mar 24 11:25:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04309 for ; Wed, 24 Mar 2004 11:25:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BBf-00029t-25; Wed, 24 Mar 2004 11:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BB0-00025c-GU for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:24:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04285 for ; Wed, 24 Mar 2004 11:24:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BAz-0000fS-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:24:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BA5-0000cr-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:23:26 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1B6B9P-0000ZH-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:22:43 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i2OGJ62F026228; Wed, 24 Mar 2004 09:19:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2OGLNVP013324; Wed, 24 Mar 2004 10:21:39 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E317585C46E; Wed, 24 Mar 2004 17:22:13 +0100 (CET) Message-ID: <4061B5B1.6010604@motorola.com> Date: Wed, 24 Mar 2004 17:22:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070901030501010402020205" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms070901030501010402020205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > i am concluding that the only configuration that works properly is > the one with one MR , one prefix and one HA, is this correct? This is not correct. That 1-1-1 configuration is not the _only_ configuration that works properly with the NEMO base protocol. With NEMO base protocol it is also possible to have 1 MR that has two home addresses on the ingress interface and two different moving network prefixes towards a unique ingress interface. It is also possible to have two home addresses on two different egress interfaces and two MNP's on a unique ingress interface. It is also possible to have two home addresses on two different egress interfaces and two MNP's on two different ingress interfaces. Alex --------------ms070901030501010402020205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNjIyMDlaMCMGCSqGSIb3DQEJBDEWBBSFKNxdwU6wLBx+giY9RlBPbKfRRjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCw97gF3X/2xnsAh39/ooBOisu/32FVx45ayHnE eFZfOnflzlO/mHGGB7wareWMQeeNxnCuDzw1tEJzquoeUCGaNSodq82e39i3/UDL1Us3QPyY PFP/9pDqTQk9HDvidfIvB1bp2NhBfyF26dGUM70kl6JprQQYX1Y+TdEUmQXIMwAAAAAAAA== --------------ms070901030501010402020205-- From exim@www1.ietf.org Wed Mar 24 11:26:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04423 for ; Wed, 24 Mar 2004 11:26:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BD1-0002W0-4x for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:26:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGQQbE009660 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BD0-0002VV-52 for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:26:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04417 for ; Wed, 24 Mar 2004 11:26:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BCw-0000m8-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:26:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BC4-0000jZ-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:25:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6BBj-0000gI-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:25:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BBf-00029t-25; Wed, 24 Mar 2004 11:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BB0-00025c-GU for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:24:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04285 for ; Wed, 24 Mar 2004 11:24:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BAz-0000fS-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:24:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BA5-0000cr-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:23:26 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1B6B9P-0000ZH-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:22:43 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i2OGJ62F026228; Wed, 24 Mar 2004 09:19:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2OGLNVP013324; Wed, 24 Mar 2004 10:21:39 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E317585C46E; Wed, 24 Mar 2004 17:22:13 +0100 (CET) Message-ID: <4061B5B1.6010604@motorola.com> Date: Wed, 24 Mar 2004 17:22:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070901030501010402020205" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070901030501010402020205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > i am concluding that the only configuration that works properly is > the one with one MR , one prefix and one HA, is this correct? This is not correct. That 1-1-1 configuration is not the _only_ configuration that works properly with the NEMO base protocol. With NEMO base protocol it is also possible to have 1 MR that has two home addresses on the ingress interface and two different moving network prefixes towards a unique ingress interface. It is also possible to have two home addresses on two different egress interfaces and two MNP's on a unique ingress interface. It is also possible to have two home addresses on two different egress interfaces and two MNP's on two different ingress interfaces. Alex --------------ms070901030501010402020205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNjIyMDlaMCMGCSqGSIb3DQEJBDEWBBSFKNxdwU6wLBx+giY9RlBPbKfRRjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCw97gF3X/2xnsAh39/ooBOisu/32FVx45ayHnE eFZfOnflzlO/mHGGB7wareWMQeeNxnCuDzw1tEJzquoeUCGaNSodq82e39i3/UDL1Us3QPyY PFP/9pDqTQk9HDvidfIvB1bp2NhBfyF26dGUM70kl6JprQQYX1Y+TdEUmQXIMwAAAAAAAA== --------------ms070901030501010402020205-- From nemo-admin@ietf.org Wed Mar 24 11:28:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04556 for ; Wed, 24 Mar 2004 11:28:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BEY-0002g7-3y; Wed, 24 Mar 2004 11:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BDs-0002e9-OP for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:27:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04474 for ; Wed, 24 Mar 2004 11:27:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BDr-0000pX-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:27:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BD0-0000me-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:26:27 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6BCR-0000iX-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:25:51 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 11:25:15 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQRuC/PytNkQMKJRVmlwiRpgihvfgAAFwnA From: "Soliman Hesham" To: , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> I don't think this is a requirement on the basic spec. > > I think this is useful in many cases but I could also > > ask the question: How do you preserve communication > > when the HA fails ? I think this is a general problem > > with MIP solutions when the communication goes through the > > HA. There is no good way of detecting such failure and when > > it happens, there is no way (other than providing a redundant > > HA) to preserve communication in a timely manner. >=20 > So i guess that current spec doesn't provides support for=20 > multiple HAs, is > this correct? =3D> Not for multiple HAs per MR, for the same prefix. If you can decrypt this sentence I'd be grateful ;) >=20 > Well, redundancy is the main goal for multihoming, so if you=20 > don't get > redundancy probably you don't need multihoming i guess. =3D> No, you're spending too much time in multi6 ;) Redundancy is one important aim of multihoming. Redundancy is _the_ aim of multihoming for fixed sites. But multihoming is also a fact for mobile=20 nodes/networks because of the availability of different access technologies that nodes can connect to.=20 The variety of these links offer several different=20 services that nodes should utilise. It's quite a different scenario from enterprise multihoming. > > > So, in brief, if i understand correctly, this configuration > > > poses the full > > > multihoming problem in a configuration that didn't suffered > > > it before. > > > > =3D> I'm not sure what you mean by "didn't suffer it before"? >=20 > I mean that the multihoming problem occurs when a site has=20 > multiple exterior > connections and not when an interior subnet has multiple=20 > routers connecting > to the rest of the local site. =3D> True today. However, at the same time, IPv6 specs assume that where multiple DRs on the same link exist,=20 the MN can choose either DR without associating the=20 prefix advertised by that router with its source address. This is probably because of today's scenarios that you describe. But in scenarios where the DRs are not=20 connected to the same site, this assumption does not=20 hold. This is something that could happen with nemo. In a sense nemo could look like a broken network if you follow today's specs.=20 But of course the problem is not specific to nemo,=20 we've just seen it because of nemo provides the=20 only realistic scenarios that we can use today.=20 > It is basically related to how far you can inject routing information > related to your subnetwork. In multihoming you are assuming=20 > that you can > inject routing information in your site, but you cannot=20 > inject it in your > isps. If you adopt this restriction that a HA only forwards=20 > packets to one > of the prefixes, you are basically partitioning the scope of=20 > the intra site > routing information. =3D> I understand wht you're saying, but the problem is that one of the MRs could move away and become separated from the other MR/rest of the network. This is something you don't see happening today (unless someone walks=20 off with a router on a trolley ;) ). If this happens, you can't keep sending traffic addressed to the same prefix to both MRs because you don't know which hosts are connected to which MRs.=20 For instance, if I have two MRs, a phone and a PDA that I normally carry with me and there are a couple of other MNNs connected to them. If I leave my PDA at home one day with another device and take my phone and laptop with me to work, the HA can't simply forward my laptop traffic to the PDA because it's not connected to it!=20 > In brief, when the nemo has two different home networks with=20 > different > prefixes, the problem is already there, since it is just=20 > like a multihomed > site with two isps > However, if there is only one home network that has only one=20 > prefix, you are > artificially adding a new prefix to solve this multiple MR=20 > issue, and this > solution introduces all the problems related to=20 > multiaddressing to this > configuration that didn't have it previously. =3D> There is no "previous" configuration. This is all new. There is no established way of assigning the same prefix to multiple MRs and managing to solve this for cases where the network is divided. Mobility is=20 the key difference between our multihoming scenarios and multi6 thinking of multihoming. If you assign the same prefix to all MRs, what do you do when one=20 of them goes away with half the network? > I guess that i fully agree with your conclusion here. > My comments are: >=20 > - First: wouldn't be useful to at least some of the multihomed > configurations without waiting for a general multihoming=20 > solution to be > deployed?=20 =3D> Yes. =20 > When there are several prefixes, this probably will require=20 > some support > from the CN node, i.e. the general multihoming case =3D> CN node? I don't follow that.=20 I'm not sure if you read the very long thread with Pascal. This discussion started by considering cases where the MRs are relatively fixed in relation to each other. I said that we need to either: a. Clarify the spec to explicitly describe that the=20 "one prefix" solution is designed for those cases and if the network is divided then tough luck, or,=20 b. Have one prefix per MR and the problems that will come with that are not nemo specific anyway so eventually will be solved.=20 Obviously b) solves the same problem too. Neither a) nor b) solve all cases today. Both a) and b) solve the problem in question. I hope this is clearer. > - Second: from what i understand, all of the multihomed=20 > configurations fail > in some way at this stage with the current spec, is this=20 > correct? whether > this is because of the general multihoming problem or=20 > because MIP problems > or nemo specific issues, i am concluding that the only=20 > configuration that > works properly is the one with one MR , one prefix and one=20 > HA, is this > correct? =3D> No. It works for only one case: The MRs will never be separated, they always stay on the same link (e.g. airplane). > If this is so, perhaps an option would be to, as i think you=20 > are suggesting, > explicitly state that only the 1 MR, 1 HA and 1 Prefix is=20 > expected to work > fine in the spec. =3D> Sorry, I'm not suggesting that :( Please see=20 above. Both a) and b) address the config in question. Either a) or b) are fine with me... Hesham From exim@www1.ietf.org Wed Mar 24 11:30:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04662 for ; Wed, 24 Mar 2004 11:30:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BG3-0002on-8V for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGTZrc010829 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:29:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BG3-0002oa-1a for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:29:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04641 for ; Wed, 24 Mar 2004 11:29:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BG2-00011a-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:29:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BF8-0000xI-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:28:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6BEY-0000sY-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BEY-0002g7-3y; Wed, 24 Mar 2004 11:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BDs-0002e9-OP for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:27:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04474 for ; Wed, 24 Mar 2004 11:27:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BDr-0000pX-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:27:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BD0-0000me-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:26:27 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6BCR-0000iX-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:25:51 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 11:25:15 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQRuC/PytNkQMKJRVmlwiRpgihvfgAAFwnA From: "Soliman Hesham" To: , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> I don't think this is a requirement on the basic spec. > > I think this is useful in many cases but I could also > > ask the question: How do you preserve communication > > when the HA fails ? I think this is a general problem > > with MIP solutions when the communication goes through the > > HA. There is no good way of detecting such failure and when > > it happens, there is no way (other than providing a redundant > > HA) to preserve communication in a timely manner. >=20 > So i guess that current spec doesn't provides support for=20 > multiple HAs, is > this correct? =3D> Not for multiple HAs per MR, for the same prefix. If you can decrypt this sentence I'd be grateful ;) >=20 > Well, redundancy is the main goal for multihoming, so if you=20 > don't get > redundancy probably you don't need multihoming i guess. =3D> No, you're spending too much time in multi6 ;) Redundancy is one important aim of multihoming. Redundancy is _the_ aim of multihoming for fixed sites. But multihoming is also a fact for mobile=20 nodes/networks because of the availability of different access technologies that nodes can connect to.=20 The variety of these links offer several different=20 services that nodes should utilise. It's quite a different scenario from enterprise multihoming. > > > So, in brief, if i understand correctly, this configuration > > > poses the full > > > multihoming problem in a configuration that didn't suffered > > > it before. > > > > =3D> I'm not sure what you mean by "didn't suffer it before"? >=20 > I mean that the multihoming problem occurs when a site has=20 > multiple exterior > connections and not when an interior subnet has multiple=20 > routers connecting > to the rest of the local site. =3D> True today. However, at the same time, IPv6 specs assume that where multiple DRs on the same link exist,=20 the MN can choose either DR without associating the=20 prefix advertised by that router with its source address. This is probably because of today's scenarios that you describe. But in scenarios where the DRs are not=20 connected to the same site, this assumption does not=20 hold. This is something that could happen with nemo. In a sense nemo could look like a broken network if you follow today's specs.=20 But of course the problem is not specific to nemo,=20 we've just seen it because of nemo provides the=20 only realistic scenarios that we can use today.=20 > It is basically related to how far you can inject routing information > related to your subnetwork. In multihoming you are assuming=20 > that you can > inject routing information in your site, but you cannot=20 > inject it in your > isps. If you adopt this restriction that a HA only forwards=20 > packets to one > of the prefixes, you are basically partitioning the scope of=20 > the intra site > routing information. =3D> I understand wht you're saying, but the problem is that one of the MRs could move away and become separated from the other MR/rest of the network. This is something you don't see happening today (unless someone walks=20 off with a router on a trolley ;) ). If this happens, you can't keep sending traffic addressed to the same prefix to both MRs because you don't know which hosts are connected to which MRs.=20 For instance, if I have two MRs, a phone and a PDA that I normally carry with me and there are a couple of other MNNs connected to them. If I leave my PDA at home one day with another device and take my phone and laptop with me to work, the HA can't simply forward my laptop traffic to the PDA because it's not connected to it!=20 > In brief, when the nemo has two different home networks with=20 > different > prefixes, the problem is already there, since it is just=20 > like a multihomed > site with two isps > However, if there is only one home network that has only one=20 > prefix, you are > artificially adding a new prefix to solve this multiple MR=20 > issue, and this > solution introduces all the problems related to=20 > multiaddressing to this > configuration that didn't have it previously. =3D> There is no "previous" configuration. This is all new. There is no established way of assigning the same prefix to multiple MRs and managing to solve this for cases where the network is divided. Mobility is=20 the key difference between our multihoming scenarios and multi6 thinking of multihoming. If you assign the same prefix to all MRs, what do you do when one=20 of them goes away with half the network? > I guess that i fully agree with your conclusion here. > My comments are: >=20 > - First: wouldn't be useful to at least some of the multihomed > configurations without waiting for a general multihoming=20 > solution to be > deployed?=20 =3D> Yes. =20 > When there are several prefixes, this probably will require=20 > some support > from the CN node, i.e. the general multihoming case =3D> CN node? I don't follow that.=20 I'm not sure if you read the very long thread with Pascal. This discussion started by considering cases where the MRs are relatively fixed in relation to each other. I said that we need to either: a. Clarify the spec to explicitly describe that the=20 "one prefix" solution is designed for those cases and if the network is divided then tough luck, or,=20 b. Have one prefix per MR and the problems that will come with that are not nemo specific anyway so eventually will be solved.=20 Obviously b) solves the same problem too. Neither a) nor b) solve all cases today. Both a) and b) solve the problem in question. I hope this is clearer. > - Second: from what i understand, all of the multihomed=20 > configurations fail > in some way at this stage with the current spec, is this=20 > correct? whether > this is because of the general multihoming problem or=20 > because MIP problems > or nemo specific issues, i am concluding that the only=20 > configuration that > works properly is the one with one MR , one prefix and one=20 > HA, is this > correct? =3D> No. It works for only one case: The MRs will never be separated, they always stay on the same link (e.g. airplane). > If this is so, perhaps an option would be to, as i think you=20 > are suggesting, > explicitly state that only the 1 MR, 1 HA and 1 Prefix is=20 > expected to work > fine in the spec. =3D> Sorry, I'm not suggesting that :( Please see=20 above. Both a) and b) address the config in question. Either a) or b) are fine with me... Hesham From nemo-admin@ietf.org Wed Mar 24 11:30:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04725 for ; Wed, 24 Mar 2004 11:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BGW-0002qE-58; Wed, 24 Mar 2004 11:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BFr-0002o9-I6 for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:29:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04623 for ; Wed, 24 Mar 2004 11:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BFq-000106-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BEu-0000v9-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:28:25 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6BDt-0000pf-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:27:21 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OGRNJO014594; Wed, 24 Mar 2004 09:27:23 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2OGRFUK001832; Wed, 24 Mar 2004 10:27:15 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C35CF85C46E; Wed, 24 Mar 2004 17:27:14 +0100 (CET) Message-ID: <4061B6DF.30202@motorola.com> Date: Wed, 24 Mar 2004 17:27:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050909000903020801040003" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] Re: Multi-homed MR at home (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms050909000903020801040003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > Actually, the links between the HA and the MRs were supposed to be > the tunnels, so i was not considering that the nemo is at home. I see, sorry for the confusion! > I mean , if the nemo is at home, it doens't use the HA to > communicate, right? Sidenote, depends on who you're asking; in my setting it is true; in other settings the HA is colocated with the BR (the one connecting the home link to the Internet) so MR will go through HA even if at home but, of course, not through tunnels. Alex --------------ms050909000903020801040003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNjI3MTFaMCMGCSqGSIb3DQEJBDEWBBShWwLXKO6JxnG7ga7jXYo7fGC2jzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAnlPzIlyd94A6l6HBWoDIprtMBWosnoVPZjYMn ulKdW94nnj6MZO4NWr8Bv9ZlzUhayy/wA/F78CmcrSiYGMe0ojkDF1K47FmNs/F3HdoEaOKj BUiHu8BEaE6KLMLH/GrJOWk4usWlB563SA1RyvPUMBPhYs8ThCGsKLSKFdEHsQAAAAAAAA== --------------ms050909000903020801040003-- From exim@www1.ietf.org Wed Mar 24 11:31:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04775 for ; Wed, 24 Mar 2004 11:31:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BHv-000336-40 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:31:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGVVd7011714 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:31:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BHu-00032p-SC for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04769 for ; Wed, 24 Mar 2004 11:31:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BHu-0001AM-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:31:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BGy-00016q-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:30:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6BGV-00012S-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BGW-0002qE-58; Wed, 24 Mar 2004 11:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BFr-0002o9-I6 for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:29:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04623 for ; Wed, 24 Mar 2004 11:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BFq-000106-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BEu-0000v9-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:28:25 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6BDt-0000pf-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:27:21 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OGRNJO014594; Wed, 24 Mar 2004 09:27:23 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2OGRFUK001832; Wed, 24 Mar 2004 10:27:15 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C35CF85C46E; Wed, 24 Mar 2004 17:27:14 +0100 (CET) Message-ID: <4061B6DF.30202@motorola.com> Date: Wed, 24 Mar 2004 17:27:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050909000903020801040003" Subject: [nemo] Re: Multi-homed MR at home (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms050909000903020801040003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > Actually, the links between the HA and the MRs were supposed to be > the tunnels, so i was not considering that the nemo is at home. I see, sorry for the confusion! > I mean , if the nemo is at home, it doens't use the HA to > communicate, right? Sidenote, depends on who you're asking; in my setting it is true; in other settings the HA is colocated with the BR (the one connecting the home link to the Internet) so MR will go through HA even if at home but, of course, not through tunnels. Alex --------------ms050909000903020801040003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNjI3MTFaMCMGCSqGSIb3DQEJBDEWBBShWwLXKO6JxnG7ga7jXYo7fGC2jzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAnlPzIlyd94A6l6HBWoDIprtMBWosnoVPZjYMn ulKdW94nnj6MZO4NWr8Bv9ZlzUhayy/wA/F78CmcrSiYGMe0ojkDF1K47FmNs/F3HdoEaOKj BUiHu8BEaE6KLMLH/GrJOWk4usWlB563SA1RyvPUMBPhYs8ThCGsKLSKFdEHsQAAAAAAAA== --------------ms050909000903020801040003-- From nemo-admin@ietf.org Wed Mar 24 11:33:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04887 for ; Wed, 24 Mar 2004 11:33:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BJN-0003IA-Bp; Wed, 24 Mar 2004 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BIZ-00036J-TM for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:32:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04793 for ; Wed, 24 Mar 2004 11:32:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BIY-0001DQ-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:32:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BHf-00018G-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:31:16 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6BGe-00013T-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:30:12 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OGUEJO018113; Wed, 24 Mar 2004 09:30:14 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2OGU7UK006778; Wed, 24 Mar 2004 10:30:07 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9B33885C46E; Wed, 24 Mar 2004 17:30:06 +0100 (CET) Message-ID: <4061B789.8010906@motorola.com> Date: Wed, 24 Mar 2004 17:30:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070602080906010204000007" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms070602080906010204000007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > If this is so, this presents all the problems of multiaddressing, i > guess. In order to be reachable through both MR, the hosts within the > NEMO will have to configure two addresses, one with P:P1:: and > another one with P:P2. This is so because if they only configure an > address with P:P1:: they will be only be reachable through MR1, since > the HA only has MR1 registered for this prefix. This is, as you say, a problem of having a host to confnigure two addresses; it is not a NEMO problem. Alex --------------ms070602080906010204000007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNjMwMDFaMCMGCSqGSIb3DQEJBDEWBBQm0sAOs14r0pSVz2qb4vWNBlThcTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDQl+vodxg5QmYLBS4Iq+0GhkwOHRCowuBLDvXT x6zQZw3OsRLVl/HFgGi84SHgksn3EiGBW6MhRmKxtrs5CQ0/eEW8XVbdSGHp/aLSF5b2W3XW hJpymhpasvjHbFa+q/r7ElzPTs5r0HOTN5fdrC86BwFdpWsIy/W4HA1MZ8g58AAAAAAAAA== --------------ms070602080906010204000007-- From exim@www1.ietf.org Wed Mar 24 11:35:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05030 for ; Wed, 24 Mar 2004 11:35:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BKu-0003YG-Oi for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:34:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGYaPt013646 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:34:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BKu-0003Y1-Ip for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:34:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05006 for ; Wed, 24 Mar 2004 11:34:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BKt-0001V0-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:34:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BK8-0001Q9-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:33:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6BJN-0001Jp-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BJN-0003IA-Bp; Wed, 24 Mar 2004 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BIZ-00036J-TM for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:32:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04793 for ; Wed, 24 Mar 2004 11:32:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BIY-0001DQ-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:32:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BHf-00018G-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:31:16 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6BGe-00013T-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:30:12 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OGUEJO018113; Wed, 24 Mar 2004 09:30:14 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2OGU7UK006778; Wed, 24 Mar 2004 10:30:07 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9B33885C46E; Wed, 24 Mar 2004 17:30:06 +0100 (CET) Message-ID: <4061B789.8010906@motorola.com> Date: Wed, 24 Mar 2004 17:30:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070602080906010204000007" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070602080906010204000007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > If this is so, this presents all the problems of multiaddressing, i > guess. In order to be reachable through both MR, the hosts within the > NEMO will have to configure two addresses, one with P:P1:: and > another one with P:P2. This is so because if they only configure an > address with P:P1:: they will be only be reachable through MR1, since > the HA only has MR1 registered for this prefix. This is, as you say, a problem of having a host to confnigure two addresses; it is not a NEMO problem. Alex --------------ms070602080906010204000007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNjMwMDFaMCMGCSqGSIb3DQEJBDEWBBQm0sAOs14r0pSVz2qb4vWNBlThcTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDQl+vodxg5QmYLBS4Iq+0GhkwOHRCowuBLDvXT x6zQZw3OsRLVl/HFgGi84SHgksn3EiGBW6MhRmKxtrs5CQ0/eEW8XVbdSGHp/aLSF5b2W3XW hJpymhpasvjHbFa+q/r7ElzPTs5r0HOTN5fdrC86BwFdpWsIy/W4HA1MZ8g58AAAAAAAAA== --------------ms070602080906010204000007-- From nemo-admin@ietf.org Wed Mar 24 11:39:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05295 for ; Wed, 24 Mar 2004 11:39:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BPA-0004Kv-Ur; Wed, 24 Mar 2004 11:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BOV-0004Bo-21 for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05243 for ; Wed, 24 Mar 2004 11:38:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BOT-0001kI-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:38:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BNg-0001ho-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:37:29 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6BNG-0001eO-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:37:02 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OGb3JO026163; Wed, 24 Mar 2004 09:37:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2OGauUK019044; Wed, 24 Mar 2004 10:36:56 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3388785C46E; Wed, 24 Mar 2004 17:36:55 +0100 (CET) Message-ID: <4061B923.7050907@motorola.com> Date: Wed, 24 Mar 2004 17:36:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030702060902000604090700" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms030702060902000604090700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Marcelo, I think that a dynamic routing protocol on MR and HA's can help to obtain failure recovery when one of the tunnels is broken (because respective wireless link unavailable, or other reason). I assume a MR with two egress interfaces and one ingress interface; I assume each egress interface has its own Home Address and MR maintains two MR-HA tunnels: one to HA1 and one to HA2; I assume that HA1, HA2 and MR run a dynamic routing protocol between them; I also assume that there is only one prefix assigned to the moving network. In this case, I think that a dynamic routing protocol can dynamically manage to continue communication of LFN (LFN has only one address) even though one of the links corresponding to one of the tunnels fails. What do you think? Alex marcelo bagnulo wrote: > Hi Hesham, > > [...] > > >>Personally, I think it's a lot cleaner to have one prefix >>per MR and somehow solve the ingress filtering problem. > > > If i understand the scenario that you are proposing, there are more > problems, not only ingress filtering. > > Let me see if i get this right: > The scenario that you are proposing would be the following > > P::/26 > ----|-------------- Home network > | > +---+ > |HA | > +---+ > route | \ route to > P:P1:: | \ P:P2:: > | \ > +---+ +---+ > |MR1| |MR2| > +---+ +---+ > P:P1::| |P:P2:: > ---------------------- Mobile network > > So, each of the MR of the NEMO has one prefix assigned and announces it in > the NEMO. > The HA has one prefix registered per each MR, so this means that it forwards > packets addressed to P:P1:: only through MR1 and the HA forwards packets > addressed to P:P2:: only through MR2 > Is this the configuration that you are proposing? > > If this is so, this presents all the problems of multiaddressing, i guess. > In order to be reachable through both MR, the hosts within the NEMO will > have to configure two addresses, one with P:P1:: and another one with P:P2. > This is so because if they only configure an address with P:P1:: they will > be only be reachable through MR1, since the HA only has MR1 registered for > this prefix. > > Well this multiaddressing configuration presents complex challenges, for > instance how do you preserve established communications when the MR that you > were using fails. > Also, in case that one of the MR is down, you need a smart way to select the > source address that is working on the reverse path, which imposes new > mechanisms in the MNN > > So, in brief, if i understand correctly, this configuration poses the full > multihoming problem in a configuration that didn't suffered it before. > > I am sure that i don't fully grasp the complete problem of detecting a > duplicate prefix in the same HA that you are discussing, so i cannot make > any consideration about the solution for this problem, but the proposed > configuration really presents complex issues. > Of course, once that multi6 develops a solution for the general case, it > should also cover this case too. > > Regards, marcelo > > > > >>This is not so difficult in the case where the 2 MRs >>belong to the same home domain/link. For instance, an >>ISP might not filter (in the MR's HA) on any of the >>prefixes that are assigned to its domain. So basically >>it forwards any packet coming from any prefix derived >>from ISP_PREFIX::/26. This would solve the simple multihoming >>case where 2 MRs belong to the same home admin domain. >>I think this will solve the problem with the scenarios >>that you mention, i.e. plane, train, bus ...etc. >> >>Do you think this will work? This requires hardly any >>changes to the spec. We can clearly do without changing >>anything, except for mentioning that 2 MRs do not share >>the same prefix. I misstated that before to say 1 prefix >>per MR, when what I really meant was two MRs do not share >>the same prefix. >> >>Hesham >> >> >> > >> > Pascal >> > >> > > --------------ms030702060902000604090700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNjM2NTFaMCMGCSqGSIb3DQEJBDEWBBQ5h5FBkXWzrHTEWyw2oicdDWqZ3jBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDLINTUNhLZr9GlMplcWRWBUJVYKmP8+tFNMtMK 9NDHrb5zc+N2Zxs63BMfK5hUS/a1f19X3JXpqIvgilcNSj17ixCjQo20nij4G3Q7tdZY0Zn4 yw+JxO8ngWq0sYEKRo6Jbxn5lZrTqLUIjZDuOTdswQoQPDQubAOGtCHYUw2RFAAAAAAAAA== --------------ms030702060902000604090700-- From exim@www1.ietf.org Wed Mar 24 11:40:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05371 for ; Wed, 24 Mar 2004 11:40:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BQW-0004Sw-OG for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:40:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGeONn017158 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 11:40:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BQU-0004SX-FM for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:40:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05356 for ; Wed, 24 Mar 2004 11:40:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BQT-0001rR-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:40:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BPf-0001pF-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:39:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6BPI-0001lf-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 11:39:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BPA-0004Kv-Ur; Wed, 24 Mar 2004 11:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BOV-0004Bo-21 for nemo@optimus.ietf.org; Wed, 24 Mar 2004 11:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05243 for ; Wed, 24 Mar 2004 11:38:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BOT-0001kI-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:38:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BNg-0001ho-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:37:29 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6BNG-0001eO-00 for nemo@ietf.org; Wed, 24 Mar 2004 11:37:02 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OGb3JO026163; Wed, 24 Mar 2004 09:37:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2OGauUK019044; Wed, 24 Mar 2004 10:36:56 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3388785C46E; Wed, 24 Mar 2004 17:36:55 +0100 (CET) Message-ID: <4061B923.7050907@motorola.com> Date: Wed, 24 Mar 2004 17:36:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030702060902000604090700" Subject: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms030702060902000604090700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Marcelo, I think that a dynamic routing protocol on MR and HA's can help to obtain failure recovery when one of the tunnels is broken (because respective wireless link unavailable, or other reason). I assume a MR with two egress interfaces and one ingress interface; I assume each egress interface has its own Home Address and MR maintains two MR-HA tunnels: one to HA1 and one to HA2; I assume that HA1, HA2 and MR run a dynamic routing protocol between them; I also assume that there is only one prefix assigned to the moving network. In this case, I think that a dynamic routing protocol can dynamically manage to continue communication of LFN (LFN has only one address) even though one of the links corresponding to one of the tunnels fails. What do you think? Alex marcelo bagnulo wrote: > Hi Hesham, > > [...] > > >>Personally, I think it's a lot cleaner to have one prefix >>per MR and somehow solve the ingress filtering problem. > > > If i understand the scenario that you are proposing, there are more > problems, not only ingress filtering. > > Let me see if i get this right: > The scenario that you are proposing would be the following > > P::/26 > ----|-------------- Home network > | > +---+ > |HA | > +---+ > route | \ route to > P:P1:: | \ P:P2:: > | \ > +---+ +---+ > |MR1| |MR2| > +---+ +---+ > P:P1::| |P:P2:: > ---------------------- Mobile network > > So, each of the MR of the NEMO has one prefix assigned and announces it in > the NEMO. > The HA has one prefix registered per each MR, so this means that it forwards > packets addressed to P:P1:: only through MR1 and the HA forwards packets > addressed to P:P2:: only through MR2 > Is this the configuration that you are proposing? > > If this is so, this presents all the problems of multiaddressing, i guess. > In order to be reachable through both MR, the hosts within the NEMO will > have to configure two addresses, one with P:P1:: and another one with P:P2. > This is so because if they only configure an address with P:P1:: they will > be only be reachable through MR1, since the HA only has MR1 registered for > this prefix. > > Well this multiaddressing configuration presents complex challenges, for > instance how do you preserve established communications when the MR that you > were using fails. > Also, in case that one of the MR is down, you need a smart way to select the > source address that is working on the reverse path, which imposes new > mechanisms in the MNN > > So, in brief, if i understand correctly, this configuration poses the full > multihoming problem in a configuration that didn't suffered it before. > > I am sure that i don't fully grasp the complete problem of detecting a > duplicate prefix in the same HA that you are discussing, so i cannot make > any consideration about the solution for this problem, but the proposed > configuration really presents complex issues. > Of course, once that multi6 develops a solution for the general case, it > should also cover this case too. > > Regards, marcelo > > > > >>This is not so difficult in the case where the 2 MRs >>belong to the same home domain/link. For instance, an >>ISP might not filter (in the MR's HA) on any of the >>prefixes that are assigned to its domain. So basically >>it forwards any packet coming from any prefix derived >>from ISP_PREFIX::/26. This would solve the simple multihoming >>case where 2 MRs belong to the same home admin domain. >>I think this will solve the problem with the scenarios >>that you mention, i.e. plane, train, bus ...etc. >> >>Do you think this will work? This requires hardly any >>changes to the spec. We can clearly do without changing >>anything, except for mentioning that 2 MRs do not share >>the same prefix. I misstated that before to say 1 prefix >>per MR, when what I really meant was two MRs do not share >>the same prefix. >> >>Hesham >> >> >> > >> > Pascal >> > >> > > --------------ms030702060902000604090700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNjM2NTFaMCMGCSqGSIb3DQEJBDEWBBQ5h5FBkXWzrHTEWyw2oicdDWqZ3jBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDLINTUNhLZr9GlMplcWRWBUJVYKmP8+tFNMtMK 9NDHrb5zc+N2Zxs63BMfK5hUS/a1f19X3JXpqIvgilcNSj17ixCjQo20nij4G3Q7tdZY0Zn4 yw+JxO8ngWq0sYEKRo6Jbxn5lZrTqLUIjZDuOTdswQoQPDQubAOGtCHYUw2RFAAAAAAAAA== --------------ms030702060902000604090700-- From nemo-admin@ietf.org Wed Mar 24 12:27:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07799 for ; Wed, 24 Mar 2004 12:27:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6C9d-0001YA-Ms; Wed, 24 Mar 2004 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6C8t-0001X7-JJ for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:26:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07773 for ; Wed, 24 Mar 2004 12:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6C8s-0005Mz-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:26:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6C7w-0005LI-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:25:17 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6C7c-0005JM-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:24:56 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AA8A81BEFC; Wed, 24 Mar 2004 18:24:25 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 606E41BEEB; Wed, 24 Mar 2004 18:24:25 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 18:21:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > => I don't think this is a requirement on the basic spec. > > > I think this is useful in many cases but I could also > > > ask the question: How do you preserve communication > > > when the HA fails ? I think this is a general problem > > > with MIP solutions when the communication goes through the > > > HA. There is no good way of detecting such failure and when > > > it happens, there is no way (other than providing a redundant > > > HA) to preserve communication in a timely manner. > > > > So i guess that current spec doesn't provides support for > > multiple HAs, is > > this correct? > > => Not for multiple HAs per MR, for the same prefix. > If you can decrypt this sentence I'd be grateful ;) It is clear, thanks. But from the tread, i understood that you cannot use different HA with different MR for the same prefix (can you decrypt now? :-) I mean, i understood that the problem is that the same prefix cannot be registered by different MR in the same or multiple HAs, is this correct? > > > > > Well, redundancy is the main goal for multihoming, so if you > > don't get > > redundancy probably you don't need multihoming i guess. > > => No, you're spending too much time in multi6 ;) I must admit that my view is very multi6 biased, so sorry of i miss some important points in the nemo context. > Redundancy is one important aim of multihoming. > Redundancy is _the_ aim of multihoming for fixed > sites. But multihoming is also a fact for mobile > nodes/networks because of the availability of different > access technologies that nodes can connect to. > The variety of these links offer several different > services that nodes should utilise. It's quite > a different scenario from enterprise multihoming. Yes, but this is redundancy. Basically, when you have multiple technologies, what happens is that one technology is no longer available (which is similar that the link goes down), and you need to use the alternative one. The only difference that i can see is that the frequency of changes will be higher and that the probability of using both link simultaneously will be lower than in the fixed case. This may be interesting because perhaps you can be able to use a strictly backup setup, that is that you only use one of the links, you don't require support for load sharing. If you relax the load sharing requirement, probably we can find a simpler solution. Is there other differences that i am missing? > > > > > So, in brief, if i understand correctly, this configuration > > > > poses the full > > > > multihoming problem in a configuration that didn't suffered > > > > it before. > > > > > > => I'm not sure what you mean by "didn't suffer it before"? > > > > I mean that the multihoming problem occurs when a site has > > multiple exterior > > connections and not when an interior subnet has multiple > > routers connecting > > to the rest of the local site. > > => True today. However, at the same time, IPv6 specs > assume that where multiple DRs on the same link exist, > the MN can choose either DR without associating the > prefix advertised by that router with its source address. > This is probably because of today's scenarios that you > describe. But in scenarios where the DRs are not > connected to the same site, this assumption does not > hold. This is something that could happen with nemo. > In a sense nemo could look like a broken network > if you follow today's specs. Ok, you are considering a case with a nemo that has two different home networks, right? Well, i would consider this scenario as a regular multihomed network, being the MR the border routers of the multihomed site and each of the home networks a different ISP. In this case, you will have in general two prefixes, and each prefix will be routable through only one ISP. This is the general case. But in any case, the point is that you can avoid the complexities of this problems in some case, and i guess that the question is if this is worth it. > > But of course the problem is not specific to nemo, > we've just seen it because of nemo provides the > only realistic scenarios that we can use today. > > > > It is basically related to how far you can inject routing information > > related to your subnetwork. In multihoming you are assuming > > that you can > > inject routing information in your site, but you cannot > > inject it in your > > isps. If you adopt this restriction that a HA only forwards > > packets to one > > of the prefixes, you are basically partitioning the scope of > > the intra site > > routing information. > > => I understand wht you're saying, but the problem is > that one of the MRs could move away and become separated > from the other MR/rest of the network. This is something > you don't see happening today (unless someone walks > off with a router on a trolley ;) ). If this happens, > you can't keep sending traffic addressed to the same prefix to > both MRs because you don't know which hosts are connected > to which MRs. > > For instance, if I have two MRs, a phone and a PDA that > I normally carry with me and there are a couple of other > MNNs connected to them. If I leave my PDA at home one day > with another device and take my phone and laptop with > me to work, the HA can't simply forward my laptop traffic > to the PDA because it's not connected to it! Ok, i see. But in this case, when the network splits, who keeps the addresses? I mean, the prefix is split or one of the parts keeps the prefix and the other one just have no prefixes at all? Ah! that is why you want multiple prefixes for the nemo, one with each MR, right? So when the network splits each one of them keeps its own prefix. > > > In brief, when the nemo has two different home networks with > > different > > prefixes, the problem is already there, since it is just > > like a multihomed > > site with two isps > > However, if there is only one home network that has only one > > prefix, you are > > artificially adding a new prefix to solve this multiple MR > > issue, and this > > solution introduces all the problems related to > > multiaddressing to this > > configuration that didn't have it previously. > > => There is no "previous" configuration. This is all > new. There is no established way of assigning the same > prefix to multiple MRs and managing to solve this > for cases where the network is divided. Mobility is > the key difference between our multihoming scenarios > and multi6 thinking of multihoming. If you assign > the same prefix to all MRs, what do you do when one > of them goes away with half the network? I think i am understanding the problem that you are considering now thanks > > > I guess that i fully agree with your conclusion here. > > My comments are: > > > > - First: wouldn't be useful to at least some of the multihomed > > configurations without waiting for a general multihoming > > solution to be > > deployed? > > => Yes. > > > > When there are several prefixes, this probably will require > > some support > > from the CN node, i.e. the general multihoming case > > => CN node? I don't follow that. The node outside the multihomed site > > I'm not sure if you read the very long thread with Pascal. > This discussion started by considering cases where the MRs > are relatively fixed in relation to each other. I said > that we need to either: > > a. Clarify the spec to explicitly describe that the > "one prefix" solution is designed for those cases and > if the network is divided then tough luck, or, > > b. Have one prefix per MR and the problems that will come > with that are not nemo specific anyway so eventually > will be solved. > > Obviously b) solves the same problem too. Neither a) > nor b) solve all cases today. Both a) and b) solve > the problem in question. I hope this is clearer. > Perfectly clear, thanks again The problem with b is that you are not providing a solution that is working now for the case of multiple MR. Option a at least works in some scenarios. I would like to explore a bit more a solution like what Pascal is proposing, since it would work as long as the nework doesn't split. I guess that the general solution will be based on b, but proabbly it would be valuable to provide a solution that works now at least for a reduced set of cases. Regards, marcelo > > > > - Second: from what i understand, all of the multihomed > > configurations fail > > in some way at this stage with the current spec, is this > > correct? whether > > this is because of the general multihoming problem or > > because MIP problems > > or nemo specific issues, i am concluding that the only > > configuration that > > works properly is the one with one MR , one prefix and one > > HA, is this > > correct? > > => No. It works for only one case: The MRs will never > be separated, they always stay on the same link (e.g. > airplane). > > > If this is so, perhaps an option would be to, as i think you > > are suggesting, > > explicitly state that only the 1 MR, 1 HA and 1 Prefix is > > expected to work > > fine in the spec. > > => Sorry, I'm not suggesting that :( Please see > above. Both a) and b) address the config in question. > Either a) or b) are fine with me... > > Hesham > From nemo-admin@ietf.org Wed Mar 24 12:28:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07866 for ; Wed, 24 Mar 2004 12:28:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CAl-0001mM-9E; Wed, 24 Mar 2004 12:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6C9t-0001gM-Qc for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:27:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07791 for ; Wed, 24 Mar 2004 12:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6C9s-0005Pb-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:27:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6C8w-0005Nk-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:26:19 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6C8K-0005Ju-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:25:40 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1C0D51BEF8; Wed, 24 Mar 2004 18:25:10 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 05E621BEEE; Wed, 24 Mar 2004 18:25:10 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 18:22:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4061B789.8010906@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > If this is so, this presents all the problems of multiaddressing, i > > guess. In order to be reachable through both MR, the hosts within the > > NEMO will have to configure two addresses, one with P:P1:: and > > another one with P:P2. This is so because if they only configure an > > address with P:P1:: they will be only be reachable through MR1, since > > the HA only has MR1 registered for this prefix. > > This is, as you say, a problem of having a host to confnigure two > addresses; it is not a NEMO problem. Yes, but if we impose that when there are multiple MR you need to have multiple prefixes one per MR, you are imposing all the problems of multiaddressing in a configuration that perhaps don't require multiple addresses. My point is that if we can avoid multiaddressing, we are avoiding lots of complex problems, so perhpas we shoudl try to do it at least in some of the scenarios. Makes sense? Regards, marcelo > > Alex > > From exim@www1.ietf.org Wed Mar 24 12:41:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08603 for ; Wed, 24 Mar 2004 12:41:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CMu-0002zu-FZ for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 12:41:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OHeYdP011439 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 12:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CMe-0002xn-TI for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 12:40:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08403 for ; Wed, 24 Mar 2004 12:40:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6CMO-0006By-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:40:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6CL8-00061y-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:38:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6CJx-0005sm-04 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:37:41 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6CAm-0002uN-O9 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:28:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CAl-0001mM-9E; Wed, 24 Mar 2004 12:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6C9t-0001gM-Qc for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:27:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07791 for ; Wed, 24 Mar 2004 12:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6C9s-0005Pb-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:27:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6C8w-0005Nk-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:26:19 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6C8K-0005Ju-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:25:40 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1C0D51BEF8; Wed, 24 Mar 2004 18:25:10 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 05E621BEEE; Wed, 24 Mar 2004 18:25:10 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 18:22:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4061B789.8010906@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > If this is so, this presents all the problems of multiaddressing, i > > guess. In order to be reachable through both MR, the hosts within the > > NEMO will have to configure two addresses, one with P:P1:: and > > another one with P:P2. This is so because if they only configure an > > address with P:P1:: they will be only be reachable through MR1, since > > the HA only has MR1 registered for this prefix. > > This is, as you say, a problem of having a host to confnigure two > addresses; it is not a NEMO problem. Yes, but if we impose that when there are multiple MR you need to have multiple prefixes one per MR, you are imposing all the problems of multiaddressing in a configuration that perhaps don't require multiple addresses. My point is that if we can avoid multiaddressing, we are avoiding lots of complex problems, so perhpas we shoudl try to do it at least in some of the scenarios. Makes sense? Regards, marcelo > > Alex > > From nemo-admin@ietf.org Wed Mar 24 12:56:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09431 for ; Wed, 24 Mar 2004 12:56:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cbt-00048s-JX; Wed, 24 Mar 2004 12:56:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cb5-00045W-8l for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:55:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09354 for ; Wed, 24 Mar 2004 12:55:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cb3-0007Js-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:55:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6CaC-0007Ga-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:54:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6CZF-0007AV-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:53:29 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2004 10:00:06 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2OHqPsk011130; Wed, 24 Mar 2004 18:52:25 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 24 Mar 2004 17:52:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 17:52:55 -0000 Message-ID: Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQRxQBsXRvrcQ4SQgi5sH26keWUzgAAYWPw From: "Pascal Thubert \(pthubert\)" To: , "Alexandru Petrescu" Cc: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 24 Mar 2004 17:52:56.0574 (UTC) FILETIME=[D6A8E1E0:01C411C8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] > Sent: mercredi 24 mars 2004 18:23 > To: Alexandru Petrescu > Cc: Soliman Hesham; Pascal Thubert (pthubert); IETF NEMO WG > Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] >=20 > > > If this is so, this presents all the problems of multiaddressing, i > > > guess. In order to be reachable through both MR, the hosts within the > > > NEMO will have to configure two addresses, one with P:P1:: and > > > another one with P:P2. This is so because if they only configure an > > > address with P:P1:: they will be only be reachable through MR1, since > > > the HA only has MR1 registered for this prefix. > > > > This is, as you say, a problem of having a host to confnigure two > > addresses; it is not a NEMO problem. >=20 > Yes, but if we impose that when there are multiple MR you need to have > multiple prefixes one per MR, you are imposing all the problems of > multiaddressing in a configuration that perhaps don't require multiple > addresses. >=20 > My point is that if we can avoid multiaddressing, we are avoiding lots of > complex problems, so perhpas we shoudl try to do it at least in some of the > scenarios. >=20 > Makes sense? Sure does to me :) Let's not avoid the case where the MRs do not split. If they split, who says which device (LFN) stays with which router, and which 'side' should win the prefix from the HA standpoint. So I agree that case is broken. But if they do not, there's an opportunity for high availability that we should not bar, either. Note that a LFN host may keep using an address for quite some time, 'permanently' if it's a DNS address, thus the value of IP mobility. So if the LFN does not move with the MR that owns the prefix, the communication is broken. Thus the assumption is that a LFN sticks to its MR. The same way, 2 MRs serving the same prefix for redundancy reasons stick together. Otherwise it's broken.=20 Pascal From nemo-admin@ietf.org Wed Mar 24 12:57:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09526 for ; Wed, 24 Mar 2004 12:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ccf-0004Hr-8H; Wed, 24 Mar 2004 12:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cc6-0004CD-5N for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:56:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09392 for ; Wed, 24 Mar 2004 12:56:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cc4-0007PO-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:56:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Cb8-0007Kj-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:55:26 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1B6CaE-0007Gu-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:54:30 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id i2OHrRFU006640; Wed, 24 Mar 2004 10:53:27 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2OHs5dl012643; Wed, 24 Mar 2004 11:54:07 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A8D40855530; Wed, 24 Mar 2004 18:54:12 +0100 (CET) Message-ID: <4061CB3E.8000303@motorola.com> Date: Wed, 24 Mar 2004 18:54:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Cc: mbagnulo@ing.uc3m.es, Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: <4061B5B1.6010604@motorola.com> In-Reply-To: <4061B5B1.6010604@motorola.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070905040103080502040704" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms070905040103080502040704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Small correction "ingress" to "egress", see one-liner below Alexandru Petrescu wrote: > marcelo bagnulo wrote: > >> i am concluding that the only configuration that works properly is the >> one with one MR , one prefix and one HA, is this correct? > > > This is not correct. That 1-1-1 configuration is not the _only_ > configuration that works properly with the NEMO base protocol. > > With NEMO base protocol it is also possible to have 1 MR that has two > home addresses on the ingress interface and two different moving network ^ sorry I meant egress > prefixes towards a unique ingress interface. > > It is also possible to have two home addresses on two different egress > interfaces and two MNP's on a unique ingress interface. > > It is also possible to have two home addresses on two different egress > interfaces and two MNP's on two different ingress interfaces. > > Alex --------------ms070905040103080502040704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNzU0MDZaMCMGCSqGSIb3DQEJBDEWBBTwXiG3MY4C8hQ/O1Wqp4e9D9/gijBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDNhiEQL/sUg7UcIoUK4up92zBJ4A3hzUnf0P3O le79eeRul+p/NpB4yzKhQuwr3RwxcVYeY3cK/Ekj5tq8upBpwmboSstxgfuANOvD9rse8oEM GgNbZg8Sgp6Qv5jqZGQPHZF/+8vEcpslUdNF8YB4QH7DAc8CUtlFO1BEIcqXmgAAAAAAAA== --------------ms070905040103080502040704-- From nemo-admin@ietf.org Wed Mar 24 12:57:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09543 for ; Wed, 24 Mar 2004 12:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ccg-0004K5-0g; Wed, 24 Mar 2004 12:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cc6-0004CL-Qz for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:56:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09395 for ; Wed, 24 Mar 2004 12:56:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cc5-0007PT-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:56:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Cb9-0007Kv-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:55:28 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6CaF-0007E6-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:54:31 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 56A681BEB5; Wed, 24 Mar 2004 18:54:01 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 41CE41BEAC; Wed, 24 Mar 2004 18:54:01 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Date: Wed, 24 Mar 2004 18:51:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4061B923.7050907@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Marcelo, I think that a dynamic routing protocol on MR and HA's can help > to obtain failure recovery when one of the tunnels is broken (because > respective wireless link unavailable, or other reason). > > I assume a MR with two egress interfaces and one ingress interface; I > assume each egress interface has its own Home Address and MR maintains > two MR-HA tunnels: one to HA1 and one to HA2; I assume that HA1, HA2 and > MR run a dynamic routing protocol between them; I also assume that there > is only one prefix assigned to the moving network. > > In this case, I think that a dynamic routing protocol can dynamically > manage to continue communication of LFN (LFN has only one address) even > though one of the links corresponding to one of the tunnels fails. > > What do you think? indeed. That is the type of solution that you would have in a fixed subnetwork with multiple routers connecting to the site. That is what the IGPs are designed to do so that is the tool. Two issues here: First, how to handle the split network problem that Hesham is considering? When the network splits, one of the MR should stop advertising the nemo prefix, i guess, so some setting for this should be required. Second, this is a general nemo issue about security when using IGPs in a nemo environment, do you think that it is acceptable to run an IGP between the MR and the HA? Regards, marcelo > > Alex > > marcelo bagnulo wrote: > > > Hi Hesham, > > > > [...] > > > > > >>Personally, I think it's a lot cleaner to have one prefix > >>per MR and somehow solve the ingress filtering problem. > > > > > > If i understand the scenario that you are proposing, there are more > > problems, not only ingress filtering. > > > > Let me see if i get this right: > > The scenario that you are proposing would be the following > > > > P::/26 > > ----|-------------- Home network > > | > > +---+ > > |HA | > > +---+ > > route | \ route to > > P:P1:: | \ P:P2:: > > | \ > > +---+ +---+ > > |MR1| |MR2| > > +---+ +---+ > > P:P1::| |P:P2:: > > ---------------------- Mobile network > > > > So, each of the MR of the NEMO has one prefix assigned and > announces it in > > the NEMO. > > The HA has one prefix registered per each MR, so this means > that it forwards > > packets addressed to P:P1:: only through MR1 and the HA > forwards packets > > addressed to P:P2:: only through MR2 > > Is this the configuration that you are proposing? > > > > If this is so, this presents all the problems of > multiaddressing, i guess. > > In order to be reachable through both MR, the hosts within the NEMO will > > have to configure two addresses, one with P:P1:: and another > one with P:P2. > > This is so because if they only configure an address with > P:P1:: they will > > be only be reachable through MR1, since the HA only has MR1 > registered for > > this prefix. > > > > Well this multiaddressing configuration presents complex challenges, for > > instance how do you preserve established communications when > the MR that you > > were using fails. > > Also, in case that one of the MR is down, you need a smart way > to select the > > source address that is working on the reverse path, which imposes new > > mechanisms in the MNN > > > > So, in brief, if i understand correctly, this configuration > poses the full > > multihoming problem in a configuration that didn't suffered it before. > > > > I am sure that i don't fully grasp the complete problem of detecting a > > duplicate prefix in the same HA that you are discussing, so i > cannot make > > any consideration about the solution for this problem, but the proposed > > configuration really presents complex issues. > > Of course, once that multi6 develops a solution for the general case, it > > should also cover this case too. > > > > Regards, marcelo > > > > > > > > > >>This is not so difficult in the case where the 2 MRs > >>belong to the same home domain/link. For instance, an > >>ISP might not filter (in the MR's HA) on any of the > >>prefixes that are assigned to its domain. So basically > >>it forwards any packet coming from any prefix derived > >>from ISP_PREFIX::/26. This would solve the simple multihoming > >>case where 2 MRs belong to the same home admin domain. > >>I think this will solve the problem with the scenarios > >>that you mention, i.e. plane, train, bus ...etc. > >> > >>Do you think this will work? This requires hardly any > >>changes to the spec. We can clearly do without changing > >>anything, except for mentioning that 2 MRs do not share > >>the same prefix. I misstated that before to say 1 prefix > >>per MR, when what I really meant was two MRs do not share > >>the same prefix. > >> > >>Hesham > >> > >> > >> > > >> > Pascal > >> > > >> > > > > > > From exim@www1.ietf.org Wed Mar 24 13:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10553 for ; Wed, 24 Mar 2004 13:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CqE-00062X-Kk for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OIB2Ng023211 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CqE-00062I-D7 for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 13:11:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10461 for ; Wed, 24 Mar 2004 13:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6CqC-0000pH-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Cor-0000ar-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:09:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Cn3-0000Hd-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:07:45 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6Ccp-0003pJ-Ig for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:57:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ccg-0004K5-0g; Wed, 24 Mar 2004 12:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cc6-0004CL-Qz for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:56:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09395 for ; Wed, 24 Mar 2004 12:56:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cc5-0007PT-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:56:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Cb9-0007Kv-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:55:28 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6CaF-0007E6-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:54:31 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 56A681BEB5; Wed, 24 Mar 2004 18:54:01 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 41CE41BEAC; Wed, 24 Mar 2004 18:54:01 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Date: Wed, 24 Mar 2004 18:51:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4061B923.7050907@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Marcelo, I think that a dynamic routing protocol on MR and HA's can help > to obtain failure recovery when one of the tunnels is broken (because > respective wireless link unavailable, or other reason). > > I assume a MR with two egress interfaces and one ingress interface; I > assume each egress interface has its own Home Address and MR maintains > two MR-HA tunnels: one to HA1 and one to HA2; I assume that HA1, HA2 and > MR run a dynamic routing protocol between them; I also assume that there > is only one prefix assigned to the moving network. > > In this case, I think that a dynamic routing protocol can dynamically > manage to continue communication of LFN (LFN has only one address) even > though one of the links corresponding to one of the tunnels fails. > > What do you think? indeed. That is the type of solution that you would have in a fixed subnetwork with multiple routers connecting to the site. That is what the IGPs are designed to do so that is the tool. Two issues here: First, how to handle the split network problem that Hesham is considering? When the network splits, one of the MR should stop advertising the nemo prefix, i guess, so some setting for this should be required. Second, this is a general nemo issue about security when using IGPs in a nemo environment, do you think that it is acceptable to run an IGP between the MR and the HA? Regards, marcelo > > Alex > > marcelo bagnulo wrote: > > > Hi Hesham, > > > > [...] > > > > > >>Personally, I think it's a lot cleaner to have one prefix > >>per MR and somehow solve the ingress filtering problem. > > > > > > If i understand the scenario that you are proposing, there are more > > problems, not only ingress filtering. > > > > Let me see if i get this right: > > The scenario that you are proposing would be the following > > > > P::/26 > > ----|-------------- Home network > > | > > +---+ > > |HA | > > +---+ > > route | \ route to > > P:P1:: | \ P:P2:: > > | \ > > +---+ +---+ > > |MR1| |MR2| > > +---+ +---+ > > P:P1::| |P:P2:: > > ---------------------- Mobile network > > > > So, each of the MR of the NEMO has one prefix assigned and > announces it in > > the NEMO. > > The HA has one prefix registered per each MR, so this means > that it forwards > > packets addressed to P:P1:: only through MR1 and the HA > forwards packets > > addressed to P:P2:: only through MR2 > > Is this the configuration that you are proposing? > > > > If this is so, this presents all the problems of > multiaddressing, i guess. > > In order to be reachable through both MR, the hosts within the NEMO will > > have to configure two addresses, one with P:P1:: and another > one with P:P2. > > This is so because if they only configure an address with > P:P1:: they will > > be only be reachable through MR1, since the HA only has MR1 > registered for > > this prefix. > > > > Well this multiaddressing configuration presents complex challenges, for > > instance how do you preserve established communications when > the MR that you > > were using fails. > > Also, in case that one of the MR is down, you need a smart way > to select the > > source address that is working on the reverse path, which imposes new > > mechanisms in the MNN > > > > So, in brief, if i understand correctly, this configuration > poses the full > > multihoming problem in a configuration that didn't suffered it before. > > > > I am sure that i don't fully grasp the complete problem of detecting a > > duplicate prefix in the same HA that you are discussing, so i > cannot make > > any consideration about the solution for this problem, but the proposed > > configuration really presents complex issues. > > Of course, once that multi6 develops a solution for the general case, it > > should also cover this case too. > > > > Regards, marcelo > > > > > > > > > >>This is not so difficult in the case where the 2 MRs > >>belong to the same home domain/link. For instance, an > >>ISP might not filter (in the MR's HA) on any of the > >>prefixes that are assigned to its domain. So basically > >>it forwards any packet coming from any prefix derived > >>from ISP_PREFIX::/26. This would solve the simple multihoming > >>case where 2 MRs belong to the same home admin domain. > >>I think this will solve the problem with the scenarios > >>that you mention, i.e. plane, train, bus ...etc. > >> > >>Do you think this will work? This requires hardly any > >>changes to the spec. We can clearly do without changing > >>anything, except for mentioning that 2 MRs do not share > >>the same prefix. I misstated that before to say 1 prefix > >>per MR, when what I really meant was two MRs do not share > >>the same prefix. > >> > >>Hesham > >> > >> > >> > > >> > Pascal > >> > > >> > > > > > > From exim@www1.ietf.org Wed Mar 24 13:11:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10570 for ; Wed, 24 Mar 2004 13:11:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CqF-000630-Me for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:11:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OIB3X0023239 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CqF-00062i-Gn for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 13:11:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10465 for ; Wed, 24 Mar 2004 13:11:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6CqD-0000pP-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:11:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Cot-0000b9-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:09:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Cn3-0000Hd-02 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:07:45 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6Ccj-0003p4-1a for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cbt-00048s-JX; Wed, 24 Mar 2004 12:56:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cb5-00045W-8l for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:55:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09354 for ; Wed, 24 Mar 2004 12:55:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cb3-0007Js-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:55:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6CaC-0007Ga-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:54:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6CZF-0007AV-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:53:29 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2004 10:00:06 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2OHqPsk011130; Wed, 24 Mar 2004 18:52:25 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 24 Mar 2004 17:52:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 17:52:55 -0000 Message-ID: Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQRxQBsXRvrcQ4SQgi5sH26keWUzgAAYWPw From: "Pascal Thubert \(pthubert\)" To: , "Alexandru Petrescu" Cc: "Soliman Hesham" , "IETF NEMO WG" X-OriginalArrivalTime: 24 Mar 2004 17:52:56.0574 (UTC) FILETIME=[D6A8E1E0:01C411C8] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] > Sent: mercredi 24 mars 2004 18:23 > To: Alexandru Petrescu > Cc: Soliman Hesham; Pascal Thubert (pthubert); IETF NEMO WG > Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] >=20 > > > If this is so, this presents all the problems of multiaddressing, i > > > guess. In order to be reachable through both MR, the hosts within the > > > NEMO will have to configure two addresses, one with P:P1:: and > > > another one with P:P2. This is so because if they only configure an > > > address with P:P1:: they will be only be reachable through MR1, since > > > the HA only has MR1 registered for this prefix. > > > > This is, as you say, a problem of having a host to confnigure two > > addresses; it is not a NEMO problem. >=20 > Yes, but if we impose that when there are multiple MR you need to have > multiple prefixes one per MR, you are imposing all the problems of > multiaddressing in a configuration that perhaps don't require multiple > addresses. >=20 > My point is that if we can avoid multiaddressing, we are avoiding lots of > complex problems, so perhpas we shoudl try to do it at least in some of the > scenarios. >=20 > Makes sense? Sure does to me :) Let's not avoid the case where the MRs do not split. If they split, who says which device (LFN) stays with which router, and which 'side' should win the prefix from the HA standpoint. So I agree that case is broken. But if they do not, there's an opportunity for high availability that we should not bar, either. Note that a LFN host may keep using an address for quite some time, 'permanently' if it's a DNS address, thus the value of IP mobility. So if the LFN does not move with the MR that owns the prefix, the communication is broken. Thus the assumption is that a LFN sticks to its MR. The same way, 2 MRs serving the same prefix for redundancy reasons stick together. Otherwise it's broken.=20 Pascal From exim@www1.ietf.org Wed Mar 24 13:11:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10592 for ; Wed, 24 Mar 2004 13:11:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CqJ-00065j-Fu for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:11:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OIB7xG023409 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:11:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CqJ-00065U-9B for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 13:11:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10489 for ; Wed, 24 Mar 2004 13:11:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6CqH-0000pr-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:11:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Cox-0000bx-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:09:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Cn4-0000Hd-01 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:07:46 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6Ccg-0003p2-9F for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ccf-0004Hr-8H; Wed, 24 Mar 2004 12:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cc6-0004CD-5N for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:56:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09392 for ; Wed, 24 Mar 2004 12:56:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cc4-0007PO-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:56:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Cb8-0007Kj-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:55:26 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1B6CaE-0007Gu-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:54:30 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id i2OHrRFU006640; Wed, 24 Mar 2004 10:53:27 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2OHs5dl012643; Wed, 24 Mar 2004 11:54:07 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A8D40855530; Wed, 24 Mar 2004 18:54:12 +0100 (CET) Message-ID: <4061CB3E.8000303@motorola.com> Date: Wed, 24 Mar 2004 18:54:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Cc: mbagnulo@ing.uc3m.es, Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] References: <4061B5B1.6010604@motorola.com> In-Reply-To: <4061B5B1.6010604@motorola.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070905040103080502040704" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070905040103080502040704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Small correction "ingress" to "egress", see one-liner below Alexandru Petrescu wrote: > marcelo bagnulo wrote: > >> i am concluding that the only configuration that works properly is the >> one with one MR , one prefix and one HA, is this correct? > > > This is not correct. That 1-1-1 configuration is not the _only_ > configuration that works properly with the NEMO base protocol. > > With NEMO base protocol it is also possible to have 1 MR that has two > home addresses on the ingress interface and two different moving network ^ sorry I meant egress > prefixes towards a unique ingress interface. > > It is also possible to have two home addresses on two different egress > interfaces and two MNP's on a unique ingress interface. > > It is also possible to have two home addresses on two different egress > interfaces and two MNP's on two different ingress interfaces. > > Alex --------------ms070905040103080502040704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxNzU0MDZaMCMGCSqGSIb3DQEJBDEWBBTwXiG3MY4C8hQ/O1Wqp4e9D9/gijBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDNhiEQL/sUg7UcIoUK4up92zBJ4A3hzUnf0P3O le79eeRul+p/NpB4yzKhQuwr3RwxcVYeY3cK/Ekj5tq8upBpwmboSstxgfuANOvD9rse8oEM GgNbZg8Sgp6Qv5jqZGQPHZF/+8vEcpslUdNF8YB4QH7DAc8CUtlFO1BEIcqXmgAAAAAAAA== --------------ms070905040103080502040704-- From nemo-admin@ietf.org Wed Mar 24 13:12:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10686 for ; Wed, 24 Mar 2004 13:12:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CrB-0006GS-G2; Wed, 24 Mar 2004 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CqX-00068H-Ab for nemo@optimus.ietf.org; Wed, 24 Mar 2004 13:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10525 for ; Wed, 24 Mar 2004 13:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6CqV-0000sx-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:11:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6CpC-0000eQ-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:10:00 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6CnD-0000K2-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:07:55 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OI7uJO009902; Wed, 24 Mar 2004 11:07:56 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2OI7Odl025385; Wed, 24 Mar 2004 12:07:36 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 68B1485C46E; Wed, 24 Mar 2004 19:07:31 +0100 (CET) Message-ID: <4061CE5B.5000403@motorola.com> Date: Wed, 24 Mar 2004 19:07:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060406070307080704010207" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms060406070307080704010207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> I assume a MR with two egress interfaces and one ingress interface; >> I assume each egress interface has its own Home Address and MR >> maintains two MR-HA tunnels: one to HA1 and one to HA2; I assume >> that HA1, HA2 and MR run a dynamic routing protocol between them; I >> also assume that there is only one prefix assigned to the moving >> network. >> >> In this case, I think that a dynamic routing protocol can >> dynamically manage to continue communication of LFN (LFN has only >> one address) even though one of the links corresponding to one of >> the tunnels fails. > > indeed. That is the type of solution that you would have in a fixed > subnetwork with multiple routers connecting to the site. That is what > the IGPs are designed to do so that is the tool. I think IGP can be used between HA's and MR even when MR is not at home, because MR still belongs to the home domain (through the tunnels), so the I in IGP is still valid. > Two issues here: > > First, how to handle the split network problem that Hesham is > considering? When the network splits, one of the MR should stop > advertising the nemo prefix, i guess, so some setting for this should > be required. "Split network problem" could you please formalize somehow? Do you mean a moving network nesting under another moving network and then separating? What exactly is "split network"? I've read most of Hesham's emails attentively, but can't remember it. Maybe a separate message with subject line saying "split network problem" will help me. > Second, this is a general nemo issue about security when using IGPs > in a nemo environment, do you think that it is acceptable to run an > IGP between the MR and the HA? I think there is no major security issue in using IGP in a NEMO environment as long as that IGP is used between MR and HA's and over the MR-HA tunnels. I'm definitely not proposing to have MR to have direct IGP interactions with the other IGP that might happen to run in the visited domain (e.g. I'm _not_ proposing MR to do IGP with AR). No? Alex --------------ms060406070307080704010207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxODA3MjNaMCMGCSqGSIb3DQEJBDEWBBQYofewbNcGNBCbpqy1cKJmNTgOSDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYB2n4xoBFu3AjzlgRlfpX3DKbX9wL/T31mLn5Kz WY16ApJM0NJ2/ZR6Bvv4plpLZiRcB9aE2klb3enxJEPUyt1DB/0iM1ztlcMTJFT1hRmSVkbJ 3CCpIfsjUxZ9mvlchHowvaueNfIR01qygpDPm/gxfcwjbj8rdSVtYYcw3tObWgAAAAAAAA== --------------ms060406070307080704010207-- From exim@www1.ietf.org Wed Mar 24 13:14:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10776 for ; Wed, 24 Mar 2004 13:14:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Csq-0006U0-DI for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:13:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OIDi3A024914 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:13:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Csq-0006Tl-8E for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 13:13:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10771 for ; Wed, 24 Mar 2004 13:13:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cso-0001AQ-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:13:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Crs-00014b-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:12:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6CrF-0000yc-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CrB-0006GS-G2; Wed, 24 Mar 2004 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CqX-00068H-Ab for nemo@optimus.ietf.org; Wed, 24 Mar 2004 13:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10525 for ; Wed, 24 Mar 2004 13:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6CqV-0000sx-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:11:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6CpC-0000eQ-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:10:00 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6CnD-0000K2-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:07:55 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2OI7uJO009902; Wed, 24 Mar 2004 11:07:56 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2OI7Odl025385; Wed, 24 Mar 2004 12:07:36 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 68B1485C46E; Wed, 24 Mar 2004 19:07:31 +0100 (CET) Message-ID: <4061CE5B.5000403@motorola.com> Date: Wed, 24 Mar 2004 19:07:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060406070307080704010207" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms060406070307080704010207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> I assume a MR with two egress interfaces and one ingress interface; >> I assume each egress interface has its own Home Address and MR >> maintains two MR-HA tunnels: one to HA1 and one to HA2; I assume >> that HA1, HA2 and MR run a dynamic routing protocol between them; I >> also assume that there is only one prefix assigned to the moving >> network. >> >> In this case, I think that a dynamic routing protocol can >> dynamically manage to continue communication of LFN (LFN has only >> one address) even though one of the links corresponding to one of >> the tunnels fails. > > indeed. That is the type of solution that you would have in a fixed > subnetwork with multiple routers connecting to the site. That is what > the IGPs are designed to do so that is the tool. I think IGP can be used between HA's and MR even when MR is not at home, because MR still belongs to the home domain (through the tunnels), so the I in IGP is still valid. > Two issues here: > > First, how to handle the split network problem that Hesham is > considering? When the network splits, one of the MR should stop > advertising the nemo prefix, i guess, so some setting for this should > be required. "Split network problem" could you please formalize somehow? Do you mean a moving network nesting under another moving network and then separating? What exactly is "split network"? I've read most of Hesham's emails attentively, but can't remember it. Maybe a separate message with subject line saying "split network problem" will help me. > Second, this is a general nemo issue about security when using IGPs > in a nemo environment, do you think that it is acceptable to run an > IGP between the MR and the HA? I think there is no major security issue in using IGP in a NEMO environment as long as that IGP is used between MR and HA's and over the MR-HA tunnels. I'm definitely not proposing to have MR to have direct IGP interactions with the other IGP that might happen to run in the visited domain (e.g. I'm _not_ proposing MR to do IGP with AR). No? Alex --------------ms060406070307080704010207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxODA3MjNaMCMGCSqGSIb3DQEJBDEWBBQYofewbNcGNBCbpqy1cKJmNTgOSDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYB2n4xoBFu3AjzlgRlfpX3DKbX9wL/T31mLn5Kz WY16ApJM0NJ2/ZR6Bvv4plpLZiRcB9aE2klb3enxJEPUyt1DB/0iM1ztlcMTJFT1hRmSVkbJ 3CCpIfsjUxZ9mvlchHowvaueNfIR01qygpDPm/gxfcwjbj8rdSVtYYcw3tObWgAAAAAAAA== --------------ms060406070307080704010207-- From nemo-admin@ietf.org Wed Mar 24 13:30:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11890 for ; Wed, 24 Mar 2004 13:30:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6D8c-0007Zb-41; Wed, 24 Mar 2004 13:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6D7u-0007Y1-7H for nemo@optimus.ietf.org; Wed, 24 Mar 2004 13:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11793 for ; Wed, 24 Mar 2004 13:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6D7s-0002gt-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6D6t-0002dR-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:28:15 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1B6D61-0002af-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:27:21 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i2OIRFa0022001; Wed, 24 Mar 2004 11:27:15 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2OIR0dl018288; Wed, 24 Mar 2004 12:27:02 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 551A185C46E; Wed, 24 Mar 2004 19:27:07 +0100 (CET) Message-ID: <4061D2F4.2040806@motorola.com> Date: Wed, 24 Mar 2004 19:27:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080107030305010809020500" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] Re:splitting moving networks (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms080107030305010809020500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> => I understand wht you're saying, but the problem is that one of >> the MRs could move away and become separated from the other MR/rest >> of the network. This is something you don't see happening today >> (unless someone walks off with a router on a trolley ;) ). If this >> happens, you can't keep sending traffic addressed to the same >> prefix to both MRs because you don't know which hosts are connected >> to which MRs. I think I've located the "split moving network problem". I think that, first, moving networks in the NEMO sense have a rigid structure, they just don't separate components from one another, a basic definition. I think second that the NEMO context has a kind of support of "splitting" which is in fact called "nesting" and which is supported by a good understanding about how it works. A PAN can enter a train entering a ferry and all works; all works also whenever the PAN gets off the train (splitting?) and into the ferry, or when the train gets off and the PAN back or similar. The only thing that does not work with "nesting" is the "cross-over" tunnel problem; other things that don't work with the NEMO base protocol (such as - with a certain interpretation - the "RA confliction" problem) may exist. Alex --------------ms080107030305010809020500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxODI3MDBaMCMGCSqGSIb3DQEJBDEWBBRdlIlZNP9Pu2aTnb0IHxEdQLJfDjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBKecLK5te5UGGVj54YYbIc0zYavHJi9rQmeWSI Nc50zXH2BwfwaJEEhErv68GNqKAUk79sZoOB+nIgLtaygBwoDwvwBXZrSLLE8erdc6lMiZNj oolo5TWTfg4VW2+cR/P5gcX9TiH7jrfhRncAKFx7EcAn5PE7kyGxitPoOXJftwAAAAAAAA== --------------ms080107030305010809020500-- From exim@www1.ietf.org Wed Mar 24 13:31:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11957 for ; Wed, 24 Mar 2004 13:31:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DA0-0007mW-N9 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:31:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OIVS8p029912 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 13:31:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DA0-0007mM-C0 for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 13:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11927 for ; Wed, 24 Mar 2004 13:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6D9y-0002qM-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:31:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6D95-0002mk-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:30:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6D8d-0002jf-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 13:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6D8c-0007Zb-41; Wed, 24 Mar 2004 13:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6D7u-0007Y1-7H for nemo@optimus.ietf.org; Wed, 24 Mar 2004 13:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11793 for ; Wed, 24 Mar 2004 13:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6D7s-0002gt-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6D6t-0002dR-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:28:15 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1B6D61-0002af-00 for nemo@ietf.org; Wed, 24 Mar 2004 13:27:21 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i2OIRFa0022001; Wed, 24 Mar 2004 11:27:15 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i2OIR0dl018288; Wed, 24 Mar 2004 12:27:02 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 551A185C46E; Wed, 24 Mar 2004 19:27:07 +0100 (CET) Message-ID: <4061D2F4.2040806@motorola.com> Date: Wed, 24 Mar 2004 19:27:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080107030305010809020500" Subject: [nemo] Re:splitting moving networks (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms080107030305010809020500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> => I understand wht you're saying, but the problem is that one of >> the MRs could move away and become separated from the other MR/rest >> of the network. This is something you don't see happening today >> (unless someone walks off with a router on a trolley ;) ). If this >> happens, you can't keep sending traffic addressed to the same >> prefix to both MRs because you don't know which hosts are connected >> to which MRs. I think I've located the "split moving network problem". I think that, first, moving networks in the NEMO sense have a rigid structure, they just don't separate components from one another, a basic definition. I think second that the NEMO context has a kind of support of "splitting" which is in fact called "nesting" and which is supported by a good understanding about how it works. A PAN can enter a train entering a ferry and all works; all works also whenever the PAN gets off the train (splitting?) and into the ferry, or when the train gets off and the PAN back or similar. The only thing that does not work with "nesting" is the "cross-over" tunnel problem; other things that don't work with the NEMO base protocol (such as - with a certain interpretation - the "RA confliction" problem) may exist. Alex --------------ms080107030305010809020500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjQxODI3MDBaMCMGCSqGSIb3DQEJBDEWBBRdlIlZNP9Pu2aTnb0IHxEdQLJfDjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBKecLK5te5UGGVj54YYbIc0zYavHJi9rQmeWSI Nc50zXH2BwfwaJEEhErv68GNqKAUk79sZoOB+nIgLtaygBwoDwvwBXZrSLLE8erdc6lMiZNj oolo5TWTfg4VW2+cR/P5gcX9TiH7jrfhRncAKFx7EcAn5PE7kyGxitPoOXJftwAAAAAAAA== --------------ms080107030305010809020500-- From exim@www1.ietf.org Wed Mar 24 13:33:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08602 for ; Wed, 24 Mar 2004 12:41:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CMu-0002zt-FO for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 12:41:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OHeYoF011452 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 12:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CMi-0002xs-Oo for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 12:40:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08412 for ; Wed, 24 Mar 2004 12:40:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6CMR-0006D6-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:40:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6CLD-00062o-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:39:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6CJy-0005sm-02 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:37:42 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6C9h-0002rj-KZ for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 12:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6C9d-0001YA-Ms; Wed, 24 Mar 2004 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6C8t-0001X7-JJ for nemo@optimus.ietf.org; Wed, 24 Mar 2004 12:26:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07773 for ; Wed, 24 Mar 2004 12:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6C8s-0005Mz-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:26:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6C7w-0005LI-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:25:17 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6C7c-0005JM-00 for nemo@ietf.org; Wed, 24 Mar 2004 12:24:56 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AA8A81BEFC; Wed, 24 Mar 2004 18:24:25 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 606E41BEEB; Wed, 24 Mar 2004 18:24:25 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 18:21:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > => I don't think this is a requirement on the basic spec. > > > I think this is useful in many cases but I could also > > > ask the question: How do you preserve communication > > > when the HA fails ? I think this is a general problem > > > with MIP solutions when the communication goes through the > > > HA. There is no good way of detecting such failure and when > > > it happens, there is no way (other than providing a redundant > > > HA) to preserve communication in a timely manner. > > > > So i guess that current spec doesn't provides support for > > multiple HAs, is > > this correct? > > => Not for multiple HAs per MR, for the same prefix. > If you can decrypt this sentence I'd be grateful ;) It is clear, thanks. But from the tread, i understood that you cannot use different HA with different MR for the same prefix (can you decrypt now? :-) I mean, i understood that the problem is that the same prefix cannot be registered by different MR in the same or multiple HAs, is this correct? > > > > > Well, redundancy is the main goal for multihoming, so if you > > don't get > > redundancy probably you don't need multihoming i guess. > > => No, you're spending too much time in multi6 ;) I must admit that my view is very multi6 biased, so sorry of i miss some important points in the nemo context. > Redundancy is one important aim of multihoming. > Redundancy is _the_ aim of multihoming for fixed > sites. But multihoming is also a fact for mobile > nodes/networks because of the availability of different > access technologies that nodes can connect to. > The variety of these links offer several different > services that nodes should utilise. It's quite > a different scenario from enterprise multihoming. Yes, but this is redundancy. Basically, when you have multiple technologies, what happens is that one technology is no longer available (which is similar that the link goes down), and you need to use the alternative one. The only difference that i can see is that the frequency of changes will be higher and that the probability of using both link simultaneously will be lower than in the fixed case. This may be interesting because perhaps you can be able to use a strictly backup setup, that is that you only use one of the links, you don't require support for load sharing. If you relax the load sharing requirement, probably we can find a simpler solution. Is there other differences that i am missing? > > > > > So, in brief, if i understand correctly, this configuration > > > > poses the full > > > > multihoming problem in a configuration that didn't suffered > > > > it before. > > > > > > => I'm not sure what you mean by "didn't suffer it before"? > > > > I mean that the multihoming problem occurs when a site has > > multiple exterior > > connections and not when an interior subnet has multiple > > routers connecting > > to the rest of the local site. > > => True today. However, at the same time, IPv6 specs > assume that where multiple DRs on the same link exist, > the MN can choose either DR without associating the > prefix advertised by that router with its source address. > This is probably because of today's scenarios that you > describe. But in scenarios where the DRs are not > connected to the same site, this assumption does not > hold. This is something that could happen with nemo. > In a sense nemo could look like a broken network > if you follow today's specs. Ok, you are considering a case with a nemo that has two different home networks, right? Well, i would consider this scenario as a regular multihomed network, being the MR the border routers of the multihomed site and each of the home networks a different ISP. In this case, you will have in general two prefixes, and each prefix will be routable through only one ISP. This is the general case. But in any case, the point is that you can avoid the complexities of this problems in some case, and i guess that the question is if this is worth it. > > But of course the problem is not specific to nemo, > we've just seen it because of nemo provides the > only realistic scenarios that we can use today. > > > > It is basically related to how far you can inject routing information > > related to your subnetwork. In multihoming you are assuming > > that you can > > inject routing information in your site, but you cannot > > inject it in your > > isps. If you adopt this restriction that a HA only forwards > > packets to one > > of the prefixes, you are basically partitioning the scope of > > the intra site > > routing information. > > => I understand wht you're saying, but the problem is > that one of the MRs could move away and become separated > from the other MR/rest of the network. This is something > you don't see happening today (unless someone walks > off with a router on a trolley ;) ). If this happens, > you can't keep sending traffic addressed to the same prefix to > both MRs because you don't know which hosts are connected > to which MRs. > > For instance, if I have two MRs, a phone and a PDA that > I normally carry with me and there are a couple of other > MNNs connected to them. If I leave my PDA at home one day > with another device and take my phone and laptop with > me to work, the HA can't simply forward my laptop traffic > to the PDA because it's not connected to it! Ok, i see. But in this case, when the network splits, who keeps the addresses? I mean, the prefix is split or one of the parts keeps the prefix and the other one just have no prefixes at all? Ah! that is why you want multiple prefixes for the nemo, one with each MR, right? So when the network splits each one of them keeps its own prefix. > > > In brief, when the nemo has two different home networks with > > different > > prefixes, the problem is already there, since it is just > > like a multihomed > > site with two isps > > However, if there is only one home network that has only one > > prefix, you are > > artificially adding a new prefix to solve this multiple MR > > issue, and this > > solution introduces all the problems related to > > multiaddressing to this > > configuration that didn't have it previously. > > => There is no "previous" configuration. This is all > new. There is no established way of assigning the same > prefix to multiple MRs and managing to solve this > for cases where the network is divided. Mobility is > the key difference between our multihoming scenarios > and multi6 thinking of multihoming. If you assign > the same prefix to all MRs, what do you do when one > of them goes away with half the network? I think i am understanding the problem that you are considering now thanks > > > I guess that i fully agree with your conclusion here. > > My comments are: > > > > - First: wouldn't be useful to at least some of the multihomed > > configurations without waiting for a general multihoming > > solution to be > > deployed? > > => Yes. > > > > When there are several prefixes, this probably will require > > some support > > from the CN node, i.e. the general multihoming case > > => CN node? I don't follow that. The node outside the multihomed site > > I'm not sure if you read the very long thread with Pascal. > This discussion started by considering cases where the MRs > are relatively fixed in relation to each other. I said > that we need to either: > > a. Clarify the spec to explicitly describe that the > "one prefix" solution is designed for those cases and > if the network is divided then tough luck, or, > > b. Have one prefix per MR and the problems that will come > with that are not nemo specific anyway so eventually > will be solved. > > Obviously b) solves the same problem too. Neither a) > nor b) solve all cases today. Both a) and b) solve > the problem in question. I hope this is clearer. > Perfectly clear, thanks again The problem with b is that you are not providing a solution that is working now for the case of multiple MR. Option a at least works in some scenarios. I would like to explore a bit more a solution like what Pascal is proposing, since it would work as long as the nework doesn't split. I guess that the general solution will be based on b, but proabbly it would be valuable to provide a solution that works now at least for a reduced set of cases. Regards, marcelo > > > > - Second: from what i understand, all of the multihomed > > configurations fail > > in some way at this stage with the current spec, is this > > correct? whether > > this is because of the general multihoming problem or > > because MIP problems > > or nemo specific issues, i am concluding that the only > > configuration that > > works properly is the one with one MR , one prefix and one > > HA, is this > > correct? > > => No. It works for only one case: The MRs will never > be separated, they always stay on the same link (e.g. > airplane). > > > If this is so, perhaps an option would be to, as i think you > > are suggesting, > > explicitly state that only the 1 MR, 1 HA and 1 Prefix is > > expected to work > > fine in the spec. > > => Sorry, I'm not suggesting that :( Please see > above. Both a) and b) address the config in question. > Either a) or b) are fine with me... > > Hesham > From nemo-admin@ietf.org Wed Mar 24 21:27:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07823 for ; Wed, 24 Mar 2004 21:27:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KaC-0003HI-D8; Wed, 24 Mar 2004 21:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KZk-0003Gd-6k for nemo@optimus.ietf.org; Wed, 24 Mar 2004 21:26:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07794 for ; Wed, 24 Mar 2004 21:26:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6KZh-0001YM-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:26:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6KYj-0001T8-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:25:29 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6KXl-0001JX-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:24:29 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 21:24:00 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQRxNusCRcOe6MzTAi1jAx4yIsWfwASKDMQ From: "Soliman Hesham" To: , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > But from the tread, i understood that you cannot use=20 > different HA with > different MR for the same prefix (can you decrypt now? :-) >=20 > I mean, i understood that the problem is that the same=20 > prefix cannot be > registered by different MR in the same or multiple HAs, is=20 > this correct? =3D> The draft is vague on this. Pascal said yes you can and I was saying this has problems that are not described. > > Redundancy is one important aim of multihoming. > > Redundancy is _the_ aim of multihoming for fixed > > sites. But multihoming is also a fact for mobile > > nodes/networks because of the availability of different > > access technologies that nodes can connect to. > > The variety of these links offer several different > > services that nodes should utilise. It's quite > > a different scenario from enterprise multihoming. >=20 > Yes, but this is redundancy. Basically, when you have=20 > multiple technologies, > what happens is that one technology is no longer available=20 > (which is similar > that the link goes down), and you need to use the alternative one. > The only difference that i can see is that the frequency of=20 > changes will be > higher and that the probability of using both link=20 > simultaneously will be > lower than in the fixed case.=20 =3D> There are other differences. You might want to use=20 more than one access simultaneously by the same node. Not only for redundancy but because different applications prefer different access technologies. I don't see a WLAN access as providing complete redundancy to a cellular access since VoIP is not=20 really feasible on WLAN for example. So it's a=20 bit different to having 2 E1s which are providing=20 1+1 redundancy. > > > When there are several prefixes, this probably will require > > > some support > > > from the CN node, i.e. the general multihoming case > > > > =3D> CN node? I don't follow that. >=20 > The node outside the multihomed site =3D> I don't think any special support is needed in the=20 CN. For the multiaddress case you need special support in MNNs. But if both MRs are willing to reverse tunnel for all addresses (i.e. the same home ISP) then=20 the multi prefix case works as well as the single prefix case. This is the scenario being discussed. > The problem with b is that you are not providing a solution=20 > that is working > now for the case of multiple MR.=20 =3D> Not really, b) works for the scenario where both MRs have the same home ISP, which is the assumption behind a) anyway. You can't have the same prefix when both MRs are=20 connected to different home ISPs. Option a at least works in=20 > some scenarios. > I would like to explore a bit more a solution like what Pascal is > proposing, since it would work as long as the nework doesn't split. > I guess that the general solution will be based on b, but=20 > proabbly it would > be valuable to provide a solution that works now at least=20 > for a reduced set > of cases. =3D> Like I said, either case can work, my problem is that=20 the current spec is vague on either case. Hesham From exim@www1.ietf.org Wed Mar 24 21:29:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07900 for ; Wed, 24 Mar 2004 21:29:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Kbj-0003N6-Cn for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 21:28:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P2SZbM012956 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 21:28:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Kbj-0003Mt-84 for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 21:28:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07884 for ; Wed, 24 Mar 2004 21:28:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Kbg-0001h4-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 21:28:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Kav-0001e7-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 21:27:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6KaD-0001al-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 21:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KaC-0003HI-D8; Wed, 24 Mar 2004 21:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KZk-0003Gd-6k for nemo@optimus.ietf.org; Wed, 24 Mar 2004 21:26:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07794 for ; Wed, 24 Mar 2004 21:26:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6KZh-0001YM-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:26:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6KYj-0001T8-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:25:29 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6KXl-0001JX-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:24:29 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Wed, 24 Mar 2004 21:24:00 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Thread-Index: AcQRxNusCRcOe6MzTAi1jAx4yIsWfwASKDMQ From: "Soliman Hesham" To: , "Pascal Thubert (pthubert)" Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > But from the tread, i understood that you cannot use=20 > different HA with > different MR for the same prefix (can you decrypt now? :-) >=20 > I mean, i understood that the problem is that the same=20 > prefix cannot be > registered by different MR in the same or multiple HAs, is=20 > this correct? =3D> The draft is vague on this. Pascal said yes you can and I was saying this has problems that are not described. > > Redundancy is one important aim of multihoming. > > Redundancy is _the_ aim of multihoming for fixed > > sites. But multihoming is also a fact for mobile > > nodes/networks because of the availability of different > > access technologies that nodes can connect to. > > The variety of these links offer several different > > services that nodes should utilise. It's quite > > a different scenario from enterprise multihoming. >=20 > Yes, but this is redundancy. Basically, when you have=20 > multiple technologies, > what happens is that one technology is no longer available=20 > (which is similar > that the link goes down), and you need to use the alternative one. > The only difference that i can see is that the frequency of=20 > changes will be > higher and that the probability of using both link=20 > simultaneously will be > lower than in the fixed case.=20 =3D> There are other differences. You might want to use=20 more than one access simultaneously by the same node. Not only for redundancy but because different applications prefer different access technologies. I don't see a WLAN access as providing complete redundancy to a cellular access since VoIP is not=20 really feasible on WLAN for example. So it's a=20 bit different to having 2 E1s which are providing=20 1+1 redundancy. > > > When there are several prefixes, this probably will require > > > some support > > > from the CN node, i.e. the general multihoming case > > > > =3D> CN node? I don't follow that. >=20 > The node outside the multihomed site =3D> I don't think any special support is needed in the=20 CN. For the multiaddress case you need special support in MNNs. But if both MRs are willing to reverse tunnel for all addresses (i.e. the same home ISP) then=20 the multi prefix case works as well as the single prefix case. This is the scenario being discussed. > The problem with b is that you are not providing a solution=20 > that is working > now for the case of multiple MR.=20 =3D> Not really, b) works for the scenario where both MRs have the same home ISP, which is the assumption behind a) anyway. You can't have the same prefix when both MRs are=20 connected to different home ISPs. Option a at least works in=20 > some scenarios. > I would like to explore a bit more a solution like what Pascal is > proposing, since it would work as long as the nework doesn't split. > I guess that the general solution will be based on b, but=20 > proabbly it would > be valuable to provide a solution that works now at least=20 > for a reduced set > of cases. =3D> Like I said, either case can work, my problem is that=20 the current spec is vague on either case. Hesham From nemo-admin@ietf.org Wed Mar 24 21:33:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07986 for ; Wed, 24 Mar 2004 21:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Kg1-0003TI-CX; Wed, 24 Mar 2004 21:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Kfc-0003SN-Te for nemo@optimus.ietf.org; Wed, 24 Mar 2004 21:32:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07980 for ; Wed, 24 Mar 2004 21:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Kfa-0001v6-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:32:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Keh-0001sX-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:31:40 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Kdv-0001lw-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:30:51 -0500 content-class: urn:content-classes:message Date: Wed, 24 Mar 2004 21:30:22 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: splitting moving networks (was: DND test) Thread-Index: AcQRzdnzGstjsPG3QwKJiYoHL/8puAAQcYow From: "Soliman Hesham" To: "Alexandru Petrescu" , Cc: "Pascal Thubert (pthubert)" , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: splitting moving networks (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I think that, first, moving networks in the NEMO sense have a rigid=20 > structure, they just don't separate components from one=20 > another, a basic=20 > definition. =3D> Disagree. Where is this definition made? It would be=20 a big mistake to make this assumption IMHO. How can=20 you say that a moving network will never be divided? If I have a PAN with 4 devices and one day I left=20 2 at home and took 2 with me to work, you're saying=20 that this is not _meant_ to work? >=20 > I think second that the NEMO context has a kind of support of=20 > "splitting" which is in fact called "nesting" and which is=20 > supported by=20 > a good understanding about how it works. A PAN can enter a train=20 > entering a ferry and all works; all works also whenever the=20 > PAN gets off=20 > the train (splitting?) and into the ferry, or when the train=20 > gets off=20 > and the PAN back or similar. =3D> This is very different from what we're discussing,=20 nesting is fine. Hesham From exim@www1.ietf.org Wed Mar 24 21:35:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08036 for ; Wed, 24 Mar 2004 21:35:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Khe-0003aA-VT for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 21:34:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P2YgkJ013764 for nemo-archive@odin.ietf.org; Wed, 24 Mar 2004 21:34:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Khe-0003Zv-Qi for nemo-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 21:34:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08033 for ; Wed, 24 Mar 2004 21:34:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Khc-00024S-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 21:34:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Kgj-000215-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 21:33:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Kg1-0001wy-00 for nemo-web-archive@ietf.org; Wed, 24 Mar 2004 21:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Kg1-0003TI-CX; Wed, 24 Mar 2004 21:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Kfc-0003SN-Te for nemo@optimus.ietf.org; Wed, 24 Mar 2004 21:32:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07980 for ; Wed, 24 Mar 2004 21:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Kfa-0001v6-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:32:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Keh-0001sX-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:31:40 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Kdv-0001lw-00 for nemo@ietf.org; Wed, 24 Mar 2004 21:30:51 -0500 content-class: urn:content-classes:message Date: Wed, 24 Mar 2004 21:30:22 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: splitting moving networks (was: DND test) Thread-Index: AcQRzdnzGstjsPG3QwKJiYoHL/8puAAQcYow From: "Soliman Hesham" To: "Alexandru Petrescu" , Cc: "Pascal Thubert (pthubert)" , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: splitting moving networks (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I think that, first, moving networks in the NEMO sense have a rigid=20 > structure, they just don't separate components from one=20 > another, a basic=20 > definition. =3D> Disagree. Where is this definition made? It would be=20 a big mistake to make this assumption IMHO. How can=20 you say that a moving network will never be divided? If I have a PAN with 4 devices and one day I left=20 2 at home and took 2 with me to work, you're saying=20 that this is not _meant_ to work? >=20 > I think second that the NEMO context has a kind of support of=20 > "splitting" which is in fact called "nesting" and which is=20 > supported by=20 > a good understanding about how it works. A PAN can enter a train=20 > entering a ferry and all works; all works also whenever the=20 > PAN gets off=20 > the train (splitting?) and into the ferry, or when the train=20 > gets off=20 > and the PAN back or similar. =3D> This is very different from what we're discussing,=20 nesting is fine. Hesham From nemo-admin@ietf.org Thu Mar 25 01:15:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17787 for ; Thu, 25 Mar 2004 01:15:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6O8r-0004wQ-Sq; Thu, 25 Mar 2004 01:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6O8p-0004vg-5X for nemo@optimus.ietf.org; Thu, 25 Mar 2004 01:14:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17710 for ; Thu, 25 Mar 2004 01:14:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6O8m-0005K3-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:14:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6O7x-0005Az-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:14:05 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6O6p-0004tD-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:12:55 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A4D545D0B0 for ; Thu, 25 Mar 2004 15:12:24 +0900 (JST) Date: Thu, 25 Mar 2004 15:12:16 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040325151216.71b69448.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Interesting discussion. On Wed, 24 Mar 2004 21:30:22 -0500 "Soliman Hesham" wrote: > > I think that, first, moving networks in the NEMO sense have a rigid > > structure, they just don't separate components from one > > another, a basic > > definition. > > => Disagree. Where is this definition made? It would be > a big mistake to make this assumption IMHO. How can > you say that a moving network will never be divided? > If I have a PAN with 4 devices and one day I left > 2 at home and took 2 with me to work, you're saying > that this is not _meant_ to work? I do understand the issue. Sorry if I repeat myself, but I would like to try to propose the following actions. a. May I suggest Vijay to add an issue in his list (although the spec. is in IESG hands) ? b. I support open and un-ambiguous standard. So: b1. I would oppose to add in the NEMO Basic Support spec. sentences such like: - 2 MRs do not share the same prefix - NEMO cannot spit - etc b2. To solve ambiguousness, I would rather just say in the top of the document (a kind of disclaimer) than there is no warranty that NEMO Basic Support works with configurations other than a single NEMO-link attached to the Internet via one MR, i.e.: - multihomed mobile networks (8 cases, as identified by the multihomong problem statement, including multiple MRs) - nested mobile networks [although it's assumed it would, but test remains to be done - we will do it in our lab very soon] - split mobile networks and that necessary fixes may be done later. So, everyone is aware that checks remains to be done, and that additional specs. may be needed for specific configuration [e.g. a multihoming usage doc), at least in the informational track. Does this makes sense for everyone ? > > I think second that the NEMO context has a kind of support of > > "splitting" which is in fact called "nesting" and which is > > supported by > > a good understanding about how it works. A PAN can enter a train > > entering a ferry and all works; all works also whenever the > > PAN gets off > > the train (splitting?) and into the ferry, or when the train > > gets off > > and the PAN back or similar. > > => This is very different from what we're discussing, > nesting is fine. I concur to what Hesham says. Nested is when a sub-NEMO gets into a parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated prefix get split in 2 separate entities. Thierry From exim@www1.ietf.org Thu Mar 25 01:17:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17911 for ; Thu, 25 Mar 2004 01:17:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OAY-0005DR-5P for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 01:16:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P6GkrR020043 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 01:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OAX-0005DC-VI for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 01:16:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17883 for ; Thu, 25 Mar 2004 01:16:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OAV-0005XY-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:16:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6O9f-0005RI-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:15:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6O8x-0005Ls-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:15:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6O8s-0004wb-GO; Thu, 25 Mar 2004 01:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6O8q-0004vl-21 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 01:15:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17713 for ; Thu, 25 Mar 2004 01:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6O8n-0005KB-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:14:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6O7y-0005BG-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:14:07 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6O6p-0004tR-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:12:55 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 715F45D165 for ; Thu, 25 Mar 2004 15:12:26 +0900 (JST) Date: Thu, 25 Mar 2004 15:12:18 +0900 From: Thierry Ernst To: nemo Message-Id: <20040325151218.5ba35925.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Terminology: split mobile networks Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Can someone draft a brief definition for split mobile networks ? I would include it in the NEMO terminology. Thanks for help. Thierry. From exim@www1.ietf.org Thu Mar 25 01:17:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17927 for ; Thu, 25 Mar 2004 01:17:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OAZ-0005Dj-6Q for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 01:16:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P6Glm9020061 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 01:16:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OAZ-0005DU-1k for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 01:16:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17887 for ; Thu, 25 Mar 2004 01:16:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OAW-0005Xl-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:16:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6O9g-0005RQ-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:15:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6O8x-0005Lv-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:15:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6O8r-0004wQ-Sq; Thu, 25 Mar 2004 01:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6O8p-0004vg-5X for nemo@optimus.ietf.org; Thu, 25 Mar 2004 01:14:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17710 for ; Thu, 25 Mar 2004 01:14:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6O8m-0005K3-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:14:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6O7x-0005Az-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:14:05 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6O6p-0004tD-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:12:55 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A4D545D0B0 for ; Thu, 25 Mar 2004 15:12:24 +0900 (JST) Date: Thu, 25 Mar 2004 15:12:16 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040325151216.71b69448.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Interesting discussion. On Wed, 24 Mar 2004 21:30:22 -0500 "Soliman Hesham" wrote: > > I think that, first, moving networks in the NEMO sense have a rigid > > structure, they just don't separate components from one > > another, a basic > > definition. > > => Disagree. Where is this definition made? It would be > a big mistake to make this assumption IMHO. How can > you say that a moving network will never be divided? > If I have a PAN with 4 devices and one day I left > 2 at home and took 2 with me to work, you're saying > that this is not _meant_ to work? I do understand the issue. Sorry if I repeat myself, but I would like to try to propose the following actions. a. May I suggest Vijay to add an issue in his list (although the spec. is in IESG hands) ? b. I support open and un-ambiguous standard. So: b1. I would oppose to add in the NEMO Basic Support spec. sentences such like: - 2 MRs do not share the same prefix - NEMO cannot spit - etc b2. To solve ambiguousness, I would rather just say in the top of the document (a kind of disclaimer) than there is no warranty that NEMO Basic Support works with configurations other than a single NEMO-link attached to the Internet via one MR, i.e.: - multihomed mobile networks (8 cases, as identified by the multihomong problem statement, including multiple MRs) - nested mobile networks [although it's assumed it would, but test remains to be done - we will do it in our lab very soon] - split mobile networks and that necessary fixes may be done later. So, everyone is aware that checks remains to be done, and that additional specs. may be needed for specific configuration [e.g. a multihoming usage doc), at least in the informational track. Does this makes sense for everyone ? > > I think second that the NEMO context has a kind of support of > > "splitting" which is in fact called "nesting" and which is > > supported by > > a good understanding about how it works. A PAN can enter a train > > entering a ferry and all works; all works also whenever the > > PAN gets off > > the train (splitting?) and into the ferry, or when the train > > gets off > > and the PAN back or similar. > > => This is very different from what we're discussing, > nesting is fine. I concur to what Hesham says. Nested is when a sub-NEMO gets into a parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated prefix get split in 2 separate entities. Thierry From nemo-admin@ietf.org Thu Mar 25 01:23:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18236 for ; Thu, 25 Mar 2004 01:23:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OGa-0005nU-Vo; Thu, 25 Mar 2004 01:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OGJ-0005mW-On for nemo@optimus.ietf.org; Thu, 25 Mar 2004 01:22:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18177 for ; Thu, 25 Mar 2004 01:22:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OGG-00066g-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:22:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OFH-00061L-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:21:39 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6OEI-0005uc-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:20:38 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1C8F65D165; Thu, 25 Mar 2004 15:20:09 +0900 (JST) Date: Thu, 25 Mar 2004 15:20:00 +0900 From: Thierry Ernst To: Cc: H.Soliman@flarion.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Message-Id: <20040325152000.7d978c78.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Below, 1 reply to marcelo, and 1 reply to all. > > Redundancy is one important aim of multihoming. > > Redundancy is _the_ aim of multihoming for fixed > > sites. But multihoming is also a fact for mobile > > nodes/networks because of the availability of different > > access technologies that nodes can connect to. > > The variety of these links offer several different > > services that nodes should utilise. It's quite > > a different scenario from enterprise multihoming. > > Yes, but this is redundancy. Basically, when you have multiple technologies, > what happens is that one technology is no longer available (which is similar > that the link goes down), and you need to use the alternative one. > The only difference that i can see is that the frequency of changes will be > higher and that the probability of using both link simultaneously will be > lower than in the fixed case. This may be interesting because perhaps you > can be able to use a strictly backup setup, that is that you only use one of > the links, you don't require support for load sharing. If you relax the load > sharing requirement, probably we can find a simpler solution. > Is there other differences that i am missing? Marcelo, did you read Title : Goals and Benefits of Multihoming Author(s) : T. Ernst Filename : draft-multihoming-generic-goals-and-benefits-00.txt Pages : 16 Date : 2004-2-11 This document attempts to define the goals and benefits of multihoming for fixed and mobile hosts and routers. Those goals and benefits are illustrated with a set of real-life scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt ? To all, all the discussions about the "split NEMO" and "multiple MR on a NEMO-prefix" etc are very good input for http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt, which will become a NEMO WG document in his next revision. I think that the issues should be discussed in that draft, not in the NEMO Basic Support draft. And I would support, additionaly to the multihoming problem statement draft, another draft for "multihoming usages". The problem statement draft will ... state ... all the ... problems, while the usage draft would give a priority to the scenario which are useful. I think we can agree on this way of working ? Thierry. From exim@www1.ietf.org Thu Mar 25 01:25:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18362 for ; Thu, 25 Mar 2004 01:25:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OII-0006OA-A5 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 01:24:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P6OkvE024544 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 01:24:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OII-0006NM-3S for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 01:24:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18344 for ; Thu, 25 Mar 2004 01:24:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OIF-0006Jw-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:24:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OHO-0006FC-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:23:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6OGZ-00069h-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OGa-0005nU-Vo; Thu, 25 Mar 2004 01:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OGJ-0005mW-On for nemo@optimus.ietf.org; Thu, 25 Mar 2004 01:22:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18177 for ; Thu, 25 Mar 2004 01:22:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OGG-00066g-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:22:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OFH-00061L-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:21:39 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6OEI-0005uc-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:20:38 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1C8F65D165; Thu, 25 Mar 2004 15:20:09 +0900 (JST) Date: Thu, 25 Mar 2004 15:20:00 +0900 From: Thierry Ernst To: Cc: H.Soliman@flarion.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Message-Id: <20040325152000.7d978c78.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Below, 1 reply to marcelo, and 1 reply to all. > > Redundancy is one important aim of multihoming. > > Redundancy is _the_ aim of multihoming for fixed > > sites. But multihoming is also a fact for mobile > > nodes/networks because of the availability of different > > access technologies that nodes can connect to. > > The variety of these links offer several different > > services that nodes should utilise. It's quite > > a different scenario from enterprise multihoming. > > Yes, but this is redundancy. Basically, when you have multiple technologies, > what happens is that one technology is no longer available (which is similar > that the link goes down), and you need to use the alternative one. > The only difference that i can see is that the frequency of changes will be > higher and that the probability of using both link simultaneously will be > lower than in the fixed case. This may be interesting because perhaps you > can be able to use a strictly backup setup, that is that you only use one of > the links, you don't require support for load sharing. If you relax the load > sharing requirement, probably we can find a simpler solution. > Is there other differences that i am missing? Marcelo, did you read Title : Goals and Benefits of Multihoming Author(s) : T. Ernst Filename : draft-multihoming-generic-goals-and-benefits-00.txt Pages : 16 Date : 2004-2-11 This document attempts to define the goals and benefits of multihoming for fixed and mobile hosts and routers. Those goals and benefits are illustrated with a set of real-life scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt ? To all, all the discussions about the "split NEMO" and "multiple MR on a NEMO-prefix" etc are very good input for http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt, which will become a NEMO WG document in his next revision. I think that the issues should be discussed in that draft, not in the NEMO Basic Support draft. And I would support, additionaly to the multihoming problem statement draft, another draft for "multihoming usages". The problem statement draft will ... state ... all the ... problems, while the usage draft would give a priority to the scenario which are useful. I think we can agree on this way of working ? Thierry. From nemo-admin@ietf.org Thu Mar 25 01:36:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18763 for ; Thu, 25 Mar 2004 01:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OTB-0006wQ-35; Thu, 25 Mar 2004 01:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OT8-0006w5-Ah for nemo@optimus.ietf.org; Thu, 25 Mar 2004 01:35:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18753 for ; Thu, 25 Mar 2004 01:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OT5-0007Eb-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:35:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OSC-00078m-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:35:00 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6ORP-0006zp-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:34:11 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 01:33:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSMIg5UhFolsb4Rdq4aJg9baSBegAAVJRQ From: "Soliman Hesham" To: "Thierry Ernst" , "nemo" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I do understand the issue. Sorry if I repeat myself, but I=20 > would like to > try to propose the following actions. >=20 > a. May I suggest Vijay to add an issue in his list (although=20 > the spec. > is in IESG hands) ? >=20 > b. I support open and un-ambiguous standard. So: >=20 > b1. I would oppose to add in the NEMO Basic Support spec. sentences > such like: > - 2 MRs do not share the same prefix > - NEMO cannot spit > - etc >=20 > b2. To solve ambiguousness, I would rather just say in the top of the > document (a kind of disclaimer) than there is no warranty that NEMO > Basic Support works with configurations other than a single NEMO-link > attached to the Internet via one MR, i.e.: >=20 > - multihomed mobile networks (8 cases, as identified by the=20 > multihomong > problem statement, including multiple MRs) >=20 > - nested mobile networks [although it's assumed it would, but test > remains to be done - we will do it in our lab very soon] >=20 > - split mobile networks >=20 > and that necessary fixes may be done later. >=20 >=20 > So, everyone is aware that checks remains to be done, and that > additional specs. may be needed for specific configuration [e.g. a > multihoming usage doc), at least in the informational track.=20 > Does this > makes sense for everyone ? =3D> That's fine with me. >=20 > I concur to what Hesham says. Nested is when a sub-NEMO gets into a > parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO > and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated > prefix get split in 2 separate entities. =3D> Agreed. Thanks, Hesham >=20 > Thierry >=20 >=20 >=20 >=20 From exim@www1.ietf.org Thu Mar 25 01:38:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18937 for ; Thu, 25 Mar 2004 01:38:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OV3-0007Kq-OL for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 01:37:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P6bvjM028188 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 01:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OV3-0007KZ-K3 for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 01:37:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18902 for ; Thu, 25 Mar 2004 01:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OV0-0007Sl-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:37:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OU8-0007M3-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:37:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6OT9-0007FP-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 01:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OTB-0006wQ-35; Thu, 25 Mar 2004 01:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OT8-0006w5-Ah for nemo@optimus.ietf.org; Thu, 25 Mar 2004 01:35:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18753 for ; Thu, 25 Mar 2004 01:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OT5-0007Eb-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:35:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OSC-00078m-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:35:00 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6ORP-0006zp-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:34:11 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 01:33:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSMIg5UhFolsb4Rdq4aJg9baSBegAAVJRQ From: "Soliman Hesham" To: "Thierry Ernst" , "nemo" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I do understand the issue. Sorry if I repeat myself, but I=20 > would like to > try to propose the following actions. >=20 > a. May I suggest Vijay to add an issue in his list (although=20 > the spec. > is in IESG hands) ? >=20 > b. I support open and un-ambiguous standard. So: >=20 > b1. I would oppose to add in the NEMO Basic Support spec. sentences > such like: > - 2 MRs do not share the same prefix > - NEMO cannot spit > - etc >=20 > b2. To solve ambiguousness, I would rather just say in the top of the > document (a kind of disclaimer) than there is no warranty that NEMO > Basic Support works with configurations other than a single NEMO-link > attached to the Internet via one MR, i.e.: >=20 > - multihomed mobile networks (8 cases, as identified by the=20 > multihomong > problem statement, including multiple MRs) >=20 > - nested mobile networks [although it's assumed it would, but test > remains to be done - we will do it in our lab very soon] >=20 > - split mobile networks >=20 > and that necessary fixes may be done later. >=20 >=20 > So, everyone is aware that checks remains to be done, and that > additional specs. may be needed for specific configuration [e.g. a > multihoming usage doc), at least in the informational track.=20 > Does this > makes sense for everyone ? =3D> That's fine with me. >=20 > I concur to what Hesham says. Nested is when a sub-NEMO gets into a > parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO > and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated > prefix get split in 2 separate entities. =3D> Agreed. Thanks, Hesham >=20 > Thierry >=20 >=20 >=20 >=20 From nemo-admin@ietf.org Thu Mar 25 02:03:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17786 for ; Thu, 25 Mar 2004 01:15:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6O8s-0004wb-GO; Thu, 25 Mar 2004 01:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6O8q-0004vl-21 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 01:15:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17713 for ; Thu, 25 Mar 2004 01:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6O8n-0005KB-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:14:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6O7y-0005BG-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:14:07 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6O6p-0004tR-00 for nemo@ietf.org; Thu, 25 Mar 2004 01:12:55 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 715F45D165 for ; Thu, 25 Mar 2004 15:12:26 +0900 (JST) Date: Thu, 25 Mar 2004 15:12:18 +0900 From: Thierry Ernst To: nemo Message-Id: <20040325151218.5ba35925.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Terminology: split mobile networks Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Can someone draft a brief definition for split mobile networks ? I would include it in the NEMO terminology. Thanks for help. Thierry. From nemo-admin@ietf.org Thu Mar 25 03:24:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08660 for ; Thu, 25 Mar 2004 03:24:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Q9h-00089r-Ry; Thu, 25 Mar 2004 03:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Q9X-00086J-6S for nemo@optimus.ietf.org; Thu, 25 Mar 2004 03:23:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08639 for ; Thu, 25 Mar 2004 03:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Q9U-00043B-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:23:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Q8V-0003y1-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:22:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6Q7h-0003qB-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:21:57 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 00:28:46 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2P8Kssm008801; Thu, 25 Mar 2004 09:20:55 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 08:21:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2004 08:21:25 -0000 Message-ID: Thread-Topic: splitting moving networks (was: DND test) Thread-Index: AcQRzdnzGstjsPG3QwKJiYoHL/8puAAQcYowAAvuwUA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Alexandru Petrescu" , Cc: "IETF NEMO WG" X-OriginalArrivalTime: 25 Mar 2004 08:21:26.0681 (UTC) FILETIME=[2AB43090:01C41242] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: splitting moving networks (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > > I think that, first, moving networks in the NEMO sense have a rigid > > structure, they just don't separate components from one > > another, a basic > > definition. >=20 > =3D> Disagree. Where is this definition made? It would be > a big mistake to make this assumption IMHO. How can > you say that a moving network will never be divided? > If I have a PAN with 4 devices and one day I left > 2 at home and took 2 with me to work, you're saying > that this is not _meant_ to work? >=20 Yes, Hesham, exactly. It's a configuration error. It should be 2 networks. But then, they should not share an ingress link, ever. It's either load balancing in an atomic (rigid) configuration or a totally separated configuration. What you're asking for is just too difficult with the current technology, and it's not just Nemo.=20 Actually, we are very careful not to expose LFNs to other mobile networks when we do our tests, because that breaks everything. And this has to do with the way the LFNs we are using handle address autoconfiguration and SAS. I agree we should doc the results of this. Our (Nemo) policy is to write an informative usage draft that gives the status of the cans and can'ts, and that status may evolve with the overall technology... You kinda convinced me that we should start the multihoming usage draft ASAP :) Pascal From exim@www1.ietf.org Thu Mar 25 03:27:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08857 for ; Thu, 25 Mar 2004 03:27:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6QCC-00006A-Tj for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 03:26:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P8QaWG000378 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 03:26:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6QCC-000061-Jr for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 03:26:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08808 for ; Thu, 25 Mar 2004 03:26:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6QCA-0004Kp-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 03:26:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6QAn-0004Do-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 03:25:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Q9q-00046x-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 03:24:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Q9h-00089r-Ry; Thu, 25 Mar 2004 03:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Q9X-00086J-6S for nemo@optimus.ietf.org; Thu, 25 Mar 2004 03:23:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08639 for ; Thu, 25 Mar 2004 03:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Q9U-00043B-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:23:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Q8V-0003y1-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:22:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6Q7h-0003qB-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:21:57 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 00:28:46 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2P8Kssm008801; Thu, 25 Mar 2004 09:20:55 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 08:21:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2004 08:21:25 -0000 Message-ID: Thread-Topic: splitting moving networks (was: DND test) Thread-Index: AcQRzdnzGstjsPG3QwKJiYoHL/8puAAQcYowAAvuwUA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Alexandru Petrescu" , Cc: "IETF NEMO WG" X-OriginalArrivalTime: 25 Mar 2004 08:21:26.0681 (UTC) FILETIME=[2AB43090:01C41242] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: splitting moving networks (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > > I think that, first, moving networks in the NEMO sense have a rigid > > structure, they just don't separate components from one > > another, a basic > > definition. >=20 > =3D> Disagree. Where is this definition made? It would be > a big mistake to make this assumption IMHO. How can > you say that a moving network will never be divided? > If I have a PAN with 4 devices and one day I left > 2 at home and took 2 with me to work, you're saying > that this is not _meant_ to work? >=20 Yes, Hesham, exactly. It's a configuration error. It should be 2 networks. But then, they should not share an ingress link, ever. It's either load balancing in an atomic (rigid) configuration or a totally separated configuration. What you're asking for is just too difficult with the current technology, and it's not just Nemo.=20 Actually, we are very careful not to expose LFNs to other mobile networks when we do our tests, because that breaks everything. And this has to do with the way the LFNs we are using handle address autoconfiguration and SAS. I agree we should doc the results of this. Our (Nemo) policy is to write an informative usage draft that gives the status of the cans and can'ts, and that status may evolve with the overall technology... You kinda convinced me that we should start the multihoming usage draft ASAP :) Pascal From nemo-admin@ietf.org Thu Mar 25 05:02:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11970 for ; Thu, 25 Mar 2004 05:02:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rgd-0005t2-0c; Thu, 25 Mar 2004 05:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6QHQ-0000Ik-Ld for nemo@optimus.ietf.org; Thu, 25 Mar 2004 03:32:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09049 for ; Thu, 25 Mar 2004 03:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6QHO-0004qz-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:31:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6QGM-0004m4-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:30:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6QG5-0004hO-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:30:37 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 00:37:26 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2P8TXsm011234; Thu, 25 Mar 2004 09:29:35 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 08:30:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 08:30:04 -0000 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSMIg5UhFolsb4Rdq4aJg9baSBegAAVJRQAAQ3LOA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 25 Mar 2004 08:30:05.0609 (UTC) FILETIME=[60025190:01C41243] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Soliman Hesham > Sent: jeudi 25 mars 2004 07:34 > To: Thierry Ernst; nemo > Subject: RE: [nemo] RE: splitting moving networks (was: DND test) >=20 >=20 > > I do understand the issue. Sorry if I repeat myself, but I > > would like to > > try to propose the following actions. > > > > a. May I suggest Vijay to add an issue in his list (although > > the spec. > > is in IESG hands) ? > > > > b. I support open and un-ambiguous standard. So: > > > > b1. I would oppose to add in the NEMO Basic Support spec. sentences > > such like: > > - 2 MRs do not share the same prefix > > - NEMO cannot spit > > - etc > > > > b2. To solve ambiguousness, I would rather just say in the top of the > > document (a kind of disclaimer) than there is no warranty that NEMO > > Basic Support works with configurations other than a single NEMO-link > > attached to the Internet via one MR, i.e.: > > > > - multihomed mobile networks (8 cases, as identified by the > > multihomong > > problem statement, including multiple MRs) > > > > - nested mobile networks [although it's assumed it would, but test > > remains to be done - we will do it in our lab very soon] > > > > - split mobile networks > > > > and that necessary fixes may be done later. > > > > > > So, everyone is aware that checks remains to be done, and that > > additional specs. may be needed for specific configuration [e.g. a > > multihoming usage doc), at least in the informational track. > > Does this > > makes sense for everyone ? >=20 > =3D> That's fine with me. Cool :) >=20 > > > > I concur to what Hesham says. Nested is when a sub-NEMO gets into a > > parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO > > and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated > > prefix get split in 2 separate entities. >=20 > =3D> Agreed. Yes. Not that this split nemo thing is not different from a multilink subnet. Which ends up being resolved using host routes... Pascal From nemo-admin@ietf.org Thu Mar 25 05:02:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12000 for ; Thu, 25 Mar 2004 05:02:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rgz-00061X-UV; Thu, 25 Mar 2004 05:02:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Qxn-0003Lm-U4 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 04:15:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10229 for ; Thu, 25 Mar 2004 04:15:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Qxl-0000GB-00 for nemo@ietf.org; Thu, 25 Mar 2004 04:15:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Qwp-0000Cv-00 for nemo@ietf.org; Thu, 25 Mar 2004 04:14:48 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6QwS-00009a-00 for nemo@ietf.org; Thu, 25 Mar 2004 04:14:24 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2P9ETJO022979; Thu, 25 Mar 2004 02:14:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2P9EMUK032395; Thu, 25 Mar 2004 03:14:22 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id CB58085C46E; Thu, 25 Mar 2004 10:14:21 +0100 (CET) Message-ID: <4062A2E7.9050003@motorola.com> Date: Thu, 25 Mar 2004 10:14:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: Thierry Ernst , nemo Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040301010500070509040904" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms040301010500070509040904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote and cited T.E.: >> Nested is when a sub-NEMO gets into a parent-NEMO; the sub-NEMO has >> not the same prefix has the parent-NEMO and doesnt' get >> renumbered. Nestedness also happens when MH visits a moving network; it's also important to stress that the respective MR's or MH's do _not_ have the same home link. Whenever there's nested encapsulation to HA (i.e. at least two tunnels encapsulated) then there's moving networks nestedness. >> Split-NEMO is the opposite: an aggregated prefix get split in 2 >> separate entities. I really do not understand this high-level definition of an aggregated prefix that splits in two separate entities; does it separate in two separated "sub-prefixes"? What is a detailed example of such a split? Alex --------------ms040301010500070509040904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUwOTE0MTVaMCMGCSqGSIb3DQEJBDEWBBSyKsmdBx4fpmYkDnN0l4P/9HNaNjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYC56nb248Y8C6Hn/90XtcSDwQ88qB0yWu/Tg5rg WGjZ5vX9YrshEbfeuTsP+7KpHQhz+b3kXcim4jXn+ji6kxaqQ5pZmdY94YaY4vajq60YcGlN 27MF4KTIgTnuJYwBW5i5VJBgBa1FEAexA0coYt/e7elnA5AXlfFgiR+svzfK4gAAAAAAAA== --------------ms040301010500070509040904-- From exim@www1.ietf.org Thu Mar 25 05:19:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13113 for ; Thu, 25 Mar 2004 05:19:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rwv-0008HI-Am for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 05:18:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PAIvhA031819 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 05:18:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rwu-0008H8-W9 for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 05:18:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12799 for ; Thu, 25 Mar 2004 05:18:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Rwr-0006iA-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 05:18:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Run-0006BW-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 05:16:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6RtM-0005wi-01 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 05:15:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rgz-00061X-UV; Thu, 25 Mar 2004 05:02:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Qxn-0003Lm-U4 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 04:15:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10229 for ; Thu, 25 Mar 2004 04:15:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Qxl-0000GB-00 for nemo@ietf.org; Thu, 25 Mar 2004 04:15:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Qwp-0000Cv-00 for nemo@ietf.org; Thu, 25 Mar 2004 04:14:48 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6QwS-00009a-00 for nemo@ietf.org; Thu, 25 Mar 2004 04:14:24 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2P9ETJO022979; Thu, 25 Mar 2004 02:14:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2P9EMUK032395; Thu, 25 Mar 2004 03:14:22 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id CB58085C46E; Thu, 25 Mar 2004 10:14:21 +0100 (CET) Message-ID: <4062A2E7.9050003@motorola.com> Date: Thu, 25 Mar 2004 10:14:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: Thierry Ernst , nemo Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040301010500070509040904" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms040301010500070509040904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote and cited T.E.: >> Nested is when a sub-NEMO gets into a parent-NEMO; the sub-NEMO has >> not the same prefix has the parent-NEMO and doesnt' get >> renumbered. Nestedness also happens when MH visits a moving network; it's also important to stress that the respective MR's or MH's do _not_ have the same home link. Whenever there's nested encapsulation to HA (i.e. at least two tunnels encapsulated) then there's moving networks nestedness. >> Split-NEMO is the opposite: an aggregated prefix get split in 2 >> separate entities. I really do not understand this high-level definition of an aggregated prefix that splits in two separate entities; does it separate in two separated "sub-prefixes"? What is a detailed example of such a split? Alex --------------ms040301010500070509040904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUwOTE0MTVaMCMGCSqGSIb3DQEJBDEWBBSyKsmdBx4fpmYkDnN0l4P/9HNaNjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYC56nb248Y8C6Hn/90XtcSDwQ88qB0yWu/Tg5rg WGjZ5vX9YrshEbfeuTsP+7KpHQhz+b3kXcim4jXn+ji6kxaqQ5pZmdY94YaY4vajq60YcGlN 27MF4KTIgTnuJYwBW5i5VJBgBa1FEAexA0coYt/e7elnA5AXlfFgiR+svzfK4gAAAAAAAA== --------------ms040301010500070509040904-- From exim@www1.ietf.org Thu Mar 25 05:20:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13338 for ; Thu, 25 Mar 2004 05:20:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rxc-0008PG-J1 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 05:19:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PAJe8m032310 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 05:19:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rxc-0008P3-CT for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 05:19:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13198 for ; Thu, 25 Mar 2004 05:19:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6RxZ-0006qh-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 05:19:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Rvd-0006OQ-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 05:17:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6RtT-0005wa-02 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 05:15:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6Rgk-0000uU-Mp for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 05:02:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Rgd-0005t2-0c; Thu, 25 Mar 2004 05:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6QHQ-0000Ik-Ld for nemo@optimus.ietf.org; Thu, 25 Mar 2004 03:32:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09049 for ; Thu, 25 Mar 2004 03:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6QHO-0004qz-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:31:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6QGM-0004m4-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:30:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6QG5-0004hO-00 for nemo@ietf.org; Thu, 25 Mar 2004 03:30:37 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 00:37:26 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2P8TXsm011234; Thu, 25 Mar 2004 09:29:35 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 08:30:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 08:30:04 -0000 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSMIg5UhFolsb4Rdq4aJg9baSBegAAVJRQAAQ3LOA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 25 Mar 2004 08:30:05.0609 (UTC) FILETIME=[60025190:01C41243] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Soliman Hesham > Sent: jeudi 25 mars 2004 07:34 > To: Thierry Ernst; nemo > Subject: RE: [nemo] RE: splitting moving networks (was: DND test) >=20 >=20 > > I do understand the issue. Sorry if I repeat myself, but I > > would like to > > try to propose the following actions. > > > > a. May I suggest Vijay to add an issue in his list (although > > the spec. > > is in IESG hands) ? > > > > b. I support open and un-ambiguous standard. So: > > > > b1. I would oppose to add in the NEMO Basic Support spec. sentences > > such like: > > - 2 MRs do not share the same prefix > > - NEMO cannot spit > > - etc > > > > b2. To solve ambiguousness, I would rather just say in the top of the > > document (a kind of disclaimer) than there is no warranty that NEMO > > Basic Support works with configurations other than a single NEMO-link > > attached to the Internet via one MR, i.e.: > > > > - multihomed mobile networks (8 cases, as identified by the > > multihomong > > problem statement, including multiple MRs) > > > > - nested mobile networks [although it's assumed it would, but test > > remains to be done - we will do it in our lab very soon] > > > > - split mobile networks > > > > and that necessary fixes may be done later. > > > > > > So, everyone is aware that checks remains to be done, and that > > additional specs. may be needed for specific configuration [e.g. a > > multihoming usage doc), at least in the informational track. > > Does this > > makes sense for everyone ? >=20 > =3D> That's fine with me. Cool :) >=20 > > > > I concur to what Hesham says. Nested is when a sub-NEMO gets into a > > parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO > > and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated > > prefix get split in 2 separate entities. >=20 > =3D> Agreed. Yes. Not that this split nemo thing is not different from a multilink subnet. Which ends up being resolved using host routes... Pascal From nemo-admin@ietf.org Thu Mar 25 09:09:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21511 for ; Thu, 25 Mar 2004 09:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXM-0006U0-Hh; Thu, 25 Mar 2004 09:08:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6SZX-0001t1-O7 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 05:58:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14614 for ; Thu, 25 Mar 2004 05:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6SZU-0002wq-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:58:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SYV-0002qZ-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:57:47 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6SXY-0002hz-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:56:48 -0500 content-class: urn:content-classes:message Date: Thu, 25 Mar 2004 05:56:20 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: splitting moving networks (was: DND test) Thread-Index: AcQSQi1tuNtZeCl2TlC1JWCAZ3ztVQAE+DaQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" , Cc: "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: splitting moving networks (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> Disagree. Where is this definition made? It would be > > a big mistake to make this assumption IMHO. How can > > you say that a moving network will never be divided? > > If I have a PAN with 4 devices and one day I left > > 2 at home and took 2 with me to work, you're saying > > that this is not _meant_ to work? > >=20 > Yes, Hesham, exactly. It's a configuration error. It should be 2 > networks. But then, they should not share an ingress link, ever.=20 =3D> You're trying to get users to understand nemo I think! It won't work. People should go away with whatever devices they want and things should just work. This scenario is based on real life it's not a configuration error. It's > either load balancing in an atomic (rigid) configuration or a totally > separated configuration. What you're asking for is just too difficult > with the current technology, and it's not just Nemo.=20 =3D> I know it's not working today, but it can be made to work. I've also stated countless times that it's not nemo specific. It doesn't mean it's not solveable... > Actually, we are very careful not to expose LFNs to other mobile > networks when we do our tests, because that breaks=20 > everything.=20 =3D> Good luck ;) Tell that to a user: Your CD player can't=20 access the Internet reliably when your phone and laptop are both connected.... > You kinda convinced me that we should start the multihoming=20 > usage draft > ASAP :) =3D> I hope the useage draft considers real useage scenarios and is not limited to ships, planes ...etc.=20 Hesham >=20 > Pascal >=20 From nemo-admin@ietf.org Thu Mar 25 09:09:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21512 for ; Thu, 25 Mar 2004 09:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXR-0006WP-5D; Thu, 25 Mar 2004 09:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ScY-0002Dv-L7 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 06:01:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14757 for ; Thu, 25 Mar 2004 06:01:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ScU-0003Hr-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:01:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Sba-0003B1-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:00:59 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6Sac-000344-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:59:58 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PB04JO020237; Thu, 25 Mar 2004 04:00:05 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i2PAuglH002934; Thu, 25 Mar 2004 04:56:43 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 57EA8855530; Thu, 25 Mar 2004 11:56:42 +0100 (CET) Message-ID: <4062BAEA.2090905@motorola.com> Date: Thu, 25 Mar 2004 11:56:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: Thierry Ernst , nemo References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050601090905090403020303" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] Re: email style (was: splitting moving networks) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms050601090905090403020303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > Alex, you seem to be responding to me, I didn't write > this. Although I agree with Thierry's description. Hesham, correct, you didn't write this, you've cited it. That's what I've said: "Soliman Hesham wrote and cited T.E.". In emails, ">" means that somebody cited somebody (first-level citation) while ">>" means a 2nd level citation. What does "=>" mean? Alex > > Soliman Hesham wrote and cited T.E.: > > >> Nested is when a sub-NEMO gets into a parent-NEMO; the > > sub-NEMO has > > >> not the same prefix has the parent-NEMO and doesnt' get > > >> renumbered. > > > > Nestedness also happens when MH visits a moving network; it's also > > important to stress that the respective MR's or MH's do > > _not_ have the > > same home link. > > > > Whenever there's nested encapsulation to HA (i.e. at least > > two tunnels > > encapsulated) then there's moving networks nestedness. > > > > >> Split-NEMO is the opposite: an aggregated prefix get split in 2 > > >> separate entities. > > > > I really do not understand this high-level definition of an > > aggregated > > prefix that splits in two separate entities; does it separate in two > > separated "sub-prefixes"? What is a detailed example of > > such a split? > > > > Alex > > > > --------------ms050601090905090403020303 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMDU2NDJaMCMGCSqGSIb3DQEJBDEWBBRZHrgQzxA1mhBfeDJXh6peTM2xYzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYB52cYlGnP1gaYBgKIU8HfK+knbCwv1OE5400bT 2ihCLUXfr8Bgwt78QDeGexCO3Ks+zDXMT3LHK9nFEU8Q18mN/VIX3PTF9OI55G7sNCYo8iTI kkDGtN64iIQXje8RzD4MEv0iDMPgCsoLfHjITa6FbPWs1UGM532EfY2BACb7UwAAAAAAAA== --------------ms050601090905090403020303-- From nemo-admin@ietf.org Thu Mar 25 09:09:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21619 for ; Thu, 25 Mar 2004 09:09:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXY-0006cq-Se; Thu, 25 Mar 2004 09:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Szi-00048g-O1 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 06:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15383 for ; Thu, 25 Mar 2004 06:25:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Sze-0005K0-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Sym-0005F4-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:24:57 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Sxp-00056a-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:23:57 -0500 content-class: urn:content-classes:message Date: Thu, 25 Mar 2004 06:23:29 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: email style (was: splitting moving networks) Thread-Index: AcQSWFFMgf+g9k8fSw+tewqruHvv9wAAe5sA From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Thierry Ernst" , "nemo" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: email style (was: splitting moving networks) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Hesham, correct, you didn't write this, you've cited it. =20 > That's what=20 > I've said: "Soliman Hesham wrote and cited T.E.". =3D> I didn't write any of the text in the email. So perhaps you shouldn't put me in the "To" field. If I'm in=20 that field I assume that someone is replying to me. > In emails, ">" means that somebody cited somebody=20 > (first-level citation)=20 > while ">>" means a 2nd level citation. What does "=3D>" mean? =3D> It means it's my comment Hesham >=20 > Alex >=20 > > > Soliman Hesham wrote and cited T.E.: > > > >> Nested is when a sub-NEMO gets into a parent-NEMO; the=20 > > > sub-NEMO has > > > >> not the same prefix has the parent-NEMO and doesnt' get > > > >> renumbered. > > >=20 > > > Nestedness also happens when MH visits a moving=20 > network; it's also=20 > > > important to stress that the respective MR's or MH's do=20 > > > _not_ have the=20 > > > same home link. > > >=20 > > > Whenever there's nested encapsulation to HA (i.e. at least=20 > > > two tunnels > > > encapsulated) then there's moving networks nestedness. > > >=20 > > > >> Split-NEMO is the opposite: an aggregated prefix get=20 > split in 2=20 > > > >> separate entities. > > >=20 > > > I really do not understand this high-level definition of an=20 > > > aggregated > > > prefix that splits in two separate entities; does it=20 > separate in two > > > separated "sub-prefixes"? What is a detailed example of=20 > > > such a split? > > >=20 > > > Alex > > >=20 > > >=20 >=20 >=20 From nemo-admin@ietf.org Thu Mar 25 09:09:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21636 for ; Thu, 25 Mar 2004 09:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXb-0006e7-9G; Thu, 25 Mar 2004 09:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6T4c-0004Js-W6 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 06:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15510 for ; Thu, 25 Mar 2004 06:30:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6T4Z-0005jz-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:30:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6T3c-0005ez-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:29:57 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6T2h-0005Vs-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:28:59 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 71C541BD36; Thu, 25 Mar 2004 12:28:26 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 5BEE91B73D; Thu, 25 Mar 2004 12:28:26 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Date: Thu, 25 Mar 2004 12:25:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4061CE5B.5000403@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > indeed. That is the type of solution that you would have in a fixed > > subnetwork with multiple routers connecting to the site. That is what > > the IGPs are designed to do so that is the tool. > > I think IGP can be used between HA's and MR even when MR is not at home, > because MR still belongs to the home domain (through the tunnels), so > the I in IGP is still valid. Yes, i agree with you. > > > Two issues here: > > > > First, how to handle the split network problem that Hesham is > > considering? When the network splits, one of the MR should stop > > advertising the nemo prefix, i guess, so some setting for this should > > be required. > > "Split network problem" could you please formalize somehow? Do you mean > a moving network nesting under another moving network and then > separating? What exactly is "split network"? I've read most of > Hesham's emails attentively, but can't remember it. Maybe a separate > message with subject line saying "split network problem" will help me. next mesages... > > > Second, this is a general nemo issue about security when using IGPs > > in a nemo environment, do you think that it is acceptable to run an > > IGP between the MR and the HA? > > I think there is no major security issue in using IGP in a NEMO > environment as long as that IGP is used between MR and HA's and over the > MR-HA tunnels. Well, the point here is to make sure that the MR only announces the prefixes that it is allowed too, and does not tries to hijack the traffic from other prefixes. This is general concern for routing protocol security, but perhaps in this case is a bit more real. I guess that you can fix that by imposing the HA to inspect all the announcements of the MR to verify that it only announces what it is allowed. This is at least more load to the HA. But the bottom line is that you not really needing an IGP here, since you don't want to discover the topology. The announced prefixes are only those that are allowed. What you want is a mechanisms to detect failures. Perhaps there are simpler options and more effective, like draft-katz-ward-bfd-00.txtto (or just a ping) to do this. OTOH, i think that IGP seems like a good option when the same prefix is reachable through two HA. You can use IGP and the metrics to select which HA and also to balance traffic. So, summarizing, there are two applications of the IGP: - HA-MR failure detection - Selection among different HAs in the home network. I'm definitely not proposing to have MR to have direct > IGP interactions with the other IGP that might happen to run in the > visited domain (e.g. I'm _not_ proposing MR to do IGP with AR). agree. Regards, marcelo > > No? > > Alex > From nemo-admin@ietf.org Thu Mar 25 09:09:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21670 for ; Thu, 25 Mar 2004 09:09:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXe-0006h5-PD; Thu, 25 Mar 2004 09:09:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6TCM-0004rx-Pu for nemo@optimus.ietf.org; Thu, 25 Mar 2004 06:38:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15712 for ; Thu, 25 Mar 2004 06:38:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6TCI-0006Ry-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:38:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6TBI-0006Nj-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:37:53 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B6TAc-0006Jc-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:37:10 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i2PBb6po007082; Thu, 25 Mar 2004 04:37:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i2PBXBPK022194; Thu, 25 Mar 2004 05:33:12 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2501B85C46E; Thu, 25 Mar 2004 12:37:05 +0100 (CET) Message-ID: <4062C45A.2000606@motorola.com> Date: Thu, 25 Mar 2004 12:36:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: Thierry Ernst , nemo References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070006060505000706020806" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] Re: email style (was: splitting moving networks) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms070006060505000706020806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > >> Hesham, correct, you didn't write this, you've cited it. That's >> what I've said: "Soliman Hesham wrote and cited T.E.". > > => I didn't write any of the text in the email. => You included the "Yes" to which I do not agree; me saying this explicitly is more convenient to you? I thought it is enough for me to just say _why_ I don't agree. > So perhaps you shouldn't put me in the "To" field. If I'm in that > field I assume that someone is replying to me. => So I must say that was an error on my part, putting you in the "To" field while actually replying to T.E., sorry. Next time I'll put you in the Cc field when I'm talking to somebody else. >> In emails, ">" means that somebody cited somebody (first-level >> citation) while ">>" means a 2nd level citation. What does "=>" >> mean? > > => It means it's my comment => Great, can I use it too? Alex --------------ms070006060505000706020806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMTM2NThaMCMGCSqGSIb3DQEJBDEWBBSoVjUn1tpOfw0JdM2ZYvz3nMdnATBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCDIcYpdzZCUrp6owA/3kRhgQDFhwk9/u9y+S9v 64QOt96IOyd8Z7n9MKk09lpnfHhZgBQvcEjgU32Q+Gc38q7IrrEYKXgUXnAYz6xxvrKpvaQT 9K3gMU425+enD3RcG6CYj/PxBktephZqB6/jm1NUkfXf9c3Znppn4oSJc8V7KQAAAAAAAA== --------------ms070006060505000706020806-- From nemo-admin@ietf.org Thu Mar 25 09:11:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22022 for ; Thu, 25 Mar 2004 09:11:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZI-0007aT-Uc; Thu, 25 Mar 2004 09:10:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6UCV-0000yK-Tl for nemo@optimus.ietf.org; Thu, 25 Mar 2004 07:43:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17925 for ; Thu, 25 Mar 2004 07:43:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6UCV-0005Ad-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:43:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6UBV-00054Q-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:42:10 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6UB4-0004yM-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:41:42 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PCfhJO016836; Thu, 25 Mar 2004 05:41:43 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2PCfaUK030677; Thu, 25 Mar 2004 06:41:36 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6CB9985C46E; Thu, 25 Mar 2004 13:41:35 +0100 (CET) Message-ID: <4062D378.7020100@motorola.com> Date: Thu, 25 Mar 2004 13:41:28 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020606000501090602020106" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms020606000501090602020106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> I think there is no major security issue in using IGP in a NEMO >> environment as long as that IGP is used between MR and HA's and >> over the MR-HA tunnels. > > Well, the point here is to make sure that the MR only announces the > prefixes that it is allowed too, and does not tries to hijack the > traffic from other prefixes. Ok. > This is general concern for routing protocol security, but perhaps in > this case is a bit more real. I guess that you can fix that by > imposing the HA to inspect all the announcements of the MR to verify > that it only announces what it is allowed. The HA inspecting all announcements of the MR, and comparing to the routes it itself owns about MR (probably introduced by admin in an existing config file and routing table) is one way of checking. For NEMO, another way of checking is the NEMO-specified Prefix Table at HA where the Prefix Table is actually a new structure but which is most probably filled by the same admin. > This is at least more load to the HA. But the bottom line is that you > not really needing an IGP here, since you don't want to discover the > topology. I think IGP or EGP or any routing protocol is not only used for topology discovery but most importantly for route maintenance when links fail. But this is of course a matter of interpretation. > What you want is a mechanisms to detect failures. Perhaps there are > simpler options and more effective, like draft-katz-ward-bfd-00.txt I just can't find it, neither 01 nor 02, nor 03, is it an RFC. I have an idea about how route failures are detected in OSPF and RIP (various flavors) and I think they can be used with the NEMO base support. > (or just a ping) to do this. OTOH, i think that IGP seems like a good > option when the same prefix is reachable through two HA. You can use > IGP and the metrics to select which HA and also to balance traffic. > > So, summarizing, there are two applications of the IGP: - HA-MR > failure detection - Selection among different HAs in the home > network. I guess so. So coming back to the NEMO multi-homing-related problem, where is the IGP _not_ sufficient? Alex --------------ms020606000501090602020106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMjQxMjhaMCMGCSqGSIb3DQEJBDEWBBQu+s9X9tcg7lwCsg5uQBxPXu/dkDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBPCqirezGfx7i2eIyW7Z5tAIJAN+TnS1KNn5uy GHLVoxrkaWyQscEXPJvh4VTsSY0Ae6tItQo4vgE/j+y0OnJqBnOCtq8eSET+akxclTzww8r2 /jf5S27gVi+KtjA1Db1x6vUWYS5XDyGhmXkcHipghHKjUZ9ikQErGg28wNwiDAAAAAAAAA== --------------ms020606000501090602020106-- From nemo-admin@ietf.org Thu Mar 25 09:11:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22054 for ; Thu, 25 Mar 2004 09:11:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZO-0007f6-CH; Thu, 25 Mar 2004 09:10:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6UOo-0001TI-G1 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 07:55:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18391 for ; Thu, 25 Mar 2004 07:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6UOn-0006PX-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6UNq-0006Jn-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:54:54 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6UMu-0006AT-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:53:56 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 05:00:42 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PCqgss008438; Thu, 25 Mar 2004 13:52:47 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 12:53:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 12:53:17 -0000 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSVimLZ4pBRkhrQimdEE4kYX7kRgAEJrsw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , , "IETF NEMO WG" X-OriginalArrivalTime: 25 Mar 2004 12:53:18.0373 (UTC) FILETIME=[253ADD50:01C41268] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Pascal Thubert (pthubert) wrote: > >> > I think that, first, moving networks in the NEMO sense have a rigid > >> > structure, they just don't separate components from one > >> > another, a basic > >> > definition. > >> > >>=3D> Disagree. Where is this definition made? It would be > >>a big mistake to make this assumption IMHO. How can > >>you say that a moving network will never be divided? > >>If I have a PAN with 4 devices and one day I left > >>2 at home and took 2 with me to work, you're saying > >>that this is not _meant_ to work? > >> > > > > Yes, Hesham, exactly. It's a configuration error. It should be 2 > > networks. But then, they should not share an ingress link, ever. It's > > either load balancing in an atomic (rigid) configuration or a totally > > separated configuration. What you're asking for is just too difficult > > with the current technology, and it's not just Nemo. >=20 > Pascal, I did not see any specific requirement from Hesham about how the > moving network actually splits; it's just "I leave two devices at home > and take two with me". That is not enough. If one really wants to see > how NEMO would work in this too-high-level scenario, and depict the > BU/BAck message exchanges and the tunnels, then one should be a little > bit more detailed on how the network actually splits. >=20 > I've tried to interpret more on what Hesham meant, drawed some diagrams > here that respect the split net Hesham's scenario and I think NEMO > Base Protocol works. But I'm not sure exactly what Hesham meant exactly. >=20 > So, Hesham, could you please be more explicit on exactly you see that > split moving network scenario? Where are the home agents? Does your > house host a home link? Are all devices LFN's or can they be MH's? > What moves and in what order. >=20 General Agreement here... Seems that Hesham wants a multilink subnet to work by magic. Like you, I wish to see use cases, maybe in the multihoming draft. There is a lack of crispness in all this.=20 I agree that Nemo basic support does not guarantee any multihoming scenario to work. Also that Nemo basic support voluntarily does not put in place any artifact that would prevent them in the future when the necessary technology is in place. I believe that's what it was meant to do. Pascal From nemo-admin@ietf.org Thu Mar 25 09:11:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22144 for ; Thu, 25 Mar 2004 09:11:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZg-0007p6-07; Thu, 25 Mar 2004 09:11:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6UnC-00032X-EI for nemo@optimus.ietf.org; Thu, 25 Mar 2004 08:21:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19426 for ; Thu, 25 Mar 2004 08:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6UnB-0000vv-00 for nemo@ietf.org; Thu, 25 Mar 2004 08:21:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6UmJ-0000pU-00 for nemo@ietf.org; Thu, 25 Mar 2004 08:20:12 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6UlQ-0000cN-00 for nemo@ietf.org; Thu, 25 Mar 2004 08:19:16 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 08:18:32 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSaCZz8I1Mfvh9SxiIS8ruE+x7xQAAYtKg From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" Cc: , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > General Agreement here... Seems that Hesham wants a=20 > multilink subnet to > work by magic.=20 =3D> Just to be sure I'm not being misquoted here.... This has _nothing_ to do with the scenarios I mentioned. I don't know what you call multilink subnet but that term,=20 to me, refers to something like the ND proxy that implements something similar to a spanning tree on L2/2.5.=20 If that's what you mean I have no idea how you concluded it from my scenario. Like you, I wish to see use cases, maybe in the > multihoming draft. There is a lack of crispness in all this.=20 =3D> The scenarios draft can help. The basic idea is to=20 that a network containing more than one MR, providing=20 access to the Internet, could be split (one MR goes=20 away with or without other MNNs/LFNs). After the split,=20 communication should be possible in both "halves". Note that=20 I haven't placed any requirements on connection survival or=20 failure detection...etc=20 Hesham From exim@www1.ietf.org Thu Mar 25 09:11:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22229 for ; Thu, 25 Mar 2004 09:11:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZj-0007s7-GB for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEBD2j030245 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZg-0007ri-PF for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:11:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21935 for ; Thu, 25 Mar 2004 09:11:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZe-0006Tk-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:11:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VYU-0006Dz-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VXU-0005zu-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:08:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXI-0006Px-31; Thu, 25 Mar 2004 09:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6SN4-0001E6-QX for nemo@optimus.ietf.org; Thu, 25 Mar 2004 05:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14267 for ; Thu, 25 Mar 2004 05:45:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6SN1-0001iE-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:45:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SM7-0001dT-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:45:00 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6SLP-0001YG-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:44:15 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PAiJJO029751; Thu, 25 Mar 2004 03:44:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2PAiBUK002831; Thu, 25 Mar 2004 04:44:12 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6D6D585C46E; Thu, 25 Mar 2004 11:44:11 +0100 (CET) Message-ID: <4062B7FA.7080203@motorola.com> Date: Thu, 25 Mar 2004 11:44:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Soliman Hesham , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040104030803070900060902" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms040104030803070900060902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> > I think that, first, moving networks in the NEMO sense have a rigid >> > structure, they just don't separate components from one >> > another, a basic >> > definition. >> >>=> Disagree. Where is this definition made? It would be >>a big mistake to make this assumption IMHO. How can >>you say that a moving network will never be divided? >>If I have a PAN with 4 devices and one day I left >>2 at home and took 2 with me to work, you're saying >>that this is not _meant_ to work? >> > > Yes, Hesham, exactly. It's a configuration error. It should be 2 > networks. But then, they should not share an ingress link, ever. It's > either load balancing in an atomic (rigid) configuration or a totally > separated configuration. What you're asking for is just too difficult > with the current technology, and it's not just Nemo. Pascal, I did not see any specific requirement from Hesham about how the moving network actually splits; it's just "I leave two devices at home and take two with me". That is not enough. If one really wants to see how NEMO would work in this too-high-level scenario, and depict the BU/BAck message exchanges and the tunnels, then one should be a little bit more detailed on how the network actually splits. I've tried to interpret more on what Hesham meant, drawed some diagrams here that respect the split net Hesham's scenario and I think NEMO Base Protocol works. But I'm not sure exactly what Hesham meant exactly. So, Hesham, could you please be more explicit on exactly you see that split moving network scenario? Where are the home agents? Does your house host a home link? Are all devices LFN's or can they be MH's? What moves and in what order. Alex --------------ms040104030803070900060902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMDQ0MTBaMCMGCSqGSIb3DQEJBDEWBBSM36WyvaBqB/bLtlqORCqXln3NLzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCfl/QGz/0qJMKyumz7rjVOGt9wuyHdZwuzMx7u MGHmFuk+PNOIsbIXaugjUWEnPRuIdef6/IhxIKnvs1E2ZUCW9+RbVHGfnxh7zbXnZK/u65Pe Q/O+jy+djtWy5GlKwmX0QGfKzX2IcHYSm1JkgC8LBzEvkuN8gSk7hQjJXumYgAAAAAAAAA== --------------ms040104030803070900060902-- From exim@www1.ietf.org Thu Mar 25 09:11:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22249 for ; Thu, 25 Mar 2004 09:11:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZq-0007uH-P3 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEBJpY030362 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZm-0007tK-Iq for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:11:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22013 for ; Thu, 25 Mar 2004 09:11:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZk-0006Uc-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:11:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VYd-0006FY-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VXb-00062z-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXY-0006cq-Se; Thu, 25 Mar 2004 09:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Szi-00048g-O1 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 06:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15383 for ; Thu, 25 Mar 2004 06:25:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Sze-0005K0-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Sym-0005F4-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:24:57 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Sxp-00056a-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:23:57 -0500 content-class: urn:content-classes:message Date: Thu, 25 Mar 2004 06:23:29 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: email style (was: splitting moving networks) Thread-Index: AcQSWFFMgf+g9k8fSw+tewqruHvv9wAAe5sA From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Thierry Ernst" , "nemo" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: email style (was: splitting moving networks) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Hesham, correct, you didn't write this, you've cited it. =20 > That's what=20 > I've said: "Soliman Hesham wrote and cited T.E.". =3D> I didn't write any of the text in the email. So perhaps you shouldn't put me in the "To" field. If I'm in=20 that field I assume that someone is replying to me. > In emails, ">" means that somebody cited somebody=20 > (first-level citation)=20 > while ">>" means a 2nd level citation. What does "=3D>" mean? =3D> It means it's my comment Hesham >=20 > Alex >=20 > > > Soliman Hesham wrote and cited T.E.: > > > >> Nested is when a sub-NEMO gets into a parent-NEMO; the=20 > > > sub-NEMO has > > > >> not the same prefix has the parent-NEMO and doesnt' get > > > >> renumbered. > > >=20 > > > Nestedness also happens when MH visits a moving=20 > network; it's also=20 > > > important to stress that the respective MR's or MH's do=20 > > > _not_ have the=20 > > > same home link. > > >=20 > > > Whenever there's nested encapsulation to HA (i.e. at least=20 > > > two tunnels > > > encapsulated) then there's moving networks nestedness. > > >=20 > > > >> Split-NEMO is the opposite: an aggregated prefix get=20 > split in 2=20 > > > >> separate entities. > > >=20 > > > I really do not understand this high-level definition of an=20 > > > aggregated > > > prefix that splits in two separate entities; does it=20 > separate in two > > > separated "sub-prefixes"? What is a detailed example of=20 > > > such a split? > > >=20 > > > Alex > > >=20 > > >=20 >=20 >=20 From exim@www1.ietf.org Thu Mar 25 09:12:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22362 for ; Thu, 25 Mar 2004 09:12:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaI-0008CM-Qb for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEBopv031490 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaI-0008BQ-7r for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:11:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22210 for ; Thu, 25 Mar 2004 09:11:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VaG-0006aW-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:11:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VZ1-0006Js-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VXo-000606-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXR-0006WP-5D; Thu, 25 Mar 2004 09:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ScY-0002Dv-L7 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 06:01:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14757 for ; Thu, 25 Mar 2004 06:01:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ScU-0003Hr-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:01:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Sba-0003B1-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:00:59 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6Sac-000344-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:59:58 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PB04JO020237; Thu, 25 Mar 2004 04:00:05 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i2PAuglH002934; Thu, 25 Mar 2004 04:56:43 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 57EA8855530; Thu, 25 Mar 2004 11:56:42 +0100 (CET) Message-ID: <4062BAEA.2090905@motorola.com> Date: Thu, 25 Mar 2004 11:56:42 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: Thierry Ernst , nemo References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050601090905090403020303" Subject: [nemo] Re: email style (was: splitting moving networks) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms050601090905090403020303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > Alex, you seem to be responding to me, I didn't write > this. Although I agree with Thierry's description. Hesham, correct, you didn't write this, you've cited it. That's what I've said: "Soliman Hesham wrote and cited T.E.". In emails, ">" means that somebody cited somebody (first-level citation) while ">>" means a 2nd level citation. What does "=>" mean? Alex > > Soliman Hesham wrote and cited T.E.: > > >> Nested is when a sub-NEMO gets into a parent-NEMO; the > > sub-NEMO has > > >> not the same prefix has the parent-NEMO and doesnt' get > > >> renumbered. > > > > Nestedness also happens when MH visits a moving network; it's also > > important to stress that the respective MR's or MH's do > > _not_ have the > > same home link. > > > > Whenever there's nested encapsulation to HA (i.e. at least > > two tunnels > > encapsulated) then there's moving networks nestedness. > > > > >> Split-NEMO is the opposite: an aggregated prefix get split in 2 > > >> separate entities. > > > > I really do not understand this high-level definition of an > > aggregated > > prefix that splits in two separate entities; does it separate in two > > separated "sub-prefixes"? What is a detailed example of > > such a split? > > > > Alex > > > > --------------ms050601090905090403020303 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMDU2NDJaMCMGCSqGSIb3DQEJBDEWBBRZHrgQzxA1mhBfeDJXh6peTM2xYzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYB52cYlGnP1gaYBgKIU8HfK+knbCwv1OE5400bT 2ihCLUXfr8Bgwt78QDeGexCO3Ks+zDXMT3LHK9nFEU8Q18mN/VIX3PTF9OI55G7sNCYo8iTI kkDGtN64iIQXje8RzD4MEv0iDMPgCsoLfHjITa6FbPWs1UGM532EfY2BACb7UwAAAAAAAA== --------------ms050601090905090403020303-- From exim@www1.ietf.org Thu Mar 25 09:12:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22368 for ; Thu, 25 Mar 2004 09:12:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaI-0008CL-PU for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEBojF031488 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaI-0008BP-6d for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:11:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22205 for ; Thu, 25 Mar 2004 09:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VaF-0006aR-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:11:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VZ0-0006Jh-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VXo-0005zw-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXF-0006OP-1l; Thu, 25 Mar 2004 09:08:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6SBU-0000XL-BR for nemo@optimus.ietf.org; Thu, 25 Mar 2004 05:34:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13910 for ; Thu, 25 Mar 2004 05:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6SBQ-0000eI-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:33:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SAX-0000ZN-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:33:02 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6SAB-0000UH-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:32:39 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PAWfJO014384; Thu, 25 Mar 2004 03:32:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i2PAVIGr019300; Thu, 25 Mar 2004 04:31:19 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2200785C46E; Thu, 25 Mar 2004 11:32:31 +0100 (CET) Message-ID: <4062B53B.5080200@motorola.com> Date: Thu, 25 Mar 2004 11:32:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: mbagnulo@ing.uc3m.es, "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010806000906040605040004" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms010806000906040605040004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: >> I think that, first, moving networks in the NEMO sense have a rigid >> structure, they just don't separate components from one another, a >> basic definition. > > => Disagree. Where is this definition made? In the terminology draft. > It would be a big mistake to make this assumption IMHO. IMHO it is a good fixed point on which we can use all sorts of levers. > How can you say that a moving network will never be divided? Just assume it; it's like assuming that there will always be a cable on which to communicate; if there's no such cable then there's no communication possible at all. > If I have a PAN with 4 devices and one day I left 2 at home and took > 2 with me to work, you're saying that this is not _meant_ to work? It _is_ meant to work. Just make sure you take the device with the MR sticker with you :-) I mean, if out of those four devices one is MR all three others are LFN's, then leaving two LFN's at home will not stop the other LFN to work just fine when behind the MR. Also, if the three LFN's are in fact MH's then again it is possible to leave two MH's at home (in this case they'll actually visit MR's home link) and have the other MH stay at its home (in the MR's ingress link) while you're taking the MR and this latter MH with you. There's no NEMO communication problem, there's no nestedness, there's no multi-homing and there's no splitting in all this (as long as all entities stay connected). >> I think second that the NEMO context has a kind of support of >> "splitting" which is in fact called "nesting" and which is >> supported by a good understanding about how it works. A PAN can >> enter a train entering a ferry and all works; all works also >> whenever the PAN gets off the train (splitting?) and into the >> ferry, or when the train gets off and the PAN back or similar. > > => This is very different from what we're discussing, nesting is > fine. Alex --------------ms010806000906040605040004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMDMyMjdaMCMGCSqGSIb3DQEJBDEWBBQvOwm+TmGCxROlER3GvPFRhvyrozBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDNKBfVBtSJLnGdBk+CWPFS+uee/3k/R2pEbIhg 97nifGOhtlVcMkYjDQpSbcWnOJwlxZU6h9dtOkfRkdTnerKMMHEWS4F3+YQ7QmXLhZqh2ZLP 8Rdl2p1URvQw7Ybq+3G+z/ZkIti9t3K/8ciyjgG4lUYloSYQTLPbMa6B1ZXNkQAAAAAAAA== --------------ms010806000906040605040004-- From nemo-admin@ietf.org Thu Mar 25 09:12:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22420 for ; Thu, 25 Mar 2004 09:12:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaQ-0008GP-DQ; Thu, 25 Mar 2004 09:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VTm-0005mf-9s for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21285 for ; Thu, 25 Mar 2004 09:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VTk-0005eZ-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:05:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VSo-0005YU-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:04:07 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6VS3-0005Np-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:03:20 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 06:10:11 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PE2Bsk002894; Thu, 25 Mar 2004 15:02:16 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 14:02:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 14:02:41 -0000 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSaCZz8I1Mfvh9SxiIS8ruE+x7xQAAYtKgAAGg0zA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Alexandru Petrescu" Cc: , "IETF NEMO WG" X-OriginalArrivalTime: 25 Mar 2004 14:02:43.0183 (UTC) FILETIME=[D7A66FF0:01C41271] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > General Agreement here... Seems that Hesham wants a > > multilink subnet to > > work by magic. >=20 > =3D> Just to be sure I'm not being misquoted here.... > This has _nothing_ to do with the scenarios I mentioned. > I don't know what you call multilink subnet but that term, > to me, refers to something like the ND proxy that implements > something similar to a spanning tree on L2/2.5. > If that's what you mean I have no idea how you concluded > it from my scenario. Well, I concluded that because you have a link with a number of devices on it, and 2 MRs. And then, you split the link, one MR stays, one MR goes, some LFNs stay and some LFNs go. The subnet has been split over 2 links.=20 This can be resolved in a number of way, including host routes at the HA. But this is out of scope for nemo basic. The link and every node that has a fixed address on it stick together.=20 > Like you, I wish to see use cases, maybe in the > > multihoming draft. There is a lack of crispness in all this. >=20 > =3D> The scenarios draft can help. The basic idea is to > that a network containing more than one MR, providing > access to the Internet, could be split (one MR goes > away with or without other MNNs/LFNs). After the split, > communication should be possible in both "halves". Note that > I haven't placed any requirements on connection survival or > failure detection...etc >=20 I'm not sure we considered that level of complexity already. Seems to me it's a new scenario to add and which validity has to be debated, for example based on practical use cases. Pascal From exim@www1.ietf.org Thu Mar 25 09:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22399 for ; Thu, 25 Mar 2004 09:12:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaJ-0008Cr-Rs for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEBpCD031538 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaJ-0008CY-7a for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:11:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22215 for ; Thu, 25 Mar 2004 09:11:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VaH-0006an-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:11:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VZ2-0006K3-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VXo-000608-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXM-0006U0-Hh; Thu, 25 Mar 2004 09:08:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6SZX-0001t1-O7 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 05:58:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14614 for ; Thu, 25 Mar 2004 05:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6SZU-0002wq-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:58:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SYV-0002qZ-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:57:47 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6SXY-0002hz-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:56:48 -0500 content-class: urn:content-classes:message Date: Thu, 25 Mar 2004 05:56:20 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: splitting moving networks (was: DND test) Thread-Index: AcQSQi1tuNtZeCl2TlC1JWCAZ3ztVQAE+DaQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" , Cc: "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: splitting moving networks (was: DND test) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> Disagree. Where is this definition made? It would be > > a big mistake to make this assumption IMHO. How can > > you say that a moving network will never be divided? > > If I have a PAN with 4 devices and one day I left > > 2 at home and took 2 with me to work, you're saying > > that this is not _meant_ to work? > >=20 > Yes, Hesham, exactly. It's a configuration error. It should be 2 > networks. But then, they should not share an ingress link, ever.=20 =3D> You're trying to get users to understand nemo I think! It won't work. People should go away with whatever devices they want and things should just work. This scenario is based on real life it's not a configuration error. It's > either load balancing in an atomic (rigid) configuration or a totally > separated configuration. What you're asking for is just too difficult > with the current technology, and it's not just Nemo.=20 =3D> I know it's not working today, but it can be made to work. I've also stated countless times that it's not nemo specific. It doesn't mean it's not solveable... > Actually, we are very careful not to expose LFNs to other mobile > networks when we do our tests, because that breaks=20 > everything.=20 =3D> Good luck ;) Tell that to a user: Your CD player can't=20 access the Internet reliably when your phone and laptop are both connected.... > You kinda convinced me that we should start the multihoming=20 > usage draft > ASAP :) =3D> I hope the useage draft considers real useage scenarios and is not limited to ships, planes ...etc.=20 Hesham >=20 > Pascal >=20 From nemo-admin@ietf.org Thu Mar 25 09:12:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22419 for ; Thu, 25 Mar 2004 09:12:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaL-0008Dh-V0; Thu, 25 Mar 2004 09:11:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VRq-0005cv-8Q for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:03:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21230 for ; Thu, 25 Mar 2004 09:03:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VRn-0005SU-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:03:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VQt-0005Nc-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:02:07 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6VQO-0005IS-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:01:36 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PE1ZJO003414; Thu, 25 Mar 2004 07:01:35 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i2PE1GjF022441; Thu, 25 Mar 2004 08:01:17 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4D99485C46E; Thu, 25 Mar 2004 15:01:16 +0100 (CET) Message-ID: <4062E625.4070806@motorola.com> Date: Thu, 25 Mar 2004 15:01:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Pascal Thubert (pthubert)" , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090204040704070702010503" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms090204040704070702010503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > The basic idea is to that a network containing more than one MR, > providing access to the Internet, could be split (one MR goes away > with or without other MNNs/LFNs). After the split, communication > should be possible in both "halves". Note that I haven't placed any > requirements on connection survival or failure detection...etc Hesham, please just say how many MR's exactly (instead of "more than one MR") and how many and what kinds of interfaces. Please say "with other LFN's" instead of "with or without other MNN's/LFN's". If I know all this, I can draw an example of how the NEMO Base Spec supports it; maybe we can even find out that "splitting" is indeed a problem. > => The scenarios draft can help. Which scenarios draft? Which of these: http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-requirements-02.txt http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-terminology-01.txt http://www.mobilenetworks.org/nemo/drafts/draft-multihoming-generic-goals-and-benefits-00.txt http://www.mobilenetworks.org/nemo/drafts/draft-lach-nemo-experiments-overdrive-01.txt http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-01.txt http://www.mobilenetworks.org/nemo/drafts/draft-charbon-nemo-multihoming-evaluation-00.txt Or is it a new draft that has not yet been published? Alex --------------ms090204040704070702010503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxNDAxMDlaMCMGCSqGSIb3DQEJBDEWBBSBAQuzjxKJOacrjweX+1C7iwCivDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCCAYZk2YgYMdDc+lsE/JW9+4GMr0X+MLMOkYI9 +UY+bIpYiyN+MLr+wv9yO6i0J71hSHWcl+O8x8vVDKbu7YMwPGfc7ngA0e566/SLl+ewfrpS Kxgq0v9IXw9BXfTlf4csdVk5FsE7+YEv4thmNnlYdngR/BBRGtTEHooiHcqMbgAAAAAAAA== --------------ms090204040704070702010503-- From nemo-admin@ietf.org Thu Mar 25 09:23:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23285 for ; Thu, 25 Mar 2004 09:23:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vhn-0001Ko-4G; Thu, 25 Mar 2004 09:19:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZS-0007h0-Fo for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:10:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21878 for ; Thu, 25 Mar 2004 09:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZN-0006O8-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:10:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VY3-00068r-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:09:32 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6VXM-0005xC-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:08:48 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 09:08:18 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQScduGSLdRdwP6SBuO/XTNl8p2kgAAN9CA From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" Cc: , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Well, I concluded that because you have a link with a number=20 > of devices > on it, and 2 MRs. And then, you split the link, one MR stays, one MR > goes, some LFNs stay and some LFNs go. The subnet has been=20 > split over 2 > links.=20 > This can be resolved in a number of way, including host routes at the > HA.=20 =3D> This is one way, yes. But this is not good for LFNs,=20 unless the signalling is done by the MR only, in which=20 case the MR needs to keep track of nodes on its link. That solution is probably a bit too complex. =20 > I'm not sure we considered that level of complexity already.=20 > Seems to me > it's a new scenario to add and which validity has to be debated, for > example based on practical use cases. =3D> Agreed. The keyword is "practical". Hesham From exim@www1.ietf.org Thu Mar 25 09:28:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23674 for ; Thu, 25 Mar 2004 09:28:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vq0-0003jd-34 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:28:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PES4Ll014351 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vpz-0003jO-TC for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23554 for ; Thu, 25 Mar 2004 09:28:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Vpy-0000Wl-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:28:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Vo0-0000Aq-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:26:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6VmY-0007ly-03 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:24:30 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6VaZ-0005Yl-Au for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:12:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaL-0008Dh-V0; Thu, 25 Mar 2004 09:11:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VRq-0005cv-8Q for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:03:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21230 for ; Thu, 25 Mar 2004 09:03:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VRn-0005SU-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:03:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VQt-0005Nc-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:02:07 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6VQO-0005IS-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:01:36 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PE1ZJO003414; Thu, 25 Mar 2004 07:01:35 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i2PE1GjF022441; Thu, 25 Mar 2004 08:01:17 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4D99485C46E; Thu, 25 Mar 2004 15:01:16 +0100 (CET) Message-ID: <4062E625.4070806@motorola.com> Date: Thu, 25 Mar 2004 15:01:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Pascal Thubert (pthubert)" , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090204040704070702010503" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms090204040704070702010503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > The basic idea is to that a network containing more than one MR, > providing access to the Internet, could be split (one MR goes away > with or without other MNNs/LFNs). After the split, communication > should be possible in both "halves". Note that I haven't placed any > requirements on connection survival or failure detection...etc Hesham, please just say how many MR's exactly (instead of "more than one MR") and how many and what kinds of interfaces. Please say "with other LFN's" instead of "with or without other MNN's/LFN's". If I know all this, I can draw an example of how the NEMO Base Spec supports it; maybe we can even find out that "splitting" is indeed a problem. > => The scenarios draft can help. Which scenarios draft? Which of these: http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-requirements-02.txt http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-terminology-01.txt http://www.mobilenetworks.org/nemo/drafts/draft-multihoming-generic-goals-and-benefits-00.txt http://www.mobilenetworks.org/nemo/drafts/draft-lach-nemo-experiments-overdrive-01.txt http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-01.txt http://www.mobilenetworks.org/nemo/drafts/draft-charbon-nemo-multihoming-evaluation-00.txt Or is it a new draft that has not yet been published? Alex --------------ms090204040704070702010503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxNDAxMDlaMCMGCSqGSIb3DQEJBDEWBBSBAQuzjxKJOacrjweX+1C7iwCivDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCCAYZk2YgYMdDc+lsE/JW9+4GMr0X+MLMOkYI9 +UY+bIpYiyN+MLr+wv9yO6i0J71hSHWcl+O8x8vVDKbu7YMwPGfc7ngA0e566/SLl+ewfrpS Kxgq0v9IXw9BXfTlf4csdVk5FsE7+YEv4thmNnlYdngR/BBRGtTEHooiHcqMbgAAAAAAAA== --------------ms090204040704070702010503-- From exim@www1.ietf.org Thu Mar 25 09:28:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23784 for ; Thu, 25 Mar 2004 09:28:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VqN-0003ox-Ax for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:28:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PESRcL014681 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:28:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VqN-0003od-61 for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:28:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23639 for ; Thu, 25 Mar 2004 09:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VqL-0000b3-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:28:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VoM-0000FB-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:26:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Vmp-0007ly-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:24:47 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6Va3-0005Xb-Gp for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:11:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZg-0007p6-07; Thu, 25 Mar 2004 09:11:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6UnC-00032X-EI for nemo@optimus.ietf.org; Thu, 25 Mar 2004 08:21:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19426 for ; Thu, 25 Mar 2004 08:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6UnB-0000vv-00 for nemo@ietf.org; Thu, 25 Mar 2004 08:21:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6UmJ-0000pU-00 for nemo@ietf.org; Thu, 25 Mar 2004 08:20:12 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6UlQ-0000cN-00 for nemo@ietf.org; Thu, 25 Mar 2004 08:19:16 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 08:18:32 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSaCZz8I1Mfvh9SxiIS8ruE+x7xQAAYtKg From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" Cc: , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > General Agreement here... Seems that Hesham wants a=20 > multilink subnet to > work by magic.=20 =3D> Just to be sure I'm not being misquoted here.... This has _nothing_ to do with the scenarios I mentioned. I don't know what you call multilink subnet but that term,=20 to me, refers to something like the ND proxy that implements something similar to a spanning tree on L2/2.5.=20 If that's what you mean I have no idea how you concluded it from my scenario. Like you, I wish to see use cases, maybe in the > multihoming draft. There is a lack of crispness in all this.=20 =3D> The scenarios draft can help. The basic idea is to=20 that a network containing more than one MR, providing=20 access to the Internet, could be split (one MR goes=20 away with or without other MNNs/LFNs). After the split,=20 communication should be possible in both "halves". Note that=20 I haven't placed any requirements on connection survival or=20 failure detection...etc=20 Hesham From exim@www1.ietf.org Thu Mar 25 09:30:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23987 for ; Thu, 25 Mar 2004 09:30:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VrW-00042j-FD for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:29:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PETVEN015457 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:29:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VrJ-00040L-Cr for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:29:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23906 for ; Thu, 25 Mar 2004 09:29:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VrA-0000kO-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Vp5-0000NT-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:27:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Vn2-0007nH-01 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:25:00 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6VXj-0005Tt-KP for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXe-0006h5-PD; Thu, 25 Mar 2004 09:09:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6TCM-0004rx-Pu for nemo@optimus.ietf.org; Thu, 25 Mar 2004 06:38:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15712 for ; Thu, 25 Mar 2004 06:38:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6TCI-0006Ry-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:38:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6TBI-0006Nj-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:37:53 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B6TAc-0006Jc-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:37:10 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i2PBb6po007082; Thu, 25 Mar 2004 04:37:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i2PBXBPK022194; Thu, 25 Mar 2004 05:33:12 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2501B85C46E; Thu, 25 Mar 2004 12:37:05 +0100 (CET) Message-ID: <4062C45A.2000606@motorola.com> Date: Thu, 25 Mar 2004 12:36:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: Thierry Ernst , nemo References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070006060505000706020806" Subject: [nemo] Re: email style (was: splitting moving networks) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070006060505000706020806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > >> Hesham, correct, you didn't write this, you've cited it. That's >> what I've said: "Soliman Hesham wrote and cited T.E.". > > => I didn't write any of the text in the email. => You included the "Yes" to which I do not agree; me saying this explicitly is more convenient to you? I thought it is enough for me to just say _why_ I don't agree. > So perhaps you shouldn't put me in the "To" field. If I'm in that > field I assume that someone is replying to me. => So I must say that was an error on my part, putting you in the "To" field while actually replying to T.E., sorry. Next time I'll put you in the Cc field when I'm talking to somebody else. >> In emails, ">" means that somebody cited somebody (first-level >> citation) while ">>" means a 2nd level citation. What does "=>" >> mean? > > => It means it's my comment => Great, can I use it too? Alex --------------ms070006060505000706020806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMTM2NThaMCMGCSqGSIb3DQEJBDEWBBSoVjUn1tpOfw0JdM2ZYvz3nMdnATBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCDIcYpdzZCUrp6owA/3kRhgQDFhwk9/u9y+S9v 64QOt96IOyd8Z7n9MKk09lpnfHhZgBQvcEjgU32Q+Gc38q7IrrEYKXgUXnAYz6xxvrKpvaQT 9K3gMU425+enD3RcG6CYj/PxBktephZqB6/jm1NUkfXf9c3Znppn4oSJc8V7KQAAAAAAAA== --------------ms070006060505000706020806-- From exim@www1.ietf.org Thu Mar 25 09:30:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23989 for ; Thu, 25 Mar 2004 09:30:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VrX-00043K-J6 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:29:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PETcEX015513 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:29:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VrV-00041P-QY for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:29:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23918 for ; Thu, 25 Mar 2004 09:29:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VrH-0000lD-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:29:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VpA-0000OR-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:27:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Vn3-0007nH-01 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:25:01 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6VXd-0005Tk-7R for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXb-0006e7-9G; Thu, 25 Mar 2004 09:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6T4c-0004Js-W6 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 06:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15510 for ; Thu, 25 Mar 2004 06:30:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6T4Z-0005jz-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:30:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6T3c-0005ez-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:29:57 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6T2h-0005Vs-00 for nemo@ietf.org; Thu, 25 Mar 2004 06:28:59 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 71C541BD36; Thu, 25 Mar 2004 12:28:26 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 5BEE91B73D; Thu, 25 Mar 2004 12:28:26 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Date: Thu, 25 Mar 2004 12:25:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4061CE5B.5000403@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > indeed. That is the type of solution that you would have in a fixed > > subnetwork with multiple routers connecting to the site. That is what > > the IGPs are designed to do so that is the tool. > > I think IGP can be used between HA's and MR even when MR is not at home, > because MR still belongs to the home domain (through the tunnels), so > the I in IGP is still valid. Yes, i agree with you. > > > Two issues here: > > > > First, how to handle the split network problem that Hesham is > > considering? When the network splits, one of the MR should stop > > advertising the nemo prefix, i guess, so some setting for this should > > be required. > > "Split network problem" could you please formalize somehow? Do you mean > a moving network nesting under another moving network and then > separating? What exactly is "split network"? I've read most of > Hesham's emails attentively, but can't remember it. Maybe a separate > message with subject line saying "split network problem" will help me. next mesages... > > > Second, this is a general nemo issue about security when using IGPs > > in a nemo environment, do you think that it is acceptable to run an > > IGP between the MR and the HA? > > I think there is no major security issue in using IGP in a NEMO > environment as long as that IGP is used between MR and HA's and over the > MR-HA tunnels. Well, the point here is to make sure that the MR only announces the prefixes that it is allowed too, and does not tries to hijack the traffic from other prefixes. This is general concern for routing protocol security, but perhaps in this case is a bit more real. I guess that you can fix that by imposing the HA to inspect all the announcements of the MR to verify that it only announces what it is allowed. This is at least more load to the HA. But the bottom line is that you not really needing an IGP here, since you don't want to discover the topology. The announced prefixes are only those that are allowed. What you want is a mechanisms to detect failures. Perhaps there are simpler options and more effective, like draft-katz-ward-bfd-00.txtto (or just a ping) to do this. OTOH, i think that IGP seems like a good option when the same prefix is reachable through two HA. You can use IGP and the metrics to select which HA and also to balance traffic. So, summarizing, there are two applications of the IGP: - HA-MR failure detection - Selection among different HAs in the home network. I'm definitely not proposing to have MR to have direct > IGP interactions with the other IGP that might happen to run in the > visited domain (e.g. I'm _not_ proposing MR to do IGP with AR). agree. Regards, marcelo > > No? > > Alex > From exim@www1.ietf.org Thu Mar 25 09:37:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24665 for ; Thu, 25 Mar 2004 09:37:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vz8-0005Dx-BD for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:37:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEbUiF020073 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:37:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vz8-0005Dg-5s for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:37:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24581 for ; Thu, 25 Mar 2004 09:37:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Vz6-00020V-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:37:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Vvd-0001La-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:33:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Vu2-00016x-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:32:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VaQ-0008GP-DQ; Thu, 25 Mar 2004 09:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VTm-0005mf-9s for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21285 for ; Thu, 25 Mar 2004 09:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VTk-0005eZ-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:05:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VSo-0005YU-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:04:07 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6VS3-0005Np-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:03:20 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 06:10:11 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PE2Bsk002894; Thu, 25 Mar 2004 15:02:16 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 14:02:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 14:02:41 -0000 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSaCZz8I1Mfvh9SxiIS8ruE+x7xQAAYtKgAAGg0zA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Alexandru Petrescu" Cc: , "IETF NEMO WG" X-OriginalArrivalTime: 25 Mar 2004 14:02:43.0183 (UTC) FILETIME=[D7A66FF0:01C41271] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > General Agreement here... Seems that Hesham wants a > > multilink subnet to > > work by magic. >=20 > =3D> Just to be sure I'm not being misquoted here.... > This has _nothing_ to do with the scenarios I mentioned. > I don't know what you call multilink subnet but that term, > to me, refers to something like the ND proxy that implements > something similar to a spanning tree on L2/2.5. > If that's what you mean I have no idea how you concluded > it from my scenario. Well, I concluded that because you have a link with a number of devices on it, and 2 MRs. And then, you split the link, one MR stays, one MR goes, some LFNs stay and some LFNs go. The subnet has been split over 2 links.=20 This can be resolved in a number of way, including host routes at the HA. But this is out of scope for nemo basic. The link and every node that has a fixed address on it stick together.=20 > Like you, I wish to see use cases, maybe in the > > multihoming draft. There is a lack of crispness in all this. >=20 > =3D> The scenarios draft can help. The basic idea is to > that a network containing more than one MR, providing > access to the Internet, could be split (one MR goes > away with or without other MNNs/LFNs). After the split, > communication should be possible in both "halves". Note that > I haven't placed any requirements on connection survival or > failure detection...etc >=20 I'm not sure we considered that level of complexity already. Seems to me it's a new scenario to add and which validity has to be debated, for example based on practical use cases. Pascal From exim@www1.ietf.org Thu Mar 25 09:38:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24884 for ; Thu, 25 Mar 2004 09:38:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vzt-0005SK-Jw for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:38:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEcHNx020961 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:38:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vzs-0005Rw-Jn for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:38:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24765 for ; Thu, 25 Mar 2004 09:38:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Vzq-0002AT-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:38:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VxH-0001db-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:35:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Vu6-000186-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vhn-0001Ko-4G; Thu, 25 Mar 2004 09:19:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZS-0007h0-Fo for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:10:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21878 for ; Thu, 25 Mar 2004 09:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZN-0006O8-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:10:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VY3-00068r-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:09:32 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6VXM-0005xC-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:08:48 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 09:08:18 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQScduGSLdRdwP6SBuO/XTNl8p2kgAAN9CA From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Alexandru Petrescu" Cc: , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Well, I concluded that because you have a link with a number=20 > of devices > on it, and 2 MRs. And then, you split the link, one MR stays, one MR > goes, some LFNs stay and some LFNs go. The subnet has been=20 > split over 2 > links.=20 > This can be resolved in a number of way, including host routes at the > HA.=20 =3D> This is one way, yes. But this is not good for LFNs,=20 unless the signalling is done by the MR only, in which=20 case the MR needs to keep track of nodes on its link. That solution is probably a bit too complex. =20 > I'm not sure we considered that level of complexity already.=20 > Seems to me > it's a new scenario to add and which validity has to be debated, for > example based on practical use cases. =3D> Agreed. The keyword is "practical". Hesham From nemo-admin@ietf.org Thu Mar 25 09:44:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25424 for ; Thu, 25 Mar 2004 09:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W5d-0006WJ-Om; Thu, 25 Mar 2004 09:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vek-0000Ug-Ff for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:16:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22982 for ; Thu, 25 Mar 2004 09:16:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VeY-0007GX-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:16:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Ve4-0007DJ-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:15:45 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Vcv-0006yu-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:14:33 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 09:14:03 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSca9fwQcajDBBRw2lSZOJtAj0bgAACjBg From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Pascal Thubert (pthubert)" , , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex,=20 I was giving a scenario that purposely eliminates=20 irrelevant information to focus on the key issue.=20 > Hesham, please just say how many MR's exactly (instead of=20 > "more than one > MR")=20 =3D> It doesn't matter for my scenario. If you need a number 2 is fine. and how many and what kinds of interfaces.=20 =3D> Doesn't matter what kinds of interfaces, cellular/WLAN pick one. Please say=20 > "with other > LFN's" instead of "with or without other MNN's/LFN's". =20 =3D> The MR can move with an LFN (or more), with an MNN (or more), or a mix of both. > > =3D> The scenarios draft can help. =3D> We need a multihoming scenarios draft, I think there is a number of people working on it. I don't=20 know if it's published yet. But this : http://www.mobilenetworks.org/nemo/drafts/draft-multihoming-generic-goals= -and -benefits-00.txt is a start. Hesham >=20 > Which scenarios draft? Which of these: >=20 > http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-req uirements-02.txt http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-terminology-01.= txt http://www.mobilenetworks.org/nemo/drafts/draft-lach-nemo-experiments-ove= rdri ve-01.txt http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-0= 1.tx t http://www.mobilenetworks.org/nemo/drafts/draft-charbon-nemo-multihoming-= eval uation-00.txt Or is it a new draft that has not yet been published? Alex From exim@www1.ietf.org Thu Mar 25 09:46:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25519 for ; Thu, 25 Mar 2004 09:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W7L-0006ge-Gl for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:45:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEjxMR025702 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:45:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W7L-0006gT-1R for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:45:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25463 for ; Thu, 25 Mar 2004 09:45:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6W7J-000362-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:45:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6W6M-00032S-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:44:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6W5d-00030f-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:44:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W5d-0006WJ-Om; Thu, 25 Mar 2004 09:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vek-0000Ug-Ff for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:16:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22982 for ; Thu, 25 Mar 2004 09:16:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VeY-0007GX-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:16:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Ve4-0007DJ-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:15:45 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Vcv-0006yu-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:14:33 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 09:14:03 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSca9fwQcajDBBRw2lSZOJtAj0bgAACjBg From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Pascal Thubert (pthubert)" , , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alex,=20 I was giving a scenario that purposely eliminates=20 irrelevant information to focus on the key issue.=20 > Hesham, please just say how many MR's exactly (instead of=20 > "more than one > MR")=20 =3D> It doesn't matter for my scenario. If you need a number 2 is fine. and how many and what kinds of interfaces.=20 =3D> Doesn't matter what kinds of interfaces, cellular/WLAN pick one. Please say=20 > "with other > LFN's" instead of "with or without other MNN's/LFN's". =20 =3D> The MR can move with an LFN (or more), with an MNN (or more), or a mix of both. > > =3D> The scenarios draft can help. =3D> We need a multihoming scenarios draft, I think there is a number of people working on it. I don't=20 know if it's published yet. But this : http://www.mobilenetworks.org/nemo/drafts/draft-multihoming-generic-goals= -and -benefits-00.txt is a start. Hesham >=20 > Which scenarios draft? Which of these: >=20 > http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-req uirements-02.txt http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-terminology-01.= txt http://www.mobilenetworks.org/nemo/drafts/draft-lach-nemo-experiments-ove= rdri ve-01.txt http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-0= 1.tx t http://www.mobilenetworks.org/nemo/drafts/draft-charbon-nemo-multihoming-= eval uation-00.txt Or is it a new draft that has not yet been published? Alex From nemo-admin@ietf.org Thu Mar 25 09:53:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25892 for ; Thu, 25 Mar 2004 09:53:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WEJ-00070j-G2; Thu, 25 Mar 2004 09:53:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WDB-0006xe-1j for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:52:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25756 for ; Thu, 25 Mar 2004 09:51:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WD9-0003Uq-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WC8-0003Pi-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:50:57 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6WBC-0003K2-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:49:59 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0508D1A042; Thu, 25 Mar 2004 15:49:28 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id E4F9719FCA; Thu, 25 Mar 2004 15:49:27 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" , "nemo" Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 15:46:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040325151216.71b69448.ernst@sfc.wide.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > b2. To solve ambiguousness, I would rather just say in the top of the > document (a kind of disclaimer) than there is no warranty that NEMO > Basic Support works with configurations other than a single NEMO-link > attached to the Internet via one MR, i.e.: > > - multihomed mobile networks (8 cases, as identified by the multihomong > problem statement, including multiple MRs) > > - nested mobile networks [although it's assumed it would, but test > remains to be done - we will do it in our lab very soon] > > - split mobile networks > > and that necessary fixes may be done later. I guess that it should be clearly stated in what configurations the solution works fine and in which ones is not clear. Regards, marcelo > > > So, everyone is aware that checks remains to be done, and that > additional specs. may be needed for specific configuration [e.g. a > multihoming usage doc), at least in the informational track. Does this > makes sense for everyone ? > > > > > I think second that the NEMO context has a kind of support of > > > "splitting" which is in fact called "nesting" and which is > > > supported by > > > a good understanding about how it works. A PAN can enter a train > > > entering a ferry and all works; all works also whenever the > > > PAN gets off > > > the train (splitting?) and into the ferry, or when the train > > > gets off > > > and the PAN back or similar. > > > > => This is very different from what we're discussing, > > nesting is fine. > > > I concur to what Hesham says. Nested is when a sub-NEMO gets into a > parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO > and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated > prefix get split in 2 separate entities. > > Thierry > > > > From exim@www1.ietf.org Thu Mar 25 09:55:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26016 for ; Thu, 25 Mar 2004 09:55:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WGC-0007If-EC for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:55:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEt8nq028058 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WGC-0007IT-9Z for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25968 for ; Thu, 25 Mar 2004 09:55:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WGA-0003rC-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:55:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WF6-0003j7-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:54:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6WEK-0003eD-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:53:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WEJ-00070j-G2; Thu, 25 Mar 2004 09:53:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WDB-0006xe-1j for nemo@optimus.ietf.org; Thu, 25 Mar 2004 09:52:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25756 for ; Thu, 25 Mar 2004 09:51:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WD9-0003Uq-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WC8-0003Pi-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:50:57 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6WBC-0003K2-00 for nemo@ietf.org; Thu, 25 Mar 2004 09:49:59 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0508D1A042; Thu, 25 Mar 2004 15:49:28 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id E4F9719FCA; Thu, 25 Mar 2004 15:49:27 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" , "nemo" Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 15:46:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040325151216.71b69448.ernst@sfc.wide.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > b2. To solve ambiguousness, I would rather just say in the top of the > document (a kind of disclaimer) than there is no warranty that NEMO > Basic Support works with configurations other than a single NEMO-link > attached to the Internet via one MR, i.e.: > > - multihomed mobile networks (8 cases, as identified by the multihomong > problem statement, including multiple MRs) > > - nested mobile networks [although it's assumed it would, but test > remains to be done - we will do it in our lab very soon] > > - split mobile networks > > and that necessary fixes may be done later. I guess that it should be clearly stated in what configurations the solution works fine and in which ones is not clear. Regards, marcelo > > > So, everyone is aware that checks remains to be done, and that > additional specs. may be needed for specific configuration [e.g. a > multihoming usage doc), at least in the informational track. Does this > makes sense for everyone ? > > > > > I think second that the NEMO context has a kind of support of > > > "splitting" which is in fact called "nesting" and which is > > > supported by > > > a good understanding about how it works. A PAN can enter a train > > > entering a ferry and all works; all works also whenever the > > > PAN gets off > > > the train (splitting?) and into the ferry, or when the train > > > gets off > > > and the PAN back or similar. > > > > => This is very different from what we're discussing, > > nesting is fine. > > > I concur to what Hesham says. Nested is when a sub-NEMO gets into a > parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO > and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated > prefix get split in 2 separate entities. > > Thierry > > > > From nemo-admin@ietf.org Thu Mar 25 09:58:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21525 for ; Thu, 25 Mar 2004 09:09:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXK-0006Rj-BZ; Thu, 25 Mar 2004 09:08:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6STw-0001cF-Fe for nemo@optimus.ietf.org; Thu, 25 Mar 2004 05:53:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14467 for ; Thu, 25 Mar 2004 05:53:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6STs-0002RI-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SSt-0002MP-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:52:00 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6SSY-0002Gp-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:51:38 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 05:51:08 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSSZE5v/vtWQY9QNmmQbd2+qF4OwADE1uA From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Thierry Ernst" , "nemo" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex, you seem to be responding to me, I didn't write this. Although I agree with Thierry's description. Hesham > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: Thursday, March 25, 2004 4:14 AM > To: Soliman Hesham > Cc: Thierry Ernst; nemo > Subject: Re: [nemo] RE: splitting moving networks (was: DND test) >=20 >=20 > Soliman Hesham wrote and cited T.E.: > >> Nested is when a sub-NEMO gets into a parent-NEMO; the=20 > sub-NEMO has > >> not the same prefix has the parent-NEMO and doesnt' get > >> renumbered. >=20 > Nestedness also happens when MH visits a moving network; it's also=20 > important to stress that the respective MR's or MH's do=20 > _not_ have the=20 > same home link. >=20 > Whenever there's nested encapsulation to HA (i.e. at least=20 > two tunnels > encapsulated) then there's moving networks nestedness. >=20 > >> Split-NEMO is the opposite: an aggregated prefix get split in 2=20 > >> separate entities. >=20 > I really do not understand this high-level definition of an=20 > aggregated > prefix that splits in two separate entities; does it separate in two > separated "sub-prefixes"? What is a detailed example of=20 > such a split? >=20 > Alex >=20 >=20 From exim@www1.ietf.org Thu Mar 25 09:58:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22248 for ; Thu, 25 Mar 2004 09:11:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZf-0007oy-FT for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEBBkR030058 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:11:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZf-0007oh-8h for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:11:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21926 for ; Thu, 25 Mar 2004 09:11:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZd-0006TQ-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:11:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VYT-0006Di-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:09:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VXU-0005zs-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:08:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXK-0006Rj-BZ; Thu, 25 Mar 2004 09:08:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6STw-0001cF-Fe for nemo@optimus.ietf.org; Thu, 25 Mar 2004 05:53:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14467 for ; Thu, 25 Mar 2004 05:53:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6STs-0002RI-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SSt-0002MP-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:52:00 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6SSY-0002Gp-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:51:38 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 05:51:08 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSSZE5v/vtWQY9QNmmQbd2+qF4OwADE1uA From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Thierry Ernst" , "nemo" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alex, you seem to be responding to me, I didn't write this. Although I agree with Thierry's description. Hesham > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: Thursday, March 25, 2004 4:14 AM > To: Soliman Hesham > Cc: Thierry Ernst; nemo > Subject: Re: [nemo] RE: splitting moving networks (was: DND test) >=20 >=20 > Soliman Hesham wrote and cited T.E.: > >> Nested is when a sub-NEMO gets into a parent-NEMO; the=20 > sub-NEMO has > >> not the same prefix has the parent-NEMO and doesnt' get > >> renumbered. >=20 > Nestedness also happens when MH visits a moving network; it's also=20 > important to stress that the respective MR's or MH's do=20 > _not_ have the=20 > same home link. >=20 > Whenever there's nested encapsulation to HA (i.e. at least=20 > two tunnels > encapsulated) then there's moving networks nestedness. >=20 > >> Split-NEMO is the opposite: an aggregated prefix get split in 2=20 > >> separate entities. >=20 > I really do not understand this high-level definition of an=20 > aggregated > prefix that splits in two separate entities; does it separate in two > separated "sub-prefixes"? What is a detailed example of=20 > such a split? >=20 > Alex >=20 >=20 From nemo-admin@ietf.org Thu Mar 25 09:58:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21509 for ; Thu, 25 Mar 2004 09:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXI-0006Px-31; Thu, 25 Mar 2004 09:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6SN4-0001E6-QX for nemo@optimus.ietf.org; Thu, 25 Mar 2004 05:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14267 for ; Thu, 25 Mar 2004 05:45:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6SN1-0001iE-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:45:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SM7-0001dT-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:45:00 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6SLP-0001YG-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:44:15 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PAiJJO029751; Thu, 25 Mar 2004 03:44:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2PAiBUK002831; Thu, 25 Mar 2004 04:44:12 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6D6D585C46E; Thu, 25 Mar 2004 11:44:11 +0100 (CET) Message-ID: <4062B7FA.7080203@motorola.com> Date: Thu, 25 Mar 2004 11:44:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Soliman Hesham , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040104030803070900060902" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms040104030803070900060902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> > I think that, first, moving networks in the NEMO sense have a rigid >> > structure, they just don't separate components from one >> > another, a basic >> > definition. >> >>=> Disagree. Where is this definition made? It would be >>a big mistake to make this assumption IMHO. How can >>you say that a moving network will never be divided? >>If I have a PAN with 4 devices and one day I left >>2 at home and took 2 with me to work, you're saying >>that this is not _meant_ to work? >> > > Yes, Hesham, exactly. It's a configuration error. It should be 2 > networks. But then, they should not share an ingress link, ever. It's > either load balancing in an atomic (rigid) configuration or a totally > separated configuration. What you're asking for is just too difficult > with the current technology, and it's not just Nemo. Pascal, I did not see any specific requirement from Hesham about how the moving network actually splits; it's just "I leave two devices at home and take two with me". That is not enough. If one really wants to see how NEMO would work in this too-high-level scenario, and depict the BU/BAck message exchanges and the tunnels, then one should be a little bit more detailed on how the network actually splits. I've tried to interpret more on what Hesham meant, drawed some diagrams here that respect the split net Hesham's scenario and I think NEMO Base Protocol works. But I'm not sure exactly what Hesham meant exactly. So, Hesham, could you please be more explicit on exactly you see that split moving network scenario? Where are the home agents? Does your house host a home link? Are all devices LFN's or can they be MH's? What moves and in what order. Alex --------------ms040104030803070900060902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMDQ0MTBaMCMGCSqGSIb3DQEJBDEWBBSM36WyvaBqB/bLtlqORCqXln3NLzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCfl/QGz/0qJMKyumz7rjVOGt9wuyHdZwuzMx7u MGHmFuk+PNOIsbIXaugjUWEnPRuIdef6/IhxIKnvs1E2ZUCW9+RbVHGfnxh7zbXnZK/u65Pe Q/O+jy+djtWy5GlKwmX0QGfKzX2IcHYSm1JkgC8LBzEvkuN8gSk7hQjJXumYgAAAAAAAAA== --------------ms040104030803070900060902-- From nemo-admin@ietf.org Thu Mar 25 09:58:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21510 for ; Thu, 25 Mar 2004 09:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXF-0006OP-1l; Thu, 25 Mar 2004 09:08:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6SBU-0000XL-BR for nemo@optimus.ietf.org; Thu, 25 Mar 2004 05:34:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13910 for ; Thu, 25 Mar 2004 05:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6SBQ-0000eI-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:33:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SAX-0000ZN-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:33:02 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6SAB-0000UH-00 for nemo@ietf.org; Thu, 25 Mar 2004 05:32:39 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PAWfJO014384; Thu, 25 Mar 2004 03:32:41 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i2PAVIGr019300; Thu, 25 Mar 2004 04:31:19 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2200785C46E; Thu, 25 Mar 2004 11:32:31 +0100 (CET) Message-ID: <4062B53B.5080200@motorola.com> Date: Thu, 25 Mar 2004 11:32:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: mbagnulo@ing.uc3m.es, "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010806000906040605040004" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms010806000906040605040004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: >> I think that, first, moving networks in the NEMO sense have a rigid >> structure, they just don't separate components from one another, a >> basic definition. > > => Disagree. Where is this definition made? In the terminology draft. > It would be a big mistake to make this assumption IMHO. IMHO it is a good fixed point on which we can use all sorts of levers. > How can you say that a moving network will never be divided? Just assume it; it's like assuming that there will always be a cable on which to communicate; if there's no such cable then there's no communication possible at all. > If I have a PAN with 4 devices and one day I left 2 at home and took > 2 with me to work, you're saying that this is not _meant_ to work? It _is_ meant to work. Just make sure you take the device with the MR sticker with you :-) I mean, if out of those four devices one is MR all three others are LFN's, then leaving two LFN's at home will not stop the other LFN to work just fine when behind the MR. Also, if the three LFN's are in fact MH's then again it is possible to leave two MH's at home (in this case they'll actually visit MR's home link) and have the other MH stay at its home (in the MR's ingress link) while you're taking the MR and this latter MH with you. There's no NEMO communication problem, there's no nestedness, there's no multi-homing and there's no splitting in all this (as long as all entities stay connected). >> I think second that the NEMO context has a kind of support of >> "splitting" which is in fact called "nesting" and which is >> supported by a good understanding about how it works. A PAN can >> enter a train entering a ferry and all works; all works also >> whenever the PAN gets off the train (splitting?) and into the >> ferry, or when the train gets off and the PAN back or similar. > > => This is very different from what we're discussing, nesting is > fine. Alex --------------ms010806000906040605040004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMDMyMjdaMCMGCSqGSIb3DQEJBDEWBBQvOwm+TmGCxROlER3GvPFRhvyrozBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDNKBfVBtSJLnGdBk+CWPFS+uee/3k/R2pEbIhg 97nifGOhtlVcMkYjDQpSbcWnOJwlxZU6h9dtOkfRkdTnerKMMHEWS4F3+YQ7QmXLhZqh2ZLP 8Rdl2p1URvQw7Ybq+3G+z/ZkIti9t3K/8ciyjgG4lUYloSYQTLPbMa6B1ZXNkQAAAAAAAA== --------------ms010806000906040605040004-- From nemo-admin@ietf.org Thu Mar 25 10:02:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26755 for ; Thu, 25 Mar 2004 10:02:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WN1-0000gF-7b; Thu, 25 Mar 2004 10:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WMn-0000W9-4z for nemo@optimus.ietf.org; Thu, 25 Mar 2004 10:01:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26710 for ; Thu, 25 Mar 2004 10:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WMk-0004e6-00 for nemo@ietf.org; Thu, 25 Mar 2004 10:01:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WLp-0004Zd-00 for nemo@ietf.org; Thu, 25 Mar 2004 10:00:58 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6WKx-0004Rf-00 for nemo@ietf.org; Thu, 25 Mar 2004 10:00:03 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 61CB1194F2; Thu, 25 Mar 2004 15:59:33 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 4AB2D18722; Thu, 25 Mar 2004 15:59:33 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Date: Thu, 25 Mar 2004 15:56:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4062D378.7020100@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > I guess so. So coming back to the NEMO multi-homing-related problem, > where is the IGP _not_ sufficient? No, i think that an IGP can work for this. My concern is whether this is best option. I mean, the HA doesn't have to discover the prefixes behind the MR since it already knows them. so using a IGP would impose the additional burden of having to inspect the packets looking for IGP messages and then inspecting the content of such packets. If you use a simple ping to detect reachability between the MR and the HA you will obtain the same functionality with a lower cost, i guess. Of course, IGP are already there. I do agree that using IGP to inform about the different paths through different HAs within the home network is fine. Regards, marcelo > > Alex > From exim@www1.ietf.org Thu Mar 25 10:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27187 for ; Thu, 25 Mar 2004 10:04:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WOn-0002H9-JN for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 10:04:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PF419C008747 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 10:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WOn-0002H0-DZ for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 10:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27026 for ; Thu, 25 Mar 2004 10:03:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WOl-0004oO-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 10:03:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WNr-0004jr-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 10:03:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6WN5-0004hV-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 10:02:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WN1-0000gF-7b; Thu, 25 Mar 2004 10:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WMn-0000W9-4z for nemo@optimus.ietf.org; Thu, 25 Mar 2004 10:01:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26710 for ; Thu, 25 Mar 2004 10:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6WMk-0004e6-00 for nemo@ietf.org; Thu, 25 Mar 2004 10:01:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6WLp-0004Zd-00 for nemo@ietf.org; Thu, 25 Mar 2004 10:00:58 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6WKx-0004Rf-00 for nemo@ietf.org; Thu, 25 Mar 2004 10:00:03 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 61CB1194F2; Thu, 25 Mar 2004 15:59:33 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 4AB2D18722; Thu, 25 Mar 2004 15:59:33 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Date: Thu, 25 Mar 2004 15:56:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4062D378.7020100@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I guess so. So coming back to the NEMO multi-homing-related problem, > where is the IGP _not_ sufficient? No, i think that an IGP can work for this. My concern is whether this is best option. I mean, the HA doesn't have to discover the prefixes behind the MR since it already knows them. so using a IGP would impose the additional burden of having to inspect the packets looking for IGP messages and then inspecting the content of such packets. If you use a simple ping to detect reachability between the MR and the HA you will obtain the same functionality with a lower cost, i guess. Of course, IGP are already there. I do agree that using IGP to inform about the different paths through different HAs within the home network is fine. Regards, marcelo > > Alex > From exim@www1.ietf.org Thu Mar 25 10:30:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00604 for ; Thu, 25 Mar 2004 10:30:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WoL-0000Lj-T0 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 10:30:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFUP02001343 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 10:30:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WOf-00026j-1d for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 10:03:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22594 for ; Thu, 25 Mar 2004 09:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VcD-0006wX-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:13:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Vaa-0006ew-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:12:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZI-0006Mq-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZI-0007aT-Uc; Thu, 25 Mar 2004 09:10:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6UCV-0000yK-Tl for nemo@optimus.ietf.org; Thu, 25 Mar 2004 07:43:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17925 for ; Thu, 25 Mar 2004 07:43:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6UCV-0005Ad-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:43:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6UBV-00054Q-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:42:10 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6UB4-0004yM-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:41:42 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2PCfhJO016836; Thu, 25 Mar 2004 05:41:43 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2PCfaUK030677; Thu, 25 Mar 2004 06:41:36 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6CB9985C46E; Thu, 25 Mar 2004 13:41:35 +0100 (CET) Message-ID: <4062D378.7020100@motorola.com> Date: Thu, 25 Mar 2004 13:41:28 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020606000501090602020106" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms020606000501090602020106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> I think there is no major security issue in using IGP in a NEMO >> environment as long as that IGP is used between MR and HA's and >> over the MR-HA tunnels. > > Well, the point here is to make sure that the MR only announces the > prefixes that it is allowed too, and does not tries to hijack the > traffic from other prefixes. Ok. > This is general concern for routing protocol security, but perhaps in > this case is a bit more real. I guess that you can fix that by > imposing the HA to inspect all the announcements of the MR to verify > that it only announces what it is allowed. The HA inspecting all announcements of the MR, and comparing to the routes it itself owns about MR (probably introduced by admin in an existing config file and routing table) is one way of checking. For NEMO, another way of checking is the NEMO-specified Prefix Table at HA where the Prefix Table is actually a new structure but which is most probably filled by the same admin. > This is at least more load to the HA. But the bottom line is that you > not really needing an IGP here, since you don't want to discover the > topology. I think IGP or EGP or any routing protocol is not only used for topology discovery but most importantly for route maintenance when links fail. But this is of course a matter of interpretation. > What you want is a mechanisms to detect failures. Perhaps there are > simpler options and more effective, like draft-katz-ward-bfd-00.txt I just can't find it, neither 01 nor 02, nor 03, is it an RFC. I have an idea about how route failures are detected in OSPF and RIP (various flavors) and I think they can be used with the NEMO base support. > (or just a ping) to do this. OTOH, i think that IGP seems like a good > option when the same prefix is reachable through two HA. You can use > IGP and the metrics to select which HA and also to balance traffic. > > So, summarizing, there are two applications of the IGP: - HA-MR > failure detection - Selection among different HAs in the home > network. I guess so. So coming back to the NEMO multi-homing-related problem, where is the IGP _not_ sufficient? Alex --------------ms020606000501090602020106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUxMjQxMjhaMCMGCSqGSIb3DQEJBDEWBBQu+s9X9tcg7lwCsg5uQBxPXu/dkDBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYBPCqirezGfx7i2eIyW7Z5tAIJAN+TnS1KNn5uy GHLVoxrkaWyQscEXPJvh4VTsSY0Ae6tItQo4vgE/j+y0OnJqBnOCtq8eSET+akxclTzww8r2 /jf5S27gVi+KtjA1Db1x6vUWYS5XDyGhmXkcHipghHKjUZ9ikQErGg28wNwiDAAAAAAAAA== --------------ms020606000501090602020106-- From nemo-admin@ietf.org Thu Mar 25 11:06:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03772 for ; Thu, 25 Mar 2004 11:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XMr-00067Z-Kw; Thu, 25 Mar 2004 11:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XML-00061E-B7 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 11:05:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03708 for ; Thu, 25 Mar 2004 11:05:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XMI-0003RT-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:05:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XLF-0003Ee-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:04:28 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6XJD-0002eX-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:02:19 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E827F1AF90; Thu, 25 Mar 2004 17:01:48 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id D13E51AF8E; Thu, 25 Mar 2004 17:01:48 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" Cc: , , Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Thu, 25 Mar 2004 16:59:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040325152000.7d978c78.ernst@sfc.wide.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Thierry > Marcelo, did you read > > Title : Goals and Benefits of Multihoming > Author(s) : T. Ernst > Filename : > draft-multihoming-generic-goals-and-benefits-00.txt > Pages : 16 > Date : 2004-2-11 > > This document attempts to define the goals and benefits of > multihoming for fixed and mobile hosts and routers. Those goals and > benefits are illustrated with a set of real-life scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-bene fits-00.txt Some comments. First, have you read RFC 3582? This is multihoming goals document defined by multi6 It is somehow different, since it has the benefits of multihoming but also other goals that a multihoming solution should provide. I think that this your document provides an interesting p.o.v. since it provides aspects more related to mobility which are not present in rfc 3582 (since it only deals with fixed networks. A couple of specific comments. First, i am not sure that a multi-prefixed node should be included in the multihomed host case. I think that a multihomed host is a host that have multiple paths to the internet and it has a mean to select which one to use. so if a host has multiple interfaces, it clearly has multiple paths to the internet and it has to select one of them In the case of a multiprefixed host, this is not clear. IMHO you are assuming a bit too much here. Even in the case that the host is in a multihomed site with one prefix per isp, it is not clear for now that the source address prefix selection performed by the host will imply the ISP/path used to route the packet. I would prefer a more general definition of multihomed node, like a host with multiple access to the Internet. I don't really see the difference between load sharing and load balancing > To all, all the discussions about the "split NEMO" and "multiple MR on a > NEMO-prefix" etc are very good input for > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt, > which will become a NEMO WG document in his next revision. IMHO an essential part is missing in this document i.e. an identification of the nemo specific issues of multihoming. As i understand it, we should first identify the nemo specific issues related with multihoming and then try to figure out if they can be addressed using existent tools or we need new ones. IMHO it is a complex task, but it is the relevant point here. I think that Goals and benefits doc highlights some aspects that i am not sure that are nemo specific, but they are more relevant in nemo environments. For instance, when you are using multiple routers to use different wireless technologies, the problem is quite different than the one that multi6 is dealing with. Basically in this case, the problem is much more local than the general multi6 problem, since you need to use the link between the HA and the MR that is available. In other words, the direct links between the nemo and the home network is very unstable and are expected to "fail" (i.e. not to be available) frequently- so if you find a solution that allows using one link or the other it seems to be good enough. OTOH, because of the high frequency of "outages" (non available links) it is very important that communications are preserved when one link becomes unavailable So, i think that this is very reasonable and probably frequent scenario for nemo, so it seems reasonable that nemo optimizes this case. That is, the case when the direct links between the nemo and its providers are not available. (Note that the multi6 solution has to deal with ISP wide failure case and IX point wide failure case and so on) The other point that Hesham has mentioned is that even if an alternative link is available, perhaps this link is not good enough for preserving an established communication. I guess that the difference here is that the differences between the link capacities can be much more greater in nemo than in the fixed case. so probably you need to impose more policy enforcement mechanisms Well, i guess that we should work on identifying this points and then decide what to do to provide multihoming in nemo, makes sense? Regards, marcelo I think that the issues should be discussed in that draft, not in the NEMO Basic Support draft. And I would support, additionaly to the multihoming problem statement draft, another draft for "multihoming usages". The problem statement draft will ... state ... all the ... problems, while the usage draft would give a priority to the scenario which are useful. I think we can agree on this way of working ? Thierry. From exim@www1.ietf.org Thu Mar 25 11:07:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03856 for ; Thu, 25 Mar 2004 11:07:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XOH-0006Ow-PW for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 11:07:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PG7Xi9024606 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 11:07:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XOH-0006On-In for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 11:07:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03850 for ; Thu, 25 Mar 2004 11:07:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XOF-0003cr-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 11:07:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XNP-0003ZD-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 11:06:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6XMs-0003Ug-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 11:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XMr-00067Z-Kw; Thu, 25 Mar 2004 11:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XML-00061E-B7 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 11:05:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03708 for ; Thu, 25 Mar 2004 11:05:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XMI-0003RT-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:05:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XLF-0003Ee-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:04:28 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6XJD-0002eX-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:02:19 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E827F1AF90; Thu, 25 Mar 2004 17:01:48 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id D13E51AF8E; Thu, 25 Mar 2004 17:01:48 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" Cc: , , Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Thu, 25 Mar 2004 16:59:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040325152000.7d978c78.ernst@sfc.wide.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thierry > Marcelo, did you read > > Title : Goals and Benefits of Multihoming > Author(s) : T. Ernst > Filename : > draft-multihoming-generic-goals-and-benefits-00.txt > Pages : 16 > Date : 2004-2-11 > > This document attempts to define the goals and benefits of > multihoming for fixed and mobile hosts and routers. Those goals and > benefits are illustrated with a set of real-life scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-bene fits-00.txt Some comments. First, have you read RFC 3582? This is multihoming goals document defined by multi6 It is somehow different, since it has the benefits of multihoming but also other goals that a multihoming solution should provide. I think that this your document provides an interesting p.o.v. since it provides aspects more related to mobility which are not present in rfc 3582 (since it only deals with fixed networks. A couple of specific comments. First, i am not sure that a multi-prefixed node should be included in the multihomed host case. I think that a multihomed host is a host that have multiple paths to the internet and it has a mean to select which one to use. so if a host has multiple interfaces, it clearly has multiple paths to the internet and it has to select one of them In the case of a multiprefixed host, this is not clear. IMHO you are assuming a bit too much here. Even in the case that the host is in a multihomed site with one prefix per isp, it is not clear for now that the source address prefix selection performed by the host will imply the ISP/path used to route the packet. I would prefer a more general definition of multihomed node, like a host with multiple access to the Internet. I don't really see the difference between load sharing and load balancing > To all, all the discussions about the "split NEMO" and "multiple MR on a > NEMO-prefix" etc are very good input for > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt, > which will become a NEMO WG document in his next revision. IMHO an essential part is missing in this document i.e. an identification of the nemo specific issues of multihoming. As i understand it, we should first identify the nemo specific issues related with multihoming and then try to figure out if they can be addressed using existent tools or we need new ones. IMHO it is a complex task, but it is the relevant point here. I think that Goals and benefits doc highlights some aspects that i am not sure that are nemo specific, but they are more relevant in nemo environments. For instance, when you are using multiple routers to use different wireless technologies, the problem is quite different than the one that multi6 is dealing with. Basically in this case, the problem is much more local than the general multi6 problem, since you need to use the link between the HA and the MR that is available. In other words, the direct links between the nemo and the home network is very unstable and are expected to "fail" (i.e. not to be available) frequently- so if you find a solution that allows using one link or the other it seems to be good enough. OTOH, because of the high frequency of "outages" (non available links) it is very important that communications are preserved when one link becomes unavailable So, i think that this is very reasonable and probably frequent scenario for nemo, so it seems reasonable that nemo optimizes this case. That is, the case when the direct links between the nemo and its providers are not available. (Note that the multi6 solution has to deal with ISP wide failure case and IX point wide failure case and so on) The other point that Hesham has mentioned is that even if an alternative link is available, perhaps this link is not good enough for preserving an established communication. I guess that the difference here is that the differences between the link capacities can be much more greater in nemo than in the fixed case. so probably you need to impose more policy enforcement mechanisms Well, i guess that we should work on identifying this points and then decide what to do to provide multihoming in nemo, makes sense? Regards, marcelo I think that the issues should be discussed in that draft, not in the NEMO Basic Support draft. And I would support, additionaly to the multihoming problem statement draft, another draft for "multihoming usages". The problem statement draft will ... state ... all the ... problems, while the usage draft would give a priority to the scenario which are useful. I think we can agree on this way of working ? Thierry. From nemo-admin@ietf.org Thu Mar 25 11:15:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04322 for ; Thu, 25 Mar 2004 11:15:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XVU-0007RW-HF; Thu, 25 Mar 2004 11:15:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XUm-0007PP-K4 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 11:14:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04248 for ; Thu, 25 Mar 2004 11:14:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XUl-00042Y-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:14:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XTn-0003xz-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:13:16 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6XSr-0003t2-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:12:17 -0500 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 623521B023; Thu, 25 Mar 2004 17:11:47 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 869361B023; Thu, 25 Mar 2004 17:11:42 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , "Thierry Ernst" Cc: , , Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Thu, 25 Mar 2004 17:09:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit just one more nemo specific issue in multihoming... having to support Hesham scenario of split network seems pretty nemo specific too Regards, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de marcelo > bagnulo > Enviado el: jueves, 25 de marzo de 2004 16:59 > Para: Thierry Ernst > CC: H.Soliman@flarion.com; pthubert@cisco.com; nemo@ietf.org > Asunto: RE: [nemo] RE: DND test [was Assigning the same prefix to > multiple MRs] > > > Hi Thierry > > Marcelo, did you read > > > > Title : Goals and Benefits of Multihoming > > Author(s) : T. Ernst > > Filename : > > draft-multihoming-generic-goals-and-benefits-00.txt > > Pages : 16 > > Date : 2004-2-11 > > > > This document attempts to define the goals and benefits of > > multihoming for fixed and mobile hosts and routers. Those goals and > > benefits are illustrated with a set of real-life scenarios. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-multihoming-generic-goal > s-and-bene > fits-00.txt > > Some comments. > First, have you read RFC 3582? > This is multihoming goals document defined by multi6 > It is somehow different, since it has the benefits of multihoming but also > other goals that a multihoming solution should provide. > > I think that this your document provides an interesting p.o.v. since it > provides aspects more related to mobility which are not present > in rfc 3582 > (since it only deals with fixed networks. > > A couple of specific comments. > > First, i am not sure that a multi-prefixed node should be included in the > multihomed host case. > I think that a multihomed host is a host that have multiple paths to the > internet and it has a mean to select which one to use. > so if a host has multiple interfaces, it clearly has multiple paths to the > internet and it has to select one of them > In the case of a multiprefixed host, this is not clear. IMHO you are > assuming a bit too much here. Even in the case that the host is in a > multihomed site with one prefix per isp, it is not clear for now that the > source address prefix selection performed by the host will imply the > ISP/path used to route the packet. > > I would prefer a more general definition of multihomed node, like a host > with multiple access to the Internet. > > I don't really see the difference between load sharing and load balancing > > > To all, all the discussions about the "split NEMO" and "multiple MR on a > > NEMO-prefix" etc are very good input for > > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issu > es-03.txt, > > which will become a NEMO WG document in his next revision. > > > IMHO an essential part is missing in this document i.e. an > identification of > the nemo specific issues of multihoming. > > As i understand it, we should first identify the nemo specific issues > related with multihoming and then try to figure out if they can > be addressed > using existent tools or we need new ones. > > IMHO it is a complex task, but it is the relevant point here. > > I think that Goals and benefits doc highlights some aspects that i am not > sure that are nemo specific, but they are more relevant in nemo > environments. > > For instance, when you are using multiple routers to use > different wireless > technologies, the problem is quite different than the one that multi6 is > dealing with. Basically in this case, the problem is much more local than > the general multi6 problem, since you need to use the link between the HA > and the MR that is available. In other words, the direct links between the > nemo and the home network is very unstable and are expected to > "fail" (i.e. > not to be available) frequently- so if you find a solution that > allows using > one link or the other it seems to be good enough. OTOH, because > of the high > frequency of "outages" (non available links) it is very important that > communications are preserved when one link becomes unavailable > > So, i think that this is very reasonable and probably frequent > scenario for > nemo, so it seems reasonable that nemo optimizes this case. That is, the > case when the direct links between the nemo and its providers are not > available. > (Note that the multi6 solution has to deal with ISP wide failure > case and IX > point wide failure case and so on) > > The other point that Hesham has mentioned is that even if an alternative > link is available, perhaps this link is not good enough for preserving an > established communication. I guess that the difference here is that the > differences between the link capacities can be much more greater in nemo > than in the fixed case. so probably you need to impose more policy > enforcement mechanisms > > Well, i guess that we should work on identifying this points and > then decide > what to do to provide multihoming in nemo, makes sense? > > Regards, marcelo > > > I think that the issues should be discussed in that draft, not in the > NEMO Basic Support draft. And I would support, additionaly to the > multihoming problem statement draft, another draft for "multihoming > usages". > > The problem statement draft will ... state ... all the ... problems, > while the usage draft would give a priority to the scenario which are > useful. > > I think we can agree on this way of working ? > > Thierry. > > From exim@www1.ietf.org Thu Mar 25 11:17:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04497 for ; Thu, 25 Mar 2004 11:17:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XXp-0007kY-F2 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 11:17:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PGHPRi029789 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 11:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XXp-0007kO-98 for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 11:17:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04465 for ; Thu, 25 Mar 2004 11:17:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XXo-0004LK-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 11:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XWk-0004FI-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 11:16:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6XVh-00049E-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 11:15:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XVU-0007RW-HF; Thu, 25 Mar 2004 11:15:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XUm-0007PP-K4 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 11:14:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04248 for ; Thu, 25 Mar 2004 11:14:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XUl-00042Y-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:14:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XTn-0003xz-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:13:16 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6XSr-0003t2-00 for nemo@ietf.org; Thu, 25 Mar 2004 11:12:17 -0500 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 623521B023; Thu, 25 Mar 2004 17:11:47 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 869361B023; Thu, 25 Mar 2004 17:11:42 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , "Thierry Ernst" Cc: , , Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Date: Thu, 25 Mar 2004 17:09:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit just one more nemo specific issue in multihoming... having to support Hesham scenario of split network seems pretty nemo specific too Regards, marcelo > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de marcelo > bagnulo > Enviado el: jueves, 25 de marzo de 2004 16:59 > Para: Thierry Ernst > CC: H.Soliman@flarion.com; pthubert@cisco.com; nemo@ietf.org > Asunto: RE: [nemo] RE: DND test [was Assigning the same prefix to > multiple MRs] > > > Hi Thierry > > Marcelo, did you read > > > > Title : Goals and Benefits of Multihoming > > Author(s) : T. Ernst > > Filename : > > draft-multihoming-generic-goals-and-benefits-00.txt > > Pages : 16 > > Date : 2004-2-11 > > > > This document attempts to define the goals and benefits of > > multihoming for fixed and mobile hosts and routers. Those goals and > > benefits are illustrated with a set of real-life scenarios. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-multihoming-generic-goal > s-and-bene > fits-00.txt > > Some comments. > First, have you read RFC 3582? > This is multihoming goals document defined by multi6 > It is somehow different, since it has the benefits of multihoming but also > other goals that a multihoming solution should provide. > > I think that this your document provides an interesting p.o.v. since it > provides aspects more related to mobility which are not present > in rfc 3582 > (since it only deals with fixed networks. > > A couple of specific comments. > > First, i am not sure that a multi-prefixed node should be included in the > multihomed host case. > I think that a multihomed host is a host that have multiple paths to the > internet and it has a mean to select which one to use. > so if a host has multiple interfaces, it clearly has multiple paths to the > internet and it has to select one of them > In the case of a multiprefixed host, this is not clear. IMHO you are > assuming a bit too much here. Even in the case that the host is in a > multihomed site with one prefix per isp, it is not clear for now that the > source address prefix selection performed by the host will imply the > ISP/path used to route the packet. > > I would prefer a more general definition of multihomed node, like a host > with multiple access to the Internet. > > I don't really see the difference between load sharing and load balancing > > > To all, all the discussions about the "split NEMO" and "multiple MR on a > > NEMO-prefix" etc are very good input for > > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issu > es-03.txt, > > which will become a NEMO WG document in his next revision. > > > IMHO an essential part is missing in this document i.e. an > identification of > the nemo specific issues of multihoming. > > As i understand it, we should first identify the nemo specific issues > related with multihoming and then try to figure out if they can > be addressed > using existent tools or we need new ones. > > IMHO it is a complex task, but it is the relevant point here. > > I think that Goals and benefits doc highlights some aspects that i am not > sure that are nemo specific, but they are more relevant in nemo > environments. > > For instance, when you are using multiple routers to use > different wireless > technologies, the problem is quite different than the one that multi6 is > dealing with. Basically in this case, the problem is much more local than > the general multi6 problem, since you need to use the link between the HA > and the MR that is available. In other words, the direct links between the > nemo and the home network is very unstable and are expected to > "fail" (i.e. > not to be available) frequently- so if you find a solution that > allows using > one link or the other it seems to be good enough. OTOH, because > of the high > frequency of "outages" (non available links) it is very important that > communications are preserved when one link becomes unavailable > > So, i think that this is very reasonable and probably frequent > scenario for > nemo, so it seems reasonable that nemo optimizes this case. That is, the > case when the direct links between the nemo and its providers are not > available. > (Note that the multi6 solution has to deal with ISP wide failure > case and IX > point wide failure case and so on) > > The other point that Hesham has mentioned is that even if an alternative > link is available, perhaps this link is not good enough for preserving an > established communication. I guess that the difference here is that the > differences between the link capacities can be much more greater in nemo > than in the fixed case. so probably you need to impose more policy > enforcement mechanisms > > Well, i guess that we should work on identifying this points and > then decide > what to do to provide multihoming in nemo, makes sense? > > Regards, marcelo > > > I think that the issues should be discussed in that draft, not in the > NEMO Basic Support draft. And I would support, additionaly to the > multihoming problem statement draft, another draft for "multihoming > usages". > > The problem statement draft will ... state ... all the ... problems, > while the usage draft would give a priority to the scenario which are > useful. > > I think we can agree on this way of working ? > > Thierry. > > From nemo-admin@ietf.org Thu Mar 25 15:32:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18998 for ; Thu, 25 Mar 2004 15:32:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bWD-0004eR-Q0; Thu, 25 Mar 2004 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bVg-0004cd-DA for nemo@optimus.ietf.org; Thu, 25 Mar 2004 15:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18959 for ; Thu, 25 Mar 2004 15:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6bVf-0005HY-00 for nemo@ietf.org; Thu, 25 Mar 2004 15:31:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6bUg-0005F4-00 for nemo@ietf.org; Thu, 25 Mar 2004 15:30:27 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B6bTz-0005DX-00 for nemo@ietf.org; Thu, 25 Mar 2004 15:29:43 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i2PKTcpo020903; Thu, 25 Mar 2004 13:29:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2PKSNVP002306; Thu, 25 Mar 2004 14:28:41 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C99B085C46E; Thu, 25 Mar 2004 21:29:14 +0100 (CET) Message-ID: <40634113.3070905@motorola.com> Date: Thu, 25 Mar 2004 21:29:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Pascal Thubert (pthubert)" , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000007050100070506030707" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms000007050100070506030707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > => It doesn't matter for my scenario. If you need a number 2 is fine. > > and how many and what kinds of interfaces. > > => Doesn't matter what kinds of interfaces, cellular/WLAN pick one. > > Please say >> "with other LFN's" instead of "with or without other MNN's/LFN's". > > => The MR can move with an LFN (or more), with an MNN (or more), or a > mix of both. Thanks for the first two details. I've built a scenario with two MR's and two HA's and two LFN's. First they are home, and then half of the moving network moves outside the home link. In the picture below, both MR1 and MR2 are connected to their home link, which is a common link. MR1 is served by HA1 and MR2 by HA2 when they're not at home. There are two MNP's on the same moving network link. LFN1 configures its default route to go to MR1 and LFN2 its default route to go to MR2 (this could be done manually routes, or with some security features, or with virtual VLAN or with other L2 technique, or otherwise, but not NEMO stuff). HA1 and HA2 are connected to the same home link but do not maintain a HA list between them since they serve different MNP's; ---- ---- | HA1| | HA2| ---- ---- | | ---- -------------------| BR |------> Internet | | ---- ---- ----- | MR1| | MR2 | ---- ----- | | ----------moving network | | ---- ----- |LFN1| |LFN2 | ---- ----- Now the sub-segment made by MR2 and LFN2 physically splits from the moving network and becomes a moving network on its own, and goes under AR, in the picture below. After obtaining CoA, MR2 maintains a tunnel to HA2. ---- ---- | HA1| | HA2| / ---- ---- ----------/ | | ---- | | -------------------| BR |--| Internet | | ---- | | ---- ----------\ | MR1| \ ---- \ ---- Visited link | --| AR |------ -----half moving net ---- | | | ---- ---- |LFN1| | MR2| ---- ---- | half moving net ---- | ----- | LFN2| ----- I think in this configuration all works fine from the NEMO standpoint. I think the potential problem may lie in how LFN's configure different default routes; this can be done at least manually and I think that how this is done is outside the scope of NEMO. So, what do you think, am I missing something? Is anything from the NEMO Base Support that forbids this kind of split moving networks configuration to work properly? Alex --------------ms000007050100070506030707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUyMDI5MDdaMCMGCSqGSIb3DQEJBDEWBBTcFKUm7vJ0wtS0bTgkuzLqpVBXSTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYA2r6cCVp5YnmozJvprkUHxm1WYp/QI6eaNHYnX D1ez7waozf252WEdH0Zh9ZEzIRnWK9rIej7RiuEKMCPiQx61glRzdwFeLHpzA57SVjIlJJ5m RVTOm1AS+FziBZZhofdpuBFlQUum73VF/Xr+LQPFSnBGtPr+bFqb3Qvp6YmJBwAAAAAAAA== --------------ms000007050100070506030707-- From exim@www1.ietf.org Thu Mar 25 15:34:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19039 for ; Thu, 25 Mar 2004 15:34:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bXh-0004rN-A6 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 15:33:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PKXX1R018680 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 15:33:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bXh-0004rB-3s for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 15:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19032 for ; Thu, 25 Mar 2004 15:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6bXf-0005OA-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 15:33:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6bWl-0005Lr-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 15:32:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6bWH-0005JH-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 15:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bWD-0004eR-Q0; Thu, 25 Mar 2004 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6bVg-0004cd-DA for nemo@optimus.ietf.org; Thu, 25 Mar 2004 15:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18959 for ; Thu, 25 Mar 2004 15:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6bVf-0005HY-00 for nemo@ietf.org; Thu, 25 Mar 2004 15:31:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6bUg-0005F4-00 for nemo@ietf.org; Thu, 25 Mar 2004 15:30:27 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B6bTz-0005DX-00 for nemo@ietf.org; Thu, 25 Mar 2004 15:29:43 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i2PKTcpo020903; Thu, 25 Mar 2004 13:29:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2PKSNVP002306; Thu, 25 Mar 2004 14:28:41 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C99B085C46E; Thu, 25 Mar 2004 21:29:14 +0100 (CET) Message-ID: <40634113.3070905@motorola.com> Date: Thu, 25 Mar 2004 21:29:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Pascal Thubert (pthubert)" , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000007050100070506030707" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms000007050100070506030707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > => It doesn't matter for my scenario. If you need a number 2 is fine. > > and how many and what kinds of interfaces. > > => Doesn't matter what kinds of interfaces, cellular/WLAN pick one. > > Please say >> "with other LFN's" instead of "with or without other MNN's/LFN's". > > => The MR can move with an LFN (or more), with an MNN (or more), or a > mix of both. Thanks for the first two details. I've built a scenario with two MR's and two HA's and two LFN's. First they are home, and then half of the moving network moves outside the home link. In the picture below, both MR1 and MR2 are connected to their home link, which is a common link. MR1 is served by HA1 and MR2 by HA2 when they're not at home. There are two MNP's on the same moving network link. LFN1 configures its default route to go to MR1 and LFN2 its default route to go to MR2 (this could be done manually routes, or with some security features, or with virtual VLAN or with other L2 technique, or otherwise, but not NEMO stuff). HA1 and HA2 are connected to the same home link but do not maintain a HA list between them since they serve different MNP's; ---- ---- | HA1| | HA2| ---- ---- | | ---- -------------------| BR |------> Internet | | ---- ---- ----- | MR1| | MR2 | ---- ----- | | ----------moving network | | ---- ----- |LFN1| |LFN2 | ---- ----- Now the sub-segment made by MR2 and LFN2 physically splits from the moving network and becomes a moving network on its own, and goes under AR, in the picture below. After obtaining CoA, MR2 maintains a tunnel to HA2. ---- ---- | HA1| | HA2| / ---- ---- ----------/ | | ---- | | -------------------| BR |--| Internet | | ---- | | ---- ----------\ | MR1| \ ---- \ ---- Visited link | --| AR |------ -----half moving net ---- | | | ---- ---- |LFN1| | MR2| ---- ---- | half moving net ---- | ----- | LFN2| ----- I think in this configuration all works fine from the NEMO standpoint. I think the potential problem may lie in how LFN's configure different default routes; this can be done at least manually and I think that how this is done is outside the scope of NEMO. So, what do you think, am I missing something? Is anything from the NEMO Base Support that forbids this kind of split moving networks configuration to work properly? Alex --------------ms000007050100070506030707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjUyMDI5MDdaMCMGCSqGSIb3DQEJBDEWBBTcFKUm7vJ0wtS0bTgkuzLqpVBXSTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYA2r6cCVp5YnmozJvprkUHxm1WYp/QI6eaNHYnX D1ez7waozf252WEdH0Zh9ZEzIRnWK9rIej7RiuEKMCPiQx61glRzdwFeLHpzA57SVjIlJJ5m RVTOm1AS+FziBZZhofdpuBFlQUum73VF/Xr+LQPFSnBGtPr+bFqb3Qvp6YmJBwAAAAAAAA== --------------ms000007050100070506030707-- From nemo-admin@ietf.org Thu Mar 25 21:23:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09387 for ; Thu, 25 Mar 2004 21:23:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gzt-0000Wl-AQ; Thu, 25 Mar 2004 21:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gzg-0000Vy-QD for nemo@optimus.ietf.org; Thu, 25 Mar 2004 21:22:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09381 for ; Thu, 25 Mar 2004 21:22:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6gze-0007nZ-00 for nemo@ietf.org; Thu, 25 Mar 2004 21:22:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6gyi-0007jL-00 for nemo@ietf.org; Thu, 25 Mar 2004 21:21:48 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6gy5-0007cm-00 for nemo@ietf.org; Thu, 25 Mar 2004 21:21:09 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 21:20:32 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSp+hy0eLeunHTSSWg+O0ffcUWHQAL5ftw From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Pascal Thubert (pthubert)" , , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I think in this configuration all works fine from the NEMO=20 > standpoint.=20 > I think the potential problem may lie in how LFN's configure=20 > different=20 > default routes; this can be done at least manually and I=20 > think that how=20 > this is done is outside the scope of NEMO. =3D> Yes. >=20 > So, what do you think, am I missing something? Is anything from the=20 > NEMO Base Support that forbids this kind of split moving networks=20 > configuration to work properly? =3D> There is only one scenario where this configuration doesn't work, if MR1 and MR2 are assigned the same MNP. This is what I've been trying to clarify in the draft.=20 Hesham From exim@www1.ietf.org Thu Mar 25 21:25:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09573 for ; Thu, 25 Mar 2004 21:25:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6h1g-0000lA-HG for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 21:24:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q2Oq9P002914 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 21:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6h1g-0000kv-B2 for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 21:24:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09565 for ; Thu, 25 Mar 2004 21:24:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6h1d-0000Cn-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 21:24:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6h0q-000085-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 21:24:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6gzv-00002R-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 21:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gzt-0000Wl-AQ; Thu, 25 Mar 2004 21:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6gzg-0000Vy-QD for nemo@optimus.ietf.org; Thu, 25 Mar 2004 21:22:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09381 for ; Thu, 25 Mar 2004 21:22:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6gze-0007nZ-00 for nemo@ietf.org; Thu, 25 Mar 2004 21:22:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6gyi-0007jL-00 for nemo@ietf.org; Thu, 25 Mar 2004 21:21:48 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6gy5-0007cm-00 for nemo@ietf.org; Thu, 25 Mar 2004 21:21:09 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 21:20:32 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSp+hy0eLeunHTSSWg+O0ffcUWHQAL5ftw From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Pascal Thubert (pthubert)" , , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I think in this configuration all works fine from the NEMO=20 > standpoint.=20 > I think the potential problem may lie in how LFN's configure=20 > different=20 > default routes; this can be done at least manually and I=20 > think that how=20 > this is done is outside the scope of NEMO. =3D> Yes. >=20 > So, what do you think, am I missing something? Is anything from the=20 > NEMO Base Support that forbids this kind of split moving networks=20 > configuration to work properly? =3D> There is only one scenario where this configuration doesn't work, if MR1 and MR2 are assigned the same MNP. This is what I've been trying to clarify in the draft.=20 Hesham From nemo-admin@ietf.org Thu Mar 25 22:27:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12062 for ; Thu, 25 Mar 2004 22:27:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hzo-0005P7-Bq; Thu, 25 Mar 2004 22:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hza-0005Ok-GF for nemo@optimus.ietf.org; Thu, 25 Mar 2004 22:26:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12019 for ; Thu, 25 Mar 2004 22:26:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hzX-0005Mg-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:26:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6hyc-0005Hs-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:25:47 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6hxn-00058y-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:24:56 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 296465D10D for ; Fri, 26 Mar 2004 12:24:21 +0900 (JST) Date: Fri, 26 Mar 2004 12:24:10 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040326122410.76bdbab7.ernst@sfc.wide.ad.jp> In-Reply-To: <4062A2E7.9050003@motorola.com> References: <4062A2E7.9050003@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, On Thu, 25 Mar 2004 10:14:15 +0100 Alexandru Petrescu wrote: > Soliman Hesham wrote and cited T.E.: > >> Nested is when a sub-NEMO gets into a parent-NEMO; the sub-NEMO has > >> not the same prefix has the parent-NEMO and doesnt' get > >> renumbered. > > Nestedness also happens when MH visits a moving network; it's also > important to stress that the respective MR's or MH's do _not_ have the > same home link. Disagree. If I own a NEMO-wheelchair and a NEMO-car, I have the same home link for both; now I put the NEMO-wheelchair in my car, it a sub-NEMO and the car is the parent-NEMO ;-) > Whenever there's nested encapsulation to HA (i.e. at least two tunnels > encapsulated) then there's moving networks nestedness. > > >> Split-NEMO is the opposite: an aggregated prefix get split in 2 > >> separate entities. > > I really do not understand this high-level definition of an aggregated > prefix that splits in two separate entities; does it separate in two > separated "sub-prefixes"? What is a detailed example of such a split? As said in another email, everyone is welcome to write a brief definition of what split-NEMO is. The definition is to reflect the discussion in this thread and to limit the scope of how NEMO can split. Thierry. From exim@www1.ietf.org Thu Mar 25 22:38:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12495 for ; Thu, 25 Mar 2004 22:38:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iAK-00063q-6y for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 22:37:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q3bqvo023297 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 22:37:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iAJ-00063a-RL for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 22:37:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12377 for ; Thu, 25 Mar 2004 22:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6iAG-0006Kn-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 22:37:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6i8o-00062X-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 22:36:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6i7y-0005tj-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 22:35:26 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6i06-00019G-Ts for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 22:27:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hzo-0005P7-Bq; Thu, 25 Mar 2004 22:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hza-0005Ok-GF for nemo@optimus.ietf.org; Thu, 25 Mar 2004 22:26:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12019 for ; Thu, 25 Mar 2004 22:26:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hzX-0005Mg-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:26:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6hyc-0005Hs-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:25:47 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6hxn-00058y-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:24:56 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 296465D10D for ; Fri, 26 Mar 2004 12:24:21 +0900 (JST) Date: Fri, 26 Mar 2004 12:24:10 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040326122410.76bdbab7.ernst@sfc.wide.ad.jp> In-Reply-To: <4062A2E7.9050003@motorola.com> References: <4062A2E7.9050003@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, On Thu, 25 Mar 2004 10:14:15 +0100 Alexandru Petrescu wrote: > Soliman Hesham wrote and cited T.E.: > >> Nested is when a sub-NEMO gets into a parent-NEMO; the sub-NEMO has > >> not the same prefix has the parent-NEMO and doesnt' get > >> renumbered. > > Nestedness also happens when MH visits a moving network; it's also > important to stress that the respective MR's or MH's do _not_ have the > same home link. Disagree. If I own a NEMO-wheelchair and a NEMO-car, I have the same home link for both; now I put the NEMO-wheelchair in my car, it a sub-NEMO and the car is the parent-NEMO ;-) > Whenever there's nested encapsulation to HA (i.e. at least two tunnels > encapsulated) then there's moving networks nestedness. > > >> Split-NEMO is the opposite: an aggregated prefix get split in 2 > >> separate entities. > > I really do not understand this high-level definition of an aggregated > prefix that splits in two separate entities; does it separate in two > separated "sub-prefixes"? What is a detailed example of such a split? As said in another email, everyone is welcome to write a brief definition of what split-NEMO is. The definition is to reflect the discussion in this thread and to limit the scope of how NEMO can split. Thierry. From nemo-admin@ietf.org Thu Mar 25 22:53:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13107 for ; Thu, 25 Mar 2004 22:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iOy-0007Fw-St; Thu, 25 Mar 2004 22:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iOr-0007FY-25 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 22:52:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13092 for ; Thu, 25 Mar 2004 22:52:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6iOn-0007e5-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:52:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6iNu-0007ZS-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:51:54 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6iN8-0007QF-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:51:06 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id D80AE5D1F2 for ; Fri, 26 Mar 2004 12:50:36 +0900 (JST) Date: Fri, 26 Mar 2004 12:50:26 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040326125026.60ec6921.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A precision. > > > => The scenarios draft can help. > > => We need a multihoming scenarios draft, I think > there is a number of people working on it. I don't > know if it's published yet. But this : > > http://www.mobilenetworks.org/nemo/drafts/draft-multihoming-generic-goals-and > -benefits-00.txt > > is a start. Version -00 has been plublished, version -01 is pending (sometimes in April). Well, this draft is, as its names stand for, "generic", i.e. not relevant to particular NEMO issues. So, I think the new WG draft-ietf-nemo-multihoming-problem-statement under course (based on draft-ng-nemo) would be the starting doc. Thierry. From exim@www1.ietf.org Thu Mar 25 22:55:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13181 for ; Thu, 25 Mar 2004 22:55:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iQj-0007Nm-UO for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 22:54:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q3sn3C028372 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 22:54:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iQj-0007NX-PR for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 22:54:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13178 for ; Thu, 25 Mar 2004 22:54:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6iQg-0007nR-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 22:54:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6iPn-0007jy-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 22:53:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6iOx-0007fa-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 22:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iOy-0007Fw-St; Thu, 25 Mar 2004 22:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iOr-0007FY-25 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 22:52:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13092 for ; Thu, 25 Mar 2004 22:52:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6iOn-0007e5-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:52:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6iNu-0007ZS-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:51:54 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6iN8-0007QF-00 for nemo@ietf.org; Thu, 25 Mar 2004 22:51:06 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id D80AE5D1F2 for ; Fri, 26 Mar 2004 12:50:36 +0900 (JST) Date: Fri, 26 Mar 2004 12:50:26 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040326125026.60ec6921.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A precision. > > > => The scenarios draft can help. > > => We need a multihoming scenarios draft, I think > there is a number of people working on it. I don't > know if it's published yet. But this : > > http://www.mobilenetworks.org/nemo/drafts/draft-multihoming-generic-goals-and > -benefits-00.txt > > is a start. Version -00 has been plublished, version -01 is pending (sometimes in April). Well, this draft is, as its names stand for, "generic", i.e. not relevant to particular NEMO issues. So, I think the new WG draft-ietf-nemo-multihoming-problem-statement under course (based on draft-ng-nemo) would be the starting doc. Thierry. From nemo-admin@ietf.org Thu Mar 25 23:04:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13518 for ; Thu, 25 Mar 2004 23:04:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iZc-0007jv-V4; Thu, 25 Mar 2004 23:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iYk-0007hX-5J for nemo@optimus.ietf.org; Thu, 25 Mar 2004 23:03:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13436 for ; Thu, 25 Mar 2004 23:03:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6iYg-0000b9-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:03:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6iXf-0000Vi-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:02:00 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6iWk-0000Lg-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:01:03 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 734975D210 for ; Fri, 26 Mar 2004 13:00:32 +0900 (JST) Date: Fri, 26 Mar 2004 13:00:22 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040326130022.0ca53bc9.ernst@sfc.wide.ad.jp> In-Reply-To: References: <20040325151216.71b69448.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 25 Mar 2004 15:46:48 +0100 "marcelo bagnulo" wrote: > > b2. To solve ambiguousness, I would rather just say in the top of the > > document (a kind of disclaimer) than there is no warranty that NEMO > > Basic Support works with configurations other than a single NEMO-link > > attached to the Internet via one MR, i.e.: > > > > - multihomed mobile networks (8 cases, as identified by the multihomong > > problem statement, including multiple MRs) > > > > - nested mobile networks [although it's assumed it would, but test > > remains to be done - we will do it in our lab very soon] > > > > - split mobile networks > > > > and that necessary fixes may be done later. > > > I guess that it should be clearly stated in what configurations the solution > works fine and in which ones is not clear. I think we should just state "the solution is guaranteed to work in the most simple case, a single MR with a single NEMO-link and single NEMO-prefix. Other configurations may work but are not guaranteed to work. Necessary fixes are irrelevant to this present document, and may be addressed in separate documents if need exist". It's not possible to list the configurations that do not work, because: - we don't know all the possible configurations - we don't want to analyse each possible configuration (at least not now), it would take too much time - the NEMO Basic Support document would become too complex. Thierry. From exim@www1.ietf.org Thu Mar 25 23:06:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13634 for ; Thu, 25 Mar 2004 23:06:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ibP-0007rV-B9 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 23:05:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q45pTc030216 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 23:05:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ibP-0007rG-4C for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 23:05:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13623 for ; Thu, 25 Mar 2004 23:05:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ibK-0000pr-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:05:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6iaS-0000ln-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:04:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6iZa-0000hZ-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:03:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iZc-0007jv-V4; Thu, 25 Mar 2004 23:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iYk-0007hX-5J for nemo@optimus.ietf.org; Thu, 25 Mar 2004 23:03:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13436 for ; Thu, 25 Mar 2004 23:03:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6iYg-0000b9-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:03:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6iXf-0000Vi-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:02:00 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6iWk-0000Lg-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:01:03 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 734975D210 for ; Fri, 26 Mar 2004 13:00:32 +0900 (JST) Date: Fri, 26 Mar 2004 13:00:22 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040326130022.0ca53bc9.ernst@sfc.wide.ad.jp> In-Reply-To: References: <20040325151216.71b69448.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 25 Mar 2004 15:46:48 +0100 "marcelo bagnulo" wrote: > > b2. To solve ambiguousness, I would rather just say in the top of the > > document (a kind of disclaimer) than there is no warranty that NEMO > > Basic Support works with configurations other than a single NEMO-link > > attached to the Internet via one MR, i.e.: > > > > - multihomed mobile networks (8 cases, as identified by the multihomong > > problem statement, including multiple MRs) > > > > - nested mobile networks [although it's assumed it would, but test > > remains to be done - we will do it in our lab very soon] > > > > - split mobile networks > > > > and that necessary fixes may be done later. > > > I guess that it should be clearly stated in what configurations the solution > works fine and in which ones is not clear. I think we should just state "the solution is guaranteed to work in the most simple case, a single MR with a single NEMO-link and single NEMO-prefix. Other configurations may work but are not guaranteed to work. Necessary fixes are irrelevant to this present document, and may be addressed in separate documents if need exist". It's not possible to list the configurations that do not work, because: - we don't know all the possible configurations - we don't want to analyse each possible configuration (at least not now), it would take too much time - the NEMO Basic Support document would become too complex. Thierry. From nemo-admin@ietf.org Thu Mar 25 23:07:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13669 for ; Thu, 25 Mar 2004 23:07:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6icY-0007vn-EC; Thu, 25 Mar 2004 23:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6icV-0007v5-BA for nemo@optimus.ietf.org; Thu, 25 Mar 2004 23:06:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13663 for ; Thu, 25 Mar 2004 23:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6icQ-0000vD-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:06:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ibP-0000qf-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:05:52 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B6iat-0000mh-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:05:20 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2Q459p9014678; Thu, 25 Mar 2004 21:05:10 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2Q457Q20395; Fri, 26 Mar 2004 05:05:07 +0100 (MET) Date: Thu, 25 Mar 2004 16:07:54 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) To: mbagnulo@ing.uc3m.es Cc: Alexandru Petrescu , Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > No, i think that an IGP can work for this. > My concern is whether this is best option. I mean, the HA doesn't have to > discover the prefixes behind the MR since it already knows them. so using a > IGP would impose the additional burden of having to inspect the packets > looking for IGP messages and then inspecting the content of such packets. That doesn't make sense. The routing protocol messages would be addressed to the routing neighbor i.e. the address of the HA and MR respectively. > If you use a simple ping to detect reachability between the MR and the HA > you will obtain the same functionality with a lower cost, i guess. A naive implementation of that would actually double the number of packets needed for a particular failure detection time limit; each end would end up needing to ping the other every N seconds in order to declare the path dead in e.g 3N seconds; each ping in each direction implies 4 packets (request+reply in each direction). The hello protocol in an IGP uses half as many packets since both ends find out whether the peer has heard them (there is a "I heard you" bit in the hello messages; each end sends a packet every N seconds. > Of course, IGP are already there. Yes, and reinvented wheels might not be as good as the existing wheels :-) There has been proposals for a separate "hello/reachbility test" protocols in the past, but I don't know if these proposals have seen enough traction. Erik From exim@www1.ietf.org Thu Mar 25 23:09:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13818 for ; Thu, 25 Mar 2004 23:09:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ieI-0008TN-98 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 23:08:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q48okm032565 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 23:08:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ieH-0008TA-VP for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 23:08:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13737 for ; Thu, 25 Mar 2004 23:08:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ieE-00015K-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:08:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6idN-00010n-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:07:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6icV-0000vy-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6icY-0007vn-EC; Thu, 25 Mar 2004 23:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6icV-0007v5-BA for nemo@optimus.ietf.org; Thu, 25 Mar 2004 23:06:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13663 for ; Thu, 25 Mar 2004 23:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6icQ-0000vD-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:06:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ibP-0000qf-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:05:52 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B6iat-0000mh-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:05:20 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2Q459p9014678; Thu, 25 Mar 2004 21:05:10 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2Q457Q20395; Fri, 26 Mar 2004 05:05:07 +0100 (MET) Date: Thu, 25 Mar 2004 16:07:54 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) To: mbagnulo@ing.uc3m.es Cc: Alexandru Petrescu , Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 > No, i think that an IGP can work for this. > My concern is whether this is best option. I mean, the HA doesn't have to > discover the prefixes behind the MR since it already knows them. so using a > IGP would impose the additional burden of having to inspect the packets > looking for IGP messages and then inspecting the content of such packets. That doesn't make sense. The routing protocol messages would be addressed to the routing neighbor i.e. the address of the HA and MR respectively. > If you use a simple ping to detect reachability between the MR and the HA > you will obtain the same functionality with a lower cost, i guess. A naive implementation of that would actually double the number of packets needed for a particular failure detection time limit; each end would end up needing to ping the other every N seconds in order to declare the path dead in e.g 3N seconds; each ping in each direction implies 4 packets (request+reply in each direction). The hello protocol in an IGP uses half as many packets since both ends find out whether the peer has heard them (there is a "I heard you" bit in the hello messages; each end sends a packet every N seconds. > Of course, IGP are already there. Yes, and reinvented wheels might not be as good as the existing wheels :-) There has been proposals for a separate "hello/reachbility test" protocols in the past, but I don't know if these proposals have seen enough traction. Erik From nemo-admin@ietf.org Thu Mar 25 23:21:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14399 for ; Thu, 25 Mar 2004 23:21:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iq7-0001Wi-6E; Thu, 25 Mar 2004 23:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iq3-0001Va-BD for nemo@optimus.ietf.org; Thu, 25 Mar 2004 23:20:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14393 for ; Thu, 25 Mar 2004 23:20:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6iq1-00027J-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:20:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ipF-00022M-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:20:10 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6ioY-0001sr-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:19:27 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4311F5D0E1 for ; Fri, 26 Mar 2004 13:18:57 +0900 (JST) Date: Fri, 26 Mar 2004 13:18:46 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040326131846.1a3045b9.ernst@sfc.wide.ad.jp> In-Reply-To: <4062B53B.5080200@motorola.com> References: <4062B53B.5080200@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > How can you say that a moving network will never be divided? > > Just assume it; it's like assuming that there will always be a cable on > which to communicate; if there's no such cable then there's no > communication possible at all. Here I agree with Hesham. Even if you prevent it in the spec, people will do it, because those who will set up the configuration may not be network administrators (i.e. usual people). So, it's safe to either: 1. provide solutions or hints how to do it 2. say that there is no warranty the spec will work in other cases than single MR with single NEMO-link. 1. is too complex to address in NEMO Basic Support, so I prefer 2. Other specs will fix specific cases. About stating in the spec something like, "no, you MUST NOT do it", this is simply a moot statement because it will happen anyway. Thierry. From exim@www1.ietf.org Thu Mar 25 23:23:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14472 for ; Thu, 25 Mar 2004 23:23:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6irp-0001cu-Hm for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 23:22:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q4MnMe006246 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 23:22:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6irp-0001cf-DD for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 23:22:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14450 for ; Thu, 25 Mar 2004 23:22:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6irn-0002Go-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:22:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6iqw-0002Cs-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:21:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6iq7-00028B-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 23:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iq7-0001Wi-6E; Thu, 25 Mar 2004 23:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6iq3-0001Va-BD for nemo@optimus.ietf.org; Thu, 25 Mar 2004 23:20:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14393 for ; Thu, 25 Mar 2004 23:20:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6iq1-00027J-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:20:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ipF-00022M-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:20:10 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6ioY-0001sr-00 for nemo@ietf.org; Thu, 25 Mar 2004 23:19:27 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4311F5D0E1 for ; Fri, 26 Mar 2004 13:18:57 +0900 (JST) Date: Fri, 26 Mar 2004 13:18:46 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-Id: <20040326131846.1a3045b9.ernst@sfc.wide.ad.jp> In-Reply-To: <4062B53B.5080200@motorola.com> References: <4062B53B.5080200@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > How can you say that a moving network will never be divided? > > Just assume it; it's like assuming that there will always be a cable on > which to communicate; if there's no such cable then there's no > communication possible at all. Here I agree with Hesham. Even if you prevent it in the spec, people will do it, because those who will set up the configuration may not be network administrators (i.e. usual people). So, it's safe to either: 1. provide solutions or hints how to do it 2. say that there is no warranty the spec will work in other cases than single MR with single NEMO-link. 1. is too complex to address in NEMO Basic Support, so I prefer 2. Other specs will fix specific cases. About stating in the spec something like, "no, you MUST NOT do it", this is simply a moot statement because it will happen anyway. Thierry. From nemo-admin@ietf.org Fri Mar 26 00:06:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15756 for ; Fri, 26 Mar 2004 00:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6jXc-0004PN-8T; Fri, 26 Mar 2004 00:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6jXO-0004Od-0H for nemo@optimus.ietf.org; Fri, 26 Mar 2004 00:05:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15697 for ; Fri, 26 Mar 2004 00:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6jXL-00050H-00 for nemo@ietf.org; Fri, 26 Mar 2004 00:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6jWS-0004x8-00 for nemo@ietf.org; Fri, 26 Mar 2004 00:04:49 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6jVl-0004qI-00 for nemo@ietf.org; Fri, 26 Mar 2004 00:04:05 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 00:03:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQS6cIV6WSECYYhSOKwGiRIdb4RMAABKvKw From: "Soliman Hesham" To: "Thierry Ernst" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > Just assume it; it's like assuming that there will always=20 > be a cable on > > which to communicate; if there's no such cable then there's no > > communication possible at all. >=20 > Here I agree with Hesham. Even if you prevent it in the spec, people > will do it, because those who will set up the configuration=20 > may not be > network administrators (i.e. usual people). >=20 > So, it's safe to either:=20 > 1. provide solutions or hints how to do it=20 >=20 > 2. say that there is no warranty the spec will work in other=20 > cases than > single MR with single NEMO-link. >=20 > 1. is too complex to address in NEMO Basic Support, so I=20 > prefer 2. Other > specs will fix specific cases.=20 >=20 > About stating in the spec something like, "no, you MUST NOT=20 > do it", this > is simply a moot statement because it will happen anyway. =3D> I completely agree.=20 Hesham From exim@www1.ietf.org Fri Mar 26 00:08:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15882 for ; Fri, 26 Mar 2004 00:08:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6jZN-00056d-M9 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 00:07:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q57n4q019623 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 00:07:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6jZN-00056I-Eb for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 00:07:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15860 for ; Fri, 26 Mar 2004 00:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6jZL-0005AX-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 00:07:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6jYT-00056o-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 00:06:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6jXc-00052W-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 00:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6jXc-0004PN-8T; Fri, 26 Mar 2004 00:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6jXO-0004Od-0H for nemo@optimus.ietf.org; Fri, 26 Mar 2004 00:05:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15697 for ; Fri, 26 Mar 2004 00:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6jXL-00050H-00 for nemo@ietf.org; Fri, 26 Mar 2004 00:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6jWS-0004x8-00 for nemo@ietf.org; Fri, 26 Mar 2004 00:04:49 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6jVl-0004qI-00 for nemo@ietf.org; Fri, 26 Mar 2004 00:04:05 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 00:03:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQS6cIV6WSECYYhSOKwGiRIdb4RMAABKvKw From: "Soliman Hesham" To: "Thierry Ernst" , Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Just assume it; it's like assuming that there will always=20 > be a cable on > > which to communicate; if there's no such cable then there's no > > communication possible at all. >=20 > Here I agree with Hesham. Even if you prevent it in the spec, people > will do it, because those who will set up the configuration=20 > may not be > network administrators (i.e. usual people). >=20 > So, it's safe to either:=20 > 1. provide solutions or hints how to do it=20 >=20 > 2. say that there is no warranty the spec will work in other=20 > cases than > single MR with single NEMO-link. >=20 > 1. is too complex to address in NEMO Basic Support, so I=20 > prefer 2. Other > specs will fix specific cases.=20 >=20 > About stating in the spec something like, "no, you MUST NOT=20 > do it", this > is simply a moot statement because it will happen anyway. =3D> I completely agree.=20 Hesham From nemo-admin@ietf.org Fri Mar 26 02:00:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20511 for ; Fri, 26 Mar 2004 02:00:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6lJy-0007EX-7R; Fri, 26 Mar 2004 02:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6lJs-0007Cv-CW for nemo@optimus.ietf.org; Fri, 26 Mar 2004 01:59:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19933 for ; Fri, 26 Mar 2004 01:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6lJo-00054s-00 for nemo@ietf.org; Fri, 26 Mar 2004 01:59:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6lIw-000519-00 for nemo@ietf.org; Fri, 26 Mar 2004 01:58:59 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6lIU-0004w8-00 for nemo@ietf.org; Fri, 26 Mar 2004 01:58:30 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id CF6FF5D0D9; Fri, 26 Mar 2004 15:57:59 +0900 (JST) Date: Fri, 26 Mar 2004 15:57:49 +0900 From: Thierry Ernst To: Cc: nemo@ietf.org Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Message-Id: <20040326155749.028f16bf.ernst@sfc.wide.ad.jp> In-Reply-To: References: <20040325152000.7d978c78.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 25 Mar 2004 16:59:08 +0100 "marcelo bagnulo" wrote: > Hi Thierry > > Marcelo, did you read > > > > Title : Goals and Benefits of Multihoming > > Author(s) : T. Ernst > > Filename : > > draft-multihoming-generic-goals-and-benefits-00.txt > > Pages : 16 > > Date : 2004-2-11 > > > > This document attempts to define the goals and benefits of > > multihoming for fixed and mobile hosts and routers. Those goals and > > benefits are illustrated with a set of real-life scenarios. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-bene > fits-00.txt > > Some comments. Thanks Marcelo for the comments ! We will surely take them into account. > First, have you read RFC 3582? Before writing version -00, no, after, yes. > This is multihoming goals document defined by multi6 > It is somehow different, since it has the benefits of multihoming but also > other goals that a multihoming solution should provide. > > I think that this your document provides an interesting p.o.v. since it > provides aspects more related to mobility which are not present in rfc 3582 > (since it only deals with fixed networks. Yes, but also, the document focus on the p.o.v. of the mobile entity, and the ability to switch between interfaces, which any node would be doing when IPv6 will be deployed in vehicles and at home. > A couple of specific comments. > > First, i am not sure that a multi-prefixed node should be included in the > multihomed host case. > I think that a multihomed host is a host that have multiple paths to the > internet and it has a mean to select which one to use. > so if a host has multiple interfaces, it clearly has multiple paths to the > internet and it has to select one of them > In the case of a multiprefixed host, this is not clear. IMHO you are > assuming a bit too much here. Even in the case that the host is in a > multihomed site with one prefix per isp, it is not clear for now that the > source address prefix selection performed by the host will imply the > ISP/path used to route the packet. No, it doesn't necessarily, but it may. We didn't want to forget any possibility. Also, thinking about the NEMO cases where distinct NEMO-prefix are advertised by distinct MR in the **same** mobile network, there is clearly a choice of path to be made. > I would prefer a more general definition of multihomed node, like a host > with multiple access to the Internet. I agree with this definition when we want to keep things generic, but in order to analyse the details, we needed a bit more detailed definition. > I don't really see the difference between load sharing and load balancing We either ;-) so we rephrased it in version -01. Will be published soon. > > To all, all the discussions about the "split NEMO" and "multiple MR on a > > NEMO-prefix" etc are very good input for > > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt, > > which will become a NEMO WG document in his next revision. > > > IMHO an essential part is missing in this document i.e. an identification of > the nemo specific issues of multihoming. What do you mean ? The document may not be well structured yet, but it does analyse the nemo specific issues. A part (a copy-paste from draft-charbon-nemo) is clearly focusing on those specific to NEMO Basic Support. > As i understand it, we should first identify the nemo specific issues > related with multihoming and then try to figure out if they can be addressed > using existent tools or we need new ones. At least, this is the intent of the soon-to-be-published draft-nemo-ietf-multihoming. So, we will try to make sure we do it right. > IMHO it is a complex task, but it is the relevant point here. > I think that Goals and benefits doc highlights some aspects that i am not > sure that are nemo specific, but they are more relevant in nemo > environments. Agree. That's why the bulk of people working on this draft, who are either from MIP6 or NEMO, did publish it as draft-multihoming, and not to any of the MIP6 or NEMO WG. > For instance, when you are using multiple routers to use different wireless > technologies, the problem is quite different than the one that multi6 is > dealing with. Basically in this case, the problem is much more local than > the general multi6 problem, since you need to use the link between the HA > and the MR that is available. In other words, the direct links between the > nemo and the home network is very unstable and are expected to "fail" (i.e. > not to be available) frequently- so if you find a solution that allows using > one link or the other it seems to be good enough. OTOH, because of the high > frequency of "outages" (non available links) it is very important that > communications are preserved when one link becomes unavailable > > So, i think that this is very reasonable and probably frequent scenario for > nemo, so it seems reasonable that nemo optimizes this case. That is, the > case when the direct links between the nemo and its providers are not > available. > (Note that the multi6 solution has to deal with ISP wide failure case and IX > point wide failure case and so on) > > The other point that Hesham has mentioned is that even if an alternative > link is available, perhaps this link is not good enough for preserving an > established communication. I guess that the difference here is that the > differences between the link capacities can be much more greater in nemo > than in the fixed case. so probably you need to impose more policy > enforcement mechanisms > > Well, i guess that we should work on identifying this points and then decide > what to do to provide multihoming in nemo, makes sense? That is exactly the purpose of draft-nemo-ietf-multihoming-problem-statement. Thanks, Thierry. > Regards, marcelo > > I think that the issues should be discussed in that draft, not in the > NEMO Basic Support draft. And I would support, additionaly to the > multihoming problem statement draft, another draft for "multihoming > usages". > > The problem statement draft will ... state ... all the ... problems, > while the usage draft would give a priority to the scenario which are > useful. > > I think we can agree on this way of working ? From exim@www1.ietf.org Fri Mar 26 02:02:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22392 for ; Fri, 26 Mar 2004 02:02:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6lLh-0008Kk-BT for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 02:01:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q71nWK032033 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 02:01:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6lLg-0008KN-L3 for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 02:01:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21802 for ; Fri, 26 Mar 2004 02:01:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6lLd-0005C5-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 02:01:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6lKi-00058q-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 02:00:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6lK2-00055f-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 02:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6lJy-0007EX-7R; Fri, 26 Mar 2004 02:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6lJs-0007Cv-CW for nemo@optimus.ietf.org; Fri, 26 Mar 2004 01:59:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19933 for ; Fri, 26 Mar 2004 01:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6lJo-00054s-00 for nemo@ietf.org; Fri, 26 Mar 2004 01:59:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6lIw-000519-00 for nemo@ietf.org; Fri, 26 Mar 2004 01:58:59 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6lIU-0004w8-00 for nemo@ietf.org; Fri, 26 Mar 2004 01:58:30 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id CF6FF5D0D9; Fri, 26 Mar 2004 15:57:59 +0900 (JST) Date: Fri, 26 Mar 2004 15:57:49 +0900 From: Thierry Ernst To: Cc: nemo@ietf.org Subject: Re: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs] Message-Id: <20040326155749.028f16bf.ernst@sfc.wide.ad.jp> In-Reply-To: References: <20040325152000.7d978c78.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 25 Mar 2004 16:59:08 +0100 "marcelo bagnulo" wrote: > Hi Thierry > > Marcelo, did you read > > > > Title : Goals and Benefits of Multihoming > > Author(s) : T. Ernst > > Filename : > > draft-multihoming-generic-goals-and-benefits-00.txt > > Pages : 16 > > Date : 2004-2-11 > > > > This document attempts to define the goals and benefits of > > multihoming for fixed and mobile hosts and routers. Those goals and > > benefits are illustrated with a set of real-life scenarios. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-bene > fits-00.txt > > Some comments. Thanks Marcelo for the comments ! We will surely take them into account. > First, have you read RFC 3582? Before writing version -00, no, after, yes. > This is multihoming goals document defined by multi6 > It is somehow different, since it has the benefits of multihoming but also > other goals that a multihoming solution should provide. > > I think that this your document provides an interesting p.o.v. since it > provides aspects more related to mobility which are not present in rfc 3582 > (since it only deals with fixed networks. Yes, but also, the document focus on the p.o.v. of the mobile entity, and the ability to switch between interfaces, which any node would be doing when IPv6 will be deployed in vehicles and at home. > A couple of specific comments. > > First, i am not sure that a multi-prefixed node should be included in the > multihomed host case. > I think that a multihomed host is a host that have multiple paths to the > internet and it has a mean to select which one to use. > so if a host has multiple interfaces, it clearly has multiple paths to the > internet and it has to select one of them > In the case of a multiprefixed host, this is not clear. IMHO you are > assuming a bit too much here. Even in the case that the host is in a > multihomed site with one prefix per isp, it is not clear for now that the > source address prefix selection performed by the host will imply the > ISP/path used to route the packet. No, it doesn't necessarily, but it may. We didn't want to forget any possibility. Also, thinking about the NEMO cases where distinct NEMO-prefix are advertised by distinct MR in the **same** mobile network, there is clearly a choice of path to be made. > I would prefer a more general definition of multihomed node, like a host > with multiple access to the Internet. I agree with this definition when we want to keep things generic, but in order to analyse the details, we needed a bit more detailed definition. > I don't really see the difference between load sharing and load balancing We either ;-) so we rephrased it in version -01. Will be published soon. > > To all, all the discussions about the "split NEMO" and "multiple MR on a > > NEMO-prefix" etc are very good input for > > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt, > > which will become a NEMO WG document in his next revision. > > > IMHO an essential part is missing in this document i.e. an identification of > the nemo specific issues of multihoming. What do you mean ? The document may not be well structured yet, but it does analyse the nemo specific issues. A part (a copy-paste from draft-charbon-nemo) is clearly focusing on those specific to NEMO Basic Support. > As i understand it, we should first identify the nemo specific issues > related with multihoming and then try to figure out if they can be addressed > using existent tools or we need new ones. At least, this is the intent of the soon-to-be-published draft-nemo-ietf-multihoming. So, we will try to make sure we do it right. > IMHO it is a complex task, but it is the relevant point here. > I think that Goals and benefits doc highlights some aspects that i am not > sure that are nemo specific, but they are more relevant in nemo > environments. Agree. That's why the bulk of people working on this draft, who are either from MIP6 or NEMO, did publish it as draft-multihoming, and not to any of the MIP6 or NEMO WG. > For instance, when you are using multiple routers to use different wireless > technologies, the problem is quite different than the one that multi6 is > dealing with. Basically in this case, the problem is much more local than > the general multi6 problem, since you need to use the link between the HA > and the MR that is available. In other words, the direct links between the > nemo and the home network is very unstable and are expected to "fail" (i.e. > not to be available) frequently- so if you find a solution that allows using > one link or the other it seems to be good enough. OTOH, because of the high > frequency of "outages" (non available links) it is very important that > communications are preserved when one link becomes unavailable > > So, i think that this is very reasonable and probably frequent scenario for > nemo, so it seems reasonable that nemo optimizes this case. That is, the > case when the direct links between the nemo and its providers are not > available. > (Note that the multi6 solution has to deal with ISP wide failure case and IX > point wide failure case and so on) > > The other point that Hesham has mentioned is that even if an alternative > link is available, perhaps this link is not good enough for preserving an > established communication. I guess that the difference here is that the > differences between the link capacities can be much more greater in nemo > than in the fixed case. so probably you need to impose more policy > enforcement mechanisms > > Well, i guess that we should work on identifying this points and then decide > what to do to provide multihoming in nemo, makes sense? That is exactly the purpose of draft-nemo-ietf-multihoming-problem-statement. Thanks, Thierry. > Regards, marcelo > > I think that the issues should be discussed in that draft, not in the > NEMO Basic Support draft. And I would support, additionaly to the > multihoming problem statement draft, another draft for "multihoming > usages". > > The problem statement draft will ... state ... all the ... problems, > while the usage draft would give a priority to the scenario which are > useful. > > I think we can agree on this way of working ? From nemo-admin@ietf.org Fri Mar 26 04:43:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09821 for ; Fri, 26 Mar 2004 04:43:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6nrk-0008WK-97; Fri, 26 Mar 2004 04:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6nre-0008Vz-BI for nemo@optimus.ietf.org; Fri, 26 Mar 2004 04:42:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09797 for ; Fri, 26 Mar 2004 04:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6nrb-00045U-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:42:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6nqd-0003zp-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:41:55 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1B6npk-0003uQ-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:41:00 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id i2Q9e2hs025607; Fri, 26 Mar 2004 02:40:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i2Q9eqlH004419; Fri, 26 Mar 2004 03:40:53 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 278E1855531; Fri, 26 Mar 2004 10:40:52 +0100 (CET) Message-ID: <4063FAA0.5040001@motorola.com> Date: Fri, 26 Mar 2004 10:40:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Pascal Thubert (pthubert)" , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080007010405030206040306" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms080007010405030206040306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: >> So, what do you think, am I missing something? Is anything from >> the NEMO Base Support that forbids this kind of split moving >> networks configuration to work properly? > > => There is only one scenario where this configuration doesn't work, > if MR1 and MR2 are assigned the same MNP. This is what I've been > trying to clarify in the draft. First, why would one assign the same MNP to MR1 and MR2? For failure avoidance of HA? In that case better use two MNP's. Second, even if one assigns only one MNP to both MR1 and MR2 in the figure in the preceding email, then one would still assign different Home Addresses on MR1 and MR2 respectively; and I think at that point everything still works fine from the NEMO perspective: it's just that there are two BC entries and two routing table entries. Alex --------------ms080007010405030206040306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYwOTQwNDhaMCMGCSqGSIb3DQEJBDEWBBTCoHk6t+M2Q1dgcksyXJpauWYXQjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCPNc6BxQMPcS30Fbr7a1DzFREftmqz54ED5p9s REPifPyWKnutWpd5z9oaO6GX9IdRCw6+fWZlRMU3c5qqRXEvxTAcjNun3XmKctvZY7m+0NNa G+kuNn0IYIFKaRQ5lGw58zPPykVWX09EPG+PjLg2ePVTgIkHewVzrOg8V/mNYQAAAAAAAA== --------------ms080007010405030206040306-- From exim@www1.ietf.org Fri Mar 26 04:45:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09894 for ; Fri, 26 Mar 2004 04:45:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ntb-0000BQ-Kp for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 04:45:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q9ixDq000696 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 04:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ntb-0000B9-36 for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 04:44:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09890 for ; Fri, 26 Mar 2004 04:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ntX-0004GA-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 04:44:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6nsf-0004Bk-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 04:44:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6nrq-00046t-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 04:43:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6nrk-0008WK-97; Fri, 26 Mar 2004 04:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6nre-0008Vz-BI for nemo@optimus.ietf.org; Fri, 26 Mar 2004 04:42:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09797 for ; Fri, 26 Mar 2004 04:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6nrb-00045U-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:42:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6nqd-0003zp-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:41:55 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1B6npk-0003uQ-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:41:00 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id i2Q9e2hs025607; Fri, 26 Mar 2004 02:40:03 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i2Q9eqlH004419; Fri, 26 Mar 2004 03:40:53 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 278E1855531; Fri, 26 Mar 2004 10:40:52 +0100 (CET) Message-ID: <4063FAA0.5040001@motorola.com> Date: Fri, 26 Mar 2004 10:40:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Pascal Thubert (pthubert)" , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080007010405030206040306" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms080007010405030206040306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: >> So, what do you think, am I missing something? Is anything from >> the NEMO Base Support that forbids this kind of split moving >> networks configuration to work properly? > > => There is only one scenario where this configuration doesn't work, > if MR1 and MR2 are assigned the same MNP. This is what I've been > trying to clarify in the draft. First, why would one assign the same MNP to MR1 and MR2? For failure avoidance of HA? In that case better use two MNP's. Second, even if one assigns only one MNP to both MR1 and MR2 in the figure in the preceding email, then one would still assign different Home Addresses on MR1 and MR2 respectively; and I think at that point everything still works fine from the NEMO perspective: it's just that there are two BC entries and two routing table entries. Alex --------------ms080007010405030206040306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYwOTQwNDhaMCMGCSqGSIb3DQEJBDEWBBTCoHk6t+M2Q1dgcksyXJpauWYXQjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYCPNc6BxQMPcS30Fbr7a1DzFREftmqz54ED5p9s REPifPyWKnutWpd5z9oaO6GX9IdRCw6+fWZlRMU3c5qqRXEvxTAcjNun3XmKctvZY7m+0NNa G+kuNn0IYIFKaRQ5lGw58zPPykVWX09EPG+PjLg2ePVTgIkHewVzrOg8V/mNYQAAAAAAAA== --------------ms080007010405030206040306-- From nemo-admin@ietf.org Fri Mar 26 04:55:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10109 for ; Fri, 26 Mar 2004 04:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6o3I-0000M8-Vo; Fri, 26 Mar 2004 04:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6o2M-0000KU-0H for nemo@optimus.ietf.org; Fri, 26 Mar 2004 04:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10067 for ; Fri, 26 Mar 2004 04:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6o2I-0004vU-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:53:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6o1S-0004qm-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:53:07 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6o0v-0004lG-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:52:33 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2Q9qesh015054; Fri, 26 Mar 2004 02:52:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i2Q9qUlH014583; Fri, 26 Mar 2004 03:52:31 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C658C85C46E; Fri, 26 Mar 2004 10:52:29 +0100 (CET) Message-ID: <4063FD59.6080700@motorola.com> Date: Fri, 26 Mar 2004 10:52:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: <20040325151216.71b69448.ernst@sfc.wide.ad.jp> <20040326130022.0ca53bc9.ernst@sfc.wide.ad.jp> In-Reply-To: <20040326130022.0ca53bc9.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070405070006070909030009" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms070405070006070909030009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > On Thu, 25 Mar 2004 15:46:48 +0100 "marcelo bagnulo" > wrote: > > >>> b2. To solve ambiguousness, I would rather just say in the top of >>> the document (a kind of disclaimer) than there is no warranty >>> that NEMO Basic Support works with configurations other than a >>> single NEMO-link attached to the Internet via one MR, i.e.: >>> >>> - multihomed mobile networks (8 cases, as identified by the >>> multihomong problem statement, including multiple MRs) >>> >>> - nested mobile networks [although it's assumed it would, but >>> test remains to be done - we will do it in our lab very soon] >>> >>> - split mobile networks >>> >>> and that necessary fixes may be done later. >> >> >> I guess that it should be clearly stated in what configurations the >> solution works fine and in which ones is not clear. > > > I think we should just state "the solution is guaranteed to work in > the most simple case, a single MR with a single NEMO-link and single > NEMO-prefix. Other configurations may work but are not guaranteed to > work. Necessary fixes are irrelevant to this present document, and > may be addressed in separate documents if need exist". > > It's not possible to list the configurations that do not work, > because: - we don't know all the possible configurations - we don't > want to analyse each possible configuration (at least not now), it > would take too much time - the NEMO Basic Support document would > become too complex. I agree, to me there's no need to add more explanations to the base document about which configs work and which don't. At the same time, there are several non-multi-homing configurations that _are_ known not to work with the base protocol, and they have been identified in scattered public discussions and drafts. It is also true that the number of configs to test is potentially illimited, but those that have been identified seem to me to be relatively basic. Take for example the "disconnected operation problem" where the TLMR of a nested aggregation of moving networks becomes disconnected from its AR; all hosts (be it mobile or fixed) in that aggregation can't talk to each other even though they are physically connected (they can't because HAs not available). This problem has been mentioned from the very beginning of the Monet BoF IIRC and seems very basic to me. Alex --------------ms070405070006070909030009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYwOTUyMjVaMCMGCSqGSIb3DQEJBDEWBBT7covYAWSfHNiHSrmOvI6Rer3QWzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDI8Dr9m8c4pUIjT3OzxR5j5v/zgyL3zhhYcim8 dGST9CRhPjcAqRTIlKAc89p0nL/i80Rw0T+EES+xDLEPSDPW5UlKevvpJaYjyHm+GNgkEKL9 J+y1juWmhSPGIaj+vqM+o79X+IKtUo2eswEaWJTGs/yHHgI/pMbAqjOwQ9c/4AAAAAAAAA== --------------ms070405070006070909030009-- From exim@www1.ietf.org Fri Mar 26 04:57:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10280 for ; Fri, 26 Mar 2004 04:57:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6o5B-0000Ta-0s for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 04:56:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q9uuGR001826 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 04:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6o5A-0000TN-OX for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 04:56:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10204 for ; Fri, 26 Mar 2004 04:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6o57-0005DN-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 04:56:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6o4D-000572-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 04:55:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6o3I-00051i-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 04:55:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6o3I-0000M8-Vo; Fri, 26 Mar 2004 04:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6o2M-0000KU-0H for nemo@optimus.ietf.org; Fri, 26 Mar 2004 04:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10067 for ; Fri, 26 Mar 2004 04:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6o2I-0004vU-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:53:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6o1S-0004qm-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:53:07 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6o0v-0004lG-00 for nemo@ietf.org; Fri, 26 Mar 2004 04:52:33 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2Q9qesh015054; Fri, 26 Mar 2004 02:52:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i2Q9qUlH014583; Fri, 26 Mar 2004 03:52:31 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C658C85C46E; Fri, 26 Mar 2004 10:52:29 +0100 (CET) Message-ID: <4063FD59.6080700@motorola.com> Date: Fri, 26 Mar 2004 10:52:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: <20040325151216.71b69448.ernst@sfc.wide.ad.jp> <20040326130022.0ca53bc9.ernst@sfc.wide.ad.jp> In-Reply-To: <20040326130022.0ca53bc9.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070405070006070909030009" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070405070006070909030009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > On Thu, 25 Mar 2004 15:46:48 +0100 "marcelo bagnulo" > wrote: > > >>> b2. To solve ambiguousness, I would rather just say in the top of >>> the document (a kind of disclaimer) than there is no warranty >>> that NEMO Basic Support works with configurations other than a >>> single NEMO-link attached to the Internet via one MR, i.e.: >>> >>> - multihomed mobile networks (8 cases, as identified by the >>> multihomong problem statement, including multiple MRs) >>> >>> - nested mobile networks [although it's assumed it would, but >>> test remains to be done - we will do it in our lab very soon] >>> >>> - split mobile networks >>> >>> and that necessary fixes may be done later. >> >> >> I guess that it should be clearly stated in what configurations the >> solution works fine and in which ones is not clear. > > > I think we should just state "the solution is guaranteed to work in > the most simple case, a single MR with a single NEMO-link and single > NEMO-prefix. Other configurations may work but are not guaranteed to > work. Necessary fixes are irrelevant to this present document, and > may be addressed in separate documents if need exist". > > It's not possible to list the configurations that do not work, > because: - we don't know all the possible configurations - we don't > want to analyse each possible configuration (at least not now), it > would take too much time - the NEMO Basic Support document would > become too complex. I agree, to me there's no need to add more explanations to the base document about which configs work and which don't. At the same time, there are several non-multi-homing configurations that _are_ known not to work with the base protocol, and they have been identified in scattered public discussions and drafts. It is also true that the number of configs to test is potentially illimited, but those that have been identified seem to me to be relatively basic. Take for example the "disconnected operation problem" where the TLMR of a nested aggregation of moving networks becomes disconnected from its AR; all hosts (be it mobile or fixed) in that aggregation can't talk to each other even though they are physically connected (they can't because HAs not available). This problem has been mentioned from the very beginning of the Monet BoF IIRC and seems very basic to me. Alex --------------ms070405070006070909030009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYwOTUyMjVaMCMGCSqGSIb3DQEJBDEWBBT7covYAWSfHNiHSrmOvI6Rer3QWzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYDI8Dr9m8c4pUIjT3OzxR5j5v/zgyL3zhhYcim8 dGST9CRhPjcAqRTIlKAc89p0nL/i80Rw0T+EES+xDLEPSDPW5UlKevvpJaYjyHm+GNgkEKL9 J+y1juWmhSPGIaj+vqM+o79X+IKtUo2eswEaWJTGs/yHHgI/pMbAqjOwQ9c/4AAAAAAAAA== --------------ms070405070006070909030009-- From nemo-admin@ietf.org Fri Mar 26 05:10:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10766 for ; Fri, 26 Mar 2004 05:10:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oHp-00017e-7c; Fri, 26 Mar 2004 05:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oGv-00016X-Rv for nemo@optimus.ietf.org; Fri, 26 Mar 2004 05:09:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10742 for ; Fri, 26 Mar 2004 05:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6oGs-0006Gx-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:09:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6oG0-0006BN-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:08:09 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6oFa-00065K-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:07:42 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 05:07:11 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTFnL0EYwyMmGqRqyIR5bvdqMzsAAAhzbg From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Pascal Thubert (pthubert)" , , "IETF NEMO WG" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Soliman Hesham wrote: > >> So, what do you think, am I missing something? Is anything from=20 > >> the NEMO Base Support that forbids this kind of split moving=20 > >> networks configuration to work properly? > >=20 > > =3D> There is only one scenario where this configuration=20 > doesn't work,=20 > > if MR1 and MR2 are assigned the same MNP. This is what I've been=20 > > trying to clarify in the draft. >=20 > First, why would one assign the same MNP to MR1 and MR2? For failure > avoidance of HA? In that case better use two MNP's. =3D> Pascal put the case for this scenario, have another look at the thread from the beginning (about a week ago). I'm not sure it's needed. >=20 > Second, even if one assigns only one MNP to both MR1 and MR2 in the > figure in the preceding email, then one would still assign different > Home Addresses on MR1 and MR2 respectively; and I think at that point > everything still works fine from the NEMO perspective: it's just that > there are two BC entries and two routing table entries. =3D> No no, the network is split you don't know where to forward LFN1's traffic, to MR1 or MR2? Hesham From exim@www1.ietf.org Fri Mar 26 05:12:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10883 for ; Fri, 26 Mar 2004 05:12:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oJh-0001Fy-Gj for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 05:11:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QABvVG004830 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 05:11:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oJg-0001Fp-Qt for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 05:11:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10864 for ; Fri, 26 Mar 2004 05:11:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6oJd-0006X2-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:11:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6oIj-0006Rs-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:10:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6oHp-0006MC-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oHp-00017e-7c; Fri, 26 Mar 2004 05:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oGv-00016X-Rv for nemo@optimus.ietf.org; Fri, 26 Mar 2004 05:09:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10742 for ; Fri, 26 Mar 2004 05:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6oGs-0006Gx-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:09:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6oG0-0006BN-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:08:09 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6oFa-00065K-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:07:42 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 05:07:11 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTFnL0EYwyMmGqRqyIR5bvdqMzsAAAhzbg From: "Soliman Hesham" To: "Alexandru Petrescu" Cc: "Pascal Thubert (pthubert)" , , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Soliman Hesham wrote: > >> So, what do you think, am I missing something? Is anything from=20 > >> the NEMO Base Support that forbids this kind of split moving=20 > >> networks configuration to work properly? > >=20 > > =3D> There is only one scenario where this configuration=20 > doesn't work,=20 > > if MR1 and MR2 are assigned the same MNP. This is what I've been=20 > > trying to clarify in the draft. >=20 > First, why would one assign the same MNP to MR1 and MR2? For failure > avoidance of HA? In that case better use two MNP's. =3D> Pascal put the case for this scenario, have another look at the thread from the beginning (about a week ago). I'm not sure it's needed. >=20 > Second, even if one assigns only one MNP to both MR1 and MR2 in the > figure in the preceding email, then one would still assign different > Home Addresses on MR1 and MR2 respectively; and I think at that point > everything still works fine from the NEMO perspective: it's just that > there are two BC entries and two routing table entries. =3D> No no, the network is split you don't know where to forward LFN1's traffic, to MR1 or MR2? Hesham From nemo-admin@ietf.org Fri Mar 26 05:26:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11325 for ; Fri, 26 Mar 2004 05:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oXJ-0001gz-5k; Fri, 26 Mar 2004 05:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oXI-0001gR-5A for nemo@optimus.ietf.org; Fri, 26 Mar 2004 05:26:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11312 for ; Fri, 26 Mar 2004 05:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6oXE-00003Y-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6oWQ-0007mN-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:25:07 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6oVh-0007h9-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:24:21 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2QAOOsh026163; Fri, 26 Mar 2004 03:24:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i2QAOENa003841; Fri, 26 Mar 2004 04:24:15 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2411E85C46E; Fri, 26 Mar 2004 11:24:14 +0100 (CET) Message-ID: <406404C7.1020503@motorola.com> Date: Fri, 26 Mar 2004 11:24:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Pascal Thubert (pthubert)" , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050102080807060005090502" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms050102080807060005090502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: >> Soliman Hesham wrote: >>>> So, what do you think, am I missing something? Is anything >>>> from the NEMO Base Support that forbids this kind of split >>>> moving networks configuration to work properly? >>> >>> => There is only one scenario where this configuration >> doesn't work, >>> if MR1 and MR2 are assigned the same MNP. This is what I've been >>> trying to clarify in the draft. >> >> First, why would one assign the same MNP to MR1 and MR2? For >> failure avoidance of HA? In that case better use two MNP's. > > => Pascal put the case for this scenario, have another look at the > thread from the beginning (about a week ago). I'm not sure it's > needed. > >> >> Second, even if one assigns only one MNP to both MR1 and MR2 in the >> figure in the preceding email, then one would still assign >> different Home Addresses on MR1 and MR2 respectively; and I think >> at that point everything still works fine from the NEMO >> perspective: it's just that there are two BC entries and two >> routing table entries. > > => No no, the network is split you don't know where to forward LFN1's > traffic, to MR1 or MR2? We don't seem to, or I don't seem to, understand. When the network is split, LFN1 can only be at one place at one time (it can not be both behind MR1 and behind MR2 simultaneously, the network is split, this is no quantum mechanics here). So LFN1 is only behind MR1. If MR1's Home Address comes before MR2's Home Address (in HA's rt table) then LFN1 gets the packet, otherwise it doesn't. And if it doesn't then there's a configuration problem. And then re-configure by re-assigning different MNP's to MR1 and MR2. Again, this problem happens whenever a router has two rt entries towards the same prefix but different nxt hop gw (and no dynamic rt protocol). This problem and its solution is not NEMO specific I think. Alex --------------ms050102080807060005090502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYxMDI0MDdaMCMGCSqGSIb3DQEJBDEWBBR86o8qFkKnmf+W8pW5X/E7kYQirjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAo1kV8NiqClQTlBzaqUuiaiwNQNkpyliFzXaG5 D0ylx5psU4/nCieUCsHVj8a+mOTEiLkhHLlh8U4+tlsHLQ5Ljm5GyWtTMTxC+sqOW03AZ2Da OjS6DUT4dZUP/0Dja3Rhh07cZ0GhxS99ht0iYVxXbCngvZviWdl/hp+pVvwk+wAAAAAAAA== --------------ms050102080807060005090502-- From exim@www1.ietf.org Fri Mar 26 05:28:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11473 for ; Fri, 26 Mar 2004 05:28:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oZE-0001p2-EO for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 05:28:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QAS0wf006997 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 05:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oZE-0001om-6b for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 05:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11414 for ; Fri, 26 Mar 2004 05:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6oZA-0000G8-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:27:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6oYG-00009y-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:27:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6oXJ-00004U-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oXJ-0001gz-5k; Fri, 26 Mar 2004 05:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6oXI-0001gR-5A for nemo@optimus.ietf.org; Fri, 26 Mar 2004 05:26:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11312 for ; Fri, 26 Mar 2004 05:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6oXE-00003Y-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6oWQ-0007mN-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:25:07 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6oVh-0007h9-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:24:21 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2QAOOsh026163; Fri, 26 Mar 2004 03:24:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i2QAOENa003841; Fri, 26 Mar 2004 04:24:15 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2411E85C46E; Fri, 26 Mar 2004 11:24:14 +0100 (CET) Message-ID: <406404C7.1020503@motorola.com> Date: Fri, 26 Mar 2004 11:24:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Pascal Thubert (pthubert)" , mbagnulo@ing.uc3m.es, IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050102080807060005090502" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms050102080807060005090502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Soliman Hesham wrote: >> Soliman Hesham wrote: >>>> So, what do you think, am I missing something? Is anything >>>> from the NEMO Base Support that forbids this kind of split >>>> moving networks configuration to work properly? >>> >>> => There is only one scenario where this configuration >> doesn't work, >>> if MR1 and MR2 are assigned the same MNP. This is what I've been >>> trying to clarify in the draft. >> >> First, why would one assign the same MNP to MR1 and MR2? For >> failure avoidance of HA? In that case better use two MNP's. > > => Pascal put the case for this scenario, have another look at the > thread from the beginning (about a week ago). I'm not sure it's > needed. > >> >> Second, even if one assigns only one MNP to both MR1 and MR2 in the >> figure in the preceding email, then one would still assign >> different Home Addresses on MR1 and MR2 respectively; and I think >> at that point everything still works fine from the NEMO >> perspective: it's just that there are two BC entries and two >> routing table entries. > > => No no, the network is split you don't know where to forward LFN1's > traffic, to MR1 or MR2? We don't seem to, or I don't seem to, understand. When the network is split, LFN1 can only be at one place at one time (it can not be both behind MR1 and behind MR2 simultaneously, the network is split, this is no quantum mechanics here). So LFN1 is only behind MR1. If MR1's Home Address comes before MR2's Home Address (in HA's rt table) then LFN1 gets the packet, otherwise it doesn't. And if it doesn't then there's a configuration problem. And then re-configure by re-assigning different MNP's to MR1 and MR2. Again, this problem happens whenever a router has two rt entries towards the same prefix but different nxt hop gw (and no dynamic rt protocol). This problem and its solution is not NEMO specific I think. Alex --------------ms050102080807060005090502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYxMDI0MDdaMCMGCSqGSIb3DQEJBDEWBBR86o8qFkKnmf+W8pW5X/E7kYQirjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAo1kV8NiqClQTlBzaqUuiaiwNQNkpyliFzXaG5 D0ylx5psU4/nCieUCsHVj8a+mOTEiLkhHLlh8U4+tlsHLQ5Ljm5GyWtTMTxC+sqOW03AZ2Da OjS6DUT4dZUP/0Dja3Rhh07cZ0GhxS99ht0iYVxXbCngvZviWdl/hp+pVvwk+wAAAAAAAA== --------------ms050102080807060005090502-- From nemo-admin@ietf.org Fri Mar 26 05:50:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12283 for ; Fri, 26 Mar 2004 05:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ouX-0002sE-SQ; Fri, 26 Mar 2004 05:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ouS-0002rT-2C for nemo@optimus.ietf.org; Fri, 26 Mar 2004 05:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12270 for ; Fri, 26 Mar 2004 05:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ouO-0002OJ-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:49:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6otR-0002Ja-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:48:54 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6osb-0002A8-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:48:01 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2004 02:55:11 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2QAk6so027241; Fri, 26 Mar 2004 11:46:59 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 26 Mar 2004 10:47:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 10:47:10 -0000 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTFnL0EYwyMmGqRqyIR5bvdqMzsAAAhzbgAAB+N4A= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Alexandru Petrescu" Cc: , "IETF NEMO WG" X-OriginalArrivalTime: 26 Mar 2004 10:47:26.0503 (UTC) FILETIME=[BA60B370:01C4131F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > First, why would one assign the same MNP to MR1 and MR2? For failure > > avoidance of HA? In that case better use two MNP's. >=20 > =3D> Pascal put the case for this scenario, have another > look at the thread from the beginning (about a week > ago). I'm not sure it's needed. Yes, I think a whole length of the initial discussion was that we had different scenarii in mind. My scenario was based on the train model that Erik proposed on the list a looong time ago, and that I called shinkansen (for that reason) in the multihoming discussion. Basically, a mobile Network has 2 MRs for high availability and load balancing purposes.=20 It took some time for me to figure out that Hesham was on a different line of thought. I recognized the situation buy remembering a discussion in Yokohama where he mentioned an ingress link being shared by 2 unrelated MRs (like MRs opportunistically using a fixed AP as an ingress link).=20 This really was not my model -because of the variety of problems involved, not because of use case validity, though-. I see such a support as very far fetched, maybe like a ultimate goal. But there's a long long way to go to get there, as I see every day in my lab. If a LFN as a chance to see a second MR, it may (and does often) decide to use it. When the second MR goes, the LFN is disrupted. The LFNs we have at hand have no clever NUD or SAS. They can not easily do their own DNA. And anyway all sessions started with an address from an MR that's gone would be lost even if they did.=20 Nemo aims at keeping LFNs sessions active while the MR moves. As of today this means that the MR moves together with all the LFNS that use an address from that MR's MNP. Having a second MR on the same MNP / same ingress link is nothing new. But all the LFNs move with that second MR for the same reasons. This implies that the whole system moves together. This is not a use case. This is not a goal. This is the limitation of today's overall technology. =20 Nemo does not specify anything one way or the other. If we want a walkman to use either a personal router, a car router or a home router, you make the walkman a mobile node. This does not depend on whether the car router is mobile and the home router is not. This has to do with the fact that the walkman changes its point of attachment. In conclusion, Nemo provides today with the mobility of a system. I used the word atomic several times for some reasons. If you want to divide the system into subsystems, each subsystem needs to handle its own mobility. So we'll end up with many, small and nested subsystems, maybe more then we may imagine initially.=20 * This is why supporting loopless nesting is critical * Some time from now, I'd not be too surprised if: * My Home network (I mean the IP network in my house) is a Nemo Home network for all my mobile toys * And it is a mobile network as well from my ISP standpoint, mostly for management purposes. Thus the mobile Home model in the home usage draft... Pascal From exim@www1.ietf.org Fri Mar 26 05:52:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12423 for ; Fri, 26 Mar 2004 05:52:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6owQ-0002zs-5j for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 05:51:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QApw4S011514 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 05:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6owP-0002zd-Rk for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 05:51:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12382 for ; Fri, 26 Mar 2004 05:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6owM-0002cA-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:51:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ovV-0002We-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:51:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6ouY-0002QT-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ouX-0002sE-SQ; Fri, 26 Mar 2004 05:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ouS-0002rT-2C for nemo@optimus.ietf.org; Fri, 26 Mar 2004 05:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12270 for ; Fri, 26 Mar 2004 05:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ouO-0002OJ-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:49:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6otR-0002Ja-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:48:54 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6osb-0002A8-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:48:01 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2004 02:55:11 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2QAk6so027241; Fri, 26 Mar 2004 11:46:59 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 26 Mar 2004 10:47:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 10:47:10 -0000 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTFnL0EYwyMmGqRqyIR5bvdqMzsAAAhzbgAAB+N4A= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Alexandru Petrescu" Cc: , "IETF NEMO WG" X-OriginalArrivalTime: 26 Mar 2004 10:47:26.0503 (UTC) FILETIME=[BA60B370:01C4131F] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > First, why would one assign the same MNP to MR1 and MR2? For failure > > avoidance of HA? In that case better use two MNP's. >=20 > =3D> Pascal put the case for this scenario, have another > look at the thread from the beginning (about a week > ago). I'm not sure it's needed. Yes, I think a whole length of the initial discussion was that we had different scenarii in mind. My scenario was based on the train model that Erik proposed on the list a looong time ago, and that I called shinkansen (for that reason) in the multihoming discussion. Basically, a mobile Network has 2 MRs for high availability and load balancing purposes.=20 It took some time for me to figure out that Hesham was on a different line of thought. I recognized the situation buy remembering a discussion in Yokohama where he mentioned an ingress link being shared by 2 unrelated MRs (like MRs opportunistically using a fixed AP as an ingress link).=20 This really was not my model -because of the variety of problems involved, not because of use case validity, though-. I see such a support as very far fetched, maybe like a ultimate goal. But there's a long long way to go to get there, as I see every day in my lab. If a LFN as a chance to see a second MR, it may (and does often) decide to use it. When the second MR goes, the LFN is disrupted. The LFNs we have at hand have no clever NUD or SAS. They can not easily do their own DNA. And anyway all sessions started with an address from an MR that's gone would be lost even if they did.=20 Nemo aims at keeping LFNs sessions active while the MR moves. As of today this means that the MR moves together with all the LFNS that use an address from that MR's MNP. Having a second MR on the same MNP / same ingress link is nothing new. But all the LFNs move with that second MR for the same reasons. This implies that the whole system moves together. This is not a use case. This is not a goal. This is the limitation of today's overall technology. =20 Nemo does not specify anything one way or the other. If we want a walkman to use either a personal router, a car router or a home router, you make the walkman a mobile node. This does not depend on whether the car router is mobile and the home router is not. This has to do with the fact that the walkman changes its point of attachment. In conclusion, Nemo provides today with the mobility of a system. I used the word atomic several times for some reasons. If you want to divide the system into subsystems, each subsystem needs to handle its own mobility. So we'll end up with many, small and nested subsystems, maybe more then we may imagine initially.=20 * This is why supporting loopless nesting is critical * Some time from now, I'd not be too surprised if: * My Home network (I mean the IP network in my house) is a Nemo Home network for all my mobile toys * And it is a mobile network as well from my ISP standpoint, mostly for management purposes. Thus the mobile Home model in the home usage draft... Pascal From nemo-admin@ietf.org Fri Mar 26 05:57:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12564 for ; Fri, 26 Mar 2004 05:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6p1I-00039U-U9; Fri, 26 Mar 2004 05:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6p0J-00038I-TY for nemo@optimus.ietf.org; Fri, 26 Mar 2004 05:55:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12507 for ; Fri, 26 Mar 2004 05:55:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6p0F-0002wh-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:55:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ozO-0002sH-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:55:02 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6oyz-0002nW-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:54:37 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 556D71B47D; Fri, 26 Mar 2004 11:54:07 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 2B1B01B50F; Fri, 26 Mar 2004 11:54:07 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" , "Soliman Hesham" Cc: "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 11:51:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40634113.3070905@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Thanks for the first two details. I've built a scenario with two MR's > and two HA's and two LFN's. First they are home, and then half of the > moving network moves outside the home link. > > In the picture below, both MR1 and MR2 are connected to their home link, > which is a common link. MR1 is served by HA1 and MR2 by HA2 when they're > not at home. There are two MNP's on the same moving network link. LFN1 > configures its default route to go to MR1 and LFN2 its default route to > go to MR2 (this could be done manually routes, or with some security > features, or with virtual VLAN or with other L2 technique, or otherwise, > but not NEMO stuff). > > HA1 and HA2 are connected to the same home link but do not maintain a HA > list between them since they serve different MNP's; > > ---- ---- > | HA1| | HA2| > ---- ---- > | | ---- > -------------------| BR |------> Internet > | | ---- > ---- ----- > | MR1| | MR2 | > ---- ----- > | | > ----------moving network > | | > ---- ----- > |LFN1| |LFN2 | > ---- ----- > > Now the sub-segment made by MR2 and LFN2 physically splits from the > moving network and becomes a moving network on its own, and goes under > AR, in the picture below. After obtaining CoA, MR2 maintains a tunnel to > HA2. > > ---- ---- > | HA1| | HA2| / > ---- ---- ----------/ > | | ---- | | > -------------------| BR |--| Internet | > | ---- | | > ---- ----------\ > | MR1| \ > ---- \ ---- Visited link > | --| AR |------ > -----half moving net ---- | > | | > ---- ---- > |LFN1| | MR2| > ---- ---- > | > half moving net ---- > | > ----- > | LFN2| > ----- > > I think in this configuration all works fine from the NEMO standpoint. > I think the potential problem may lie in how LFN's configure different > default routes; this can be done at least manually and I think that how > this is done is outside the scope of NEMO. Question, does the MR2 and MR1 register the same prefix or different prefixes? Do the MNN have one or two prefixes? If they have one, how do you know whether to forward packets to HA1 or to HA2 when they are split? If they have 2 prefixes, hpw does this works when the network is not split but one of the MR is down? Note that if MNN only can use one MR with its correspondent prefix, this is not really one NEMO, but two nemos moving together, i guess. Regards, marcelo > > So, what do you think, am I missing something? Is anything from the > NEMO Base Support that forbids this kind of split moving networks > configuration to work properly? > > Alex > From exim@www1.ietf.org Fri Mar 26 05:59:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12672 for ; Fri, 26 Mar 2004 05:59:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6p3B-0003Ho-CC for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 05:58:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QAwv7k012626 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 05:58:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6p3B-0003HZ-6K for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 05:58:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12643 for ; Fri, 26 Mar 2004 05:58:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6p37-0003Fq-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:58:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6p2B-000397-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:57:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6p1H-00032P-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 05:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6p1I-00039U-U9; Fri, 26 Mar 2004 05:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6p0J-00038I-TY for nemo@optimus.ietf.org; Fri, 26 Mar 2004 05:55:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12507 for ; Fri, 26 Mar 2004 05:55:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6p0F-0002wh-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:55:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ozO-0002sH-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:55:02 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6oyz-0002nW-00 for nemo@ietf.org; Fri, 26 Mar 2004 05:54:37 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 556D71B47D; Fri, 26 Mar 2004 11:54:07 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id 2B1B01B50F; Fri, 26 Mar 2004 11:54:07 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" , "Soliman Hesham" Cc: "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 11:51:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40634113.3070905@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Thanks for the first two details. I've built a scenario with two MR's > and two HA's and two LFN's. First they are home, and then half of the > moving network moves outside the home link. > > In the picture below, both MR1 and MR2 are connected to their home link, > which is a common link. MR1 is served by HA1 and MR2 by HA2 when they're > not at home. There are two MNP's on the same moving network link. LFN1 > configures its default route to go to MR1 and LFN2 its default route to > go to MR2 (this could be done manually routes, or with some security > features, or with virtual VLAN or with other L2 technique, or otherwise, > but not NEMO stuff). > > HA1 and HA2 are connected to the same home link but do not maintain a HA > list between them since they serve different MNP's; > > ---- ---- > | HA1| | HA2| > ---- ---- > | | ---- > -------------------| BR |------> Internet > | | ---- > ---- ----- > | MR1| | MR2 | > ---- ----- > | | > ----------moving network > | | > ---- ----- > |LFN1| |LFN2 | > ---- ----- > > Now the sub-segment made by MR2 and LFN2 physically splits from the > moving network and becomes a moving network on its own, and goes under > AR, in the picture below. After obtaining CoA, MR2 maintains a tunnel to > HA2. > > ---- ---- > | HA1| | HA2| / > ---- ---- ----------/ > | | ---- | | > -------------------| BR |--| Internet | > | ---- | | > ---- ----------\ > | MR1| \ > ---- \ ---- Visited link > | --| AR |------ > -----half moving net ---- | > | | > ---- ---- > |LFN1| | MR2| > ---- ---- > | > half moving net ---- > | > ----- > | LFN2| > ----- > > I think in this configuration all works fine from the NEMO standpoint. > I think the potential problem may lie in how LFN's configure different > default routes; this can be done at least manually and I think that how > this is done is outside the scope of NEMO. Question, does the MR2 and MR1 register the same prefix or different prefixes? Do the MNN have one or two prefixes? If they have one, how do you know whether to forward packets to HA1 or to HA2 when they are split? If they have 2 prefixes, hpw does this works when the network is not split but one of the MR is down? Note that if MNN only can use one MR with its correspondent prefix, this is not really one NEMO, but two nemos moving together, i guess. Regards, marcelo > > So, what do you think, am I missing something? Is anything from the > NEMO Base Support that forbids this kind of split moving networks > configuration to work properly? > > Alex > From nemo-admin@ietf.org Fri Mar 26 06:52:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14817 for ; Fri, 26 Mar 2004 06:52:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6psX-0006Kq-C2; Fri, 26 Mar 2004 06:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6prd-0006Iv-QO for nemo@optimus.ietf.org; Fri, 26 Mar 2004 06:51:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14784 for ; Fri, 26 Mar 2004 06:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6prZ-0000OV-00 for nemo@ietf.org; Fri, 26 Mar 2004 06:51:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6pqi-0000Jv-00 for nemo@ietf.org; Fri, 26 Mar 2004 06:50:09 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6pqI-0000ET-00 for nemo@ietf.org; Fri, 26 Mar 2004 06:49:42 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 38A751B3FE; Fri, 26 Mar 2004 12:49:11 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id CEC291BE21; Fri, 26 Mar 2004 12:04:11 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Alexandru Petrescu" , "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Date: Fri, 26 Mar 2004 12:01:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > No, i think that an IGP can work for this. > > My concern is whether this is best option. I mean, the HA > doesn't have to > > discover the prefixes behind the MR since it already knows > them. so using a > > IGP would impose the additional burden of having to inspect the packets > > looking for IGP messages and then inspecting the content of > such packets. > > That doesn't make sense. The routing protocol messages would be addressed > to the routing neighbor i.e. the address of the HA and MR respectively. You are right, it doesn't. Thanks for clearing my confusion. > > > If you use a simple ping to detect reachability between the MR > and the HA > > you will obtain the same functionality with a lower cost, i guess. > > A naive implementation of that would actually double the number of > packets needed for a particular failure detection time limit; > each end would > end up needing to ping the other every N seconds in order to declare the > path dead in e.g 3N seconds; each ping in each direction implies 4 packets > (request+reply in each direction). > The hello protocol in an IGP uses half as many packets since both ends > find out whether the peer has heard them (there is a "I heard you" bit in > the hello messages; each end sends a packet every N seconds. > > > Of course, IGP are already there. > > Yes, and reinvented wheels might not be as good as the existing wheels :-) > > There has been proposals for a separate "hello/reachbility test" protocols > in the past, but I don't know if these proposals have seen enough > traction. Yes, i was more worried becuase of my bogus need to inspect all packets. I guess that an IGP would do just fine here. Regards, marcelo > > Erik > > From exim@www1.ietf.org Fri Mar 26 06:54:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14892 for ; Fri, 26 Mar 2004 06:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6puV-0006TU-Vg for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 06:54:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QBs344024882 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 06:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6puV-0006TA-LN for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 06:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14886 for ; Fri, 26 Mar 2004 06:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6puR-0000dG-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 06:53:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ptU-0000YH-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 06:53:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6psh-0000Th-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 06:52:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6psX-0006Kq-C2; Fri, 26 Mar 2004 06:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6prd-0006Iv-QO for nemo@optimus.ietf.org; Fri, 26 Mar 2004 06:51:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14784 for ; Fri, 26 Mar 2004 06:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6prZ-0000OV-00 for nemo@ietf.org; Fri, 26 Mar 2004 06:51:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6pqi-0000Jv-00 for nemo@ietf.org; Fri, 26 Mar 2004 06:50:09 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1B6pqI-0000ET-00 for nemo@ietf.org; Fri, 26 Mar 2004 06:49:42 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 38A751B3FE; Fri, 26 Mar 2004 12:49:11 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.216]) by smtp01.uc3m.es (Postfix) with SMTP id CEC291BE21; Fri, 26 Mar 2004 12:04:11 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Alexandru Petrescu" , "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] Re: Routing Protocol to avoid failed paths through failed links (was: DND test) Date: Fri, 26 Mar 2004 12:01:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > No, i think that an IGP can work for this. > > My concern is whether this is best option. I mean, the HA > doesn't have to > > discover the prefixes behind the MR since it already knows > them. so using a > > IGP would impose the additional burden of having to inspect the packets > > looking for IGP messages and then inspecting the content of > such packets. > > That doesn't make sense. The routing protocol messages would be addressed > to the routing neighbor i.e. the address of the HA and MR respectively. You are right, it doesn't. Thanks for clearing my confusion. > > > If you use a simple ping to detect reachability between the MR > and the HA > > you will obtain the same functionality with a lower cost, i guess. > > A naive implementation of that would actually double the number of > packets needed for a particular failure detection time limit; > each end would > end up needing to ping the other every N seconds in order to declare the > path dead in e.g 3N seconds; each ping in each direction implies 4 packets > (request+reply in each direction). > The hello protocol in an IGP uses half as many packets since both ends > find out whether the peer has heard them (there is a "I heard you" bit in > the hello messages; each end sends a packet every N seconds. > > > Of course, IGP are already there. > > Yes, and reinvented wheels might not be as good as the existing wheels :-) > > There has been proposals for a separate "hello/reachbility test" protocols > in the past, but I don't know if these proposals have seen enough > traction. Yes, i was more worried becuase of my bogus need to inspect all packets. I guess that an IGP would do just fine here. Regards, marcelo > > Erik > > From nemo-admin@ietf.org Fri Mar 26 09:40:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21974 for ; Fri, 26 Mar 2004 09:40:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sV7-0000oJ-Af; Fri, 26 Mar 2004 09:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sUK-0000lp-8O for nemo@optimus.ietf.org; Fri, 26 Mar 2004 09:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21908 for ; Fri, 26 Mar 2004 09:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6sUI-0001xx-00 for nemo@ietf.org; Fri, 26 Mar 2004 09:39:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6sTP-0001vO-00 for nemo@ietf.org; Fri, 26 Mar 2004 09:38:16 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6sSk-0001sQ-00 for nemo@ietf.org; Fri, 26 Mar 2004 09:37:34 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2QEbash028256; Fri, 26 Mar 2004 07:37:36 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i2QEbOjF022312; Fri, 26 Mar 2004 08:37:25 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7855585C46E; Fri, 26 Mar 2004 15:37:24 +0100 (CET) Message-ID: <4064401E.3060801@motorola.com> Date: Fri, 26 Mar 2004 15:37:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020403050904000208080909" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms020403050904000208080909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> ---- ---- >> | HA1| | HA2| >> ---- ---- >> | | ---- >> -------------------| BR |------> Internet >> | | ---- >> ---- ----- >> | MR1| | MR2 | >> ---- ----- >> | | >> ----------moving network >> | | >> ---- ----- >> |LFN1| |LFN2 | >> ---- ----- >> >>Now the sub-segment made by MR2 and LFN2 physically splits from the >>moving network and becomes a moving network on its own, and goes under >>AR, in the picture below. After obtaining CoA, MR2 maintains a tunnel to >>HA2. >> >> ---- ---- >> | HA1| | HA2| / >> ---- ---- ----------/ >> | | ---- | | >> -------------------| BR |--| Internet | >> | ---- | | >> ---- ----------\ >> | MR1| \ >> ---- \ ---- Visited link >> | --| AR |------ >> -----half moving net ---- | >> | | >> ---- ---- >> |LFN1| | MR2| >> ---- ---- >> | >> half moving net ---- >> | >> ----- >> | LFN2| >> ----- >> >> I think in this configuration all works fine from the NEMO >> standpoint. I think the potential problem may lie in how LFN's >> configure different default routes; this can be done at least >> manually and I think that how this is done is outside the scope of >> NEMO. > > Question, does the MR2 and MR1 register the same prefix or different > prefixes? MR1 and MR2 register different MNP's to their respective HA. > Do the MNN have one or two prefixes? In this scenario there's only LFN and each LFN autoconfigures an address from the respective MNP. > If they have one, how do you know whether to forward packets to HA1 > or to HA2 when they are split? I do not see why there should be one MNP. If the goal is to support "split" moving networks then just use two MNP's. > If they have 2 prefixes, hpw does this works when the network is not split > but one of the MR is down? If one MR1 is down then LFN1 does not get packets. If one wants to have LFN1 still get the packets when MR1 is down then there should be a means to do it. Just tell me that means (keeping both MR's at home) and I'm going to try to see how it works when MR's leave the home. > Note that if MNN only can use one MR with its correspondent prefix, > this is not really one NEMO, but two nemos moving together, i guess. Yes, there are two moving networks two MNP's two Mobile Routers; it is configured in such a way to be able to be split, is there anything wrong with this? Alex --------------ms020403050904000208080909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYxNDM3MThaMCMGCSqGSIb3DQEJBDEWBBQR8e+WUFUuTk83EK1WD5FSSwewMTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAsi9UyV1F8rcVJoLm6W1P6Uba8XRtaelpiNdDY GO4JQTHF4y+5BM9E4o0cPBC2Ln3xhQ9EJKPhwqK8RGveINRgL7jajeAvi9cwWuzzFXIHujM1 msLloF0JiRjz++/fAFZZQjtO+wKN24DErOIzqquihdqEsf7chmA3tbv0q68v5gAAAAAAAA== --------------ms020403050904000208080909-- From exim@www1.ietf.org Fri Mar 26 09:42:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22067 for ; Fri, 26 Mar 2004 09:42:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sX4-00019U-CL for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 09:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QEg2VT004427 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 09:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sX3-00019D-6q for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 09:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22047 for ; Fri, 26 Mar 2004 09:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6sX1-00024d-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 09:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6sW4-00022F-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 09:41:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6sV9-0001zR-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 09:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sV7-0000oJ-Af; Fri, 26 Mar 2004 09:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6sUK-0000lp-8O for nemo@optimus.ietf.org; Fri, 26 Mar 2004 09:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21908 for ; Fri, 26 Mar 2004 09:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6sUI-0001xx-00 for nemo@ietf.org; Fri, 26 Mar 2004 09:39:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6sTP-0001vO-00 for nemo@ietf.org; Fri, 26 Mar 2004 09:38:16 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B6sSk-0001sQ-00 for nemo@ietf.org; Fri, 26 Mar 2004 09:37:34 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2QEbash028256; Fri, 26 Mar 2004 07:37:36 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i2QEbOjF022312; Fri, 26 Mar 2004 08:37:25 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7855585C46E; Fri, 26 Mar 2004 15:37:24 +0100 (CET) Message-ID: <4064401E.3060801@motorola.com> Date: Fri, 26 Mar 2004 15:37:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Soliman Hesham , "Pascal Thubert (pthubert)" , IETF NEMO WG Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020403050904000208080909" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms020403050904000208080909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> ---- ---- >> | HA1| | HA2| >> ---- ---- >> | | ---- >> -------------------| BR |------> Internet >> | | ---- >> ---- ----- >> | MR1| | MR2 | >> ---- ----- >> | | >> ----------moving network >> | | >> ---- ----- >> |LFN1| |LFN2 | >> ---- ----- >> >>Now the sub-segment made by MR2 and LFN2 physically splits from the >>moving network and becomes a moving network on its own, and goes under >>AR, in the picture below. After obtaining CoA, MR2 maintains a tunnel to >>HA2. >> >> ---- ---- >> | HA1| | HA2| / >> ---- ---- ----------/ >> | | ---- | | >> -------------------| BR |--| Internet | >> | ---- | | >> ---- ----------\ >> | MR1| \ >> ---- \ ---- Visited link >> | --| AR |------ >> -----half moving net ---- | >> | | >> ---- ---- >> |LFN1| | MR2| >> ---- ---- >> | >> half moving net ---- >> | >> ----- >> | LFN2| >> ----- >> >> I think in this configuration all works fine from the NEMO >> standpoint. I think the potential problem may lie in how LFN's >> configure different default routes; this can be done at least >> manually and I think that how this is done is outside the scope of >> NEMO. > > Question, does the MR2 and MR1 register the same prefix or different > prefixes? MR1 and MR2 register different MNP's to their respective HA. > Do the MNN have one or two prefixes? In this scenario there's only LFN and each LFN autoconfigures an address from the respective MNP. > If they have one, how do you know whether to forward packets to HA1 > or to HA2 when they are split? I do not see why there should be one MNP. If the goal is to support "split" moving networks then just use two MNP's. > If they have 2 prefixes, hpw does this works when the network is not split > but one of the MR is down? If one MR1 is down then LFN1 does not get packets. If one wants to have LFN1 still get the packets when MR1 is down then there should be a means to do it. Just tell me that means (keeping both MR's at home) and I'm going to try to see how it works when MR's leave the home. > Note that if MNN only can use one MR with its correspondent prefix, > this is not really one NEMO, but two nemos moving together, i guess. Yes, there are two moving networks two MNP's two Mobile Routers; it is configured in such a way to be able to be split, is there anything wrong with this? Alex --------------ms020403050904000208080909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYxNDM3MThaMCMGCSqGSIb3DQEJBDEWBBQR8e+WUFUuTk83EK1WD5FSSwewMTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAsi9UyV1F8rcVJoLm6W1P6Uba8XRtaelpiNdDY GO4JQTHF4y+5BM9E4o0cPBC2Ln3xhQ9EJKPhwqK8RGveINRgL7jajeAvi9cwWuzzFXIHujM1 msLloF0JiRjz++/fAFZZQjtO+wKN24DErOIzqquihdqEsf7chmA3tbv0q68v5gAAAAAAAA== --------------ms020403050904000208080909-- From nemo-admin@ietf.org Fri Mar 26 14:27:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09657 for ; Fri, 26 Mar 2004 14:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wyq-0005KD-Au; Fri, 26 Mar 2004 14:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wy4-0005JL-3s for nemo@optimus.ietf.org; Fri, 26 Mar 2004 14:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09612 for ; Fri, 26 Mar 2004 14:26:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wy1-0007ao-00 for nemo@ietf.org; Fri, 26 Mar 2004 14:26:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wx3-0007YJ-00 for nemo@ietf.org; Fri, 26 Mar 2004 14:25:09 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B6ww7-0007UH-00 for nemo@ietf.org; Fri, 26 Mar 2004 14:24:11 -0500 Received: from MobileGravity.local.sfc.wide.ad.jp (pdd871f.tkyoac00.ap.so-net.ne.jp [218.221.135.31]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2QJMkUV021441; Sat, 27 Mar 2004 04:22:47 +0900 Date: Sat, 27 Mar 2004 04:23:26 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: Alexandru.Petrescu@motorola.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At Fri, 26 Mar 2004 05:07:11 -0500, Soliman Hesham wrote: > > > > Soliman Hesham wrote: > > >> So, what do you think, am I missing something? Is anything from > > >> the NEMO Base Support that forbids this kind of split moving > > >> networks configuration to work properly? > > > > > > => There is only one scenario where this configuration > > doesn't work, > > > if MR1 and MR2 are assigned the same MNP. This is what I've been > > > trying to clarify in the draft. > > > > First, why would one assign the same MNP to MR1 and MR2? For failure > > avoidance of HA? In that case better use two MNP's. > > => Pascal put the case for this scenario, have another > look at the thread from the beginning (about a week > ago). I'm not sure it's needed. It might be useful for vehicle's moving network. Even if we prohibit the single prefix assignment to multiple MRs as you said, we still need to confirm whether each MNP is surely assigned to single MR or not. But how? Do you think we can just treat this as configuration errors and do nothing for this? I think it is much easier to verify whether a mobile network is not split or not. HA can ask to one of MR whether the other is onlink or not (ex. check ND cache). If not, HA can reject BUs from both MRs. Of course, there isn't such operation in the basic nemo though. I do not try to propose solutions here, but I just want to say.. If NEMO can detect the split mobile network and prohibit the split mobile network, there is no problem for the same MNP configuration. Let's try not simply remove the case where same MNP is assigned to multiple MRs and wait more inputs from multihoming work of NEMO WG. ryuji > > > > Second, even if one assigns only one MNP to both MR1 and MR2 in the > > figure in the preceding email, then one would still assign different > > Home Addresses on MR1 and MR2 respectively; and I think at that point > > everything still works fine from the NEMO perspective: it's just that > > there are two BC entries and two routing table entries. > > => No no, the network is split you don't know where > to forward LFN1's traffic, to MR1 or MR2? > > Hesham > From exim@www1.ietf.org Fri Mar 26 14:28:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09717 for ; Fri, 26 Mar 2004 14:28:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6x0C-0005Tl-4R for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 14:28:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QJSOJt021061 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 14:28:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6x0B-0005Tc-U1 for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 14:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09711 for ; Fri, 26 Mar 2004 14:28:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6x09-0007iV-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 14:28:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wz8-0007ew-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 14:27:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6wyq-0007c6-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 14:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wyq-0005KD-Au; Fri, 26 Mar 2004 14:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wy4-0005JL-3s for nemo@optimus.ietf.org; Fri, 26 Mar 2004 14:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09612 for ; Fri, 26 Mar 2004 14:26:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wy1-0007ao-00 for nemo@ietf.org; Fri, 26 Mar 2004 14:26:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wx3-0007YJ-00 for nemo@ietf.org; Fri, 26 Mar 2004 14:25:09 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B6ww7-0007UH-00 for nemo@ietf.org; Fri, 26 Mar 2004 14:24:11 -0500 Received: from MobileGravity.local.sfc.wide.ad.jp (pdd871f.tkyoac00.ap.so-net.ne.jp [218.221.135.31]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2QJMkUV021441; Sat, 27 Mar 2004 04:22:47 +0900 Date: Sat, 27 Mar 2004 04:23:26 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: Alexandru.Petrescu@motorola.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At Fri, 26 Mar 2004 05:07:11 -0500, Soliman Hesham wrote: > > > > Soliman Hesham wrote: > > >> So, what do you think, am I missing something? Is anything from > > >> the NEMO Base Support that forbids this kind of split moving > > >> networks configuration to work properly? > > > > > > => There is only one scenario where this configuration > > doesn't work, > > > if MR1 and MR2 are assigned the same MNP. This is what I've been > > > trying to clarify in the draft. > > > > First, why would one assign the same MNP to MR1 and MR2? For failure > > avoidance of HA? In that case better use two MNP's. > > => Pascal put the case for this scenario, have another > look at the thread from the beginning (about a week > ago). I'm not sure it's needed. It might be useful for vehicle's moving network. Even if we prohibit the single prefix assignment to multiple MRs as you said, we still need to confirm whether each MNP is surely assigned to single MR or not. But how? Do you think we can just treat this as configuration errors and do nothing for this? I think it is much easier to verify whether a mobile network is not split or not. HA can ask to one of MR whether the other is onlink or not (ex. check ND cache). If not, HA can reject BUs from both MRs. Of course, there isn't such operation in the basic nemo though. I do not try to propose solutions here, but I just want to say.. If NEMO can detect the split mobile network and prohibit the split mobile network, there is no problem for the same MNP configuration. Let's try not simply remove the case where same MNP is assigned to multiple MRs and wait more inputs from multihoming work of NEMO WG. ryuji > > > > Second, even if one assigns only one MNP to both MR1 and MR2 in the > > figure in the preceding email, then one would still assign different > > Home Addresses on MR1 and MR2 respectively; and I think at that point > > everything still works fine from the NEMO perspective: it's just that > > there are two BC entries and two routing table entries. > > => No no, the network is split you don't know where > to forward LFN1's traffic, to MR1 or MR2? > > Hesham > From nemo-admin@ietf.org Fri Mar 26 15:10:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12038 for ; Fri, 26 Mar 2004 15:10:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6xeT-0007ZK-Ij; Fri, 26 Mar 2004 15:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6xdu-0007PY-Vx for nemo@optimus.ietf.org; Fri, 26 Mar 2004 15:09:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11881 for ; Fri, 26 Mar 2004 15:09:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6xdr-0003Fp-00 for nemo@ietf.org; Fri, 26 Mar 2004 15:09:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6xd6-0003AE-00 for nemo@ietf.org; Fri, 26 Mar 2004 15:08:37 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B6xcM-00033U-00 for nemo@ietf.org; Fri, 26 Mar 2004 15:07:50 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i2QK7Wpo028177; Fri, 26 Mar 2004 13:07:32 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2QK6MVP013294; Fri, 26 Mar 2004 14:06:27 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0700D85C46E; Fri, 26 Mar 2004 21:07:14 +0100 (CET) Message-ID: <40648D6C.90704@motorola.com> Date: Fri, 26 Mar 2004 21:07:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Cc: H.Soliman@flarion.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040806070306060805080709" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms040806070306060805080709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >>> Soliman Hesham wrote: >>>>> So, what do you think, am I missing something? Is anything >>>>> from the NEMO Base Support that forbids this kind of split >>>>> moving networks configuration to work properly? >>>> >>>> => There is only one scenario where this configuration doesn't >>>> work, if MR1 and MR2 are assigned the same MNP. This is what >>>> I've been trying to clarify in the draft. >>> >>> First, why would one assign the same MNP to MR1 and MR2? For >>> failure avoidance of HA? In that case better use two MNP's. >> >> => Pascal put the case for this scenario, have another look at the >> thread from the beginning (about a week ago). I'm not sure it's >> needed. > > It might be useful for vehicle's moving network. Ok. > Even if we prohibit the single prefix assignment to multiple MRs as > you said, we still need to confirm whether each MNP is surely > assigned to single MR or not. But how? Do you think we can just > treat this as configuration errors and do nothing for this? I think I do not propose to forbid single MNP per moving link when there are two MR's; I think that if there is only one MNP per moving link and that there are two MR's and each has a different Home Address and each maintains a different tunnel to a different HA, then a routing protocol might help to avoid loosing Internet access to any LFN on that moving link when one of the MR's looses its egress wireless connection; I think that when I'm writing that NEMO Base Support supports a moving link with one MNP on it then I'm replied "yes, but what about two MNP's"; then if I'm writing that NEMO Base Support supports a moving link with two MNP's on it then I'm replied "yes, but what about one MNP" :-) > I think it is much easier to verify whether a mobile network is not > split or not. HA can ask to one of MR whether the other is onlink or > not (ex. check ND cache). If not, HA can reject BUs from both MRs. Of > course, there isn't such operation in the basic nemo though. > > I do not try to propose solutions here, but I just want to say.. > > If NEMO can detect the split mobile network and prohibit the split > mobile network, there is no problem for the same MNP configuration. > > Let's try not simply remove the case where same MNP is assigned to > multiple MRs Yes, I agree with this, I don't propose to always have two MNP's per link; there should be one MNP per link when there are two TLMR's and they together with their HA's should use an IGP to detect whenever the egress wireless interface is lost. And, if the two TLMR's can have an IGP to detect best paths when one HA becomes unavailable, why shouldn't that IGP solve also the splitting of the moving link itself? This could work: just put a Fixed Router at the point where the split is susceptible to occur and let it find the right paths after the split. > and wait more inputs from multihoming work of NEMO WG. Yes, I do not mean to interfere with the NEMO WG multi-homing work, sorry, I think it will help clarifying multi-homing in the NEMO context. Alex --------------ms040806070306060805080709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYyMDA3MDhaMCMGCSqGSIb3DQEJBDEWBBTgwLa0GNYj+/WoQ8XnRmhwy0nsHjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYChA9kxBNJ4DLZgFtQfaXIk74CwYODpMsTaxh8D lFntTGshvK/cxfNJv+GU1GYZvXl+xE+FKT6N8dT7/oU0ph/+ctfRXp3q+iB+I7goaXUBli0z egvO/8sRMqc/AptApUrBhNr3heUOogVC+q8v1c/Bm3P0g20lMN/etIQot37yEwAAAAAAAA== --------------ms040806070306060805080709-- From exim@www1.ietf.org Fri Mar 26 15:11:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12156 for ; Fri, 26 Mar 2004 15:11:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6xfu-0008Fo-Kf for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 15:11:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QKBUk4031722 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 15:11:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6xfu-0008FZ-D2 for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 15:11:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12120 for ; Fri, 26 Mar 2004 15:11:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6xfr-0003Pc-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 15:11:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6xer-0003MC-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 15:10:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6xeX-0003IM-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 15:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6xeT-0007ZK-Ij; Fri, 26 Mar 2004 15:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6xdu-0007PY-Vx for nemo@optimus.ietf.org; Fri, 26 Mar 2004 15:09:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11881 for ; Fri, 26 Mar 2004 15:09:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6xdr-0003Fp-00 for nemo@ietf.org; Fri, 26 Mar 2004 15:09:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6xd6-0003AE-00 for nemo@ietf.org; Fri, 26 Mar 2004 15:08:37 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B6xcM-00033U-00 for nemo@ietf.org; Fri, 26 Mar 2004 15:07:50 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i2QK7Wpo028177; Fri, 26 Mar 2004 13:07:32 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i2QK6MVP013294; Fri, 26 Mar 2004 14:06:27 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0700D85C46E; Fri, 26 Mar 2004 21:07:14 +0100 (CET) Message-ID: <40648D6C.90704@motorola.com> Date: Fri, 26 Mar 2004 21:07:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Cc: H.Soliman@flarion.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040806070306060805080709" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms040806070306060805080709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >>> Soliman Hesham wrote: >>>>> So, what do you think, am I missing something? Is anything >>>>> from the NEMO Base Support that forbids this kind of split >>>>> moving networks configuration to work properly? >>>> >>>> => There is only one scenario where this configuration doesn't >>>> work, if MR1 and MR2 are assigned the same MNP. This is what >>>> I've been trying to clarify in the draft. >>> >>> First, why would one assign the same MNP to MR1 and MR2? For >>> failure avoidance of HA? In that case better use two MNP's. >> >> => Pascal put the case for this scenario, have another look at the >> thread from the beginning (about a week ago). I'm not sure it's >> needed. > > It might be useful for vehicle's moving network. Ok. > Even if we prohibit the single prefix assignment to multiple MRs as > you said, we still need to confirm whether each MNP is surely > assigned to single MR or not. But how? Do you think we can just > treat this as configuration errors and do nothing for this? I think I do not propose to forbid single MNP per moving link when there are two MR's; I think that if there is only one MNP per moving link and that there are two MR's and each has a different Home Address and each maintains a different tunnel to a different HA, then a routing protocol might help to avoid loosing Internet access to any LFN on that moving link when one of the MR's looses its egress wireless connection; I think that when I'm writing that NEMO Base Support supports a moving link with one MNP on it then I'm replied "yes, but what about two MNP's"; then if I'm writing that NEMO Base Support supports a moving link with two MNP's on it then I'm replied "yes, but what about one MNP" :-) > I think it is much easier to verify whether a mobile network is not > split or not. HA can ask to one of MR whether the other is onlink or > not (ex. check ND cache). If not, HA can reject BUs from both MRs. Of > course, there isn't such operation in the basic nemo though. > > I do not try to propose solutions here, but I just want to say.. > > If NEMO can detect the split mobile network and prohibit the split > mobile network, there is no problem for the same MNP configuration. > > Let's try not simply remove the case where same MNP is assigned to > multiple MRs Yes, I agree with this, I don't propose to always have two MNP's per link; there should be one MNP per link when there are two TLMR's and they together with their HA's should use an IGP to detect whenever the egress wireless interface is lost. And, if the two TLMR's can have an IGP to detect best paths when one HA becomes unavailable, why shouldn't that IGP solve also the splitting of the moving link itself? This could work: just put a Fixed Router at the point where the split is susceptible to occur and let it find the right paths after the split. > and wait more inputs from multihoming work of NEMO WG. Yes, I do not mean to interfere with the NEMO WG multi-homing work, sorry, I think it will help clarifying multi-homing in the NEMO context. Alex --------------ms040806070306060805080709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAz MjYyMDA3MDhaMCMGCSqGSIb3DQEJBDEWBBTgwLa0GNYj+/WoQ8XnRmhwy0nsHjBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYChA9kxBNJ4DLZgFtQfaXIk74CwYODpMsTaxh8D lFntTGshvK/cxfNJv+GU1GYZvXl+xE+FKT6N8dT7/oU0ph/+ctfRXp3q+iB+I7goaXUBli0z egvO/8sRMqc/AptApUrBhNr3heUOogVC+q8v1c/Bm3P0g20lMN/etIQot37yEwAAAAAAAA== --------------ms040806070306060805080709-- From nemo-admin@ietf.org Fri Mar 26 21:30:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04981 for ; Fri, 26 Mar 2004 21:30:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73aD-0003A2-9i; Fri, 26 Mar 2004 21:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73Zh-00038d-RG for nemo@optimus.ietf.org; Fri, 26 Mar 2004 21:29:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04939 for ; Fri, 26 Mar 2004 21:29:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B73Zf-0004uq-00 for nemo@ietf.org; Fri, 26 Mar 2004 21:29:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B73Yj-0004rS-00 for nemo@ietf.org; Fri, 26 Mar 2004 21:28:30 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B73Xr-0004jG-00 for nemo@ietf.org; Fri, 26 Mar 2004 21:27:35 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 21:26:58 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTZ9gwnWb9c2Z2TMypH5EP0CGISAAOVvyw From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: , , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > It might be useful for vehicle's moving network.=20 >=20 > Even if we prohibit the single prefix assignment to multiple MRs as > you said, we still need to confirm whether each MNP is=20 > surely assigned > to single MR or not. But how? =20 =3D> Not sure what you mean, the current spec does that. > Do you think we can just treat this as configuration errors and do > nothing for this? =3D> I'm not sure what you refer to by "this" above. >=20 > I think it is much easier to verify whether a mobile network is not > split or not. HA can ask to one of MR whether the other is onlink > or not (ex. check ND cache). If not, HA can reject BUs from both MRs. > Of course, there isn't such operation in the basic nemo though. =3D> On the surface this seems easy but not if you consider the corner cases, MR reboot, link failures....etc. I don't think it's that easy actually. >=20 > If NEMO can detect the split mobile network and prohibit the > split mobile network, there is no problem for the same MNP > configuration. =3D> I find this logic a bit skewed actually. Of course if=20 you start with shared MNPs then it follows that if we can prevent splitting then everything is ok. There is only=20 a small problem: you can't prevent splitting.=20 Hesham From exim@www1.ietf.org Fri Mar 26 21:31:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05016 for ; Fri, 26 Mar 2004 21:31:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73bc-0003IJ-Uk for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 21:31:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R2VSh5012658 for nemo-archive@odin.ietf.org; Fri, 26 Mar 2004 21:31:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73bc-0003I5-Og for nemo-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 21:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05009 for ; Fri, 26 Mar 2004 21:31:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B73ba-00052K-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 21:31:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B73af-0004z6-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 21:30:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B73aJ-0004vn-00 for nemo-web-archive@ietf.org; Fri, 26 Mar 2004 21:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73aD-0003A2-9i; Fri, 26 Mar 2004 21:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73Zh-00038d-RG for nemo@optimus.ietf.org; Fri, 26 Mar 2004 21:29:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04939 for ; Fri, 26 Mar 2004 21:29:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B73Zf-0004uq-00 for nemo@ietf.org; Fri, 26 Mar 2004 21:29:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B73Yj-0004rS-00 for nemo@ietf.org; Fri, 26 Mar 2004 21:28:30 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B73Xr-0004jG-00 for nemo@ietf.org; Fri, 26 Mar 2004 21:27:35 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Fri, 26 Mar 2004 21:26:58 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTZ9gwnWb9c2Z2TMypH5EP0CGISAAOVvyw From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > It might be useful for vehicle's moving network.=20 >=20 > Even if we prohibit the single prefix assignment to multiple MRs as > you said, we still need to confirm whether each MNP is=20 > surely assigned > to single MR or not. But how? =20 =3D> Not sure what you mean, the current spec does that. > Do you think we can just treat this as configuration errors and do > nothing for this? =3D> I'm not sure what you refer to by "this" above. >=20 > I think it is much easier to verify whether a mobile network is not > split or not. HA can ask to one of MR whether the other is onlink > or not (ex. check ND cache). If not, HA can reject BUs from both MRs. > Of course, there isn't such operation in the basic nemo though. =3D> On the surface this seems easy but not if you consider the corner cases, MR reboot, link failures....etc. I don't think it's that easy actually. >=20 > If NEMO can detect the split mobile network and prohibit the > split mobile network, there is no problem for the same MNP > configuration. =3D> I find this logic a bit skewed actually. Of course if=20 you start with shared MNPs then it follows that if we can prevent splitting then everything is ok. There is only=20 a small problem: you can't prevent splitting.=20 Hesham From nemo-admin@ietf.org Sat Mar 27 00:19:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11041 for ; Sat, 27 Mar 2004 00:19:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76Dm-0002jF-5V; Sat, 27 Mar 2004 00:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76DM-0002iw-Q3 for nemo@optimus.ietf.org; Sat, 27 Mar 2004 00:18:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11026 for ; Sat, 27 Mar 2004 00:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B76DK-0002JD-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:18:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B76CN-0002FY-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:17:36 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B76Bu-0002BK-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:17:06 -0500 Received: from [192.168.0.11] (pdd8773.tkyoac00.ap.so-net.ne.jp [218.221.135.115]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2R5FjUW025966; Sat, 27 Mar 2004 14:15:45 +0900 Date: Sat, 27 Mar 2004 14:16:49 +0900 From: Ryuji Wakikawa To: "Soliman Hesham" Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Cc: , , , In-Reply-To: References: Message-Id: <20040327134607.324C.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > > It might be useful for vehicle's moving network. > > > > Even if we prohibit the single prefix assignment to multiple MRs as > > you said, we still need to confirm whether each MNP is > > surely assigned > > to single MR or not. But how? > > => Not sure what you mean, the current spec does that. Prefix table. Yes, your are right. I am not sure the use of prefix table guarantee the 1MNP-1MR all the case. When MR has multiple egress interfaces and register each CoA with respective HoA, HA can not distinguish between the case when one MNP assigned to two MRs and the case of one MNP to multihomed MR. But we can solve the multihomed MR case with draft-wakikawa-mip6-multiplecoa-02:-) When each MR registers to different HAs, we need to verify whether prefix table of each HA is consistent or not. Well, we can use HAHA like protocol for this. > > Do you think we can just treat this as configuration errors and do > > nothing for this? > > => I'm not sure what you refer to by "this" above. the case when HA detects there are multiple MRs for the same MNP. > > > > I think it is much easier to verify whether a mobile network is not > > split or not. HA can ask to one of MR whether the other is onlink > > or not (ex. check ND cache). If not, HA can reject BUs from both MRs. > > Of course, there isn't such operation in the basic nemo though. > > => On the surface this seems easy but not if you consider > the corner cases, MR reboot, link failures....etc. > I don't think it's that easy actually. I don't see any problem here. HA does not have the binding for the MR that reboot or lost connectivity. Only when HA has multiple bindings for the same MR, it checks the split network with registered MRs. > > > > If NEMO can detect the split mobile network and prohibit the > > split mobile network, there is no problem for the same MNP > > configuration. > > => I find this logic a bit skewed actually. Of course if > you start with shared MNPs then it follows that if we can > prevent splitting then everything is ok. There is only > a small problem: you can't prevent splitting. How skewed? I think there are two options here for the splitting. The nemo prohibit the split mobile network somehow. The nemo allow the split mobile network for the same MNP (i.e. HA somehow know which LFN is located which MR and deliver packets correctly to target MR, etc) I do not see big advantages on the latter case. If we have detection mechanism of splitting, nemo can support the configuration of the 1MNP to more than 1 MRs. ryuji From exim@www1.ietf.org Sat Mar 27 00:21:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11096 for ; Sat, 27 Mar 2004 00:21:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76FG-0002rS-4V for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 00:20:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R5KYeP010997 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 00:20:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76FF-0002rI-PG for nemo-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 00:20:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11081 for ; Sat, 27 Mar 2004 00:20:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B76FD-0002RJ-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 00:20:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B76EI-0002NX-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 00:19:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B76Dq-0002Jr-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 00:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76Dm-0002jF-5V; Sat, 27 Mar 2004 00:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76DM-0002iw-Q3 for nemo@optimus.ietf.org; Sat, 27 Mar 2004 00:18:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11026 for ; Sat, 27 Mar 2004 00:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B76DK-0002JD-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:18:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B76CN-0002FY-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:17:36 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B76Bu-0002BK-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:17:06 -0500 Received: from [192.168.0.11] (pdd8773.tkyoac00.ap.so-net.ne.jp [218.221.135.115]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2R5FjUW025966; Sat, 27 Mar 2004 14:15:45 +0900 Date: Sat, 27 Mar 2004 14:16:49 +0900 From: Ryuji Wakikawa To: "Soliman Hesham" Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Cc: , , , In-Reply-To: References: Message-Id: <20040327134607.324C.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > It might be useful for vehicle's moving network. > > > > Even if we prohibit the single prefix assignment to multiple MRs as > > you said, we still need to confirm whether each MNP is > > surely assigned > > to single MR or not. But how? > > => Not sure what you mean, the current spec does that. Prefix table. Yes, your are right. I am not sure the use of prefix table guarantee the 1MNP-1MR all the case. When MR has multiple egress interfaces and register each CoA with respective HoA, HA can not distinguish between the case when one MNP assigned to two MRs and the case of one MNP to multihomed MR. But we can solve the multihomed MR case with draft-wakikawa-mip6-multiplecoa-02:-) When each MR registers to different HAs, we need to verify whether prefix table of each HA is consistent or not. Well, we can use HAHA like protocol for this. > > Do you think we can just treat this as configuration errors and do > > nothing for this? > > => I'm not sure what you refer to by "this" above. the case when HA detects there are multiple MRs for the same MNP. > > > > I think it is much easier to verify whether a mobile network is not > > split or not. HA can ask to one of MR whether the other is onlink > > or not (ex. check ND cache). If not, HA can reject BUs from both MRs. > > Of course, there isn't such operation in the basic nemo though. > > => On the surface this seems easy but not if you consider > the corner cases, MR reboot, link failures....etc. > I don't think it's that easy actually. I don't see any problem here. HA does not have the binding for the MR that reboot or lost connectivity. Only when HA has multiple bindings for the same MR, it checks the split network with registered MRs. > > > > If NEMO can detect the split mobile network and prohibit the > > split mobile network, there is no problem for the same MNP > > configuration. > > => I find this logic a bit skewed actually. Of course if > you start with shared MNPs then it follows that if we can > prevent splitting then everything is ok. There is only > a small problem: you can't prevent splitting. How skewed? I think there are two options here for the splitting. The nemo prohibit the split mobile network somehow. The nemo allow the split mobile network for the same MNP (i.e. HA somehow know which LFN is located which MR and deliver packets correctly to target MR, etc) I do not see big advantages on the latter case. If we have detection mechanism of splitting, nemo can support the configuration of the 1MNP to more than 1 MRs. ryuji From nemo-admin@ietf.org Sat Mar 27 00:45:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12244 for ; Sat, 27 Mar 2004 00:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76cw-00044l-7S; Sat, 27 Mar 2004 00:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76bz-00042J-8G for nemo@optimus.ietf.org; Sat, 27 Mar 2004 00:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12100 for ; Sat, 27 Mar 2004 00:43:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B76bw-0004Qy-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:44:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B76b7-0004IC-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:43:09 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B76aD-00042f-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:42:13 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sat, 27 Mar 2004 00:41:39 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTuq5RI+Hiw8ZrSxWiR1m6/qWGvwAAcNzw From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: , , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> Not sure what you mean, the current spec does that. >=20 > Prefix table. Yes, your are right. > I am not sure the use of prefix table guarantee the 1MNP-1MR all the > case.=20 >=20 > When MR has multiple egress interfaces and register each CoA with > respective HoA, HA can not distinguish between the case when one MNP > assigned to two MRs and the case of one MNP to multihomed MR.=20 =3D> Of course. > When each MR registers to different HAs, we need to verify whether > prefix table of each HA is consistent or not.=20 =3D> No we don't need to do that, they're two independent=20 entries. > > > Do you think we can just treat this as configuration=20 > errors and do > > > nothing for this? > >=20 > > =3D> I'm not sure what you refer to by "this" above. >=20 > the case when HA detects there are multiple MRs for the same MNP. =3D> As I stated before, I think it's cleaner to have=20 different MNPs for MRs. If that's the decision, then of course we can treat this case as an error just like MIP treats multiple MNs with the same HoA as an error.=20 > > =3D> On the surface this seems easy but not if you consider > > the corner cases, MR reboot, link failures....etc. > > I don't think it's that easy actually. >=20 > I don't see any problem here. >=20 > HA does not have the binding for the MR that reboot or lost=20 > connectivity. =3D> If the MR registered for an hour how is=20 the binding removed? > Only when HA has multiple bindings for the same MR, it checks the > split network with registered MRs.=20 =3D> When it checks and one MR doesn't answer what happens? I've already stated these points before. You can find=20 them in earlier emails. Hesham From exim@www1.ietf.org Sat Mar 27 00:47:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12346 for ; Sat, 27 Mar 2004 00:47:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76eZ-0004Ce-2j for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 00:46:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R5khDj016151 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 00:46:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76eY-0004CN-RX for nemo-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 00:46:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12326 for ; Sat, 27 Mar 2004 00:46:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B76eV-0004lN-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 00:46:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B76dh-0004g8-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 00:45:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B76cw-0004aQ-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 00:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76cw-00044l-7S; Sat, 27 Mar 2004 00:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B76bz-00042J-8G for nemo@optimus.ietf.org; Sat, 27 Mar 2004 00:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12100 for ; Sat, 27 Mar 2004 00:43:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B76bw-0004Qy-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:44:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B76b7-0004IC-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:43:09 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B76aD-00042f-00 for nemo@ietf.org; Sat, 27 Mar 2004 00:42:13 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sat, 27 Mar 2004 00:41:39 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTuq5RI+Hiw8ZrSxWiR1m6/qWGvwAAcNzw From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> Not sure what you mean, the current spec does that. >=20 > Prefix table. Yes, your are right. > I am not sure the use of prefix table guarantee the 1MNP-1MR all the > case.=20 >=20 > When MR has multiple egress interfaces and register each CoA with > respective HoA, HA can not distinguish between the case when one MNP > assigned to two MRs and the case of one MNP to multihomed MR.=20 =3D> Of course. > When each MR registers to different HAs, we need to verify whether > prefix table of each HA is consistent or not.=20 =3D> No we don't need to do that, they're two independent=20 entries. > > > Do you think we can just treat this as configuration=20 > errors and do > > > nothing for this? > >=20 > > =3D> I'm not sure what you refer to by "this" above. >=20 > the case when HA detects there are multiple MRs for the same MNP. =3D> As I stated before, I think it's cleaner to have=20 different MNPs for MRs. If that's the decision, then of course we can treat this case as an error just like MIP treats multiple MNs with the same HoA as an error.=20 > > =3D> On the surface this seems easy but not if you consider > > the corner cases, MR reboot, link failures....etc. > > I don't think it's that easy actually. >=20 > I don't see any problem here. >=20 > HA does not have the binding for the MR that reboot or lost=20 > connectivity. =3D> If the MR registered for an hour how is=20 the binding removed? > Only when HA has multiple bindings for the same MR, it checks the > split network with registered MRs.=20 =3D> When it checks and one MR doesn't answer what happens? I've already stated these points before. You can find=20 them in earlier emails. Hesham From nemo-admin@ietf.org Sat Mar 27 02:43:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00270 for ; Sat, 27 Mar 2004 02:43:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78T9-0002Q0-9Y; Sat, 27 Mar 2004 02:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78Sv-0002Ok-RJ for nemo@optimus.ietf.org; Sat, 27 Mar 2004 02:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00247 for ; Sat, 27 Mar 2004 02:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B78Ss-0006wK-00 for nemo@ietf.org; Sat, 27 Mar 2004 02:42:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B78Rw-0006rM-00 for nemo@ietf.org; Sat, 27 Mar 2004 02:41:49 -0500 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1B78Rc-0006ll-00 for nemo@ietf.org; Sat, 27 Mar 2004 02:41:28 -0500 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i2R7Yt1u021459; Sat, 27 Mar 2004 16:34:55 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i2R7Yt4W021458; Sat, 27 Mar 2004 16:34:55 +0900 Date: Sat, 27 Mar 2004 16:34:55 +0900 From: Seongho Cho To: Soliman Hesham Cc: Ryuji Wakikawa , Alexandru.Petrescu@motorola.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-ID: <20040327163455.A21410@popeye.snu.ac.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from H.Soliman@flarion.com on Sat, Mar 27, 2004 at 12:41:39AM -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, On Sat, Mar 27, 2004 at 12:41:39AM -0500, Soliman Hesham wrote: > > > > => Not sure what you mean, the current spec does that. > > > > Prefix table. Yes, your are right. > > I am not sure the use of prefix table guarantee the 1MNP-1MR all the > > case. > > > > When MR has multiple egress interfaces and register each CoA with > > respective HoA, HA can not distinguish between the case when one MNP > > assigned to two MRs and the case of one MNP to multihomed MR. > > => Of course. I agree. > > When each MR registers to different HAs, we need to verify whether > > prefix table of each HA is consistent or not. > > => No we don't need to do that, they're two independent > entries. For some purposes, the consistency *would* be preferable. If we want some fault tolerance, multiple HAs and replication (or consistency) can be helpful. And this consistency problem can be solved by the HAHA protocol. So, we don't need to close the possibility. > > > > Do you think we can just treat this as configuration > > errors and do > > > > nothing for this? > > > > > > => I'm not sure what you refer to by "this" above. > > > > the case when HA detects there are multiple MRs for the same MNP. > > => As I stated before, I think it's cleaner to have > different MNPs for MRs. If that's the decision, then > of course we can treat this case as an error just like > MIP treats multiple MNs with the same HoA as an error. > IMO, multiple MRs can have the same MNP for the fault tolerance. That's one of the purpose of multihomed mobile networks, and that can be also the decision. > > > => On the surface this seems easy but not if you consider > > > the corner cases, MR reboot, link failures....etc. > > > I don't think it's that easy actually. > > > > I don't see any problem here. > > > > HA does not have the binding for the MR that reboot or lost > > connectivity. > > => If the MR registered for an hour how is > the binding removed? The periodic BU can solve this problem. But traffics toward the HA which lost it's tunnel with the MR may experience disconnection. Seongho > > Only when HA has multiple bindings for the same MR, it checks the > > split network with registered MRs. > > => When it checks and one MR doesn't answer what happens? > I've already stated these points before. You can find > them in earlier emails. > From exim@www1.ietf.org Sat Mar 27 02:45:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00361 for ; Sat, 27 Mar 2004 02:45:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78Uo-0002Zn-Ux for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 02:44:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R7ik5N009904 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 02:44:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78Uo-0002Zf-J9 for nemo-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 02:44:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00327 for ; Sat, 27 Mar 2004 02:44:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B78Uk-00076Q-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 02:44:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B78Tm-00071i-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 02:43:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B78TA-0006ws-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 02:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78T9-0002Q0-9Y; Sat, 27 Mar 2004 02:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78Sv-0002Ok-RJ for nemo@optimus.ietf.org; Sat, 27 Mar 2004 02:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00247 for ; Sat, 27 Mar 2004 02:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B78Ss-0006wK-00 for nemo@ietf.org; Sat, 27 Mar 2004 02:42:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B78Rw-0006rM-00 for nemo@ietf.org; Sat, 27 Mar 2004 02:41:49 -0500 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1B78Rc-0006ll-00 for nemo@ietf.org; Sat, 27 Mar 2004 02:41:28 -0500 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i2R7Yt1u021459; Sat, 27 Mar 2004 16:34:55 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i2R7Yt4W021458; Sat, 27 Mar 2004 16:34:55 +0900 Date: Sat, 27 Mar 2004 16:34:55 +0900 From: Seongho Cho To: Soliman Hesham Cc: Ryuji Wakikawa , Alexandru.Petrescu@motorola.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) Message-ID: <20040327163455.A21410@popeye.snu.ac.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from H.Soliman@flarion.com on Sat, Mar 27, 2004 at 12:41:39AM -0500 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, On Sat, Mar 27, 2004 at 12:41:39AM -0500, Soliman Hesham wrote: > > > > => Not sure what you mean, the current spec does that. > > > > Prefix table. Yes, your are right. > > I am not sure the use of prefix table guarantee the 1MNP-1MR all the > > case. > > > > When MR has multiple egress interfaces and register each CoA with > > respective HoA, HA can not distinguish between the case when one MNP > > assigned to two MRs and the case of one MNP to multihomed MR. > > => Of course. I agree. > > When each MR registers to different HAs, we need to verify whether > > prefix table of each HA is consistent or not. > > => No we don't need to do that, they're two independent > entries. For some purposes, the consistency *would* be preferable. If we want some fault tolerance, multiple HAs and replication (or consistency) can be helpful. And this consistency problem can be solved by the HAHA protocol. So, we don't need to close the possibility. > > > > Do you think we can just treat this as configuration > > errors and do > > > > nothing for this? > > > > > > => I'm not sure what you refer to by "this" above. > > > > the case when HA detects there are multiple MRs for the same MNP. > > => As I stated before, I think it's cleaner to have > different MNPs for MRs. If that's the decision, then > of course we can treat this case as an error just like > MIP treats multiple MNs with the same HoA as an error. > IMO, multiple MRs can have the same MNP for the fault tolerance. That's one of the purpose of multihomed mobile networks, and that can be also the decision. > > > => On the surface this seems easy but not if you consider > > > the corner cases, MR reboot, link failures....etc. > > > I don't think it's that easy actually. > > > > I don't see any problem here. > > > > HA does not have the binding for the MR that reboot or lost > > connectivity. > > => If the MR registered for an hour how is > the binding removed? The periodic BU can solve this problem. But traffics toward the HA which lost it's tunnel with the MR may experience disconnection. Seongho > > Only when HA has multiple bindings for the same MR, it checks the > > split network with registered MRs. > > => When it checks and one MR doesn't answer what happens? > I've already stated these points before. You can find > them in earlier emails. > From nemo-admin@ietf.org Sat Mar 27 03:03:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00973 for ; Sat, 27 Mar 2004 03:03:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78mT-0003iR-LT; Sat, 27 Mar 2004 03:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78m9-0003i5-6n for nemo@optimus.ietf.org; Sat, 27 Mar 2004 03:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00968 for ; Sat, 27 Mar 2004 03:02:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B78m5-00012H-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:02:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B78lI-0000yB-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:01:49 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B78kY-0000nh-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:01:02 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sat, 27 Mar 2004 03:00:22 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTzunZ74nBHuTiQIq2EUQlXaKZwAAALLYw From: "Soliman Hesham" To: "Seongho Cho" Cc: "Ryuji Wakikawa" , , , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > > When each MR registers to different HAs, we need to=20 > verify whether > > > prefix table of each HA is consistent or not.=20 > >=20 > > =3D> No we don't need to do that, they're two independent=20 > > entries. >=20 > For some purposes, the consistency *would* be preferable.=20 > If we want some > fault tolerance, multiple HAs and replication (or=20 > consistency) can be helpful. > And this consistency problem can be solved by the HAHA protocol.=20 > So, we don't need to close the possibility. =3D> There is no inconsistency here to address. I think there is a lot of confusion about multihoming actually. I intend to put my thoughts in a draft to avoid repetition. > >=20 > > =3D> As I stated before, I think it's cleaner to have=20 > > different MNPs for MRs. If that's the decision, then > > of course we can treat this case as an error just like > > MIP treats multiple MNs with the same HoA as an error.=20 > >=20 >=20 > IMO, multiple MRs can have the same MNP for the fault tolerance. > That's one of the purpose of multihomed mobile networks, and > that can be also the decision. =3D> You're mixing a solution with a requirement. Start by putting requirements then we can discuss solutions THEN we can decide which solution is better.=20 > > =3D> If the MR registered for an hour how is=20 > > the binding removed? >=20 > The periodic BU can solve this problem.=20 =3D> No it doesn't, perhaps some interaction between the IGP and the binding cache management function can be done but this is still handwaving without any=20 concrete ideas. Hesham From exim@www1.ietf.org Sat Mar 27 03:05:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01062 for ; Sat, 27 Mar 2004 03:05:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78o4-0003pG-W5 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 03:04:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R84eNB014704 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 03:04:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78o4-0003p5-Ke for nemo-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 03:04:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01053 for ; Sat, 27 Mar 2004 03:04:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B78o0-0001B6-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:04:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B78n4-00017A-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:03:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B78mR-00013G-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78mT-0003iR-LT; Sat, 27 Mar 2004 03:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B78m9-0003i5-6n for nemo@optimus.ietf.org; Sat, 27 Mar 2004 03:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00968 for ; Sat, 27 Mar 2004 03:02:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B78m5-00012H-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:02:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B78lI-0000yB-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:01:49 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B78kY-0000nh-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:01:02 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sat, 27 Mar 2004 03:00:22 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTzunZ74nBHuTiQIq2EUQlXaKZwAAALLYw From: "Soliman Hesham" To: "Seongho Cho" Cc: "Ryuji Wakikawa" , , , , Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > > When each MR registers to different HAs, we need to=20 > verify whether > > > prefix table of each HA is consistent or not.=20 > >=20 > > =3D> No we don't need to do that, they're two independent=20 > > entries. >=20 > For some purposes, the consistency *would* be preferable.=20 > If we want some > fault tolerance, multiple HAs and replication (or=20 > consistency) can be helpful. > And this consistency problem can be solved by the HAHA protocol.=20 > So, we don't need to close the possibility. =3D> There is no inconsistency here to address. I think there is a lot of confusion about multihoming actually. I intend to put my thoughts in a draft to avoid repetition. > >=20 > > =3D> As I stated before, I think it's cleaner to have=20 > > different MNPs for MRs. If that's the decision, then > > of course we can treat this case as an error just like > > MIP treats multiple MNs with the same HoA as an error.=20 > >=20 >=20 > IMO, multiple MRs can have the same MNP for the fault tolerance. > That's one of the purpose of multihomed mobile networks, and > that can be also the decision. =3D> You're mixing a solution with a requirement. Start by putting requirements then we can discuss solutions THEN we can decide which solution is better.=20 > > =3D> If the MR registered for an hour how is=20 > > the binding removed? >=20 > The periodic BU can solve this problem.=20 =3D> No it doesn't, perhaps some interaction between the IGP and the binding cache management function can be done but this is still handwaving without any=20 concrete ideas. Hesham From nemo-admin@ietf.org Sat Mar 27 03:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01584 for ; Sat, 27 Mar 2004 03:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B795p-0004hr-Fi; Sat, 27 Mar 2004 03:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B795T-0004go-5s for nemo@optimus.ietf.org; Sat, 27 Mar 2004 03:22:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01574 for ; Sat, 27 Mar 2004 03:22:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B795Q-0002Ve-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:22:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B794V-0002S8-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:21:39 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B794L-0002OB-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:21:29 -0500 Received: from MobileGravity.local.sfc.wide.ad.jp (pdd8773.tkyoac00.ap.so-net.ne.jp [218.221.135.115]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2R8KEUV027359; Sat, 27 Mar 2004 17:20:14 +0900 Date: Sat, 27 Mar 2004 17:20:56 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At Sat, 27 Mar 2004 00:41:39 -0500, Soliman Hesham wrote: > > > > > => Not sure what you mean, the current spec does that. > > > > Prefix table. Yes, your are right. > > I am not sure the use of prefix table guarantee the 1MNP-1MR all the > > case. > > > > When MR has multiple egress interfaces and register each CoA with > > respective HoA, HA can not distinguish between the case when one MNP > > assigned to two MRs and the case of one MNP to multihomed MR. > > => Of course. > > > When each MR registers to different HAs, we need to verify whether > > prefix table of each HA is consistent or not. > > => No we don't need to do that, they're two independent > entries. Do you propose to use prefix table as MUST in the basic ? > > > > Do you think we can just treat this as configuration > > errors and do > > > > nothing for this? > > > > > > => I'm not sure what you refer to by "this" above. > > > > the case when HA detects there are multiple MRs for the same MNP. > > => As I stated before, I think it's cleaner to have > different MNPs for MRs. If that's the decision, then > of course we can treat this case as an error just like > MIP treats multiple MNs with the same HoA as an error. OK. They have mechasnim to detect that such as DAD at home link. > > > > => On the surface this seems easy but not if you consider > > > the corner cases, MR reboot, link failures....etc. > > > I don't think it's that easy actually. > > > > I don't see any problem here. > > > > HA does not have the binding for the MR that reboot or lost > > connectivity. > > => If the MR registered for an hour how is > the binding removed? How to remove binding for reboot MR is not NEMO specific issue. Mobile IP has same issue. ryuji > > Only when HA has multiple bindings for the same MR, it checks the > > split network with registered MRs. > > => When it checks and one MR doesn't answer what happens? > I've already stated these points before. You can find > them in earlier emails. > > Hesham > From exim@www1.ietf.org Sat Mar 27 03:25:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01670 for ; Sat, 27 Mar 2004 03:25:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B797P-0004rf-Ix for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 03:24:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R8OdKR018700 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 03:24:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B797P-0004rX-3H for nemo-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 03:24:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01667 for ; Sat, 27 Mar 2004 03:24:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B797M-0002eq-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:24:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B796R-0002af-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:23:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B795q-0002WW-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B795p-0004hr-Fi; Sat, 27 Mar 2004 03:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B795T-0004go-5s for nemo@optimus.ietf.org; Sat, 27 Mar 2004 03:22:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01574 for ; Sat, 27 Mar 2004 03:22:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B795Q-0002Ve-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:22:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B794V-0002S8-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:21:39 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B794L-0002OB-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:21:29 -0500 Received: from MobileGravity.local.sfc.wide.ad.jp (pdd8773.tkyoac00.ap.so-net.ne.jp [218.221.135.115]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2R8KEUV027359; Sat, 27 Mar 2004 17:20:14 +0900 Date: Sat, 27 Mar 2004 17:20:56 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At Sat, 27 Mar 2004 00:41:39 -0500, Soliman Hesham wrote: > > > > > => Not sure what you mean, the current spec does that. > > > > Prefix table. Yes, your are right. > > I am not sure the use of prefix table guarantee the 1MNP-1MR all the > > case. > > > > When MR has multiple egress interfaces and register each CoA with > > respective HoA, HA can not distinguish between the case when one MNP > > assigned to two MRs and the case of one MNP to multihomed MR. > > => Of course. > > > When each MR registers to different HAs, we need to verify whether > > prefix table of each HA is consistent or not. > > => No we don't need to do that, they're two independent > entries. Do you propose to use prefix table as MUST in the basic ? > > > > Do you think we can just treat this as configuration > > errors and do > > > > nothing for this? > > > > > > => I'm not sure what you refer to by "this" above. > > > > the case when HA detects there are multiple MRs for the same MNP. > > => As I stated before, I think it's cleaner to have > different MNPs for MRs. If that's the decision, then > of course we can treat this case as an error just like > MIP treats multiple MNs with the same HoA as an error. OK. They have mechasnim to detect that such as DAD at home link. > > > > => On the surface this seems easy but not if you consider > > > the corner cases, MR reboot, link failures....etc. > > > I don't think it's that easy actually. > > > > I don't see any problem here. > > > > HA does not have the binding for the MR that reboot or lost > > connectivity. > > => If the MR registered for an hour how is > the binding removed? How to remove binding for reboot MR is not NEMO specific issue. Mobile IP has same issue. ryuji > > Only when HA has multiple bindings for the same MR, it checks the > > split network with registered MRs. > > => When it checks and one MR doesn't answer what happens? > I've already stated these points before. You can find > them in earlier emails. > > Hesham > From nemo-admin@ietf.org Sat Mar 27 03:42:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02262 for ; Sat, 27 Mar 2004 03:42:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B79OD-0005qX-Pp; Sat, 27 Mar 2004 03:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B79Nr-0005or-KL for nemo@optimus.ietf.org; Sat, 27 Mar 2004 03:41:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02251 for ; Sat, 27 Mar 2004 03:41:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B79Np-0004Ew-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:41:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B79Mv-0004Al-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:40:41 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B79MA-00041U-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:39:54 -0500 Received: from MobileGravity.local.sfc.wide.ad.jp (pdd8773.tkyoac00.ap.so-net.ne.jp [218.221.135.115]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2R8cfUV027460; Sat, 27 Mar 2004 17:38:41 +0900 Date: Sat, 27 Mar 2004 17:39:23 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: shcho@popeye.snu.ac.kr, Alexandru.Petrescu@motorola.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , At Sat, 27 Mar 2004 03:00:22 -0500, Soliman Hesham wrote: > > > > > > When each MR registers to different HAs, we need to > > verify whether > > > > prefix table of each HA is consistent or not. > > > > > > => No we don't need to do that, they're two independent > > > entries. > > > > For some purposes, the consistency *would* be preferable. > > If we want some > > fault tolerance, multiple HAs and replication (or > > consistency) can be helpful. > > And this consistency problem can be solved by the HAHA protocol. > > So, we don't need to close the possibility. > > => There is no inconsistency here to address. > I think there is a lot of confusion about multihoming > actually. I intend to put my thoughts in a draft to > avoid repetition. Which draft are you talking about? I will wait for your definition. > > > > > > => As I stated before, I think it's cleaner to have > > > different MNPs for MRs. If that's the decision, then > > > of course we can treat this case as an error just like > > > MIP treats multiple MNs with the same HoA as an error. > > > > > > > IMO, multiple MRs can have the same MNP for the fault tolerance. > > That's one of the purpose of multihomed mobile networks, and > > that can be also the decision. > > => You're mixing a solution with a requirement. Start by You mixed both, too. How can you give such strong statement (1MNP-1MR) without requirement thought. > putting requirements then we can discuss solutions THEN > we can decide which solution is better. I agree. The facts are we are still working on requirement and problem statement in NEMO WG. At this stage, we have the scenario where multiple MRs have same MNP in the ChanWah's pb statement draft. ryuji > > > => If the MR registered for an hour how is > > > the binding removed? > > > > The periodic BU can solve this problem. > > => No it doesn't, perhaps some interaction between > the IGP and the binding cache management function > can be done but this is still handwaving without any > concrete ideas. > > Hesham From exim@www1.ietf.org Sat Mar 27 03:44:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02369 for ; Sat, 27 Mar 2004 03:44:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B79Pv-00062h-B9 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 03:43:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R8hltD023227 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 03:43:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B79Pu-00062Y-Up for nemo-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 03:43:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02362 for ; Sat, 27 Mar 2004 03:43:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B79Ps-0004S1-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:43:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B79P0-0004Mz-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:42:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B79OD-0004HT-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 03:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B79OD-0005qX-Pp; Sat, 27 Mar 2004 03:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B79Nr-0005or-KL for nemo@optimus.ietf.org; Sat, 27 Mar 2004 03:41:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02251 for ; Sat, 27 Mar 2004 03:41:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B79Np-0004Ew-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:41:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B79Mv-0004Al-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:40:41 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1B79MA-00041U-00 for nemo@ietf.org; Sat, 27 Mar 2004 03:39:54 -0500 Received: from MobileGravity.local.sfc.wide.ad.jp (pdd8773.tkyoac00.ap.so-net.ne.jp [218.221.135.115]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i2R8cfUV027460; Sat, 27 Mar 2004 17:38:41 +0900 Date: Sat, 27 Mar 2004 17:39:23 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Cc: shcho@popeye.snu.ac.kr, Alexandru.Petrescu@motorola.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, nemo@ietf.org Subject: Re: [nemo] RE: splitting moving networks (was: DND test) In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At Sat, 27 Mar 2004 03:00:22 -0500, Soliman Hesham wrote: > > > > > > When each MR registers to different HAs, we need to > > verify whether > > > > prefix table of each HA is consistent or not. > > > > > > => No we don't need to do that, they're two independent > > > entries. > > > > For some purposes, the consistency *would* be preferable. > > If we want some > > fault tolerance, multiple HAs and replication (or > > consistency) can be helpful. > > And this consistency problem can be solved by the HAHA protocol. > > So, we don't need to close the possibility. > > => There is no inconsistency here to address. > I think there is a lot of confusion about multihoming > actually. I intend to put my thoughts in a draft to > avoid repetition. Which draft are you talking about? I will wait for your definition. > > > > > > => As I stated before, I think it's cleaner to have > > > different MNPs for MRs. If that's the decision, then > > > of course we can treat this case as an error just like > > > MIP treats multiple MNs with the same HoA as an error. > > > > > > > IMO, multiple MRs can have the same MNP for the fault tolerance. > > That's one of the purpose of multihomed mobile networks, and > > that can be also the decision. > > => You're mixing a solution with a requirement. Start by You mixed both, too. How can you give such strong statement (1MNP-1MR) without requirement thought. > putting requirements then we can discuss solutions THEN > we can decide which solution is better. I agree. The facts are we are still working on requirement and problem statement in NEMO WG. At this stage, we have the scenario where multiple MRs have same MNP in the ChanWah's pb statement draft. ryuji > > > => If the MR registered for an hour how is > > > the binding removed? > > > > The periodic BU can solve this problem. > > => No it doesn't, perhaps some interaction between > the IGP and the binding cache management function > can be done but this is still handwaving without any > concrete ideas. > > Hesham From nemo-admin@ietf.org Sat Mar 27 08:39:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12661 for ; Sat, 27 Mar 2004 08:39:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7E1c-0000FK-5Q; Sat, 27 Mar 2004 08:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7E1W-0000Eu-Uz for nemo@optimus.ietf.org; Sat, 27 Mar 2004 08:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12657 for ; Sat, 27 Mar 2004 08:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7E1V-0001kB-00 for nemo@ietf.org; Sat, 27 Mar 2004 08:38:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7E0e-0001ez-00 for nemo@ietf.org; Sat, 27 Mar 2004 08:38:01 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7E0D-0001ZX-00 for nemo@ietf.org; Sat, 27 Mar 2004 08:37:33 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sat, 27 Mar 2004 08:36:54 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQT1G9wXJN2NYVQSmKWWpSyc5iFAAAKlitw From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: , , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> No we don't need to do that, they're two independent=20 > > entries. >=20 > Do you propose to use prefix table as MUST in the basic ? =3D> What is the relationship between maintaining two separate entries in the binding cache and the prefix table being mandatory? In any case, I do think the prefix table should be mandatory. > > =3D> As I stated before, I think it's cleaner to have=20 > > different MNPs for MRs. If that's the decision, then > > of course we can treat this case as an error just like > > MIP treats multiple MNs with the same HoA as an error.=20 >=20 > OK. > They have mechasnim to detect that such as DAD at home link. =3D> DAD detects address duplication on the link, which still applies to the MR's HoA. It does not detect when two MNs off link are trying to register with the same HoA. This is detected because every HoA is tied to=20 a unique SA.=20 > > > > =3D> On the surface this seems easy but not if you consider > > > > the corner cases, MR reboot, link failures....etc. > > > > I don't think it's that easy actually. > > >=20 > > > I don't see any problem here. > > >=20 > > > HA does not have the binding for the MR that reboot or lost=20 > > > connectivity. > >=20 > > =3D> If the MR registered for an hour how is=20 > > the binding removed? >=20 > How to remove binding for reboot MR is not NEMO specific issue.=20 > Mobile IP has same issue. =3D> It is nemo specific in the case where we try=20 to introduce this new test which doesn't exist in MIP. The bigger point is what does the HA do if one MR does not answer the test. Hesham From exim@www1.ietf.org Sat Mar 27 08:41:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12733 for ; Sat, 27 Mar 2004 08:41:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7E3R-0000Ph-85 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 08:40:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2RDer7E001586 for nemo-archive@odin.ietf.org; Sat, 27 Mar 2004 08:40:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7E3R-0000PV-1s for nemo-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 08:40:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12722 for ; Sat, 27 Mar 2004 08:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7E3P-0001vf-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 08:40:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7E2Y-0001qY-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 08:39:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7E1i-0001lW-00 for nemo-web-archive@ietf.org; Sat, 27 Mar 2004 08:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7E1c-0000FK-5Q; Sat, 27 Mar 2004 08:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7E1W-0000Eu-Uz for nemo@optimus.ietf.org; Sat, 27 Mar 2004 08:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12657 for ; Sat, 27 Mar 2004 08:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7E1V-0001kB-00 for nemo@ietf.org; Sat, 27 Mar 2004 08:38:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7E0e-0001ez-00 for nemo@ietf.org; Sat, 27 Mar 2004 08:38:01 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7E0D-0001ZX-00 for nemo@ietf.org; Sat, 27 Mar 2004 08:37:33 -0500 content-class: urn:content-classes:message Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sat, 27 Mar 2004 08:36:54 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQT1G9wXJN2NYVQSmKWWpSyc5iFAAAKlitw From: "Soliman Hesham" To: "Ryuji Wakikawa" Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> No we don't need to do that, they're two independent=20 > > entries. >=20 > Do you propose to use prefix table as MUST in the basic ? =3D> What is the relationship between maintaining two separate entries in the binding cache and the prefix table being mandatory? In any case, I do think the prefix table should be mandatory. > > =3D> As I stated before, I think it's cleaner to have=20 > > different MNPs for MRs. If that's the decision, then > > of course we can treat this case as an error just like > > MIP treats multiple MNs with the same HoA as an error.=20 >=20 > OK. > They have mechasnim to detect that such as DAD at home link. =3D> DAD detects address duplication on the link, which still applies to the MR's HoA. It does not detect when two MNs off link are trying to register with the same HoA. This is detected because every HoA is tied to=20 a unique SA.=20 > > > > =3D> On the surface this seems easy but not if you consider > > > > the corner cases, MR reboot, link failures....etc. > > > > I don't think it's that easy actually. > > >=20 > > > I don't see any problem here. > > >=20 > > > HA does not have the binding for the MR that reboot or lost=20 > > > connectivity. > >=20 > > =3D> If the MR registered for an hour how is=20 > > the binding removed? >=20 > How to remove binding for reboot MR is not NEMO specific issue.=20 > Mobile IP has same issue. =3D> It is nemo specific in the case where we try=20 to introduce this new test which doesn't exist in MIP. The bigger point is what does the HA do if one MR does not answer the test. Hesham From nemo-admin@ietf.org Sun Mar 28 07:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14850 for ; Sun, 28 Mar 2004 07:24:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ZKb-0003uO-Nb; Sun, 28 Mar 2004 07:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ZJm-0003pf-2P for nemo@optimus.ietf.org; Sun, 28 Mar 2004 07:23:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14673 for ; Sun, 28 Mar 2004 07:23:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7ZJl-0000HQ-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:23:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7ZHa-0007jw-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:20:55 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B7ZEM-0006sF-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:17:35 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6B27617757; Sun, 28 Mar 2004 14:17:03 +0200 (CEST) Received: from lolo (vpn-252-234.uc3m.es [163.117.252.234]) by smtp02.uc3m.es (Postfix) with SMTP id 9CCA117747; Sun, 28 Mar 2004 14:17:00 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sun, 28 Mar 2004 14:14:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4064401E.3060801@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Yes, there are two moving networks two MNP's two Mobile Routers; it is > configured in such a way to be able to be split, is there anything wrong > with this? No, there is nothing wrong, it is just that this configuration hardly provides any multihoming benefit. I guess that i was thinking in a network with multiple MRs, that provides multihomed benefits and that can split. Regards, marcelo > > Alex > > From exim@www1.ietf.org Sun Mar 28 07:27:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15269 for ; Sun, 28 Mar 2004 07:27:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ZNA-0004IV-NF for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 07:26:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SCQeLR016513 for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 07:26:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ZNA-0004IG-Ga for nemo-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 07:26:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15159 for ; Sun, 28 Mar 2004 07:26:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7ZN9-00017n-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 07:26:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7ZM4-0000qW-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 07:25:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7ZKp-0000VZ-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 07:24:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ZKb-0003uO-Nb; Sun, 28 Mar 2004 07:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ZJm-0003pf-2P for nemo@optimus.ietf.org; Sun, 28 Mar 2004 07:23:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14673 for ; Sun, 28 Mar 2004 07:23:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7ZJl-0000HQ-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:23:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7ZHa-0007jw-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:20:55 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B7ZEM-0006sF-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:17:35 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6B27617757; Sun, 28 Mar 2004 14:17:03 +0200 (CEST) Received: from lolo (vpn-252-234.uc3m.es [163.117.252.234]) by smtp02.uc3m.es (Postfix) with SMTP id 9CCA117747; Sun, 28 Mar 2004 14:17:00 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , "Pascal Thubert (pthubert)" , "IETF NEMO WG" Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sun, 28 Mar 2004 14:14:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4064401E.3060801@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Yes, there are two moving networks two MNP's two Mobile Routers; it is > configured in such a way to be able to be split, is there anything wrong > with this? No, there is nothing wrong, it is just that this configuration hardly provides any multihoming benefit. I guess that i was thinking in a network with multiple MRs, that provides multihomed benefits and that can split. Regards, marcelo > > Alex > > From nemo-admin@ietf.org Sun Mar 28 07:59:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16187 for ; Sun, 28 Mar 2004 07:59:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ZsS-0007Fj-T5; Sun, 28 Mar 2004 07:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Zs3-0007FA-Kx for nemo@optimus.ietf.org; Sun, 28 Mar 2004 07:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16183 for ; Sun, 28 Mar 2004 07:58:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Zs2-0004z6-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:58:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Zr5-0004t9-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:57:36 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B7Zqb-0004mg-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:57:06 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6160717770; Sun, 28 Mar 2004 14:56:35 +0200 (CEST) Received: from lolo (vpn-252-234.uc3m.es [163.117.252.234]) by smtp02.uc3m.es (Postfix) with SMTP id 2185F17765; Sun, 28 Mar 2004 14:56:32 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , Subject: multiple prefixes, multihoming ans spliting (was RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sun, 28 Mar 2004 14:53:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > => As I stated before, I think it's cleaner to have > different MNPs for MRs. First of all, let's first define what is the goal of having multiple MR, or put in another way, which is the goal of being multihomed. Because of the nature of multihoming in NEMO, i think that the support for multiple technologies is a very important goal, so i guess that a multihoming solution should support this. This means that we have two MR with different access technologies, so packets have to be forwarded through the router that has a link available. I guess that is expected that links will become available and unavailable quite often when the network is moving, so it is important that established connections are preserved when switching technologies (and MRs) So i think that important requirements for multihoming in nemo are what some can call transparent support for ubiquity. Now, this is different from the fault tolerance requirement (despite what i have claimed before :-), since this is very localized problem, the links that can "fail" are the links between the MR and the access routers. This would allow a solution that consists in mechanisms based in the HA, or even in the Home network perhaps in the visited network, but not much more An possibility as you mention would be to use multiple prefixes, one per MR. The problem here is that one prefix is associated with a MR, so with an access technology. So when this access technology is unavailable, this prefix would become unavailable. For example, suppose you have MR1 with Pref1 and MR2 with Pref2 There is also a LFN, that in order to be reachable through both technologies, it has to configure two addresses, Pref1:LFN and Pref2:LFN Suppose now that LFN has established a communication with a host in the internet, Host1, using Pref1:LFN. suddenly, the network moves and the technology that is using MR1 is no longer available. How do you preserve the established session? To do that you can: Modify the external host Host1 to support multiple addresses per connection. This may be part of a general multihoming solution, but this will take time to be deployed Make some tunnels between the MR so that they forward packets belonging to the other prefix, which actually you end up with both routers forwarding the same prefix, which i am not sure this is so clean. There are also other problems with this multiprefixed setup, like for instance how do you select the source address that is working properly for initiating a communication. Probably you will need a mechanism in the LFN to retry with different source addresses. This may also be part of a general multihoming solution, but again may take longer to deploy. So my comment essentially is: the support for ubiquity seems an important goal and that IMHO can be solved by adding some mechanisms to specific devices, like the HA, and MR only. If you adopt a multiprefix solution, a clean support will require support from the external hosts. Other solutions like the tunnel based solutions, are not so clean i am not so sure that are cleaner than the single prefixed ones. Additionally, a multiprefix solution will require support from LFN. So, my bet would be to try to explore a single prefixed solution that provides transparent support for ubiquity and see how we can address the case when it splits. Regards, marcelo From exim@www1.ietf.org Sun Mar 28 08:01:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16241 for ; Sun, 28 Mar 2004 08:01:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Ztw-0007fb-Nx for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 08:00:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SD0Wsu029482 for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 08:00:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Ztw-0007fR-I3 for nemo-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 08:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16230 for ; Sun, 28 Mar 2004 08:00:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Ztv-0005B0-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 08:00:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Zsx-000559-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 07:59:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7ZsW-0004zW-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 07:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ZsS-0007Fj-T5; Sun, 28 Mar 2004 07:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Zs3-0007FA-Kx for nemo@optimus.ietf.org; Sun, 28 Mar 2004 07:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16183 for ; Sun, 28 Mar 2004 07:58:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Zs2-0004z6-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:58:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Zr5-0004t9-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:57:36 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B7Zqb-0004mg-00 for nemo@ietf.org; Sun, 28 Mar 2004 07:57:06 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6160717770; Sun, 28 Mar 2004 14:56:35 +0200 (CEST) Received: from lolo (vpn-252-234.uc3m.es [163.117.252.234]) by smtp02.uc3m.es (Postfix) with SMTP id 2185F17765; Sun, 28 Mar 2004 14:56:32 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , Subject: multiple prefixes, multihoming ans spliting (was RE: [nemo] RE: splitting moving networks (was: DND test) Date: Sun, 28 Mar 2004 14:53:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > => As I stated before, I think it's cleaner to have > different MNPs for MRs. First of all, let's first define what is the goal of having multiple MR, or put in another way, which is the goal of being multihomed. Because of the nature of multihoming in NEMO, i think that the support for multiple technologies is a very important goal, so i guess that a multihoming solution should support this. This means that we have two MR with different access technologies, so packets have to be forwarded through the router that has a link available. I guess that is expected that links will become available and unavailable quite often when the network is moving, so it is important that established connections are preserved when switching technologies (and MRs) So i think that important requirements for multihoming in nemo are what some can call transparent support for ubiquity. Now, this is different from the fault tolerance requirement (despite what i have claimed before :-), since this is very localized problem, the links that can "fail" are the links between the MR and the access routers. This would allow a solution that consists in mechanisms based in the HA, or even in the Home network perhaps in the visited network, but not much more An possibility as you mention would be to use multiple prefixes, one per MR. The problem here is that one prefix is associated with a MR, so with an access technology. So when this access technology is unavailable, this prefix would become unavailable. For example, suppose you have MR1 with Pref1 and MR2 with Pref2 There is also a LFN, that in order to be reachable through both technologies, it has to configure two addresses, Pref1:LFN and Pref2:LFN Suppose now that LFN has established a communication with a host in the internet, Host1, using Pref1:LFN. suddenly, the network moves and the technology that is using MR1 is no longer available. How do you preserve the established session? To do that you can: Modify the external host Host1 to support multiple addresses per connection. This may be part of a general multihoming solution, but this will take time to be deployed Make some tunnels between the MR so that they forward packets belonging to the other prefix, which actually you end up with both routers forwarding the same prefix, which i am not sure this is so clean. There are also other problems with this multiprefixed setup, like for instance how do you select the source address that is working properly for initiating a communication. Probably you will need a mechanism in the LFN to retry with different source addresses. This may also be part of a general multihoming solution, but again may take longer to deploy. So my comment essentially is: the support for ubiquity seems an important goal and that IMHO can be solved by adding some mechanisms to specific devices, like the HA, and MR only. If you adopt a multiprefix solution, a clean support will require support from the external hosts. Other solutions like the tunnel based solutions, are not so clean i am not so sure that are cleaner than the single prefixed ones. Additionally, a multiprefix solution will require support from LFN. So, my bet would be to try to explore a single prefixed solution that provides transparent support for ubiquity and see how we can address the case when it splits. Regards, marcelo From nemo-admin@ietf.org Sun Mar 28 10:54:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22373 for ; Sun, 28 Mar 2004 10:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cbp-0006PM-9n; Sun, 28 Mar 2004 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cbg-0006OC-2V for nemo@optimus.ietf.org; Sun, 28 Mar 2004 10:53:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22360 for ; Sun, 28 Mar 2004 10:53:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7cbd-0003Mb-00 for nemo@ietf.org; Sun, 28 Mar 2004 10:53:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7caa-0003EZ-00 for nemo@ietf.org; Sun, 28 Mar 2004 10:52:44 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7cZi-00031G-00 for nemo@ietf.org; Sun, 28 Mar 2004 10:51:50 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 28 Mar 2004 10:51:12 -0500 Date: Sun, 28 Mar 2004 10:51:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: [SPAM] - multiple prefixes, multihoming ans spliting (was RE: [nemo] RE: splitting moving networks (was: DND test) - Email found in subject Thread-Index: AcQUxBqsh6f883kSQjywVFGDnR17hAAEKulA Content-Class: urn:content-classes:message From: "Soliman Hesham" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 To: , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 28 Mar 2004 15:51:12.0609 (UTC) FILETIME=[7ECF4510:01C414DC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] multiple prefixes, multihoming and spliting Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > => As I stated before, I think it's cleaner to have > > different MNPs for MRs. > > First of all, let's first define what is the goal of having > multiple MR, or > put in another way, which is the goal of being multihomed. > > Because of the nature of multihoming in NEMO, i think that > the support for > multiple technologies is a very important goal, so i guess that a > multihoming solution should support this. This means that we > have two MR > with different access technologies, so packets have to be > forwarded through > the router that has a link available. > I guess that is expected that links will become available > and unavailable > quite often when the network is moving, so it is important > that established > connections are preserved when switching technologies (and MRs) > > So i think that important requirements for multihoming in > nemo are what some > can call transparent support for ubiquity. => Agreed. > > Now, this is different from the fault tolerance requirement > (despite what i > have claimed before :-), since this is very localized > problem, the links > that can "fail" are the links between the MR and the access > routers. => Exactly, this is one point I wanted to clarify in an earlier response to you. This > would allow a solution that consists in mechanisms based in > the HA, or even > in the Home network perhaps in the visited network, but not much more => We can also include the MR(s) as a possibility. > > An possibility as you mention would be to use multiple > prefixes, one per MR. > > The problem here is that one prefix is associated with a MR, > so with an > access technology. So when this access technology is > unavailable, this > prefix would become unavailable. => Right. > For example, suppose you have MR1 with Pref1 and MR2 with Pref2 > There is also a LFN, that in order to be reachable through both > technologies, it has to configure two addresses, Pref1:LFN > and Pref2:LFN > Suppose now that LFN has established a communication with a > host in the > internet, Host1, using Pref1:LFN. > suddenly, the network moves and the technology that is using > MR1 is no > longer available. How do you preserve the established session? > > To do that you can: > Modify the external host Host1 to support multiple addresses > per connection. > This may be part of a general multihoming solution, but this > will take time > to be deployed => Well you can use existing solutions to do that: MIP. But I need to look into it a bit deeper to see how the home address config will work. > Make some tunnels between the MR so that they forward > packets belonging to > the other prefix, which actually you end up with both > routers forwarding the > same prefix, which i am not sure this is so clean. => That wouldn't solve this problem anyway since one of the MRs is not connected to the Internet. What you need to do is make sure that MR2's HA will accept MR1's traffic. This can easily work when both HAs are in the same ISP's domain. > > There are also other problems with this multiprefixed setup, like for > instance how do you select the source address that is > working properly for > initiating a communication. Probably you will need a > mechanism in the LFN to > retry with different source addresses. This may also be part > of a general > multihoming solution, but again may take longer to deploy. => It's a part of any multiaddressing solution. Let me comment on a couple of points here: - If MRs are connected to different access technologies then we need information to be sent from those MRs to MNNs to inform them about the implications of selecting certain addresses. This is essentially the same problem for multihomed hosts (note by multihomed I mean a host with more than one interface), except that in the multihomed host case this information is internal. - Fault detection, router failure ...etc can be achieved with ND. How timely this is depends on tuning ND information. - The fact that adding this stuff will take time is in no way discrediting the approach. Note that adding this information does not mean we need to wait for a full multihoming solution with, for example, location/identifier split. This is not relevant for the link-local problems that we're addressing here. > > So my comment essentially is: the support for ubiquity seems > an important > goal and that IMHO can be solved by adding some mechanisms > to specific > devices, like the HA, and MR only. => This may well be the end result, but setting that as a goal is premature IMO. Especially when we don't understand all the problems in this space. > If you adopt a multiprefix solution, a clean support will > require support > from the external hosts. Other solutions like the tunnel > based solutions, > are not so clean i am not so sure that are cleaner than the > single prefixed > ones. => I didn't understand the "other" solution, why is tunnelling needed? and why is it not clean? Additionally, a multiprefix solution will require > support from LFN. > > So, my bet would be to try to explore a single prefixed solution that > provides transparent support for ubiquity and see how we can > address the > case when it splits. => I'm going to consider both approaches and see what ends up being more scalable in the long term. At the moment I can't see the single prefix case as being realistic for a general multihoming solution. Since the easy case (of MRs being fixed in relation to each other) is solveable by either approach, I don't see why we should end up with a single prefix solution for the "short" term and another solution for the long term. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From exim@www1.ietf.org Sun Mar 28 10:56:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22438 for ; Sun, 28 Mar 2004 10:56:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cdb-0006gk-LC for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 10:55:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SFtpdS025709 for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 10:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cdb-0006ga-Dr for nemo-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 10:55:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22428 for ; Sun, 28 Mar 2004 10:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7cdZ-0003e4-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 10:55:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7cce-0003Vn-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 10:54:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7cbo-0003NX-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 10:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cbp-0006PM-9n; Sun, 28 Mar 2004 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cbg-0006OC-2V for nemo@optimus.ietf.org; Sun, 28 Mar 2004 10:53:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22360 for ; Sun, 28 Mar 2004 10:53:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7cbd-0003Mb-00 for nemo@ietf.org; Sun, 28 Mar 2004 10:53:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7caa-0003EZ-00 for nemo@ietf.org; Sun, 28 Mar 2004 10:52:44 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7cZi-00031G-00 for nemo@ietf.org; Sun, 28 Mar 2004 10:51:50 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 28 Mar 2004 10:51:12 -0500 Date: Sun, 28 Mar 2004 10:51:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: [SPAM] - multiple prefixes, multihoming ans spliting (was RE: [nemo] RE: splitting moving networks (was: DND test) - Email found in subject Thread-Index: AcQUxBqsh6f883kSQjywVFGDnR17hAAEKulA Content-Class: urn:content-classes:message From: "Soliman Hesham" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 To: , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 28 Mar 2004 15:51:12.0609 (UTC) FILETIME=[7ECF4510:01C414DC] Content-Transfer-Encoding: 7bit Subject: [nemo] multiple prefixes, multihoming and spliting Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > => As I stated before, I think it's cleaner to have > > different MNPs for MRs. > > First of all, let's first define what is the goal of having > multiple MR, or > put in another way, which is the goal of being multihomed. > > Because of the nature of multihoming in NEMO, i think that > the support for > multiple technologies is a very important goal, so i guess that a > multihoming solution should support this. This means that we > have two MR > with different access technologies, so packets have to be > forwarded through > the router that has a link available. > I guess that is expected that links will become available > and unavailable > quite often when the network is moving, so it is important > that established > connections are preserved when switching technologies (and MRs) > > So i think that important requirements for multihoming in > nemo are what some > can call transparent support for ubiquity. => Agreed. > > Now, this is different from the fault tolerance requirement > (despite what i > have claimed before :-), since this is very localized > problem, the links > that can "fail" are the links between the MR and the access > routers. => Exactly, this is one point I wanted to clarify in an earlier response to you. This > would allow a solution that consists in mechanisms based in > the HA, or even > in the Home network perhaps in the visited network, but not much more => We can also include the MR(s) as a possibility. > > An possibility as you mention would be to use multiple > prefixes, one per MR. > > The problem here is that one prefix is associated with a MR, > so with an > access technology. So when this access technology is > unavailable, this > prefix would become unavailable. => Right. > For example, suppose you have MR1 with Pref1 and MR2 with Pref2 > There is also a LFN, that in order to be reachable through both > technologies, it has to configure two addresses, Pref1:LFN > and Pref2:LFN > Suppose now that LFN has established a communication with a > host in the > internet, Host1, using Pref1:LFN. > suddenly, the network moves and the technology that is using > MR1 is no > longer available. How do you preserve the established session? > > To do that you can: > Modify the external host Host1 to support multiple addresses > per connection. > This may be part of a general multihoming solution, but this > will take time > to be deployed => Well you can use existing solutions to do that: MIP. But I need to look into it a bit deeper to see how the home address config will work. > Make some tunnels between the MR so that they forward > packets belonging to > the other prefix, which actually you end up with both > routers forwarding the > same prefix, which i am not sure this is so clean. => That wouldn't solve this problem anyway since one of the MRs is not connected to the Internet. What you need to do is make sure that MR2's HA will accept MR1's traffic. This can easily work when both HAs are in the same ISP's domain. > > There are also other problems with this multiprefixed setup, like for > instance how do you select the source address that is > working properly for > initiating a communication. Probably you will need a > mechanism in the LFN to > retry with different source addresses. This may also be part > of a general > multihoming solution, but again may take longer to deploy. => It's a part of any multiaddressing solution. Let me comment on a couple of points here: - If MRs are connected to different access technologies then we need information to be sent from those MRs to MNNs to inform them about the implications of selecting certain addresses. This is essentially the same problem for multihomed hosts (note by multihomed I mean a host with more than one interface), except that in the multihomed host case this information is internal. - Fault detection, router failure ...etc can be achieved with ND. How timely this is depends on tuning ND information. - The fact that adding this stuff will take time is in no way discrediting the approach. Note that adding this information does not mean we need to wait for a full multihoming solution with, for example, location/identifier split. This is not relevant for the link-local problems that we're addressing here. > > So my comment essentially is: the support for ubiquity seems > an important > goal and that IMHO can be solved by adding some mechanisms > to specific > devices, like the HA, and MR only. => This may well be the end result, but setting that as a goal is premature IMO. Especially when we don't understand all the problems in this space. > If you adopt a multiprefix solution, a clean support will > require support > from the external hosts. Other solutions like the tunnel > based solutions, > are not so clean i am not so sure that are cleaner than the > single prefixed > ones. => I didn't understand the "other" solution, why is tunnelling needed? and why is it not clean? Additionally, a multiprefix solution will require > support from LFN. > > So, my bet would be to try to explore a single prefixed solution that > provides transparent support for ubiquity and see how we can > address the > case when it splits. => I'm going to consider both approaches and see what ends up being more scalable in the long term. At the moment I can't see the single prefix case as being realistic for a general multihoming solution. Since the easy case (of MRs being fixed in relation to each other) is solveable by either approach, I don't see why we should end up with a single prefix solution for the "short" term and another solution for the long term. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From nemo-admin@ietf.org Sun Mar 28 19:07:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12710 for ; Sun, 28 Mar 2004 19:07:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7kIv-0004vt-83; Sun, 28 Mar 2004 19:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7kHy-0004pJ-Qi for nemo@optimus.ietf.org; Sun, 28 Mar 2004 19:06:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12580 for ; Sun, 28 Mar 2004 19:05:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7kHv-0006Of-00 for nemo@ietf.org; Sun, 28 Mar 2004 19:05:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7kGz-0006GJ-00 for nemo@ietf.org; Sun, 28 Mar 2004 19:05:02 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B7kG8-00060D-00 for nemo@ietf.org; Sun, 28 Mar 2004 19:04:08 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7BE1617B02; Mon, 29 Mar 2004 02:03:37 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id D376117B08; Mon, 29 Mar 2004 02:03:32 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , Date: Mon, 29 Mar 2004 02:00:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] RE: multiple prefixes, multihoming and spliting Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > This > > would allow a solution that consists in mechanisms based in > > the HA, or even > > in the Home network perhaps in the visited network, but not much more > > => We can also include the MR(s) as a possibility. indeed [...] > > For example, suppose you have MR1 with Pref1 and MR2 with Pref2 > > There is also a LFN, that in order to be reachable through both > > technologies, it has to configure two addresses, Pref1:LFN > > and Pref2:LFN > > Suppose now that LFN has established a communication with a > > host in the > > internet, Host1, using Pref1:LFN. > > suddenly, the network moves and the technology that is using > > MR1 is no > > longer available. How do you preserve the established session? > > > > To do that you can: > > Modify the external host Host1 to support multiple addresses > > per connection. > > This may be part of a general multihoming solution, but this > > will take time > > to be deployed > > => Well you can use existing solutions to do that: MIP. Been there before, and i haven't been able to make it work if you use RR check. A detailed analysis of how i would build a multihoming support solution using MIP can be found at: draft-bagnulo-multi6-mnm-00.txt Basically the conclusion is that a connection can survive only 7 minutes after the HoA is unreachable because BCE lifetime expiring. After 7 min, the connection is down. > But I need to look into it a bit deeper to see how the > home address config will work. > > > Make some tunnels between the MR so that they forward > > packets belonging to > > the other prefix, which actually you end up with both > > routers forwarding the > > same prefix, which i am not sure this is so clean. > > => That wouldn't solve this problem anyway since one > of the MRs is not connected to the Internet. What you > need to do is make sure that MR2's HA will accept MR1's > traffic. This can easily work when both HAs are in the > same ISP's domain. > Indeed, you need 4 tunnels (to solve both ingress filtering and reachability) BAsically the type of solution that i am considering is RFC 3178, RFC 2260 > > > > There are also other problems with this multiprefixed setup, like for > > instance how do you select the source address that is > > working properly for > > initiating a communication. Probably you will need a > > mechanism in the LFN to > > retry with different source addresses. This may also be part > > of a general > > multihoming solution, but again may take longer to deploy. > > => It's a part of any multiaddressing solution. Let > me comment on a couple of points here: > > - If MRs are connected to different access technologies > then we need information to be sent from those MRs to > MNNs to inform them about the implications of selecting > certain addresses. This is essentially the same problem > for multihomed hosts (note by multihomed I mean a host > with more than one interface), except that in the > multihomed host case this information is internal. Well, this is one step more that i was considering. I was mainly focusing in fault tolerance, you are also including policing. Policing can be done by the hosts or by the routing system. If you do host based policing, the path selection is performed by the host and there is harder to enforce it by the routing system. This would be more like the multiprefix approach. The single prefix approach, allows the routers to define and enforce policing. Both approaches have drawbacks and benefits, but i guess that allowing the network administrator to enforce policy is an important benefit. > > - Fault detection, router failure ...etc can be achieved > with ND. How timely this is depends on tuning ND information. > > - The fact that adding this stuff will take time is > in no way discrediting the approach. Agreed, but adding stuff usually increases the complexity of the solution > Note that adding > this information does not mean we need to wait for > a full multihoming solution with, for example, location/identifier > split. This is not relevant for the link-local problems > that we're addressing here. Agree, but it depends on which stuff are waiting for. Some of the stuff may require a full multihoming solution. > > > > > So my comment essentially is: the support for ubiquity seems > > an important > > goal and that IMHO can be solved by adding some mechanisms > > to specific > > devices, like the HA, and MR only. > > => This may well be the end result, but setting > that as a goal is premature IMO. Especially when we > don't understand all the problems in this space. Agree. I was just stating where would i focus my energy when addressing this problem. > > > If you adopt a multiprefix solution, a clean support will > > require support > > from the external hosts. Other solutions like the tunnel > > based solutions, > > are not so clean i am not so sure that are cleaner than the > > single prefixed > > ones. > > => I didn't understand the "other" solution, why is tunnelling > needed? I have in mind something like RFC 3178, RFC2260 > and why is it not clean? You were the one who introduced the clean word :-) No, it is just that when you start adding tunnels to a solution it starts getting messier IMHO, You end up with MTU problems, fragmenting overhead manual config and so on. So, i am just saying that while is seems a clean approach to assign a prefix to each MR, then when you start trying to provide fault tolerance support, you need other stuff that may turn the solution a bit more messier, so we have to look at the complete picture to compare. > > Additionally, a multiprefix solution will require > > support from LFN. > > > > So, my bet would be to try to explore a single prefixed solution that > > provides transparent support for ubiquity and see how we can > > address the > > case when it splits. > > => I'm going to consider both approaches and see > what ends up being more scalable in the long term. Fine. I am willing to provide my opinion if you find it usefull > At the moment I can't see the single prefix case > as being realistic for a general multihoming solution. After trying to solve the problems of a generic solution that requires multiprefix i can see lots of the difficulties that this approach presents :-) > Since the easy case (of MRs being fixed in relation > to each other) is solveable by either approach, > I don't see why we should end up with a single prefix > solution for the "short" term and another solution > for the long term. Actually, i see it more like that you can solve the ubiquity problem with a single prefix, but you need multiprefixes to support general fault tolerance. But i guess that you will want ubiquity more often than fault tolerance, and i see ubiquity support much more urgent than fault tolerance, but i may be wrong. I mean, the only reason that i can see so far that is worth all the effort of multiaddressing is preserving routing system scalability, which is why the generic multihoming approach requires it. Other problems that can be solved with alternative approaches, i would look very into them before going to multiaddressing. Regards, marcelo > > Hesham > > ======================================================== > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review or distribution by other is > strictly prohibited. If you are not the inteded recipient please contact > the sender and delete all copies. > ======================================================== > From exim@www1.ietf.org Sun Mar 28 19:09:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12790 for ; Sun, 28 Mar 2004 19:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7kKt-0005Pq-Gz for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 19:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T0939x020800 for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 19:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7kKt-0005PA-9p for nemo-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 19:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12766 for ; Sun, 28 Mar 2004 19:08:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7kKq-0006lQ-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 19:09:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7kJu-0006eM-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 19:08:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7kIw-0006XK-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 19:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7kIv-0004vt-83; Sun, 28 Mar 2004 19:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7kHy-0004pJ-Qi for nemo@optimus.ietf.org; Sun, 28 Mar 2004 19:06:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12580 for ; Sun, 28 Mar 2004 19:05:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7kHv-0006Of-00 for nemo@ietf.org; Sun, 28 Mar 2004 19:05:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7kGz-0006GJ-00 for nemo@ietf.org; Sun, 28 Mar 2004 19:05:02 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B7kG8-00060D-00 for nemo@ietf.org; Sun, 28 Mar 2004 19:04:08 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7BE1617B02; Mon, 29 Mar 2004 02:03:37 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id D376117B08; Mon, 29 Mar 2004 02:03:32 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , Date: Mon, 29 Mar 2004 02:00:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [nemo] RE: multiple prefixes, multihoming and spliting Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This > > would allow a solution that consists in mechanisms based in > > the HA, or even > > in the Home network perhaps in the visited network, but not much more > > => We can also include the MR(s) as a possibility. indeed [...] > > For example, suppose you have MR1 with Pref1 and MR2 with Pref2 > > There is also a LFN, that in order to be reachable through both > > technologies, it has to configure two addresses, Pref1:LFN > > and Pref2:LFN > > Suppose now that LFN has established a communication with a > > host in the > > internet, Host1, using Pref1:LFN. > > suddenly, the network moves and the technology that is using > > MR1 is no > > longer available. How do you preserve the established session? > > > > To do that you can: > > Modify the external host Host1 to support multiple addresses > > per connection. > > This may be part of a general multihoming solution, but this > > will take time > > to be deployed > > => Well you can use existing solutions to do that: MIP. Been there before, and i haven't been able to make it work if you use RR check. A detailed analysis of how i would build a multihoming support solution using MIP can be found at: draft-bagnulo-multi6-mnm-00.txt Basically the conclusion is that a connection can survive only 7 minutes after the HoA is unreachable because BCE lifetime expiring. After 7 min, the connection is down. > But I need to look into it a bit deeper to see how the > home address config will work. > > > Make some tunnels between the MR so that they forward > > packets belonging to > > the other prefix, which actually you end up with both > > routers forwarding the > > same prefix, which i am not sure this is so clean. > > => That wouldn't solve this problem anyway since one > of the MRs is not connected to the Internet. What you > need to do is make sure that MR2's HA will accept MR1's > traffic. This can easily work when both HAs are in the > same ISP's domain. > Indeed, you need 4 tunnels (to solve both ingress filtering and reachability) BAsically the type of solution that i am considering is RFC 3178, RFC 2260 > > > > There are also other problems with this multiprefixed setup, like for > > instance how do you select the source address that is > > working properly for > > initiating a communication. Probably you will need a > > mechanism in the LFN to > > retry with different source addresses. This may also be part > > of a general > > multihoming solution, but again may take longer to deploy. > > => It's a part of any multiaddressing solution. Let > me comment on a couple of points here: > > - If MRs are connected to different access technologies > then we need information to be sent from those MRs to > MNNs to inform them about the implications of selecting > certain addresses. This is essentially the same problem > for multihomed hosts (note by multihomed I mean a host > with more than one interface), except that in the > multihomed host case this information is internal. Well, this is one step more that i was considering. I was mainly focusing in fault tolerance, you are also including policing. Policing can be done by the hosts or by the routing system. If you do host based policing, the path selection is performed by the host and there is harder to enforce it by the routing system. This would be more like the multiprefix approach. The single prefix approach, allows the routers to define and enforce policing. Both approaches have drawbacks and benefits, but i guess that allowing the network administrator to enforce policy is an important benefit. > > - Fault detection, router failure ...etc can be achieved > with ND. How timely this is depends on tuning ND information. > > - The fact that adding this stuff will take time is > in no way discrediting the approach. Agreed, but adding stuff usually increases the complexity of the solution > Note that adding > this information does not mean we need to wait for > a full multihoming solution with, for example, location/identifier > split. This is not relevant for the link-local problems > that we're addressing here. Agree, but it depends on which stuff are waiting for. Some of the stuff may require a full multihoming solution. > > > > > So my comment essentially is: the support for ubiquity seems > > an important > > goal and that IMHO can be solved by adding some mechanisms > > to specific > > devices, like the HA, and MR only. > > => This may well be the end result, but setting > that as a goal is premature IMO. Especially when we > don't understand all the problems in this space. Agree. I was just stating where would i focus my energy when addressing this problem. > > > If you adopt a multiprefix solution, a clean support will > > require support > > from the external hosts. Other solutions like the tunnel > > based solutions, > > are not so clean i am not so sure that are cleaner than the > > single prefixed > > ones. > > => I didn't understand the "other" solution, why is tunnelling > needed? I have in mind something like RFC 3178, RFC2260 > and why is it not clean? You were the one who introduced the clean word :-) No, it is just that when you start adding tunnels to a solution it starts getting messier IMHO, You end up with MTU problems, fragmenting overhead manual config and so on. So, i am just saying that while is seems a clean approach to assign a prefix to each MR, then when you start trying to provide fault tolerance support, you need other stuff that may turn the solution a bit more messier, so we have to look at the complete picture to compare. > > Additionally, a multiprefix solution will require > > support from LFN. > > > > So, my bet would be to try to explore a single prefixed solution that > > provides transparent support for ubiquity and see how we can > > address the > > case when it splits. > > => I'm going to consider both approaches and see > what ends up being more scalable in the long term. Fine. I am willing to provide my opinion if you find it usefull > At the moment I can't see the single prefix case > as being realistic for a general multihoming solution. After trying to solve the problems of a generic solution that requires multiprefix i can see lots of the difficulties that this approach presents :-) > Since the easy case (of MRs being fixed in relation > to each other) is solveable by either approach, > I don't see why we should end up with a single prefix > solution for the "short" term and another solution > for the long term. Actually, i see it more like that you can solve the ubiquity problem with a single prefix, but you need multiprefixes to support general fault tolerance. But i guess that you will want ubiquity more often than fault tolerance, and i see ubiquity support much more urgent than fault tolerance, but i may be wrong. I mean, the only reason that i can see so far that is worth all the effort of multiaddressing is preserving routing system scalability, which is why the generic multihoming approach requires it. Other problems that can be solved with alternative approaches, i would look very into them before going to multiaddressing. Regards, marcelo > > Hesham > > ======================================================== > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review or distribution by other is > strictly prohibited. If you are not the inteded recipient please contact > the sender and delete all copies. > ======================================================== > From nemo-admin@ietf.org Sun Mar 28 21:39:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19543 for ; Sun, 28 Mar 2004 21:39:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mg2-0007G0-5d; Sun, 28 Mar 2004 21:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mfD-00077D-2o for nemo@optimus.ietf.org; Sun, 28 Mar 2004 21:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19464 for ; Sun, 28 Mar 2004 21:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7mfA-0003ql-00 for nemo@ietf.org; Sun, 28 Mar 2004 21:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7meK-0003jk-00 for nemo@ietf.org; Sun, 28 Mar 2004 21:37:17 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7mdp-0003aW-00 for nemo@ietf.org; Sun, 28 Mar 2004 21:36:45 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 28 Mar 2004 21:36:09 -0500 Date: Sun, 28 Mar 2004 21:36:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: multiple prefixes, multihoming and spliting Thread-Index: AcQVIUn6I6cs0mnQSCeRxAkgm4oajQAEqdfw Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 29 Mar 2004 02:36:09.0600 (UTC) FILETIME=[98038000:01C41536] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] RE: multiple prefixes, multihoming and spliting Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > To do that you can: > > > Modify the external host Host1 to support multiple addresses > > > per connection. > > > This may be part of a general multihoming solution, but this > > > will take time > > > to be deployed > > > > => Well you can use existing solutions to do that: MIP. > > Been there before, and i haven't been able to make it work > if you use RR > check. > A detailed analysis of how i would build a multihoming > support solution > using MIP can be found at: draft-bagnulo-multi6-mnm-00.txt > Basically the conclusion is that a connection can survive > only 7 minutes > after the HoA is unreachable because BCE lifetime expiring. > After 7 min, > the connection is down. => That's why I said I need to look into it to see how the _HoA_ config will work. I think you've considered the case of having multiple HoAs to provide multihoming support for the home site. I'm talking about switching CoAs. This is a different approach. I'm _not_ concerned with multihoming for the _home_site_. Like I said, I'll put it all in a draft. It's hard to explain it all on email. > > > > - If MRs are connected to different access technologies > > then we need information to be sent from those MRs to > > MNNs to inform them about the implications of selecting > > certain addresses. This is essentially the same problem > > for multihomed hosts (note by multihomed I mean a host > > with more than one interface), except that in the > > multihomed host case this information is internal. > > Well, this is one step more that i was considering. I was > mainly focusing in > fault tolerance, you are also including policing. => This is not policing, it's a matter of providing the right information for hosts to do policy-based src address selection. Policing > can be done by > the hosts or by the routing system. If you do host based > policing, the path > selection is performed by the host and there is harder to > enforce it by the > routing system. This would be more like the multiprefix approach. > The single prefix approach, allows the routers to define and enforce > policing. > Both approaches have drawbacks and benefits, but i guess > that allowing the > network administrator to enforce policy is an important benefit. => I's impossible to do what I'm trying to do by the administrator. It has to be done by the end host. > > - The fact that adding this stuff will take time is > > in no way discrediting the approach. > > Agreed, but adding stuff usually increases the complexity of > the solution => Sure, I still think it's inevitable though. This might change after a deep analysis. > > Note that adding > > this information does not mean we need to wait for > > a full multihoming solution with, for example, location/identifier > > split. This is not relevant for the link-local problems > > that we're addressing here. > > Agree, but it depends on which stuff are waiting for. Some > of the stuff may > require a full multihoming solution. => Not the default router - host interface, this is needed in all cases independently of the rehoming protocol. > > > If you adopt a multiprefix solution, a clean support will > > > require support > > > from the external hosts. Other solutions like the tunnel > > > based solutions, > > > are not so clean i am not so sure that are cleaner than the > > > single prefixed > > > ones. > > > > => I didn't understand the "other" solution, why is tunnelling > > needed? > > I have in mind something like RFC 3178, RFC2260 > > > and why is it not clean? > > You were the one who introduced the clean word :-) > > No, it is just that when you start adding tunnels to a > solution it starts > getting messier IMHO, You end up with MTU problems, > fragmenting overhead > manual config and so on. > > So, i am just saying that while is seems a clean approach to > assign a prefix > to each MR, then when you start trying to provide fault > tolerance support, > you need other stuff that may turn the solution a bit more > messier, so we > have to look at the complete picture to compare. => Ok, if we want to look at the complete picture we should also consider the cases where the 2 MRs are not fixed in relation to each other. > > => I'm going to consider both approaches and see > > what ends up being more scalable in the long term. > > Fine. I am willing to provide my opinion if you find it usefull => Please continue to do that. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From exim@www1.ietf.org Sun Mar 28 21:41:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19624 for ; Sun, 28 Mar 2004 21:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mhz-0007cV-Rg for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 21:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T2f370029287 for nemo-archive@odin.ietf.org; Sun, 28 Mar 2004 21:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mhz-0007cI-Lb for nemo-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 21:41:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19598 for ; Sun, 28 Mar 2004 21:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7mhw-0004GF-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 21:41:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7mgy-00047r-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 21:40:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7mg3-0003zP-00 for nemo-web-archive@ietf.org; Sun, 28 Mar 2004 21:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mg2-0007G0-5d; Sun, 28 Mar 2004 21:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mfD-00077D-2o for nemo@optimus.ietf.org; Sun, 28 Mar 2004 21:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19464 for ; Sun, 28 Mar 2004 21:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7mfA-0003ql-00 for nemo@ietf.org; Sun, 28 Mar 2004 21:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7meK-0003jk-00 for nemo@ietf.org; Sun, 28 Mar 2004 21:37:17 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7mdp-0003aW-00 for nemo@ietf.org; Sun, 28 Mar 2004 21:36:45 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 28 Mar 2004 21:36:09 -0500 Date: Sun, 28 Mar 2004 21:36:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: multiple prefixes, multihoming and spliting Thread-Index: AcQVIUn6I6cs0mnQSCeRxAkgm4oajQAEqdfw Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 29 Mar 2004 02:36:09.0600 (UTC) FILETIME=[98038000:01C41536] Content-Transfer-Encoding: 7bit Subject: [nemo] RE: multiple prefixes, multihoming and spliting Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > To do that you can: > > > Modify the external host Host1 to support multiple addresses > > > per connection. > > > This may be part of a general multihoming solution, but this > > > will take time > > > to be deployed > > > > => Well you can use existing solutions to do that: MIP. > > Been there before, and i haven't been able to make it work > if you use RR > check. > A detailed analysis of how i would build a multihoming > support solution > using MIP can be found at: draft-bagnulo-multi6-mnm-00.txt > Basically the conclusion is that a connection can survive > only 7 minutes > after the HoA is unreachable because BCE lifetime expiring. > After 7 min, > the connection is down. => That's why I said I need to look into it to see how the _HoA_ config will work. I think you've considered the case of having multiple HoAs to provide multihoming support for the home site. I'm talking about switching CoAs. This is a different approach. I'm _not_ concerned with multihoming for the _home_site_. Like I said, I'll put it all in a draft. It's hard to explain it all on email. > > > > - If MRs are connected to different access technologies > > then we need information to be sent from those MRs to > > MNNs to inform them about the implications of selecting > > certain addresses. This is essentially the same problem > > for multihomed hosts (note by multihomed I mean a host > > with more than one interface), except that in the > > multihomed host case this information is internal. > > Well, this is one step more that i was considering. I was > mainly focusing in > fault tolerance, you are also including policing. => This is not policing, it's a matter of providing the right information for hosts to do policy-based src address selection. Policing > can be done by > the hosts or by the routing system. If you do host based > policing, the path > selection is performed by the host and there is harder to > enforce it by the > routing system. This would be more like the multiprefix approach. > The single prefix approach, allows the routers to define and enforce > policing. > Both approaches have drawbacks and benefits, but i guess > that allowing the > network administrator to enforce policy is an important benefit. => I's impossible to do what I'm trying to do by the administrator. It has to be done by the end host. > > - The fact that adding this stuff will take time is > > in no way discrediting the approach. > > Agreed, but adding stuff usually increases the complexity of > the solution => Sure, I still think it's inevitable though. This might change after a deep analysis. > > Note that adding > > this information does not mean we need to wait for > > a full multihoming solution with, for example, location/identifier > > split. This is not relevant for the link-local problems > > that we're addressing here. > > Agree, but it depends on which stuff are waiting for. Some > of the stuff may > require a full multihoming solution. => Not the default router - host interface, this is needed in all cases independently of the rehoming protocol. > > > If you adopt a multiprefix solution, a clean support will > > > require support > > > from the external hosts. Other solutions like the tunnel > > > based solutions, > > > are not so clean i am not so sure that are cleaner than the > > > single prefixed > > > ones. > > > > => I didn't understand the "other" solution, why is tunnelling > > needed? > > I have in mind something like RFC 3178, RFC2260 > > > and why is it not clean? > > You were the one who introduced the clean word :-) > > No, it is just that when you start adding tunnels to a > solution it starts > getting messier IMHO, You end up with MTU problems, > fragmenting overhead > manual config and so on. > > So, i am just saying that while is seems a clean approach to > assign a prefix > to each MR, then when you start trying to provide fault > tolerance support, > you need other stuff that may turn the solution a bit more > messier, so we > have to look at the complete picture to compare. => Ok, if we want to look at the complete picture we should also consider the cases where the 2 MRs are not fixed in relation to each other. > > => I'm going to consider both approaches and see > > what ends up being more scalable in the long term. > > Fine. I am willing to provide my opinion if you find it usefull => Please continue to do that. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From nemo-admin@ietf.org Mon Mar 29 02:05:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05981 for ; Mon, 29 Mar 2004 02:05:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qpR-0008DG-Re; Mon, 29 Mar 2004 02:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qod-0007lr-PN for nemo@optimus.ietf.org; Mon, 29 Mar 2004 02:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04428 for ; Mon, 29 Mar 2004 02:04:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7qoa-0000ZS-00 for nemo@ietf.org; Mon, 29 Mar 2004 02:04:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7qnb-0000Qn-00 for nemo@ietf.org; Mon, 29 Mar 2004 02:03:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B7qmg-0000DL-00 for nemo@ietf.org; Mon, 29 Mar 2004 02:02:10 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2004 23:10:13 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2T714sk016029; Mon, 29 Mar 2004 09:01:04 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 29 Mar 2004 08:01:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 08:01:35 +0100 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTZ9gwnWb9c2Z2TMypH5EP0CGISAAOVvywAB9tY+A= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , X-OriginalArrivalTime: 29 Mar 2004 07:01:36.0544 (UTC) FILETIME=[AD364A00:01C4155B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > If NEMO can detect the split mobile network and prohibit the > > split mobile network, there is no problem for the same MNP > > configuration. >=20 > =3D> I find this logic a bit skewed actually. Of course if > you start with shared MNPs then it follows that if we can > prevent splitting then everything is ok. There is only > a small problem: you can't prevent splitting. Hesham: what if the MR goes and the LFN stays? If you can not prevent the other splitting then you can't prevent that one either. In LFN there's the word fixed, for fixed relative to the MR. If there are 2 MRs on the ingress link then the LFN is fixed with regards to the 2 of them. As I said it's an atomic system by definition. The MR, its LFNs, a second MR is the ingress link is shared between to MRs. So the MRs are mobile but not related to each other. This case is not broken, and you can prevent the relative movement... One way is to package the 2 MRs together and call that a high availability MR :) Seems you did not get much support trying to bar that. And like I said if there's a split then all nodes that can split from each other must manage there own mobility.=20 Pascal From exim@www1.ietf.org Mon Mar 29 02:07:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08257 for ; Mon, 29 Mar 2004 02:07:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qrn-00010k-S6 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 02:07:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T77RoA003879 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 02:07:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qrn-00010K-BW for nemo-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 02:07:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07695 for ; Mon, 29 Mar 2004 02:07:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7qrj-0000zz-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 02:07:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7qqV-0000qZ-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 02:06:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7qpX-0000iV-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 02:05:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qpR-0008DG-Re; Mon, 29 Mar 2004 02:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qod-0007lr-PN for nemo@optimus.ietf.org; Mon, 29 Mar 2004 02:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04428 for ; Mon, 29 Mar 2004 02:04:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7qoa-0000ZS-00 for nemo@ietf.org; Mon, 29 Mar 2004 02:04:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7qnb-0000Qn-00 for nemo@ietf.org; Mon, 29 Mar 2004 02:03:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B7qmg-0000DL-00 for nemo@ietf.org; Mon, 29 Mar 2004 02:02:10 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2004 23:10:13 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2T714sk016029; Mon, 29 Mar 2004 09:01:04 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 29 Mar 2004 08:01:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 08:01:35 +0100 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQTZ9gwnWb9c2Z2TMypH5EP0CGISAAOVvywAB9tY+A= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , X-OriginalArrivalTime: 29 Mar 2004 07:01:36.0544 (UTC) FILETIME=[AD364A00:01C4155B] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > If NEMO can detect the split mobile network and prohibit the > > split mobile network, there is no problem for the same MNP > > configuration. >=20 > =3D> I find this logic a bit skewed actually. Of course if > you start with shared MNPs then it follows that if we can > prevent splitting then everything is ok. There is only > a small problem: you can't prevent splitting. Hesham: what if the MR goes and the LFN stays? If you can not prevent the other splitting then you can't prevent that one either. In LFN there's the word fixed, for fixed relative to the MR. If there are 2 MRs on the ingress link then the LFN is fixed with regards to the 2 of them. As I said it's an atomic system by definition. The MR, its LFNs, a second MR is the ingress link is shared between to MRs. So the MRs are mobile but not related to each other. This case is not broken, and you can prevent the relative movement... One way is to package the 2 MRs together and call that a high availability MR :) Seems you did not get much support trying to bar that. And like I said if there's a split then all nodes that can split from each other must manage there own mobility.=20 Pascal From nemo-admin@ietf.org Mon Mar 29 04:09:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20405 for ; Mon, 29 Mar 2004 04:09:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7slS-0006Vc-FZ; Mon, 29 Mar 2004 04:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7skp-0006P5-S8 for nemo@optimus.ietf.org; Mon, 29 Mar 2004 04:08:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20337 for ; Mon, 29 Mar 2004 04:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7skn-0003bL-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:08:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7sjs-0003U6-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:07:25 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7sjP-0003LZ-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:06:55 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 04:06:24 -0500 Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 04:06:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVW7EBMOARbU1JRs6cvGAnIvgrgwAD6qAA Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 29 Mar 2004 09:06:24.0631 (UTC) FILETIME=[1C75B070:01C4156D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > > If NEMO can detect the split mobile network and prohibit the > > > split mobile network, there is no problem for the same MNP > > > configuration. > > > > => I find this logic a bit skewed actually. Of course if > > you start with shared MNPs then it follows that if we can > > prevent splitting then everything is ok. There is only > > a small problem: you can't prevent splitting. > > Hesham: what if the MR goes and the LFN stays? If you can not prevent > the other splitting then you can't prevent that one either. => Correct. > > In LFN there's the word fixed, for fixed relative to the MR. If there > are 2 MRs on the ingress link then the LFN is fixed with > regards to the > 2 of them. => It's fixed but either MR can do the job for it. What happens when one prefix disappears from a link today? The nodes onlink just use the other prefix(es). As I said it's an atomic system by definition. The MR, its > LFNs, a second MR is the ingress link is shared between to > MRs. So the > MRs are mobile but not related to each other. This case is > not broken, => It's not broken but it's limited to certain scenarios. I never claimed it was broken. > and you can prevent the relative movement... One way is to > package the 2 > MRs together and call that a high availability MR :) => You're missing the point. This isn't about availability only, on some cases it'll just happen that 2 MRs appear then one disappear. Availability is just one aspect. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From exim@www1.ietf.org Mon Mar 29 04:11:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20495 for ; Mon, 29 Mar 2004 04:11:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7sn1-0006xC-GX for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 04:10:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T9AdkB026722 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 04:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7sn1-0006wv-1S for nemo-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 04:10:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20484 for ; Mon, 29 Mar 2004 04:10:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7smy-0003vj-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7sm1-0003mS-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:09:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7slV-0003dQ-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:09:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7slS-0006Vc-FZ; Mon, 29 Mar 2004 04:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7skp-0006P5-S8 for nemo@optimus.ietf.org; Mon, 29 Mar 2004 04:08:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20337 for ; Mon, 29 Mar 2004 04:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7skn-0003bL-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:08:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7sjs-0003U6-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:07:25 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7sjP-0003LZ-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:06:55 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 04:06:24 -0500 Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 04:06:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVW7EBMOARbU1JRs6cvGAnIvgrgwAD6qAA Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 29 Mar 2004 09:06:24.0631 (UTC) FILETIME=[1C75B070:01C4156D] Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > If NEMO can detect the split mobile network and prohibit the > > > split mobile network, there is no problem for the same MNP > > > configuration. > > > > => I find this logic a bit skewed actually. Of course if > > you start with shared MNPs then it follows that if we can > > prevent splitting then everything is ok. There is only > > a small problem: you can't prevent splitting. > > Hesham: what if the MR goes and the LFN stays? If you can not prevent > the other splitting then you can't prevent that one either. => Correct. > > In LFN there's the word fixed, for fixed relative to the MR. If there > are 2 MRs on the ingress link then the LFN is fixed with > regards to the > 2 of them. => It's fixed but either MR can do the job for it. What happens when one prefix disappears from a link today? The nodes onlink just use the other prefix(es). As I said it's an atomic system by definition. The MR, its > LFNs, a second MR is the ingress link is shared between to > MRs. So the > MRs are mobile but not related to each other. This case is > not broken, => It's not broken but it's limited to certain scenarios. I never claimed it was broken. > and you can prevent the relative movement... One way is to > package the 2 > MRs together and call that a high availability MR :) => You're missing the point. This isn't about availability only, on some cases it'll just happen that 2 MRs appear then one disappear. Availability is just one aspect. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From nemo-admin@ietf.org Mon Mar 29 04:40:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21685 for ; Mon, 29 Mar 2004 04:40:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tFS-0001RA-C3; Mon, 29 Mar 2004 04:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tEg-0001OC-18 for nemo@optimus.ietf.org; Mon, 29 Mar 2004 04:39:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21628 for ; Mon, 29 Mar 2004 04:39:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tEd-0000Dg-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:39:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tDe-00004K-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:38:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B7tCe-0007dW-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:37:08 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2004 01:45:10 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2T9Zgsw011141; Mon, 29 Mar 2004 11:36:01 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 29 Mar 2004 10:36:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 10:36:15 +0100 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVW7EBMOARbU1JRs6cvGAnIvgrgwAD6qAAAADSZNA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , X-OriginalArrivalTime: 29 Mar 2004 09:36:16.0530 (UTC) FILETIME=[4883C720:01C41571] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: lundi 29 mars 2004 11:06 > To: Pascal Thubert (pthubert); Ryuji Wakikawa > Cc: Alexandru.Petrescu@motorola.com; mbagnulo@ing.uc3m.es; nemo@ietf.org > Subject: RE: [nemo] RE: splitting moving networks (was: DND test) >=20 >=20 > > > > > > If NEMO can detect the split mobile network and prohibit the > > > > split mobile network, there is no problem for the same MNP > > > > configuration. > > > > > > =3D> I find this logic a bit skewed actually. Of course if > > > you start with shared MNPs then it follows that if we can > > > prevent splitting then everything is ok. There is only > > > a small problem: you can't prevent splitting. > > > > Hesham: what if the MR goes and the LFN stays? If you can not prevent > > the other splitting then you can't prevent that one either. >=20 > =3D> Correct. >=20 > > > > In LFN there's the word fixed, for fixed relative to the MR. If there > > are 2 MRs on the ingress link then the LFN is fixed with > > regards to the > > 2 of them. >=20 > =3D> It's fixed but either MR can do the job for it. > What happens when one prefix disappears from a link > today? The nodes onlink just use the other prefix(es). Is that so? In fact: 1) Connections are lost (HIP, where art thou?) 2) it takes quite some time for hosts to NUD their default GW, if they ever do. In the lab, we basically unplug and replug the interfaces to clean up the hosts when such a thing happens. There are a lot of DNA/NUD/MIP RA-interval based solutions proposed but if you talk about today, it's pretty slow. My point is that while I agree with a ultimate goal that I seem to understand from all this, we do not have the overall technology to do it. And I believe that the Nemo spec is OK in the context.=20 > As I said it's an atomic system by definition. The MR, its > > LFNs, a second MR is the ingress link is shared between to > > MRs. So the > > MRs are mobile but not related to each other. This case is > > not broken, >=20 > =3D> It's not broken but it's limited to certain scenarios. > I never claimed it was broken. Cool.=20 > > and you can prevent the relative movement... One way is to > > package the 2 > > MRs together and call that a high availability MR :) >=20 > =3D> You're missing the point. This isn't about > availability only, on some cases it'll just happen > that 2 MRs appear then one disappear. > Availability is just one aspect. Yes, I believe you're right about corner cases. Splitting them in 2 sets: Set a: multi6/IPv6 problems (connections broken, slow NUD on default GW) Set b: new problems induced by Nemo. Since the Nemo MR looks like a standard GW to the LFNs, the only thing I can see in set b is against the DND test as I proposed it. But I see nothing specific about the nemo spec? Pascal From exim@www1.ietf.org Mon Mar 29 04:42:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21812 for ; Mon, 29 Mar 2004 04:42:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tHd-0001pM-HP for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 04:42:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T9gHEZ007024 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 04:42:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tHd-0001pD-5e for nemo-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 04:42:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21741 for ; Mon, 29 Mar 2004 04:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tHa-0000dY-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:42:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tGb-0000UJ-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:41:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7tFc-0000Lw-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:40:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tFS-0001RA-C3; Mon, 29 Mar 2004 04:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tEg-0001OC-18 for nemo@optimus.ietf.org; Mon, 29 Mar 2004 04:39:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21628 for ; Mon, 29 Mar 2004 04:39:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tEd-0000Dg-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:39:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tDe-00004K-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:38:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B7tCe-0007dW-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:37:08 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2004 01:45:10 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2T9Zgsw011141; Mon, 29 Mar 2004 11:36:01 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 29 Mar 2004 10:36:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 10:36:15 +0100 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVW7EBMOARbU1JRs6cvGAnIvgrgwAD6qAAAADSZNA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , X-OriginalArrivalTime: 29 Mar 2004 09:36:16.0530 (UTC) FILETIME=[4883C720:01C41571] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: lundi 29 mars 2004 11:06 > To: Pascal Thubert (pthubert); Ryuji Wakikawa > Cc: Alexandru.Petrescu@motorola.com; mbagnulo@ing.uc3m.es; nemo@ietf.org > Subject: RE: [nemo] RE: splitting moving networks (was: DND test) >=20 >=20 > > > > > > If NEMO can detect the split mobile network and prohibit the > > > > split mobile network, there is no problem for the same MNP > > > > configuration. > > > > > > =3D> I find this logic a bit skewed actually. Of course if > > > you start with shared MNPs then it follows that if we can > > > prevent splitting then everything is ok. There is only > > > a small problem: you can't prevent splitting. > > > > Hesham: what if the MR goes and the LFN stays? If you can not prevent > > the other splitting then you can't prevent that one either. >=20 > =3D> Correct. >=20 > > > > In LFN there's the word fixed, for fixed relative to the MR. If there > > are 2 MRs on the ingress link then the LFN is fixed with > > regards to the > > 2 of them. >=20 > =3D> It's fixed but either MR can do the job for it. > What happens when one prefix disappears from a link > today? The nodes onlink just use the other prefix(es). Is that so? In fact: 1) Connections are lost (HIP, where art thou?) 2) it takes quite some time for hosts to NUD their default GW, if they ever do. In the lab, we basically unplug and replug the interfaces to clean up the hosts when such a thing happens. There are a lot of DNA/NUD/MIP RA-interval based solutions proposed but if you talk about today, it's pretty slow. My point is that while I agree with a ultimate goal that I seem to understand from all this, we do not have the overall technology to do it. And I believe that the Nemo spec is OK in the context.=20 > As I said it's an atomic system by definition. The MR, its > > LFNs, a second MR is the ingress link is shared between to > > MRs. So the > > MRs are mobile but not related to each other. This case is > > not broken, >=20 > =3D> It's not broken but it's limited to certain scenarios. > I never claimed it was broken. Cool.=20 > > and you can prevent the relative movement... One way is to > > package the 2 > > MRs together and call that a high availability MR :) >=20 > =3D> You're missing the point. This isn't about > availability only, on some cases it'll just happen > that 2 MRs appear then one disappear. > Availability is just one aspect. Yes, I believe you're right about corner cases. Splitting them in 2 sets: Set a: multi6/IPv6 problems (connections broken, slow NUD on default GW) Set b: new problems induced by Nemo. Since the Nemo MR looks like a standard GW to the LFNs, the only thing I can see in set b is against the DND test as I proposed it. But I see nothing specific about the nemo spec? Pascal From nemo-admin@ietf.org Mon Mar 29 04:54:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22536 for ; Mon, 29 Mar 2004 04:54:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tT1-0002ar-Mi; Mon, 29 Mar 2004 04:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tSJ-0002WC-VO for nemo@optimus.ietf.org; Mon, 29 Mar 2004 04:53:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22468 for ; Mon, 29 Mar 2004 04:53:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tSG-0002Jr-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:53:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tRL-0002Ag-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:52:20 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7tQQ-0001tJ-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:51:22 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 04:50:53 -0500 Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 04:50:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVcWfk1qWyCeK5S9G8okGIx43IwwAAIw5Q Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 29 Mar 2004 09:50:53.0944 (UTC) FILETIME=[537E8780:01C41573] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > In LFN there's the word fixed, for fixed relative to the MR. If > there > > > are 2 MRs on the ingress link then the LFN is fixed with > > > regards to the > > > 2 of them. > > > > => It's fixed but either MR can do the job for it. > > What happens when one prefix disappears from a link > > today? The nodes onlink just use the other prefix(es). > > Is that so? In fact: > > 1) Connections are lost (HIP, where art thou?) => And? Is there a requirement to maintain connectivity in this particular case? This will happen regardless of the solution you use. > > 2) it takes quite some time for hosts to NUD their default > GW, if they > ever do. In the lab, we basically unplug and replug the interfaces to > clean up the hosts when such a thing happens. There are a lot of > DNA/NUD/MIP RA-interval based solutions proposed but if you > talk about > today, it's pretty slow. => Sigh. I'm trying to focus this discussion on 2 things: - The validity of the scenario - Requirements. We already discussed that there are various problems to be solved. For the split case, problems exist anyway regardless of the number of prefixes. They're just _different_ problems. Now, regardless of how many problems exist, it seems unproductive to say : "This is too hard, discard those scenarios". This statement doesn't provide alternatives. This might be ok if we think the scenario is not real or not worth solving. But we didn't even discuss this, so ..... > > My point is that while I agree with a ultimate goal that I seem to > understand from all this, we do not have the overall technology to do > it. => I know that! It's not the point. And I believe that the Nemo spec is OK in the context. => The nemo spec shouldn't attempt to solve the split case. My original comment on the nemo spec is that it's vague and doesn't state the limitations of the current solution. This was already addressed by Thierry's comment to add a disclaimer that multihoming is not guaranteed to work. > > > and you can prevent the relative movement... One way is to > > > package the 2 > > > MRs together and call that a high availability MR :) > > > > => You're missing the point. This isn't about > > availability only, on some cases it'll just happen > > that 2 MRs appear then one disappear. > > Availability is just one aspect. > Yes, I believe you're right about corner cases. Splitting them in 2 > sets: > Set a: multi6/IPv6 problems (connections broken, slow NUD on > default GW) > Set b: new problems induced by Nemo. => Agreed on a high level. We might want to split them further later. > > Since the Nemo MR looks like a standard GW to the LFNs, the > only thing I > can see in set b is against the DND test as I proposed it. => Sorry I can't parse this. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From exim@www1.ietf.org Mon Mar 29 04:55:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22585 for ; Mon, 29 Mar 2004 04:55:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tUO-0002o5-32 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 04:55:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T9tSQF010787 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 04:55:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tUN-0002na-4H for nemo-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 04:55:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22582 for ; Mon, 29 Mar 2004 04:55:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tUK-0002av-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:55:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tTM-0002TU-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:54:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7tT5-0002M3-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 04:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tT1-0002ar-Mi; Mon, 29 Mar 2004 04:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tSJ-0002WC-VO for nemo@optimus.ietf.org; Mon, 29 Mar 2004 04:53:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22468 for ; Mon, 29 Mar 2004 04:53:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tSG-0002Jr-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:53:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tRL-0002Ag-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:52:20 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7tQQ-0001tJ-00 for nemo@ietf.org; Mon, 29 Mar 2004 04:51:22 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 04:50:53 -0500 Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 04:50:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVcWfk1qWyCeK5S9G8okGIx43IwwAAIw5Q Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 29 Mar 2004 09:50:53.0944 (UTC) FILETIME=[537E8780:01C41573] Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > In LFN there's the word fixed, for fixed relative to the MR. If > there > > > are 2 MRs on the ingress link then the LFN is fixed with > > > regards to the > > > 2 of them. > > > > => It's fixed but either MR can do the job for it. > > What happens when one prefix disappears from a link > > today? The nodes onlink just use the other prefix(es). > > Is that so? In fact: > > 1) Connections are lost (HIP, where art thou?) => And? Is there a requirement to maintain connectivity in this particular case? This will happen regardless of the solution you use. > > 2) it takes quite some time for hosts to NUD their default > GW, if they > ever do. In the lab, we basically unplug and replug the interfaces to > clean up the hosts when such a thing happens. There are a lot of > DNA/NUD/MIP RA-interval based solutions proposed but if you > talk about > today, it's pretty slow. => Sigh. I'm trying to focus this discussion on 2 things: - The validity of the scenario - Requirements. We already discussed that there are various problems to be solved. For the split case, problems exist anyway regardless of the number of prefixes. They're just _different_ problems. Now, regardless of how many problems exist, it seems unproductive to say : "This is too hard, discard those scenarios". This statement doesn't provide alternatives. This might be ok if we think the scenario is not real or not worth solving. But we didn't even discuss this, so ..... > > My point is that while I agree with a ultimate goal that I seem to > understand from all this, we do not have the overall technology to do > it. => I know that! It's not the point. And I believe that the Nemo spec is OK in the context. => The nemo spec shouldn't attempt to solve the split case. My original comment on the nemo spec is that it's vague and doesn't state the limitations of the current solution. This was already addressed by Thierry's comment to add a disclaimer that multihoming is not guaranteed to work. > > > and you can prevent the relative movement... One way is to > > > package the 2 > > > MRs together and call that a high availability MR :) > > > > => You're missing the point. This isn't about > > availability only, on some cases it'll just happen > > that 2 MRs appear then one disappear. > > Availability is just one aspect. > Yes, I believe you're right about corner cases. Splitting them in 2 > sets: > Set a: multi6/IPv6 problems (connections broken, slow NUD on > default GW) > Set b: new problems induced by Nemo. => Agreed on a high level. We might want to split them further later. > > Since the Nemo MR looks like a standard GW to the LFNs, the > only thing I > can see in set b is against the DND test as I proposed it. => Sorry I can't parse this. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From nemo-admin@ietf.org Mon Mar 29 05:07:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23119 for ; Mon, 29 Mar 2004 05:07:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tfa-00043O-41; Mon, 29 Mar 2004 05:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tev-0003wH-IN for nemo@optimus.ietf.org; Mon, 29 Mar 2004 05:06:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23044 for ; Mon, 29 Mar 2004 05:06:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tes-00043y-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:06:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tdq-0003w7-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:05:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B7tct-0003h9-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:04:15 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2004 02:12:20 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2TA2DtO024671; Mon, 29 Mar 2004 12:03:02 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 29 Mar 2004 11:03:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 11:03:27 +0100 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVcWfk1qWyCeK5S9G8okGIx43IwwAAIw5QAAB8g0A= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , X-OriginalArrivalTime: 29 Mar 2004 10:03:34.0864 (UTC) FILETIME=[1909B500:01C41575] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > > > > Since the Nemo MR looks like a standard GW to the LFNs, the > > only thing I > > can see in set b is against the DND test as I proposed it. >=20 > =3D> Sorry I can't parse this. In the case of an atomic system with 2 MRs sharing an ingress link and one MNP with a bunch of LFNs. Is that a problem that is specific to Nemo in the case where one MR dies? I mean as opposed to the same config but the routers are fixed? I think not. Pascal From exim@www1.ietf.org Mon Mar 29 05:09:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23214 for ; Mon, 29 Mar 2004 05:09:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7th8-0004Rn-0P for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 05:08:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TA8b3u017096 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 05:08:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7th6-0004RL-FD for nemo-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 05:08:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23209 for ; Mon, 29 Mar 2004 05:08:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7th3-0004P0-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 05:08:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tg8-0004Ft-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 05:07:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7tfc-00046U-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 05:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tfa-00043O-41; Mon, 29 Mar 2004 05:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tev-0003wH-IN for nemo@optimus.ietf.org; Mon, 29 Mar 2004 05:06:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23044 for ; Mon, 29 Mar 2004 05:06:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tes-00043y-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:06:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tdq-0003w7-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:05:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B7tct-0003h9-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:04:15 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2004 02:12:20 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2TA2DtO024671; Mon, 29 Mar 2004 12:03:02 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 29 Mar 2004 11:03:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 11:03:27 +0100 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVcWfk1qWyCeK5S9G8okGIx43IwwAAIw5QAAB8g0A= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Ryuji Wakikawa" Cc: , , X-OriginalArrivalTime: 29 Mar 2004 10:03:34.0864 (UTC) FILETIME=[1909B500:01C41575] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > > > > Since the Nemo MR looks like a standard GW to the LFNs, the > > only thing I > > can see in set b is against the DND test as I proposed it. >=20 > =3D> Sorry I can't parse this. In the case of an atomic system with 2 MRs sharing an ingress link and one MNP with a bunch of LFNs. Is that a problem that is specific to Nemo in the case where one MR dies? I mean as opposed to the same config but the routers are fixed? I think not. Pascal From nemo-admin@ietf.org Mon Mar 29 05:26:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24034 for ; Mon, 29 Mar 2004 05:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7txy-0005fV-6u; Mon, 29 Mar 2004 05:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7txC-0005dB-UZ for nemo@optimus.ietf.org; Mon, 29 Mar 2004 05:25:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23924 for ; Mon, 29 Mar 2004 05:25:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tx9-0006p7-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:25:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7twB-0006hZ-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:24:11 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7tvD-0006Uw-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:23:11 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 05:22:42 -0500 Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 05:22:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVdSkq8TyYXMnxQNu7Jbu5lolJegAARkIA Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 29 Mar 2004 10:22:42.0303 (UTC) FILETIME=[C4F700F0:01C41577] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In the case of an atomic system with 2 MRs sharing an > ingress link and > one MNP with a bunch of LFNs. Is that a problem that is > specific to Nemo > in the case where one MR dies? I mean as opposed to the same > config but > the routers are fixed? => If you constrain the config to routers that are fixed w.r.t each other then No. Our argument is basically that you can't generalise this scenario and assume that it is the case for all mobile networks IMO. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From exim@www1.ietf.org Mon Mar 29 05:27:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24062 for ; Mon, 29 Mar 2004 05:27:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tzL-0005qv-T2 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 05:27:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TARR8J022497 for nemo-archive@odin.ietf.org; Mon, 29 Mar 2004 05:27:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tzK-0005qm-VB for nemo-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 05:27:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24057 for ; Mon, 29 Mar 2004 05:27:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tzH-00078t-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 05:27:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tyR-00071f-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 05:26:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7txw-0006tL-00 for nemo-web-archive@ietf.org; Mon, 29 Mar 2004 05:26:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7txy-0005fV-6u; Mon, 29 Mar 2004 05:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7txC-0005dB-UZ for nemo@optimus.ietf.org; Mon, 29 Mar 2004 05:25:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23924 for ; Mon, 29 Mar 2004 05:25:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tx9-0006p7-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:25:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7twB-0006hZ-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:24:11 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B7tvD-0006Uw-00 for nemo@ietf.org; Mon, 29 Mar 2004 05:23:11 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 05:22:42 -0500 Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Mon, 29 Mar 2004 05:22:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQVdSkq8TyYXMnxQNu7Jbu5lolJegAARkIA Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Ryuji Wakikawa" CC: , , X-OriginalArrivalTime: 29 Mar 2004 10:22:42.0303 (UTC) FILETIME=[C4F700F0:01C41577] Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In the case of an atomic system with 2 MRs sharing an > ingress link and > one MNP with a bunch of LFNs. Is that a problem that is > specific to Nemo > in the case where one MR dies? I mean as opposed to the same > config but > the routers are fixed? => If you constrain the config to routers that are fixed w.r.t each other then No. Our argument is basically that you can't generalise this scenario and assume that it is the case for all mobile networks IMO. Hesham ======================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by other is strictly prohibited. If you are not the inteded recipient please contact the sender and delete all copies. ======================================================== From nemo-admin@ietf.org Tue Mar 30 08:20:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17756 for ; Tue, 30 Mar 2004 08:20:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8J9v-0001Ki-78; Tue, 30 Mar 2004 08:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8J9E-0001Ft-H9 for nemo@optimus.ietf.org; Tue, 30 Mar 2004 08:19:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17729 for ; Tue, 30 Mar 2004 08:19:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8J9C-0005oL-00 for nemo@ietf.org; Tue, 30 Mar 2004 08:19:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8J8F-0005gX-00 for nemo@ietf.org; Tue, 30 Mar 2004 08:18:19 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B8J7s-0005Yl-00 for nemo@ietf.org; Tue, 30 Mar 2004 08:17:56 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4995817528; Tue, 30 Mar 2004 15:17:25 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id 754E317527; Tue, 30 Mar 2004 15:17:23 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" Cc: Subject: RE: [nemo] RE: multiple prefixes, multihoming and spliting Date: Tue, 30 Mar 2004 15:14:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [Trim the cc list] > => That's why I said I need to look into it to see > how the _HoA_ config will work. I think you've > considered the case of having multiple HoAs to provide > multihoming support for the home site. I'm talking about > switching CoAs. This is a different approach. I'm _not_ > concerned with multihoming for the _home_site_. Ok. So, the idea would be: Recycling an old figure... P::/26 ----|-------------- Home network | +---+ |HA | +---+ route | \ route to P:P1:: | \ P:P2:: | \ +---+ +---+ |MR1| |MR2| +---+ +---+ P:P1::| |P:P2:: ---------------------- Mobile network (it doesn't matter if there is only one or more HAs) So, the nemo has as many prefixes as MR and each MR registers its own prefix to the HA Only one MR can register one prefix (i.e. not two different MR can register simultaneously the same prefix) When both MR are working, LFN can use any of the two prefixes and this will determine the reverse path of the packets. Now when MR1 is no longer available (or its link is no longer available), the idea would be that MR2 registers P:P2:: on the HA so that packets are no longer forwarded to MR1 but to MR2. This would provide transparent ubiquity support while not requiring the simultaneous registration of the same prefix by different HA This would also allow that when the network splits, each MR takes its prefix with it. Is this what you are considering? > > Like I said, I'll put it all in a draft. It's hard > to explain it all on email. > > > > > > > - If MRs are connected to different access technologies > > > then we need information to be sent from those MRs to > > > MNNs to inform them about the implications of selecting > > > certain addresses. This is essentially the same problem > > > for multihomed hosts (note by multihomed I mean a host > > > with more than one interface), except that in the > > > multihomed host case this information is internal. > > > > Well, this is one step more that i was considering. I was > > mainly focusing in > > fault tolerance, you are also including policing. > > => This is not policing, it's a matter of providing > the right information for hosts to do policy-based > src address selection. well it is also policing. for instance i guess that the netwrok admin would want to ba able to stop the users from using the GPRS access when a wi fi access is available or something. I mean, especially in wireless environments, path selection may have economical impact, so the network admin probably wants to be able to influence in which link is used, don't you think? > > Policing > > can be done by > > the hosts or by the routing system. If you do host based > > policing, the path > > selection is performed by the host and there is harder to > > enforce it by the > > routing system. This would be more like the multiprefix approach. > > The single prefix approach, allows the routers to define and enforce > > policing. > > Both approaches have drawbacks and benefits, but i guess > > that allowing the > > network administrator to enforce policy is an important benefit. > > => I's impossible to do what I'm trying to do by the > administrator. It has to be done by the end host. well, let's first discuss whether this is a requirement and then we can discuss if we can do it or it is impossible Regards, marcelo From exim@www1.ietf.org Tue Mar 30 08:21:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17806 for ; Tue, 30 Mar 2004 08:21:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8JBA-0001XF-Fl for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 08:21:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UDLK64005900 for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 08:21:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8JBA-0001X5-AK for nemo-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 08:21:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17800 for ; Tue, 30 Mar 2004 08:21:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8JB9-000655-00 for nemo-web-archive@ietf.org; Tue, 30 Mar 2004 08:21:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8JAE-0005xU-00 for nemo-web-archive@ietf.org; Tue, 30 Mar 2004 08:20:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8J9y-0005pX-00 for nemo-web-archive@ietf.org; Tue, 30 Mar 2004 08:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8J9v-0001Ki-78; Tue, 30 Mar 2004 08:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8J9E-0001Ft-H9 for nemo@optimus.ietf.org; Tue, 30 Mar 2004 08:19:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17729 for ; Tue, 30 Mar 2004 08:19:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8J9C-0005oL-00 for nemo@ietf.org; Tue, 30 Mar 2004 08:19:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8J8F-0005gX-00 for nemo@ietf.org; Tue, 30 Mar 2004 08:18:19 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B8J7s-0005Yl-00 for nemo@ietf.org; Tue, 30 Mar 2004 08:17:56 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4995817528; Tue, 30 Mar 2004 15:17:25 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id 754E317527; Tue, 30 Mar 2004 15:17:23 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" Cc: Subject: RE: [nemo] RE: multiple prefixes, multihoming and spliting Date: Tue, 30 Mar 2004 15:14:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Trim the cc list] > => That's why I said I need to look into it to see > how the _HoA_ config will work. I think you've > considered the case of having multiple HoAs to provide > multihoming support for the home site. I'm talking about > switching CoAs. This is a different approach. I'm _not_ > concerned with multihoming for the _home_site_. Ok. So, the idea would be: Recycling an old figure... P::/26 ----|-------------- Home network | +---+ |HA | +---+ route | \ route to P:P1:: | \ P:P2:: | \ +---+ +---+ |MR1| |MR2| +---+ +---+ P:P1::| |P:P2:: ---------------------- Mobile network (it doesn't matter if there is only one or more HAs) So, the nemo has as many prefixes as MR and each MR registers its own prefix to the HA Only one MR can register one prefix (i.e. not two different MR can register simultaneously the same prefix) When both MR are working, LFN can use any of the two prefixes and this will determine the reverse path of the packets. Now when MR1 is no longer available (or its link is no longer available), the idea would be that MR2 registers P:P2:: on the HA so that packets are no longer forwarded to MR1 but to MR2. This would provide transparent ubiquity support while not requiring the simultaneous registration of the same prefix by different HA This would also allow that when the network splits, each MR takes its prefix with it. Is this what you are considering? > > Like I said, I'll put it all in a draft. It's hard > to explain it all on email. > > > > > > > - If MRs are connected to different access technologies > > > then we need information to be sent from those MRs to > > > MNNs to inform them about the implications of selecting > > > certain addresses. This is essentially the same problem > > > for multihomed hosts (note by multihomed I mean a host > > > with more than one interface), except that in the > > > multihomed host case this information is internal. > > > > Well, this is one step more that i was considering. I was > > mainly focusing in > > fault tolerance, you are also including policing. > > => This is not policing, it's a matter of providing > the right information for hosts to do policy-based > src address selection. well it is also policing. for instance i guess that the netwrok admin would want to ba able to stop the users from using the GPRS access when a wi fi access is available or something. I mean, especially in wireless environments, path selection may have economical impact, so the network admin probably wants to be able to influence in which link is used, don't you think? > > Policing > > can be done by > > the hosts or by the routing system. If you do host based > > policing, the path > > selection is performed by the host and there is harder to > > enforce it by the > > routing system. This would be more like the multiprefix approach. > > The single prefix approach, allows the routers to define and enforce > > policing. > > Both approaches have drawbacks and benefits, but i guess > > that allowing the > > network administrator to enforce policy is an important benefit. > > => I's impossible to do what I'm trying to do by the > administrator. It has to be done by the end host. well, let's first discuss whether this is a requirement and then we can discuss if we can do it or it is impossible Regards, marcelo From nemo-admin@ietf.org Tue Mar 30 10:47:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26205 for ; Tue, 30 Mar 2004 10:47:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LS9-0003XS-Be; Tue, 30 Mar 2004 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LRY-0003T5-EH for nemo@optimus.ietf.org; Tue, 30 Mar 2004 10:46:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26131 for ; Tue, 30 Mar 2004 10:46:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8LRW-0006Ir-00 for nemo@ietf.org; Tue, 30 Mar 2004 10:46:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8LQe-0006AM-00 for nemo@ietf.org; Tue, 30 Mar 2004 10:45:29 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8LPx-0005sD-00 for nemo@ietf.org; Tue, 30 Mar 2004 10:44:45 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 10:44:10 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] RE: multiple prefixes, multihoming and spliting Date: Tue, 30 Mar 2004 10:44:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] RE: multiple prefixes, multihoming and spliting X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQWWVor9yonHYOySD66XaaInZ76lwAEO+8A From: "Soliman Hesham" To: CC: X-OriginalArrivalTime: 30 Mar 2004 15:44:10.0725 (UTC) FILETIME=[D82C6150:01C4166D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > So, the idea would be: >=20 > Recycling an old figure... >=20 >=20 > P::/26 > ----|-------------- Home network > | > +---+ > |HA | > +---+ > route | \ route to > P:P1:: | \ P:P2:: > | \ > +---+ +---+ > |MR1| |MR2| > +---+ +---+ > P:P1::| |P:P2:: > ---------------------- Mobile network >=20 >=20 > (it doesn't matter if there is only one or more HAs) >=20 > So, the nemo has as many prefixes as MR and each MR=20 > registers its own prefix > to the HA > Only one MR can register one prefix (i.e. not two different=20 > MR can register > simultaneously the same prefix) =3D> Actually I was thinking of having both MRs register simultaneously. I think what you're saying is geared towards redundancy. While this is valid, I think that we still need to consider the case where both MRs are registered. But anyway, this is fine as an example. >=20 > When both MR are working, LFN can use any of the two=20 > prefixes and this will > determine the reverse path of the packets. >=20 > Now when MR1 is no longer available (or its link is no=20 > longer available), > the idea would be that MR2 registers P:P2:: on the HA so=20 > that packets are no > longer forwarded to MR1 but to MR2. >=20 > This would provide transparent ubiquity support while not=20 > requiring the > simultaneous registration of the same prefix by different HA >=20 > This would also allow that when the network splits, each MR=20 > takes its prefix > with it. >=20 > Is this what you are considering? =3D> Not really, but this is possible. I was considering=20 the case where both prefixes are registered simultaneously. In this scenario the LFNs will still work fine as you=20 describe. But the advantage of both being registered is that different types of access may be available to each MR. Do you see a show stopper when both are registered? I'm curious why you chose to have only one prefix registered. > > =3D> This is not policing, it's a matter of providing > > the right information for hosts to do policy-based > > src address selection. >=20 > well it is also policing. for instance i guess that the=20 > netwrok admin would > want to ba able to stop the users from using the GPRS access=20 > when a wi fi > access is available or something. I mean, especially in wireless > environments, path selection may have economical impact, so=20 > the network > admin probably wants to be able to influence in which link=20 > is used, don't > you think? =3D> There are multiple points to address here:=20 - Who is the admin in your example? The MR can be=20 administered by the the entity as the LFN/MNN. - This goes back to my earlier point about whether different=20 access link can really be used for complete redundancy.=20 In your example, this doesn't work. The ISP doesn't=20 (typically) want to run the voice traffic on a public=20 access WLAN because there are no guarantees for quality.=20 The choice of access must be done by the end host.=20 It's quite natural that the end host will choose the=20 link with better performance.=20 - There may be cases where the ISP provides Wifi access to alleviate the load on the cellular network. But I don't really think that the use of the Wifi access should/need be enforced. Incentives like=20 cost/BW are much more likely to attract users anyway. So the question is how we to provide the information to end hosts to make the decision. - At the end of the day, the ISP has no way of being sure about the characteristics/requirements of the application being used by the end host in all cases.=20 So forcing things is not really a scalable or a=20 generic way to solve the problem.=20 > > =3D> I's impossible to do what I'm trying to do by the > > administrator. It has to be done by the end host. >=20 > well, let's first discuss whether this is a requirement and=20 > then we can > discuss if we can do it or it is impossible =3D> My requirement is that hosts should be able to discover and choose the type of access. See the last=20 point above about why the end host must choose.=20 I appreciate the fact that ISPs want to influence this decision, but I don't think this should/could be done at run time in a generic manner. IMO this is best=20 done out of band (e.g. subscription).=20 Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From exim@www1.ietf.org Tue Mar 30 10:48:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26247 for ; Tue, 30 Mar 2004 10:48:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LTV-0003eC-NG for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 10:48:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UFmPGs014016 for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 10:48:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LTV-0003dz-HW for nemo-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 10:48:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26244 for ; Tue, 30 Mar 2004 10:48:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8LTT-0006a3-00 for nemo-web-archive@ietf.org; Tue, 30 Mar 2004 10:48:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8LSZ-0006Sb-00 for nemo-web-archive@ietf.org; Tue, 30 Mar 2004 10:47:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8LSD-0006Kl-00 for nemo-web-archive@ietf.org; Tue, 30 Mar 2004 10:47:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LS9-0003XS-Be; Tue, 30 Mar 2004 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LRY-0003T5-EH for nemo@optimus.ietf.org; Tue, 30 Mar 2004 10:46:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26131 for ; Tue, 30 Mar 2004 10:46:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8LRW-0006Ir-00 for nemo@ietf.org; Tue, 30 Mar 2004 10:46:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8LQe-0006AM-00 for nemo@ietf.org; Tue, 30 Mar 2004 10:45:29 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8LPx-0005sD-00 for nemo@ietf.org; Tue, 30 Mar 2004 10:44:45 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 10:44:10 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] RE: multiple prefixes, multihoming and spliting Date: Tue, 30 Mar 2004 10:44:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] RE: multiple prefixes, multihoming and spliting X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQWWVor9yonHYOySD66XaaInZ76lwAEO+8A From: "Soliman Hesham" To: CC: X-OriginalArrivalTime: 30 Mar 2004 15:44:10.0725 (UTC) FILETIME=[D82C6150:01C4166D] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > So, the idea would be: >=20 > Recycling an old figure... >=20 >=20 > P::/26 > ----|-------------- Home network > | > +---+ > |HA | > +---+ > route | \ route to > P:P1:: | \ P:P2:: > | \ > +---+ +---+ > |MR1| |MR2| > +---+ +---+ > P:P1::| |P:P2:: > ---------------------- Mobile network >=20 >=20 > (it doesn't matter if there is only one or more HAs) >=20 > So, the nemo has as many prefixes as MR and each MR=20 > registers its own prefix > to the HA > Only one MR can register one prefix (i.e. not two different=20 > MR can register > simultaneously the same prefix) =3D> Actually I was thinking of having both MRs register simultaneously. I think what you're saying is geared towards redundancy. While this is valid, I think that we still need to consider the case where both MRs are registered. But anyway, this is fine as an example. >=20 > When both MR are working, LFN can use any of the two=20 > prefixes and this will > determine the reverse path of the packets. >=20 > Now when MR1 is no longer available (or its link is no=20 > longer available), > the idea would be that MR2 registers P:P2:: on the HA so=20 > that packets are no > longer forwarded to MR1 but to MR2. >=20 > This would provide transparent ubiquity support while not=20 > requiring the > simultaneous registration of the same prefix by different HA >=20 > This would also allow that when the network splits, each MR=20 > takes its prefix > with it. >=20 > Is this what you are considering? =3D> Not really, but this is possible. I was considering=20 the case where both prefixes are registered simultaneously. In this scenario the LFNs will still work fine as you=20 describe. But the advantage of both being registered is that different types of access may be available to each MR. Do you see a show stopper when both are registered? I'm curious why you chose to have only one prefix registered. > > =3D> This is not policing, it's a matter of providing > > the right information for hosts to do policy-based > > src address selection. >=20 > well it is also policing. for instance i guess that the=20 > netwrok admin would > want to ba able to stop the users from using the GPRS access=20 > when a wi fi > access is available or something. I mean, especially in wireless > environments, path selection may have economical impact, so=20 > the network > admin probably wants to be able to influence in which link=20 > is used, don't > you think? =3D> There are multiple points to address here:=20 - Who is the admin in your example? The MR can be=20 administered by the the entity as the LFN/MNN. - This goes back to my earlier point about whether different=20 access link can really be used for complete redundancy.=20 In your example, this doesn't work. The ISP doesn't=20 (typically) want to run the voice traffic on a public=20 access WLAN because there are no guarantees for quality.=20 The choice of access must be done by the end host.=20 It's quite natural that the end host will choose the=20 link with better performance.=20 - There may be cases where the ISP provides Wifi access to alleviate the load on the cellular network. But I don't really think that the use of the Wifi access should/need be enforced. Incentives like=20 cost/BW are much more likely to attract users anyway. So the question is how we to provide the information to end hosts to make the decision. - At the end of the day, the ISP has no way of being sure about the characteristics/requirements of the application being used by the end host in all cases.=20 So forcing things is not really a scalable or a=20 generic way to solve the problem.=20 > > =3D> I's impossible to do what I'm trying to do by the > > administrator. It has to be done by the end host. >=20 > well, let's first discuss whether this is a requirement and=20 > then we can > discuss if we can do it or it is impossible =3D> My requirement is that hosts should be able to discover and choose the type of access. See the last=20 point above about why the end host must choose.=20 I appreciate the fact that ISPs want to influence this decision, but I don't think this should/could be done at run time in a generic manner. IMO this is best=20 done out of band (e.g. subscription).=20 Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From exim@www1.ietf.org Tue Mar 30 17:29:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17800 for ; Tue, 30 Mar 2004 17:29:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006Zv-J6 for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2143WKq016943 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 23:03:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxeeS-0004PB-C5 for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29433 for ; Sun, 29 Feb 2004 23:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxeeO-0001Z9-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 23:03:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxedQ-0001Td-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 23:02:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxedB-0001OK-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 23:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxedA-0004BP-9b; Sun, 29 Feb 2004 23:02:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxecO-00048z-Uu for nemo@optimus.ietf.org; Sun, 29 Feb 2004 23:01:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29371 for ; Sun, 29 Feb 2004 23:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxecL-0001MN-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:01:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxebQ-0001HO-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:00:25 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1Axeaq-0001CR-00 for nemo@ietf.org; Sun, 29 Feb 2004 22:59:48 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i213xcha024459 for ; Sun, 29 Feb 2004 19:59:39 -0800 (PST) Message-ID: <4042B535.5010003@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 19:59:49 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Subject: [nemo] a special discussion session for threat analysis and security requirements X-Priority: 2 (high) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, It seems to me that we have many folks are interested in working on security/threat related issues under NEMO, while, as TJ concluded today, we still need a good external review for security issues. In order for us to work together more effectively as a team and to consolidate different efforts, I proposed to TJ that maybe we should have a special meeting this week in Seoul to discuss about security issue. This special discussion will be open to any one who is interested in the security issue under NEMO. I propose two options for the meeting time: (1). 11-12 on Wed morning (2). 11-12 on Thu morning For those of you who are indeed interested in joining us, please let me know in emails whether any one of the propsed time is good for you. And, then, after I collect all the inputs, I will announce tomorrow around 4:00 p.m. to the NEMO mailing list. Draft Agenda: (1). Introduce ourselves (2). status of all current drafts (3). what should we really achieve regarding the security issue in NEMO? (4). "how to achieve that goal" and hopefully some action items before the next IETF. Thanks. Any comments will be welcome. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:29:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17827 for ; Tue, 30 Mar 2004 17:29:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006Zv-LP for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Ce76X011426 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 08:40:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Dbr-0002yD-HL for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 08:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11969 for ; Wed, 8 Oct 2003 08:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Dbq-0004JL-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 08:40:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Dbq-0004JI-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 08:40:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Dbo-0002w4-A6; Wed, 08 Oct 2003 08:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Dap-0002kp-Vf for nemo@optimus.ietf.org; Wed, 08 Oct 2003 08:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11914; Wed, 8 Oct 2003 08:38:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Dao-0004IM-00; Wed, 08 Oct 2003 08:39:02 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7Dam-0004I2-00; Wed, 08 Oct 2003 08:39:02 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 08 Oct 2003 05:39:24 -0700 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h98CbpZ1002121; Wed, 8 Oct 2003 05:38:27 -0700 (PDT) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Oct 2003 13:38:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [manet] NEMO or MANET? Date: Wed, 8 Oct 2003 13:38:23 +0100 Message-ID: Thread-Topic: [nemo] Re: [manet] NEMO or MANET? Thread-Index: AcONlmg/qjQ49or7QmGoUB3AqvdtUQAAbzvA From: "Pascal Thubert (pthubert)" To: "Lawrence MacIntyre" , "Wanrong Yu" Cc: , X-OriginalArrivalTime: 08 Oct 2003 12:38:24.0902 (UTC) FILETIME=[10DE4260:01C38D99] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Lawrence: I guess the question was not about the car address, but the prefix behind it. Like a MANET router with a bunch of non manet enabled nodes attached to it.=20 One way of seeing this is a lookup that resolved the "dumb" node prefix into a via manet router (this is a constant) and then resolves where the manet router is (say using a flooding). Another is to flood directly to the "dumb" node address but then the manet router has to terminate the protocol and respond itself. This is all the difference between MIP and Nemo, actually. I may be missing something but I'm not sure this is fully addressed in MANET either? Pascal=20 > -----Original Message----- > From: Lawrence MacIntyre [mailto:lpz@ornl.gov] > Sent: mercredi 8 octobre 2003 14:11 > To: Wanrong Yu > Cc: nemo@ietf.org; manet@ietf.org > Subject: [nemo] Re: [manet] NEMO or MANET? >=20 > For MANET, this is no problem at all. The Mobile Routers (cars) will > discover each other and communicate directly. There is no need for any > fixed infrastructure. >=20 > On Wed, 2003-10-08 at 05:25, Wanrong Yu wrote: > > Hi,all > > I have read some drafts of NEMO and MANET, but I > > have some doubts. If there are several mobile networks, > > each has one or more MRs(we can imagine several cars), > > these cars meet and want to communication with each > > other, if the fixed infrastructure is unsable for some > > reasons, does the communication possible? and how? > > From the aspect of NEMO, we can loose the restrict > > of the existence of fixed infrastructure, from the > > aspect of MANET, we can extend the single node in the > > ad hoc to a subnet, both will point to the scenario > > above. I think this maybe a new scenario neithor NEMO > > or MANET has covered, and there are new issues arise > > such as routing and security. > > Does there any researchs on this scenario, or some > > current technology have solve the problem perfectly? > > Any comments or advices are welcomed, thanks a lot! > > > > Wanrong Yu > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > -- > Lawrence MacIntyre 865.574.8696 lpz@ornl.gov > Oak Ridge National Laboratory > High Performance Information Infrastructure Technology Group From exim@www1.ietf.org Tue Mar 30 17:48:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20294 for ; Tue, 30 Mar 2004 17:48:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjj-0006a4-2e for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGFlK0r027326 for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 10:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHPs-00075m-0Z for nemo-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 10:47:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19745 for ; Tue, 16 Dec 2003 10:47:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHPb-0006Il-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 10:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHPZ-0006IT-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 10:47:02 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHE3-0004Jr-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 10:35:08 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWH3T-0002C3-70 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 10:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWH3J-0004Cs-6y; Tue, 16 Dec 2003 10:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWH3A-0004Bu-Vi for nemo@optimus.ietf.org; Tue, 16 Dec 2003 10:23:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16963 for ; Tue, 16 Dec 2003 10:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWH38-0003gt-01 for nemo@ietf.org; Tue, 16 Dec 2003 10:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWGoD-0003Qm-00 for nemo@ietf.org; Tue, 16 Dec 2003 10:08:27 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AWFdS-0002nl-00 for nemo@ietf.org; Tue, 16 Dec 2003 08:53:14 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBGDrAI2015532; Tue, 16 Dec 2003 14:53:10 +0100 (MET) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.75]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAJZKNL5; Tue, 16 Dec 2003 14:53:09 +0100 Message-ID: <3FDF0E36.7060606@ericsson.com> Date: Tue, 16 Dec 2003 14:52:54 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yasuhiro Ohara CC: vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> <3FDDEBAB.2010502@iprg.nokia.com> <20031216.222214.69509365.yasu@sfc.wide.ad.jp> In-Reply-To: <20031216.222214.69509365.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: >>>>if we assume the bi-directional tunnel to be a virtual link, >>>>then RFC 2740 (OSPFv3) says >>>> >>>> On virtual links, global scope or site-local IP addresses must be >>>> used as the source for OSPF protocol packets. >>>> >>> >>>Not that you are responsible for the wording of RFC 2740, but I'm >>>curious why virtual links use the exception of global addresses. In >>>IPv6, shouldn't all links be able to use link-local addresses? It is a >>>more preferred approach, as you wouldn't have to assign a global prefix >>>to that link, but instead just use link-local addresses. Point-to-point >>>links between routers should not require global addresses. >>> >>>Now in this case maybe you can use the packet design as you speficy >>>below, but are the inner packet addresses really the best choices? The >>>addresses HA and MR_HoA actually belong to another link (the physical >>>home link in case we don't have a virtual home link). >> >>I am fine with using link local addresses inside the tunnel. >>dont know why RFC 2740 says "global scope or site-local IP >>addresses must be used as the source for OSPF protocol >>packets". >> >>something that needs clarification in the OSPF WG. > > > Hi, > > Don't know about MIP (HA/CoA) thing but ... > > Virtual link does not involve packet encapsulation. > It is just an adjacency forming (routing information exchange) > between routers of multi-hop far away. OK, I see. Not quite what neither me nor Vijay envisioned. > > You can't use linklocal address as neither source nor > destination address of the packet that traverse multi-hop. > If linklocal addresses are used in those field, > routers drops (rejects) the packet according to IPv6 spec, > ... you know ;p) Seems true... So if I quote what Vijay said: >>>>if we assume the bi-directional tunnel to be a virtual link, >>>>then RFC 2740 (OSPFv3) says doesn't hold any longer, as OSPF doesn't deal with tunnels (not that I found anything about it while browsing through the spec). I don't think that a virtual link can be used just like a tunnel would. Within a tunnel I thought we could run OSPFv3 with link-local addresses and make OSPFv3 unaware of that the tunnel moves when the MR moves. But with virtual links the OSPFv3 implementation must now deal with that the MR end of the link changes its IP address. I'd prefer not to go this path; routing protocols should not have to be modified to run together with NEMO. /Mattias From exim@www1.ietf.org Tue Mar 30 17:52:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21024 for ; Tue, 30 Mar 2004 17:52:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rje-0006ZK-2f for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i228OJJH024220 for nemo-archive@odin.ietf.org; Tue, 2 Mar 2004 03:24:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5CK-0006IN-KG for nemo-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:24:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25837 for ; Tue, 2 Mar 2004 03:24:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5CI-0005kp-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 03:24:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay5BJ-0005aR-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 03:23:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5AL-0005Pp-00 for nemo-web-archive@ietf.org; Tue, 02 Mar 2004 03:22:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5AE-00065K-96; Tue, 02 Mar 2004 03:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay59e-00061Q-6r for nemo@optimus.ietf.org; Tue, 02 Mar 2004 03:21:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25746 for ; Tue, 2 Mar 2004 03:21:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay59b-0005KA-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:21:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay58n-0005CI-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:20:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1Ay587-00050j-00 for nemo@ietf.org; Tue, 02 Mar 2004 03:19:55 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2004 00:25:49 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i228Is1x014529; Tue, 2 Mar 2004 09:18:57 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Mar 2004 08:19:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] can an HA itself be an MNN under NEMO? Date: Tue, 2 Mar 2004 08:19:22 -0000 Message-ID: Thread-Topic: [nemo] can an HA itself be an MNN under NEMO? Thread-Index: AcP+og94zPqH1e96S0Gf0FTMtqf1bgBk7oTA From: "Pascal Thubert (pthubert)" To: "S. Felix Wu" , "IETF NEMO WG" Cc: "Fan Zhao" , "Souhwan Jung" X-OriginalArrivalTime: 02 Mar 2004 08:19:23.0229 (UTC) FILETIME=[119EA8D0:01C4002F] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable "Option# 1: - do NOT allow HA as MNN" * Option# 2: - An HA can be an MNN, but it can never be "included" by its own MR. - But, how about those eight cases in Multi- homing? Disagree. With nemo basic there's a limitation on how this can work as = you present and as HY Lach presented last IETF (Mobile Home must be = Root-MRs). Note that one application of Mobile Home is a 'quasi fixed' Home or = branch office gateway. Usage is preconfiguration by IT or ISP, and plug = and play deployment (and moving when office is displaced). Note: With RRH support, any configuration works (even a HA attached to = its own MRs). Reason is MR forward RRH up the tree to the AR even when = not bound (note: DHAAD is issued with a all zeroes RRH and it traverses = too). As a result, the fixed 'super' HA can answer by echoing the RRH, = then mobile Home binds, and then MRs bind via the fixed 'super' HA. Demo = available :) This is not the only advantage of RRH since it's mostly aimed at RO, but = it's pretty neat.=20 Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of S. = Felix Wu > Sent: dimanche 29 f=E9vrier 2004 08:12 > To: IETF NEMO WG > Cc: Fan Zhao; Souhwan Jung; wu@cs.ucdavis.edu > Subject: [nemo] can an HA itself be an MNN under NEMO? >=20 >=20 > Hi, >=20 > During our analysis of multi-homing and nested NEMO cases, we > have encountered a question, hopefully get some clarifications > from the NEMO working group: >=20 > -- Can an HA itself be an MNN under the NEMO context? >=20 > Please see our attached PDF file for our preliminary analysis on > this issue. It seems to us that this can be allowed for MIPv6, but > should NOT be allowed for NEMO (otherwise, we might have a loop, > and the multi-homing issue might be more complex). >=20 > -Felix > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:53:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21232 for ; Tue, 30 Mar 2004 17:53:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjf-0006YH-7G for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PEPcT7011469 for nemo-archive@odin.ietf.org; Thu, 25 Mar 2004 09:25:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vcc-0000I8-Po for nemo-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:14:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22612 for ; Thu, 25 Mar 2004 09:13:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VcJ-0006xg-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:13:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Vaf-0006fv-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:12:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZN-0006OK-00 for nemo-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZO-0007f6-CH; Thu, 25 Mar 2004 09:10:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6UOo-0001TI-G1 for nemo@optimus.ietf.org; Thu, 25 Mar 2004 07:55:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18391 for ; Thu, 25 Mar 2004 07:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6UOn-0006PX-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6UNq-0006Jn-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:54:54 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B6UMu-0006AT-00 for nemo@ietf.org; Thu, 25 Mar 2004 07:53:56 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2004 05:00:42 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PCqgss008438; Thu, 25 Mar 2004 13:52:47 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Mar 2004 12:53:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: splitting moving networks (was: DND test) Date: Thu, 25 Mar 2004 12:53:17 -0000 Message-ID: Thread-Topic: [nemo] RE: splitting moving networks (was: DND test) Thread-Index: AcQSVimLZ4pBRkhrQimdEE4kYX7kRgAEJrsw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" Cc: "Soliman Hesham" , , "IETF NEMO WG" X-OriginalArrivalTime: 25 Mar 2004 12:53:18.0373 (UTC) FILETIME=[253ADD50:01C41268] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Pascal Thubert (pthubert) wrote: > >> > I think that, first, moving networks in the NEMO sense have a rigid > >> > structure, they just don't separate components from one > >> > another, a basic > >> > definition. > >> > >>=3D> Disagree. Where is this definition made? It would be > >>a big mistake to make this assumption IMHO. How can > >>you say that a moving network will never be divided? > >>If I have a PAN with 4 devices and one day I left > >>2 at home and took 2 with me to work, you're saying > >>that this is not _meant_ to work? > >> > > > > Yes, Hesham, exactly. It's a configuration error. It should be 2 > > networks. But then, they should not share an ingress link, ever. It's > > either load balancing in an atomic (rigid) configuration or a totally > > separated configuration. What you're asking for is just too difficult > > with the current technology, and it's not just Nemo. >=20 > Pascal, I did not see any specific requirement from Hesham about how the > moving network actually splits; it's just "I leave two devices at home > and take two with me". That is not enough. If one really wants to see > how NEMO would work in this too-high-level scenario, and depict the > BU/BAck message exchanges and the tunnels, then one should be a little > bit more detailed on how the network actually splits. >=20 > I've tried to interpret more on what Hesham meant, drawed some diagrams > here that respect the split net Hesham's scenario and I think NEMO > Base Protocol works. But I'm not sure exactly what Hesham meant exactly. >=20 > So, Hesham, could you please be more explicit on exactly you see that > split moving network scenario? Where are the home agents? Does your > house host a home link? Are all devices LFN's or can they be MH's? > What moves and in what order. >=20 General Agreement here... Seems that Hesham wants a multilink subnet to work by magic. Like you, I wish to see use cases, maybe in the multihoming draft. There is a lack of crispness in all this.=20 I agree that Nemo basic support does not guarantee any multihoming scenario to work. Also that Nemo basic support voluntarily does not put in place any artifact that would prevent them in the future when the necessary technology is in place. I believe that's what it was meant to do. Pascal From exim@www1.ietf.org Tue Mar 30 18:09:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25486 for ; Tue, 30 Mar 2004 18:09:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006YH-MJ for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QF1hiF019553 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 10:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwN1D-00055F-EN for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:01:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17363 for ; Thu, 26 Feb 2004 10:01:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwN1B-0003DA-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:01:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwN0K-00036q-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:00:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzb-00030S-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzb-00047d-KS; Thu, 26 Feb 2004 10:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzG-000451-T2 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:59:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17195 for ; Thu, 26 Feb 2004 09:59:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzE-0002yJ-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:59:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMyI-0002qy-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:43 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwMxS-0002db-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:57:51 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4854F5D28A; Thu, 26 Feb 2004 23:56:21 +0900 (JST) Date: Thu, 26 Feb 2004 17:52:59 +0900 From: Thierry Ernst To: Mattias Pettersson Cc: cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040226175259.10846d05.ernst@sfc.wide.ad.jp> In-Reply-To: <403C6A63.50401@ericsson.com> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> <20040225143439.29254724.ernst@sfc.wide.ad.jp> <403C6A63.50401@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,DATE_IN_PAST_06_12 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mattias, > >>> o (N,1,N) Mobile Network > Thierry, Chan-Wah [I answer you both here], > > It is a question on what entities should carry out the dirty work. > Either the MRs or the MNNs. It's not the same dirty work. On the MR, it's about registering several prefixes, or synchronisation On the MNN, it's about source address selection. Any host is considered to implement some source address selection mechanism. Or, is there anything else dirty to do ? > To me it is important that legacy IPv6 hosts can still get connectivity > in a moving network without having to implement new proposals such as > draft-huitema-multi6-hosts-xx. > > So what is most important: to support standard IPv6 hosts or to simplify > the MR? It seems like in order to simplify the MR we are proposing to > introduce a NEMO scenario that was considered "broken" in the IPv6 WG > earlier. All routers on a link are equal, from the host's point of view! > The ND model builds on that. I agree that we have arguments both in NEMO > and in multi6 to question that model, but we do we want to change that > model just to allow a variant of a scenario? I personaly wish to support standard IPv6 hosts. But I've never heard that advertising multiple prefixes would break the model. Do you have any reference to a possible decision made by the IPv6 WG to disallow such scenario ? Any document where this is documented ? Thierry From exim@www1.ietf.org Tue Mar 30 18:14:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26929 for ; Tue, 30 Mar 2004 18:14:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006Xa-DT for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QF1hFi019518 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 10:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwN1C-00054f-Pt for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:01:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17360 for ; Thu, 26 Feb 2004 10:01:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwN1A-0003D4-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:01:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwN0K-00036g-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:00:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzb-00030R-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzZ-00046x-EA; Thu, 26 Feb 2004 10:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMz9-00044r-BK for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:59:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17189 for ; Thu, 26 Feb 2004 09:59:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMz7-0002xB-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:59:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMyB-0002pm-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:35 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwMxG-0002dV-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:57:38 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 98F385D288; Thu, 26 Feb 2004 23:56:20 +0900 (JST) Date: Thu, 26 Feb 2004 17:44:36 +0900 From: Thierry Ernst To: Mattias Pettersson Cc: nemo Subject: Re: [nemo] merged multihoming draft Message-Id: <20040226174436.2d0edbd9.ernst@sfc.wide.ad.jp> In-Reply-To: <403B4083.5080501@ericsson.com> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,DATE_IN_PAST_06_12 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > o (N,1,N) Mobile Network > > > > The (N,1,N) mobile network has multiple active egress mobile > > routers registering to the same home-agent, and advertising > > multiple prefixes. If a mobile router is advertising more than one > > prefix, we have the same problem as (1,1,N) as in how to register > > more than one NEMO-prefix to the same home-agent. > > > > On the other hand, if each mobile router take cares of a separate > > (and only one) NEMO-prefix, then there should not be any > > NEMO-specific problem. > > As I remember Erik once said to me in an earlier NEMO discussion: we > don't want to go down the second alternative. MRs should not advertise > different prefixes to the same link - they must advertise the same > prefix set (or otherwise be coordinated and able to route traffic on > behalf of each other). For an MNN, each MR is a just default router and > all default routers must be able to route all traffic. We don't want to > put such requirements on the MNNs to map each prefix to a specific exit > router and remembering to use the correct source address when sending to > a specific default router. Just one more detail: the fact that multiple prefixes are advertised on the mobile network's egreess interface doesn't preclude that multiple NEMO-prefixes will be advertised down the mobile network. So, I guess there are several interpretations of this case. The sentence starting with 'since ...' in section 2.6 should be clarified (probably adding 'may be advertised'. Not allowing to advertise multiple prefixes may be one recommendation, but then, it means we have to design a protocol to synchronize MRs. On the other hand, if we allow the advertisement of multiple NEMO-prefixes, MNNs have to select their source address. What I said is of course orthogonal with multiple NEMO-prefix registration with the HA. > Such a general host behaviour may be required for multihoming to work in > IPv6 some day, but we have not reached that point yet. Thierry From exim@www1.ietf.org Tue Mar 30 18:15:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27188 for ; Tue, 30 Mar 2004 18:15:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006WI-3L for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QF1jPH019632 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 10:01:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwN1F-00056W-Fk for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:01:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17373 for ; Thu, 26 Feb 2004 10:01:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwN1D-0003DQ-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:01:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwN0N-00037E-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:00:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzh-00030d-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:00:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzg-0004Gf-Gg; Thu, 26 Feb 2004 10:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzP-00045V-5V for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:59:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17204 for ; Thu, 26 Feb 2004 09:59:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzN-0002yo-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:59:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMyN-0002ro-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:48 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwMxZ-0002de-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:57:57 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 106455D28D; Thu, 26 Feb 2004 23:56:22 +0900 (JST) Date: Thu, 26 Feb 2004 18:00:43 +0900 From: Thierry Ernst To: Cc: mattias.l.pettersson@ericsson.com, cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040226180043.572c3fc1.ernst@sfc.wide.ad.jp> In-Reply-To: References: <403C6A63.50401@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > > It is a question on what entities should carry out the dirty work. > > Either the MRs or the MNNs. > > Perhaps in the case of multiple prefixes, the dirty work has to be carried > by the Home Network Site Exit routers? Can we be more specific with 'dirty work' ? > > To me it is important that legacy IPv6 hosts can still get connectivity > > in a moving network without having to implement new proposals such as > > draft-huitema-multi6-hosts-xx. > > Fully agree with the first statement. > But Host centric (draft-huitema-multi6-hosts) approach allows exactly this > for multihomed network. > > That is, that a regular IPv6 host is connected to the multihomed network and > still works properly. > Clearly, there some benefits, like preserving established communications > through outages, that it will not be able to obtain, but at least it will > work fine and its operation won't be disturbed because of multihoming. > > > > > So what is most important: to support standard IPv6 hosts or to simplify > > the MR? > > I fully agree that standard IPv6 have to keep on working properly. > Perhaps they won't obtain all the multihoming benefits, though > > > It seems like in order to simplify the MR we are proposing to > > introduce a NEMO scenario that was considered "broken" in the IPv6 WG > > earlier. All routers on a link are equal, from the host's point of view! > > Well, again this IMHO is generic to multihoming and not specific to nemo. > I guess that if a hosts has to be updated to obtain full multihoming > benefits in a fixed network, it would be reasonable that it also has to be > updated in order to obtain multihoming benefits in nemo. Fully agree. What is specific to NEMO WG is the ability to register several NEMO-prefixes with the HA, if we need to. Obtaining all potential benefits of multihoming is not a NEMO task. It should be carried on by another WG which doesn't focus on mobility. On the other hand, our goal is to document the issues; I suspect actions will have been taken by other WGs based on the conclusions of the NEMO Multihoming Pb Statement WG document. Thierry. From exim@www1.ietf.org Tue Mar 30 18:20:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28664 for ; Tue, 30 Mar 2004 18:20:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006WI-Qc for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QF1kBE019686 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 10:01:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwN1G-00057N-GL for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:01:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17376 for ; Thu, 26 Feb 2004 10:01:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwN1E-0003DZ-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:01:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwN0P-00037V-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:00:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzj-00030f-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzj-0004Hd-OD; Thu, 26 Feb 2004 10:00:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzR-00045j-Tq for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:59:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17213 for ; Thu, 26 Feb 2004 09:59:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzP-0002z9-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:59:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMyR-0002sW-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:52 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwMxc-0002dl-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:00 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id D88555D28E; Thu, 26 Feb 2004 23:56:22 +0900 (JST) Date: Thu, 26 Feb 2004 18:05:57 +0900 From: Thierry Ernst To: Cc: nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040226180557.37e4571d.ernst@sfc.wide.ad.jp> In-Reply-To: References: <403B4083.5080501@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I have an additional question about this draft: > > Why do you consider that a mobile network that has several prefixes is > multihomed. > I mean, i would say that a natural case for this is that the Home network is > multihomed, but not really the Mobile Network. > In this case, i guess that there is nothing NEMO specific, only that general > multi6 solutions have to be supported. > > Am i missing something? ( i haven't been around for long, so i have missed > previous discussions on this topic) Hi Marcelo, This is may be a definition issue ? I agree that taking the definition to the words may tell that any host in the Internet is multihomed since border routers usually are. I would indeed say that the MRs might be multihoming, but the MNNs might not be. I would appreciate if you could read through the multihoming section in draft-ietf-nemo-terminology and comment on the definition. That would be helpful for us. Thierry. From exim@www1.ietf.org Tue Mar 30 18:21:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29112 for ; Tue, 30 Mar 2004 18:21:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006a4-FQ for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKX4KA025348 for nemo-archive@odin.ietf.org; Wed, 19 Nov 2003 15:33:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZ0a-0006al-3v for nemo-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 15:33:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10330 for ; Wed, 19 Nov 2003 15:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ0Y-0001hF-00 for nemo-web-archive@ietf.org; Wed, 19 Nov 2003 15:33:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMZ0Y-0001hC-00 for nemo-web-archive@ietf.org; Wed, 19 Nov 2003 15:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZ0W-0006Ze-Rl; Wed, 19 Nov 2003 15:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMZ0I-0006Yt-8h for nemo@optimus.ietf.org; Wed, 19 Nov 2003 15:32:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10299 for ; Wed, 19 Nov 2003 15:32:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ0G-0001gU-00 for nemo@ietf.org; Wed, 19 Nov 2003 15:32:44 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ0G-0001gR-00 for nemo@ietf.org; Wed, 19 Nov 2003 15:32:44 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAJKWXkt026931; Wed, 19 Nov 2003 13:32:33 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAJKWXXM025043; Wed, 19 Nov 2003 14:32:34 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 91D042EC95; Wed, 19 Nov 2003 21:32:32 +0100 (CET) Message-ID: <3FBBD360.50402@motorola.com> Date: Wed, 19 Nov 2003 21:32:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: James Kempf , nemo@ietf.org Subject: Re: [nemo] Jim's comments on Basic Support References: <3FBBCCE1.6080005@iprg.nokia.com> In-Reply-To: <3FBBCCE1.6080005@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Jim, > > I have filed your comments as Issues 20 and 21 at > http://people.nokia.net/vijayd/nemo/issues.html. > >> When the Mobile Router is at home, it MAY be configured to send >> Router Advertisements and reply to Router Solicitations on the >> interface attached to the home link. The value of the Router >> Lifetime field MUST be set to zero to prevent other nodes from >> configuring the Mobile Router as the default router. >> >> jak> What happens if the Mobile Router advertises prefix A on the >> home link, then moves and advertises prefix B? This could happen if >> the Mobile Router was configured for a particular prefix on the >> home link, then received a separate prefix when it moved away. I agree there might be a problem if MR is allowed to advertise _any_ prefix (send RA's) on the visited link (be it prefix A, or a dynamically acquired prefix B from HA). I think that's why spec says MR SHOULD NOT send RA's on the visited link. What could be discussed is whether this should be a "SHOULD NOT" or a "MUST NOT". I suggest to keep it "SHOULD NOT". >> A Mobile Router SHOULD NOT send unsolicited Router Advertisements >> and SHOULD NOT reply to Router Solicitations on any egress >> interface when that interface is attached to a visited link. >> However, the Mobile Router SHOULD reply with Neighbor >> Advertisements to Neighbor Solicitations received on the egress >> interface, for topologically correct addresses. >> >> jak> What happens to hosts that are utilizing the router due to it >> having sent unsolicted RAs on the egress interface on the home >> link when the router moves away? So are you suggesting making it "MUST NOT"? >> Wouldn't it be better just to prohibit the Mobile Router from >> responding to RSs and sending unsolicited RAs on its egress >> interface? Prohibit that, maybe yes, but only when MR is away from home. I suggest to keep it as SHOULD NOT, in order to allow for an extreme case that is this: MR attaches to AR. A new MH attaches to same AR. Fade AR disappear away. At this point, if MR does not send RA's on the visited link it has no way of talking to MH. This would be a limited case, and if MR could send RA's in the ether (when AR is dead) then MH autoconfigures an address and can talk directly to MR (of course, not using their home addresses, and MH can not talk to LFN's inside the moving network). I think this is the only reason that could be a "SHOULD NOT" instead of a "MUST NOT". >> A Mobile Router MUST NOT ignore Router Advertisements received on >> the egress interface. The received Router Advertisements MAY be >> used for address configuration, default router selection or >> movement detection. >> >> jak> In fact, it MUST utilize these as described in the base MIP6 >> protocol for movement detection. What the MIPv6 spec does not observe (even if the MN terminology suggests so) is that that MN could be an MR and send RA's natively. Thinking in a MIPv6 for hosts context exclusively does not make it obvious that that MH might be able to talk to another MH, when they're both under the same AR and when that AR disappears. Alex From exim@www1.ietf.org Tue Mar 30 18:23:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29593 for ; Tue, 30 Mar 2004 18:23:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006ZK-N3 for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACM0QVI009517 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 17:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK32H-0002TF-CM for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 17:00:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12141 for ; Wed, 12 Nov 2003 17:00:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK32F-0007Ef-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 17:00:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK32E-0007Ea-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 17:00:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK31v-0002MT-Mp; Wed, 12 Nov 2003 17:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK31T-00029M-89 for nemo@optimus.ietf.org; Wed, 12 Nov 2003 16:59:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12028 for ; Wed, 12 Nov 2003 16:59:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK31Q-0007CT-00 for nemo@ietf.org; Wed, 12 Nov 2003 16:59:33 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AK31P-0007CQ-00 for nemo@ietf.org; Wed, 12 Nov 2003 16:59:32 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id hACLwKha028398; Wed, 12 Nov 2003 13:58:22 -0800 (PST) Message-ID: <3FB2ACFD.3050507@cs.ucdavis.edu> Date: Wed, 12 Nov 2003 13:58:21 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com, IETF NEMO WG Subject: Re: ICMP Tunnel error processing and reporting( was Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt) References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> <3FB1A4B4.7020306@cs.ucdavis.edu> <3FB273DE.5010206@iprg.nokia.com> In-Reply-To: <3FB273DE.5010206@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Vijay, Vijay Devarapalli wrote: > good, this is the kind of detailed threat analysis I like to see. Thanks. Yes, I agree that we should look for something more specific to the nemo itself. > I am missing something here.... > > if there is a problem with the outer header, the response goes back > to the MR. the MNN will not get the ICMP error. > > if there is a problem with the inner header, it means the Home Agent > has already stripped the outer header and some node (could be the > Home Agent also) is trying processing the inner packet. in this case, > the nodes send the ICMP error back to the MNN. the Home Agent, when it > tries to send the ICMP error back to the MNN, tunnels the error to the > MR. the MR removes the outer tunnel headers and forwards the ICMP error > alone to the MNN. the MNN will not get information about the tunnel > between the MR and the HA. according to the RFC, in some situations, the ICMP message should also be forwarded to the MNN. But, later (after I sent out my first email -- appologize for that), I also found that even under these cases (i.e., the MR needs to send/forward ICMP messages to MNN, the source of the original packet), the tunnel header information will be removed according to the same rfc. Thanks. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:25:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00046 for ; Tue, 30 Mar 2004 18:25:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006ZK-66 for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I94BKL018330 for nemo-archive@odin.ietf.org; Thu, 18 Mar 2004 04:04:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tRh-0004lQ-IQ for nemo-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 04:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28331 for ; Thu, 18 Mar 2004 04:04:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tRe-0002Mu-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 04:04:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3tQg-0002EM-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 04:03:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3tPg-00021q-00 for nemo-web-archive@ietf.org; Thu, 18 Mar 2004 04:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tPd-0004VI-PT; Thu, 18 Mar 2004 04:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tP2-0004UP-V9 for nemo@optimus.ietf.org; Thu, 18 Mar 2004 04:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28217 for ; Thu, 18 Mar 2004 04:01:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tP0-0001z2-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:01:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3tO7-0001rH-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:00:28 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3tNj-0001ic-00 for nemo@ietf.org; Thu, 18 Mar 2004 04:00:03 -0500 content-class: urn:content-classes:message Date: Thu, 18 Mar 2004 03:59:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Assigning the same prefix to multiple MRs Thread-Index: AcQMxNChCye+bQyHQ7uwn1cg3lREcAAAABTQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 > > =3D> And what happens when the test doesn't work? Which > > MR do packets get tunnelled to? > > Of course there is no such interaction defined today > > between HAs. >=20 > A type above, I meant "The idea for 'DND' is for HA2 to test the > connectivity to MR2 via MR1". > The test is done prior to accepting MR2's binding. If the=20 > test does not > work, MR2 registration fails. Like DAD. =3D> Right so MR2 and the network behind it become unreachable because MR1 is possible down! That's not good. > > =3D> How do we stop a MN from registering with 2 CoAs > > in MIPv6? The spec states that one BU overwrites > > an existing one. Simple! I see no reason why this > > spec should allow that when it's explicitly disallowed > > in MIPv6. Especially when the issue has not been sufficiently > > addressed in the spec. Of course we can address it in another > > spec (or in this one if people think it's really > > urgent), but none of this is happening now. So I think > > we got the worste of both worlds in the current spec. > >=20 > Yes and no: it works as you say if the 2 regs come to the=20 > same HA.=20 =3D> That's the only case we have now. One HoA, one CoA, one HA. But > if there are 2 HAs,=20 =3D> There is never 2 HAs visible on the IP layer. > also if the node is at home and there's a second binding for the same > Home address, the binding looses. MIPv6 is not consistent in=20 > that case =3D> Because this case does not exist in MIPv6. > Also, a Nemo prefix registration is a route updating. There can be > parallel routes, this is nothing new and actually very=20 > useful for path > redundancy.=20 =3D> Sure if parallel paths lead to the same destination. This is the whole point, they may not lead to the same destination. You're basically asking for anycast prefixes.=20 Anycast is not useful if you want to have reliable=20 communication with the same host (i.e. a reachable host). You can not compare a MIPv6 registration of a=20 > Mobile Host, > which is a nothing but a remote ND operation, with the Nemo explicit > registration of a prefix, which is a routing action. So we=20 > apply MIPv6 > thinking to the Home Address of the MR, but we apply routing=20 > thinking to > the prefix.=20 =3D> I'm saying that if you want to do that then apply it properly. At the moment it's not applied properly. It seems like this feature was not agreed on and things were left hanging in the air. I suggest that we either fix it or make it clear that it's not allowed. This happens every day with your favorite ISP. If the net > admin has configured a same prefix in 2 different places, shit > happens... =3D> I don't know what you' rereferring to here. None of this happens today. I think you have parallel redundant paths mixed up with this. They're not the same thing. ISP routers don't move while advertising a prefix which cannot be reached through them... > > =3D> Open to bugs? Without a complete solution this thing > > is a bug. I think we should either hold the spec until > > it's fixed or explicity disallow it like MIPv6. > > Either solution is fine with me. > Do you mean OSPF is a bug? OSPF by itself will not prevent a prefix > duplication. Actually some very controlled deployments use=20 > that for site > redundancy. If I remember well, the Nagano Olympics site=20 > worked that way > a few years ago, but I may be wrong on that specific one. Leave > something for deployment guys, they know their job. =3D> See my comments above. > Well, the hint was there in version 00. I was asked to=20 > remove it.=20 =3D> So it seems like it's not agreed on. In this case I'd just add something in the draft that makes it clear that you can't do that. Maybe another draft is needed to add this. Hesham From exim@www1.ietf.org Tue Mar 30 18:27:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00356 for ; Tue, 30 Mar 2004 18:27:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006a4-Lh for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HEUXx0018616 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 09:30:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3c41-0004qB-KQ for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 09:30:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07833 for ; Wed, 17 Mar 2004 09:30:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3c40-0003sU-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 09:30:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3c3G-0003mj-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 09:29:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3c2m-0003en-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 09:29:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3c2X-0004jh-Ow; Wed, 17 Mar 2004 09:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3c2B-0004jI-TJ for nemo@optimus.ietf.org; Wed, 17 Mar 2004 09:28:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07717 for ; Wed, 17 Mar 2004 09:28:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3c2A-0003c2-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:28:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3c19-0003VB-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:27:35 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3c0a-0003Nw-00 for nemo@ietf.org; Wed, 17 Mar 2004 09:27:00 -0500 content-class: urn:content-classes:message Date: Wed, 17 Mar 2004 09:26:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQMJn6/PPK0JwZ5QUeVSAP/QnpDLwAAr2mg From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "IETF NEMO WG" Content-Transfer-Encoding: quoted-printable Subject: [nemo] Assigning the same prefix to multiple MRs Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 > > =3D> That seems too handwavy for a standards track doc. What > > is the point of having the same prefix for more than one MR > > anyway? Is it a quick fix for multihoming ? I'm not sure > > that this is even true because even the MR might not always > > know if it should send a BU or not for its own prefix. > >=20 > > Perhaps this (I'm reluctant to call it feature) > > capability should be removed and only have 1 prefix per MR. >=20 > I'm not sure it's a quick fix. But it's an opening for sure.=20 > Multihoming > will have a harder time if we bar that situation blindly.=20 =3D> I think this capability is added blindly actually. I don't think we'll do much for the multihoming problem compared with potentials bugs. More on this below. > Taking the train case, I see it as a value to be able to=20 > configure the 2 > MRs with the same mobile prefix. If the configuration is controlled > properly then that's no problem. Seems nicer to me to probe=20 > for error as > opposed to forbid... =3D> How can you probe for error? This is a general=20 solution I presume and not limited for the train case. a network with more than one MR assigned the same home prefix can become unreachable if the 2 MRs are in different places. Id the two MRs are separated for whatever reason none of them will know who should register the prefix. In fact, they won't even know if they are separated.=20 So I don't think this is a good idea. At least not=20 without several cautions and very specific use cases. >=20 > Now, whether you support this configuration or not, you may want to > check for it anyway. DAD is not wanted in MIP but it's checked for.=20 =3D> DAD is wanted of course, but it needs to be faster. In any case, DAD is part of IPv6, MIP didn't add it. This is a new thing added by nemo, for what seems to be a limited gain. The least we could do is add "CAREFUL" all over it to make sure that people understand what this=20 means. Personally, I'd prefer to remove this and have it=20 studied properly as part of a multihoming scenario. >=20 > And if the check is added and finds that the situation is OK, why bar > it? =3D> I haven't seen the check you refer to so I can't tell. But independently of the check, there needs=20 to be a rigorous analysis of the impacts. For example, what happens if the check fails? which MR gets the lucky tunnel ;) what happens when an MR boots or part of the network moves away for any reason (failures or mobility) ?=20 Hesham From exim@www1.ietf.org Tue Mar 30 18:28:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00628 for ; Tue, 30 Mar 2004 18:28:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006WI-8S for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6M275n029425 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 17:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsCd-0007eW-Du for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17:02:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03808 for ; Thu, 6 Nov 2003 17:01:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsCb-0001Wt-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:02:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsCb-0001Wq-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsCY-0007dW-CM; Thu, 06 Nov 2003 17:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsCM-0007cN-JO for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:01:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03792 for ; Thu, 6 Nov 2003 17:01:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsCK-0001WG-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:01:48 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AHsCJ-0001WD-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:01:47 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA6M1hSr001696 for ; Thu, 6 Nov 2003 15:01:45 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA6M1IBJ019583 for ; Thu, 6 Nov 2003 16:01:21 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 17ED92EC95 for ; Thu, 6 Nov 2003 23:01:19 +0100 (CET) Message-ID: <3FAAC4AE.5060602@motorola.com> Date: Thu, 06 Nov 2003 23:01:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi to authors of draft-thubert-nemo-basic-usages-00.txt I think the words "Examples of basic nemo usages" in the title are claiming more than the draft actually describes. The draft mainly describes the architecture of the home network, or NEMO is about the home network _and_ the mobile network. I would suggest a better title to say "Examples of home networks for NEMO". > Home Link: The link attached to the interface at the Home Agent on > which the Home Prefix is configured. The interface can be a virtual > interface, in which case the Home Link is a virtual Home Link. ...and in which case there is no need for Proxy ND (an essential feature of MIPv6), or there is a need for a Virtual Proxy ND, to be figured out. > With Mobile IPv6, the Home Network is generally a physical network > interconnecting the Home Agents, It would sound better IMHO to say that a MIPv6 Home Network is a physical _link_ (instead of a physical network). Network sounds to me like yes being physical, but having routers connecting links, or the MIPv6 home network linking the HA's together has no routers in between. Finally, I think that the draft misses an important opportunity to first describe a simple MIPv6 home network that accomodates NEMO mobile networks (implicit and explicit network modes), which is the following: | route v /48 HA | /52 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN /56 /56 /56 /56 In this home network the prefixes are aggregated. If one wonders how can a link be assigned a shorter-than-64 prefix and still have the stateless autoconfiguration work then one needs to consider that the length of the prefixlen advertised by RA on that link is not necessarily the prefix len in the routing tables of routers pointing to that link. In other words, HA's rt entry towards MR1 would be len 56 but MR1 would send RA's with prefix len 64 inside on its first link such that its first-level LFN's could configure IPv6 addresses with their Ethernet-like cards. Note that RFC2462 does not relate the prefix lens in the RA to the prefix lens existing in routing tables. That doc acknowledges that most people use EUI-64 and asks that: > It is the responsibility of the system administrator to insure that > the lengths of prefixes contained in Router Advertisements are > consistent with the length of interface identifiers for that link > type. So, I would suggest to add a simple description of this simple home network and say what are its problems. Alex GBU From exim@www1.ietf.org Tue Mar 30 18:28:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00848 for ; Tue, 30 Mar 2004 18:28:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006WI-9N for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QA7XU7032043 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 05:07:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIQU-0008K5-Jv for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 05:07:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01962 for ; Thu, 26 Feb 2004 05:07:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIQR-0001w4-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 05:07:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIPX-0001rW-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 05:06:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwIP7-0001mk-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 05:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIP3-000807-B8; Thu, 26 Feb 2004 05:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIOT-0007yV-4D for nemo@optimus.ietf.org; Thu, 26 Feb 2004 05:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01896 for ; Thu, 26 Feb 2004 05:05:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIOP-0001ku-00 for nemo@ietf.org; Thu, 26 Feb 2004 05:05:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwINV-0001hA-00 for nemo@ietf.org; Thu, 26 Feb 2004 05:04:26 -0500 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1AwIN1-0001aW-00 for nemo@ietf.org; Thu, 26 Feb 2004 05:03:55 -0500 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 1AwIMU-00027t-00; Thu, 26 Feb 2004 21:03:22 +1100 Date: Thu, 26 Feb 2004 21:03:21 +1100 (EST) From: Eranga Perera To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano cc: nemo@ietf.org Subject: Re: [nemo] Visiting Nodes In-Reply-To: <1077784218.790.15.camel@acorde> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Carlos, Thanks for the reply. By visiting I mean nodes which belong to another network as opposed to local nodes. If we agree that there could be nodes that are not MIPv6 capable and also belongs to another network then shouldn't we witihn the NEMO group give emphasis to such nodes too. I believe that there is alot to do in order to enable mobility for such nodes in a NEMO setting. What do you think? Regrds, Eranga On Thu, 26 Feb 2004, Carlos [ISO-8859-1] Jes=FAs Bernardos Cano wrote: > Hi Eranga, > > =09All MNNs (Mobile Network Nodes) move with the mobile network, but not > all of them are "mobile nodes" (i.e. have MIPv6 support and can move > topologically with respect to the MR). Local Fixed Nodes (LFNs) are > nodes that belong to the mobile network and which do not move with > respect to the MR (like the node you pointed in your example). In the > other hand, there are nodes with mobility capabilities: Visiting Mobile > Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term "visiting" > is not very clear and could lead to confusion, but IMHO it does not mean > that other nodes-with no mobility capabilities-could not visit a mobile > network (i.e. a node with portability-DHCPv6 support). > > =09Best regards, > > =09Carlos J. > > El jue, 26-02-2004 a las 07:01, Eranga Perera escribi=F3: > > Hi All, > > Would someone be able to clarify why is it that all visiting nodes to a > > mobile network are assumed to be mobile nodes? > > More precisely how about the nodes that belong to another network (not > > mobile network) but has no mobility capabilities? > > (scenario - commuter with a PDA with no mobility capabilities obtain > > connectivity via a MR deployed on a bus) > > > > Thankx in advance, > > Eranga > -- > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF > From exim@www1.ietf.org Tue Mar 30 18:30:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01178 for ; Tue, 30 Mar 2004 18:30:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjL-0006WI-5I for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69pJ6t012220 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 04:51:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgnL-0003Aj-W5 for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 04:51:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01999 for ; Thu, 6 Nov 2003 04:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgnG-00067c-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 04:51:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHgnG-00067Z-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 04:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgmD-000341-7l; Thu, 06 Nov 2003 04:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgj9-0002QR-KP for nemo@optimus.ietf.org; Thu, 06 Nov 2003 04:46:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01746 for ; Thu, 6 Nov 2003 04:46:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgj0-00061P-00 for nemo@ietf.org; Thu, 06 Nov 2003 04:46:46 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AHgiz-00060Y-00 for nemo@ietf.org; Thu, 06 Nov 2003 04:46:45 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id hA69k5Ou009454; Thu, 6 Nov 2003 18:46:05 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id hA69k7L05646; Thu, 6 Nov 2003 18:46:07 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/astros2) with ESMTP id hA69k7S23280; Thu, 6 Nov 2003 18:46:07 +0900 (JST) Received: from STRATOS ([10.96.152.147]) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id hA69k32t032659; Thu, 6 Nov 2003 18:46:04 +0900 (JST) Message-Id: <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> Date: Thu, 06 Nov 2003 09:46:25 +0000 From: MATSUMOTO Taisuke Subject: Re: [nemo] Behavior of HA To: "Vijay Devarapalli" Cc: nemo@ietf.org Organization: Matsushita Electric Industrial Co., Ltd. In-Reply-To: <3FA95896.7010002@iprg.nokia.com> References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Vijay, Thank you for your response. > > So, I think that some schemes to avoid that restriction of the > > mobile IPv6 specifications is required for the NEMO basic support. > > yes. the mobile IPv6 restriction needs to be relaxed. currently > section 10.3.1 of MIPv6 says > > if the home address for the binding (the Home Address field > in the packet's Home Address option) is not an on-link IPv6 > address with respect to the home agent's current Prefix List, then > the home agent MUST reject the Binding Update and SHOULD return a > Binding Acknowledgement to the mobile node, in which the Status > field is set to 132 (not home subnet). > > for Nemo, the Home Agent should not reject the Binding if the > home address is from a prefix that has been delegated to a > Mobile Router. > > comments? I think that your comment is reasonabie. But I have another question how to know if the prefix is delegated to the mobile router. If it should be pre-configured in the home agent, it makes the explicit prefix length mode lose an advantage to the implicit mode. Am I misunderstanding anything? Taisuke From exim@www1.ietf.org Tue Mar 30 18:32:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01686 for ; Tue, 30 Mar 2004 18:32:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjI-0006a4-Eu for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HASgcH028871 for nemo-archive@odin.ietf.org; Wed, 17 Mar 2004 05:28:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3YHn-0007VV-P6 for nemo-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 05:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29158 for ; Wed, 17 Mar 2004 05:28:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3YHk-0006c7-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 05:28:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3YH0-0006Ut-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 05:27:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3YGR-0006NR-00 for nemo-web-archive@ietf.org; Wed, 17 Mar 2004 05:27:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3YGL-0007HI-80; Wed, 17 Mar 2004 05:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3YFn-0007Fk-4K for nemo@optimus.ietf.org; Wed, 17 Mar 2004 05:26:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29076 for ; Wed, 17 Mar 2004 05:26:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3YFj-0006K8-00 for nemo@ietf.org; Wed, 17 Mar 2004 05:26:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3YEl-0006DE-00 for nemo@ietf.org; Wed, 17 Mar 2004 05:25:23 -0500 Received: from ipoutme5.wanadoo.fr ([193.252.22.21] helo=mwinf1002.wanadoo.fr) by ietf-mx with esmtp (Exim 4.12) id 1B3YDq-00060z-00 for nemo@ietf.org; Wed, 17 Mar 2004 05:24:26 -0500 Received: from wwinf1001 (wwinf1001 [172.22.141.28]) by mwinf1002.wanadoo.fr (SMTP Server) with ESMTP id 8CC061C00117 for ; Wed, 17 Mar 2004 11:23:55 +0100 (CET) Message-ID: <4225881.1079519035562.JavaMail.www@wwinf1001> From: Ines BEN HAMIDA Reply-To: ines.ben-hamida@wanadoo.fr To: nemo@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Date: Wed, 17 Mar 2004 11:23:55 +0100 (CET) Content-Transfer-Encoding: 7bit Subject: [nemo] resource reservation for NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I'm interested by resource reservation for NEMO (how an MR can reserve badwidth in wireless network for all the mobile network). For me, since the MR does the reservation for all the MNN behind it, there is no difference between NEMO and a mobile host in resource reservation. Can some one give me any help or any useful documentation about this subject? thank you Ines From exim@www1.ietf.org Tue Mar 30 18:32:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01796 for ; Tue, 30 Mar 2004 18:32:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006WI-SF for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i259PqkW028759 for nemo-archive@odin.ietf.org; Fri, 5 Mar 2004 04:25:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBaZ-0007SF-Un for nemo-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 04:25:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27722 for ; Fri, 5 Mar 2004 04:25:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzBaI-0001Be-00 for nemo-web-archive@ietf.org; Fri, 05 Mar 2004 04:25:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzBZC-0000y9-00 for nemo-web-archive@ietf.org; Fri, 05 Mar 2004 04:24:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzBYu-0000ms-00 for nemo-web-archive@ietf.org; Fri, 05 Mar 2004 04:24:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBYp-00070e-Qm; Fri, 05 Mar 2004 04:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzASJ-0000Id-0z for nemo@optimus.ietf.org; Fri, 05 Mar 2004 03:13:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25292 for ; Fri, 5 Mar 2004 03:13:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzASG-0002BM-00 for nemo@ietf.org; Fri, 05 Mar 2004 03:13:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzARI-00020U-00 for nemo@ietf.org; Fri, 05 Mar 2004 03:12:12 -0500 Received: from [147.6.42.146] (helo=filter2.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AzAQH-0001gN-00 for nemo@ietf.org; Fri, 05 Mar 2004 03:11:09 -0500 Received: from external ([147.6.24.123]) by filter2 (1.0) id i2589qL09214; Fri, 05 Mar 2004 17:09:52 +0900 Message-ID: <008601c40289$545099c0$7b180693@yjtcha> From: "Yongjoo Tcha" To: Date: Fri, 5 Mar 2004 17:10:32 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01C402D4.C43386D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [nemo] Posting to nemo mailing list Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0083_01C402D4.C43386D0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSB3YW50IHRvIHBvc3QgdG8gbWFpbGluZyBsaXN0Lg0KSSBhbHJlYWR5IHN1YnNjcmliZWQgdG8g bWlwNCBXRy4NCg0KY29uZmlybSA0NjE2NDQNClRoYW5rIHlvdS4= ------=_NextPart_000_0083_01C402D4.C43386D0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTQwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48 Rk9OVCBzaXplPTI+SSB3YW50IHRvIHBvc3QgdG8gbWFpbGluZyBsaXN0LjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPkkgYWxyZWFkeSBzdWJzY3JpYmVkIHRvIG1pcDQgV0cuPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5jb25m aXJtIDQ2MTY0NDwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmsgeW91LjwvRk9OVD48L0RJ Vj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0083_01C402D4.C43386D0-- From exim@www1.ietf.org Tue Mar 30 18:48:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05821 for ; Tue, 30 Mar 2004 18:48:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj0-0006WI-MO for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPH58SK002404 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 12:05:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgcd-0000cW-Vj for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:05:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27317 for ; Tue, 25 Nov 2003 12:04:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgcc-00017f-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 12:05:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgcc-00017c-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 12:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgcY-0000ad-D1; Tue, 25 Nov 2003 12:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgbp-0000RU-JY for nemo@optimus.ietf.org; Tue, 25 Nov 2003 12:04:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27254 for ; Tue, 25 Nov 2003 12:04:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgbo-000172-00 for nemo@ietf.org; Tue, 25 Nov 2003 12:04:16 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOgbn-00016y-00 for nemo@ietf.org; Tue, 25 Nov 2003 12:04:15 -0500 Message-ID: <00dd01c3b375$fe05e2d0$956015ac@dclkempt40> From: "James Kempf" To: "Pascal Thubert \(pthubert\)" , "Alexis Olivereau" Cc: References: Subject: Re: [nemo] RE: Explicit Prefix Length Option Date: Tue, 25 Nov 2003 09:03:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascall, I think what Alexis is trying to get at is the following. Suppose there are two mobile routers, both having IPsec SAs with the HA. One has IP address A and the other has IP address B. Router A is allowed to route prefix set X and router B is allowed to route prefix set Y. What prevents router A from sending a BU with Prefix Option having the prefixes in set Y, thereby hijacking B's traffic? This is the point I was trying to get at about service provider deployment security (sorry if I was a bit cryptic). jak ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Alexis Olivereau" Cc: Sent: Tuesday, November 25, 2003 3:41 AM Subject: RE: [nemo] RE: Explicit Prefix Length Option > > > > -----Original Message----- > > From: Alexis Olivereau [mailto:Alexis@motorola.com] > > Sent: mardi 25 novembre 2003 12:29 > > To: Pascal Thubert (pthubert) > > Cc: nemo@ietf.org > > Subject: Re: [nemo] RE: Explicit Prefix Length Option > > > > > Pascal Thubert (pthubert) wrote: > > > This is what I was trying to say. Keep the MIPv6 model, and > > > implicitly extend that authorization to a given prefix length around > > > the static home address. You can configure that HA to accept the > > > registration for a prefix around the home address, provided that the > > > MR has proven its identity (the MIPv6 way), and with a minimum > > > configured prefix length. The explicit prefix extends the implicit > > > authorization in MIPv6. > > > > > > This is what I was trying to say. Keep the MIPv6 model, and > > > implicitly extend that authorization to a given prefix length around > > > the static home address. > > > > I am not sure I understand what you are proposing here. Do you mean > that > > a Mobile Router would be able to claim the ownership of any prefix > above > > a certain length, provided that the prefix is based on its home > address? > > Then I could imagine cases where two Mobile Routers could legitimately > > claim the ownership of the same prefix... Or we need to add more > > constraints on how the MRs' home addresses are assigned. > > This is entering the multihomeing discussion. In that case, yes, that > would be possible. > We do not have a test to check that multiple registration of a given MNP > lead to a unique mobile link. With basic, we assume that the > configuration is correct and that the authorization checks that there is > no abuse. > > Pascal > > > From exim@www1.ietf.org Tue Mar 30 18:56:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08045 for ; Tue, 30 Mar 2004 18:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006Yx-4d for nemo-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF4n9J002181 for nemo-archive@odin.ietf.org; Wed, 18 Feb 2004 10:04:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTFp-0000Z6-Hp for nemo-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:04:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16892 for ; Wed, 18 Feb 2004 10:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTFn-00068j-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 10:04:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTEf-0005vl-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 10:03:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtTCz-0005cN-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 10:01:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCH-00066h-4a; Wed, 18 Feb 2004 10:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTC7-0005zq-Oi for nemo@optimus.ietf.org; Wed, 18 Feb 2004 10:00:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15972; Wed, 18 Feb 2004 10:00:56 -0500 (EST) Message-Id: <200402181500.KAA15972@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 10:00:55 -0500 Subject: [nemo] I-D ACTION:draft-ietf-nemo-requirements-02.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Goals and Requirements Author(s) : T. Ernst Filename : draft-ietf-nemo-requirements-02.txt Pages : 13 Date : 2004-2-18 Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. The required support mechanisms will be provided in two phases. The first phase, referred to as NEMO Basic Support is to provide session continuity while the necessary optimizations mechanims referred to as NEMO Extended Support might be provided later. This document outlines the goals expected from network mobility support and defines the requirements that must be met by NEMO Basic Support solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18101420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101420.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Wed Mar 31 01:07:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01323 for ; Wed, 31 Mar 2004 01:07:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YsP-0005ws-7h; Wed, 31 Mar 2004 01:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YrX-0005ua-Kc for nemo@optimus.ietf.org; Wed, 31 Mar 2004 01:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01293 for ; Wed, 31 Mar 2004 01:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8YrU-0001Xa-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:06:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Yqb-0001TT-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:05:09 -0500 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 1B8Ypk-0001Oo-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:04:17 -0500 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By note With Smtp ; Wed, 31 Mar 2004 16:04:15 +1000 From: "Muhammad Ali Malik" To: "Nemo@Ietf. Org" Date: Wed, 31 Mar 2004 16:04:10 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010E_01C41739.CD866C10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Subject: [nemo] Layer 3 handoff Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_010E_01C41739.CD866C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Consider a situation when mobile network is deployed in bus or train. How many Layer 3 handoff is possible when connected to same subscriber using 3G technology. Because if there is no layer 3 handoff when connected to same subscriber, there will be no use of nemo or mobile IPv6 for the moving network. Thanxx and regards, Muhammad ------=_NextPart_000_010E_01C41739.CD866C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Consider a situation when mobile network is deployed in bus or = train. How many Layer 3 handoff is possible when connected to same subscriber using = 3G technology. Because if there is no layer 3 handoff when connected to = same subscriber, there will be no use of nemo or mobile IPv6 for the moving = network.

 

Thanxx and regards,

 

Muhammad

------=_NextPart_000_010E_01C41739.CD866C10-- From exim@www1.ietf.org Wed Mar 31 01:09:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01451 for ; Wed, 31 Mar 2004 01:09:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YuN-0006NZ-Ja for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 01:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V693wI024521 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 01:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YuN-0006NQ-EO for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 01:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01421 for ; Wed, 31 Mar 2004 01:09:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8YuK-0001nV-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 01:09:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8YtL-0001i6-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 01:08:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8YsO-0001cA-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 01:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YsP-0005ws-7h; Wed, 31 Mar 2004 01:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YrX-0005ua-Kc for nemo@optimus.ietf.org; Wed, 31 Mar 2004 01:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01293 for ; Wed, 31 Mar 2004 01:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8YrU-0001Xa-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:06:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Yqb-0001TT-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:05:09 -0500 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 1B8Ypk-0001Oo-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:04:17 -0500 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By note With Smtp ; Wed, 31 Mar 2004 16:04:15 +1000 From: "Muhammad Ali Malik" To: "Nemo@Ietf. Org" Date: Wed, 31 Mar 2004 16:04:10 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010E_01C41739.CD866C10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: [nemo] Layer 3 handoff Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_010E_01C41739.CD866C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Consider a situation when mobile network is deployed in bus or train. How many Layer 3 handoff is possible when connected to same subscriber using 3G technology. Because if there is no layer 3 handoff when connected to same subscriber, there will be no use of nemo or mobile IPv6 for the moving network. Thanxx and regards, Muhammad ------=_NextPart_000_010E_01C41739.CD866C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Consider a situation when mobile network is deployed in bus or = train. How many Layer 3 handoff is possible when connected to same subscriber using = 3G technology. Because if there is no layer 3 handoff when connected to = same subscriber, there will be no use of nemo or mobile IPv6 for the moving = network.

 

Thanxx and regards,

 

Muhammad

------=_NextPart_000_010E_01C41739.CD866C10-- From nemo-admin@ietf.org Wed Mar 31 01:32:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02557 for ; Wed, 31 Mar 2004 01:32:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ZGa-0007qS-P5; Wed, 31 Mar 2004 01:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ZFm-0007pW-HH for nemo@optimus.ietf.org; Wed, 31 Mar 2004 01:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02506 for ; Wed, 31 Mar 2004 01:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZFj-0003mP-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:31:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ZEn-0003hf-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:30:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8ZE7-0003an-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:29:27 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 01:28:46 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] Layer 3 handoff Date: Wed, 31 Mar 2004 01:28:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Layer 3 handoff X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQW5mhz2VHJYWwKT5Sari2uMS3AzwAAWxrg From: "Soliman Hesham" To: "Muhammad Ali Malik" , "Nemo@Ietf. Org" X-OriginalArrivalTime: 31 Mar 2004 06:28:46.0911 (UTC) FILETIME=[6C0BA4F0:01C416E9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable =20 >Consider a situation when mobile network is deployed in bus or train. = How many Layer 3=20 >handoff is possible when connected to same subscriber using 3G = technology. Because if=20 >there is no layer 3 handoff when connected to same subscriber, there = will be no use of=20 >nemo or mobile IPv6 for the moving network. =20 =3D> Correct. There is no L3 handoff in this scenario. OTOH, if there is another access available (connected to a different AR) there can be an L3 handoff.=20 Hesham =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From exim@www1.ietf.org Wed Mar 31 01:34:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02669 for ; Wed, 31 Mar 2004 01:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ZIV-0007yC-1G for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 01:33:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V6XxLs030636 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 01:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ZIU-0007y3-Tf for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 01:33:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02618 for ; Wed, 31 Mar 2004 01:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZIR-00042O-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 01:33:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ZHk-0003xS-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 01:33:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZGa-0003r3-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 01:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ZGa-0007qS-P5; Wed, 31 Mar 2004 01:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ZFm-0007pW-HH for nemo@optimus.ietf.org; Wed, 31 Mar 2004 01:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02506 for ; Wed, 31 Mar 2004 01:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZFj-0003mP-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:31:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ZEn-0003hf-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:30:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8ZE7-0003an-00 for nemo@ietf.org; Wed, 31 Mar 2004 01:29:27 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 01:28:46 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] Layer 3 handoff Date: Wed, 31 Mar 2004 01:28:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] Layer 3 handoff X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQW5mhz2VHJYWwKT5Sari2uMS3AzwAAWxrg From: "Soliman Hesham" To: "Muhammad Ali Malik" , "Nemo@Ietf. Org" X-OriginalArrivalTime: 31 Mar 2004 06:28:46.0911 (UTC) FILETIME=[6C0BA4F0:01C416E9] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 >Consider a situation when mobile network is deployed in bus or train. = How many Layer 3=20 >handoff is possible when connected to same subscriber using 3G = technology. Because if=20 >there is no layer 3 handoff when connected to same subscriber, there = will be no use of=20 >nemo or mobile IPv6 for the moving network. =20 =3D> Correct. There is no L3 handoff in this scenario. OTOH, if there is another access available (connected to a different AR) there can be an L3 handoff.=20 Hesham =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From nemo-admin@ietf.org Wed Mar 31 10:22:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28293 for ; Wed, 31 Mar 2004 10:22:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8hWZ-0001lh-T7; Wed, 31 Mar 2004 10:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8hVu-0001bc-Sv for nemo@optimus.ietf.org; Wed, 31 Mar 2004 10:20:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28022 for ; Wed, 31 Mar 2004 10:20:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8hVs-0006Ft-00 for nemo@ietf.org; Wed, 31 Mar 2004 10:20:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8hV2-00069I-00 for nemo@ietf.org; Wed, 31 Mar 2004 10:19:29 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B8hUD-0005vS-00 for nemo@ietf.org; Wed, 31 Mar 2004 10:18:37 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 45A8A15FE2; Wed, 31 Mar 2004 17:18:06 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id E6A4B16DAF; Wed, 31 Mar 2004 17:17:50 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" Cc: Subject: RE: [nemo] RE: multiple prefixes, multihoming and spliting Date: Wed, 31 Mar 2004 12:15:03 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > => Not really, but this is possible. I was considering > the case where both prefixes are registered simultaneously. > In this scenario the LFNs will still work fine as you > describe. But the advantage of both being registered > is that different types of access may be available > to each MR. Do you see a show stopper when both are > registered? I'm curious why you chose to have only > one prefix registered. I was considering that each router has only one access technology. So selecting the router is equivalent to select the technology. I guess you are considering a more general case, where MR has multiple technologies. Let me see if i understand the motivations for having multiple prefixes: You can bind one prefix with one technology, with one link or with one MR. I am not really sure which is better. I guess that if you bind one prefix with one technology, you have a simple mechanisms to let the host to select the technology that fits the needs of its traffic and all of this per application (or even per packet) since it the selection is contained in the source address used. You can bind a prefix to a link, so that even if you have multiple links of the same technology, you can provide some support for fault tolerance by selecting the link available through the selection of the source prefix. You can bind a prefix to a MR, so that if the nemo splits, each MR takes it prefix with it. Now, depending on which of these goals you are designing for, it makes more or less sense to register the same prefix by different MRs, i guess. > > > > => This is not policing, it's a matter of providing > > > the right information for hosts to do policy-based > > > src address selection. > > > > well it is also policing. for instance i guess that the > > netwrok admin would > > want to ba able to stop the users from using the GPRS access > > when a wi fi > > access is available or something. I mean, especially in wireless > > environments, path selection may have economical impact, so > > the network > > admin probably wants to be able to influence in which link > > is used, don't > > you think? > > => There are multiple points to address here: > > - Who is the admin in your example? The MR can be > administered by the the entity as the LFN/MNN. I usually consider that there is a network admin, that configures and manages MRs and links, and then there are users, who can configure its LFN at will. So, if the network admin wishes a specific usage of the network recourses like links, it may not be able to trust the LFN to do what is specified. For instance, a policy like "use the expensive link only to carry real time traffic and not for ftp" may makes sense for the network admin but the user may think otherwise. So, it is probably good to allow the network admin to enforce some of its policies. > > - This goes back to my earlier point about whether different > access link can really be used for complete redundancy. > In your example, this doesn't work. The ISP doesn't > (typically) want to run the voice traffic on a public > access WLAN because there are no guarantees for quality. Ok, i see your point. I usually define fault tolerance as sending the packets through the available path as long one exists. Your definition seems to be more demanding, like use the link available that matches the QoS required. > The choice of access must be done by the end host. > It's quite natural that the end host will choose the > link with better performance. Yes but this may be conflicting with network admin preferences. I guess we have a tradeoff here, between empowering the users vs. empowering the network admin. I also think that different scenarios will require different parts to be empowered. I guess that there will be a need for different approaches. the other option would be to try to find a solution that provides tools to both of them to perform path selection, and we should decide who overrules who. But i am not sure such solution exists. > > - There may be cases where the ISP provides Wifi > access to alleviate the load on the cellular network. > But I don't really think that the use of the Wifi > access should/need be enforced. Incentives like > cost/BW are much more likely to attract users anyway. > So the question is how we to provide the information > to end hosts to make the decision. Well, if you bind a prefix with a technology, the selection of the source address performed by the host may inform the routing system which technology it is willing to use to carry the packet. Then what you need is a mechanism to influence the source address selection policy RFC 3484 policy table may be a starting point. You probably need to extend it, in order to have more granularity, perhaps the port numbers. You will also need a mechanisms to automatically configure this policy table, like a dhcp option ( i prefer it to Radv based mechanism) > > - At the end of the day, the ISP has no way > of being sure about the characteristics/requirements > of the application being used by the end host in all cases. > So forcing things is not really a scalable or a > generic way to solve the problem. In a world where users behave according to the common good, this is fine. In a world with greedy users, this may not work so well, i am afraid. So, again, i guess the solution depends on the environment. > > > > => I's impossible to do what I'm trying to do by the > > > administrator. It has to be done by the end host. > > > > well, let's first discuss whether this is a requirement and > > then we can > > discuss if we can do it or it is impossible > > => My requirement is that hosts should be able to > discover and choose the type of access. See the last > point above about why the end host must choose. I agree with this requirement > I appreciate the fact that ISPs want to influence this > decision, but I don't think this should/could be done > at run time in a generic manner. IMO this is best > done out of band (e.g. subscription). I am not talking about the ISP here but about the administrator of the nemo. regards, marcelo > > Hesham > > > ======================================================== > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review or distribution by others is > strictly prohibited. If you are not the intended recipient please contact > the sender and delete all copies. > ======================================================== > > From exim@www1.ietf.org Wed Mar 31 10:24:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28431 for ; Wed, 31 Mar 2004 10:24:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8hZO-0002lS-CH for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 10:23:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VFNwJK010626 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 10:23:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8hZN-0002lJ-St for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 10:23:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28397 for ; Wed, 31 Mar 2004 10:23:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8hZL-0006UC-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 10:23:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8hYM-0006Pj-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 10:22:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8hXU-0006NI-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 10:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8hWZ-0001lh-T7; Wed, 31 Mar 2004 10:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8hVu-0001bc-Sv for nemo@optimus.ietf.org; Wed, 31 Mar 2004 10:20:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28022 for ; Wed, 31 Mar 2004 10:20:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8hVs-0006Ft-00 for nemo@ietf.org; Wed, 31 Mar 2004 10:20:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8hV2-00069I-00 for nemo@ietf.org; Wed, 31 Mar 2004 10:19:29 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1B8hUD-0005vS-00 for nemo@ietf.org; Wed, 31 Mar 2004 10:18:37 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 45A8A15FE2; Wed, 31 Mar 2004 17:18:06 +0200 (CEST) Received: from lolo (vpn-252-208.uc3m.es [163.117.252.208]) by smtp02.uc3m.es (Postfix) with SMTP id E6A4B16DAF; Wed, 31 Mar 2004 17:17:50 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Soliman Hesham" Cc: Subject: RE: [nemo] RE: multiple prefixes, multihoming and spliting Date: Wed, 31 Mar 2004 12:15:03 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > => Not really, but this is possible. I was considering > the case where both prefixes are registered simultaneously. > In this scenario the LFNs will still work fine as you > describe. But the advantage of both being registered > is that different types of access may be available > to each MR. Do you see a show stopper when both are > registered? I'm curious why you chose to have only > one prefix registered. I was considering that each router has only one access technology. So selecting the router is equivalent to select the technology. I guess you are considering a more general case, where MR has multiple technologies. Let me see if i understand the motivations for having multiple prefixes: You can bind one prefix with one technology, with one link or with one MR. I am not really sure which is better. I guess that if you bind one prefix with one technology, you have a simple mechanisms to let the host to select the technology that fits the needs of its traffic and all of this per application (or even per packet) since it the selection is contained in the source address used. You can bind a prefix to a link, so that even if you have multiple links of the same technology, you can provide some support for fault tolerance by selecting the link available through the selection of the source prefix. You can bind a prefix to a MR, so that if the nemo splits, each MR takes it prefix with it. Now, depending on which of these goals you are designing for, it makes more or less sense to register the same prefix by different MRs, i guess. > > > > => This is not policing, it's a matter of providing > > > the right information for hosts to do policy-based > > > src address selection. > > > > well it is also policing. for instance i guess that the > > netwrok admin would > > want to ba able to stop the users from using the GPRS access > > when a wi fi > > access is available or something. I mean, especially in wireless > > environments, path selection may have economical impact, so > > the network > > admin probably wants to be able to influence in which link > > is used, don't > > you think? > > => There are multiple points to address here: > > - Who is the admin in your example? The MR can be > administered by the the entity as the LFN/MNN. I usually consider that there is a network admin, that configures and manages MRs and links, and then there are users, who can configure its LFN at will. So, if the network admin wishes a specific usage of the network recourses like links, it may not be able to trust the LFN to do what is specified. For instance, a policy like "use the expensive link only to carry real time traffic and not for ftp" may makes sense for the network admin but the user may think otherwise. So, it is probably good to allow the network admin to enforce some of its policies. > > - This goes back to my earlier point about whether different > access link can really be used for complete redundancy. > In your example, this doesn't work. The ISP doesn't > (typically) want to run the voice traffic on a public > access WLAN because there are no guarantees for quality. Ok, i see your point. I usually define fault tolerance as sending the packets through the available path as long one exists. Your definition seems to be more demanding, like use the link available that matches the QoS required. > The choice of access must be done by the end host. > It's quite natural that the end host will choose the > link with better performance. Yes but this may be conflicting with network admin preferences. I guess we have a tradeoff here, between empowering the users vs. empowering the network admin. I also think that different scenarios will require different parts to be empowered. I guess that there will be a need for different approaches. the other option would be to try to find a solution that provides tools to both of them to perform path selection, and we should decide who overrules who. But i am not sure such solution exists. > > - There may be cases where the ISP provides Wifi > access to alleviate the load on the cellular network. > But I don't really think that the use of the Wifi > access should/need be enforced. Incentives like > cost/BW are much more likely to attract users anyway. > So the question is how we to provide the information > to end hosts to make the decision. Well, if you bind a prefix with a technology, the selection of the source address performed by the host may inform the routing system which technology it is willing to use to carry the packet. Then what you need is a mechanism to influence the source address selection policy RFC 3484 policy table may be a starting point. You probably need to extend it, in order to have more granularity, perhaps the port numbers. You will also need a mechanisms to automatically configure this policy table, like a dhcp option ( i prefer it to Radv based mechanism) > > - At the end of the day, the ISP has no way > of being sure about the characteristics/requirements > of the application being used by the end host in all cases. > So forcing things is not really a scalable or a > generic way to solve the problem. In a world where users behave according to the common good, this is fine. In a world with greedy users, this may not work so well, i am afraid. So, again, i guess the solution depends on the environment. > > > > => I's impossible to do what I'm trying to do by the > > > administrator. It has to be done by the end host. > > > > well, let's first discuss whether this is a requirement and > > then we can > > discuss if we can do it or it is impossible > > => My requirement is that hosts should be able to > discover and choose the type of access. See the last > point above about why the end host must choose. I agree with this requirement > I appreciate the fact that ISPs want to influence this > decision, but I don't think this should/could be done > at run time in a generic manner. IMO this is best > done out of band (e.g. subscription). I am not talking about the ISP here but about the administrator of the nemo. regards, marcelo > > Hesham > > > ======================================================== > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review or distribution by others is > strictly prohibited. If you are not the intended recipient please contact > the sender and delete all copies. > ======================================================== > > From nemo-admin@ietf.org Wed Mar 31 11:32:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01020 for ; Wed, 31 Mar 2004 11:32:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8idF-0007iR-BF; Wed, 31 Mar 2004 11:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8icO-0007dm-BK for nemo@optimus.ietf.org; Wed, 31 Mar 2004 11:31:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00974 for ; Wed, 31 Mar 2004 11:30:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8icD-0002Xn-00 for nemo@ietf.org; Wed, 31 Mar 2004 11:30:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ibM-0002Ti-00 for nemo@ietf.org; Wed, 31 Mar 2004 11:30:05 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8iak-0002Oh-00 for nemo@ietf.org; Wed, 31 Mar 2004 11:29:26 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 11:28:52 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] RE: multiple prefixes, multihoming and spliting Date: Wed, 31 Mar 2004 11:28:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] RE: multiple prefixes, multihoming and spliting X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQXM18qf8HOSX7HSOu8UGBJ6gE5owAAj4fQ From: "Soliman Hesham" To: CC: X-OriginalArrivalTime: 31 Mar 2004 16:28:52.0555 (UTC) FILETIME=[4114E9B0:01C4173D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > =3D> Not really, but this is possible. I was considering > > the case where both prefixes are registered simultaneously. > > In this scenario the LFNs will still work fine as you > > describe. But the advantage of both being registered > > is that different types of access may be available > > to each MR. Do you see a show stopper when both are > > registered? I'm curious why you chose to have only > > one prefix registered. >=20 > I was considering that each router has only one access technology. So > selecting the router is equivalent to select the technology.=20 > I guess you are > considering a more general case, where MR has multiple technologies. =3D> No. I want to allow the MNNs to use the available=20 technologies effieciently. That's why simultaneous registrations make sense. In other words, if each MR is connected to=20 a different technology then nodes should be able to use either access simultaneously.=20 >=20 > Let me see if i understand the motivations for having=20 > multiple prefixes: > You can bind one prefix with one technology, with one link=20 > or with one MR. I > am not really sure which is better. I guess that if you bind=20 > one prefix with > one technology, you have a simple mechanisms to let the host=20 > to select the > technology that fits the needs of its traffic and all of this per > application (or even per packet) since it the selection is=20 > contained in the > source address used. =3D> Not per packet. Per application is ok. But I'm not binding a prefix to an access technology. The prefix belongs to the MR, whichever access type it has is what it uses.=20 > You can bind a prefix to a link, so that even if you have=20 > multiple links of > the same technology, you can provide some support for fault=20 > tolerance by > selecting the link available through the selection of the=20 > source prefix. =3D> See above. I'm not binding anything to access technology. > You can bind a prefix to a MR, so that if the nemo splits,=20 > each MR takes it > prefix with it. =3D> That's it! >=20 > Now, depending on which of these goals you are designing=20 > for, it makes more > or less sense to register the same prefix by different MRs, i guess. =3D> It's the last one above. > > =3D> There are multiple points to address here: > > > > - Who is the admin in your example? The MR can be > > administered by the the entity as the LFN/MNN. >=20 > I usually consider that there is a network admin, that configures and > manages MRs and links, and then there are users, who can=20 > configure its LFN > at will.=20 =3D> We're very far apart here. I don't make assumptions like these. The MR could be your mobile phone, laptop, PDA ...etc. There is no point in assuming that these devices are not administered by the end user. So, if the network admin wishes a specific usage of=20 > the network > recourses like links, it may not be able to trust the LFN to=20 > do what is > specified. For instance, a policy like "use the expensive=20 > link only to carry > real time traffic and not for ftp" may makes sense for the=20 > network admin but > the user may think otherwise.=20 =3D> Hmmm. I wonder why the user would think otherwise. So, it is probably good to=20 > allow the network > admin to enforce some of its policies. =3D> Again, the network admin is the user in many cases. > > - This goes back to my earlier point about whether different > > access link can really be used for complete redundancy. > > In your example, this doesn't work. The ISP doesn't > > (typically) want to run the voice traffic on a public > > access WLAN because there are no guarantees for quality. >=20 > Ok, i see your point. > I usually define fault tolerance as sending the packets through the > available path as long one exists. > Your definition seems to be more demanding, like use the=20 > link available that > matches the QoS required. =3D> I'm not defining fault tolerance though. I'm trying to point out that different access technologies can be used efficiently by different applications. I'm not limiting multihoming to redundancy. > > The choice of access must be done by the end host. > > It's quite natural that the end host will choose the > > link with better performance. >=20 > Yes but this may be conflicting with network admin preferences. > I guess we have a tradeoff here, between empowering the=20 > users vs. empowering > the network admin. > I also think that different scenarios will require different=20 > parts to be > empowered. =3D> Sure, the question is how? It's not clear that=20 protocol work is needed here. I think that out of band mechanisms are sufficient to setup the necessary static information like cost. The rest is up to the user. If a user decides to ignore a WLAN and ftp a 10M file=20 on a cellular link and pay for it, then that's fine. > I guess that there will be a need for different approaches. > the other option would be to try to find a solution that=20 > provides tools to > both of them to perform path selection, and we should decide=20 > who overrules > who. =3D> The user overrules. > > - There may be cases where the ISP provides Wifi > > access to alleviate the load on the cellular network. > > But I don't really think that the use of the Wifi > > access should/need be enforced. Incentives like > > cost/BW are much more likely to attract users anyway. > > So the question is how we to provide the information > > to end hosts to make the decision. >=20 > Well, if you bind a prefix with a technology, the selection=20 > of the source > address performed by the host may inform the routing system=20 > which technology > it is willing to use to carry the packet. > Then what you need is a mechanism to influence the source=20 > address selection > policy > RFC 3484 policy table may be a starting point. > You probably need to extend it, in order to have more=20 > granularity, perhaps > the port numbers. > You will also need a mechanisms to automatically configure=20 > this policy > table, like a dhcp option ( i prefer it to Radv based mechanism) =3D> Yes, something along those lines. RFC 3484 is very simplistic though for these types of scenarios. But I'm not too concerned about this part because every implementation can select the src address in its own way. I'm more concerned (in IETF) about the way of communicating=20 the information about the link behind the MR. > > - At the end of the day, the ISP has no way > > of being sure about the characteristics/requirements > > of the application being used by the end host in all cases. > > So forcing things is not really a scalable or a > > generic way to solve the problem. >=20 > In a world where users behave according to the common good,=20 > this is fine. > In a world with greedy users, this may not work so well, i am afraid. =3D> The user will always behave for his own good. Trying to overrule that will not work in a deregulated world.=20 Basically what I'm trying to say is that you need not be afraid because ISPs want the user to use the cheap link for cheap apps and the expensive link for QoS.=20 And why wouldn't the user want that if it's cheaper for her? I don't see a problem. Are you worried that=20 a user might want to use an expensive access despite=20 the presence of a cheap one for the same app?? Doesn't=20 make sense. Or the reverse: use a cheap access that doesn't support QoS for an app that requires QoS? Well if it works poorly and they're happy with that, it's ok! > > I appreciate the fact that ISPs want to influence this > > decision, but I don't think this should/could be done > > at run time in a generic manner. IMO this is best > > done out of band (e.g. subscription). >=20 > I am not talking about the ISP here but about the=20 > administrator of the nemo. =3D> The nemo may well be administered by the user of the MNNs. If not, then it's an ISP, what else=20 could it be? Hesham=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From exim@www1.ietf.org Wed Mar 31 11:34:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01084 for ; Wed, 31 Mar 2004 11:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8if6-00083Q-Mk for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 11:33:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VGXuOX030961 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 11:33:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8if5-00083I-RO for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 11:33:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01076 for ; Wed, 31 Mar 2004 11:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8if4-0002fk-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 11:33:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ieC-0002e5-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 11:33:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8idI-0002cJ-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 11:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8idF-0007iR-BF; Wed, 31 Mar 2004 11:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8icO-0007dm-BK for nemo@optimus.ietf.org; Wed, 31 Mar 2004 11:31:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00974 for ; Wed, 31 Mar 2004 11:30:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8icD-0002Xn-00 for nemo@ietf.org; Wed, 31 Mar 2004 11:30:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ibM-0002Ti-00 for nemo@ietf.org; Wed, 31 Mar 2004 11:30:05 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8iak-0002Oh-00 for nemo@ietf.org; Wed, 31 Mar 2004 11:29:26 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 11:28:52 -0500 Content-Class: urn:content-classes:message Subject: RE: [nemo] RE: multiple prefixes, multihoming and spliting Date: Wed, 31 Mar 2004 11:28:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [nemo] RE: multiple prefixes, multihoming and spliting X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQXM18qf8HOSX7HSOu8UGBJ6gE5owAAj4fQ From: "Soliman Hesham" To: CC: X-OriginalArrivalTime: 31 Mar 2004 16:28:52.0555 (UTC) FILETIME=[4114E9B0:01C4173D] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> Not really, but this is possible. I was considering > > the case where both prefixes are registered simultaneously. > > In this scenario the LFNs will still work fine as you > > describe. But the advantage of both being registered > > is that different types of access may be available > > to each MR. Do you see a show stopper when both are > > registered? I'm curious why you chose to have only > > one prefix registered. >=20 > I was considering that each router has only one access technology. So > selecting the router is equivalent to select the technology.=20 > I guess you are > considering a more general case, where MR has multiple technologies. =3D> No. I want to allow the MNNs to use the available=20 technologies effieciently. That's why simultaneous registrations make sense. In other words, if each MR is connected to=20 a different technology then nodes should be able to use either access simultaneously.=20 >=20 > Let me see if i understand the motivations for having=20 > multiple prefixes: > You can bind one prefix with one technology, with one link=20 > or with one MR. I > am not really sure which is better. I guess that if you bind=20 > one prefix with > one technology, you have a simple mechanisms to let the host=20 > to select the > technology that fits the needs of its traffic and all of this per > application (or even per packet) since it the selection is=20 > contained in the > source address used. =3D> Not per packet. Per application is ok. But I'm not binding a prefix to an access technology. The prefix belongs to the MR, whichever access type it has is what it uses.=20 > You can bind a prefix to a link, so that even if you have=20 > multiple links of > the same technology, you can provide some support for fault=20 > tolerance by > selecting the link available through the selection of the=20 > source prefix. =3D> See above. I'm not binding anything to access technology. > You can bind a prefix to a MR, so that if the nemo splits,=20 > each MR takes it > prefix with it. =3D> That's it! >=20 > Now, depending on which of these goals you are designing=20 > for, it makes more > or less sense to register the same prefix by different MRs, i guess. =3D> It's the last one above. > > =3D> There are multiple points to address here: > > > > - Who is the admin in your example? The MR can be > > administered by the the entity as the LFN/MNN. >=20 > I usually consider that there is a network admin, that configures and > manages MRs and links, and then there are users, who can=20 > configure its LFN > at will.=20 =3D> We're very far apart here. I don't make assumptions like these. The MR could be your mobile phone, laptop, PDA ...etc. There is no point in assuming that these devices are not administered by the end user. So, if the network admin wishes a specific usage of=20 > the network > recourses like links, it may not be able to trust the LFN to=20 > do what is > specified. For instance, a policy like "use the expensive=20 > link only to carry > real time traffic and not for ftp" may makes sense for the=20 > network admin but > the user may think otherwise.=20 =3D> Hmmm. I wonder why the user would think otherwise. So, it is probably good to=20 > allow the network > admin to enforce some of its policies. =3D> Again, the network admin is the user in many cases. > > - This goes back to my earlier point about whether different > > access link can really be used for complete redundancy. > > In your example, this doesn't work. The ISP doesn't > > (typically) want to run the voice traffic on a public > > access WLAN because there are no guarantees for quality. >=20 > Ok, i see your point. > I usually define fault tolerance as sending the packets through the > available path as long one exists. > Your definition seems to be more demanding, like use the=20 > link available that > matches the QoS required. =3D> I'm not defining fault tolerance though. I'm trying to point out that different access technologies can be used efficiently by different applications. I'm not limiting multihoming to redundancy. > > The choice of access must be done by the end host. > > It's quite natural that the end host will choose the > > link with better performance. >=20 > Yes but this may be conflicting with network admin preferences. > I guess we have a tradeoff here, between empowering the=20 > users vs. empowering > the network admin. > I also think that different scenarios will require different=20 > parts to be > empowered. =3D> Sure, the question is how? It's not clear that=20 protocol work is needed here. I think that out of band mechanisms are sufficient to setup the necessary static information like cost. The rest is up to the user. If a user decides to ignore a WLAN and ftp a 10M file=20 on a cellular link and pay for it, then that's fine. > I guess that there will be a need for different approaches. > the other option would be to try to find a solution that=20 > provides tools to > both of them to perform path selection, and we should decide=20 > who overrules > who. =3D> The user overrules. > > - There may be cases where the ISP provides Wifi > > access to alleviate the load on the cellular network. > > But I don't really think that the use of the Wifi > > access should/need be enforced. Incentives like > > cost/BW are much more likely to attract users anyway. > > So the question is how we to provide the information > > to end hosts to make the decision. >=20 > Well, if you bind a prefix with a technology, the selection=20 > of the source > address performed by the host may inform the routing system=20 > which technology > it is willing to use to carry the packet. > Then what you need is a mechanism to influence the source=20 > address selection > policy > RFC 3484 policy table may be a starting point. > You probably need to extend it, in order to have more=20 > granularity, perhaps > the port numbers. > You will also need a mechanisms to automatically configure=20 > this policy > table, like a dhcp option ( i prefer it to Radv based mechanism) =3D> Yes, something along those lines. RFC 3484 is very simplistic though for these types of scenarios. But I'm not too concerned about this part because every implementation can select the src address in its own way. I'm more concerned (in IETF) about the way of communicating=20 the information about the link behind the MR. > > - At the end of the day, the ISP has no way > > of being sure about the characteristics/requirements > > of the application being used by the end host in all cases. > > So forcing things is not really a scalable or a > > generic way to solve the problem. >=20 > In a world where users behave according to the common good,=20 > this is fine. > In a world with greedy users, this may not work so well, i am afraid. =3D> The user will always behave for his own good. Trying to overrule that will not work in a deregulated world.=20 Basically what I'm trying to say is that you need not be afraid because ISPs want the user to use the cheap link for cheap apps and the expensive link for QoS.=20 And why wouldn't the user want that if it's cheaper for her? I don't see a problem. Are you worried that=20 a user might want to use an expensive access despite=20 the presence of a cheap one for the same app?? Doesn't=20 make sense. Or the reverse: use a cheap access that doesn't support QoS for an app that requires QoS? Well if it works poorly and they're happy with that, it's ok! > > I appreciate the fact that ISPs want to influence this > > decision, but I don't think this should/could be done > > at run time in a generic manner. IMO this is best > > done out of band (e.g. subscription). >=20 > I am not talking about the ISP here but about the=20 > administrator of the nemo. =3D> The nemo may well be administered by the user of the MNNs. If not, then it's an ISP, what else=20 could it be? Hesham=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From nemo-admin@ietf.org Wed Mar 31 14:16:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08036 for ; Wed, 31 Mar 2004 14:16:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8lBx-0004Ft-9x; Wed, 31 Mar 2004 14:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8lBG-0004Et-FQ for nemo@optimus.ietf.org; Wed, 31 Mar 2004 14:15:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07998 for ; Wed, 31 Mar 2004 14:15:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8lBD-0004d7-00 for nemo@ietf.org; Wed, 31 Mar 2004 14:15:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8lAF-0004Zz-00 for nemo@ietf.org; Wed, 31 Mar 2004 14:14:15 -0500 Received: from [192.103.16.30] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1B8l9m-0004VL-00 for nemo@ietf.org; Wed, 31 Mar 2004 14:13:46 -0500 Received: from [192.103.17.194] ([192.103.17.194]) by multihop.net (8.12.11/8.12.10) with ESMTP id i2VJC4WP087764 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 31 Mar 2004 11:12:04 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <3BB6BDCE-8347-11D8-B9E0-000A95DA08F2@kniveton.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF NEMO WG From: "T.J. Kniveton" Date: Wed, 31 Mar 2004 11:11:37 -0800 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] IESG Review of Basic Support draft Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please note that the IESG has reviewed the NEMO Basic Support draft. Their comments are on the data tracker web site: https://datatracker.ietf.org/public/pidtracker.cgi? command=print_ballot&ballot_id=1225&filename=draft-ietf-nemo-basic- support It looks like there is a good overall opinion of the draft. Vijay is looking into the comments and figuring out how to handle any needed changes. TJ From exim@www1.ietf.org Wed Mar 31 14:17:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08067 for ; Wed, 31 Mar 2004 14:17:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8lDP-0004Ux-57 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 14:17:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VJHVRF017287 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 14:17:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8lDM-0004Uk-3H for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 14:17:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08059 for ; Wed, 31 Mar 2004 14:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8lD9-0004h6-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 14:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8lCE-0004fi-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 14:16:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8lC2-0004e2-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 14:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8lBx-0004Ft-9x; Wed, 31 Mar 2004 14:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8lBG-0004Et-FQ for nemo@optimus.ietf.org; Wed, 31 Mar 2004 14:15:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07998 for ; Wed, 31 Mar 2004 14:15:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8lBD-0004d7-00 for nemo@ietf.org; Wed, 31 Mar 2004 14:15:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8lAF-0004Zz-00 for nemo@ietf.org; Wed, 31 Mar 2004 14:14:15 -0500 Received: from [192.103.16.30] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1B8l9m-0004VL-00 for nemo@ietf.org; Wed, 31 Mar 2004 14:13:46 -0500 Received: from [192.103.17.194] ([192.103.17.194]) by multihop.net (8.12.11/8.12.10) with ESMTP id i2VJC4WP087764 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 31 Mar 2004 11:12:04 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <3BB6BDCE-8347-11D8-B9E0-000A95DA08F2@kniveton.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF NEMO WG From: "T.J. Kniveton" Date: Wed, 31 Mar 2004 11:11:37 -0800 X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [nemo] IESG Review of Basic Support draft Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please note that the IESG has reviewed the NEMO Basic Support draft. Their comments are on the data tracker web site: https://datatracker.ietf.org/public/pidtracker.cgi? command=print_ballot&ballot_id=1225&filename=draft-ietf-nemo-basic- support It looks like there is a good overall opinion of the draft. Vijay is looking into the comments and figuring out how to handle any needed changes. TJ From nemo-admin@ietf.org Wed Mar 31 19:05:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21654 for ; Wed, 31 Mar 2004 19:05:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8phg-0003Sx-Mv; Wed, 31 Mar 2004 19:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8phQ-0003Rq-9V for nemo@optimus.ietf.org; Wed, 31 Mar 2004 19:04:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21648 for ; Wed, 31 Mar 2004 19:04:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8phM-00045e-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:04:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8pgT-00043W-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:03:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B8pfw-00040b-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:03:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3102j207330; Wed, 31 Mar 2004 16:02:45 -0800 X-mProtect: <200404010002> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgVYweS; Wed, 31 Mar 2004 16:02:43 PST Message-ID: <406B5F89.1020503@iprg.nokia.com> Date: Wed, 31 Mar 2004 16:17:13 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org, H.Soliman@flarion.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, Alexandru.Petrescu@motorola.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] summary of same MNP to mutliple MRs discussion Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit it took me a while to go through the entire thread. I am not sure what the problem is. the problem kept shifting. :) here is a summary (from what I understood). first of all, the current spec prevents assigning the same MNP to two mobile routers _if required_. it depends on what is configured in the Prefix Table on the Home Agent. if the Prefix Table on the Home Agent says that a particular MNP was given out only to MR1, the Home Agent sends a binding ack with status 142 to MR2 when MR2 sends a BU to the Home Agent. if the Prefx Table says both MR1 and MR2 are authorized for a MNP, then it _is_ possible for both MR1 and MR2 to register with the Home Agent with the same MNP at the same time. the HA then has two routes to the MNP, one route pointing to MR1 and the second pointing to MR2. this is what Hesham is talking about. the current NEMO basic support spec works in this case. if the Mobile Network splits, with MR1 in one network and MR2 in another network, both advertising the same MNP and both registered with the Home Agent, then there is a problem. Hesham wants this stated in the spec. the Home Agent could pick the wrong route. then again, others have argued that if you expect two mobile routers which were part of the same Mobile Network (but not nested, both have uplinks) to move away and split the mobile network into two, it is stupid to assign the same MNP to both. each MR should be delegated a unique MNP. on top of everything we dont have a clear definition of what it means when two Mobile Networks merge or split. (we are _not_ talking about nesting here). this is almost MANET space. did I miss something? Vijay ps: I created an issue for this. issue 37 at http://people.nokia.net/vijayd/nemo/issues.html From exim@www1.ietf.org Wed Mar 31 19:07:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21705 for ; Wed, 31 Mar 2004 19:07:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8pjK-0003e0-Su for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 19:06:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3106kjd013925 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 19:06:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8pjI-0003cT-Vx for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 19:06:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21697 for ; Wed, 31 Mar 2004 19:06:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8pjF-0004BQ-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 19:06:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8piI-00049m-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 19:05:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8phm-000469-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 19:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8phg-0003Sx-Mv; Wed, 31 Mar 2004 19:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8phQ-0003Rq-9V for nemo@optimus.ietf.org; Wed, 31 Mar 2004 19:04:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21648 for ; Wed, 31 Mar 2004 19:04:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8phM-00045e-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:04:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8pgT-00043W-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:03:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B8pfw-00040b-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:03:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3102j207330; Wed, 31 Mar 2004 16:02:45 -0800 X-mProtect: <200404010002> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgVYweS; Wed, 31 Mar 2004 16:02:43 PST Message-ID: <406B5F89.1020503@iprg.nokia.com> Date: Wed, 31 Mar 2004 16:17:13 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org, H.Soliman@flarion.com, pthubert@cisco.com, mbagnulo@ing.uc3m.es, Alexandru.Petrescu@motorola.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] summary of same MNP to mutliple MRs discussion Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit it took me a while to go through the entire thread. I am not sure what the problem is. the problem kept shifting. :) here is a summary (from what I understood). first of all, the current spec prevents assigning the same MNP to two mobile routers _if required_. it depends on what is configured in the Prefix Table on the Home Agent. if the Prefix Table on the Home Agent says that a particular MNP was given out only to MR1, the Home Agent sends a binding ack with status 142 to MR2 when MR2 sends a BU to the Home Agent. if the Prefx Table says both MR1 and MR2 are authorized for a MNP, then it _is_ possible for both MR1 and MR2 to register with the Home Agent with the same MNP at the same time. the HA then has two routes to the MNP, one route pointing to MR1 and the second pointing to MR2. this is what Hesham is talking about. the current NEMO basic support spec works in this case. if the Mobile Network splits, with MR1 in one network and MR2 in another network, both advertising the same MNP and both registered with the Home Agent, then there is a problem. Hesham wants this stated in the spec. the Home Agent could pick the wrong route. then again, others have argued that if you expect two mobile routers which were part of the same Mobile Network (but not nested, both have uplinks) to move away and split the mobile network into two, it is stupid to assign the same MNP to both. each MR should be delegated a unique MNP. on top of everything we dont have a clear definition of what it means when two Mobile Networks merge or split. (we are _not_ talking about nesting here). this is almost MANET space. did I miss something? Vijay ps: I created an issue for this. issue 37 at http://people.nokia.net/vijayd/nemo/issues.html From nemo-admin@ietf.org Wed Mar 31 19:59:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23751 for ; Wed, 31 Mar 2004 19:59:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qXs-0000aB-Ow; Wed, 31 Mar 2004 19:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qXe-0000Za-JE for nemo@optimus.ietf.org; Wed, 31 Mar 2004 19:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23711 for ; Wed, 31 Mar 2004 19:58:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8qXc-0007Fm-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8qWg-0007CC-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:57:46 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8qVm-00076f-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:56:50 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 19:56:14 -0500 Content-Class: urn:content-classes:message Date: Wed, 31 Mar 2004 19:56:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Topic: summary of same MNP to mutliple MRs discussion Thread-Index: AcQXfMIVZYcsVOYZTO2BbTNYdoZg9gABenFw From: "Soliman Hesham" To: "Vijay Devarapalli" , , , , X-OriginalArrivalTime: 01 Apr 2004 00:56:14.0339 (UTC) FILETIME=[21CC8530:01C41784] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: summary of same MNP to mutliple MRs discussion Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Vijay,=20 Thanks for the summary. see below. > first of all, the current spec prevents assigning the > same MNP to two mobile routers _if required_.=20 =3D> typo? you mean "does not prevent"? it depends > on what is configured in the Prefix Table on the Home > Agent. if the Prefix Table on the Home Agent says that > a particular MNP was given out only to MR1, the Home > Agent sends a binding ack with status 142 to MR2 when > MR2 sends a BU to the Home Agent. >=20 > if the Prefx Table says both MR1 and MR2 are authorized > for a MNP, then it _is_ possible for both MR1 and MR2 > to register with the Home Agent with the same MNP at > the same time. the HA then has two routes to the MNP, > one route pointing to MR1 and the second pointing to MR2. > this is what Hesham is talking about. the current NEMO > basic support spec works in this case. >=20 > if the Mobile Network splits, with MR1 in one network > and MR2 in another network, both advertising the same > MNP and both registered with the Home Agent, then there > is a problem. Hesham wants this stated in the spec. the > Home Agent could pick the wrong route. =3D> Yes. >=20 > then again, others have argued that if you expect two > mobile routers which were part of the same Mobile > Network (but not nested, both have uplinks) to move > away and split the mobile network into two, it is > stupid to assign the same MNP to both. each MR should > be delegated a unique MNP. =3D> That opinion should be stated in the spec. > did I miss something? >=20 =3D> This is a good and specific summary.=20 Hesham > Vijay >=20 > ps: I created an issue for this. issue 37 at > http://people.nokia.net/vijayd/nemo/issues.html >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From exim@www1.ietf.org Wed Mar 31 20:01:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23857 for ; Wed, 31 Mar 2004 20:01:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qZe-0000jz-Te for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 20:00:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3110o4X002847 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 20:00:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qZe-0000jq-L5 for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 20:00:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23850 for ; Wed, 31 Mar 2004 20:00:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8qZc-0007QH-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 20:00:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8qYl-0007LQ-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 19:59:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8qXw-0007Ht-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 19:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qXs-0000aB-Ow; Wed, 31 Mar 2004 19:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qXe-0000Za-JE for nemo@optimus.ietf.org; Wed, 31 Mar 2004 19:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23711 for ; Wed, 31 Mar 2004 19:58:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8qXc-0007Fm-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8qWg-0007CC-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:57:46 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8qVm-00076f-00 for nemo@ietf.org; Wed, 31 Mar 2004 19:56:50 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 19:56:14 -0500 Content-Class: urn:content-classes:message Date: Wed, 31 Mar 2004 19:56:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Topic: summary of same MNP to mutliple MRs discussion Thread-Index: AcQXfMIVZYcsVOYZTO2BbTNYdoZg9gABenFw From: "Soliman Hesham" To: "Vijay Devarapalli" , , , , X-OriginalArrivalTime: 01 Apr 2004 00:56:14.0339 (UTC) FILETIME=[21CC8530:01C41784] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: summary of same MNP to mutliple MRs discussion Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Vijay,=20 Thanks for the summary. see below. > first of all, the current spec prevents assigning the > same MNP to two mobile routers _if required_.=20 =3D> typo? you mean "does not prevent"? it depends > on what is configured in the Prefix Table on the Home > Agent. if the Prefix Table on the Home Agent says that > a particular MNP was given out only to MR1, the Home > Agent sends a binding ack with status 142 to MR2 when > MR2 sends a BU to the Home Agent. >=20 > if the Prefx Table says both MR1 and MR2 are authorized > for a MNP, then it _is_ possible for both MR1 and MR2 > to register with the Home Agent with the same MNP at > the same time. the HA then has two routes to the MNP, > one route pointing to MR1 and the second pointing to MR2. > this is what Hesham is talking about. the current NEMO > basic support spec works in this case. >=20 > if the Mobile Network splits, with MR1 in one network > and MR2 in another network, both advertising the same > MNP and both registered with the Home Agent, then there > is a problem. Hesham wants this stated in the spec. the > Home Agent could pick the wrong route. =3D> Yes. >=20 > then again, others have argued that if you expect two > mobile routers which were part of the same Mobile > Network (but not nested, both have uplinks) to move > away and split the mobile network into two, it is > stupid to assign the same MNP to both. each MR should > be delegated a unique MNP. =3D> That opinion should be stated in the spec. > did I miss something? >=20 =3D> This is a good and specific summary.=20 Hesham > Vijay >=20 > ps: I created an issue for this. issue 37 at > http://people.nokia.net/vijayd/nemo/issues.html >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From nemo-admin@ietf.org Wed Mar 31 20:13:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24313 for ; Wed, 31 Mar 2004 20:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qlQ-0002f3-TO; Wed, 31 Mar 2004 20:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qlE-0002eF-8Q for nemo@optimus.ietf.org; Wed, 31 Mar 2004 20:12:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24284 for ; Wed, 31 Mar 2004 20:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8qlC-0000KB-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8qkI-0000Gu-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:11:50 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B8qjM-00008E-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:10:52 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i311AHw08016; Wed, 31 Mar 2004 17:10:17 -0800 X-mProtect: <200404010110> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQmtfJ9; Wed, 31 Mar 2004 17:10:15 PST Message-ID: <406B6F5D.1060501@iprg.nokia.com> Date: Wed, 31 Mar 2004 17:24:45 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: nemo@ietf.org, pthubert@cisco.com, mbagnulo@ing.uc3m.es, Alexandru.Petrescu@motorola.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Re: summary of same MNP to mutliple MRs discussion Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > Vijay, > > Thanks for the summary. see below. > > > first of all, the current spec prevents assigning the > > same MNP to two mobile routers _if required_. > > => typo? you mean "does not prevent"? > no. based on information in the Prefix Table, the Home Agent can prevent more than one MR claiming the same MNP. or to put it more accurately, detect this and prevent the second MR from registering (and creating routes). see section 6.1.2. if the Prefix Table says both MRs are authorized for a particular MNP, then they can both register with the same MNP in the BU. Vijay From exim@www1.ietf.org Wed Mar 31 20:15:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24376 for ; Wed, 31 Mar 2004 20:15:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qn8-0002m9-Vj for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 20:14:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i311EkVt010665 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 20:14:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qn8-0002lw-PC for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 20:14:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24365 for ; Wed, 31 Mar 2004 20:14:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8qn6-0000RN-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 20:14:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8qmI-0000Ou-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 20:13:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8qlT-0000M6-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 20:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qlQ-0002f3-TO; Wed, 31 Mar 2004 20:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8qlE-0002eF-8Q for nemo@optimus.ietf.org; Wed, 31 Mar 2004 20:12:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24284 for ; Wed, 31 Mar 2004 20:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8qlC-0000KB-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8qkI-0000Gu-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:11:50 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B8qjM-00008E-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:10:52 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i311AHw08016; Wed, 31 Mar 2004 17:10:17 -0800 X-mProtect: <200404010110> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQmtfJ9; Wed, 31 Mar 2004 17:10:15 PST Message-ID: <406B6F5D.1060501@iprg.nokia.com> Date: Wed, 31 Mar 2004 17:24:45 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: nemo@ietf.org, pthubert@cisco.com, mbagnulo@ing.uc3m.es, Alexandru.Petrescu@motorola.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: summary of same MNP to mutliple MRs discussion Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > Vijay, > > Thanks for the summary. see below. > > > first of all, the current spec prevents assigning the > > same MNP to two mobile routers _if required_. > > => typo? you mean "does not prevent"? > no. based on information in the Prefix Table, the Home Agent can prevent more than one MR claiming the same MNP. or to put it more accurately, detect this and prevent the second MR from registering (and creating routes). see section 6.1.2. if the Prefix Table says both MRs are authorized for a particular MNP, then they can both register with the same MNP in the BU. Vijay From nemo-admin@ietf.org Wed Mar 31 20:35:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25121 for ; Wed, 31 Mar 2004 20:35:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8r6j-0004Dk-5z; Wed, 31 Mar 2004 20:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8r6P-0004Cr-Jk for nemo@optimus.ietf.org; Wed, 31 Mar 2004 20:34:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25039 for ; Wed, 31 Mar 2004 20:34:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8r6N-0001bW-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8r5P-0001YY-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:33:40 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8r4S-0001VK-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:32:40 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 20:32:11 -0500 Content-Class: urn:content-classes:message Date: Wed, 31 Mar 2004 20:32:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Topic: [nemo] IESG Review of Basic Support draft Thread-Index: AcQXVLYWN3HSsgwITrGVcUhYRuZwMQAMlWWA From: "Soliman Hesham" To: "IETF NEMO WG" X-OriginalArrivalTime: 01 Apr 2004 01:32:11.0246 (UTC) FILETIME=[276A68E0:01C41789] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] Section 8 comment in IESG review Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I saw Steve Bellovin's comment on this section below. Since I've been wanting to raise the same point, I have=20 a short comment. 8: This text is unclear: When the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router should be careful in including the same Mobile Network Prefixes in the Binding Update to the Home Agent and in the routing protocol updates. The Home Agent depending on its configuration might not add routes based on the prefix information in the Binding Updates at all, and might use only the routing protocol updates. Moreover, including the same prefix information in both the Binding Update and the routing protocol update is redundant. Do you mean "be careful to include the same information in both places" -- redunancy is sometimes good. Or do you mean "be careful to avoid doing this"? Personally, I think the former is more appropriate, because it allows a check on the validity of the routing information. Note that the prefixes announced via binding updates are checked for authorization; routing data generally is not. I would thus suggest that routing advertisements MUST NOT contain any prefixes not known to the home agent by either implicit mode configuration or explicit mode announcement. =3D> Basically I think we need to make sure that the HA checks the routing information exchanged and matches it=20 against the prefix information that it already knows from the MNP table/manual config/BCEs ..etc to make sure that MRs are authorised to advertise such prefix(es).=20 So we need tight coupling between the routing protocol content and the content in the BU/manual config. Otherwise Bad Guy could send a vaild BU and start announcing someone else's prefix.=20 Note that in many cases today IGPs are authenticated with a single "domain key". To maintain this type of security we need to verify that the MRs are authorised to advertise reachability to the prefixes in question.=20 I think a text change for this section will suffice. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From exim@www1.ietf.org Wed Mar 31 20:38:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25543 for ; Wed, 31 Mar 2004 20:38:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8r9V-0004jV-Cu for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 20:37:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i311br8Y018189 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 20:37:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8r9V-0004jI-3I for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 20:37:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25418 for ; Wed, 31 Mar 2004 20:37:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8r9S-00029p-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 20:37:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8r7w-0001s7-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 20:36:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8r6j-0001fU-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 20:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8r6j-0004Dk-5z; Wed, 31 Mar 2004 20:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8r6P-0004Cr-Jk for nemo@optimus.ietf.org; Wed, 31 Mar 2004 20:34:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25039 for ; Wed, 31 Mar 2004 20:34:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8r6N-0001bW-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8r5P-0001YY-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:33:40 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B8r4S-0001VK-00 for nemo@ietf.org; Wed, 31 Mar 2004 20:32:40 -0500 Received: from ftmail2000.HQ.Flarion.com ([10.10.1.120]) by ftmailgfi.HQ.Flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Mar 2004 20:32:11 -0500 Content-Class: urn:content-classes:message Date: Wed, 31 Mar 2004 20:32:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Topic: [nemo] IESG Review of Basic Support draft Thread-Index: AcQXVLYWN3HSsgwITrGVcUhYRuZwMQAMlWWA From: "Soliman Hesham" To: "IETF NEMO WG" X-OriginalArrivalTime: 01 Apr 2004 01:32:11.0246 (UTC) FILETIME=[276A68E0:01C41789] Content-Transfer-Encoding: quoted-printable Subject: [nemo] Section 8 comment in IESG review Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I saw Steve Bellovin's comment on this section below. Since I've been wanting to raise the same point, I have=20 a short comment. 8: This text is unclear: When the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router should be careful in including the same Mobile Network Prefixes in the Binding Update to the Home Agent and in the routing protocol updates. The Home Agent depending on its configuration might not add routes based on the prefix information in the Binding Updates at all, and might use only the routing protocol updates. Moreover, including the same prefix information in both the Binding Update and the routing protocol update is redundant. Do you mean "be careful to include the same information in both places" -- redunancy is sometimes good. Or do you mean "be careful to avoid doing this"? Personally, I think the former is more appropriate, because it allows a check on the validity of the routing information. Note that the prefixes announced via binding updates are checked for authorization; routing data generally is not. I would thus suggest that routing advertisements MUST NOT contain any prefixes not known to the home agent by either implicit mode configuration or explicit mode announcement. =3D> Basically I think we need to make sure that the HA checks the routing information exchanged and matches it=20 against the prefix information that it already knows from the MNP table/manual config/BCEs ..etc to make sure that MRs are authorised to advertise such prefix(es).=20 So we need tight coupling between the routing protocol content and the content in the BU/manual config. Otherwise Bad Guy could send a vaild BU and start announcing someone else's prefix.=20 Note that in many cases today IGPs are authenticated with a single "domain key". To maintain this type of security we need to verify that the MRs are authorised to advertise reachability to the prefixes in question.=20 I think a text change for this section will suffice. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is=20 strictly prohibited. If you are not the intended recipient please = contact the sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D From nemo-admin@ietf.org Wed Mar 31 22:25:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29418 for ; Wed, 31 Mar 2004 22:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8spB-0006Qa-M0; Wed, 31 Mar 2004 22:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8sp1-0006QC-Af for nemo@optimus.ietf.org; Wed, 31 Mar 2004 22:24:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29414 for ; Wed, 31 Mar 2004 22:24:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8soy-0001fT-00 for nemo@ietf.org; Wed, 31 Mar 2004 22:24:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8so5-0001dD-00 for nemo@ietf.org; Wed, 31 Mar 2004 22:23:54 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B8sno-0001Zi-00 for nemo@ietf.org; Wed, 31 Mar 2004 22:23:36 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i313MUL30314; Wed, 31 Mar 2004 19:22:30 -0800 X-mProtect: <200404010322> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqZPErt; Wed, 31 Mar 2004 19:22:28 PST Message-ID: <406B8E5A.7060301@iprg.nokia.com> Date: Wed, 31 Mar 2004 19:36:58 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Router lifetime in RAs from mobile routers Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi, you had the following comment on draft-ietf-nemo-basic-support > I'm a bit confused by this text in section 5.6: > > When the Mobile Router is at home, it MAY be configured to send > Router Advertisements and reply to Router Solicitations on the > interface attached to the home link. The value of the Router > Lifetime field MUST be set to zero to prevent other nodes from > configuring the Mobile Router as the default router. > > I don't see cases where the mobile router would have a different > upstream link in its home link than a non-mobile router on this > link. Is there a use case where it is expected that all the routers > on the home link might be mobile routers (so only mobile routers > are replying to RSs?) > > Not a blocking comment, obviously; I'm just curious about the use > case that drives this. actually this restriction is there to protect IPv6 hosts on the home link from configuring a mobile router as the default router instead of a non-mobile router. you could have mobile nodes and mobile routers connecting to the same home link when they are at home. when the mobile routers return home, they can start acting like regular routers on the egress interface (the interface with which they attach to the home link). they can start sending router advertisements. but we dont want mobile nodes (or any IPv6 host) on the home link to pick the mobile router as the default router. so we recommed setting the lifetime in the router advertisements to zero, so that no host on the home link picks a mobile router as the default router. do you see a need for more text to explain this? Vijay From exim@www1.ietf.org Wed Mar 31 22:39:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29900 for ; Wed, 31 Mar 2004 22:39:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8t32-0007TM-OY for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 22:39:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i313dK4U028720 for nemo-archive@odin.ietf.org; Wed, 31 Mar 2004 22:39:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8t32-0007T9-JO for nemo-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 22:39:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29811 for ; Wed, 31 Mar 2004 22:39:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8t2z-0002WE-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 22:39:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8t21-0002O8-00 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 22:38:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8t0n-0002HA-02 for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 22:37:01 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8spG-0004QY-0Z for nemo-web-archive@ietf.org; Wed, 31 Mar 2004 22:25:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8spB-0006Qa-M0; Wed, 31 Mar 2004 22:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8sp1-0006QC-Af for nemo@optimus.ietf.org; Wed, 31 Mar 2004 22:24:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29414 for ; Wed, 31 Mar 2004 22:24:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8soy-0001fT-00 for nemo@ietf.org; Wed, 31 Mar 2004 22:24:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8so5-0001dD-00 for nemo@ietf.org; Wed, 31 Mar 2004 22:23:54 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B8sno-0001Zi-00 for nemo@ietf.org; Wed, 31 Mar 2004 22:23:36 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i313MUL30314; Wed, 31 Mar 2004 19:22:30 -0800 X-mProtect: <200404010322> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqZPErt; Wed, 31 Mar 2004 19:22:28 PST Message-ID: <406B8E5A.7060301@iprg.nokia.com> Date: Wed, 31 Mar 2004 19:36:58 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Router lifetime in RAs from mobile routers Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, you had the following comment on draft-ietf-nemo-basic-support > I'm a bit confused by this text in section 5.6: > > When the Mobile Router is at home, it MAY be configured to send > Router Advertisements and reply to Router Solicitations on the > interface attached to the home link. The value of the Router > Lifetime field MUST be set to zero to prevent other nodes from > configuring the Mobile Router as the default router. > > I don't see cases where the mobile router would have a different > upstream link in its home link than a non-mobile router on this > link. Is there a use case where it is expected that all the routers > on the home link might be mobile routers (so only mobile routers > are replying to RSs?) > > Not a blocking comment, obviously; I'm just curious about the use > case that drives this. actually this restriction is there to protect IPv6 hosts on the home link from configuring a mobile router as the default router instead of a non-mobile router. you could have mobile nodes and mobile routers connecting to the same home link when they are at home. when the mobile routers return home, they can start acting like regular routers on the egress interface (the interface with which they attach to the home link). they can start sending router advertisements. but we dont want mobile nodes (or any IPv6 host) on the home link to pick the mobile router as the default router. so we recommed setting the lifetime in the router advertisements to zero, so that no host on the home link picks a mobile router as the default router. do you see a need for more text to explain this? Vijay