From nemo-admin@nal.motlabs.com Wed Oct 16 07:41:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25125 for ; Wed, 16 Oct 2002 07:41:56 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GBi2E28087 for ; Wed, 16 Oct 2002 13:44:03 +0200 Date: Wed, 16 Oct 2002 13:44:03 +0200 Message-Id: <200210161144.g9GBi2E28087@jessica.nal.motlabs.com> Subject: Welcome to the "nemo" mailing list From: nemo-request@nal.motlabs.com To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Welcome to the nemo@nal.motlabs.com mailing list! To post to this list, send your email to: nemo@nal.motlabs.com General information about the mailing list is at: http://www.nal.motlabs.com/mailman/listinfo/nemo If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://www.nal.motlabs.com/mailman/options/nemo/nemo-archive%40lists.ietf.org You can also make such adjustments via email by sending a message to: nemo-request@nal.motlabs.com with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: pupafo If you forget your password, don't worry, you will receive a monthly reminder telling you what all your nal.motlabs.com mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From nemo-admin@nal.motlabs.com Wed Oct 16 08:05:47 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26074 for ; Wed, 16 Oct 2002 08:05:40 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GC73E28239; Wed, 16 Oct 2002 14:07:03 +0200 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GBoPE28132 for ; Wed, 16 Oct 2002 13:50:25 +0200 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA12350 for ; Wed, 16 Oct 2002 04:50:30 -0700 (MST)] Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA13285 for ; Wed, 16 Oct 2002 04:50:22 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id g9GBoJw01373 for ; Wed, 16 Oct 2002 06:50:20 -0500 Received: from crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B40462EC8B for ; Wed, 16 Oct 2002 13:50:18 +0200 (CEST) Message-ID: <3DAD527A.9060106@crm.mot.com> From: Alexandru Petrescu Reply-To: petrescu@crm.mot.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] test Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 16 Oct 2002 13:50:18 +0200 Content-Transfer-Encoding: 7bit test ignore houh hah From nemo-admin@nal.motlabs.com Wed Oct 16 08:32:49 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27045 for ; Wed, 16 Oct 2002 08:32:42 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GCY4E28522; Wed, 16 Oct 2002 14:34:04 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GCXAE28512 for ; Wed, 16 Oct 2002 14:33:12 +0200 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 82E8B5D016; Wed, 16 Oct 2002 21:32:56 +0900 (JST) Message-Id: <20021016.213256.106412072.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Cc: tj@kniveton.com, hesham.soliman@era.ericsson.se From: Thierry Ernst In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0B6C@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF0538044F0B6C@Esealnt861.al.sw.ericsson.se> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Nemo WG approved Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 16 Oct 2002 21:32:56 +0900 (JST) Content-Transfer-Encoding: 7bit Hi all, Before anything else, let me also thank every one who helped setting up the NEMO working group, and particularly Hesham Soliman. I enjoyed working with him on the charter and preparing the BOF very much; the team work went very smoothly. I thus hope Hesham will put some cycles before we enter the RO discussion, because, as been involved in the creation of the WG, his experience is invaluable for all of us. Finally, welcome to TJ Kniveton who will soon learn all the wonderful joys of co-chairing NEMO :-). I hope it will be easier now that we agreed on the charter and become a WG. Now, let's meet our milestones ! Thierry. > From: "Hesham Soliman (EAB)" > Subject: RE: Nemo WG approved > Date: Wed, 16 Oct 2002 09:23:34 +0200 > > Folks, > > Thanks Erik for the good news and your instrumental help > this year. > > I'd like to thank you all for your infinite patience, > support and hard work to get this WG approved. Special > thanks to Thierry for receiving my regular early morning > phone calls! > > I've enjoyed the discussions we had and I'll look forward > to working with you all very soon. Perhaps next spring > when I have a few more cycles and when the RO discussions > start getting heated! > > See you in Atlanta, > Hesham > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Wednesday, October 16, 2002 7:31 AM > > To: monet@nal.motlabs.com > > Cc: erik.nordmark@sun.com; hesham.soliman@era.ericsson.se; > > tj@kniveton.com; ernst@sfc.wide.ad.jp > > Subject: Nemo WG approved > > > > > > > > The IESG has approved the Nemo WG charter and an official > > announcement > > will appear in the next few days. > > > > As part of moving from the BoF stage to the WG stage the > > ADs decided to > > change the co-chair for the group. > > > > T.J Kniveton has offered to co-chair together with Thierry. As part > > of this I'd like to thank Hesham very much for the work he > > put into making the > > BoF take place and working on refining the problem > > statement and charter, etc. > > I'm sure Hesham will continue to be active in the Nemo WG > > (at least that is > > what he told me). > > > > As part of moving from BoF to WG the intent is also to use > > the mailing > > list called nemo@nal.motlabs.com instead of "monet", but > > the chairs will > > figure out if there is any adminstrative issues to take > > care of in that space. > > > > So once again thanks to Hesham and welcome to Thierry and TJ. > > > > Erik > > > From nemo-admin@nal.motlabs.com Wed Oct 16 08:43:43 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27316 for ; Wed, 16 Oct 2002 08:43:41 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GCj9E28652; Wed, 16 Oct 2002 14:45:09 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GCiJE28636 for ; Wed, 16 Oct 2002 14:44:20 +0200 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id AB7265D016; Wed, 16 Oct 2002 21:44:11 +0900 (JST) Message-Id: <20021016.214411.26714639.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Cc: tj@kniveton.com From: Thierry Ernst X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] From now, please post to NEMO, not MONET Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 16 Oct 2002 21:44:11 +0900 (JST) Content-Transfer-Encoding: 7bit Hi all, As part of the process of creating the working group, we have moved the former MONET mailing and web page to NEMO. You don't need to subscribe to the new list, all people on the list have been automatically unsubscribed from MONET and subscribed to NEMO. From now, please only post to nemo@nal.motlabs.com. If you still send to monet by mistake, you will receive a message requesting you to post to nemo. You will find the archives at http://www.nal.motlabs.com/mailman/listinfo/nemo ; both the NEMO archives starting from today, and the MONET archives until today. The MONET archives may not be pleasant to read, though. We will soon have our official web page on http://www.ietf.org, and our additional web page for NEMO is http://www.nal.motlabs.com/nemo/. Please update your bookmarks. If you have any enquiry, please feel free to ask. And, shall I say, "Short life to the NEMO WG" :-) Thierry From nemo-admin@nal.motlabs.com Wed Oct 16 09:12:07 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28069 for ; Wed, 16 Oct 2002 09:10:39 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GCt2E28729; Wed, 16 Oct 2002 14:55:02 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GCsME28717 for ; Wed, 16 Oct 2002 14:54:24 +0200 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 226875D016; Wed, 16 Oct 2002 21:54:09 +0900 (JST) Message-Id: <20021016.215408.110844322.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Cc: alexandru.petrescu@motorola.com From: Thierry Ernst References: <20021016.203209.86399361.ernst@sfc.wide.ad.jp> In-Reply-To: <20021016.203209.86399361.ernst@sfc.wide.ad.jp> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] More about NEMO: mind your filters Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 16 Oct 2002 21:54:08 +0900 (JST) Content-Transfer-Encoding: 7bit One more thing is that you should also change filters from [monet] to [nemo]. And, by the way, I forgot to thank Alexandru Petrescu who has overcome all the troubles of translating monet to nemo. Good job ! Thierry From nemo-admin@nal.motlabs.com Wed Oct 16 11:19:08 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02917 for ; Wed, 16 Oct 2002 11:19:01 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GFK7E29198; Wed, 16 Oct 2002 17:20:07 +0200 Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9GFJkE29184 for ; Wed, 16 Oct 2002 17:19:47 +0200 Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g9GFJMCF019069 for ; Thu, 17 Oct 2002 00:19:29 +0900 (KST) Message-ID: <010f01c27527$65f032d0$ad29024b@yhhan> From: "Youn-Hee Han" To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id g9GFJkE29184 Subject: [nemo] Re: [monet] Nemo WG approved Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 17 Oct 2002 00:19:12 +0900 Content-Transfer-Encoding: 8bit Hello Thierry! This is good news for me and other NEMO researchers. I am very interested in the RO issues in NEMO, and have the plan of submitting a RO-related draft in this WG. However, I heard from your presentation at our company that we should work on the basic support of NEMO by the the spring in 2003. I want to know the clear division between the basic support and the extended support. Of course, I already read the new charter which decribes the detailed basic and extended support. However, if you would tell the highlight or crux about the two supports in this mailing list, I could appreciate you. Also, please let me know some open issues about the basic support. I think that the job on the above request will be good guidance for many NEMO researchers. Cheers, Youn-Hee Han. Samsung AIT From nemo-admin@nal.motlabs.com Thu Oct 17 11:27:48 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14558 for ; Thu, 17 Oct 2002 11:27:46 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9HFT5E02294; Thu, 17 Oct 2002 17:29:06 +0200 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9HFS3E02284 for ; Thu, 17 Oct 2002 17:28:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9HFQkgZ028918 for ; Thu, 17 Oct 2002 17:26:47 +0200 (MET DST) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 17 Oct 2002 17:27:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: [monet] Nemo WG approved Thread-Index: AcJ01jdveQyomm/aR0urlqhloOxJ0QBGs+og From: "Pascal Thubert (pthubert)" To: Cc: , , X-OriginalArrivalTime: 17 Oct 2002 15:27:04.0118 (UTC) FILETIME=[A5551560:01C275F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id g9HFS3E02284 Subject: [nemo] RE: [monet] Nemo WG approved Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 17 Oct 2002 16:27:03 +0100 Content-Transfer-Encoding: 8bit We exist :) Next is how can we get into the agenda? There are drafts that could be discussed... Pascal > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: mercredi 16 octobre 2002 07:31 > To: monet@nal.motlabs.com > Cc: erik.nordmark@sun.com; hesham.soliman@era.ericsson.se; tj@kniveton.com; > ernst@sfc.wide.ad.jp > Subject: [monet] Nemo WG approved > > > The IESG has approved the Nemo WG charter and an official announcement > will appear in the next few days. > > As part of moving from the BoF stage to the WG stage the ADs decided to > change the co-chair for the group. > > T.J Kniveton has offered to co-chair together with Thierry. As part > of this I'd like to thank Hesham very much for the work he put into making the > BoF take place and working on refining the problem statement and charter, etc. > I'm sure Hesham will continue to be active in the Nemo WG (at least that is > what he told me). > > As part of moving from BoF to WG the intent is also to use the mailing > list called nemo@nal.motlabs.com instead of "monet", but the chairs will > figure out if there is any adminstrative issues to take care of in that space. > > So once again thanks to Hesham and welcome to Thierry and TJ. > > Erik From nemo-admin@nal.motlabs.com Thu Oct 17 22:13:08 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03255 for ; Thu, 17 Oct 2002 22:13:07 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9I2F6E04972; Fri, 18 Oct 2002 04:15:06 +0200 Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9I2EZE04960 for ; Fri, 18 Oct 2002 04:14:36 +0200 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id g9I28kZ16831 for ; Fri, 18 Oct 2002 10:08:46 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 920A6A9D28B; Fri, 18 Oct 2002 10:27:35 +0800 (SGT) From: Chan-Wah Ng To: NEMO-IETF Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Message-Id: <1034908055.3983.44.camel@beethoven> Mime-Version: 1.0 Subject: [nemo] draft-ng-nemo-aa-use-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 18 Oct 2002 10:27:35 +0800 Content-Transfer-Encoding: 7bit Hi all, First let me congratulate the forming of the NEMO WG. Thanks to the effort of Hesham, Thierry and many others. I would like to draw the attention of the group to the draft I have submitted, the URL is: http://www.ietf.org/internet-drafts/draft-ng-nemo-aaa-use-00.txt This draft covers some usage scenario of large-scale commercial deployment of NEMO, and attempt to raise discussion on AAA issues (specifically, we only focus on access control for the moment) unique to NEMO. Our intention is to use this draft as a starting point to invite discussion on AAA issues for NEMO. I think it is good to discuss this while the work items for NEMO is being formed. All comments/criticisms are welcomed. Regards, Chan-Wah Ng. From nemo-admin@nal.motlabs.com Fri Oct 18 02:46:33 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17077 for ; Fri, 18 Oct 2002 02:46:31 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9I6lWE05933; Fri, 18 Oct 2002 08:47:32 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9I6k7E05923 for ; Fri, 18 Oct 2002 08:46:08 +0200 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id CD1855D0B8; Fri, 18 Oct 2002 15:45:53 +0900 (JST) Message-Id: <20021018.154553.98574249.ernst@sfc.wide.ad.jp> To: yhhan@sait.samsung.co.kr Cc: nemo@nal.motlabs.com Subject: Re: [nemo] Re: [monet] Nemo WG approved From: Thierry Ernst In-Reply-To: <010f01c27527$65f032d0$ad29024b@yhhan> References: <010f01c27527$65f032d0$ad29024b@yhhan> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 18 Oct 2002 15:45:53 +0900 (JST) Content-Transfer-Encoding: 7bit Dear Youn-Hee Han, > I want to know the clear division between > the basic support and the extended support. Of course, I already > read the new charter which decribes the detailed basic and > extended support. However, if you would tell the highlight > or crux about the two supports in this mailing list, I could appreciate you. There were a few threads about this on the mailing list before IETF Yokohama to which you can refer to. Basically, it is assumed that optimizing routing is a complex task to conduct but we would like to have a quick solution for applications that don't bother with these routing issues. So, basic support will offer what is needed to maintain ongoing sessions while extended support will be offered later as an optimization. > Also, please let me know some open issues about the basic support. > I think that the job on the above request will be good guidance > for many NEMO researchers. Basically, issues in basic support is one of the topics that we will have to discuss on this list. Thierry. From nemo-admin@nal.motlabs.com Mon Oct 21 06:14:35 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22780 for ; Mon, 21 Oct 2002 06:14:34 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9LAG7k19829; Mon, 21 Oct 2002 12:16:08 +0200 Received: from pop17.dreamnet.ne.jp (smtp17.dreamnet.ne.jp [202.217.109.105]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9LAF2k19816 for ; Mon, 21 Oct 2002 12:15:02 +0200 Received: from [10.81.113.92] ([202.14.153.7]) by pop17.dreamnet.ne.jp with ESMTP id <20021021101458.OURO10895.pop17.dreamnet.ne.jp@[10.81.113.92]> for ; Mon, 21 Oct 2002 19:14:58 +0900 From: Takeshi TANAKA To: nemo-ml Message-Id: <20021021181742.8F19.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Subject: [nemo] Next meeting Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 21 Oct 2002 18:18:20 +0800 Content-Transfer-Encoding: 7bit Hi all, Are we holding a session at the next IETF meeting? If we are, has the agenda been finalized? Best Regards, Takeshi ----------------------------------------------- Takeshi TANAKA Wireless Solution Laboratories, Panasonic e-mail: Takeshi.Tanaka@yrp.mci.mei.co.jp phone: +81-468-40-5494 / fax: +81-468-40-5183 ----------------------------------------------- From nemo-admin@nal.motlabs.com Mon Oct 21 06:17:17 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22846 for ; Mon, 21 Oct 2002 06:17:16 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9LAJ1k19860; Mon, 21 Oct 2002 12:19:01 +0200 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9LAHIk19841 for ; Mon, 21 Oct 2002 12:17:18 +0200 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id DAA04630 for ; Mon, 21 Oct 2002 03:17:16 -0700 (MST)] Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id DAA28123 for ; Mon, 21 Oct 2002 03:13:47 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id g9LAHCU05740 for ; Mon, 21 Oct 2002 05:17:12 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9E29A2EC86 for ; Mon, 21 Oct 2002 12:17:11 +0200 (CEST) From: Takeshi TANAKA To: Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nemo] Next meeting Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 21 Oct 2002 12:17:11 +0200 Hi all, Are we holding a session at the next IETF meeting? If we are, has the agenda been finalized? Best Regards, Takeshi ----------------------------------------------- Takeshi TANAKA Wireless Solution Laboratories, Panasonic e-mail: Takeshi.Tanaka@yrp.mci.mei.co.jp phone: +81-468-40-5494 / fax: +81-468-40-5183 ----------------------------------------------- From nemo-admin@nal.motlabs.com Mon Oct 21 06:35:03 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23083 for ; Mon, 21 Oct 2002 06:35:02 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9LAb1k20048; Mon, 21 Oct 2002 12:37:01 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9LAaWk20036 for ; Mon, 21 Oct 2002 12:36:32 +0200 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4EE765D024; Mon, 21 Oct 2002 19:36:24 +0900 (JST) Message-Id: <20021021.193624.03870493.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Cc: tj@kniveton.com Subject: Re: [nemo] Next meeting From: Thierry Ernst In-Reply-To: <20021021181742.8F19.TAKESHI.TANAKA@yrp.mci.mei.co.jp> References: <20021021181742.8F19.TAKESHI.TANAKA@yrp.mci.mei.co.jp> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 21 Oct 2002 19:36:24 +0900 (JST) Content-Transfer-Encoding: 7bit > Are we holding a session at the next IETF meeting? > If we are, has the agenda been finalized? We will definitely have a NEMO meeting at Atlanta, so yes you can book your flights. About the agenda, we will post a mail this week on the NEMO mailing list. Thierry From nemo-admin@nal.motlabs.com Mon Oct 21 14:00:09 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08454 for ; Mon, 21 Oct 2002 14:00:08 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9LI1Sk22203; Mon, 21 Oct 2002 20:01:29 +0200 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9LI0fk22182 for ; Mon, 21 Oct 2002 20:00:41 +0200 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA05149; Mon, 21 Oct 2002 11:00:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9LI0U514120; Mon, 21 Oct 2002 11:00:30 -0700 X-mProtect: <200210211800> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdzTnDov; Mon, 21 Oct 2002 11:00:29 PDT Message-ID: <3DB440BD.3CAE2B3@kniveton.com> From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Takeshi TANAKA CC: nemo@nal.motlabs.com Subject: Re: [nemo] Next meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 21 Oct 2002 11:00:29 -0700 Content-Transfer-Encoding: 7bit Takeshi TANAKA wrote: > Are we holding a session at the next IETF meeting? > If we are, has the agenda been finalized? Hi folks, We are discussing the agenda proposal this week, then a meeting request will be sent to the IETF. After we receive confirmation, I will post it to the list. Thanks, -TJ From nemo-admin@nal.motlabs.com Thu Oct 24 14:50:17 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19444 for ; Thu, 24 Oct 2002 14:50:16 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9OIp6H07696; Thu, 24 Oct 2002 20:51:06 +0200 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9OIoeH07686 for ; Thu, 24 Oct 2002 20:50:40 +0200 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27424; Thu, 24 Oct 2002 11:50:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9OIoAa04941; Thu, 24 Oct 2002 11:50:10 -0700 X-mProtect: <200210241850> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpd54WVni; Thu, 24 Oct 2002 11:50:08 PDT Message-ID: <3DB840E1.5D9B1AEC@kniveton.com> From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@nal.motlabs.com, ernst@sfc.wide.ad.jp, narten@us.ibm.com, erik.nordmark@sun.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Solution Requirements Process Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 24 Oct 2002 11:50:09 -0700 Content-Transfer-Encoding: 7bit This week, we have been discussing the issue of how to begin work on producing the documents which the NEMO wg has promised to deliver. This involved process begins with defining the requirements of Phase I of our work: the non-optimized reachability support using reverse tunneling. Our ADs have been helpful in suggesting how to make good forward progress on this, and we would like to share the process that was proposed, and what we feel is necessary to build momentum at this point. Firstly, one of our goals is to start discussing the various facets of the requirements as they have been proposed right away. This way, we can identify the areas of agreement straight off, and discuss the controversial topics one by one. In order to take all viewpoints into consideration, we would like to have as a starting point all requirements documents that were previously discussed in the BOF sessions. Since these are individual drafts which have expired, we ask those authors to resubmit them before the draft cutoff. If others have already written text on ideas for requirements that are ready for discussion, they can be put into draft form as well, minding the fast approaching cut-off for new drafts. Once we have these drafts, it will be helpful if a reviewer can go through them to see the common points of agreement, the deltas between the documents; i.e. points of difference, and unique ideas which may only be found in one or two drafts. After having this information, we can discuss these points on the list and reach a consensus in an organized way. For the IETF, we have requested a 2 hour slot, when we can have some further analysis of open issues in the Requirements, and other topics as will be outlined in the agenda. And finally, we were wondering whether anyone has begun to think about the threats analysis document and has come up with any material on that topic. Thanks, TJ & Thierry From nemo-admin@nal.motlabs.com Fri Oct 25 08:21:40 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22314 for ; Fri, 25 Oct 2002 08:21:38 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9PCHRC01406; Fri, 25 Oct 2002 14:17:27 +0200 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9PCGeC01395 for ; Fri, 25 Oct 2002 14:16:40 +0200 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id FAA14578; Fri, 25 Oct 2002 05:16:37 -0700 (MST)] Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA07526; Fri, 25 Oct 2002 05:16:37 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g9PCDQU31704; Fri, 25 Oct 2002 07:13:27 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 30D352EC86; Fri, 25 Oct 2002 14:13:20 +0200 (CEST) To: "T.J. Kniveton" Cc: , , , Subject: Re: [nemo] NEMO Solution Requirements Process References: <3DB840E1.5D9B1AEC@kniveton.com> From: Alexandru Petrescu In-Reply-To: <3DB840E1.5D9B1AEC@kniveton.com> Message-ID: Lines: 49 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 25 Oct 2002 14:13:19 +0200 "T.J. Kniveton" writes: > This week, we have been discussing the issue of how to begin work on > producing the documents which the NEMO wg has promised to deliver. This > involved process begins with defining the requirements of Phase I of our > work: the non-optimized reachability support using reverse > tunneling. Yes, we should concentrate more on requirements that are related to the MRHA tunnel kind of solution. For example, requirements that are related to RO, or requirements that are related to it being transparent to TCP are no longer relevant now. We now know that this is transparent to TCP and that RO is for later. IMHO, what we need to require is things like how is the link-local address supported in Mobile IPv6, because MR is a router and normally uses its ll address for exchanging routing info. Requirements like that. > And finally, we were wondering whether anyone has begun to think about > the threats analysis document and has come up with any material on that > topic. Yes, we begun thinking about security threat analysis, but not about the document :-) Threat analysis is much simplified when the MRHA-like Mobile IPv6 solution is clearer. There are still many open questions about that solution. As with the MRHA requirements, the security threat analysis should address only the MRHA-like solution, not the RO. It should find out whether using MR instead of MH in Mobile IPv6 introduces new threats and what kinds of threats. For example, in the MH case, a possible threat is that MH1 impersonates MH2, where MH1 and MH2 have the same HA. This is countered by securing the MHHA tunnel. In the MR case, when MR acts as an MH too, and if that MH develops an SA with a CN (via return routability tests), then it must not be possible for the LFN's to take advantage of that SA in order to communicate with the CN. When the MR is at home, and MR maintains secure classical secure routing (like authenticated RIP or authenticated OSPF) with its routers at home, then that classical secure routing should be maintained when the MR is not at home. Things like that. But I bet there are many more. Alex From nemo-admin@nal.motlabs.com Fri Oct 25 12:16:28 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00397 for ; Fri, 25 Oct 2002 12:16:26 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9PGD2C02512; Fri, 25 Oct 2002 18:13:02 +0200 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9PGCuC02502 for ; Fri, 25 Oct 2002 18:12:56 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9PGBDSc024487 for ; Fri, 25 Oct 2002 18:11:38 +0200 (MET DST) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 25 Oct 2002 18:12:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: Thread-Topic: Route Optimization in Nemo Thread-Index: AcJ8QRWxclhd6t1JSW+1IdVC3RPxKg== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 25 Oct 2002 16:12:48.0524 (UTC) FILETIME=[5C6E34C0:01C27C41] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id g9PGCuC02502 Subject: [nemo] Route Optimization in Nemo Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 25 Oct 2002 17:12:48 +0100 Content-Transfer-Encoding: 8bit Hi Some time ago, I published http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-00.tx t Which is an attempt to start a discussion on Route Optimization in the Nemo context. I wish to debate issues on this topic if anybody is interested. At the moment, the goal is to refine our understanding of the problem space. Pascal Thubert From nemo-admin@nal.motlabs.com Sat Oct 26 19:29:41 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14704 for ; Sat, 26 Oct 2002 19:29:40 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9QNR7C14901; Sun, 27 Oct 2002 01:27:07 +0200 Received: from mail.com (host-66-133-60-178.verestar.net [66.133.60.178]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id g9QNQhC14891 for ; Sun, 27 Oct 2002 01:26:47 +0200 Message-Id: <200210262326.g9QNQhC14891@jessica.nal.motlabs.com> From: "LOUISA E. ESTRADA" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Reply-To: "LOUISA E. ESTRADA" Content-Transfer-Encoding: 8bit Subject: [nemo] SOLICITING FOR YOUR ASSISTANCE. Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 27 Oct 2002 00:26:44 +0100 Content-Transfer-Encoding: 8bit FROM: MRS. LOUISA EJERCITOR ESTRADA Email: estradal@rediffmail.com estradalo@rediffmail.com E-fax: +1 775-458-2140 Dear Sir, I got your contact address through a reliable friend in my search for a reliable and trustworthy person who will assist me in a business investment venture in your country. I am Mrs. LOUISA EJERCITOR ESTRADA, the wife of Mr. Joseph Estrada the former president of Philippine located in the south East Asia. My husband was presently impeached from office by a backed uprising of mass demonstrators and the senate. During my husband's regime as president of Philippine, I realized US$21.540 millions of dollars from various contract projects I executed successfully. I had planned to invest this money for my children's future on real estate and industrial production. My husband is not aware of this because I wish to do it secretly for now. Before my husband was impeached from office, I concretely and secretly deposited this money and declared it computer ledger cards with diplomatic Security Company that transports valuable goods/consignment through diplomatic courier service to their offshore offices. The consignments that are contained in the two trunks are declared owned by my foreign business partners. I wish to discuss how much I will offer you if you will be willing to assist me claim the money and invest it in your country. I want to assure you that all modalities are put in place and it is a risk free transaction. I trust you as a God fearing person who will not sit on my life saving fund. This business demands absolute secrecy and confidentiality, thus all communications for now should be through e-mail because all my phone lines are connected to the Philippine's Telecommunication network services. I will furnish you with more details when I receive your positive response. Expecting your urgent reply. Thanking you for your anticipated co-operation. Best regards, MRS. LOUISA EJERCITOR ESTRADA From nemo-admin@nal.motlabs.com Sun Oct 27 23:16:53 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16006 for ; Sun, 27 Oct 2002 23:16:52 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9S4I7C25905; Mon, 28 Oct 2002 05:18:07 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9S4HLC25895 for ; Mon, 28 Oct 2002 05:17:21 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4A5835D00D for ; Mon, 28 Oct 2002 13:17:12 +0900 (JST) Message-Id: <20021028.131712.63244074.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com From: Thierry Ernst X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Terminology Update Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 13:17:12 +0900 (JST) Content-Transfer-Encoding: 7bit Hi all, I've updated the terminology draft: http://www.ietf.org/internet-drafts/draft-ernst-nemo-terminology-00.txt Please don't refer to draft-ernst-monet-terminology ... anymore. If I receive useful comments by Friday, I can update it to a version -01 before the meeting. Cheers, Thierry From nemo-admin@nal.motlabs.com Mon Oct 28 02:06:45 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28531 for ; Mon, 28 Oct 2002 02:06:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9S782C26621; Mon, 28 Oct 2002 08:08:03 +0100 Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9S770C26611 for ; Mon, 28 Oct 2002 08:07:01 +0100 Received: by bulls.mei.co.jp (8.12.5/3.7W/kings) with ESMTP id g9S76ehE029215; Mon, 28 Oct 2002 16:06:40 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id g9S76eU24223; Mon, 28 Oct 2002 16:06:40 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with ESMTP id g9S76dP01971; Mon, 28 Oct 2002 16:06:39 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:02091217) id g9S76d524213; Mon, 28 Oct 2002 16:06:40 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.11.3/3.7W-GW1) with ESMTP id g9S76Zj10889; Mon, 28 Oct 2002 16:06:35 +0900 (JST) Received: from [133.183.211.202] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7W-TELECOM) with ESMTP id g9S76Un16055; Mon, 28 Oct 2002 16:06:31 +0900 (JST) From: Takeshi TANAKA To: "Pascal Thubert (pthubert)" , IETF NEMO Subject: Re: [nemo] Route Optimization in Nemo In-Reply-To: References: Message-Id: <20021028150706.0A59.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 15:10:06 +0800 Content-Transfer-Encoding: 7bit Hi Pascal, We are also interested in the RO problem of NEMO especially in nested case. We see that nested mobile nodes is inevitable in a practical world deployment scenario. First of, some comments on your RO-Taxonomy draft: > 2.1 Nested tunnels optimization > Such a solution introduces the following problems: > "Pinball" routing ... > Packet size ... I think the problem of nested tunnels can be further broken down into: "pinball" routing - HA/MR processing resources consumption - increased latency increased in packet size - wireless link bandwidth consumption - network resource consumption - more packet fragmentation(by each termination) > The potential approaches for avoiding the nesting of tunnels include: > Route Aggregation ... > Surrogate ... > Internal Routing and gateway ... > RRH ... Routing header can be used to avoid problems you listed, but I think naming the paragraph RRH is putting adding presumptions on the method of constructing the Routing Header, since there could be other method to collect information needed to construct routing header. > 3. MR-to-CN > ... > accept the risk. If not, the optimization may be limited to > triangular routing MR->CN->HA->MR. > ... I think packet delivery path in this case will not be a triangular routing(MR->CN->HA->MR), but "dog-leg" routing (MR->HA->CN, CN->HA->MR). > 6. Conclusion > ...MIPv6 seems to be...more difficult to probide a Nemo solution > with backward compatibility, since: ... > 2) The RR test has no negotiable option and is not open for extension, What does this sentence mean? In MIPv6 draft #18, each messages in RR test can contain some mobility option field. These option fields can be used to carry other information. In addition, we can modify the way each cookie is generated at CN side if necessary. For your "call for debate" in laying down the RO requirements, it is a good idea. We will try to write down something concrete for futher discussion in the mailing list. On a side note, we think there wont be any time slots for discussion about RO solutions in the upcoming IETF meeting, but if we can laid down some set of requirements for RO, perhaps we can request for a time slot to discuss the problem scope of RO? ------------ Takeshi From nemo-admin@nal.motlabs.com Mon Oct 28 04:17:23 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01255 for ; Mon, 28 Oct 2002 04:17:20 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9S9I4C27144; Mon, 28 Oct 2002 10:18:04 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9S9HlC27134 for ; Mon, 28 Oct 2002 10:17:47 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9S9GJ3u029905; Mon, 28 Oct 2002 10:16:27 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 28 Oct 2002 10:17:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C27E62.D932ED90" Subject: RE: [nemo] Route Optimization in Nemo Message-ID: X-MS-Has-Attach: yes Thread-Topic: [nemo] Route Optimization in Nemo Thread-Index: AcJ+UJkO/ygaZ6oZQ9u+zTc+/FYtGwACVIwA From: "Pascal Thubert (pthubert)" To: "Takeshi TANAKA" , "IETF NEMO" X-OriginalArrivalTime: 28 Oct 2002 09:17:34.0867 (UTC) FILETIME=[D9F91630:01C27E62] Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 09:17:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C27E62.D932ED90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Takeshi TANAKA [mailto:Takeshi.Tanaka@yrp.mci.mei.co.jp]=20 > Sent: lundi 28 octobre 2002 08:10 > To: Pascal Thubert (pthubert); IETF NEMO > Subject: Re: [nemo] Route Optimization in Nemo >=20 >=20 > Hi Pascal,=20 >=20 > We are also interested in the RO problem of NEMO especially=20 > in nested case. We see that nested mobile nodes is=20 > inevitable in a practical world deployment scenario. >=20 > First of, some comments on your RO-Taxonomy draft: >=20 > > 2.1 Nested tunnels optimization > > Such a solution introduces the following problems: > > "Pinball" routing ... > > Packet size ... >=20 > I think the problem of nested tunnels can be further broken=20 > down into: "pinball" routing > - HA/MR processing resources consumption > - increased latency > increased in packet size > - wireless link bandwidth consumption > - network resource consumption > - more packet fragmentation(by each termination) >=20 Sure ! Depending on the environment and the implementation, the gating factor may not be the same in all cases. >=20 > > The potential approaches for avoiding the nesting of=20 > tunnels include:=20 > > Route Aggregation ... Surrogate ... > > Internal Routing and gateway ... > > RRH ... > Routing header can be used to avoid problems you listed, but=20 > I think naming the paragraph RRH is putting adding=20 > presumptions on the method of constructing the Routing=20 > Header, since there could be other method to collect=20 > information needed to construct routing header. >=20 Agreed, I'll fix that. RRH could be listed as an example but it's not a category. I'm not sure how to describe the category, though, and I expect more discussion when I do, since I mean to differentiate from a MANET based source routing. What do you think of "standard based source routing"? Note that the RRH draft presents RRH as an IPv6 header, not a MIP thing. Then the draft shows how that header could be used by MIP, though the usage is not restricted to MIP.=20 >=20 > > 3. MR-to-CN > > ... > > accept the risk. If not, the optimization may be limited to =20 > > triangular routing MR->CN->HA->MR. ... > I think packet delivery path in this case will not be a=20 > triangular routing(MR->CN->HA->MR), but "dog-leg" routing=20 > (MR->HA->CN, CN->HA->MR). >=20 Not sure: The MR can encapsulate packets to the CN instead of the home agent, potentially at the expense of IPSec. The CN has to support the encapsulation and it may accept to forward the inner packets even if it does not trust the MR enough to optimize the reverse direction. This may defeat ingress filtering, but then it's a matter of policy. Be prepared for a long debate :) >=20 > > 6. Conclusion > > ...MIPv6 seems to be...more difficult to probide a Nemo=20 > solution with=20 > > backward compatibility, since: ... > > 2) The RR test has no negotiable option and is not open for=20 > extension, > What does this sentence mean? > In MIPv6 draft #18, each messages in RR test can contain some=20 > mobility option field. These option fields can be used to=20 > carry other information. In addition, we can modify the way=20 > each cookie is generated at CN side if necessary. >=20 OK, I'm being crytic again. I was talking about the RR and CN as described by MIP. Options give you additional information but there's no such thing as a completion code or negotiation in RR test. As you mention, we will have to modify the CN again. The MIP CN is already a burden, I wonder how difficult it will be to add our stuff into it. We could have coped with a simple generic negociation like triangular yes-no, CareOf yes-no... Which could have been beneficial to MIP as well. I tried a few things on the MIP list. Please see 'CoT' and the 'HAO, BE processing' discussions in July (some appended). I understand it's not a priority and they want to close the debate, our cost. Same for the HaO, we would need a CN change to make it multihop. At that point, I believe that a RH is better ;) > For your "call for debate" in laying down the RO=20 > requirements, it is a good idea. We will try to write down=20 > something concrete for futher discussion in the mailing list. >=20 :) > On a side note, we think there wont be any time slots for=20 > discussion about RO solutions in the upcoming IETF meeting,=20 > but if we can laid down some set of requirements for RO,=20 > perhaps we can request for a time slot to discuss the problem=20 > scope of RO? >=20 Agreed, and it's up to the chairmen to do the first thing first. There's this debate about the requirements for the basic Nemo that will take a long time in the Agenda. I believe that understanding RO is important for the design of Basic, but I agree it's not necessarily needed to establish the requirements.=20 Yet, since some of us are industrials, we can't wait 2 years to have everything done by the book. If Nemo is too slow, I'm sure companies will come up with proprietary solutions for the interim, at a cost; so it's beneficial to start this thread already, even if it means a very short entry in the Agenda, and offline meetings in Atlanta. Will you be there? > ------------ > Takeshi >=20 >=20 ------_=_NextPart_001_01C27E62.D932ED90 Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f content-class: urn:content-classes:message Subject: [mobile-ip] CoT Date: Mon, 1 Jul 2002 09:47:18 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] CoT List-Subscribe: List-Unsubscribe: From: "Pascal Thubert" Sender: To: Content-Transfer-Encoding: quoted-printable I understand that the RR test is meant for the CN to ensure that the = remote mobile node is actually who he says, at least as far as the Home Agent = knows. So a CN sends a secret via Home, and hopefully the REAL guy gets it. Then = the REAL guy could talk to the CN, using that secret to authenticate himself. = Now, what about the CareOf Test? Seems that is it mostly used to check that the = path to the MN works. To me, it looks like the first beat of a heartbeat more = than a HELLO; we're just missing the next beats to detect when the path becomes unusable, in which case the home route should be used. Anyway, what = bothers me is that the CareOf address is part of the secret that comes with that = test. When the MN moves, a new test is needed before the BU, correct? In general, I do not necessarily see the value of that secret in the CoT = for MIP. If the guy at the CoA has the secret from the HoT, then it's him, = ain't it? This line of thinking would end up with a flow like: 1) HoT once 2) BU, based on HoT only, when CoA change 3) CoT as a heartbeat What do you think? Pascal ------_=_NextPart_001_01C27E62.D932ED90 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [mobile-ip] Re: summary of HAO, BE processing discussion Date: Thu, 18 Jul 2002 16:00:05 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: summary of HAO, BE processing discussion Thread-Index: AcIudC3FP1HZfqSJReOAyqGZaNDiug== From: "Pascal Thubert" To: =?US-ASCII?B?S2VpaWNoaSBTSElNQSAvICI/T2NeZQ==?= , Cc: "mat (mailer list)" , , , Content-Transfer-Encoding: quoted-printable I think I've been a little cryptic: Some devices such as a fridge may be happy to have a minimum set of requirements for IPv6. Other devices such as clustered servers may not be able to maintain a BCE at all because the cluster IP address is shared among all the members of the cluster -- unless they perform a new protocol to distribute the BCEs-. Furthermore, if the cluster uses a dispatcher that is not on the return path, then the dispatcher cannot provide the MIP termination, either. However, if that same dispatcher terminates an IPSEC tunnel, or by other means to be defined later such as piggy backing, it could be possible to trust a Home address option and perform triangular routing.=20 Using a Binding Cache as opposed to piggy backing the BU with each packet assumes that memory scales better than CPU. This seems a reasonable approach, so does delaying the support of piggybacking. But still, we must allow for the case where this trade-off does not apply. Say the dispatcher I just mentioned has a hardware accelerated crypto engine; say it can cache some recent computations in a LRU fashion; say it has limited memory capabilities to keep many BCEs long term; and say it needs to serve requests for a huge amount of unrelated users; in that case, the trade-off is the wrong choice, and triangular may be the best can do, unless the client sources its requests with its CoA, which leads to more open issues. MUSTing a Binding Cache in IPv6 outlaws this configuration de facto.=20 If we agree that there can be several levels of support by the CN for RO, then we could define what the behaviour is for each level and how to negotiate that between the CN and the MN. My suggestion was to do that negotiation at RR test time so that no bind support would be necessary unless both parties agree upon bi-directional route optimization. A way to perform that negotiation is to give a meaning to the response to HoTi and CoTi. This may be achieved by adding negative Return Code to Hot Cot, and mostly by accepting an ICMP error as a 'no' response. So 'No' to Both HoTi and CoTi means no bind updates, and usage of the bidir MN-HA tunnel, which ensures compatibility with minimum and legacy stacks, as per the draft 'Yes' to both HoTi and CoTi means let's go with the bind update, as per the draft 'Yes' to CoTi only means support for Home Address option but not for Bind Cache 'Yes' to HoTi only does not make sense to me at the moment ??? This is not exactly the way the draft presents things, mostly for the triangular part. Also, the draft is heavily biased (e.g. 8.1) in such a way as to let the reader believe that MIP could not work without support of the Home Address option by all nodes, "since otherwise communications may be impossible". I believe that this is misleading, and that we should rather explain the different scenarios and pro/cons of each level of support by the CN. I believe we ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1.=20 Does that make sense? Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Keiichi SHIMA / "?OEc^e Sent: Thursday, July 18, 2002 7:19 AM To: jari.arkko@kolumbus.fi Cc: mat@cisco.com; itojun@iijlab.net; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: summary of HAO, BE processing discussion Let me add one thing. From: Jari Arkko > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. In addition, the current draft requires not only HAO but also BE. This means all IPv6 nodes must implement a new extention header (mobility header). I never say that such a mechanism is bad at all. It is good of course. But from the view of the fast deployment of both IPv6 and Mobile IPv6, I personally think it better not to require additional requirements... This is not the view of the protocol designer, though. I'm probablly a bad designer and a bad scientist. I just want a real IPv6 and a Mobile IPv6... Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project ------_=_NextPart_001_01C27E62.D932ED90-- From nemo-admin@nal.motlabs.com Mon Oct 28 07:40:41 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06053 for ; Mon, 28 Oct 2002 07:40:39 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SCg5C28666; Mon, 28 Oct 2002 13:42:06 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SCfdC28652 for ; Mon, 28 Oct 2002 13:41:39 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id OAA06257 for ; Mon, 28 Oct 2002 14:41:38 +0200 (EET) Received: from ele4114 (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with SMTP id OAA28329 for ; Mon, 28 Oct 2002 14:41:37 +0200 (EET) Message-ID: <003d01c27e7f$c5b36550$725ebc82@ELE4114.ele.vtt.fi> From: "=?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?=" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C27E90.88F2D040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [nemo] IPv6 prefix delegation Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 14:44:35 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C27E90.88F2D040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , I was wondering is IPv6 prefix delegation for the links of a Mobile = Network part of NEMO-WG focus? Should NEMO pay attention on this subject at all or does it belong = entirely to some other working group? Pekka P=E4=E4kk=F6nen ------=_NextPart_000_003A_01C27E90.88F2D040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi ,
 
I was wondering is IPv6 prefix delegation for the = links of a=20 Mobile Network part of NEMO-WG focus?
Should NEMO pay attention on this subject at = all=20 or does it belong entirely to some other working = group?
 
Pekka P=E4=E4kk=F6nen
 
------=_NextPart_000_003A_01C27E90.88F2D040-- From nemo-admin@nal.motlabs.com Mon Oct 28 08:18:46 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07455 for ; Mon, 28 Oct 2002 08:18:45 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SDK3C28924; Mon, 28 Oct 2002 14:20:03 +0100 Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SDJUC28908 for ; Mon, 28 Oct 2002 14:19:30 +0100 Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9SDJ8iZ006103 for ; Mon, 28 Oct 2002 08:19:08 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 28 Oct 2002 08:19:37 -0500 Message-ID: <3DBD38C8.6030709@nc.rr.com> From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@nal.motlabs.com Subject: Re: [nemo] IPv6 prefix delegation References: <003d01c27e7f$c5b36550$725ebc82@ELE4114.ele.vtt.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 08:16:56 -0500 Content-Transfer-Encoding: 8bit Hi Pekka, The original discussion of prefix delegation occurred on the IPv6 WG mailing list. The zerouter BoF being held in Atlanta is also going be interested in the subject. I can see where NEMO needs to be involved as well. Regards, Brian Pekka Pääkkönen wrote: > Hi , > > I was wondering is IPv6 prefix delegation for the links of a Mobile > Network part of NEMO-WG focus? > Should NEMO pay attention on this subject at all or does it belong > entirely to some other working group? > > Pekka Pääkkönen > From nemo-admin@nal.motlabs.com Mon Oct 28 09:02:53 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09675 for ; Mon, 28 Oct 2002 09:02:52 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SE42C29145; Mon, 28 Oct 2002 15:04:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SE3bC29135 for ; Mon, 28 Oct 2002 15:03:37 +0100 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA12078; Mon, 28 Oct 2002 07:03:33 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA01150; Mon, 28 Oct 2002 06:59:53 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g9SE0Id25135; Mon, 28 Oct 2002 08:00:19 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id D2FD02EC86; Mon, 28 Oct 2002 15:00:17 +0100 (CET) To: Cc: , , , , , , , From: Alexandru Petrescu Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nemo] draft submission Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 28 Oct 2002 15:00:17 +0100 Dear Sir, Please accept the following -00 personal draft submission; please announce this Internet Draft on the IETF Announce mailing list. Petrescu, et al., "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)". http://www.nal.motlabs.com/~petrescu/draft-petrescu-nemo-mrha-00.txt Thank you, Alex From nemo-admin@nal.motlabs.com Mon Oct 28 09:20:36 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10284 for ; Mon, 28 Oct 2002 09:20:35 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SEM2C29411; Mon, 28 Oct 2002 15:22:02 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SELlC29401 for ; Mon, 28 Oct 2002 15:21:47 +0100 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id HAA24999; Mon, 28 Oct 2002 07:21:44 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA09587; Mon, 28 Oct 2002 07:21:43 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g9SEMRY16098; Mon, 28 Oct 2002 08:22:28 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6E8562EC8B; Mon, 28 Oct 2002 15:21:38 +0100 (CET) Message-ID: <3DBD47F1.16CD68CB@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cc: Thierry Ernst, "T.J. Kniveton", Janneteau_Christophe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] draft submission: draft-janneteau-nemo-requirements-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 15:21:37 +0100 Content-Transfer-Encoding: 7bit Dear all, We have just re-submit a revision of our internet draft on requirements: http://www.nal.motlabs.com/nemo/draft-janneteau-nemo-requirements-00.txt (as a replacement of the former I-D draft-lach-monet-requirements-00.txt). Hope this text will be useful for the WG. Any comment is welcome. Thanks, Christophe From nemo-admin@nal.motlabs.com Mon Oct 28 09:22:40 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10329 for ; Mon, 28 Oct 2002 09:22:38 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SEO1C29437; Mon, 28 Oct 2002 15:24:01 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SENhC29427 for ; Mon, 28 Oct 2002 15:23:43 +0100 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id HAA29591; Mon, 28 Oct 2002 07:20:50 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA29362; Mon, 28 Oct 2002 07:23:35 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g9SEOJY17102; Mon, 28 Oct 2002 08:24:20 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id EEA912EC86; Mon, 28 Oct 2002 15:23:30 +0100 (CET) Message-ID: <3DBD4862.FFA90535@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: , Thierry Ernst, "T.J. Kniveton", Janneteau_Christophe References: <3DBD47F1.16CD68CB@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: draft submission: draft-janneteau-nemo-requirements-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 15:23:30 +0100 Content-Transfer-Encoding: 7bit Here is the correct URL: http://www.nal.motlabs.com/nemo/drafts/draft-janneteau-nemo-requirements-00.txt Sorry, Christophe Christophe Janneteau wrote: > > Dear all, > > We have just re-submit a revision of our internet draft on requirements: > > http://www.nal.motlabs.com/nemo/draft-janneteau-nemo-requirements-00.txt > > (as a replacement of the former I-D > draft-lach-monet-requirements-00.txt). > > Hope this text will be useful for the WG. Any comment is welcome. > Thanks, > Christophe From nemo-admin@nal.motlabs.com Mon Oct 28 09:25:30 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10469 for ; Mon, 28 Oct 2002 09:25:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SER2C29468; Mon, 28 Oct 2002 15:27:02 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SEQDC29457 for ; Mon, 28 Oct 2002 15:26:14 +0100 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA02058; Mon, 28 Oct 2002 07:26:11 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA11396; Mon, 28 Oct 2002 07:26:10 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g9SEMvd07822; Mon, 28 Oct 2002 08:22:58 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B24CC2EC86; Mon, 28 Oct 2002 15:22:56 +0100 (CET) To: Brian Haberman Cc: Subject: Re: [nemo] IPv6 prefix delegation References: <003d01c27e7f$c5b36550$725ebc82@ELE4114.ele.vtt.fi> <3DBD38C8.6030709@nc.rr.com> From: Alexandru Petrescu In-Reply-To: <3DBD38C8.6030709@nc.rr.com> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 28 Oct 2002 15:22:56 +0100 Brian Haberman writes: > The original discussion of prefix delegation occurred on > the IPv6 WG mailing list. The zerouter BoF being held in Atlanta > is also going be interested in the subject. I can see where NEMO > needs to be involved as well. The word "delegation" is also related to security delegation ideas having been circulated on this list when discussing about LFNs delegating their MR to do RO on their behalf. Or something like that. Pekka Nikander and Erik Nordmark IIRC. Alex From nemo-admin@nal.motlabs.com Mon Oct 28 09:49:56 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11811 for ; Mon, 28 Oct 2002 09:49:54 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SEp1C30261; Mon, 28 Oct 2002 15:51:01 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SEoFC30245 for ; Mon, 28 Oct 2002 15:50:16 +0100 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA04045; Mon, 28 Oct 2002 07:50:11 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA09984; Mon, 28 Oct 2002 07:50:10 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g9SEo6d26899; Mon, 28 Oct 2002 08:50:07 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 10C162EC86; Mon, 28 Oct 2002 15:50:06 +0100 (CET) To: Brian Haberman Cc: Subject: Re: [nemo] IPv6 prefix delegation References: <003d01c27e7f$c5b36550$725ebc82@ELE4114.ele.vtt.fi> <3DBD38C8.6030709@nc.rr.com> From: Alexandru Petrescu In-Reply-To: <3DBD38C8.6030709@nc.rr.com> Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 28 Oct 2002 15:50:06 +0100 Brian Haberman writes: > The original discussion of prefix delegation occurred on > the IPv6 WG mailing list. The zerouter BoF being held in Atlanta > is also going be interested in the subject. I can see where NEMO > needs to be involved as well. Brian, where does NEMO need to be involved with prefix delegation? Thanks, Alex From nemo-admin@nal.motlabs.com Mon Oct 28 10:54:09 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15457 for ; Mon, 28 Oct 2002 10:54:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SFo8C30890; Mon, 28 Oct 2002 16:50:09 +0100 Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SFnHC30876 for ; Mon, 28 Oct 2002 16:49:18 +0100 Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9SFn7up004242; Mon, 28 Oct 2002 10:49:07 -0500 (EST) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 28 Oct 2002 10:48:32 -0500 Message-ID: <3DBD5BDC.5030804@nc.rr.com> From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] IPv6 prefix delegation References: <003d01c27e7f$c5b36550$725ebc82@ELE4114.ele.vtt.fi> <3DBD38C8.6030709@nc.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 10:46:37 -0500 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Brian Haberman writes: > >> The original discussion of prefix delegation occurred on >>the IPv6 WG mailing list. The zerouter BoF being held in Atlanta >>is also going be interested in the subject. I can see where NEMO >>needs to be involved as well. > > > Brian, where does NEMO need to be involved with prefix delegation? > When a mobile network connects to a new site, that site may be using prefix delegation in order to communicate with the stationary router. Several prefix delegation models allow for the negotiation of things like the routing protocol to use for the connection. Regards, Brian From nemo-admin@nal.motlabs.com Mon Oct 28 11:51:51 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18344 for ; Mon, 28 Oct 2002 11:51:50 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SGr5C31930; Mon, 28 Oct 2002 17:53:05 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SGqqC31916 for ; Mon, 28 Oct 2002 17:52:53 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SGpUth026324; Mon, 28 Oct 2002 17:51:31 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 28 Oct 2002 17:52:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [nemo] IPv6 prefix delegation Message-ID: Thread-Topic: [nemo] IPv6 prefix delegation Thread-Index: AcJ+kpNiq+bdjbxvRomS3Gz9MFrvQgADqzTg From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 28 Oct 2002 16:52:36.0177 (UTC) FILETIME=[6AD26410:01C27EA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id g9SGqqC31916 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 16:52:35 -0000 Content-Transfer-Encoding: 8bit There are basically 3 ways for the HA to establish routes to the mobile networks via the MR: 1) static model: routes are statically configured at the HA, and the networks are pre-configured on the MR interfaces as well. 2) Dynamic model: A protocol is used by the MR to advertise its networks to the HA so the HA does not need prior config. The protocol could be a traditional IGP over the home tunnel, or a MIP extension such as proposed by Thierry's draft. 3) Delegation - there we are -: The MR learns the prefixes on its network from the HA. This could be done using DHCPv6 when it's an RFC, or other (still debated at IPv6 without even MIP in the picture !!!) Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@crm.mot.com] > Sent: lundi 28 octobre 2002 15:50 > To: Brian Haberman > Cc: nemo@nal.motlabs.com > Subject: Re: [nemo] IPv6 prefix delegation > > > Brian Haberman writes: > > The original discussion of prefix delegation occurred on the > > IPv6 WG mailing list. The zerouter BoF being held in > Atlanta is also > > going be interested in the subject. I can see where NEMO > needs to be > > involved as well. > > Brian, where does NEMO need to be involved with prefix delegation? > > Thanks, > > Alex > > From nemo-admin@nal.motlabs.com Mon Oct 28 12:00:52 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18821 for ; Mon, 28 Oct 2002 12:00:50 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SH11C32022; Mon, 28 Oct 2002 18:01:01 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SH0hC32001 for ; Mon, 28 Oct 2002 18:00:45 +0100 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA05099 for ; Mon, 28 Oct 2002 10:00:34 -0700 (MST)] Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA10406 for ; Mon, 28 Oct 2002 10:00:33 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id g9SH0TE29379; Mon, 28 Oct 2002 11:00:30 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id CC4C12EC86; Mon, 28 Oct 2002 18:00:27 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: Subject: Re: [nemo] IPv6 prefix delegation References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 28 Oct 2002 18:00:27 +0100 "Pascal Thubert (pthubert)" writes: > There are basically 3 ways for the HA to establish routes to the mobile > networks via the MR: > > 1) static model: routes are statically configured at the HA, and the > networks are pre-configured on the MR interfaces as well. > > 2) Dynamic model: A protocol is used by the MR to advertise its networks > to the HA so the HA does not need prior config. The protocol could be a > traditional IGP over the home tunnel, or a MIP extension such as > proposed by Thierry's draft. 2.5) Dynamic model with ICMP redirects instead of IGP. > 3) Delegation - there we are -: The MR learns the prefixes on its > network from the HA. This could be done using DHCPv6 when it's an RFC, > or other (still debated at IPv6 without even MIP in the picture !!!) The MR learns its MNPs from the HA when MR is not at home, through the MRHA tunnel? I thought Brian was referring to MR learns new prefixes from the visited network, something like Care-of Prefixes instead of CoA. Which, in my very humble oppinion, is very much about RO? Alex From nemo-admin@nal.motlabs.com Mon Oct 28 12:50:03 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20817 for ; Mon, 28 Oct 2002 12:50:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SHp3C00603; Mon, 28 Oct 2002 18:51:03 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SHo5C00593 for ; Mon, 28 Oct 2002 18:50:05 +0100 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA06389; Mon, 28 Oct 2002 10:50:00 -0700 (MST)] Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA00232; Mon, 28 Oct 2002 10:49:59 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g9SHo0U14230; Mon, 28 Oct 2002 11:50:01 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8E86C2EC86; Mon, 28 Oct 2002 18:49:53 +0100 (CET) To: Takeshi TANAKA Cc: "Pascal Thubert (pthubert)" , IETF NEMO Subject: Re: [nemo] Route Optimization in Nemo References: <20021028150706.0A59.TAKESHI.TANAKA@yrp.mci.mei.co.jp> From: Alexandru Petrescu In-Reply-To: <20021028150706.0A59.TAKESHI.TANAKA@yrp.mci.mei.co.jp> Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 28 Oct 2002 18:49:53 +0100 Takeshi TANAKA writes: > For your "call for debate" in laying down the RO requirements, it is a > good idea. We will try to write down something concrete for futher > discussion in the mailing list. Yes, it's good to have a rough idea about what are the RO implications. And I'm also interested in looking into the RO requirements. If I were to start a document, I would start with defining the problem of RO before trying the requirements. For example a certain number of points of triangular routing could be feasible, but no more than n. So we first must know exactly what is "number of points of triangular routing". Me too I'm interested in that, but it's maybe for later. Alex From nemo-admin@nal.motlabs.com Mon Oct 28 13:05:34 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21504 for ; Mon, 28 Oct 2002 13:05:31 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SI74C01036; Mon, 28 Oct 2002 19:07:04 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SI6bC01026 for ; Mon, 28 Oct 2002 19:06:37 +0100 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA20924; Mon, 28 Oct 2002 11:06:30 -0700 (MST)] Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA11542; Mon, 28 Oct 2002 11:02:49 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id g9SI3Fi16834; Mon, 28 Oct 2002 12:03:16 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id D13892EC86; Mon, 28 Oct 2002 19:03:14 +0100 (CET) To: Takeshi TANAKA Cc: "Pascal Thubert (pthubert)" , IETF NEMO Subject: Re: [nemo] Route Optimization in Nemo References: <20021028150706.0A59.TAKESHI.TANAKA@yrp.mci.mei.co.jp> From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 28 Oct 2002 19:03:14 +0100 Alexandru Petrescu writes: > Takeshi TANAKA writes: > > For your "call for debate" in laying down the RO requirements, it is a > > good idea. We will try to write down something concrete for futher > > discussion in the mailing list. > > Yes, it's good to have a rough idea about what are the RO > implications. And I'm also interested in looking into the RO > requirements. If I were to start a document, I would start with > defining the problem of RO before trying the requirements. For > example a certain number of points of triangular routing could be > feasible, but no more than n. So we first must know exactly what is > "number of points of triangular routing". > > Me too I'm interested in that, but it's maybe for later. Sorry for following up on my own email. A good definition of the RO space is also about stating what are the non-RO implications to upper layers. For example, if MN uses TCP, and if sending packets through the HA to CN, but receiving packets straight from CN, then this very much looks like an "assymetric" link, and I think there was recently an iab draft on why it's not good for TCP to have assymetric links. I think this is also about RO, but again, for later, maybe I'm posting too much. Alex From nemo-admin@nal.motlabs.com Mon Oct 28 17:38:49 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02527 for ; Mon, 28 Oct 2002 17:38:35 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SMbOC02958; Mon, 28 Oct 2002 23:37:25 +0100 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9SMaTC02948 for ; Mon, 28 Oct 2002 23:36:30 +0100 Message-ID: <006401c27ed2$3402b5e0$6a6015ac@T23KEMPF> From: "James Kempf" To: "Takeshi TANAKA" , "Alexandru Petrescu" Cc: "Pascal Thubert \(pthubert\)" , "IETF NEMO" References: <20021028150706.0A59.TAKESHI.TANAKA@yrp.mci.mei.co.jp> Subject: Re: [nemo] Route Optimization in Nemo MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Oct 2002 14:25:57 -0800 Content-Transfer-Encoding: 7bit IMHO, security is *the* issue for Nemo RO. RR depends on the routing fabric, and with NEMO, the routing fabric is changing. jak From nemo-admin@nal.motlabs.com Mon Oct 28 23:49:02 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10591 for ; Mon, 28 Oct 2002 23:49:01 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9T4o7C04484; Tue, 29 Oct 2002 05:50:07 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9T4neC04470 for ; Tue, 29 Oct 2002 05:49:40 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A49B55D03A for ; Tue, 29 Oct 2002 13:49:19 +0900 (JST) Message-Id: <20021029.134919.50026499.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com From: Thierry Ernst X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Requirements Update Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 13:49:19 +0900 (JST) Content-Transfer-Encoding: 7bit Hi all, I've also updated my requirement draft with the new name: http://www.nal.motlabs.com/nemo/drafts/draft-ernst-nemo-requirements.txt Changes: - text has been much refined. - a section "Observation" takes much of what was previously in the terminology draft. (so, the terminology draft is now just about the terminology) - new section "Requirements for Basic Support" where I've itemized the requirements based on the discussion in the previous section. Those requirements are listed in the same fashion as proposed by Pascal Thubert a long time ago on the mailing list: clear short sentences. It's not a complete list - I've not included requirements proposed by other people, but I've expressed them in a way that should clarify my point of view on the case. At least that the objective. Don't forget that the terminology draft has also been re-structured: http://www.nal.motlabs.com/nemo/drafts/draft-ernst-nemo-terminology.txt Thierry From nemo-admin@nal.motlabs.com Tue Oct 29 02:42:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23977 for ; Tue, 29 Oct 2002 02:42:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9T7i3C05024; Tue, 29 Oct 2002 08:44:03 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9T7hnC05014 for ; Tue, 29 Oct 2002 08:43:49 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9T7gMjg018360; Tue, 29 Oct 2002 08:42:23 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 29 Oct 2002 08:43:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [nemo] Route Optimization in Nemo Message-ID: Thread-Topic: [nemo] Route Optimization in Nemo Thread-Index: AcJ+qnWIJtXyRfbmS9CePefXJk21TQAczHDg From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Takeshi TANAKA" , "Holger Kempf (hkempf)" Cc: "IETF NEMO" X-OriginalArrivalTime: 29 Oct 2002 07:43:25.0283 (UTC) FILETIME=[DCF8BB30:01C27F1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id g9T7hnC05014 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 07:43:24 -0000 Content-Transfer-Encoding: 8bit Hi Alex > If I were to start a document, I would start > with defining the problem of RO That's the draft I humbly started. Maybe that was unclear? My draft is elaborating on the taxonomy of the RO problem space, since it has multiple aspects in Nemo. Once this work is complete, I expect we'll be able to write a problem statement, in which security and AAA will be key issues. Then will be able to write requirements. What do you think? Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@crm.mot.com] > Sent: lundi 28 octobre 2002 18:50 > To: Takeshi TANAKA > Cc: Pascal Thubert (pthubert); IETF NEMO > Subject: Re: [nemo] Route Optimization in Nemo > > > Takeshi TANAKA writes: > > For your "call for debate" in laying down the RO > requirements, it is a > > good idea. We will try to write down something concrete for futher > > discussion in the mailing list. > > Yes, it's good to have a rough idea about what are the RO > implications. And I'm also interested in looking into the RO > requirements. If I were to start a document, I would start > with defining the problem of RO before trying the > requirements. For example a certain number of points of > triangular routing could be feasible, but no more than n. So > we first must know exactly what is "number of points of > triangular routing". > > Me too I'm interested in that, but it's maybe for later. > > Alex > > From nemo-admin@nal.motlabs.com Tue Oct 29 02:57:21 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24274 for ; Tue, 29 Oct 2002 02:57:20 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9T7x1C05083; Tue, 29 Oct 2002 08:59:01 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9T7wAC05073 for ; Tue, 29 Oct 2002 08:58:11 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 9A1F25D01E for ; Tue, 29 Oct 2002 16:58:03 +0900 (JST) Message-Id: <20021029.165803.25924246.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Subject: Re: [nemo] Route Optimization in Nemo From: Thierry Ernst In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 16:58:03 +0900 (JST) Content-Transfer-Encoding: 7bit > > If I were to start a document, I would start > > with defining the problem of RO This is tough. How to define the problem without basing the arguments on a solution ? If the argumentation is based on a solution, how are we sure we understand the problem space well enough ? > That's the draft I humbly started. Maybe that was unclear? My draft is > elaborating on the taxonomy of the RO problem space, since it has > multiple aspects in Nemo. Once this work is complete, I expect we'll be > able to write a problem statement, in which security and AAA will be key > issues. Then will be able to write requirements. From nemo-admin@nal.motlabs.com Tue Oct 29 04:45:28 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26241 for ; Tue, 29 Oct 2002 04:45:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9T9k6C06320; Tue, 29 Oct 2002 10:46:06 +0100 Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9T9jhC06309 for ; Tue, 29 Oct 2002 10:45:44 +0100 Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g9T9jVCG011071; Tue, 29 Oct 2002 18:45:33 +0900 (KST) Message-ID: <03c001c27f2f$ee3730a0$f529024b@athos> From: "JinHyeock Choi" To: , "Thierry Ernst" References: <20021028.131712.63244074.ernst@sfc.wide.ad.jp> Subject: Re: [nemo] Terminology Update MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id g9T9jhC06309 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 18:45:33 +0900 Content-Transfer-Encoding: 8bit Hi Thierry Here are some comments on your Terminology draft 1) I wonder how to define 'Mobile Network Prefix' for 'Nested Mobility' case. If Mobile Network is composed by only one IP-subnet, we can easily define Mobile Network Prefix as you defined in [Page 7] Mobile Network Prefix A bit string that consists of some number of initial bits of an IP address which identifies the entire mobile network within the Internet topology. All MNNs necessarily have an address named after this prefix. But in Nested Mobility case, parent-NEMO and sub-NEMO may have different Mobile Network Prefix. In that case, how would you define the Mobile Network Prefix for the aggregated Mobile Network? Can we make a definition such that all MNNs have an address named after that Mobile Network Prefix? 2) In [Page 7], Local Mobile Node (LMN) is defined like below Local Mobile Node (LMN) A mobile node (MN) or a mobile router (MR) that belongs to the mobile network (i.e. its home link is within the mobile network). But according to some people LMN is defined alternatively A mobile node that resides in mobile network and never leave that mobile network. Those two definitions are not same. For example, according to the first definition, 'LMN's HA can't be MR's Home Agent' as Alex explained. I think we should clarify it lest there should be confusion. 3) In [Page 11], multihomed is defined like below So, a mobile network is multihomed when either: - a MR has multiple egress interfaces on the same foreign link - a MR has multiple egress interfaces on distinct foreign link - there are more than one MR in the mobile network In the third line, how about change from 'more than one MR' to 'more than one TLMR'? In Nested Mobility case, some Mobile Network may have multiple MRs without being multihomed. I wish these comments are useful. Best Regards JinHyeock From nemo-admin@nal.motlabs.com Tue Oct 29 05:03:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26455 for ; Tue, 29 Oct 2002 05:03:20 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TA52C06459; Tue, 29 Oct 2002 11:05:02 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TA4sC06447 for ; Tue, 29 Oct 2002 11:04:54 +0100 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id DAA04252; Tue, 29 Oct 2002 03:04:52 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id DAA08583; Tue, 29 Oct 2002 03:01:11 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g9TA4kd06419; Tue, 29 Oct 2002 04:04:47 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id EABD52EC86; Tue, 29 Oct 2002 11:04:44 +0100 (CET) To: Thierry Ernst Cc: Subject: Re: [nemo] Route Optimization in Nemo References: <20021029.165803.25924246.ernst@sfc.wide.ad.jp> From: Alexandru Petrescu In-Reply-To: <20021029.165803.25924246.ernst@sfc.wide.ad.jp> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 29 Oct 2002 11:04:44 +0100 Thierry Ernst writes: > > > If I were to start a document, I would start > > > with defining the problem of RO > > This is tough. How to define the problem without basing the arguments > on a solution ? If the argumentation is based on a solution, how are > we sure we understand the problem space well enough ? So it's about iterarating between problems, potential solutions, back to problems and so on. Alex From nemo-admin@nal.motlabs.com Tue Oct 29 06:04:55 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27399 for ; Tue, 29 Oct 2002 06:04:53 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TB63C07845; Tue, 29 Oct 2002 12:06:03 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TB5PC07834 for ; Tue, 29 Oct 2002 12:05:25 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id D716B5D01E for ; Tue, 29 Oct 2002 19:33:11 +0900 (JST) Message-Id: <20021029.193311.89377553.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Subject: Re: [nemo] Terminology Update From: Thierry Ernst In-Reply-To: <03c001c27f2f$ee3730a0$f529024b@athos> References: <20021028.131712.63244074.ernst@sfc.wide.ad.jp> <03c001c27f2f$ee3730a0$f529024b@athos> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 19:33:11 +0900 (JST) Content-Transfer-Encoding: 7bit Dear JinHyeock, Interesting comments. Thank you. I think the nested case is tricky ... A MR of a mobile network becomes a TLMR when a sub-NEMO attaches to it. Do you think it's necessary to reflect that in the terminology ? If you have an idea to explain it easily, your definition is welcome ! > Here are some comments on your Terminology draft > > 1) I wonder how to define 'Mobile Network Prefix' for 'Nested Mobility' case. > If Mobile Network is composed by only one IP-subnet, we can easily define > Mobile Network Prefix as you defined in [Page 7] > > Mobile Network Prefix > > A bit string that consists of some number of initial bits of an IP > address which identifies the entire mobile network within the > Internet topology. All MNNs necessarily have an address named > after this prefix. > > But in Nested Mobility case, parent-NEMO and sub-NEMO may have different > Mobile Network Prefix. In that case, how would you define the Mobile Network > Prefix for the aggregated Mobile Network? Can we make a definition such that > all MNNs have an address named after that Mobile Network Prefix? For this one, I have the answer. Each mobile network in the nested mobile network has its own Mobile Network Prefix and keeps it. The MR of a sub-NEMO gets a COA with the prefix of its parent-NEMO. So, from the point of view of the TLMR, there is only one prefix. No need to care about prefixes down the hierarchy. At least this is what happens in Basic Support. In case of Extended Support, we may have to define new terms if this is not true anymore. > 2) In [Page 7], Local Mobile Node (LMN) is defined like below > > Local Mobile Node (LMN) > > A mobile node (MN) or a mobile router (MR) that belongs to the > mobile network (i.e. its home link is within the mobile network). (A) > But according to some people LMN is defined alternatively > > A mobile node that resides in mobile network and never leave that > mobile network. (B) > Those two definitions are not same. For example, according to the first > definition, 'LMN's HA can't be MR's Home Agent' as Alex explained. > I think we should clarify it lest there should be confusion. (C) (A) does not prevent (B). (B) is more restrictive. The problem you mention in (C) may require to refine the definition of LMN. As stated in the draft and on the mailing list, this is NOT a final definition. The definition may even not be necessary once we agree on the requirement. > > 3) In [Page 11], multihomed is defined like below > > So, a mobile network is multihomed when either: > - a MR has multiple egress interfaces on the same foreign link > - a MR has multiple egress interfaces on distinct foreign link > - there are more than one MR in the mobile network > > In the third line, how about change from 'more than one MR' to > 'more than one TLMR'? In Nested Mobility case, some Mobile Network > may have multiple MRs without being multihomed. From the perspective of nested mobile networks, what a MR is is tricky. 1. At first we have 2 mobile networks. Mobile networks is multihomed via 2 MRs. lx ______ Internet______________ ly | | | MR.1 ---MR.2.1 MR.2.2 | | | l1 ------ ---------- l2 2. What happens when MR.2.1. attaches to l1 ? - MR.2.1 becomes a subservient of MR.1 - MR.1 is the TLMR for the aggregated network - mobile_network_1 is the parent-NEMO (and also the root-NEMO) - mobile_network_2 is the sub-NEMO - mobile_network_2 is still multihomed to l1 and ly 2. What happens when MR.1 attaches to l2 ? - MR.1 becomes a subservient of MR.2.1 and MR.2.2. - MR.2.1 and MR.2.2 are the TLMRs - mobile_network_2 is the parent-NEMO (and also the root-NEMO) - mobile_network_1 is the sub-NEMO - the nested mobile network is multihomed So, may be I should include those examples. I don't see an issue in the definition. Do you think the definition should be clarified ? Thanks for reading the draft and discussing it. Thierry From nemo-admin@nal.motlabs.com Tue Oct 29 07:08:42 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00235 for ; Tue, 29 Oct 2002 07:08:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TCA2C08173; Tue, 29 Oct 2002 13:10:03 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TC9kC08158 for ; Tue, 29 Oct 2002 13:09:46 +0100 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id FAA26187; Tue, 29 Oct 2002 05:06:56 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA15227; Tue, 29 Oct 2002 05:09:42 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g9TC9cd16664; Tue, 29 Oct 2002 06:09:39 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9ED9B2EC86; Tue, 29 Oct 2002 13:09:37 +0100 (CET) To: Thierry Ernst Cc: Subject: Re: [nemo] Requirements Update References: <20021029.134919.50026499.ernst@sfc.wide.ad.jp> From: Alexandru Petrescu In-Reply-To: <20021029.134919.50026499.ernst@sfc.wide.ad.jp> Message-ID: Lines: 55 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 29 Oct 2002 13:09:37 +0100 Thierry Ernst writes: > I've also updated my requirement draft with the new name: > http://www.nal.motlabs.com/nemo/drafts/draft-ernst-nemo-requirements.txt Thierry, thank you for keeping your requirements draft updated. I have remarks related to R1-18 of the new section 4 Requirements for Basic Support. It's excellent to have them short and concentrated in one place of the draft, easier to discuss. Most of the requirements still look a bit high-level to me, but maybe that's what requirements are about, to be high-level and easy to understand. I'm trying to figure out whether it's possible to find a way to put requirements on other entities than the MR. For example, I agree with the definition of a VMN as being a Mobile IPv6 Mobile Node that comes into and leaves a mobile network. But I have difficulty in thinking that this is more than a definition, which you seem to imply, i.e. a requirement. Case in point is R4. The way in which the nemo-mrha (mobile network with bidir tunnel MR to HA) supports VMNs and LMNs is by having MNs that run vanilla Mobile IPv6 and that can move in two ways: (1) only internal to the mobile network, or (2) coming from outside, move inside the mobile network and then leave the mobile network. This can be accomplished by using vanilla Mobile IPv6 only, no need to distinguish LMN and VMN for more than a scenario discussion purpose. If we distinguish, one might be tempted into believing VMNs and LMNs will behave differently than a Mobile IPv6 MN. I might have lost something in this view, please correct me if I'm wrong. This is partly solved by R6, if I understand correctly, where it says that MNN's are not nemo-enabled. But then we must be sure that MR's are not part of MNN's; the current definition says that an MNN can be an MR, but MR's are clearly nemo-enabled. And we should solve the "MN" problem where the name "MN" stands for either MH and MR, while we are mostly accustomed to say "MN" for "MH" only. "R8: A VMN that gets attached to a link within the mobile network obtains an address on that link." is a requirement? If it does not obtain an address valid on that link then nothing works. Or maybe we should leave it there in order to be sure. R13, 14: please, why do you believe that horizontal and vertical handoffs must be supported? If those two are MUSTs then I would also suggest support of diagonal handoff is a MUST as well. Or maybe neither? For the rest of R's I'm mostly agreeing with them and I find they are more correctly formulated, and useful for designing an mrha solution. Alex From nemo-admin@nal.motlabs.com Tue Oct 29 07:32:37 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01045 for ; Tue, 29 Oct 2002 07:32:35 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TCY2C08283; Tue, 29 Oct 2002 13:34:02 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TCXqC08272 for ; Tue, 29 Oct 2002 13:33:52 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id OAA03865 for ; Tue, 29 Oct 2002 14:33:47 +0200 (EET) Received: from ele4114 (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with SMTP id OAA10680 for ; Tue, 29 Oct 2002 14:33:40 +0200 (EET) Message-ID: <006301c27f47$d4d9e310$725ebc82@ELE4114.ele.vtt.fi> From: "=?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?=" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01C27F58.96AAA2D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [nemo] IPv6 prefix delegation Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 14:36:38 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C27F58.96AAA2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CN | --------------- ( Internet )--HA=20 --------------- | AR linkX/prefix X = =20 | MR2-------------------MN2=20 | link1/prefix1 |=20 MR1 =20 | | link2/prefix 2 | MN1 =20 Hi all. =20 Please consider the above picture. MR2 and MN2 on linkX want to = establish a NEMO-network (consists of MR2 and MN2).=20 It is assumed that MR2 needs to dynamically get a IPv6 prefix X for the = NEMO, because the NEMO-network is created in an ad-hoc way. When this new NEMO is created and attached to Internet via AR or MR1 the = following questions arise:=20 1.) Where will the IPv6 prefix for the NEMO be received from? From AR, = HA or MR1 or some other network entity? 2.) What are the protocol requirements for IPv6 prefix delegation in a = NEMO environment?=20 3.) Do we need IPv6 prefix delegation for NEMO environment? The picture = suggests yes, because no IPv6 prefix has been initially allocated for = the NEMO. Should these issues be concerned with in the requirements related to = NEMO? Pekka P=E4=E4kk=F6nen ------=_NextPart_000_0060_01C27F58.96AAA2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
          &nbs= p;       =20 CN
          &nbs= p;        =20 |
          &nbs= p;   =20 ---------------
          &nbs= p;  ( =20 Internet    )--HA
          &nbs= p;   =20 ---------------
          &nbs= p;       =20 |
          &nbs= p;      =20 AR            = ;            =    linkX/prefix=20 X            =      
          &nbs= p;       =20 |            =            =20 MR2-------------------MN2
          &nbs= p;       =20 | link1/prefix1
          &nbs= p;       =20 | 
          &nbs= p;      =20 MR1           &nbs= p;  =20
          &nbs= p;       =20 |
          &nbs= p;       =20 | link2/prefix 2
          &nbs= p;       =20 |
          &nbs= p;      =20 MN1
          &nbs= p;    =20
Hi=20 all.           &nb= sp;           &nbs= p;      =20
Please consider the above picture. MR2 and MN2 on = linkX want=20 to establish a NEMO-network (consists of MR2 and MN2). =
It is assumed that MR2 needs to dynamically get = a IPv6=20 prefix X for the NEMO, because the NEMO-network is created in an = ad-hoc=20 way.
When this new NEMO is created and attached to = Internet=20 via AR or MR1 the following questions arise:
 
1.) Where will the IPv6 prefix for the NEMO be = received=20 from? From AR, HA or MR1 or some other network entity?
 
2.) What are the protocol requirements for IPv6 = prefix=20 delegation in a NEMO environment?
 
3.) Do we need IPv6 prefix delegation for NEMO = environment?=20 The picture suggests yes, because no IPv6 prefix has been initially = allocated=20 for the NEMO.
 
 
Should these issues be concerned with = in the=20 requirements related to NEMO?
 
 
Pekka P=E4=E4kk=F6nen
 
------=_NextPart_000_0060_01C27F58.96AAA2D0-- From nemo-admin@nal.motlabs.com Tue Oct 29 08:29:37 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02840 for ; Tue, 29 Oct 2002 08:29:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TDS5C08566; Tue, 29 Oct 2002 14:28:06 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TDRlC08554 for ; Tue, 29 Oct 2002 14:27:47 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9TDPdHP000937; Tue, 29 Oct 2002 14:26:25 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 29 Oct 2002 14:27:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27F4E.F1A42ADA" Subject: RE: [nemo] IPv6 prefix delegation Message-ID: Thread-Topic: [nemo] IPv6 prefix delegation Thread-Index: AcJ/SInNi6rtAsJxRtCy24202jyLxQABadKQ From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?= , X-OriginalArrivalTime: 29 Oct 2002 13:27:36.0649 (UTC) FILETIME=[F2251B90:01C27F4E] Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 13:27:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C27F4E.F1A42ADA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IMHO, the questions are definitively valid for Nemo, even non nested. = There are related issues being discussed at DHCPv6, for instance = subnetting, that could be of some specific interest for Nemo.=20 =20 For Basic, I'm not sure if we include that?=20 =20 Pascal -----Original Message----- From: Pekka P=E4=E4kk=F6nen [mailto:Pekka.Paakkonen@vtt.fi]=20 Sent: mardi 29 octobre 2002 13:37 To: nemo@nal.motlabs.com Subject: [nemo] IPv6 prefix delegation =20 CN | --------------- ( Internet )--HA=20 --------------- | AR linkX/prefix X = =20 | MR2-------------------MN2=20 | link1/prefix1 |=20 MR1 =20 | | link2/prefix 2 | MN1 =20 Hi all. =20 Please consider the above picture. MR2 and MN2 on linkX want to = establish a NEMO-network (consists of MR2 and MN2).=20 It is assumed that MR2 needs to dynamically get a IPv6 prefix X for the = NEMO, because the NEMO-network is created in an ad-hoc way. When this new NEMO is created and attached to Internet via AR or MR1 the = following questions arise:=20 =20 1.) Where will the IPv6 prefix for the NEMO be received from? From AR, = HA or MR1 or some other network entity? =20 2.) What are the protocol requirements for IPv6 prefix delegation in a = NEMO environment?=20 =20 3.) Do we need IPv6 prefix delegation for NEMO environment? The picture = suggests yes, because no IPv6 prefix has been initially allocated for = the NEMO. =20 =20 Should these issues be concerned with in the requirements related to = NEMO? =20 =20 Pekka P=E4=E4kk=F6nen =20 ------_=_NextPart_001_01C27F4E.F1A42ADA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
IMHO,=20 the questions are definitively valid for Nemo, even non nested. There = are=20 related issues being discussed at DHCPv6, for instance subnetting, that = could be=20 of some specific interest for Nemo.
 
For=20 Basic, I'm not sure if we include that?
 
Pascal
-----Original Message-----
From: = Pekka P=E4=E4kk=F6nen=20 [mailto:Pekka.Paakkonen@vtt.fi]
Sent: mardi 29 octobre 2002 = 13:37
To: nemo@nal.motlabs.com
Subject: [nemo] = IPv6 prefix=20 delegation

 
          &nbs= p;       =20 CN
          &nbs= p;        =20 |
          &nbs= p;   =20 ---------------
          &nbs= p;  ( =20 Internet    )--HA
          &nbs= p;   =20 ---------------
          &nbs= p;       =20 |
          &nbs= p;      =20 = AR            = ;            =    linkX/prefix=20 = X            =      
          &nbs= p;       =20 = |            =            =20 MR2-------------------MN2
          &nbs= p;       =20 | link1/prefix1
          &nbs= p;       =20 | 
          &nbs= p;      =20 = MR1           &nbs= p;  =20
          &nbs= p;       =20 |
          &nbs= p;       =20 | link2/prefix 2
          &nbs= p;       =20 |
          &nbs= p;      =20 MN1
          &nbs= p;    =20
Hi=20 = all.           &nb= sp;           &nbs= p;      =20
Please consider the above picture. MR2 and MN2 on = linkX want=20 to establish a NEMO-network (consists of MR2 and MN2). =
It is assumed that MR2 needs to = dynamically get a IPv6=20 prefix X for the NEMO, because the NEMO-network is created in an = ad-hoc=20 way.
When this new NEMO is created and attached to = Internet=20 via AR or MR1 the following questions arise:
 
1.) Where will the IPv6 prefix for the NEMO = be received=20 from? From AR, HA or MR1 or some other network entity?
 
2.) What are the protocol requirements for IPv6 = prefix=20 delegation in a NEMO environment?
 
3.) Do we need IPv6 prefix delegation for NEMO = environment?=20 The picture suggests yes, because no IPv6 prefix has been initially = allocated=20 for the NEMO.
 
 
Should these issues be concerned with = in the=20 requirements related to NEMO?
 
 
Pekka P=E4=E4kk=F6nen
 
------_=_NextPart_001_01C27F4E.F1A42ADA-- From nemo-admin@nal.motlabs.com Tue Oct 29 09:43:06 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06069 for ; Tue, 29 Oct 2002 09:42:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TEf9C09188; Tue, 29 Oct 2002 15:41:12 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TEe2C09176 for ; Tue, 29 Oct 2002 15:40:04 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id g9TEdWnM021107; Tue, 29 Oct 2002 07:39:32 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA20271; Tue, 29 Oct 2002 07:35:51 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g9TEdXU21896; Tue, 29 Oct 2002 08:39:34 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 41BD32EC86; Tue, 29 Oct 2002 15:39:26 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: "Takeshi TANAKA" , "Holger Kempf (hkempf)" , "IETF NEMO" Subject: Re: [nemo] Route Optimization in Nemo References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 56 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 29 Oct 2002 15:39:26 +0100 "Pascal Thubert (pthubert)" writes: > > If I were to start a document, I would start > > with defining the problem of RO > > That's the draft I humbly started. Maybe that was unclear? No no that was clear, and thank you for starting it at this early time. I read it, so there's at least one reader. I also read RRH and I'm going to describe it in a technical report as well. (then somebody else can describe my description and so on). Frankly speaking, my problem is that the draft is already started and it already has a certain flavor. It has the tunnel nestedness and the RRH bias. If I were to start, I would start with the simplest common denominator of all that's been discussed, something simple and easy to understand, nothing new, no innovation. Define "triangle routing", "dog-leg routing", RO, and their origins. Make a few sketches with the classic Mobile IPv6 RO problem, then add the mrha thingie, and then see another sketch with several HAs and so on. Then I would describe a practical case when RO is bad for when I go to a conference and all my communication goes to home (because I use VPN). Then I would describe an exemple with practical case where RO-less Mobile IPv6 can be bad for TCP. Then I would indicate to the reader that those two problems are even worse when the triangle has more than three corners (several HA's). Then I would talk about nested mobile networks, with multi-homing, where there are sketches with paths that are shortest than what nemo-mrha proposes. (you touch briefly the nested RO need). Remark no new solution proposed, no talk about DHCP, prefix delegation, no RRH, no HoTI/CoTI, no DSR, no too high bandwidth consumption (how high?), no CR (Correspondent-side Router, Core Router, FA?). That makes up a table of contents, with a little bit of contents too. Then I would reserve more than 15 minutes for formatting before the deadline. That's what my approach would be but it is most certainly different than anyone else's who would have decided to start such a document. So please take it as my humble oppinion only; and also as a statement that maybe I won't write such a document :-) Thanks, Alex From nemo-admin@nal.motlabs.com Tue Oct 29 11:02:52 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10554 for ; Tue, 29 Oct 2002 11:02:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TG0CC10091; Tue, 29 Oct 2002 17:00:12 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TFxAC09907 for ; Tue, 29 Oct 2002 16:59:12 +0100 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA06663 for ; Tue, 29 Oct 2002 08:58:51 -0700 (MST)] Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA19768 for ; Tue, 29 Oct 2002 08:58:50 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id g9TFwjH30829; Tue, 29 Oct 2002 09:58:46 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3DDAA2EC8B; Tue, 29 Oct 2002 16:58:43 +0100 (CET) To: "James Kempf" Cc: "Takeshi TANAKA" , "Pascal Thubert (pthubert)" , "IETF NEMO" Subject: Re: [nemo] Route Optimization in Nemo References: <20021028150706.0A59.TAKESHI.TANAKA@yrp.mci.mei.co.jp> <006401c27ed2$3402b5e0$6a6015ac@T23KEMPF> From: Alexandru Petrescu In-Reply-To: <006401c27ed2$3402b5e0$6a6015ac@T23KEMPF> Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 29 Oct 2002 16:58:43 +0100 "James Kempf" writes: > IMHO, security is *the* issue for Nemo RO. RR depends on the routing > fabric, and with NEMO, the routing fabric is changing. Aha, that is well said, the routing fabric seems to be changing, because mobile networks nest one under the other and as such, the deepest mobile network will have a set of mobile networks above it before reaching the fixed infrastructure. And that set of mobile networks are changing. And, while with the current RR tests an MH can think that paths are secure, in nested mobility the deepest MR can not be sure that one middle-level mobile network is trustful. But if I assume that every MR in this nested structure has done AAA before obtaining connectivity, then the deepest MR will have less reason to worry. But yes, IMHO too, RR tests and security are important issues for NEMO RO for the fact that the normal RR is assuming the CoA and the HoA are in the same machine (MH), and in the NEMO case, the CoA is of MR and the HoA is of an LFN, so LFN and MR must trust each other. What do you think? Alex From nemo-admin@nal.motlabs.com Tue Oct 29 12:06:46 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14088 for ; Tue, 29 Oct 2002 12:06:38 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TH57C11065; Tue, 29 Oct 2002 18:05:07 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9TH4QC11051 for ; Tue, 29 Oct 2002 18:04:30 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id g9TH4ArI003200 for ; Tue, 29 Oct 2002 10:04:13 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA22247 for ; Tue, 29 Oct 2002 10:04:10 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g9TH4DU15001; Tue, 29 Oct 2002 11:04:14 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E2E112EC86; Tue, 29 Oct 2002 18:04:05 +0100 (CET) To: "Pekka =?iso-8859-1?q?P=E4=E4kk=F6nen?=" Cc: Subject: Re: [nemo] IPv6 prefix delegation References: <006301c27f47$d4d9e310$725ebc82@ELE4114.ele.vtt.fi> From: Alexandru Petrescu In-Reply-To: <006301c27f47$d4d9e310$725ebc82@ELE4114.ele.vtt.fi> Message-ID: Lines: 71 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id g9TH4QC11051 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 29 Oct 2002 18:04:05 +0100 Content-Transfer-Encoding: 8bit "Pekka Pääkkönen" writes: > CN > | > --------------- > ( Internet )--HA > --------------- > | > AR linkX/prefix X > | MR2-------------------MN2 > | link1/prefix1 > | > MR1 > | > | link2/prefix 2 > | > MN1 Good picture. > Hi all. > Please consider the above picture. MR2 and MN2 on linkX want to > establish a NEMO-network (consists of MR2 and MN2). It is assumed > that MR2 needs to dynamically get a IPv6 prefix X for the NEMO, > because the NEMO-network is created in an ad-hoc way. That's a nice statement, but if it is done in an ad-hoc way, then I believe it's a manet problem, not a NEMO problem. I think we can see it as a NEMO problem only if we want MN2 to get a new CoA once MR2 had attached under MR1, but I thought this will not happen and MN2 will not have to deal with any form of mobility (I assume that's why you attached MN2 to MR2, presumably like an LFN). > When this new NEMO is created and attached to Internet via AR or MR1 > the following questions arise: > > 1.) Where will the IPv6 prefix for the NEMO be received from? From > AR, HA or MR1 or some other network entity? So it's assumed that a mobile network will receive a new prefix (instead of a CoA), let's say a CoP (Care-of Prefix) when it moves. This might be very useful for RO. This might be done with Router Renumbering as well. This might be done with other routing protocols as well. > 2.) What are the protocol requirements for IPv6 prefix delegation in > a NEMO environment? Off the top of my head: security requirements. > 3.) Do we need IPv6 prefix delegation for NEMO environment? The > picture suggests yes, because no IPv6 prefix has been initially > allocated for the NEMO. Initially, there's a prefix allocated to the mobile network when the mobile network is at home. Let's call it MNP (mobile network prefix). The mobile network can continue to use this MNP wherever it moves, and only the MR will obtain a CoA (not a CoP). The MR maintains a bidirectional tunnel with the HA through which all communication of LFNs goes. This has obvious inconvenients like multiple tunnels when nested nets (for which RRH is a solution), or lack of RO with the CN and so on. These drawbacks should be described somewhere. But inspite of these obvious drawbacks it still offers a solution for mobile networks, nested nets, with minimal modifications to Mobile IPv6. Looks like a good first step. > Should these issues be concerned with in the requirements related to > NEMO? I think yes, in the NEMO RO requirements case. Alex From nemo-admin@nal.motlabs.com Tue Oct 29 12:31:55 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15350 for ; Tue, 29 Oct 2002 12:31:47 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9THV6C11196; Tue, 29 Oct 2002 18:31:06 +0100 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9THUKC11186 for ; Tue, 29 Oct 2002 18:30:22 +0100 Message-ID: <004d01c27f70$9d5233b0$656015ac@T23KEMPF> From: "James Kempf" To: , "Thierry Ernst" References: <20021028.131712.63244074.ernst@sfc.wide.ad.jp> <03c001c27f2f$ee3730a0$f529024b@athos> Subject: Re: [nemo] Terminology Update MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 09:28:34 -0800 Content-Transfer-Encoding: 7bit Thierry, As you may be aware, the Seamoby WG currently has a WG draft on its charter that consolidates mobility related terms in the IETF. The draft is meant to be a way for draft authors of mobility-related drafts to avoid the extensive terminology section at the beginning, and provide a reference to normalize references to mobility-related terms. Would you be interested in merging your terminology draft in with the Seamoby draft? I think it would be extremely useful to have the mobile network terms together with the rest of the mobility-related terms. jak From nemo-admin@nal.motlabs.com Tue Oct 29 22:24:11 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06213 for ; Tue, 29 Oct 2002 22:24:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9U3ODC17152; Wed, 30 Oct 2002 04:24:13 +0100 Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9U3NsC17142 for ; Wed, 30 Oct 2002 04:23:55 +0100 Received: by bulls.mei.co.jp (8.12.5/3.7W/bulls) with ESMTP id g9U3NXmP014085; Wed, 30 Oct 2002 12:23:33 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id g9U3NXj10652; Wed, 30 Oct 2002 12:23:33 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id g9U3NV829918; Wed, 30 Oct 2002 12:23:31 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:02091217) id g9U3NV512910; Wed, 30 Oct 2002 12:23:31 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.11.3/3.7W-GW1) with ESMTP id g9U3NPP19283; Wed, 30 Oct 2002 12:23:25 +0900 (JST) Received: from [133.183.211.98] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7W-TELECOM) with ESMTP id g9U3NUn29853; Wed, 30 Oct 2002 12:23:30 +0900 (JST) From: Takeshi TANAKA To: "Pascal Thubert (pthubert)" , IETF NEMO Subject: Re: [nemo] Route Optimization in Nemo In-Reply-To: References: Message-Id: <20021030115139.A84B.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Oct 2002 12:27:04 +0900 Content-Transfer-Encoding: 7bit Hi Pascal, Sorry for late reply, At Mon, 28 Oct 2002 09:17:33 -0000 "Pascal Thubert (pthubert)" wrote : > > -----Original Message----- > > From: Takeshi TANAKA [mailto:Takeshi.Tanaka@yrp.mci.mei.co.jp] > > Sent: lundi 28 octobre 2002 08:10 > > To: Pascal Thubert (pthubert); IETF NEMO > > Subject: Re: [nemo] Route Optimization in Nemo > > > > > > Hi Pascal, > > > > We are also interested in the RO problem of NEMO especially > > in nested case. We see that nested mobile nodes is > > inevitable in a practical world deployment scenario. > > > > First of, some comments on your RO-Taxonomy draft: > > > > > 2.1 Nested tunnels optimization > > > Such a solution introduces the following problems: > > > "Pinball" routing ... > > > Packet size ... > > > > I think the problem of nested tunnels can be further broken > > down into: "pinball" routing > > - HA/MR processing resources consumption > > - increased latency > > increased in packet size > > - wireless link bandwidth consumption > > - network resource consumption > > - more packet fragmentation(by each termination) > > > Sure ! Depending on the environment and the implementation, the gating > factor may not be the same in all cases. > > > > > The potential approaches for avoiding the nesting of > > tunnels include: > > > Route Aggregation ... Surrogate ... > > > Internal Routing and gateway ... > > > RRH ... > > Routing header can be used to avoid problems you listed, but > > I think naming the paragraph RRH is putting adding > > presumptions on the method of constructing the Routing > > Header, since there could be other method to collect > > information needed to construct routing header. > > > > Agreed, I'll fix that. RRH could be listed as an example but it's not a > category. I'm not sure how to describe the category, though, and I > expect more discussion when I do, since I mean to differentiate from a > MANET based source routing. What do you think of "standard based source > routing"? Note that the RRH draft presents RRH as an IPv6 header, not a > MIP thing. Then the draft shows how that header could be used by MIP, > though the usage is not restricted to MIP. We thought that category is for a solution that uses Routing Header that can contain multiple addresses to avoid a path that goes through all HAs, and yes I agree to call that category as "standard based source routing". > > > 3. MR-to-CN > > > ... > > > accept the risk. If not, the optimization may be limited to > > > triangular routing MR->CN->HA->MR. ... > > I think packet delivery path in this case will not be a > > triangular routing(MR->CN->HA->MR), but "dog-leg" routing > > (MR->HA->CN, CN->HA->MR). > > > > Not sure: The MR can encapsulate packets to the CN instead of the home > agent, potentially at the expense of IPSec. The CN has to support the > encapsulation and it may accept to forward the inner packets even if it > does not trust the MR enough to optimize the reverse direction. This may > defeat ingress filtering, but then it's a matter of policy. Be prepared > for a long debate :) I misunderstood that "If not, the optimization..." means "If we do not modify CN behavior, the optimization", now understand. > > > 6. Conclusion > > > ...MIPv6 seems to be...more difficult to probide a Nemo > > solution with > > > backward compatibility, since: ... > > > 2) The RR test has no negotiable option and is not open for > > extension, > > What does this sentence mean? > > In MIPv6 draft #18, each messages in RR test can contain some > > mobility option field. These option fields can be used to > > carry other information. In addition, we can modify the way > > each cookie is generated at CN side if necessary. > > > > OK, I'm being crytic again. I was talking about the RR and CN as > described by MIP. Options give you additional information but there's no > such thing as a completion code or negotiation in RR test. As you > mention, we will have to modify the CN again. The MIP CN is already a > burden, I wonder how difficult it will be to add our stuff into it. We > could have coped with a simple generic negociation like triangular > yes-no, CareOf yes-no... Which could have been beneficial to MIP as > well. > > I tried a few things on the MIP list. Please see 'CoT' and the 'HAO, BE > processing' discussions in July (some appended). I understand it's not a > priority and they want to close the debate, our cost. Same for the HaO, > we would need a CN change to make it multihop. At that point, I believe > that a RH is better ;) > > > For your "call for debate" in laying down the RO > > requirements, it is a good idea. We will try to write down > > something concrete for futher discussion in the mailing list. > > > > :) > > > On a side note, we think there wont be any time slots for > > discussion about RO solutions in the upcoming IETF meeting, > > but if we can laid down some set of requirements for RO, > > perhaps we can request for a time slot to discuss the problem > > scope of RO? > > > > Agreed, and it's up to the chairmen to do the first thing first. There's > this debate about the requirements for the basic Nemo that will take a > long time in the Agenda. I believe that understanding RO is important > for the design of Basic, but I agree it's not necessarily needed to > establish the requirements. > > Yet, since some of us are industrials, we can't wait 2 years to have > everything done by the book. If Nemo is too slow, I'm sure companies > will come up with proprietary solutions for the interim, at a cost; so > it's beneficial to start this thread already, even if it means a very > short entry in the Agenda, and offline meetings in Atlanta. > > Will you be there? Yes, will be there with Chan Wah. ----------------------------------------------- Takeshi TANAKA Wireless Solution Laboratories, Panasonic e-mail: Takeshi.Tanaka@yrp.mci.mei.co.jp phone: +81-468-40-5494 / fax: +81-468-40-5183 ----------------------------------------------- From nemo-admin@nal.motlabs.com Wed Oct 30 04:06:04 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06313 for ; Wed, 30 Oct 2002 04:06:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9U977C18400; Wed, 30 Oct 2002 10:07:07 +0100 Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9U966C18389 for ; Wed, 30 Oct 2002 10:06:06 +0100 Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g9U95qCG013836; Wed, 30 Oct 2002 18:05:58 +0900 (KST) Message-ID: <00cd01c27ff3$921e8790$f529024b@athos> From: "JinHyeock Choi" To: , "Thierry Ernst" References: <20021028.131712.63244074.ernst@sfc.wide.ad.jp><03c001c27f2f$ee3730a0$f529024b@athos> <20021029.193311.89377553.ernst@sfc.wide.ad.jp> Subject: Re: [nemo] Terminology Update MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id g9U966C18389 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Oct 2002 18:05:55 +0900 Content-Transfer-Encoding: 8bit Dear Thierry > I think the nested case is tricky ... A MR of a mobile network becomes > a TLMR when a sub-NEMO attaches to it. Do you think it's necessary to > reflect that in the terminology ? If you have an idea to explain it > easily, your definition is welcome ! Yes, I agree. How about define the terms like 'parent-MR' or 'sub-MR'. Those definitions might be useful to describe nested cases. > For this one, I have the answer. > > Each mobile network in the nested mobile network has its own Mobile > Network Prefix and keeps it. The MR of a sub-NEMO gets a COA with the > prefix of its parent-NEMO. So, from the point of view of the TLMR, > there is only one prefix. No need to care about prefixes down the > hierarchy. At least this is what happens in Basic Support. So parent-NEMO and sub-NEMO may have entirely different Mobile Network Prefix. According to your definition, 'all MNNs necessarily have an address named after Mobile Prefix'. I guess that mean 'all MNNs which are directly attached to MR's ingress interface'. Your define Mobile Network Prefix with respect to Mobile Network. Instead how about define Mobile Network Prefix with respect to Mobile Router like 'prefix assigned to ingress interface of Mobile Router'? > > 2) In [Page 7], Local Mobile Node (LMN) is defined like below > > > > Local Mobile Node (LMN) > > > > A mobile node (MN) or a mobile router (MR) that belongs to the > > mobile network (i.e. its home link is within the mobile network). > > (A) > > > But according to some people LMN is defined alternatively > > > > A mobile node that resides in mobile network and never leave that > > mobile network. > > (B) > > > Those two definitions are not same. For example, according to the first > > definition, 'LMN's HA can't be MR's Home Agent' as Alex explained. > > I think we should clarify it lest there should be confusion. > > (C) > > (A) does not prevent (B). (B) is more restrictive. (B) doesn't imply (A). Assume there is a mobile node such that it never leave a mobile network but its home link is outside that mobile network. That node satisfies (B) but doesn't satisfy (A). Can we preclude such cases? And (A) doesn't imply (B) either. > From the perspective of nested mobile networks, what a MR is is > tricky. > > 1. At first we have 2 mobile networks. Mobile networks is multihomed via > 2 MRs. > > > lx ______ Internet______________ ly > | | | > MR.1 ---MR.2.1 MR.2.2 > | | | > l1 ------ ---------- l2 > > > 2. What happens when MR.2.1. attaches to l1 ? > > - MR.2.1 becomes a subservient of MR.1 > - MR.1 is the TLMR for the aggregated network > - mobile_network_1 is the parent-NEMO (and also the root-NEMO) > - mobile_network_2 is the sub-NEMO > - mobile_network_2 is still multihomed to l1 and ly > > 2. What happens when MR.1 attaches to l2 ? > - MR.1 becomes a subservient of MR.2.1 and MR.2.2. > - MR.2.1 and MR.2.2 are the TLMRs > - mobile_network_2 is the parent-NEMO (and also the root-NEMO) > - mobile_network_1 is the sub-NEMO > - the nested mobile network is multihomed > > So, may be I should include those examples. > > I don't see an issue in the definition. Do you think the definition > should be clarified ? Assuem a case which you described in Figure 5 of your draft. That Mobile Network is composed by one parent-NEMO and one sub-NEMO. And each NEMO has only one MR. That Mobile Network is not multi-homed but has two MRs. According to your draft, if there are more than one MR in the mobile network, it is multi-homed. I think what you mean is 'if there are more than one MR which is attached to fixed Internet.'. I may be too scrupulous but tried to interpret your definition literally and found some difficulties. Best Regards JinHyeock From nemo-admin@nal.motlabs.com Wed Oct 30 06:27:29 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09596 for ; Wed, 30 Oct 2002 06:27:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9UBT3C20966; Wed, 30 Oct 2002 12:29:03 +0100 Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9UBSNC20955 for ; Wed, 30 Oct 2002 12:28:23 +0100 Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g9UBS7CG009189; Wed, 30 Oct 2002 20:28:16 +0900 (KST) Message-ID: <01d801c28007$72c7fa70$f529024b@athos> From: "JinHyeock Choi" To: =?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?= , "Alexandru Petrescu" Cc: References: <006301c27f47$d4d9e310$725ebc82@ELE4114.ele.vtt.fi> Subject: Re: [nemo] IPv6 prefix delegation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id g9UBSNC20955 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Oct 2002 20:28:09 +0900 Content-Transfer-Encoding: 8bit Hi > "Pekka Pääkkönen" writes: > > CN > > | > > --------------- > > ( Internet )--HA > > --------------- > > | > > AR linkX/prefix X > > | MR2-------------------MN2 > > | link1/prefix1 > > | > > MR1 > > | > > | link2/prefix 2 > > | > > MN1 > > Good picture. Yes. It's difficult for me to draw a picture for mailing list. > > Hi all. > > Please consider the above picture. MR2 and MN2 on linkX want to > > establish a NEMO-network (consists of MR2 and MN2). It is assumed > > that MR2 needs to dynamically get a IPv6 prefix X for the NEMO, > > because the NEMO-network is created in an ad-hoc way. > > That's a nice statement, but if it is done in an ad-hoc way, then I > believe it's a manet problem, not a NEMO problem. I think we can see > it as a NEMO problem only if we want MN2 to get a new CoA once MR2 had > attached under MR1, but I thought this will not happen and MN2 will > not have to deal with any form of mobility (I assume that's why you > attached MN2 to MR2, presumably like an LFN). I agree. MN2 even may not recognize that it has moved at all. > > When this new NEMO is created and attached to Internet via AR or MR1 > > the following questions arise: > > > > 1.) Where will the IPv6 prefix for the NEMO be received from? From > > AR, HA or MR1 or some other network entity? > > So it's assumed that a mobile network will receive a new prefix > (instead of a CoA), let's say a CoP (Care-of Prefix) when it moves. > This might be very useful for RO. This might be done with Router > Renumbering as well. This might be done with other routing protocols > as well. In basic support, only Mobile Router have to receive CoA in foreign network. Mobile Network doesn't have to receive prefix (Care-of Prefix). But I agree that it will be useful for RO if Mobile Network get a CoP in foreign network. > > 2.) What are the protocol requirements for IPv6 prefix delegation in > > a NEMO environment? > > Off the top of my head: security requirements. > > > 3.) Do we need IPv6 prefix delegation for NEMO environment? The > > picture suggests yes, because no IPv6 prefix has been initially > > allocated for the NEMO. > > Initially, there's a prefix allocated to the mobile network when the > mobile network is at home. Let's call it MNP (mobile network prefix). > The mobile network can continue to use this MNP wherever it moves, and > only the MR will obtain a CoA (not a CoP). The MR maintains a > bidirectional tunnel with the HA through which all communication of > LFNs goes. This has obvious inconvenients like multiple tunnels when > nested nets (for which RRH is a solution), or lack of RO with the CN > and so on. These drawbacks should be described somewhere. But > inspite of these obvious drawbacks it still offers a solution for > mobile networks, nested nets, with minimal modifications to Mobile > IPv6. Looks like a good first step. Exactly. MNP is configured to the ingress interface of MR and remains same regardless of MR's movement. > > Should these issues be concerned with in the requirements related to > > NEMO? > > I think yes, in the NEMO RO requirements case. > > Alex JinHyeock From nemo-admin@nal.motlabs.com Wed Oct 30 23:13:15 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25246 for ; Wed, 30 Oct 2002 23:13:11 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9V4DDC25589; Thu, 31 Oct 2002 05:13:15 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9V4CmC25579 for ; Thu, 31 Oct 2002 05:12:50 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 00A8A5D0A5; Thu, 31 Oct 2002 13:12:35 +0900 (JST) Message-Id: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Cc: tj@kniveton.com From: Thierry Ernst X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Launching Requirement Discussion Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 31 Oct 2002 13:12:34 +0900 (JST) Content-Transfer-Encoding: 7bit Dear all, It seems that we have a couple of new/updated drafts to discuss the requirements, but I haven't seen an announcement from all the authors, so I'm not sure about what is on the table. So far, I have seen: draft-ernst-nemo-requirements-00.txt draft-ng-nemo-aaa-use-00.txt draft-janneteau-nemo-requirements-00.txt draft-sarikaya-nemo-archreqs-00.txt Is anything missing from this list ? I haven't seen an update of TJ's. Anyway, may I ask all people interested in clearing up the requirements to read the drafts and to figure out what are their commonalities and divergences and comment on what is new, what is still not clear, and what is missing ? So far, draft-ng-nemo-aaa has interesting new input about access control; I haven't read the other drafts yet. At the meeting, we will have someone to report the results of the discussion on the requirements, so you should better all express your views now, before everything is put in shape, hopefully before the meeting. Thierry From nemo-admin@nal.motlabs.com Thu Oct 31 03:34:55 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10368 for ; Thu, 31 Oct 2002 03:34:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9V8XLC26568; Thu, 31 Oct 2002 09:33:24 +0100 Received: from web10001.mail.yahoo.com (web10001.mail.yahoo.com [216.136.130.37]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id g9V8WmC26558 for ; Thu, 31 Oct 2002 09:32:49 +0100 Message-ID: <20021031083238.11348.qmail@web10001.mail.yahoo.com> Received: from [202.224.189.50] by web10001.mail.yahoo.com via HTTP; Thu, 31 Oct 2002 00:32:38 PST From: ChanWah Ng Reply-To: cwng@psl.com.sg To: nemo@nal.motlabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nemo] draft-ng-nemo-access-router-option-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 31 Oct 2002 00:32:38 -0800 (PST) Hi all, We have published a draft on a proposal for overcoming the Nested-Tunnel Optimization. This draft introduces an access router option in BU messages, allowing MR to inform their HA the global address of the NEMO-enabled AR the MR is attached to. If the AR is also mobile, the global address will be the HoA of the mobile AR. Using this, the HA can now independently construct an extended RH2 (as proposed by Pascal et al) instead of relying on RRH (again, proposed by Pascal et al). It is difficult to establish the legitmacy of a RRH, we hope the access router option will provide a means to reduce the security threats in constructing extended RH2. We understand that RO is not the focus of the working group at the moment, but we do believe that there are parties interested enough to look at developing RO solutions in parallel to basic, so that when the time comes for the WG to look at RO, a reasonably well thought out solution is already available. We thus invite interested party to comment on the draft. You can find the draft at any of the following URL: http://www.nal.motlabs.com/nemo/drafts/draft-ng-nemo-access-router-option.txt http://www.psl.com.sg/draft-ng-nemo-access-router-option-00.txt Thanks, Chan-Wah Ng __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ From nemo-admin@nal.motlabs.com Thu Oct 31 06:03:24 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12507 for ; Thu, 31 Oct 2002 06:03:22 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9VB46C28553; Thu, 31 Oct 2002 12:04:06 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id g9VB3OC28542 for ; Thu, 31 Oct 2002 12:03:24 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 78AC55D09C; Thu, 31 Oct 2002 20:03:15 +0900 (JST) Message-Id: <20021031.200315.07252610.ernst@sfc.wide.ad.jp> To: athene@sait.samsung.co.kr Cc: nemo@nal.motlabs.com Subject: Re: [nemo] Terminology Update From: Thierry Ernst In-Reply-To: <00cd01c27ff3$921e8790$f529024b@athos> References: <03c001c27f2f$ee3730a0$f529024b@athos> <20021029.193311.89377553.ernst@sfc.wide.ad.jp> <00cd01c27ff3$921e8790$f529024b@athos> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 31 Oct 2002 20:03:15 +0900 (JST) Content-Transfer-Encoding: 7bit Hi, From: "JinHyeock Choi" > > I think the nested case is tricky ... A MR of a mobile network becomes > > a TLMR when a sub-NEMO attaches to it. Do you think it's necessary to > > reflect that in the terminology ? If you have an idea to explain it > > easily, your definition is welcome ! > > Yes, I agree. How about define the terms like 'parent-MR' or 'sub-MR'. > Those definitions might be useful to describe nested cases. Good idea. Consistent with the current text. > > For this one, I have the answer. > > > > Each mobile network in the nested mobile network has its own Mobile > > Network Prefix and keeps it. The MR of a sub-NEMO gets a COA with the > > prefix of its parent-NEMO. So, from the point of view of the TLMR, > > there is only one prefix. No need to care about prefixes down the > > hierarchy. At least this is what happens in Basic Support. > > So parent-NEMO and sub-NEMO may have entirely different > Mobile Network Prefix. According to your definition, 'all MNNs necessarily > have an address named after Mobile Prefix'. I guess that mean > 'all MNNs which are directly attached to MR's ingress interface'. No, first because the mobile network may have more than one internal link. And, second because the definition does not say the prefix identifies the **nested mobile network** but the **mobile network** where the MNNs are located in. I don't see a need to refine this definition as far as Basic Support is concerned. > Your define Mobile Network Prefix with respect to Mobile Network. > Instead how about define Mobile Network Prefix with respect to Mobile Router > like 'prefix assigned to ingress interface of Mobile Router'? As said above, the rationale was that a mobile network may contain several links; these are the same tradeoffs that led me to the design of the "Prefix Scope Binding Update" draft. (i.e. the need to insert the prefix and its length in the PSBU). > > > 2) In [Page 7], Local Mobile Node (LMN) is defined like below > > > > > > Local Mobile Node (LMN) > > > > > > A mobile node (MN) or a mobile router (MR) that belongs to the > > > mobile network (i.e. its home link is within the mobile network). > > > > (A) > > > > > But according to some people LMN is defined alternatively > > > > > > A mobile node that resides in mobile network and never leave that > > > mobile network. > > > > (B) > > > > > Those two definitions are not same. For example, according to the first > > > definition, 'LMN's HA can't be MR's Home Agent' as Alex explained. > > > I think we should clarify it lest there should be confusion. > > > > (C) > > > > (A) does not prevent (B). (B) is more restrictive. > > (B) doesn't imply (A). Assume there is a mobile node such that it never > leave a mobile network but its home link is outside that mobile network. > That node satisfies (B) but doesn't satisfy (A). Can we preclude such cases? > And (A) doesn't imply (B) either. Sorry, but if you look at the definition, if the home link is not in the mobile network, it's a VMN, not a LMN :) So, what's the problem ? I kept the terminology abstract enough so that all scenarios could be discussed; if we agree for some reasons in the requirement discussions that a LMN should not leave the mobile network, the definition could be refined later. But, instead of discussing if a scenario is permitted or not, I would prefer you to check the requirements drafts and look if any of them prevent the scenario you have depicted. > > From the perspective of nested mobile networks, what a MR is is > > tricky. > > > > 1. At first we have 2 mobile networks. Mobile networks is multihomed via > > 2 MRs. > > > > > > lx ______ Internet______________ ly > > | | | > > MR.1 ---MR.2.1 MR.2.2 > > | | | > > l1 ------ ---------- l2 > > > > > > 2. What happens when MR.2.1. attaches to l1 ? > > > > - MR.2.1 becomes a subservient of MR.1 > > - MR.1 is the TLMR for the aggregated network > > - mobile_network_1 is the parent-NEMO (and also the root-NEMO) > > - mobile_network_2 is the sub-NEMO > > - mobile_network_2 is still multihomed to l1 and ly > > > > 2. What happens when MR.1 attaches to l2 ? > > - MR.1 becomes a subservient of MR.2.1 and MR.2.2. > > - MR.2.1 and MR.2.2 are the TLMRs > > - mobile_network_2 is the parent-NEMO (and also the root-NEMO) > > - mobile_network_1 is the sub-NEMO > > - the nested mobile network is multihomed > > > > So, may be I should include those examples. > > > > I don't see an issue in the definition. Do you think the definition > > should be clarified ? > > Assuem a case which you described in Figure 5 of your draft. That Mobile Network > is composed by one parent-NEMO and one sub-NEMO. And each NEMO has only > one MR. That Mobile Network is not multi-homed but has two MRs. > > According to your draft, if there are more than one MR in the mobile network, > it is multi-homed. I think what you mean is 'if there are more than one MR > which is attached to fixed Internet.'. Here again, the definition didn't say ***nested mobile network*** but ***mobile network***. So, according to your concern, I should refine the definition of multihoming to include a case about nested mobile networks. > I may be too scrupulous but tried to interpret your definition literally and found > some difficulties. As long as it helps us to refine the terminology that's fine. But I agree you may be a bit too scrupulous at this stage :) Thierry From test-admin@nal.motlabs.com Thu Oct 31 22:59:53 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26362 for ; Thu, 31 Oct 2002 22:59:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA142DC01108 for ; Fri, 1 Nov 2002 05:02:13 +0100 Date: Fri, 1 Nov 2002 05:02:13 +0100 Message-Id: <200211010402.gA142DC01108@jessica.nal.motlabs.com> Subject: nal.motlabs.com mailing list memberships reminder From: mailman-owner@jessica.nal.motlabs.com To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: test-admin@nal.motlabs.com Errors-To: test-admin@nal.motlabs.com X-BeenThere: test@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your nal.motlabs.com 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@nal.motlabs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@jessica.nal.motlabs.com. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@nal.motlabs.com pupafo http://www.nal.motlabs.com/mailman/options/nemo/nemo-archive%40lists.ietf.org