From nemo-bounces@ietf.org Tue Feb 1 03:33:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02517 for ; Tue, 1 Feb 2005 03:33:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvtOR-0005z1-Hh; Tue, 01 Feb 2005 03:28:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvtNS-0005r2-Ff for nemo@megatron.ietf.org; Tue, 01 Feb 2005 03:27:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01905 for ; Tue, 1 Feb 2005 03:27:13 -0500 (EST) Received: from csiges9.insa-lyon.fr ([134.214.79.200] helo=mail.insa-lyon.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvtfY-0001xq-4a for nemo@ietf.org; Tue, 01 Feb 2005 03:45:57 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.insa-lyon.fr (Postfix) with ESMTP id 891854FDC8; Tue, 1 Feb 2005 09:26:34 +0100 (CET) Received: from mail.insa-lyon.fr ([127.0.0.1]) by localhost (csiges9.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18446-01-28; Tue, 1 Feb 2005 09:26:22 +0100 (CET) Received: from localhost (criges1.insa-lyon.fr [134.214.76.54]) by mail.insa-lyon.fr (Postfix) with ESMTP id 0A0474FD18; Tue, 1 Feb 2005 09:26:21 +0100 (CET) Received: from 221.162.11.154 ([221.162.11.154]) by webmail.insa-lyon.fr (IMP) with HTTP for ; Tue, 1 Feb 2005 09:26:20 +0100 Message-ID: <1107246380.41ff3d2ce8ccd@webmail.insa-lyon.fr> Date: Tue, 1 Feb 2005 09:26:20 +0100 From: Chelius Guillaume To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 221.162.11.154 X-Virus-Scanned: by amavisd-new at insa-lyon.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: eun@mmlab.snu.ac.kr, Laurent.Toutain@irisa.fr, Eric.Fleury@inria.fr Subject: [nemo] Draft proposal for prefix delegation in NEMO X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi folks, We submitted a draft about prefix delegation for NEMO. This draft proposes a distributed mechanism for prefix autoconfiguration = in an IPv6 network. http://www.ietf.org/internet-drafts/draft-chelius-nemo-router-autoconf-00= .txt =20 Contrarily to classical prefix delegation mechanisms such as a DHCP adapt= ation, the proposed protocol is completely distributed and does not rely on any centralized server. It uses a link-state approach to detect auto-configur= ed prefixes collisions as well as to perform collision avoidance while attri= buting a prefix to a new link. Your comments are welcome. Best regards, Guillaume Chelius. ---------------------------- ARES Project, INRIA web: http://ares.insa-lyon.fr/~gchelius mail: guillaume.chelius@insa-lyon.fr phone: (+33) 472 436 182 fax: (+33) 472 436 227 From nemo-bounces@ietf.org Tue Feb 1 10:46:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18200 for ; Tue, 1 Feb 2005 10:46:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw09H-0000Tz-C5; Tue, 01 Feb 2005 10:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw041-0007Gq-Ga for nemo@megatron.ietf.org; Tue, 01 Feb 2005 10:35:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17197 for ; Tue, 1 Feb 2005 10:35:36 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0MB-0005DZ-O8 for nemo@ietf.org; Tue, 01 Feb 2005 10:54:25 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2005 16:44:59 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j11FYTQG026333; Tue, 1 Feb 2005 16:34:58 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Feb 2005 16:35:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Draft proposal for prefix delegation in NEMO Date: Tue, 1 Feb 2005 16:34:49 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC801506@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Draft proposal for prefix delegation in NEMO Thread-Index: AcUIOM4tp0XYZ092TWy1cYFQArEzAAALScdA From: "Pascal Thubert \(pthubert\)" To: "Chelius Guillaume" , X-OriginalArrivalTime: 01 Feb 2005 15:35:08.0120 (UTC) FILETIME=[9BFC6D80:01C50873] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: eun@mmlab.snu.ac.kr, Laurent.Toutain@irisa.fr, Eric.Fleury@inria.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Guillaume: Could you please refine a bit on the use case part? My quick reading of this draft places it in a nested NEMO configuration as a MANET bootstrap solution.=20 Pascal | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Chelius Guillaume | Sent: Tuesday, February 01, 2005 9:26 AM | To: nemo@ietf.org | Cc: eun@mmlab.snu.ac.kr; Laurent.Toutain@irisa.fr; Eric.Fleury@inria.fr | Subject: [nemo] Draft proposal for prefix delegation in NEMO |=20 | Hi folks, |=20 | We submitted a draft about prefix delegation for NEMO. | This draft proposes a distributed mechanism for prefix autoconfiguration | in an | IPv6 network. | http://www.ietf.org/internet-drafts/draft-chelius-nemo-router-autoconf- | 00.txt |=20 | Contrarily to classical prefix delegation mechanisms such as a DHCP | adaptation, | the proposed protocol is completely distributed and does not rely on any | centralized server. It uses a link-state approach to detect auto- | configured | prefixes collisions as well as to perform collision avoidance while | attributing | a prefix to a new link. |=20 | Your comments are welcome. |=20 | Best regards, | Guillaume Chelius. | ---------------------------- | ARES Project, INRIA | web: http://ares.insa-lyon.fr/~gchelius | mail: guillaume.chelius@insa-lyon.fr | phone: (+33) 472 436 182 | fax: (+33) 472 436 227 From rbyfgn@o2.pl Wed Feb 2 01:02:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02479; Wed, 2 Feb 2005 01:02:59 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwDti-0004dA-Dl; Wed, 02 Feb 2005 01:21:55 -0500 Received: from [211.209.11.17] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CwDbL-0002EQ-SN; Wed, 02 Feb 2005 01:02:56 -0500 Received: from symphony-54.iinet.net.au ([101.57.159.228]:1906 "HELO mail.ies.edu") by ies.edu with SMTP id ; Wed, 02 Feb 2005 03:01:47 -0300 Date: Wed, 02 Feb 2005 10:57:47 +0500 Message-Id: <4.2.48.2081924.0083fc70@ies.edu> From: "Pearl Cahill" To: Subject: Its all for a good cause X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit meme only . septacro resorcinol cattail. sanctify throttle scuffle dentistry glenn simplicity cumberland egipt. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit bank arenaceous
You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web
Guaranteed.
 
 
 
 
 
 
.
.
.
http://www.193.bptunsr.com/ You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web Guaranteed.
.  
   
NOMORE ------------A85031401794097-- ------------A48356845382213 Content-Type: image/jpeg; name="gab.JPG" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACQAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAtUAAAZrAAANLH/2wCEABQRERoTGioZGSo1KCEoNTEpKCgpMUE4ODg4OEFERERERERE REREREREREREREREREREREREREREREREREREREQBFhoaIh0iKRoaKTkpIik5RDktLTlEREREOERE RERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAQUBkAMBIgACEQEDEQH/ xADOAAABBQEBAAAAAAAAAAAAAAADAAECBAUGBwEAAwEBAQAAAAAAAAAAAAAAAAECAwQFEAACAgIB BAEDBQEAAwEBAAABAgADEQQFECESEzEgFCUwMhUGFiJBMzRANREAAgECAwMIBAsHAwUBAQAAAQIR AAMhMRJBURMQIGFxgSIyBJGhQqIw8LHB0VKS4iMzQ+FicoLC0hTxsgVTY3MkNEAVEgABAgMGBQQB BQEAAAAAAAAAAREhMUEQIDBAgbFRoQISQvBhcSLBkeEyUmKi/9oADAMBAAIRAxEAAADkXZMdJBKZ Nuax+qe1lqHWxZOT8b0/KaRWezWBOmaSi4ndpMISKaJ6P5f2Evp5xoDJPJx507GPI1h9tPjXDro8 1MXSvytcfX2/PO3citcWdV1o+ZzQ7hcxXDsJ8HYH2Y+YOT0M8A7XAM6ebSe4qtdBT0ObpvQadTWy NzlWtQErEMOX0cI040W5jdXNBOrzU4FZNphahsZOmn3V3nejDOfQxE7EqZgNGruhmJhBZi9QLdsS FF6sAsuOuM8rmeBhpxTanoDI9hC8gYoxz1czey2t2KcMNd6GKtI0eS6rLVD18HWSvyqaMXk8x3mD rnzTkF0c5DR3U8YNyjUivUnDou88r9UQqNvCDWDnWwJpclqgdVagbobWYGjXxbQaEq1ENV6tQN+g BBfWLqhOObvBNJB59Q6CHJ3c70lK44jG9ZmqNsw6mpYqVIujoY3YaZ4t4kou9OBnOTkdQ1Tl2ZSj TF5voMHo5ws61yf2Dx72FCrWeTDqVzdgNmfNwDpwZow36OWg3mw64b8Y5ob0ccAdDQ0efDShRsBe Lz7h0iSDEz71Tm6asSiz0IQBAKwk0LK1c2qn1nCa7jaOF8rtTrGuHhIDKoCwioZG3WucCO9ZuOd9 Qwd7TNJK8wyrvRUNoIIyo02tpJQ0lRZeVFMvBrmCwlCSapXWJJISSDnM+YOTrJNg56WBjNcggwGW cw8m6N4iV6diB4kkqwHNypnRHZNXsxc5EsOK5LhLjN6LL1NsklDbGtcrWaEA/HUo2anSdC0Ulx1H zH07zHtmw+vY0WBX7WMupWw3pH6fn64eioZPOtJIOSVl+DupivMPOJeEMCkMExpjqNbQRKEIq+Xt NpGFsqoPYNl7+TmcZHJWCHSB9Dh7muaSW2NGwKVrnw9BhdCno5/Rw5TS53HzL03geyb9LuudDJME uqzj3tZAOU1ky51uVq8dJJZPlNKL8PaWbvWYKGsw8WM5LSuVQQZMyEmSFCUBxrWQNy2qtsUlIjgB C09EDpOX6bTOSCtMjVCpqtnbT2UdMSkKhpBENgKq0kzqDtSUUKSZMdMgdJBzGjRvcPaiDckjO9Tm jKEuLFqyysIqE7RHIE4AMDhqukJCcSQkJXFcklRR3eb6O4hn280kpasA0Y5J0X4LNa0tHA3mqtE9 Tm2aDJvR1at3r54RLkXGoqBGXFJgZ8nRueYM0/M9G5PMK50JxdxLI2AWsiKSoJYSmjPBJsAoR1LI 9BvQJAkzIkZ6ZvVtU2s/pc7V0mvn6icZLa6CjW13Zjy1kLOvzTMuj0IMdMjWsvpDQI+kBY6YCFtN AR0FYpUHMEETz+5BNEZrmVoVNlAkRUz93IogUNibUovDYBQjFfp6QEnGdSSUZaZtXaxSKcL9GAmz obYaqxbgX3o1B7SxLKNN8jWHIkZKnjALDEx9ppnUM6ImcHdkm7xQcmbmdbj7dFgNLk+azfRlyNKV ZjEjjHWpklGkIkUwiDAtwZQkSBLiTsG5rbFK5rlMcltlk1Nge2GOPYMGGPoIBgm3GDD1LjDcQwWy jiW1LaqvzaWcu08VWkdgtNXcM7RRrnyq/Tv8ncQoz46QmcyVbRrOi8akUVsTzc4xL2WUdw2pZyDK yU4K4mJS0ztkBHXM1qgak7AWlnQXEZBcDITiKhOgkWZy0gs4uOOU1NRcJJkiSZxJ2cPOW1Y4dFQ4 iYdFicCwlJ3CBoDZdLTMKzUOzMXUqXlU5xdxKLZFyS3xV3bPsC5uuk5Qm1WPTOLbasO4MqtZnMKU LhlnU1ql91oRGRckLUhokUJJb0blURUJBcUWCvaz7dzhTO/N0Z1TYy8tXLWLloZ4TQ8JRCB6ZWXC VTCYkXYVhiqW5vRo06IbVLfDp9/m93OrWhnS0xM2crz0nzEGm+Whaj5SRrLJQrV/GTnZfFSe02Mg 2VjINpYqFtrEQbhOfsDmxIR1CztOnF5TuXDoU3kkneaVetfptlPk26NBqruS1BzaDXuVyqFDUzts tPquH6VLcrsF8lGYRrzrUa0gV2iyNmoCNXaozrznZtUzOj1WYL9OEAvSoTHeelBu/VqHU2bOZadb cEn6w6aU1lmS5+ickkPJISAkzPSWhYCk1aKlCFWSVVc9LabF5JXu7SWnEFJXzpJAkkCSQJJAkkCS QJJAkkCSQJJAiJD/AP/aAAgBAgABBQDoWxGOYjTIgIP1GZmZmZmYDMmZmZmZme8JxPLvnMUd7DFY iK2R9B/V+ZYQIATPgK0sExEOJmFgsyCP1gxUuQYDD8AGPnGRB3gJEOZX2H6zDI6CKe7joOhOIrT2 RW8umO2RAhIgBM8GhVh0II6s2ID1BUQtnpnoYDAJX0b5rTyLsFWa3x5PkW4YVAMyrYvTEA+kQMBC Q0IxBMyroe8RlJfwzNcgCu4lyEybFwoRJaQzdcTH0iHvAJnArM8hA+ILcQv5HInkJ5CZmfrP0gdo IIvwT3JwQxhJyGyCcnEQdsdXQoZnriGZ6Z7CCYzEU48TPGeM8ZiGo5WsD68dMzMP0CCCJMTBmJgw gjoAYy4H0FCOmIe3Q/QOijET5z2zPKeXbyzAonYRyWPV3Ll4TCZn6RBFEzF7/qt3B+owQCY7DvEn bHads/8AgkT4+p/HJjD9ARe8z3U4nmJ5ieYnmJ5iewTzE8xPMTzE8xPIQxh26iYgHTMQxsZHx2mR ntMiHE7Q4hImRMiEiZGTD8H6B8Q9E6J+r//aAAgBAwABBQDoFzFGI6wAmFSPqAyQoJFYgrECiCsR lAhRZ6xnwGDWIUAhUeMC5mO3xG+KxD3jLg/TkzJmTMmZPXMyZmZ6EYlYMJxPmFYhmYw8hjECkwgg /rOFcIMAiYhIi4ziGEAwYxYO/wCspwehnYBeh6CEZnrGXXx/VVZiEGYniTFXxhOTiBehhMsOepg6 HpiZnx1zMzPTMz0IzAuITDPGW/QOhhE7zHQdDO8DTP0iGEz5NoxPEzxM8Z4zEwZ4mY+kw9B9P/iG Zj/MxCJiYgGOjHv1Vg3TEMB6DoIYYYI7AnImZmZmYHELZ+vMInj0H0GGGOZkTyGMiZEBB6ZgOfpB B6Y6Yg+g9GOY3x45PjPGePdVxCei9voVfGV/GPo+Op6McTExk+tZ4LPATwE8RConaATEx1Q4OfpH Q9D8ntB89vElZlfI/DlSD3gEP0LmCIf0MR+0MscJPukn3ST7pJ9yk+5Se+ufcVz7iue+ue+ue+uC 5CRFPf6xLB28SBsYCkrjyXyyohZISsBWMVMZlMDIJ5JhmUwFS4g+fpPQR4fi34/THz//2gAIAQEA AQUA6iCLSWjazVDUBZKQE2FsxNy/0Nu7jXsCZnPXPUCJC017317NS4bFXxCQAvK6rTb5HX0ztbtO mjb+uo2+R19KbO5Tq11cjRa9nJ69Vu3v0aS37tOvU3I661MwULzWmwG5S11O5TdYnI67328jRTav Jaz0jkNc0V7lNlOpu07q2cnro9fI69ltO7TsP9FFBsajjgh19INPDBuU5q3yz8h47FSaxZrdVqx4 kdD1EHaKY5gbE/qu55L8zm1d9Hi7Kn1OQ8t/Z2dv7rjHNutbus3IbF+4djiuSYum9aW5Hk3+92m2 ms4u/wBmtK2La2jRbt6im2vkNTaOttA2VDb2WPIa7BtJXs+3G044/jLW0tz+vtheb11GvwWv4VdM QdjrKGbWTzgjLHr7P/8AaSAKahhtfI2tM5ZSJjqIvaAkQ/8AUM/rlhXeTZCuRmLxlVb18albHiaZ bxldqVcbXWW4mnNPGJSL+Josg45Az8VSzPxldldNIrSjQShrtFLLLeNqsdeNr8F4qtYeLq8142vx HE1rLONrcWcZVYx1lsr1dca69FAmrrF2opCCo+MU+UbsLGAXX2w23ae1K9gO1lKuu/qZh/56YgER TPHAcTy8x/Xf/wCjy2wNROle5uNv6+xsnf8A5pE1z/YETpRyV22G5xTR9/bVf/Po7aG8m/TubLa4 0+YXZerlr7dV+UDNRfsNymzsJq1Pyd9VDcm7bKb72zU5F9fQ++89npjpW2DrXZlbdq8mVYWW7lYm z5W1svqK2+yUr2AhXttr22FKtBBEzAwMsSZweKu9W5/YQXu6WccrXU6SU3fxVBQUq6xeLWqfxGuK 79NL7V44VFFTUq2OPr2rauNSu2rj66tQ8ZWBTxy1bF1SXoeIRq10a12BoVi0aQo1OL49ePo6WVNU ZRUbXo1FqBda5/IBY33OwqUdqLDWOW0isorLom2tVdW+thrsSwXayuNziXEupasgGUUta1HBrjd0 m1YzGHvK7DU25vvumWMUXX2b9nS/kNnYeq66neS5qOI2Lr35BNy/Xuq29+/W17DZUtt9+9tbdt2n tWbGlq7e15bFXJ7J1XbYr0tnY29fjty3Y0Wt22utXmdgceKrFI5TYVa1ZE6O6vNvRNM1HFdijIbV DEVGqBbrgawq+UTDLvUNTZxlROubjTZr7TMUcsCmZvcet0TgQzU6lWodO9A/PAJUc4PQfHR9DWd2 qRm9SF/tafD1J5ipA7cfquwAUNxWtZd9vV671pFXp1d9QuolhqQo1FT12VJZNluNFtezoJVqnjQ9 epXVdTfVsL0fjxPXkfx1KMpxEcYrIENglj5B8qzdyL0yzZs27NbWFNOxrB5RV4ytcdLBmKksT2Qa VdU5ZW23sBUzE+Ot28lyXblj0VXD73T2KHVr9ttTk0fUUXqNp92/jX3hs6i6d9n3C21WaXD/APw7 5qHJ6oa7YTY27iq+I11ublOf801N/d0dmq+zZGqjnjdvpYMrdSay0HeAEQORBbHvFYa5mG2TOBpW zYb488sgxAcdDPLEaxg9jWOr+KV26vtLaLhdbQv2zZw+3WetutXcz3JW2taao3INXAwP6NOtXQ36 CPldiyEBoylYrzzEJEYhi/xfR4iq56LNHbuusWsKFfEFhEBhMtaO4jLkeIIsIWK2ZS5pKb1dn0be yazq6gpHTdpCjR5pdg9Pify+lP5fSn8vpT+X0pRu6+wZbalKjlNM/VW2G2bQ7qcBLFaNrZhqYRlY T2FI20oG3s+yU0kypAGpRsKjJAwI9gEa0CWXZhtyVyQvY+hCU1hkaamNx1Tdfiabm7rtbVWpXvbp 3Rx1Is3Oln7dUUJQBSR40zxpmNa1uB5i2yz+w7jb2xY9W6v9c5T72j6LbSLFr7+PZ18YlpENjENY 7EpaxOpkrqKsCAAqRNclk8YTiWXBZZu+RUPbFTxlfeIkSuKsAljBetn7NEg09N/YF2wtV52OM4uv j16WftprezUr/se4i3f2S6mvQ5ltvd/sehVsattz1oS2rr73B2cfqptnUvptW5OoqxDgQuojZeGl pWxrl9IYUpkFf+mSeuGsyi8VS3cRRfycuttvlYek6162gd5q19lWKIoltgrFrM56fM0CtY2dmrVr r5Tc3H5PjbNTj9fdq1eQP9i0letxYss/bRdZTqJwPJOvM6t2qupyNXHcpynOtyiiuu6zQsW2+z+0 6Fq69tQs/rG5ZVZ1VPJTUhja7KKFFsaplDAQgqFLQLiYhXMxgMgjaqmDVUQ0LGpEsoxNTZZmrXxA gOJ7yS3eN4gddlHQ621XtLtcTqbc3+P2OMq43UXZts16rT0cZVeD3hrUgrX/AGbj9ncZ9HlHavhe S2hyfDbCJscc2rx/2XIz7LkZxOm9S9aLXodqwwWsiPWrzxZJdqtXBGGJ3iHMBxCcgGEQ4EKiMoli zj9cNYBBLASNM+suPJtq/wAPpu0a7GNW3WNzV5BtjR4inUf/APCES5KK/UA2YJmEZAUo2BGHYMck YhGIO57tGyATmBsyztNOsJWBBAJjE2NiVV4LMFHtM9pntM9hnsM9hnsM9hnmZ5meZjXBZ92gg2Ua eU8pmZmZmZ+inVv1mJgMB6EGbagOO8evyip4QtklTApEJnjmMMyx/XFt9pTsBBBNi0iNrIEY+sW/ Mu5Wqqfy9Zerka7Ep3PY9W+lll++tNlfLU2Lr8tVe0vuM9hYl+/kZxlrE4M7xH8x3mTMmZMziCU8 gjEYMIinEBnzN1SCDmHtGfBVh5LmeWYxGQJnE2T7F0aSbwIoxF6NSHlh8FWv7+y35v8AL16fh7H+ 386286qdw2rq/v3P/fWVRKvAO/xf/wBMxy3/AJVCx1dca6dOKtyle35P7bPuYxwNXdusuVgrisGV WPTEtVx0WOgdWq9LMSY4Ag7OD3AwI+MucS15xSlrB2iwQdNtgteqrVy35l3FVWz+IrDjh0Ev0VtL cLWy18LXSRwtKrrcZVrkjI2EKM5lWtZcdfVWgRrXE91k9rie14pZX91k91kzYZTSKgsxGUqadzBA nxF7zco9iqSIwzMZA/5gtBhcmYMZGMNGZoV+IAiwCDpsUPssdNFDKGHqM9RnqM9ZnrM9ZnrM9Zng Z4GGvIGhWCEIniZ4zxmJiYmJj6F6HvGUGa1/kAYGxCczaogYiVgMfETwBgQCNgRjGmuviogggjsE GuRZPBQbrCkJJ/TCCeAhUCewL+khghPRgQa7Q6+UBh7zboNZqPbtAYTGjRF8mUYgEEHTcOVrrfxr R1mx+7a2rqrNjfsz99t4v2bfYu8PT99tktyd7Lp71ljPyF0DAhBC4Ea2NdNq4kBDjwMof3V4MwZg zBncRWDBLMwPPIGeWA1mJTd6mUwGAx0Di2k0sr5g6GNNdIIsEEzFY33r/wAAnE2P3b6+M19da7BY BLfZepfFtSsHVmtqDmqeJrt0LfGo2xro1sLkzW1zY3TjtdqpXXaHCE7cbJGprXpclgss1950lO4j gOIz5ltreS2nGhtlwrQNAZbWLBcjUlGyITD3lY8QsAg6bN3qr0qPt0XMAxNhDCAwp16qB/H6uaqK qZXr1VN9jrljrVM9mnRaworCLrVolqmseamFlEoQWlXQA+ZmLZ42zxtgrsE8LZ4Wz1OwRAgoEVe1 ZYQeyCvMGvmV0LWUs8grRWmZbWHFlbUFHDAysZYRRBAZmKotsVfKFgIGzCQAzVZ8qp5VTyqnlXPK uZrma5lJlJlI1dLz1a9cD5IImVmRO07TtO30Cs1MgyE7QEGJ2njmeEX/AIKtEeK0Mtq8hahoK2Ai pcBRB0zHfAqYCe2AliSXOyxz+mzBYflR7Ci+K/o2aWRVlYoixZmCYgPiVMRopnzNmoOKFPtURR0z GbE/k6nsrtgszKyXgwo2P3ck4aalq1hHGqLa0pT01LstWmwy6yCqldb12KqDiFCAv4hFnqOVQIMz xE8Fmhse6tb0ae9PPwWFVEq3arXVjlag0fQzPFkKd4sAmMdCMgMRFaK8DRu4rTxuUQQwticruGtH E1eTes691LQf8qMLNj92zr323WcdbXKtDYLfxuwU+32msOps1Oupt+vx37al0bscfW9Ko3lKQc9l GST8w2oJ7q5rU1a8WmpXUIdn3Vw21kV61FDUh3KUgw14mxR5BRiLAZnq65iPFaK0zCvdZmFsTYvF a3sbGcRP/ZxlqsFvXAtWW1+YNbCeDTwaeDTwaeDTwaeDTxMKEipLKSp7YYnBmDDWDPUs9Kz0rPSs 9KT0pBUq9Fr8RiOMy9fFw0VoGEDAzMJjnBSzIVoGmYDC0sswL3NhsWWCOSrU14lDi1QJyHK/ZWf6 Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6KafM/dXYhE YTbSHMVCYK4BiDvPGWLMmspZFeBoXjWYj2F40cSwS4YPEbwqlNdZhAE5DWW/bWoWPvVpr2byVVV8 br1WHe1/tr9jWrqqGhQBXrJ9qusn22tQNi/YelH2tNDs7mpSH260o2rdXWG5vazUDX0kto0NKlpp cfW63cfVTTt6dVa8lr10bHJa6a71010cmRCI02RlIogmIIIy5lwi2msrbiC6GzAa32FVjrGEtEuG SiduO2PbWLwZzF76+2d9wNjZ+4N+y1617tlVWztPsm/Za8Dk7Vf74msbp9a2FHs2/aTylnsHIXFL dz3PdvG+y7aa1ats1FuSvKW8nbYPvrfDYvbYs2N47DbO4dk8dd7t4wwza/YIsEHQQyyX5mv5+P8A 1hs5r9eBiWRpbjD/AL1xOP8AL3PibH2vl+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn 4+fj5+Pn4+fj5+Pn4+U/Z+f/2gAIAQICBj8AuNmmzKWRsiOmQdLjLbAcbKd2C6n8Tu6bIISUii2R tbEWxT2GTT1+Zr8WdWg3b/0J09SM/u53pOie43THh8/vhQQjbAWzupUTth7cdSLys6u5eAidTIgn Wq9Lp7/gRvKGlf1FTpr/AKQVU1xWFeyBJB1tnkV7hRE4kaI4jzdlFYcjZG4y4qotkiRKyGVa8i5J rJDEbHuuuG+DHIQxvpLFfMPcXB1xVKFChQoUKFChQoUP/9oACAEDAgY/ALjkCN5iMEQjOInM0XkJ z1EaoqPJzb5YTTma8hVpQ7rrCqRybLdW7HHgMtx0tiMo+ThMa+mK+ImVhbETMOgmLHDZBMCFyFxs FM29jEKZVzVydGHfJtY2Xja1RWE+eQnMVUm9/wC1jYfcsCe5PcnuT3J7k9ye5PcnuT3J7jIu+Knd JyE/XsPQ6mrIl6gdPMV+PAhA6m0EVUlQZtdRWRuHM+v9kbFpqeJ4nieJ4nieJ4nieJ4nif/aAAgB AQEGPwDm4UCMJMfE0C2DRlQfIkaT07R8/p5DcGIK/H49NET3c+2OTHn4VjS3reDKaW6uTiR9HZyS cAKwckE6dWltM/xRp9dKt99Jbw4E/JXEvNpUmJgnHsmrbF8LpC2zBxJ+TtpeO+nV4cCcuoGuLebS kxME59U0LYaHOIV1ZCerUBPZXAYsLhyXhvj1d3EdIoNfbSGMDAn5Jrj3Gi2Y70E55ZUl4v8Ah3CF RoOJPZ0baLHIY0G1kKTAYo4Wf4iseuj5cN+IBq0wcuvKntI0vbwcQcPj0UfLK83RmsH5Yj11wGJ4 katKozGP5QabzCuDbXxGDh2Z+qv8rX+F9aDvjLPPor/IVvwoLaschn00XsNqUGDgRj20yFiWXxaV ZtPXpBjtoWVeXZdaiDiM8DEGnt221NbMPgcD15c0JvoEmdnx9VKzDwj4/wCvxGGQ2VI2VwnziQd9 FZgb6IGQqc/g38qxy769W349PJdFvxRs3SJ9U0hdgEAVP5vpmrulS6oOEhEZjrI2zlsq2GxZbiqe wGrXlm8C3FuWz0E040lxbXhrEeLfiR00FY95HVT2V5cIZvapG8AbasPt4Z/rrhAF0tJpwjxNtxI/ 1FPYfxW2VfX8RS+X/SLrdTo2EeumJ+q3yVwAQqapJkz2CPnqEIDC2olhOGHSK8zdczB1NAiYnZJ+ Wk85pOvWXZ8MQ3bPq20LtoaibQIxia8wQe80m4u4zR8pJ0FeP2aJj7UUnlk8V06QOicaNoAol0So aMx1EjfT2rh0srM1yc+2k87YaDbgoy/Val05HvMd5PNFz6vz0C2zEdPx3cxQPZVmb5Kx241141NS M6g4HnYVhyIo9oMPdJ+atLGJqK4iIurfpE1IAAzhRFEBV0kzGkZ76AYAsuRIyqQABtgRJpoVdLYk aRnRVAqznpAFAhEna2kTWoACcWgRJ6d9EhVhvENIxoI4BgyJGVaDiKJQALuAgULoADbWjH00W0r3 vF3R3uvfRRgCp2RhQIABGAMYxuosFXvCG7ox660EDTlGyN1YKojw90YdW6lMDUuTRjQuMqs37yg0 bdwBlPskYVpGXLjUigMMKw5TNPuc6fRlUdXKZFSMxUHnSKxzFWv5/wDY1M23ZPLesKqMiBCqs+mJ 2yLZMnaNmwmvNW7Y1heFAe4VVZXZg2fQOurt+8pU2XNt1BnvYZHDAz0UpucLSxC/h3w7id66R2wT 28jXPLWg1sEqGe5pLRnA0t6yKs37SFjduCzoJ0lWM9e6rdi/bC8XUEZH1YqJx7qx2TTi1wgqErN6 8LZYjculsOuKF63gDIIOwigw4cYybtzh/wBLT6quWoXVbXXNu4HQj+KB8lf5i2V4ekuQbvegZx3I 9JFWrdhNdy8vEUE6QE3sYPqBo27vdHA1aFcss688QuOzKmvXPCgkxQ81csgWYDGLkuFO3TpA7NVD y1i2H1WheDl9IgmPqk/HKr9l10XbSz3W1CGBIIMKfVXl790F0YAXbhbFZ9o7xvxw6aHlrS64XVce cEB8OzEtuwwx+BxqBTcPcYrDAilnbHMINY8uNSOSRyWn2ao9OHz0zXD3Rgi7z+zlPmLdx7bsAraN OMZYMreqrt9SS17RqnLuiBFXbbgst5uIwOw9EZZVr/yna2DGDW4w2agoPvdfIwsXLlpHMlEKxJzj UpK/ykVatLKrZdbqwc2G+ZmZxq3eYnVaLFYyxEY03AuPaDEuVTQRJ/iVo7MK77kqMS9xvlOVJ5gM y3FEK6aTgf4gw7YmnvF3d7ihGLach1KPo6K/wwW4elkkxqhp6I27qtlGZHtJw0uLGrT0yCp9HVR8 0Xd7hTh97TETOQUfR0UbdwalYQQaFh7txrIj8MlYgbJC64/mr/KEhuHwtPs6Zn441dvSdV5QjboA jDDpr/FsgOApRRcOB/igfIKFoYtm7fWPxwHRy6XEHkCit9d4xXdFFvAm8mgcSY21BrjWxKnOgwMH ZQuNl0VgjR1VAwPTUGiUxG6oYQeQKokndRNy4dW62MvT+yg2oMhmGyy39NY8gcZqZE0HuRqAjDLk LASQCY30fOnzGhoZtAVNCx7JkaveFeTCnhcdbjXBpB8KgiJ9XXjNDyrubiNbNwFwoIIaPZVRHZV6 4kahdaJAP6g2GRS+VS4Utm0XMKpM6o2g/OOivMWWJvC1bF1JADEwcO6AD6KHmU4mthqGFgWurFtc dMz0bKR2ADMoJAMiSN+2r3lxdKIi2yoVVnHPxKfn7K87aduItqFS7AGqcxhhK9FJ5lbpaOGDbKrp hoEeHVt+tRsWXu8RVBZLS24E7Sbg/qrzZY9+xIRiF1ZbdMpPVhTeaN5i4sl40ppnTP1Z96Oil88L xL6bblCiaDqj93Vt+tVh+KXFy6lp0ZViG2iACI6SauJ5d7xNs6XFtbOlT13AD6z6K/yDGvicIuRg omNRAMYdcUs+ZJ1AwGW3jh7MKMs/ao+SInzurQGjulT+rugDMb8KCs2pgMWMCfRhyxcAI6a4i+D5 KB6Y5JNYW56omtJXSu2ayqK0nKigMKcQBRBxEmK0kMBsruyR08uWNYkx0UBAE7emtLLpntFC3ta5 I7Afprq53Ea0hf6xRZ9MUrsoLLOliMROcHZNcTSNYGnVGMbp3UbWhdBMldIgnPLrriaRrjTqjGN0 7qNwKNZEFoxI661tZtls9RRZ9MVAwAp791RcZwoIcBgNO6RXB0Lw8tGkafRlR4qg21GogrIAXHLo pbzIlwMJVnQHA9Ymj5UKga4utkCYMowxwg9tcMqCkadMYRujdXCZFNuANBA0wMsMsKGtQ2khlkTB GRHTRPmDY4oieJo1dGeNHhvaFqYbSy6ZO/ZJr/1uBxP+3o1erGn8ySS7CJb2VGwbhtrVadXWYlCC PVyljgN9aWgiIMVIBEdPNiiTiDUBMN80CfETpAFLb3Csagc1YgwWmdlBlJIzNG4uS+Hq/wBaM864 9om241Qr+buLcBH/AGu8OzLsryNy5cKcQ/isG0z3duyrS+SuNdtEPx/xGuKPq4ktBnceyr3+X5hl YXboUcZlIAOGkAgnqx6BXlOKzo7+YRCw7rMh1RPWN9JwmuC07gX31s7KvRJOnpKirK+QutdVieMv EN1Qu+SW0ndjjup/KHVce4Z8qzYzqPhJP1Djj7NeXs62Ns6uNda4Vlo2vDFF7OiRUWbiMhRpti+9 /vbDqZe71aqdvNXm/wAoo+q3xWUg493hgjDrXpyqx/40+Sk4z8NOC0tr0e19bCPSKu2rNxn8o1sR cFwtpefZeScsczFf/wAwki6h/Evj/pbGH7zZdGJoKNmGONeb4LKuFmdaFvZ6GX56tm8yki9bJZV0 iO1m+Wmt6lvMQdKW++07I0zGMY4VZ/486n8xcX8XSRqW2M8SQJ9nE440ri01ny17TbcMUhXGCnus 2YwM8uFYTB5cOWTXdHprvmTu2UWb2RIrCtPOJgEbKMmAdgo7aLNgorVHooiyuqM8QPlioa3B6x9P MR3EtbOpMTgfjvoKxAZp0rtMbqI8tYbS7FyWaMWxJ73zYT0Y1N20yicx3u3Ls66gHH4F2QQ1w6nM kknt9QyGz4GKx2cnRy4VNYUXYya1WjBr8RsPRUgYmoqDztI9VRuy5JAic99RcienmC1bE3XyHRtP x/YdTnXcPiY/NynzCvw3QE6iTpy9ro+gZxTO/dtPcFqwSMWMfT6Jg8z8639sV+db+2K/Ot/bFfnW /tiotXFc7lYHkL3CFUZk5UALyY5d4c4ioHJDVK1jWFd4VnWlcak0BlUIzR6qxYt11B5mFZxWFSwk nfUgR1ViKxUcxr/e0t4VcREbug9PKbt46VFC95uU8tP4Plx47p2E7h0/ZxxKHzZHGC6rVhfDaUZT 07h2nZHIeo0129bNwh1QDVpzDH5qkeTeP42/tr/47n22/tr/AOO59tv7ahNXl7gPd1NqWeuAV68f oPkvOfmr4WOZjYenaDt+Vf8AjrByPfOyfoUYn9lN5S0Pyh/67Ri8eIHpfxDpw21w3P4tqAeldh+Y /t5rBanliSKwPqrTEGomBWJqeSaB5c67uPVUtlyYfAHqNKQAM8FyGJ3cvmPM3hrt+V0patHwlyYk 78RJ3iBQVfxPPOAzufBYU7umD2eyKMd662Ny42bH6PieU9RpwgLHiJgBPsvQX/GJgAe19FWna0A1 wsCpkRpI+mrvlCgAt6+9OelgtPeIAuWxqVvmry3m1P4gBWf/ABnCeyB2UWbG/wCZ9Itzietz7o6a tebQkXVIa50E5fZyPTVv/kbI7jki4g2N7a9viX7tLcQyrCQfgMK72ValzqTnWFTy6TlUkioQSa7x w3CtS9orDA/V5JOfwLeXEzbJ8W2ccMcvmijdvNpQZmifL3vLqCe6jag0bMxnTcQ63e6Lt519mdww nP8A0p710xb80itbfq2Hp+frrQ7Mp/eRh800HXIiRyHqNObbFSbiYqY9l6DDzOBE+N68tbvvreXO qSdq768xdvTpLXV7onHXPzV/i+TRtLYsTmQPUBvJPopbcz5by6zcce1jJj+JjpXog76b/kvNA8K2 wgKJ73sr1KPmoo6uVYQQVGXpp/Lk/gXTAZvZPst2ZHoJp/8Aj7oMqWK9EeIfRzAdhru+upGNGcCK xGHJAqBhyY8kVHJlyyMCKCN4qjl0p6anbzeNZALDxAASw6+jdWpcxmpzHx2HbR4ttST7QwPpFE2L puWG7hsXMZ1YQsfNBq3e8sWtW7HduJrZgXgFlWScBME7dg20GdFYjIsoMcpA3U1vhHUbiNErkFbp 6aUHMAVaby6atOqcRhlvos3l0LEySUtYk1w7umzaOYUKJ7Ez7aXynkrZNod645Il39OQoeX8tbW4 4IlWEgnaca/+S19hPpr/AOS19hPpo3/MKq33ADBRkq5D6ewbOZwrogHBTsrCu9WUGscRWtfDu3ck 10b+Wag1IqeYbh9nAdvLhRDDA40TkDWhM+brWUeCNS9R+SZ66AR1f+MR8me31ddWfMIEfhzKaoXH CcejrI6aN5AVdsSoclQejKe0ej/8Wxga0ySNk7OayHZyCo5MeSK31G3kyodOPNKJiak4tUn4TEgV nWDD4MFSCu0TzlO/5qio5enkwipro5NIzOA5oUYTRO7KtbGAM+WQCyg6dQKqs9bsoPZNcJUcvHh7 gPvMNW/uzVy4QVFvxA6T/tLCcMpmuGyMjEFhr04xE+Fm30ECsASyq5iCVmds7DmBXBCM7xMLpH+5 lnsmpAbVJAQQSYzxUlduJ1YZHGgoBEnTMownd3GaO3kwwFdBMTUVjumihyiRyZUGXEESDWVZGsjW RqThyQ4K9eVYc1WjDGp5J2cmOysOQ4181SKUnZJ5veqDkKIY9xfZ38jaPFpOnrirWWng9yeyfVFW v8fTHEbVp38N/juq3Z2Ncuu38KXGP+7T66a+SpNm5qGllb8M4GdJPsznuFWf/Je/rqz1XPkFW/aL 29BtzBiTkTAxxwkE7MqW53m0OtopcA1KSREGJwkGCSI3EUaC7Mz1VO7kgYmv3jny2kV9YNoFhh3S NMZYiccD9XrpLervm7dVl26RxI+Ra4E4fmT+5ER9v1chIxoK2IOyMq0DrjdyYYruqVPMg5VpbbUA 0DursqDUipYV0cmFMx2COcWOQrWPEcTywCVUnUVAVlnfDqwHZFC4rurxGruE+8p04Yd2KaLjjVIe NA1T1Jh1iCd+VAhmQgaO7pxXcdQYULZdygMhWW20faQn11qtuytvC2/7IH8sTtk0VDMC3iMJj1ro 0e7mSc6BBLacVnSAOpVCrPTE1FSeqsK7ow3nKt7b+TBZ7a8Hr/ZXg9f7KnR6/wBlNc0Es0DFtg2D CvB6/wBleD1/so6UCk+18RW8nM8upcDWm4I6eZh4hlRJ2EzNY0I2GpNYVA5caPSecqJGkGWruv6q g/Bwa1AY/DxUVoY95fWOZrXtrKss6x5wHNLHIVrWccdR+M0DUDM1j8Hjjy970/DalzFSOWK1Lka6 ecBztH1qiB6a7wkdlDqoqgWFXXBBJbfBkR6DmKJsaSqhPEpOpnyA7wjNd+eVSNOrXw9Gjb18SI6f Vsrh2ioKgFiwLYnZmvxig7DvklNA+sJ9WE9VFgqlAYJCEgRmJ1zhtISKLoFXToGkqWJLR++g2/PS rdjvyFKjTBWZBEtuOINNdTTwlJ7uk6mCnEg6vR3TUjEHKp5hAzrPGs/VS3FODANHWJ31mKzFZ+qs x6K31I5mPJ+6eZBrDLnaudGxcK6ak50OqkvfUMN/C2HyweyltT3Um63yIOz+ihdM6OMXnSfDjjll 00OGGNy43GMAHuiNMyy/u7cxlSXV/Lb8T3dJP+33jQUu+iXPdZ1UCZBDKwXHaDjNXC2LMbWJn92D gQenOg9tTOk2lH/TuExJ39Z/qpWUHg2wLJMCJMbdU7VnunLPOuEc7ZKdns+6R2jm628K5dJ/Z8vb y2wbfDKWtFzLvN3dxxiGxP1uukQoYW7cctIiG1xtn2hswoqPAIun+MjRHox6+QxnWpgQPaO+joyG Z30JxFbjU8nzCu8a0Ns8PSOZBro5kVHNLbdnXWt/GfVWo51JzoNUHEGiLSKgOelQPkrVwrc5zoX6 KPDRVnPSAJouiKrHMqoBNa+Emr62gT8lC4UUuMmKiR21re2jMcJZQTXDCqE+rAj0VotqEXOFED1V JyrAj01iRUkwu/f1fT6KABHpruth2V4/UPorx+ofRXj9Q+iiQ2eeA+ivH6h9FeP1D6Kh3wPRUDKs eTA1sFSxn+EVgI6TnWrNht5sGv3fgQzeFMe2tTejknZWNZeisj8e2sj8e2sjWRrI1kayNZGsqyrv KD1ipCKD0AVkBWI+Cg8/o5sV0c+BnQG7l0LkM6A+E6a7x7xGFDDvbaiSev4LA41pOfwunYMedw1a WmBu9NY8kLntO6tK0OqlsnJpd/4V+kx2TR4Y0pcRioGEOs+v+2lu2gA5WGgROod2d/fA9NKbUAnU rMM2gHM7aKgKuEjSEBy2R359UVau3QHNxH1BlBgqVG0YH6wymkBAbVa4sMF0hjGQjSPjNM1osLgX ZwoxwP5eP2sO2mTy4CiVW6iiBBgzHq6pq6igBQ+AGQ7i1AzNTOO+o9P0/srdU8mQq2LikM1tXkx3 spyyzGcZ9cL3fE72+1dX9taNPe1aPd1T1R68KyFSQK4ayCcjWls/lrAVqGdQwx58c1jvj5+bw08T eocmh+8Nh2/toTcAnZ/rWleQdVNCnS2lQ/dgJtwOM4t7MZVwrQLLIKP3F07wQNOeOS7aDaQulQkO RB6Rp1ZbJiha0+DV3yVhpnLGfSBU8JgpIaDozAIz4hwx+rNDuawNZ7hXNyCfEy5RAw6ZpQ9snSht DSVmMIJl49DeijYdAF0xJAGWWVx/kHXTXwhD6vASslYAO3TOEjH0TVx7qldTagpInBVGwkbN9asp 2isDht6eSTyYsB214h6aX8TUEXhpqK4Lhuichnu65DcTBWZ1WViWmen2jtwpr5IEKEXvZ7Sfm9Ne IemoLCOuuIG1RktcR8PqjdyYGp2/AY8yeZJos2Z5AN9cJxJGVAGRFYVhmKyNZGsjWRrI1kayNZGs jUQahgY2GpAmpNZcmIrKsqyrKsqyrAc08+R8B0csjMUtxcNQDCp28gt6NUrqnVG/oO6vyvf+7X5X v/dr8r3/ALtfle/92vyvf+7X5Xv/AHa/K9/7tfle/wDdr8r3/u1+V7/3a/K9/wC7X5Xv/dr8r3/u 1+V7/wB2vyvf+7X5Xv8A3a/K9/7tfle/92vyvf8Au1+V7/3a/K9/7tfle/8Adr8r3/u0trh6dU46 pyE7uZq5M+d0c7o5vBuiUJ7p3VK4VEE13/ClrWQNsE4Vb1WSiM6ie9BB69+8GiFtppBw75Ldo1z6 hVspbUG4momWw6u98s09y+JtoMes5U1sZAyvUcqtsiISyBmLOQZjYNY+SlLIOHwg7tqOoHqn+mku hFZyxBLvpw+0tLdCIXLMDreBHR3xS2jgGOz5qZFtgBWgHU2Mb8dvRHXVuxaUKGCk4nbnmTlVt7I/ DZtDYnMGPXTIqjQCO6Z+mfXXAICIBh3jiY2kk+qgWQLOTIxKn0zStaC3LhnWrMQR1AEeunbzCwNf DQScG/ZV5Lw76sEVpOBOA9cVbkTc4ircMnbjFXpThhI4bS3e9JM9lcO2IWFwpltogURjr7/o1/00 qWhCgZfynmH4GDl8nMgZc/A99cG+ntrvYGldM9AHWJalVVVVV+JAnxdpPqosyKGJksNXzsR6qRWA hBpEUbVs6ZOosshvTOVKbkSo0ztPXSKwEIukRupXAWUXhxsI6caFpkQoCWA72E9TChZZFZASwnVt 6mFB07pBkRsos1tJJljBx9eE7YiuKFQOF0z3svtVoc64YOC8kgjtriNbTUTJPe/uo3XRCSIOePrw 7IpbcBUXJV6esk+ugQi6lyaDPqMHtFBFbTBLErILE76cQo4mnURPs5RjQtmDD8STMz6aNxoBbdWt 0XV9Yatn80eqi7ous+0NX90eqkbSq+LBBA8J5hjn48uMadld2K/FnT+7l9NdzLmjkHD3d6d3x9fR XTX4/D1R7emY7a/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9 H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcocLha9mnTPqr//Z ------------A48356845382213-- From nemo-bounces@ietf.org Wed Feb 2 10:43:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18657 for ; Wed, 2 Feb 2005 10:43:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMXB-0005XB-AO; Wed, 02 Feb 2005 10:35:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMSF-0003hZ-00 for nemo@megatron.ietf.org; Wed, 02 Feb 2005 10:30:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16948 for ; Wed, 2 Feb 2005 10:30:02 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMkc-0002S3-HB for nemo@ietf.org; Wed, 02 Feb 2005 10:49:07 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Feb 2005 16:39:48 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j12FTEib020776; Wed, 2 Feb 2005 16:29:31 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Feb 2005 16:29:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Wed, 2 Feb 2005 16:28:38 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC801AC5@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPAFKQxKMA== From: "Pascal Thubert \(pthubert\)" To: "BINET David RD-CORE-CAE" X-OriginalArrivalTime: 02 Feb 2005 15:29:24.0601 (UTC) FILETIME=[F9A55690:01C5093B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable |=20 | From the draft, I understand that the question about the configuration of | Home Address is only valid in extended mode. In aggregated mode and | virtual mode, there is no specific Home subnet and Home Address will be | configured on any MNP. | I think it could be useful to distinguish both modes in current "extended | mode", one if the Home Address is taken from Home Net (basic one) and one | if the home address is taken from Mobile Net (extended one). |=20 I did not see any support for this proposal since. I'm anxious that it changes what we usually called extended to be only the case where the address comes from the MNP. People might get confused, since it was not the most expected usage of extended. I created issue 4 to discuss this point. Pascal From nemo-bounces@ietf.org Thu Feb 3 11:28:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12117 for ; Thu, 3 Feb 2005 11:28:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwjnH-00067l-Gt; Thu, 03 Feb 2005 11:25:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwjYV-0000kT-KY for nemo@megatron.ietf.org; Thu, 03 Feb 2005 11:10:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10116 for ; Thu, 3 Feb 2005 11:10:05 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwjr5-0003Ap-O2 for nemo@ietf.org; Thu, 03 Feb 2005 11:29:21 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2005 17:20:08 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j13G8mj1011248 for ; Thu, 3 Feb 2005 17:09:32 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Feb 2005 17:09:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Thu, 3 Feb 2005 17:09:14 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC801FC6@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPAFKQxKMAAz6piA From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 03 Feb 2005 16:09:18.0970 (UTC) FILETIME=[B736CDA0:01C50A0A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: Last call for the Home network models draft is passed and there's one issue left (issue 4). My humble view is to reject it because it's a bit late to change a name, even if it might be ill-chosen. If someone disagrees please voice it now. I plan to submit version 2 next week, and ask the chairs to send it to IESG. Bleeding edge version and issues are at: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod els-issues.html =09 Pascal | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Pascal Thubert (pthubert) | Sent: Wednesday, February 02, 2005 4:29 PM | To: BINET David RD-CORE-CAE | Cc: nemo@ietf.org | Subject: RE: [nemo] RE: about the Home Network Models WG item |=20 | | | | From the draft, I understand that the question about the configuration | of | | Home Address is only valid in extended mode. In aggregated mode and | | virtual mode, there is no specific Home subnet and Home Address will | be | | configured on any MNP. | | I think it could be useful to distinguish both modes in current | "extended | | mode", one if the Home Address is taken from Home Net (basic one) and | one | | if the home address is taken from Mobile Net (extended one). | | |=20 | I did not see any support for this proposal since. I'm anxious that it | changes what we usually called extended to be only the case where the | address comes from the MNP. People might get confused, since it was not | the most expected usage of extended. |=20 | I created issue 4 to discuss this point. |=20 | Pascal From nemo-bounces@ietf.org Fri Feb 4 05:01:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08222 for ; Fri, 4 Feb 2005 05:01:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx06o-0006wV-Kq; Fri, 04 Feb 2005 04:50:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx04C-0005St-IU for nemo@megatron.ietf.org; Fri, 04 Feb 2005 04:47:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07080 for ; Fri, 4 Feb 2005 04:47:53 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx0Mw-0003TQ-KP for nemo@ietf.org; Fri, 04 Feb 2005 05:07:19 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Feb 2005 10:47:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 4 Feb 2005 10:47:49 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC201CAAF1E@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPAFKQxKMABYusKg From: "BINET David RD-CORE-CAE" To: "Pascal Thubert \(pthubert\)" X-OriginalArrivalTime: 04 Feb 2005 09:47:49.0876 (UTC) FILETIME=[96A9FB40:01C50A9E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello, Comments in text=20 >=20 > |=20 > | From the draft, I understand that the question about the=20 > configuration > of > | Home Address is only valid in extended mode. In aggregated mode and=20 > | virtual mode, there is no specific Home subnet and Home Address will > be > | configured on any MNP. > | I think it could be useful to distinguish both modes in current > "extended > | mode", one if the Home Address is taken from Home Net=20 > (basic one) and > one > | if the home address is taken from Mobile Net (extended one). > |=20 >=20 > I did not see any support for this proposal since. I'm=20 > anxious that it changes what we usually called extended to be=20 > only the case where the address comes from the MNP. People=20 > might get confused, since it was not the most expected usage=20 > of extended. >=20 > I created issue 4 to discuss this point. Even if the "extended" term is not really the right one to describe this mode, the most important is to have a common understanding about its description. I think it is the case now. I think we can distinguish two sub-modes in extended one, one if the Home Address is configured from Home net and one if the Home Address is configured from Mobile Net. It could be convenient to make it more visible in the description of the extended-mode.=20 >=20 > Pascal >=20 David From nemo-bounces@ietf.org Fri Feb 4 08:43:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26494 for ; Fri, 4 Feb 2005 08:43:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx3gH-0002AX-Ex; Fri, 04 Feb 2005 08:39:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx3fd-00020j-Fp for nemo@megatron.ietf.org; Fri, 04 Feb 2005 08:38:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26137 for ; Fri, 4 Feb 2005 08:38:47 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx3yP-0001dY-Sa for nemo@ietf.org; Fri, 04 Feb 2005 08:58:14 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2005 14:49:07 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j14Dbwib001053; Fri, 4 Feb 2005 14:38:14 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Feb 2005 14:38:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 4 Feb 2005 14:38:10 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC83975A@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPAFKQxKMABYusKgAAeKzdA= From: "Pascal Thubert \(pthubert\)" To: "BINET David RD-CORE-CAE" X-OriginalArrivalTime: 04 Feb 2005 13:38:14.0115 (UTC) FILETIME=[C68D7330:01C50ABE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: BINET David RD-CORE-CAE [mailto:david.binet@francetelecom.com] | Sent: Friday, February 04, 2005 10:48 AM | To: Pascal Thubert (pthubert) | Cc: nemo@ietf.org | Subject: RE: [nemo] RE: about the Home Network Models WG item |=20 | Hello, |=20 | Comments in text |=20 | > | > | | > | From the draft, I understand that the question about the | > configuration | > of | > | Home Address is only valid in extended mode. In aggregated mode and | > | virtual mode, there is no specific Home subnet and Home Address will | > be | > | configured on any MNP. | > | I think it could be useful to distinguish both modes in current | > "extended | > | mode", one if the Home Address is taken from Home Net | > (basic one) and | > one | > | if the home address is taken from Mobile Net (extended one). | > | | > | > I did not see any support for this proposal since. I'm | > anxious that it changes what we usually called extended to be | > only the case where the address comes from the MNP. People | > might get confused, since it was not the most expected usage | > of extended. | > | > I created issue 4 to discuss this point. | Even if the "extended" term is not really the right one to describe this | mode, the most important is to have a common understanding about its | description. I think it is the case now. | I think we can distinguish two sub-modes in extended one, one if the | Home Address is configured from Home net and one if the Home Address is | configured from Mobile Net. It could be convenient to make it more | visible in the description of the extended-mode. I guess I can do that :) I added section 5.3. Please let me know what you think. Pascal From nemo-bounces@ietf.org Fri Feb 4 10:51:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08697 for ; Fri, 4 Feb 2005 10:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5dV-0001EK-LX; Fri, 04 Feb 2005 10:44:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5ZK-0003uk-RB for nemo@megatron.ietf.org; Fri, 04 Feb 2005 10:40:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07675 for ; Fri, 4 Feb 2005 10:40:23 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx5s8-0004bx-1M for nemo@ietf.org; Fri, 04 Feb 2005 10:59:52 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Feb 2005 16:39:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: about the Home Network Models WG item Date: Fri, 4 Feb 2005 16:39:16 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC201CAB3B1@ftrdmel3.rd.francetelecom.fr> Thread-Topic: [nemo] RE: about the Home Network Models WG item Thread-Index: AcTzVBe+LRBqVR0pSaKjvVT05Opv5AAvqM8AACDkTPAFKQxKMABYusKgAAeKzdAABO8QYA== From: "BINET David RD-CORE-CAE" To: "Pascal Thubert \(pthubert\)" X-OriginalArrivalTime: 04 Feb 2005 15:39:17.0057 (UTC) FILETIME=[AF9A7310:01C50ACF] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thanks Pascal for this modification. It stresses the fact that "normal mode" is to derive home address from = home link. David=20 > -----Message d'origine----- > De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > Envoy=E9 : vendredi 4 f=E9vrier 2005 14:38 > =C0 : BINET David RD-CORE-CAE > Cc : nemo@ietf.org > Objet : RE: [nemo] RE: about the Home Network Models WG item >=20 >=20 >=20 > | -----Original Message----- > | From: BINET David RD-CORE-CAE [mailto:david.binet@francetelecom.com] > | Sent: Friday, February 04, 2005 10:48 AM > | To: Pascal Thubert (pthubert) > | Cc: nemo@ietf.org > | Subject: RE: [nemo] RE: about the Home Network Models WG item > |=20 > | Hello, > |=20 > | Comments in text > |=20 > | > > | > | > | > | From the draft, I understand that the question about the > | > configuration > | > of > | > | Home Address is only valid in extended mode. In aggregated mode > and > | > | virtual mode, there is no specific Home subnet and Home Address > will > | > be > | > | configured on any MNP. > | > | I think it could be useful to distinguish both modes in current > | > "extended > | > | mode", one if the Home Address is taken from Home Net > | > (basic one) and > | > one > | > | if the home address is taken from Mobile Net (extended one). > | > | > | > > | > I did not see any support for this proposal since. I'm=20 > anxious that=20 > | > it changes what we usually called extended to be only the=20 > case where=20 > | > the address comes from the MNP. People might get=20 > confused, since it=20 > | > was not the most expected usage of extended. > | > > | > I created issue 4 to discuss this point. > | Even if the "extended" term is not really the right one to describe > this > | mode, the most important is to have a common understanding=20 > about its=20 > | description. I think it is the case now. > | I think we can distinguish two sub-modes in extended one,=20 > one if the=20 > | Home Address is configured from Home net and one if the Home Address > is > | configured from Mobile Net. It could be convenient to make it more=20 > | visible in the description of the extended-mode. >=20 > I guess I can do that :) >=20 > I added section 5.3. Please let me know what you think. >=20 > Pascal >=20 From nemo-bounces@ietf.org Fri Feb 4 17:03:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11538 for ; Fri, 4 Feb 2005 17:03:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxBR6-00067b-ON; Fri, 04 Feb 2005 16:56:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxBO0-0005VI-4Z for nemo@megatron.ietf.org; Fri, 04 Feb 2005 16:53:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10323 for ; Fri, 4 Feb 2005 16:53:05 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxBgo-0005OV-LP for nemo@ietf.org; Fri, 04 Feb 2005 17:12:37 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 7447861B4 for ; Fri, 4 Feb 2005 13:51:39 -0800 (PST) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19508-06 for ; Fri, 4 Feb 2005 13:51:32 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 29A6061A7; Fri, 4 Feb 2005 13:51:32 -0800 (PST) Received: from [192.103.16.145] (unknown [192.103.16.145]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 5E54D60F5 for ; Fri, 4 Feb 2005 13:51:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <3f348d63391feec76e17ebe163313973@kniveton.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF NEMO WG From: "T.J.Kniveton" Date: Fri, 4 Feb 2005 13:52:47 -0800 X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Subject: [nemo] Combining / separate Prefix Delegation drafts X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit At the last IETF, I presented the draft on Prefix Delegation, and there was no clear consensus whether that draft should be combined with the existing DHCPv6 PD draft, or they should be advanced as 2 separate WG drafts. Please make any comments on that now. Here is the excerpt from the minutes: > 6. Prefix Delegation ......................................... 10mins > TJ Kniveton > > draft-kniveton-nemo-prefix-delegation-00.txt > > Prefix delegation is included in the charter of the WG > This draft is augmenting the work done by R. Droms > The goal is to use NEMO signaling for prefix delegation > New protocol elements are defined to carry prefix requests > Both Transient (CoA) and Persistent (HoA) prefixes are considered > This approach complements DHCP methods. > NEMO signaling has some additional mobility related attributes > and NEMO based approaches might save flows > Question to the wg is: Is the WG interested in DHCPv6 only method? > Does it make sense to merge this approach with DHCPv6? > > Questions: > ---------- > > Vijay: I don't agree with statement that the two approaches are > complementary. DHCP can provide a complete solution. > TJ: You can have a solution with only DHCP, but there are some > nemo specifics elements missing. You can also have a solution > using only nemo signaling also. So there are three options only > NEMO, DHCP, hybrid. > Vijay: Could we have two proposed methods, where we just have the > DHCPv6, and the other with this apporach? > TJ: We could consider this options. Opinions from the WG? > Pascal: The motivation part of the draft says clearly why we > need this so please read it if you haven't. > Pascal: Do we need to merge this or separate is fine? > Vijay: Separate is fine > TJ: No sense from the room. We proceed working with Ralph and > Pascal and figure out how to integrate those, since there is > no sense from the room > Vidya: MIP6 agreed on using NAI for HoA, are we just relying > on MIP6 for whatever they decide? > TJ: NEMO is an extension on MIP6, whatever agreement HA and MN > have, they'll be a parallel set of rules for MR > Vidya: There needs to be a way for authorizing MR say it's > acceptable to own this prefix > TJ: This is an implementation/policy decision, how do we decide > MR allowed to use a HoA? The same thing happen with prefixes. > TJ: In conclusion, since there's really no strong oppinion. We > could advance both of these documents (DHCP based and NEMO based) > as WG items. > Ryuji: Both mechanisms are statefull, do we need two statefull > mechanisms? Do we need a stateless mechanism? > Erik: This draft will be a wg but i can't find the draft in > id directory > TJ: It was submitted late and it is not in directory > TJ: Ralph's draft is expired From nemo-bounces@ietf.org Fri Feb 4 17:05:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11829 for ; Fri, 4 Feb 2005 17:05:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxBVk-000744-Sa; Fri, 04 Feb 2005 17:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxBQu-00066K-E2 for nemo@megatron.ietf.org; Fri, 04 Feb 2005 16:56:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10810 for ; Fri, 4 Feb 2005 16:56:05 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxBjk-0005VO-6X for nemo@ietf.org; Fri, 04 Feb 2005 17:15:37 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id C9AA561F1 for ; Fri, 4 Feb 2005 13:54:46 -0800 (PST) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19535-06 for ; Fri, 4 Feb 2005 13:54:39 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 8AAD061A7; Fri, 4 Feb 2005 13:54:39 -0800 (PST) Received: from [192.103.16.145] (unknown [192.103.16.145]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id C2B0E60F5 for ; Fri, 4 Feb 2005 13:54:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF NEMO WG From: "T.J.Kniveton" Date: Fri, 4 Feb 2005 13:55:55 -0800 X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Implementations X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit I am putting together the requested list of RFC 3963 implementations. Please send me the following info: Organization Name of Implementation (if any) Description of features supported. HA? MR? Implicit? Explicit? Fully-enabled? etc. Terms of availability (free? cost? internal use only?) Contact e-mail and/or web site Any other info you want to list -TJ From nemo-bounces@ietf.org Fri Feb 4 18:00:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16451 for ; Fri, 4 Feb 2005 18:00:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxCJT-0002SG-Dv; Fri, 04 Feb 2005 17:52:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxCHH-0001xG-EA for nemo@megatron.ietf.org; Fri, 04 Feb 2005 17:50:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15547 for ; Fri, 4 Feb 2005 17:50:12 -0500 (EST) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCa7-0006vN-0N for nemo@ietf.org; Fri, 04 Feb 2005 18:09:45 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j14MoCPJ002026; Fri, 4 Feb 2005 15:50:12 -0700 (MST) Received: from [10.181.32.11] (mvp-10-181-32-11.ea.mot.com [10.181.32.11]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id j14Mmofg019296; Fri, 4 Feb 2005 16:48:51 -0600 Message-ID: <4203FC1B.40507@motorola.com> Date: Fri, 04 Feb 2005 23:50:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J.Kniveton" Subject: Re: [nemo] NEMO Implementations References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060404030805090109020104" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms060404030805090109020104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit What do you plan to do with this list? Alex T.J.Kniveton wrote: > I am putting together the requested list of RFC 3963 implementations. > Please send me the following info: > > Organization > Name of Implementation (if any) > Description of features supported. HA? MR? Implicit? Explicit? > Fully-enabled? etc. > Terms of availability (free? cost? internal use only?) > Contact e-mail and/or web site > Any other info you want to list > > -TJ > > --------------ms060404030805090109020104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAy MDQyMjUwMDNaMCMGCSqGSIb3DQEJBDEWBBTj+5RgJUXWFxkbyVerPnzET9+28jBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYAZBrOmADdt5JyarDJs+DVeC8Xh1K0mAs37WO5Z VE9dwM8+cUmyFAzmiORKEEya1yLsJ+A+/P3mRfCU+zt77VQbKow/Y3tRxFLCY1xQ42YnN5Rm 3ebxh5E04HIggBOalteaJ41gBIBTblYA19s1ZCkGx6kg7BvkdEX/RQM8AHHqZwAAAAAAAA== --------------ms060404030805090109020104-- From nemo-bounces@ietf.org Sat Feb 5 20:48:55 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21517 for ; Sat, 5 Feb 2005 20:48:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxbTI-0000bx-5c; Sat, 05 Feb 2005 20:44:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxbRm-0000Ln-11 for nemo@megatron.ietf.org; Sat, 05 Feb 2005 20:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20885 for ; Sat, 5 Feb 2005 20:42:44 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cxbkq-0004or-88 for nemo@ietf.org; Sat, 05 Feb 2005 21:02:30 -0500 Received: from samurai.local.sfc.wide.ad.jp ([210.130.172.233]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j161fwFj023083; Sun, 6 Feb 2005 10:42:02 +0900 Date: Sun, 06 Feb 2005 10:41:58 +0900 Message-ID: From: Ryuji Wakikawa To: tj@kniveton.com Subject: Re: [nemo] NEMO Implementations In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello TJ. Here is the information of BSD impl. > Organization: WIDE project > Name of Implementation (if any): SHISA > Description of features supported.: All functions except for dynamic routing support > Terms of availability: free > Contact e-mail and/or web site: http://www.mobileip.jp > Any other info you want to list: none thanks ryuji From nemo-bounces@ietf.org Mon Feb 7 15:41:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11733 for ; Mon, 7 Feb 2005 15:41:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyFfY-0003ny-F2; Mon, 07 Feb 2005 15:39:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyFYo-0000CS-Fy for nemo@megatron.ietf.org; Mon, 07 Feb 2005 15:32:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10237 for ; Mon, 7 Feb 2005 15:32:39 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyFsF-0001qq-Ls for nemo@ietf.org; Mon, 07 Feb 2005 15:52:48 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 77B998001A5; Mon, 7 Feb 2005 22:32:07 +0200 (EET) Date: Mon, 7 Feb 2005 22:32:07 +0200 (EET) From: Ville Nuorvala To: "T.J.Kniveton" Subject: Re: [nemo] NEMO Implementations In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Fri, 4 Feb 2005, T.J.Kniveton wrote: Hello TJ, here is the info for our Linux implementation. Organization: Go-Core project at the Helsinki University of Technology Name of Implementation (if any): NEPL Description of features supported.: everything except dynamic routing Terms of availability: NEPL is distributed under the GPL Contact e-mail and/or web site: http://www.mobile-ipv6.org Any other info you want to list: results from the recent 6th TAHI IPv6 Interoperability Test Event can be found at http://www.nautilus6.org/doc/tc-nemo-tahi-interop-20050207-KuntzR.txt Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From nemo-bounces@ietf.org Mon Feb 7 22:31:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04551 for ; Mon, 7 Feb 2005 22:31:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyM4Q-00007k-Dj; Mon, 07 Feb 2005 22:29:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyM2s-0007Gx-Tj for nemo@megatron.ietf.org; Mon, 07 Feb 2005 22:28:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04169 for ; Mon, 7 Feb 2005 22:28:07 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyMMM-0000Q7-Pb for nemo@ietf.org; Mon, 07 Feb 2005 22:48:21 -0500 Received: from iseran.local (unknown [218.44.163.112]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 5B1974C9AF for ; Tue, 8 Feb 2005 12:27:21 +0900 (JST) Date: Tue, 8 Feb 2005 12:31:20 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20050208123120.032579f0.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [nemo] M bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, Someone has jusked ask me what is the M bit in the BU format of RFC3963, and of course I replied it's related to http://www.ietf.org/internet-drafts/draft-ietf-mipshop-hmipv6-04.txt When we revise NEMO BS, I think we should be a bit more explicit than simply saying "the rest of the BU format remains the same as defined in [1]" since the"M" bit is not defined in [1]. This might include a reference to HMIP. Thierry. Devarapalli, et al. Standards Track [Page 6] RFC 3963 NEMO Basic Support Protocol January 2005 4.1. Binding Update A new flag (R) is included in the Binding Update to indicate to the Home Agent whether the Binding Update is coming from a Mobile Router and not from a mobile node. The rest of the Binding Update format remains the same as defined in [1]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- Thierry Ernst, PhD WIDE, Jun Murai Lab., Keio University, Japan Nautilus6 Chair: http://www.nautilus6.org Web: http://www.sfc.wide.ad.jp/~ernst/ T:+81-44-580-1600 F:+81-44-580-1437 -- From nemo-bounces@ietf.org Tue Feb 8 03:29:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15095 for ; Tue, 8 Feb 2005 03:29:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyQj9-00079z-NY; Tue, 08 Feb 2005 03:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyQhS-0006xW-Ec for nemo@megatron.ietf.org; Tue, 08 Feb 2005 03:26:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14842 for ; Tue, 8 Feb 2005 03:26:21 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyR10-0006Dq-B5 for nemo@ietf.org; Tue, 08 Feb 2005 03:46:35 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 0411E80018F; Tue, 8 Feb 2005 10:25:49 +0200 (EET) Date: Tue, 8 Feb 2005 10:25:49 +0200 (EET) From: Ville Nuorvala To: "T.J.Kniveton" Subject: Re: [nemo] NEMO Implementations In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi TJ, I forgot to give Nautilus6 at WIDE their due credit in my announcement. Please use this updated info: Organization: Go-Core project at the Helsinki University of Technology in cooperation with Nautilus6 at WIDE Name of Implementation (if any): NEPL Description of features supported.: everything except dynamic routing Terms of availability: NEPL is distributed under the GPL Contact e-mail and/or web site: http://www.mobile-ipv6.org Any other info you want to list: results from the recent 6th TAHI IPv6 Interoperability Test Event can be found at http://www.nautilus6.org/doc/tc-nemo-tahi-interop-20050207-KuntzR.txt Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From nemo-bounces@ietf.org Tue Feb 8 13:43:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03340 for ; Tue, 8 Feb 2005 13:43:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyaGg-0000Sj-UJ; Tue, 08 Feb 2005 13:39:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyaFD-00006g-Ag for nemo@megatron.ietf.org; Tue, 08 Feb 2005 13:37:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02901 for ; Tue, 8 Feb 2005 13:37:48 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyaYq-0002yX-M2 for nemo@ietf.org; Tue, 08 Feb 2005 13:58:09 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id ED4A86217; Tue, 8 Feb 2005 10:36:11 -0800 (PST) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66816-05; Tue, 8 Feb 2005 10:36:04 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id AE87661BE; Tue, 8 Feb 2005 10:36:04 -0800 (PST) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id A86646127; Tue, 8 Feb 2005 10:36:03 -0800 (PST) In-Reply-To: <4203FC1B.40507@motorola.com> References: <4203FC1B.40507@motorola.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Subject: Re: [nemo] NEMO Implementations Date: Tue, 8 Feb 2005 10:37:38 -0800 To: Alexandru Petrescu X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit On Feb 4, 2005, at 2:50 PM, Alexandru Petrescu wrote: > What do you plan to do with this list? Post it on the web page for the public to see. TJ From nemo-bounces@ietf.org Tue Feb 8 16:40:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28757 for ; Tue, 8 Feb 2005 16:40:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CycB2-0006Lj-Rm; Tue, 08 Feb 2005 15:41:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyc86-0004LP-2R; Tue, 08 Feb 2005 15:38:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15061; Tue, 8 Feb 2005 15:38:36 -0500 (EST) Message-Id: <200502082038.PAA15061@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 08 Feb 2005 15:38:36 -0500 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-home-network-models-02.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : NEMO Home Network models Author(s) : P. Thubert, et al. Filename : draft-ietf-nemo-home-network-models-02.txt Pages : 24 Date : 2005-2-8 This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers, conforming the NEMO Basic Support draft [8]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO related mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-home-network-models-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-home-network-models-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-8160449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-home-network-models-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-home-network-models-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-8160449.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Wed Feb 9 04:26:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12374 for ; Wed, 9 Feb 2005 04:26:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyo55-0005A2-Ew; Wed, 09 Feb 2005 04:24:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyo40-0004b5-6V for nemo@megatron.ietf.org; Wed, 09 Feb 2005 04:23:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12214 for ; Wed, 9 Feb 2005 04:23:09 -0500 (EST) Received: from isis.lip6.fr ([132.227.60.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyoNk-0002Ap-NF for nemo@ietf.org; Wed, 09 Feb 2005 04:43:38 -0500 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.13.1/jtpda-5.4+victor) with ESMTP id j199MS2T005803 ; Wed, 9 Feb 2005 10:22:28 +0100 X-pt: isis.lip6.fr Received: from [132.227.62.151] (dhcp-rp-invite11 [132.227.62.151]) by tibre.lip6.fr (8.11.6p3/8.11.6) with ESMTP id j199MSp07102; Wed, 9 Feb 2005 10:22:28 +0100 (CET) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC801506@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC801506@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Guillaume Chelius Subject: Re: [nemo] Draft proposal for prefix delegation in NEMO Date: Wed, 9 Feb 2005 10:20:51 +0100 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.619.2) X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.5.10 (isis.lip6.fr [132.227.60.2]); Wed, 09 Feb 2005 10:22:28 +0100 (CET) X-Scanned-By: isis.lip6.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, eun@mmlab.snu.ac.kr, Laurent.Toutain@irisa.fr, Eric.Fleury@inria.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Pascal, Sorry for the delay. The protocol presented in this draft is usefull whenever a network or=20= some links are bootstrapped without network administration information=20= or ability. A case of application is indeed to allow the bootstrap of a=20= nested NEMO config. Guillaume. Le 1 f=E9vr. 05, =E0 16:34, Pascal Thubert (pthubert) a =E9crit : > Hi Guillaume: > > Could you please refine a bit on the use case part? > > My quick reading of this draft places it in a nested NEMO = configuration > as a MANET bootstrap solution. > > Pascal > > > > | -----Original Message----- > | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > Of > | Chelius Guillaume > | Sent: Tuesday, February 01, 2005 9:26 AM > | To: nemo@ietf.org > | Cc: eun@mmlab.snu.ac.kr; Laurent.Toutain@irisa.fr; > Eric.Fleury@inria.fr > | Subject: [nemo] Draft proposal for prefix delegation in NEMO > | > | Hi folks, > | > | We submitted a draft about prefix delegation for NEMO. > | This draft proposes a distributed mechanism for prefix > autoconfiguration > | in an > | IPv6 network. > | > = http://www.ietf.org/internet-drafts/draft-chelius-nemo-router-autoconf- > | 00.txt > | > | Contrarily to classical prefix delegation mechanisms such as a DHCP > | adaptation, > | the proposed protocol is completely distributed and does not rely on > any > | centralized server. It uses a link-state approach to detect auto- > | configured > | prefixes collisions as well as to perform collision avoidance while > | attributing > | a prefix to a new link. > | > | Your comments are welcome. > | > | Best regards, > | Guillaume Chelius. > | ---------------------------- > | ARES Project, INRIA > | web: http://ares.insa-lyon.fr/~gchelius > | mail: guillaume.chelius@insa-lyon.fr > | phone: (+33) 472 436 182 > | fax: (+33) 472 436 227 > Guillaume Chelius. ---------------------------- ARES Project, INRIA web: http://ares.insa-lyon.fr/~gchelius mail: guillaume.chelius@insa-lyon.fr phone: (+33) 472 436 182 fax: (+33) 472 436 227 From nemo-bounces@ietf.org Mon Feb 14 10:06:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11247 for ; Mon, 14 Feb 2005 10:06:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0hi6-0005FG-1Y; Mon, 14 Feb 2005 10:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0hdq-0004nD-A2 for nemo@megatron.ietf.org; Mon, 14 Feb 2005 09:56:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10174 for ; Mon, 14 Feb 2005 09:56:00 -0500 (EST) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0hyg-0004G2-6w for nemo@ietf.org; Mon, 14 Feb 2005 10:17:35 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 65160C32B for ; Mon, 14 Feb 2005 09:55:23 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j1EEtMRs027882 for ; Mon, 14 Feb 2005 09:55:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j1EEtM3K004091 for ; Mon, 14 Feb 2005 09:55:22 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 03759-02 for ;Mon, 14 Feb 2005 09:55:22 -0500 (EST) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j1EEtLm q004078for ; Mon, 14 Feb 2005 09:55:21 -0500 (EST) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id 9919E33800F; Mon, 14 Feb 2005 09:55:21 -0500 (EST) Received: from grc.nasa.gov (gr2138224.grc.nasa.gov [139.88.111.45])by webma il.grc.nasa.gov (Postfix) with ESMTP id 4E26F33800Dfor ; Mon , 14 Feb 2005 09:55:21 -0500 (EST) Message-ID: <4210BBDB.3080601@grc.nasa.gov> Date: Mon, 14 Feb 2005 09:55:23 -0500 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.19 X-imss-result: Passed X-imss-approveListMatch: *@*.nasa.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: [nemo] Request for Comment on IPv6-based Global Air Space communicationnet work requirements X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit NASA has formulated a list of requirements to ensure global interoperability and deployment. NASA is seeking comments from various industries, academia and government agencies throughout the world regarding these salient requirements. Comments are being sought from those directly involved in aeronautics, as well as telecommunication, communication, computer and information assurance providers as we believe those outside the traditional aeronautics community have expertise and insight that is directly applicable to network centric operations. Application of commercial off the shelf technologies and techniques will, hopefully, enable network centric operation to be economically and technically realizable over the Global Airspace System. A user friendly URL for this request can be found here: http://roland.grc.nasa.gov/~ivancic/RFI/rfi.html The official announcement is here: http://prod.nais.nasa.gov/cgi-bin/eps/synopsis.cgi?acqid=114192 Please feel free to forward this request to whomever you my feel would benefit -- ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Lab 216-433-2620 Mobile 440-503-4892 Yahoo ID: ivancic http://roland.grc.nasa.gov/~ivancic From nemo-bounces@ietf.org Wed Feb 16 17:23:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04191 for ; Wed, 16 Feb 2005 17:23:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XWA-00050r-QT; Wed, 16 Feb 2005 17:19:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XNL-0000y4-Em for nemo@megatron.ietf.org; Wed, 16 Feb 2005 17:10:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02861 for ; Wed, 16 Feb 2005 17:10:24 -0500 (EST) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Xie-0004cR-6l for nemo@ietf.org; Wed, 16 Feb 2005 17:32:30 -0500 Received: from trust ([211.196.184.168]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id j1GMGTL2003521; Thu, 17 Feb 2005 07:16:30 +0900 (KST) (envelope-from eun@mmlab.snu.ac.kr) Message-Id: <200502162216.j1GMGTL2003521@mmlab.snu.ac.kr> From: "Eun Kyoung PAIK" To: "'Guillaume Chelius'" Subject: RE: [nemo] Draft proposal for prefix delegation in NEMO Date: Thu, 17 Feb 2005 07:10:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUOieerjPKO/cuXSP2lfUr5ebl+HAF6g2Bw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Laurent.Toutain@irisa.fr, Eric.Fleury@inria.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Guillaume, How about revising our draft based on Pascal's comment and submitting -01.txt by Feb. 21 ? Regards, Eun Kyoung > -----Original Message----- > From: Guillaume Chelius [mailto:guillaume.chelius@insa-lyon.fr] > Sent: Wednesday, February 09, 2005 6:21 PM > To: Pascal Thubert (pthubert) > Cc: Laurent.Toutain@irisa.fr; eun@mmlab.snu.ac.kr; nemo@ietf.org; > Eric.Fleury@inria.fr > Subject: Re: [nemo] Draft proposal for prefix delegation in NEMO >=20 > Hi Pascal, >=20 > Sorry for the delay. >=20 > The protocol presented in this draft is usefull whenever a network or > some links are bootstrapped without network administration information > or ability. A case of application is indeed to allow the bootstrap of = a > nested NEMO config. >=20 > Guillaume. >=20 > Le 1 f=E9vr. 05, =E0 16:34, Pascal Thubert (pthubert) a =E9crit : >=20 > > Hi Guillaume: > > > > Could you please refine a bit on the use case part? > > > > My quick reading of this draft places it in a nested NEMO = configuration > > as a MANET bootstrap solution. > > > > Pascal > > > > > > > > | -----Original Message----- > > | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On = Behalf > > Of > > | Chelius Guillaume > > | Sent: Tuesday, February 01, 2005 9:26 AM > > | To: nemo@ietf.org > > | Cc: eun@mmlab.snu.ac.kr; Laurent.Toutain@irisa.fr; > > Eric.Fleury@inria.fr > > | Subject: [nemo] Draft proposal for prefix delegation in NEMO > > | > > | Hi folks, > > | > > | We submitted a draft about prefix delegation for NEMO. > > | This draft proposes a distributed mechanism for prefix > > autoconfiguration > > | in an > > | IPv6 network. > > | > > = http://www.ietf.org/internet-drafts/draft-chelius-nemo-router-autoconf- > > | 00.txt > > | > > | Contrarily to classical prefix delegation mechanisms such as a = DHCP > > | adaptation, > > | the proposed protocol is completely distributed and does not rely = on > > any > > | centralized server. It uses a link-state approach to detect auto- > > | configured > > | prefixes collisions as well as to perform collision avoidance = while > > | attributing > > | a prefix to a new link. > > | > > | Your comments are welcome. > > | > > | Best regards, > > | Guillaume Chelius. > > | ---------------------------- > > | ARES Project, INRIA > > | web: http://ares.insa-lyon.fr/~gchelius > > | mail: guillaume.chelius@insa-lyon.fr > > | phone: (+33) 472 436 182 > > | fax: (+33) 472 436 227 > > > Guillaume Chelius. > ---------------------------- > ARES Project, INRIA > web: http://ares.insa-lyon.fr/~gchelius > mail: guillaume.chelius@insa-lyon.fr > phone: (+33) 472 436 182 > fax: (+33) 472 436 227 >=20 From nemo-bounces@ietf.org Thu Feb 17 00:59:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18955 for ; Thu, 17 Feb 2005 00:59:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1efX-0007XI-1a; Thu, 17 Feb 2005 00:57:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1eeW-0007BD-Cu for nemo@megatron.ietf.org; Thu, 17 Feb 2005 00:56:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18775 for ; Thu, 17 Feb 2005 00:56:36 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ezt-00007y-Ls for nemo@ietf.org; Thu, 17 Feb 2005 01:18:47 -0500 Received: from [IPv6:2001:200:0:8410:20c:f1ff:feaa:6c9a] (unknown [IPv6:2001:200:0:8410:20c:f1ff:feaa:6c9a]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 4E9924C638 for ; Thu, 17 Feb 2005 14:55:51 +0900 (JST) Message-ID: <42143140.5090607@sfc.wide.ad.jp> Date: Thu, 17 Feb 2005 14:53:04 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [nemo] Typos in rfc3963 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, I have just seen 2 typos in rfc3963: * In the Table of Content: 7.1. Modified Dynamic Home Agent Discovery Request . . . . . 20 7.2. Modified Dynamic Home Agent Discovery Address Request . 20 Should be: 7.1. Modified Dynamic Home Agent Address Discovery Request . 20 7.2. Modified Dynamic Home Agent Address Discovery Reply . . 20 * Page 20: 7.1. Modified Dynamic Home Agent Discovery Address Request Should be: 7.1. Modified Dynamic Home Agent Address Discovery Request 7.2. Modified Dynamic Home Agent Discovery Address Request Should be: 7.2. Modified Dynamic Home Agent Address Discovery Reply Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Thu Feb 17 03:21:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22704 for ; Thu, 17 Feb 2005 03:21:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1grf-0000jj-FO; Thu, 17 Feb 2005 03:18:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1gpI-00081i-Qu for nemo@megatron.ietf.org; Thu, 17 Feb 2005 03:15:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22178 for ; Thu, 17 Feb 2005 03:15:55 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1hAh-0003Ke-VA for nemo@ietf.org; Thu, 17 Feb 2005 03:38:04 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1H8jU802787; Thu, 17 Feb 2005 00:45:30 -0800 X-mProtect: <200502170845> Nokia Silicon Valley Messaging Protection Received: from daec-linuxvpn0584.americas.nokia.com (10.241.58.4, claiming to be "[192.168.1.101]") by darkstar.iprg.nokia.com smtpd8Avc1z; Thu, 17 Feb 2005 00:45:27 PST Message-ID: <42145289.8000706@iprg.nokia.com> Date: Thu, 17 Feb 2005 00:15:05 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [nemo] Typos in rfc3963 References: <42143140.5090607@sfc.wide.ad.jp> In-Reply-To: <42143140.5090607@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit I am not sure how the RFC Editor generates the table of contents. the table of contents should really reflect whats there in the text. :) we have to fix it when it is revised. thanks for catching this. Vijay Romain KUNTZ wrote: > Hello, > > I have just seen 2 typos in rfc3963: > > * In the Table of Content: > 7.1. Modified Dynamic Home Agent Discovery Request . . . . . 20 > 7.2. Modified Dynamic Home Agent Discovery Address Request . 20 > Should be: > 7.1. Modified Dynamic Home Agent Address Discovery Request . 20 > 7.2. Modified Dynamic Home Agent Address Discovery Reply . . 20 > > > * Page 20: > 7.1. Modified Dynamic Home Agent Discovery Address Request > Should be: > 7.1. Modified Dynamic Home Agent Address Discovery Request > > 7.2. Modified Dynamic Home Agent Discovery Address Request > Should be: > 7.2. Modified Dynamic Home Agent Address Discovery Reply > > Regards, > From nemo-bounces@ietf.org Sun Feb 20 06:27:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24204 for ; Sun, 20 Feb 2005 06:27:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2nyM-0007ka-1u; Sun, 20 Feb 2005 05:05:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2mXo-00079M-Em for nemo@megatron.ietf.org; Sun, 20 Feb 2005 03:34:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12299 for ; Sun, 20 Feb 2005 03:34:17 -0500 (EST) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2mtk-0001u7-UW for nemo@ietf.org; Sun, 20 Feb 2005 03:57:06 -0500 Received: from trust ([220.121.192.79]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id j1K8dFL2082537; Sun, 20 Feb 2005 17:39:16 +0900 (KST) (envelope-from eun@mmlab.snu.ac.kr) Message-Id: <200502200839.j1K8dFL2082537@mmlab.snu.ac.kr> From: "Eun Kyoung PAIK" To: "'Guillaume Chelius'" , "'Pascal Thubert \(pthubert\)'" Subject: RE: [nemo] Draft proposal for prefix delegation in NEMO Date: Sun, 20 Feb 2005 17:33:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUOieerjPKO/cuXSP2lfUr5ebl+HAInEhjw X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Laurent.Toutain@irisa.fr, Eric.Fleury@inria.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Guillaume,=20 We may submit our draft following BOF, too. http://ietf.org/ietf/05mar/autoconf.txt Regards, Eun Kyoung > -----Original Message----- > From: Guillaume Chelius [mailto:guillaume.chelius@insa-lyon.fr] > Sent: Wednesday, February 09, 2005 6:21 PM > To: Pascal Thubert (pthubert) > Cc: Laurent.Toutain@irisa.fr; eun@mmlab.snu.ac.kr; nemo@ietf.org; > Eric.Fleury@inria.fr > Subject: Re: [nemo] Draft proposal for prefix delegation in NEMO >=20 > Hi Pascal, >=20 > Sorry for the delay. >=20 > The protocol presented in this draft is usefull whenever a network or > some links are bootstrapped without network administration information > or ability. A case of application is indeed to allow the bootstrap of = a > nested NEMO config. >=20 > Guillaume. >=20 > Le 1 f=E9vr. 05, =E0 16:34, Pascal Thubert (pthubert) a =E9crit : >=20 > > Hi Guillaume: > > > > Could you please refine a bit on the use case part? > > > > My quick reading of this draft places it in a nested NEMO = configuration > > as a MANET bootstrap solution. > > > > Pascal > > > > > > > > | -----Original Message----- > > | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On = Behalf > > Of > > | Chelius Guillaume > > | Sent: Tuesday, February 01, 2005 9:26 AM > > | To: nemo@ietf.org > > | Cc: eun@mmlab.snu.ac.kr; Laurent.Toutain@irisa.fr; > > Eric.Fleury@inria.fr > > | Subject: [nemo] Draft proposal for prefix delegation in NEMO > > | > > | Hi folks, > > | > > | We submitted a draft about prefix delegation for NEMO. > > | This draft proposes a distributed mechanism for prefix > > autoconfiguration > > | in an > > | IPv6 network. > > | > > = http://www.ietf.org/internet-drafts/draft-chelius-nemo-router-autoconf- > > | 00.txt > > | > > | Contrarily to classical prefix delegation mechanisms such as a = DHCP > > | adaptation, > > | the proposed protocol is completely distributed and does not rely = on > > any > > | centralized server. It uses a link-state approach to detect auto- > > | configured > > | prefixes collisions as well as to perform collision avoidance = while > > | attributing > > | a prefix to a new link. > > | > > | Your comments are welcome. > > | > > | Best regards, > > | Guillaume Chelius. > > | ---------------------------- > > | ARES Project, INRIA > > | web: http://ares.insa-lyon.fr/~gchelius > > | mail: guillaume.chelius@insa-lyon.fr > > | phone: (+33) 472 436 182 > > | fax: (+33) 472 436 227 > > > Guillaume Chelius. > ---------------------------- > ARES Project, INRIA > web: http://ares.insa-lyon.fr/~gchelius > mail: guillaume.chelius@insa-lyon.fr > phone: (+33) 472 436 182 > fax: (+33) 472 436 227 >=20 From nemo-bounces@ietf.org Mon Feb 21 01:48:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29899 for ; Mon, 21 Feb 2005 01:48:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36sc-0002H7-13; Mon, 21 Feb 2005 01:17:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36jG-0000MZ-HH for nemo@megatron.ietf.org; Mon, 21 Feb 2005 01:07:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27026 for ; Mon, 21 Feb 2005 01:07:28 -0500 (EST) Received: from style.sfc.wide.ad.jp ([203.178.143.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D375M-0006gQ-1i for nemo@ietf.org; Mon, 21 Feb 2005 01:30:27 -0500 Received: from localhost (style.sfc.wide.ad.jp [IPv6:2001:200:0:8801:202:b3ff:fe87:cb44]) by style.sfc.wide.ad.jp (8.13.1/8.13.1) with ESMTP id j1L66Z9M030520 for ; Mon, 21 Feb 2005 15:06:35 +0900 (JST) Date: Mon, 21 Feb 2005 15:06:35 +0900 (JST) Message-Id: <20050221.150635.41659080.watari@sfc.wide.ad.jp> To: nemo@ietf.org From: Masafumi Watari Organization: Keio University X-Mailer: Mew version 4.2rc3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Feb_21_15_06_35_2005_313)--" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [nemo] Fw: I-D ACTION:draft-watari-nemo-nested-cn-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org ----Next_Part(Mon_Feb_21_15_06_35_2005_313)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, We have submitted the revised version of our draft following the comments received on the ML. The draft can be found in the URL below: http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-01.txt Any comments are welcome. Regards, watari ----Next_Part(Mon_Feb_21_15_06_35_2005_313)-- Content-Type: Message/Rfc822 Content-Disposition: inline Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:47ff:fedf:73a6]) by style.sfc.wide.ad.jp (8.13.1/8.13.1) with ESMTP id j1IFwgbI001586 for ; Sat, 19 Feb 2005 00:58:42 +0900 (JST) Received: by mail.sfc.wide.ad.jp (Postfix) id 49EA04C82A; Sat, 19 Feb 2005 00:59:08 +0900 (JST) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 4771B4C68D for ; Sat, 19 Feb 2005 00:59:08 +0900 (JST) Received: by shonan.sfc.wide.ad.jp (Postfix) id F29FF5D1A6; Sat, 19 Feb 2005 00:59:08 +0900 (JST) Delivered-To: watari@sfc.wide.ad.jp Received: from ironport1.sfc.wide.ad.jp (ironport1.sfc.wide.ad.jp [203.178.142.150]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id D76105D129; Sat, 19 Feb 2005 00:59:07 +0900 (JST) Received: from megatron.ietf.org (132.151.6.71) by ironport1.sfc.wide.ad.jp with ESMTP; 19 Feb 2005 00:58:54 +0900 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= X-IronPort-AV: i="3.90,99,1107702000"; d="txt'208?scan'208,208"; a="744359:sNHT89832144" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D29sR-0004eB-8C; Fri, 18 Feb 2005 10:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D29fY-0007hg-GA for i-d-announce@megatron.ietf.org; Fri, 18 Feb 2005 10:03:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11023 for ; Fri, 18 Feb 2005 10:03:46 -0500 (EST) Message-Id: <200502181503.KAA11023@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 18 Feb 2005 10:03:46 -0500 Subject: I-D ACTION:draft-watari-nemo-nested-cn-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on style.sfc.wide.ad.jp X-Spam-Status: No, hits=-4.2 required=4.5 tests=BAYES_00, MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.63 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Route Optimization with Nested Correspondent Nodes Author(s) : T. Ernst, M. Watari Filename : draft-watari-nemo-nested-cn-01.txt Pages : 20 Date : 2005-2-17 This document aims at assisting the problem statement of route optimization in nested mobile networks. We describe the paths packets would take using existing Mobile IPv6 and NEMO Basic Support mechanisms when one or both end nodes of a communication flow are located in a nested NEMO. One of both of the end nodes may themselves be either mobile nodes performing Mobile IPv6, or standard IPv6 nodes performing no mobility function at all. The path can become extremely suboptimal if no optimization is provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-watari-nemo-nested-cn-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-watari-nemo-nested-cn-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-18103437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-watari-nemo-nested-cn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-watari-nemo-nested-cn-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18103437.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- ----Next_Part(Mon_Feb_21_15_06_35_2005_313)---- From nemo-bounces@ietf.org Mon Feb 21 08:19:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23797 for ; Mon, 21 Feb 2005 08:19:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3ChI-0008Nd-4L; Mon, 21 Feb 2005 07:29:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3C7Q-0001xW-DH for nemo@megatron.ietf.org; Mon, 21 Feb 2005 06:52:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16132 for ; Mon, 21 Feb 2005 06:52:39 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3CTX-0006jy-8q for nemo@ietf.org; Mon, 21 Feb 2005 07:15:43 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC900301FMYQM@mailout2.samsung.com> for nemo@ietf.org; Mon, 21 Feb 2005 20:52:10 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC900A33FMY1W@mailout2.samsung.com> for nemo@ietf.org; Mon, 21 Feb 2005 20:52:10 +0900 (KST) Received: from Shubhranshu ([75.2.43.171]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IC9008HTFMXI0@mmp2.samsung.com> for nemo@ietf.org; Mon, 21 Feb 2005 20:52:09 +0900 (KST) Date: Mon, 21 Feb 2005 20:52:09 +0900 From: Shubhranshu Subject: Re: [nemo] Draft proposal for prefix delegation in NEMO To: Eun Kyoung PAIK , "'Guillaume Chelius'" Message-id: <01ec01c5180b$c627a140$ab2b024b@Shubhranshu> Organization: Samsung Electronics MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <200502200839.j1K8dFL2082537@mmlab.snu.ac.kr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: QUOTED-PRINTABLE Hello Eun Kyoung, I would like to know how you are relating your draft with autoconf ? A quick reading of the draft suggests that it can be related with the ad hoc autoconf scenario where manet is connected to the Internet= via gateway. In this case gateway can be ER. However, considering the def= inition "a dedicated router is elected on each * link* " , DR does not make s= ense and it can be very costly in terms of control packet overhead. Regards, Shubhranshu ----- Original Message -----=20 =46rom: "Eun Kyoung PAIK" To: "'Guillaume Chelius'" ; "'Pascal = Thubert (pthubert)'" Cc: ; ; Sent: Sunday, February 20, 2005 5:33 PM Subject: RE: [nemo] Draft proposal for prefix delegation in NEMO Hi Guillaume, We may submit our draft following BOF, too. http://ietf.org/ietf/05mar/autoconf.txt Regards, Eun Kyoung > -----Original Message----- > From: Guillaume Chelius [mailto:guillaume.chelius@insa-lyon.fr] > Sent: Wednesday, February 09, 2005 6:21 PM > To: Pascal Thubert (pthubert) > Cc: Laurent.Toutain@irisa.fr; eun@mmlab.snu.ac.kr; nemo@ietf.org; > Eric.Fleury@inria.fr > Subject: Re: [nemo] Draft proposal for prefix delegation in NEMO > > Hi Pascal, > > Sorry for the delay. > > The protocol presented in this draft is usefull whenever a network= or > some links are bootstrapped without network administration informat= ion > or ability. A case of application is indeed to allow the bootstrap = of a > nested NEMO config. > > Guillaume. > > Le 1 f=E9vr. 05, =E0 16:34, Pascal Thubert (pthubert) a =E9crit : > > > Hi Guillaume: > > > > Could you please refine a bit on the use case part? > > > > My quick reading of this draft places it in a nested NEMO configu= ration > > as a MANET bootstrap solution. > > > > Pascal > > > > > > > > | -----Original Message----- > > | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On B= ehalf > > Of > > | Chelius Guillaume > > | Sent: Tuesday, February 01, 2005 9:26 AM > > | To: nemo@ietf.org > > | Cc: eun@mmlab.snu.ac.kr; Laurent.Toutain@irisa.fr; > > Eric.Fleury@inria.fr > > | Subject: [nemo] Draft proposal for prefix delegation in NEMO > > | > > | Hi folks, > > | > > | We submitted a draft about prefix delegation for NEMO. > > | This draft proposes a distributed mechanism for prefix > > autoconfiguration > > | in an > > | IPv6 network. > > | > > http://www.ietf.org/internet-drafts/draft-chelius-nemo-router-aut= oconf- > > | 00.txt > > | > > | Contrarily to classical prefix delegation mechanisms such as a = DHCP > > | adaptation, > > | the proposed protocol is completely distributed and does not re= ly on > > any > > | centralized server. It uses a link-state approach to detect aut= o- > > | configured > > | prefixes collisions as well as to perform collision avoidance w= hile > > | attributing > > | a prefix to a new link. > > | > > | Your comments are welcome. > > | > > | Best regards, > > | Guillaume Chelius. > > | ---------------------------- > > | ARES Project, INRIA > > | web: http://ares.insa-lyon.fr/~gchelius > > | mail: guillaume.chelius@insa-lyon.fr > > | phone: (+33) 472 436 182 > > | fax: (+33) 472 436 227 > > > Guillaume Chelius. > ---------------------------- > ARES Project, INRIA > web: http://ares.insa-lyon.fr/~gchelius > mail: guillaume.chelius@insa-lyon.fr > phone: (+33) 472 436 182 > fax: (+33) 472 436 227 > From nemo-bounces@ietf.org Wed Feb 23 19:02:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19126 for ; Wed, 23 Feb 2005 19:02:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kju-0005VE-PU; Tue, 22 Feb 2005 19:50:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hEh-0001Ip-EO; Tue, 22 Feb 2005 16:06:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21649; Tue, 22 Feb 2005 16:06:24 -0500 (EST) Message-Id: <200502222106.QAA21649@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:06:24 -0500 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : T. Ernst, et al. Filename : draft-ietf-nemo-multihoming-issues-02.txt Pages : 36 Date : 2005-2-22 This document is an analysis of multihoming in the context of network mobility (NEMO). As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. We also describe possible deployment scenarios and we attempt to identify issues that arise when mobile networks are multihomed while mobility supports is taken care by NEMO Basic Support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160543.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Wed Feb 23 19:08:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20104 for ; Wed, 23 Feb 2005 19:08:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kjx-0005W2-UC; Tue, 22 Feb 2005 19:50:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hF0-0001J4-N9; Tue, 22 Feb 2005 16:06:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21661; Tue, 22 Feb 2005 16:06:44 -0500 (EST) Message-Id: <200502222106.QAA21661@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:06:44 -0500 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-requirements-04.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Goals and Requirements Author(s) : T. Ernst Filename : draft-ietf-nemo-requirements-04.txt Pages : 14 Date : 2005-2-22 Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. The required support mechanisms will be provided in two phases. The first phase, referred to as NEMO Basic Support is to provide session continuity while the necessary optimizations mechanims referred to as NEMO Extended Support might be provided later. This document outlines the goals expected from network mobility support and defines the requirements that must be met by NEMO Basic Support solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-requirements-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-requirements-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160548.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Wed Feb 23 19:12:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21334 for ; Wed, 23 Feb 2005 19:12:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kk0-0005WW-6e; Tue, 22 Feb 2005 19:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hF9-0001Ng-Uv; Tue, 22 Feb 2005 16:06:55 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21683; Tue, 22 Feb 2005 16:06:53 -0500 (EST) Message-Id: <200502222106.QAA21683@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:06:53 -0500 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-terminology-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Terminology Author(s) : T. Ernst, H. Lach Filename : draft-ietf-nemo-terminology-03.txt Pages : 22 Date : 2005-2-22 This document defines a terminology for discussing network mobility issues and solution requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-terminology-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-terminology-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-terminology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-terminology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160555.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Wed Feb 23 20:29:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13546 for ; Wed, 23 Feb 2005 20:29:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3vyG-0006UK-A4; Wed, 23 Feb 2005 07:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3vyE-0006Tx-SH for nemo@megatron.ietf.org; Wed, 23 Feb 2005 07:50:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12609 for ; Wed, 23 Feb 2005 07:50:19 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3wKq-0001Uq-35 for nemo@ietf.org; Wed, 23 Feb 2005 08:13:48 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 450E64CD8B for ; Wed, 23 Feb 2005 21:49:49 +0900 (JST) Date: Wed, 23 Feb 2005 21:53:58 +0900 From: Thierry Ernst To: nemo Message-Id: <20050223215358.20cab146.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [nemo] CFP NEMO WG slot X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, According to the draft agenfa, the NEMO WG would meet: 1500-1530 Break (Refreshments provided) - Ballroom Foyer, 3rd Floor 1530-1730 Afternoon Sessions II INT nemo Network Mobility WG If you want to get a slot to discuss a particular topic and you haven't emailed TJ or myself yet, please do so now and provide the following - topic - issue to be discussed - name of speaker - relevant draft or mailing list thread - length - how does it relate to the WG goals and milestones In addition to the usual slots: - Agenda bashing - Status on WG documents (home model; NEMO BS, Terminology, requirement, MIB, multihoming) - Conclusions and next steps requests on the following topics will be allocated time in priority: - v4 traversal for the NEMO protocol - Prefix Delegation for NEMO BS - Multihoming -- Which issues should be solved by the NEMO WG ? -- Solutions on specific NEMO multihohming issues - RO discussion -- Status -- Do we have concensus on the WG document content ? -- What are the main RO issues to solve - Report of TAHI and Connectathon events Also, if you have submiited a new version of a draft and you haven't announced it yet on the mailing list, please do so and try to raise some discussion. Thierry From nemo-bounces@ietf.org Wed Feb 23 20:35:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15864 for ; Wed, 23 Feb 2005 20:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3vwG-0006QQ-R0; Wed, 23 Feb 2005 07:48:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3vwG-0006QA-10 for nemo@megatron.ietf.org; Wed, 23 Feb 2005 07:48:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12349 for ; Wed, 23 Feb 2005 07:48:06 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3wIg-0001Rx-1h for nemo@ietf.org; Wed, 23 Feb 2005 08:11:35 -0500 Received: from [IPv6:2001:200:0:8410:20c:f1ff:feaa:6c9a] (unknown [IPv6:2001:200:0:8410:20c:f1ff:feaa:6c9a]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 354504C82E for ; Wed, 23 Feb 2005 21:47:16 +0900 (JST) Message-ID: <421C7A92.6080107@sfc.wide.ad.jp> Date: Wed, 23 Feb 2005 21:44:02 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [nemo] draft-kuntz-nemo-multihoming-test-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, We have submitted an updated draft about multihoming tests with multiple mobile routers and multiple prefixes. We just made few editorial changes, updated the references and added some informations about available NEMO implementations. You can find the revised version here: http://www.ietf.org/internet-drafts/draft-kuntz-nemo-multihoming-test-01.txt This draft will be completed this spring with more tests using another implementations. Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Wed Feb 23 22:22:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25241 for ; Wed, 23 Feb 2005 22:22:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3knN-0006hG-4v; Tue, 22 Feb 2005 19:54:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Whf-0001kN-Nf for nemo@megatron.ietf.org; Tue, 22 Feb 2005 04:51:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07680 for ; Tue, 22 Feb 2005 04:51:32 -0500 (EST) Received: from isis.lip6.fr ([132.227.60.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3X42-0006iJ-Vn for nemo@ietf.org; Tue, 22 Feb 2005 05:14:47 -0500 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.13.1/jtpda-5.4+victor) with ESMTP id j1M9p1S9008281 ; Tue, 22 Feb 2005 10:51:01 +0100 X-pt: isis.lip6.fr Received: from [132.227.61.11] (ariane [132.227.61.11]) by tibre.lip6.fr (8.11.6p3/8.11.6) with ESMTP id j1M9osp21201; Tue, 22 Feb 2005 10:50:56 +0100 (CET) In-Reply-To: References: <200502200839.j1K8dFL2082537@mmlab.snu.ac.kr> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Guillaume Chelius Date: Tue, 22 Feb 2005 10:49:24 +0100 To: "T.J.Kniveton" X-Mailer: Apple Mail (2.619.2) X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.5.10 (isis.lip6.fr [132.227.60.2]); Tue, 22 Feb 2005 10:51:01 +0100 (CET) X-Scanned-By: isis.lip6.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Eun Kyoung PAIK , "'Pascal Thubert \(pthubert\)'" , Laurent.Toutain@irisa.fr, Eric.Fleury@inria.fr Subject: [nemo] Re: Reminder on ad-hoc X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello TJ, I think there was some misunderstanding about the draft. It is not an=20 ad hoc network auto-configuration protocol. I tried to make it clear in=20= my last post and I hope I succeed. The draft is a proposal to perform=20= prefix delegation in a distributed way. Regards, Guillaume Chelius. ---------------------------- ARES Project, INRIA web: http://ares.insa-lyon.fr/~gchelius mail: guillaume.chelius@insa-lyon.fr phone: (+33) 472 436 182 fax: (+33) 472 436 227 Le 22 f=E9vr. 05, =E0 02:05, T.J.Kniveton a =E9crit : > For those of you working on ad-hoc network {auto}configuration=20 > protocols, I am glad to see this work happening. Keep in mind,=20 > however, that NEMO does not deal with ad-hoc networks, which should=20 > hopefully be orthagonal with the NEMO solution space. So we will not=20= > be considering ad-hoc protocols or configuration in NEMO as the=20 > charter currently stands. > > -TJ > > From nemo-bounces@ietf.org Wed Feb 23 22:50:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06538 for ; Wed, 23 Feb 2005 22:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kls-00064U-Sk; Tue, 22 Feb 2005 19:52:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Nnw-00007i-LA for nemo@megatron.ietf.org; Mon, 21 Feb 2005 19:21:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03430 for ; Mon, 21 Feb 2005 19:21:19 -0500 (EST) Received: from salzburg.ucdavis.edu ([169.237.104.162]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3OA9-0001Hm-99 for nemo@ietf.org; Mon, 21 Feb 2005 19:44:30 -0500 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by salzburg.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j1M0LIvf021134 for ; Mon, 21 Feb 2005 16:21:18 -0800 (PST) Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1]) by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j1M0LHne007210 for ; Mon, 21 Feb 2005 16:21:17 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id j1M0LH3M007209; Mon, 21 Feb 2005 16:21:17 -0800 (PST) Date: Mon, 21 Feb 2005 16:21:17 -0800 (PST) Message-Id: <200502220021.j1M0LH3M007209@phaenicia.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [nemo] draft-zhao-mip6-rr-ext-01 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, We submit draft-zhao-mip6-rr-ext-00.txt last week and just update it with a 01 version. I think it might be of interests to NEMO WG as well. Both versions can be found in the following URL: http://wwwcsif.cs.ucdavis.edu/~zhaofa/MIP6/ if they have not shown up in the Internet-Drafts directories. Abstract This draft proposes some extensions to the Return Routability Test in MIP6 to address the location privacy issue and enable CN as well as MN to promptly detect the attack that could compromise the security of MIP6 RO mechanism. Your comments are welcome. Regards, fan From nemo-bounces@ietf.org Wed Feb 23 22:50:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06706 for ; Wed, 23 Feb 2005 22:50:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3klt-00064d-Ff; Tue, 22 Feb 2005 19:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3NsF-0000lN-6p for nemo@megatron.ietf.org; Mon, 21 Feb 2005 19:25:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03794 for ; Mon, 21 Feb 2005 19:25:45 -0500 (EST) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3OER-0001Pg-Ii for nemo@ietf.org; Mon, 21 Feb 2005 19:48:56 -0500 Received: from citheronia.ucdavis.edu (citheronia.ucdavis.edu [169.237.104.183]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j1M0PhAl015013 for ; Mon, 21 Feb 2005 16:25:44 -0800 (PST) Received: from citheronia.ucdavis.edu (localhost [127.0.0.1]) by citheronia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j1M0Phg4000860 for ; Mon, 21 Feb 2005 16:25:43 -0800 (PST) Received: (from www@localhost) by citheronia.ucdavis.edu (8.12.10/8.12.9/Submit) id j1M0Ph7q000859; Mon, 21 Feb 2005 16:25:43 -0800 (PST) Date: Mon, 21 Feb 2005 16:25:43 -0800 (PST) Message-Id: <200502220025.j1M0Ph7q000859@citheronia.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [nemo] draft-zhao-nemo-ro-ps-01 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, We have submitted draft-zhao-nemo-ro-ps-01. It can be found in the following URL: http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ if it has not shown up in the Internet-Drafts directories. Abstract This document describes the routing optimization problem in NEMO and analyzes the related approaches to solve this problem. Your comments are welcome. Thanks. Sincerely, fan From nemo-bounces@ietf.org Wed Feb 23 22:54:43 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08132 for ; Wed, 23 Feb 2005 22:54:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3km1-00067K-3i; Tue, 22 Feb 2005 19:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3OVa-0005IC-BE for nemo@megatron.ietf.org; Mon, 21 Feb 2005 20:06:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07453 for ; Mon, 21 Feb 2005 20:06:29 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3OrY-0002Sz-6u for nemo@ietf.org; Mon, 21 Feb 2005 20:29:41 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 84E4261F1; Mon, 21 Feb 2005 17:03:34 -0800 (PST) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63245-03; Mon, 21 Feb 2005 17:03:27 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 44A6D61D7; Mon, 21 Feb 2005 17:03:27 -0800 (PST) Received: from [192.103.16.145] (unknown [192.103.16.145]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 2EA6160ED; Mon, 21 Feb 2005 17:03:26 -0800 (PST) In-Reply-To: <200502200839.j1K8dFL2082537@mmlab.snu.ac.kr> References: <200502200839.j1K8dFL2082537@mmlab.snu.ac.kr> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Date: Mon, 21 Feb 2005 17:05:21 -0800 To: "Eun Kyoung PAIK" X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: "'Guillaume Chelius'" , nemo@ietf.org, "'Pascal Thubert \(pthubert\)'" , Laurent.Toutain@irisa.fr, Eric.Fleury@inria.fr Subject: [nemo] Reminder on ad-hoc X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit For those of you working on ad-hoc network {auto}configuration protocols, I am glad to see this work happening. Keep in mind, however, that NEMO does not deal with ad-hoc networks, which should hopefully be orthagonal with the NEMO solution space. So we will not be considering ad-hoc protocols or configuration in NEMO as the charter currently stands. -TJ From nemo-bounces@ietf.org Wed Feb 23 23:28:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18942 for ; Wed, 23 Feb 2005 23:28:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3knM-0006gZ-4u; Tue, 22 Feb 2005 19:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3WdV-0001Ka-FC for nemo@megatron.ietf.org; Tue, 22 Feb 2005 04:47:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07156 for ; Tue, 22 Feb 2005 04:47:19 -0500 (EST) Received: from isis.lip6.fr ([132.227.60.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Wzx-0006YV-OL for nemo@ietf.org; Tue, 22 Feb 2005 05:10:34 -0500 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.13.1/jtpda-5.4+victor) with ESMTP id j1M9kn31007693 ; Tue, 22 Feb 2005 10:46:49 +0100 X-pt: isis.lip6.fr Received: from [132.227.61.11] (ariane [132.227.61.11]) by tibre.lip6.fr (8.11.6p3/8.11.6) with ESMTP id j1M9kmp20983; Tue, 22 Feb 2005 10:46:49 +0100 (CET) In-Reply-To: <01ec01c5180b$c627a140$ab2b024b@Shubhranshu> References: <200502200839.j1K8dFL2082537@mmlab.snu.ac.kr> <01ec01c5180b$c627a140$ab2b024b@Shubhranshu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <25558142ed842453c43e285fbbb59f59@insa-lyon.fr> Content-Transfer-Encoding: quoted-printable From: Guillaume Chelius Subject: Re: [nemo] Draft proposal for prefix delegation in NEMO Date: Tue, 22 Feb 2005 10:45:18 +0100 To: Shubhranshu X-Mailer: Apple Mail (2.619.2) X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.5.10 (isis.lip6.fr [132.227.60.2]); Tue, 22 Feb 2005 10:46:49 +0100 (CET) X-Scanned-By: isis.lip6.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Eun Kyoung PAIK X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Shubhranshu, Our draft is not related with MANet autoconf. MANet autoconf aims at =20 providing unicast addresses to MANet nodes which is not the case in our =20= draft. Our goal is to number links, in other words to attribute Subnet =20= IDs to links, in a classical network (e.g. SOHO) where some =20 dynamicity can occur. It is an alternate and distributed proposal to =20 classical prefix delegation mechanisms. Consider a network which is bootstrapped or modified (addiction of new =20= links or addition of some mobile networks). Our protocol allows the =20 automatic attribution of subnet ids for the new links with the =20 insurance that there will be no collisions with already attributed =20 subnet ids. The protocol will also resolve prefix collisions when two =20= auto-configured networks merge. This protocol is useful as soon as an =20= IPv6 network is not managed by a human administrator which could do all =20= the numbering stuff: for example, at home, you can not ask a regular =20= person to have IPv6 skills in order to administrate its personnal =20 network. Another application is for networks where there are some =20 dynamicity and which dynamicity is a regular behavior (temporal merging =20= of networks or temporal creation of links) like NEMOs and where you can =20= not ask an administrator to permanentlly watch the network in order to =20= respond to events. In a classical environment (as opposed to MANet), election of a =20 dedicated router is not a costly operation. It is done for example by =20= the OSPF protocol which elects a DR on each network link. Keep in mind =20= that we are considering classical networks such as SOHO and not highly =20= dynamic MANets. Best regards, Guillaume Chelius. ---------------------------- ARES Project, INRIA web: http://ares.insa-lyon.fr/~gchelius mail: guillaume.chelius@insa-lyon.fr phone: (+33) 472 436 182 fax: (+33) 472 436 227 Le 21 f=E9vr. 05, =E0 12:52, Shubhranshu a =E9crit : > Hello Eun Kyoung, > > I would like to know how you are relating your draft with autoconf ? > > A quick reading of the draft suggests that it can be related with > the ad hoc autoconf scenario where manet is connected to the Internet =20= > via > gateway. In this case gateway can be ER. However, considering the =20 > definition > "a dedicated router is elected on each * link* " , DR does not make =20= > sense > and it can be very costly in terms of control packet overhead. > > Regards, > Shubhranshu > > > ----- Original Message ----- > From: "Eun Kyoung PAIK" > To: "'Guillaume Chelius'" ; "'Pascal =20= > Thubert (pthubert)'" > Cc: ; ; = > Sent: Sunday, February 20, 2005 5:33 PM > Subject: RE: [nemo] Draft proposal for prefix delegation in NEMO > > > Hi Guillaume, > > We may submit our draft following BOF, too. > > http://ietf.org/ietf/05mar/autoconf.txt > > Regards, > Eun Kyoung > >> -----Original Message----- >> From: Guillaume Chelius [mailto:guillaume.chelius@insa-lyon.fr] >> Sent: Wednesday, February 09, 2005 6:21 PM >> To: Pascal Thubert (pthubert) >> Cc: Laurent.Toutain@irisa.fr; eun@mmlab.snu.ac.kr; nemo@ietf.org; >> Eric.Fleury@inria.fr >> Subject: Re: [nemo] Draft proposal for prefix delegation in NEMO >> >> Hi Pascal, >> >> Sorry for the delay. >> >> The protocol presented in this draft is usefull whenever a network = or >> some links are bootstrapped without network administration = information >> or ability. A case of application is indeed to allow the bootstrap of = =20 >> a >> nested NEMO config. >> >> Guillaume. >> >> Le 1 f=E9vr. 05, =E0 16:34, Pascal Thubert (pthubert) a =E9crit : >> >>> Hi Guillaume: >>> >>> Could you please refine a bit on the use case part? >>> >>> My quick reading of this draft places it in a nested NEMO =20 >>> configuration >>> as a MANET bootstrap solution. >>> >>> Pascal >>> >>> >>> >>> | -----Original Message----- >>> | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On =20 >>> Behalf >>> Of >>> | Chelius Guillaume >>> | Sent: Tuesday, February 01, 2005 9:26 AM >>> | To: nemo@ietf.org >>> | Cc: eun@mmlab.snu.ac.kr; Laurent.Toutain@irisa.fr; >>> Eric.Fleury@inria.fr >>> | Subject: [nemo] Draft proposal for prefix delegation in NEMO >>> | >>> | Hi folks, >>> | >>> | We submitted a draft about prefix delegation for NEMO. >>> | This draft proposes a distributed mechanism for prefix >>> autoconfiguration >>> | in an >>> | IPv6 network. >>> | >>> http://www.ietf.org/internet-drafts/draft-chelius-nemo-router-=20 >>> autoconf- >>> | 00.txt >>> | >>> | Contrarily to classical prefix delegation mechanisms such as a = DHCP >>> | adaptation, >>> | the proposed protocol is completely distributed and does not rely =20= >>> on >>> any >>> | centralized server. It uses a link-state approach to detect auto- >>> | configured >>> | prefixes collisions as well as to perform collision avoidance = while >>> | attributing >>> | a prefix to a new link. >>> | >>> | Your comments are welcome. >>> | >>> | Best regards, >>> | Guillaume Chelius. >>> | ---------------------------- >>> | ARES Project, INRIA >>> | web: http://ares.insa-lyon.fr/~gchelius >>> | mail: guillaume.chelius@insa-lyon.fr >>> | phone: (+33) 472 436 182 >>> | fax: (+33) 472 436 227 >>> >> Guillaume Chelius. >> ---------------------------- >> ARES Project, INRIA >> web: http://ares.insa-lyon.fr/~gchelius >> mail: guillaume.chelius@insa-lyon.fr >> phone: (+33) 472 436 182 >> fax: (+33) 472 436 227 >> > > > > > > From nemo-bounces@ietf.org Thu Feb 24 01:06:40 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24756 for ; Thu, 24 Feb 2005 01:06:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D48e6-0001Nm-SR; Wed, 23 Feb 2005 21:22:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D48e4-0001Md-Rs for nemo@megatron.ietf.org; Wed, 23 Feb 2005 21:22:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02809 for ; Wed, 23 Feb 2005 21:22:25 -0500 (EST) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D490p-00071o-1x for nemo@ietf.org; Wed, 23 Feb 2005 21:46:02 -0500 Received: from mozart.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1O2ItgV022732 for ; Thu, 24 Feb 2005 10:18:55 +0800 (SGT) Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 76CB520C1A0; Thu, 24 Feb 2005 10:34:38 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-/NVPLcd7AfwnMELA6CX7" Organization: Panasonic Singapore Laboratories Date: Thu, 24 Feb 2005 10:34:38 +0800 Message-Id: <1109212478.19951.18.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-04.txt] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-/NVPLcd7AfwnMELA6CX7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, we have updated the RO-Taxonomy draft. Changes are: - broken the text into more coherent sections: - 2. Problem statement - 3. Benefits of RO - 4. Types of RO - 5. Issues of RO - 6. Analysis of Problem Space - added descriptions of using MANET within NEMO The current contents of the draft is largely in accordance to those specified in the current WG charter, though my understanding based on San Diego is that some members of the WG wanted something different, particularly only a short WG problem statement draft without analysis of solution space. I think the next step is for the WG to get consensus on what the draft should contain, and the current authors of the relevant drafts can then get together and combine their individual drafts into a WG draft. Oh, and yes, as always comments/criticisms on the RO-taxonomy draft is always welcomed, regardless of harsh, gentle, or otherwise :). /rgds /cwng -------- Forwarded Message -------- From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-thubert-nemo-ro-taxonomy-04.txt Date: Tue, 22 Feb 2005 15:55:54 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Taxonomy of Route Optimization models in the Nemo Context Author(s) : P. Thubert, et al. Filename : draft-thubert-nemo-ro-taxonomy-04.txt Pages : 37 Date : 2005-2-22 With current Network Mobility (NEMO) Basic Support, all communications to and from mobile network nodes must go through the MR-HA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay. To overcome these limitations, one might have to turn to route optimization (RO) for NEMO. This memo documents various types of route optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO route optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-thubert-nemo-ro-taxonomy-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thubert-nemo-ro-taxonomy-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. reference to remote file attachment Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thubert-nemo-ro-taxonomy-04.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=-/NVPLcd7AfwnMELA6CX7 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA1LTItMjIxNjAyMjAuSS1E QGlldGYub3JnPgoKRU5DT0RJTkcgbWltZQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1 YmVydC1uZW1vLXJvLXRheG9ub215LTA0LnR4dAo= --=-/NVPLcd7AfwnMELA6CX7 Content-Type: Message/External-body; name="draft-thubert-nemo-ro-taxonomy-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA1LTItMjIxNjAyMjAuSS1E QGlldGYub3JnPgoK --=-/NVPLcd7AfwnMELA6CX7-- From nemo-bounces@ietf.org Thu Feb 24 01:30:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03794 for ; Thu, 24 Feb 2005 01:30:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4AhW-0005Ys-FJ; Wed, 23 Feb 2005 23:34:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4AhU-0005W1-Jw for nemo@megatron.ietf.org; Wed, 23 Feb 2005 23:34:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20397 for ; Wed, 23 Feb 2005 23:34:05 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4B4I-0003wh-4Z for nemo@ietf.org; Wed, 23 Feb 2005 23:57:44 -0500 Received: from [192.168.0.8] (p4167-ipbf713marunouchi.tokyo.ocn.ne.jp [222.149.251.167]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j1O4UbFk023291; Thu, 24 Feb 2005 13:30:37 +0900 Date: Thu, 24 Feb 2005 13:31:03 +0900 From: Ryuji Wakikawa To: "T.J.Kniveton" Subject: Re: [nemo] Reminder on ad-hoc In-Reply-To: References: <200502200839.j1K8dFL2082537@mmlab.snu.ac.kr> Message-Id: <20050224132756.D517.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] X-Spam-Score: 2.4 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Eun Kyoung PAIK , "'Pascal Thubert \(pthubert\)'" , Eric.Fleury@inria.fr, "'Guillaume Chelius'" , Laurent.Toutain@irisa.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi TJ and All Pascal, Greg and I launched a MANEMO maillist to discuss the integration of MANET and NEMO. if you are interested in, please visit here. http://www.mobileip.jp/mailman/listinfo/manemo regards, ryuji > For those of you working on ad-hoc network {auto}configuration > protocols, I am glad to see this work happening. Keep in mind, however, > that NEMO does not deal with ad-hoc networks, which should hopefully be > orthagonal with the NEMO solution space. So we will not be considering > ad-hoc protocols or configuration in NEMO as the charter currently > stands. > > -TJ From nemo-bounces@ietf.org Thu Feb 24 04:30:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23497 for ; Thu, 24 Feb 2005 04:30:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4FJB-0001US-4H; Thu, 24 Feb 2005 04:29:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4FJ6-0001Ox-Cj for nemo@megatron.ietf.org; Thu, 24 Feb 2005 04:29:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23295 for ; Thu, 24 Feb 2005 04:29:14 -0500 (EST) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Ffx-0008HW-Lu for nemo@ietf.org; Thu, 24 Feb 2005 04:52:54 -0500 Received: from mozart.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1O9PkhS010405 for ; Thu, 24 Feb 2005 17:25:46 +0800 (SGT) Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 3FAC6206807; Thu, 24 Feb 2005 17:41:31 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt From: Chan-Wah Ng To: IETF NEMO WG In-Reply-To: <200502222106.QAA21649@ietf.org> References: <200502222106.QAA21649@ietf.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Date: Thu, 24 Feb 2005 17:41:30 +0800 Message-Id: <1109238091.19951.25.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello all, Like to highlight what are the main changes to this version of the draft. Changes are basically minimal, with the most important change as the addition of the authors' opinions on which WG(s) is/are better suited to address each of the issues listed in Sect 4. These additions, as I'd said, is largely the opinions of the authors, so it is subjected to the WG's consensus. Would thus like to make use of the slot in Minneapolis to talk a little about it. Thanks, /rgds /cwng On Tue, 2005-02-22 at 16:06 -0500, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > Title : Analysis of Multihoming in Network Mobility Support > Author(s) : T. Ernst, et al. > Filename : draft-ietf-nemo-multihoming-issues-02.txt > Pages : 36 > Date : 2005-2-22 > > This document is an analysis of multihoming in the context of network > mobility (NEMO). As there are many situations in which mobile > networks may be multihomed, a taxonomy is proposed to classify the > possible configurations. We also describe possible deployment > scenarios and we attempt to identify issues that arise when mobile > networks are multihomed while mobility supports is taken care by NEMO > Basic Support. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-multihoming-issues-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > reference to remote file attachment > Content-Type: Message/External-body; access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <2005-2-22160543.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt From nemo-bounces@ietf.org Thu Feb 24 05:52:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00160 for ; Thu, 24 Feb 2005 05:52:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Gac-0006Yr-TW; Thu, 24 Feb 2005 05:51:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4GaW-0006Xg-Gv for nemo@megatron.ietf.org; Thu, 24 Feb 2005 05:51:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00087 for ; Thu, 24 Feb 2005 05:51:17 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4GxO-0001V3-Dp for nemo@ietf.org; Thu, 24 Feb 2005 06:14:58 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 11E8F5D5A5; Thu, 24 Feb 2005 11:51:09 +0100 (CET) Received: from [163.117.139.55] (unknown [163.117.139.55]) by smtp01.uc3m.es (Postfix) with ESMTP id F1BE95D5A4; Thu, 24 Feb 2005 11:51:08 +0100 (CET) In-Reply-To: <20050223215358.20cab146.ernst@sfc.wide.ad.jp> References: <20050223215358.20cab146.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] CFP NEMO WG slot Date: Thu, 24 Feb 2005 11:51:09 +0100 To: Thierry Ernst X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, i would like to present the draft about multi6 and nemo - topic: nemo multihoming - issue to be discussed: application of multi6 to nemo - name of speaker: marcelo bagnulo - relevant draft or mailing list thread:=20 http://www.ietf.org/internet-drafts/draft-bagnulo-nemo-multi6-00.txt - length: 10 min - how does it relate to the WG goals and milestones: it provides some=20 inforamtion about how appropriate is multi6 to provide nemo multihoming=20= support regards, marcelo El 23/02/2005, a las 13:53, Thierry Ernst escribi=F3: > > Dear all, > > According to the draft agenfa, the NEMO WG would meet: > 1500-1530 Break (Refreshments provided) - Ballroom Foyer, 3rd Floor > 1530-1730 Afternoon Sessions II > INT nemo Network Mobility WG > > If you want to get a slot to discuss a particular topic and you = haven't > emailed TJ or myself yet, please do so now and provide the following > - topic > - issue to be discussed > - name of speaker > - relevant draft or mailing list thread > - length > - how does it relate to the WG goals and milestones > > In addition to the usual slots: > - Agenda bashing > - Status on WG documents > (home model; NEMO BS, Terminology, requirement, MIB, multihoming) > - Conclusions and next steps > > requests on the following topics will be allocated time in priority: > - v4 traversal for the NEMO protocol > - Prefix Delegation for NEMO BS > - Multihoming > -- Which issues should be solved by the NEMO WG ? > -- Solutions on specific NEMO multihohming issues=20 > - RO discussion > -- Status > -- Do we have concensus on the WG document content ? > -- What are the main RO issues to solve > - Report of TAHI and Connectathon events > > > Also, if you have submiited a new version of a draft and you haven't > announced it yet on the mailing list, please do so and try to raise=20 > some > discussion. > > Thierry > From nemo-bounces@ietf.org Thu Feb 24 05:53:55 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00222 for ; Thu, 24 Feb 2005 05:53:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4GbG-0006rn-Fh; Thu, 24 Feb 2005 05:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4GbD-0006qD-Vo for nemo@megatron.ietf.org; Thu, 24 Feb 2005 05:52:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00129 for ; Thu, 24 Feb 2005 05:52:01 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Gy6-0001W1-HT for nemo@ietf.org; Thu, 24 Feb 2005 06:15:43 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6EACD5D5BE for ; Thu, 24 Feb 2005 11:51:54 +0100 (CET) Received: from [163.117.139.55] (unknown [163.117.139.55]) by smtp01.uc3m.es (Postfix) with ESMTP id 58B265D5BD for ; Thu, 24 Feb 2005 11:51:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <200502222106.QAA21649@ietf.org> References: <200502222106.QAA21649@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <72f0a85ad43327f48abfec959488595c@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt Date: Thu, 24 Feb 2005 11:51:54 +0100 To: nemo WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, a while ago i made several comments about the previous version of this =20= draft, which you can find in =20 http://www.ietf.org/mail-archive/web/nemo/current/msg01970.html but is =20= didn't receive any answer and i think they were not included in the =20 draft, could some of the authors comment on that? Thanks, marcelo El 22/02/2005, a las 22:06, Internet-Drafts@ietf.org escribi=F3: > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > This draft is a work item of the Network Mobility Working Group of the = =20 > IETF. > > Title : Analysis of Multihoming in Network Mobility = Support > Author(s) : T. Ernst, et al. > Filename : draft-ietf-nemo-multihoming-issues-02.txt > Pages : 36 > Date : 2005-2-22 > =09 > This document is an analysis of multihoming in the context of network > mobility (NEMO). As there are many situations in which mobile > networks may be multihomed, a taxonomy is proposed to classify the > possible configurations. We also describe possible deployment > scenarios and we attempt to identify issues that arise when mobile > networks are multihomed while mobility supports is taken care by =20= > NEMO > Basic Support. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-=20 > issues-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of = =20 > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the =20= > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-multihoming-issues-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE = /internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail = readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-2-22160543.I-D@ietf.org> > From nemo-bounces@ietf.org Thu Feb 24 07:08:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07806 for ; Thu, 24 Feb 2005 07:08:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4HfU-0002B1-II; Thu, 24 Feb 2005 07:00:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4HfP-00028i-Ej for nemo@megatron.ietf.org; Thu, 24 Feb 2005 07:00:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06815 for ; Thu, 24 Feb 2005 07:00:24 -0500 (EST) Received: from netlx010.civ.utwente.nl ([130.89.1.92]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4I2H-000319-Co for nemo@ietf.org; Thu, 24 Feb 2005 07:24:06 -0500 Received: from utwenteweiwei (kabel219029.mobiel.utwente.nl [130.89.219.29]) by netlx010.civ.utwente.nl (8.11.7/HKD) with SMTP id j1OBpQw12953 for ; Thu, 24 Feb 2005 12:51:26 +0100 Message-ID: <003801c51a67$2284a840$1ddb5982@utwenteweiwei> From: "weiwei" To: Date: Thu, 24 Feb 2005 12:51:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C51A6F.82E9A750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-MailScanner-From: xuw@cs.utwente.nl X-Spam-Score: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [nemo] question about multihoming X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weiwei List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C51A6F.82E9A750 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQogY291bGQgYW55b25lIHRlbGwgbWUgdGhlIGJlbmVmaXRzIG9mIChuLDEsbikg b3ZlciAobiwxLDEpIHdoZW4gY29uc2lkZXJpbmcgbXVsdGlob21pbmc/DQoNCnRoYW5rcywNCg0K d2Vpd2Vp ------=_NextPart_000_0035_01C51A6F.82E9A750 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI2MDQiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5EZWFyIGFsbCw8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDtjb3VsZCBhbnlvbmUgdGVsbCBtZSB0aGUg YmVuZWZpdHMgb2YgKG4sMSxuKSBvdmVyIA0KKG4sMSwxKSB3aGVuIGNvbnNpZGVyaW5nIG11bHRp aG9taW5nPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPnRoYW5rcyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj53ZWl3ZWk8L0ZPTlQ+ PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0035_01C51A6F.82E9A750-- From nemo-bounces@ietf.org Thu Feb 24 08:29:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17509 for ; Thu, 24 Feb 2005 08:29:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4J0H-0002pA-CX; Thu, 24 Feb 2005 08:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4J0E-0002oz-OA for nemo@megatron.ietf.org; Thu, 24 Feb 2005 08:26:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17243 for ; Thu, 24 Feb 2005 08:26:01 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JN8-0005W6-TL for nemo@ietf.org; Thu, 24 Feb 2005 08:49:43 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2005 14:42:53 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1ODP4mS000547; Thu, 24 Feb 2005 14:25:48 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 14:25:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Draft proposal for prefix delegation in NEMO Date: Thu, 24 Feb 2005 14:25:35 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC92D055@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Draft proposal for prefix delegation in NEMO Thread-Index: AcUaKW1jacB4zzWNSCyX6OBEyRgeuwAGjCfg From: "Pascal Thubert \(pthubert\)" To: "Guillaume Chelius" , "Shubhranshu" X-OriginalArrivalTime: 24 Feb 2005 13:25:41.0631 (UTC) FILETIME=[564C80F0:01C51A74] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Eun Kyoung PAIK X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Guillaume Chelius | Sent: Tuesday, February 22, 2005 10:45 AM | To: Shubhranshu | Cc: nemo@ietf.org; Eun Kyoung PAIK | Subject: Re: [nemo] Draft proposal for prefix delegation in NEMO |=20 | Hello Shubhranshu, |=20 | Our draft is not related with MANet autoconf. MANet autoconf aims at | providing unicast addresses to MANet nodes which is not the case in our | draft. Our goal is to number links, in other words to attribute Subnet | IDs to links, in a classical network (e.g. SOHO) where some | dynamicity can occur. It is an alternate and distributed proposal to | classical prefix delegation mechanisms. I would be disappointed that this be out of autoconf scope: we have a number of MANET protocols that can carry not only host addresses but also prefixes, and there are a number of use cases where this is required (see MANEMO). So there is a very good value in populating prefixes as well. Also, MANET does not necessarily mean moving a lot. It's more like no preengineered structure and everyone keeps his address. But even that might need a bootstrap. There again, MANEMO should cover mostly fixed configurations (such as L3 mesh networks). So I see a great value in your draft in that space. Pascal From nemo-bounces@ietf.org Thu Feb 24 08:31:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17683 for ; Thu, 24 Feb 2005 08:31:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4J3a-00046o-Nu; Thu, 24 Feb 2005 08:29:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4J3Y-00043H-Eb for nemo@megatron.ietf.org; Thu, 24 Feb 2005 08:29:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17538 for ; Thu, 24 Feb 2005 08:29:26 -0500 (EST) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JQR-0005aU-EH for nemo@ietf.org; Thu, 24 Feb 2005 08:53:08 -0500 Received: from mozart.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1ODPukB014830; Thu, 24 Feb 2005 21:25:56 +0800 (SGT) Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 13A8E206807; Thu, 24 Feb 2005 21:41:43 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: <72f0a85ad43327f48abfec959488595c@it.uc3m.es> References: <200502222106.QAA21649@ietf.org> <72f0a85ad43327f48abfec959488595c@it.uc3m.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Date: Thu, 24 Feb 2005 21:41:42 +0800 Message-Id: <1109252502.19951.68.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: 7bit Cc: nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Marcelo, On Thu, 2005-02-24 at 11:51 +0100, marcelo bagnulo braun wrote: > Hi, > > a while ago i made several comments about the previous version of this > draft, which you can find in > http://www.ietf.org/mail-archive/web/nemo/current/msg01970.html but is > didn't receive any answer and i think they were not included in the > draft, could some of the authors comment on that? > Thanks, marcelo > I am sorry, I must have missed your earlier mail. Let me response to it now. On Tue, 2004-11-16 at 19:16 +0100, marcelo bagnulo braun wrote: > Hi all, > > just some additional comments about this draft > > Section 2. states that: > > One thing the reader has to keep in mind is that in each of the > following 8 cases, the MR may be multihomed if either (i) multiple > prefixes are advertised on the home link, (ii) multiple prefixes are > advertised on the visited link, > > Now, i am not sure the ii) case is relevant here. I mean, in this case, > the visited network is the one that is multihomed, not the NEMO. In > this case, the MR will be just on more node within the multihomed > visited network. I don't have a strong opinion on this, just that i was > puzzled when i saw it there, since this doesn't fail into my definition > of nemo multihoming. anyway... The impact of case (ii) are mostly concerned with a general multihomed mobile node. Since the operation of NEMO Basic Support is largely based on Mobile IPv6, concerns of multihomed mobile node would impact a mobile router as well. So, for completeness, we feel it is necessary to voice it out. Later in the issues section, we should have pointed that concerns for the case (ii) are not NEMO-Specific, and recommends that NEMO to be compatible with whatever solutions other WG comes up with. > > > Section 4.3 Ingress Filtering states that: > > A simple solution is to require all > MNNs to set their default router to the MR that advertises the MNP > the MNNs configured their addresses from. > > Now this is not simple as it seems. > What if you have the following configuration > > > +----+ +-----+ > | MR1| | MR2 | > +----+ +-----+ > | | > ----------------------- > | > +----+ > | R | > +----+ > | > ----------------- > LAN2 > > What is R supposed to advertise in LAN? I guess that in order to apply > this approach in this configuration you will need to add an additional > router in LAN2 so that you have two routers so that each one can > advertise a different prefix (this basically means that you will need > to build as many paralel netwroks as you have prefixes (this is not > what i would call simple) > I guess that simply adding that in some configurations like the one i > depicted above this mechanism is not good would be enough Hmm, let's explore this a bit further. Router R is also an MNN on the NEMO, yes? So it should follow the same rule. Now R can advertise both prefixes, but it must add a route to its routing table so that all packets with source prefix P1 is routed to MR1, and all packet with source prefix P2 is routed to MR2 (assuming MR1 advertises P1 and MR2 advertises P2). Would this work? > Next, in the same section it is stated that: > > For a possible approach, see [12]. > > I haven't read the latest version of this draft, but i don't know how > this draft can help here, i mean the problem here is a problem with > source address selection not with destiantion. I mean you need a > mechanism to convey the hosts the following information: for a source > address with prefix P1, you must use a give router for forwarding. Last > version i read of 12, it stated that: for a destination address the use > router X, which is different and not what is needed. am i missing > something? besides, the previous comment still holds here. i.e. the > configuration depicted above is not trivially supported. > > Then, it is stated that: > > If the tunnel to HA1 is broken, packets would be sent through the > tunnel to HA1 are diverted through the tunnel to HA2. > > Well, i guess this is not only a problem with ingress filtering but > also about fault tolerance. I mean, even if there were no ingress > filtering in place, the reply packets addressed to the address that > contains the prefix corresponding to the HA that is down wouldn't reach > the nemo, becuase of the failure. with ingress filtering neither > forward packet will flow, i agree, but the main issue is related with > the failure not with the ingress filtering imho > > Then i suggest a minor change of wording where it is stated that: > > If HA2 (or > some border gateway in the domain of HA2) performs ingress > filtering, packets with source address configured from MNP P1 may > be discarded. > > s/may/will > i mean if there is ingress filtering in place, then the packet will be > discarded for sure :-) agree :). > > Later on, it is stated that > > To avoid ingress filtering mechanisms dropping packets in such > situations, MR(s) can stop advertising P1. This would prevent MNNs > from using the address auto-configured on this prefix. > > Now for this you need additional stuff: > first you need a mechanism to detect the failure that is addressed > later on on the draft (i would suggest a reference to the next section) OK. > Second you need to use something like router renumbering or dhcp prefix > delegation when the nemo has more than one link, since Router > advertisment is link scoped. OK. But most of this occurs in normal site multihoming, so I guess the best approach for us is to provide more extensive reference to all the work done in multi6. > > I mean, all this ingress filtering stuff is not so easily solved in the > general case, imho in some configurations you will need or: > - a mesh of tunnels between the MR > - source address dependetn routing in the nemo > see draft-huitema-multi6-ingress-filtering-00.txt for more details > > Section 4.4 Failure Detection it is stated that > > There are other failure modes to consider as well, such as failure at > home agent, failure at access routers, or in general failure of a > link or node along the path from the mobile router to the home agent. > By the nature of the routing infrastructure, failure of intermediate > nodes or links are recovered by the the routing infrastructure by > choosing a different route. > > > this is clearly not the case in multihoming. I mean in the case where > the multihomed nemo has multiple prefixes and each one is associated > with a different home link, the communication will be preserved by > using a differnet address that is routed through a different home > network, In this case, you need to change addresses, so the routing > infrastructure will not do the trick. > I mean, in the other failure modes you cannot assume that the problem > will be solved by the routing infrastructure (if not multi6 would be > out of work :-) I think you misinterpret that statement, or equally probable, we did not write the statement clearly. What it mean is that for failure that occurs in routing infrastructure, the routing infrastructure would recover itself ... since IETF designed it to self-healing. I guess we should re-write the statement to clearly state that. > Next you have a typo in > > For those failures that can't be > receovered (such a failure of the access router), a heartbeadt > ^ thanks, it is corrected in version -02. > Now, i am not sure that sections 4.7 MR Synchronization and 4.8 > Prefix Delegation are really needed. > I mean the issues presented in this section are: > > For doing so, the issues discussed below must be addressed, > preferably dynamically. > > I am not sure that MR sync and Prefix delegation MUST be addressed, > imho this depends on the solution you are considering. I can easily > think a host based solution that doesn't requires MR sync. > > In section 4.10 Source Address Selection i think that a big issue is > missing w.r.t. fault tolerance. I mean, in the case that the source > address is linked to a given HA, then the source address selection will > impact the fault tolerance capabilities, since if the source address > corresponding to the HA that is down is picked, the return packets > won't make it. So you need to use the source address selection > mechanism to obtain fault tolerance. all this consideration is missing > here, and imho it is very important. > for additional considerations on this, please refer to > draft-huitema-multi6-addr-selection-00.txt Thanks, we will read the draft and add appropriate considerations wrt to source address selection. > > section 4.11 Impact on the Routing Infrastructure > i simply suggest to remove it. I mean, i don't think that multiple > routes to a nemo will be announced in the DFZ. If this is the case, > multi6 has failed, and for now, we are a bit more optimistic :-) OK, unless there is any strong objection against removing this issue. > Finally, separate the references in normative informative Hmmm... is that necessary? I mean, the draft itself is an informational document. Once again, I apologize for missing this mail last November. Rest assure we would addressed the concerns you have in the -03 version. /rgds /cwng From nemo-bounces@ietf.org Thu Feb 24 08:38:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18185 for ; Thu, 24 Feb 2005 08:38:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4JAo-0004Gt-V4; Thu, 24 Feb 2005 08:36:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4JAn-0004Gk-6j for nemo@megatron.ietf.org; Thu, 24 Feb 2005 08:36:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18096 for ; Thu, 24 Feb 2005 08:36:55 -0500 (EST) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JXe-0005k4-2I for nemo@ietf.org; Thu, 24 Feb 2005 09:00:37 -0500 Received: from mozart.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1ODXDYq014924; Thu, 24 Feb 2005 21:33:13 +0800 (SGT) Received: by mozart.psl.com.sg (Postfix, from userid 1000) id E3E51206807; Thu, 24 Feb 2005 21:48:59 +0800 (SGT) Subject: Re: [nemo] question about multihoming From: Chan-Wah Ng To: weiwei In-Reply-To: <003801c51a67$2284a840$1ddb5982@utwenteweiwei> References: <003801c51a67$2284a840$1ddb5982@utwenteweiwei> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Date: Thu, 24 Feb 2005 21:48:59 +0800 Message-Id: <1109252939.19951.74.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, weiwei, I guess it is not a question of benefits. It is a question of deployment. A possible scenario for (n,1,n) would be the joining of two separate mobile networks into one. /rgds /cwng On Thu, 2005-02-24 at 12:51 +0100, weiwei wrote: > Dear all, > could anyone tell me the benefits of (n,1,n) over (n,1,1) when > considering multihoming? > > thanks, > > weiwei From nemo-bounces@ietf.org Thu Feb 24 08:52:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19643 for ; Thu, 24 Feb 2005 08:52:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4JLy-0005S3-OZ; Thu, 24 Feb 2005 08:48:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4JLw-0005Nn-N0 for nemo@megatron.ietf.org; Thu, 24 Feb 2005 08:48:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19147 for ; Thu, 24 Feb 2005 08:48:27 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Jip-0005zf-Jo for nemo@ietf.org; Thu, 24 Feb 2005 09:12:09 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id j1ODmJGJ026122; Thu, 24 Feb 2005 14:48:19 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id j1ODmJ8X029605; Thu, 24 Feb 2005 14:48:19 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id j1ODmK414133; Thu, 24 Feb 2005 14:48:20 +0100 (MET) Date: Thu, 24 Feb 2005 14:48:20 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to xuw@cs.utwente.nl using -f To: cwng@psl.com.sg Subject: Re: [nemo] question about multihoming Received: from 217.114.97.45 (auth. user xuw@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 24 Feb 2005 15:48:19 +0200 X-IlohaMail-Blah: xuw@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1109252939.19951.74.camel@bach.psl.com.sg> From: xuw Bounce-To: xuw MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: "nemo@ietf.org" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable hi, cwng so do you mean that there are no more benefits of using multiple MNP than one ,from the perspective of load sharing or redundancy ? you know, i am trying to compare these 8 cases from the perspective of benefits. for instance, using multiple mobile router at least has the benefits of handling the case that one mobile router is broken, comparing with the case in which only one mobile router is used. Or do you mean it is kind of non sense of comparing them ?? :) thanks, weiwei On 2/24/2005, "Chan-Wah Ng" wrote: >Hello, weiwei, > >I guess it is not a question of benefits. It is a question of >deployment. A possible scenario for (n,1,n) would be the joining of two >separate mobile networks into one. > >/rgds >/cwng > >On Thu, 2005-02-24 at 12:51 +0100, weiwei wrote: >> Dear all, >> could anyone tell me the benefits of (n,1,n) over (n,1,1) when >> considering multihoming? >> >> thanks, >> >> weiwei From nemo-bounces@ietf.org Thu Feb 24 09:17:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22897 for ; Thu, 24 Feb 2005 09:17:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Jml-0004dT-Pk; Thu, 24 Feb 2005 09:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Jmk-0004X3-1Q for nemo@megatron.ietf.org; Thu, 24 Feb 2005 09:16:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22645 for ; Thu, 24 Feb 2005 09:16:08 -0500 (EST) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4K9d-0006jk-8G for nemo@ietf.org; Thu, 24 Feb 2005 09:39:51 -0500 Received: from mozart.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1OECTfT015410; Thu, 24 Feb 2005 22:12:29 +0800 (SGT) Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 03046206807; Thu, 24 Feb 2005 22:28:16 +0800 (SGT) Subject: Re: [nemo] question about multihoming From: Chan-Wah Ng To: xuw In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Date: Thu, 24 Feb 2005 22:28:15 +0800 Message-Id: <1109255295.19951.82.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: "nemo@ietf.org" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, weiwei, No, no. That's not what I mean. What I means is that there is no obvious benefits for NEMO per se to have (n,1,n) over (n,1,1). In fact, I think any administrator who purposely configure an (n,1,n) is asking for trouble. However, as I have mentioned, there is a deployment scenario where an (n,1,n) network might occur, so we have to consider it. /rgds /cwng On Thu, 2005-02-24 at 14:48 +0100, xuw wrote: > hi, cwng > so do you mean that there are no more benefits of using multiple MNP than > one ,from the perspective of load sharing or redundancy ? you know, i am > trying to compare these 8 cases from the perspective of benefits. for > instance, using multiple mobile router at least has the benefits of > handling the case that one mobile router is broken, comparing with the > case in which only one mobile router is used. > Or do you mean it is kind of non sense of comparing them ?? :) > > thanks, > weiwei > > On 2/24/2005, "Chan-Wah Ng" wrote: > > >Hello, weiwei, > > > >I guess it is not a question of benefits. It is a question of > >deployment. A possible scenario for (n,1,n) would be the joining of two > >separate mobile networks into one. > > > >/rgds > >/cwng > > > >On Thu, 2005-02-24 at 12:51 +0100, weiwei wrote: > >> Dear all, > >> could anyone tell me the benefits of (n,1,n) over (n,1,1) when > >> considering multihoming? > >> > >> thanks, > >> > >> weiwei > > From nemo-bounces@ietf.org Thu Feb 24 22:51:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29107 for ; Thu, 24 Feb 2005 22:51:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4WTa-0000Xt-BL; Thu, 24 Feb 2005 22:49:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4WTZ-0000WV-1Z for nemo@megatron.ietf.org; Thu, 24 Feb 2005 22:49:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28888 for ; Thu, 24 Feb 2005 22:49:10 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4WTb-0004vN-O1 for nemo@ietf.org; Thu, 24 Feb 2005 22:49:16 -0500 Received: from iseran.local (unknown [219.142.66.65]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 22E014CC33 for ; Fri, 25 Feb 2005 12:48:47 +0900 (JST) Date: Fri, 25 Feb 2005 12:52:50 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] question about multihoming Message-Id: <20050225125250.3de3907e.ernst@sfc.wide.ad.jp> In-Reply-To: <1109255295.19951.82.camel@bach.psl.com.sg> References: <1109255295.19951.82.camel@bach.psl.com.sg> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, I'm not sure we can conclude right now that one case has a benefit over another one: - first, this hasn't been discussed much - second, the document has been written to emphasize the issues (and not to emphasize the benefits) We would indeed appreciate feedback on the ML so that we know what cases need to be supported for what purposes. That would help the NEMO WG to decide which issues are worth to be solved, or which should be solved in priority. If we don't receive such kind of explicit feedback, I'm afraid that the WG cannot update its charter with new multihoming items. So, instead of ChanWah, me or anyone else of answering what are the benefits, may we have people posting which case they consider important to be supported with an example scenario ? About the multiple MR case itself, there are much more motivations than redundancy. It could be increased bandwidth, ability to bring a new egress iface in the NEMO in case the existing MR cannot be upgraded (no slot available or embedder MR), etc. Thierry > Hello, weiwei, > > No, no. That's not what I mean. What I means is that there is no > obvious benefits for NEMO per se to have (n,1,n) over (n,1,1). In > fact, I think any administrator who purposely configure an (n,1,n) is > asking for trouble. However, as I have mentioned, there is a > deployment scenario where an (n,1,n) network might occur, so we have > to consider it. > > /rgds > /cwng > > > On Thu, 2005-02-24 at 14:48 +0100, xuw wrote: > > hi, cwng > > so do you mean that there are no more benefits of using multiple MNP > > than one ,from the perspective of load sharing or redundancy ? you > > know, i am trying to compare these 8 cases from the perspective of > > benefits. for instance, using multiple mobile router at least has > > the benefits of handling the case that one mobile router is broken, > > comparing with the case in which only one mobile router is used. > > Or do you mean it is kind of non sense of comparing them ?? :) > > > > thanks, > > weiwei > > > > On 2/24/2005, "Chan-Wah Ng" wrote: > > > > >Hello, weiwei, > > > > > >I guess it is not a question of benefits. It is a question of > > >deployment. A possible scenario for (n,1,n) would be the joining > > >of two separate mobile networks into one. > > > > > >/rgds > > >/cwng > > > > > >On Thu, 2005-02-24 at 12:51 +0100, weiwei wrote: > > >> Dear all, > > >> could anyone tell me the benefits of (n,1,n) over (n,1,1) when > > >> considering multihoming? > > >> > > >> thanks, > > >> > > >> weiwei > > > > From nemo-bounces@ietf.org Fri Feb 25 04:52:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23971 for ; Fri, 25 Feb 2005 04:52:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4c7n-0005jJ-ED; Fri, 25 Feb 2005 04:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4c7j-0005aO-Df for nemo@megatron.ietf.org; Fri, 25 Feb 2005 04:51:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23832 for ; Fri, 25 Feb 2005 04:51:00 -0500 (EST) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4c7o-0004KX-UX for nemo@ietf.org; Fri, 25 Feb 2005 04:51:09 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7465648013; Fri, 25 Feb 2005 10:50:52 +0100 (CET) Received: from [163.117.139.55] (unknown [163.117.139.55]) by smtp03.uc3m.es (Postfix) with ESMTP id 5BF0947F4B; Fri, 25 Feb 2005 10:50:52 +0100 (CET) In-Reply-To: <20050225125250.3de3907e.ernst@sfc.wide.ad.jp> References: <1109255295.19951.82.camel@bach.psl.com.sg> <20050225125250.3de3907e.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] question about multihoming Date: Fri, 25 Feb 2005 10:50:51 +0100 To: Thierry Ernst X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Thierry, imho, both configurations are reasonable. In particular, (n,1,1) seems a very natural case OTOH, imho (n,1,n) is also natural, but perhaps not so intuitive.=20 Imagine the case where home netwrok is multihomed so that the home=20 network has several prefixes form different ISPs, This will imply that=20= the nemo has multiple prefixes in order to benefit from the multihoming=20= capabilities of the home network. Note that in this case, the multiple=20= prefixes are not related to the nemo multihoming, but to the home=20 network multihoming. imho this is a valid usage case. Now, there is also the possibility to artificially turn a (n,1,1) into=20= a (n,1,n) as a mechanisms to provide some nemo multihoming=20 capabilities. This means that the home network has a single prefix, but=20= the nemo has n prefixes, and for example each one is artificially=20 associated with a MR (in order to enable for instance that the=20 selection of the prefix determines the selection of the MR (you need=20 additional stuff for this)). Now, in this scenario, i am not sure this=20= is a good approach. More details about this you can find them in > http://www.ietf.org/internet-drafts/draft-bagnulo-nemo-multi6-00.txt In particular check sections 3.1. and 3.2. Regards, marcelo > El 25/02/2005, a las 4:52, Thierry Ernst escribi=F3: > > Dear all, > > I'm not sure we can conclude right now that one case has a benefit = over > another one: > > - first, this hasn't been discussed much > > - second, the document has been written to emphasize the issues (and=20= > not > to emphasize the benefits) > > We would indeed appreciate feedback on the ML so that we know what=20 > cases > need to be supported for what purposes. That would help the NEMO WG to > decide which issues are worth to be solved, or which should be solved=20= > in > priority. If we don't receive such kind of explicit feedback, I'm=20 > afraid > that the WG cannot update its charter with new multihoming items. > > So, instead of ChanWah, me or anyone else of answering what are the > benefits, may we have people posting which case they consider = important > to be supported with an example scenario ? > > About the multiple MR case itself, there are much more motivations = than > redundancy. It could be increased bandwidth, ability to bring a new > egress iface in the NEMO in case the existing MR cannot be upgraded = (no > slot available or embedder MR), etc. > > Thierry > >> Hello, weiwei, >> >> No, no. That's not what I mean. What I means is that there is no >> obvious benefits for NEMO per se to have (n,1,n) over (n,1,1). In >> fact, I think any administrator who purposely configure an (n,1,n) is >> asking for trouble. However, as I have mentioned, there is a >> deployment scenario where an (n,1,n) network might occur, so we have >> to consider it. >> >> /rgds >> /cwng >> >> >> On Thu, 2005-02-24 at 14:48 +0100, xuw wrote: >>> hi, cwng >>> so do you mean that there are no more benefits of using multiple MNP >>> than one ,from the perspective of load sharing or redundancy ? you >>> know, i am trying to compare these 8 cases from the perspective of >>> benefits. for instance, using multiple mobile router at least has >>> the benefits of handling the case that one mobile router is broken, >>> comparing with the case in which only one mobile router is used. >>> Or do you mean it is kind of non sense of comparing them ?? :) >>> >>> thanks, >>> weiwei >>> >>> On 2/24/2005, "Chan-Wah Ng" wrote: >>> >>>> Hello, weiwei, >>>> >>>> I guess it is not a question of benefits. It is a question of >>>> deployment. A possible scenario for (n,1,n) would be the joining >>>> of two separate mobile networks into one. >>>> >>>> /rgds >>>> /cwng >>>> >>>> On Thu, 2005-02-24 at 12:51 +0100, weiwei wrote: >>>>> Dear all, >>>>> could anyone tell me the benefits of (n,1,n) over (n,1,1) when >>>>> considering multihoming? >>>>> >>>>> thanks, >>>>> >>>>> weiwei >>> >>> > From nemo-bounces@ietf.org Fri Feb 25 09:44:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21644 for ; Fri, 25 Feb 2005 09:44:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ggE-0004q2-0i; Fri, 25 Feb 2005 09:42:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4GS3-0000Bc-TZ for nemo@megatron.ietf.org; Thu, 24 Feb 2005 05:42:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29394 for ; Thu, 24 Feb 2005 05:42:33 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Gov-0001Ik-29 for nemo@ietf.org; Thu, 24 Feb 2005 06:06:14 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0A9A25D583 for ; Thu, 24 Feb 2005 11:42:25 +0100 (CET) Received: from [163.117.139.55] (unknown [163.117.139.55]) by smtp01.uc3m.es (Postfix) with ESMTP id E8E6E5D57F for ; Thu, 24 Feb 2005 11:42:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <200502222106.QAA21649@ietf.org> References: <200502222106.QAA21649@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <470d8b39b6da849f281212cf5b7c990c@bagnulo.net> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt Date: Thu, 24 Feb 2005 11:42:24 +0100 To: nemo WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 25 Feb 2005 09:42:54 -0500 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, a while ago i made several comments about the previous version of this =20= draft, which you can find in =20 http://www.ietf.org/mail-archive/web/nemo/current/msg01970.html but is =20= didn't receive any answer and i think they were not included in the =20 draft, could some of the authors comment on that? Thanks, marcelo El 22/02/2005, a las 22:06, Internet-Drafts@ietf.org escribi=F3: > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > This draft is a work item of the Network Mobility Working Group of the = =20 > IETF. > > Title : Analysis of Multihoming in Network Mobility = Support > Author(s) : T. Ernst, et al. > Filename : draft-ietf-nemo-multihoming-issues-02.txt > Pages : 36 > Date : 2005-2-22 > =09 > This document is an analysis of multihoming in the context of network > mobility (NEMO). As there are many situations in which mobile > networks may be multihomed, a taxonomy is proposed to classify the > possible configurations. We also describe possible deployment > scenarios and we attempt to identify issues that arise when mobile > networks are multihomed while mobility supports is taken care by =20= > NEMO > Basic Support. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-=20 > issues-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of = =20 > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the =20= > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-multihoming-issues-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE = /internet-drafts/draft-ietf-nemo-multihoming-issues-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail = readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-2-22160543.I-D@ietf.org> > From nemo-bounces@ietf.org Fri Feb 25 09:44:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21691 for ; Fri, 25 Feb 2005 09:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ggD-0004os-JB; Fri, 25 Feb 2005 09:42:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4GNx-0008En-4E for nemo@megatron.ietf.org; Thu, 24 Feb 2005 05:38:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28998 for ; Thu, 24 Feb 2005 05:38:18 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Gkn-0001Cj-Tl for nemo@ietf.org; Thu, 24 Feb 2005 06:01:59 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 760D45D57B; Thu, 24 Feb 2005 11:38:08 +0100 (CET) Received: from [163.117.139.55] (unknown [163.117.139.55]) by smtp01.uc3m.es (Postfix) with ESMTP id 5EADB5D577; Thu, 24 Feb 2005 11:38:08 +0100 (CET) In-Reply-To: <20050223215358.20cab146.ernst@sfc.wide.ad.jp> References: <20050223215358.20cab146.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: [nemo] CFP NEMO WG slot Date: Thu, 24 Feb 2005 11:38:08 +0100 To: Thierry Ernst X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 25 Feb 2005 09:42:54 -0500 Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, i would like to present the draft about multi6 and nemo - topic: nemo multihoming - issue to be discussed: application of multi6 to nemo - name of speaker: marcelo bagnulo - relevant draft or mailing list thread: http://www.ietf.org/internet-drafts/draft-bagnulo-nemo-multi6-00.txt - length: 10 min - how does it relate to the WG goals and milestones: it provides some inforamtion about how appropriate is multi6 to provide nemo multihoming support regards, marcelo > > In addition to the usual slots: > - Agenda bashing > - Status on WG documents > (home model; NEMO BS, Terminology, requirement, MIB, multihoming) > - Conclusions and next steps > > requests on the following topics will be allocated time in priority: > - v4 traversal for the NEMO protocol > - Prefix Delegation for NEMO BS > - Multihoming > -- Which issues should be solved by the NEMO WG ? > -- Solutions on specific NEMO multihohming issues > - RO discussion > -- Status > -- Do we have concensus on the WG document content ? > -- What are the main RO issues to solve > - Report of TAHI and Connectathon events > > > Also, if you have submiited a new version of a draft and you haven't > announced it yet on the mailing list, please do so and try to raise > some > discussion. > > Thierry > From nemo-bounces@ietf.org Fri Feb 25 09:52:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22418 for ; Fri, 25 Feb 2005 09:52:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4goO-0005T0-Mn; Fri, 25 Feb 2005 09:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzHgy-0001GO-5N; Thu, 10 Feb 2005 12:01:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16691; Thu, 10 Feb 2005 12:01:21 -0500 (EST) Received: from struggle.mr.itd.umich.edu ([141.211.14.79]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzI0z-00004x-TE; Thu, 10 Feb 2005 12:22:07 -0500 Received: from [127.0.0.1] (c-67-182-52-27.client.comcast.net [67.182.52.27]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id j1AH1GdX028820; Thu, 10 Feb 2005 12:01:19 -0500 Message-ID: <420B934F.6040003@umich.edu> Date: Thu, 10 Feb 2005 09:01:03 -0800 From: subrata goswami User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 25 Feb 2005 09:51:22 -0500 Subject: [nemo] New ID for End Node Based Mobility X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit A new Internet Draft is available on mobility support in IP networks. Title: IPv4 Mobility through Peer Signaling ID: draft-goswami-mip4-peer-signaling-00.txt Abstract: This document describes a way to perform mobility in IPv4 (potentially IPv6) without requiring any new entity in networks infrastructure (e.g. Home Agent, Foreign Agent, etc.). Instead of using infrastructure entities this method delegates all the mobility function to the end nodes. The method relies on source and destination address translation at the end nodes, and signaling between end nodes to perform hand offs - all these function can be encapsulated in an entity called Mobility Agent (MA) in the end nodes. URL: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12788 From nemo-bounces@ietf.org Sat Feb 26 15:49:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00949 for ; Sat, 26 Feb 2005 15:49:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D58r2-0007Ty-M9; Sat, 26 Feb 2005 15:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D58r0-0007Tt-Tw for nemo@megatron.ietf.org; Sat, 26 Feb 2005 15:47:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00912 for ; Sat, 26 Feb 2005 15:47:56 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D58rO-0002Ou-SL for nemo@ietf.org; Sat, 26 Feb 2005 15:48:23 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4BC195D3EC; Sat, 26 Feb 2005 21:47:46 +0100 (CET) Received: from [163.117.252.20] (unknown [163.117.252.20]) by smtp01.uc3m.es (Postfix) with ESMTP id 8FA905D425; Sat, 26 Feb 2005 21:47:37 +0100 (CET) In-Reply-To: <1109252502.19951.68.camel@bach.psl.com.sg> References: <200502222106.QAA21649@ietf.org> <72f0a85ad43327f48abfec959488595c@it.uc3m.es> <1109252502.19951.68.camel@bach.psl.com.sg> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <704f80d0def10daef1a8c4d570c65c1f@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt Date: Sat, 26 Feb 2005 21:28:57 +0100 To: Chan-Wah Ng X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Content-Transfer-Encoding: quoted-printable Cc: nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Chan-Wah, El 24/02/2005, a las 14:41, Chan-Wah Ng escribi=F3: > Hello Marcelo, > > > On Thu, 2005-02-24 at 11:51 +0100, marcelo bagnulo braun wrote: >> Hi, >> >> a while ago i made several comments about the previous version of = this >> draft, which you can find in >> http://www.ietf.org/mail-archive/web/nemo/current/msg01970.html but = is >> didn't receive any answer and i think they were not included in the >> draft, could some of the authors comment on that? >> Thanks, marcelo >> > > I am sorry, I must have missed your earlier mail. Let me response to=20= > it > now. > > > > On Tue, 2004-11-16 at 19:16 +0100, marcelo bagnulo braun wrote: >> Hi all, >> >> just some additional comments about this draft >> >> Section 2. states that: >> >> One thing the reader has to keep in mind is that in each of the >> following 8 cases, the MR may be multihomed if either (i) = multiple >> prefixes are advertised on the home link, (ii) multiple prefixes=20= >> are >> advertised on the visited link, >> >> Now, i am not sure the ii) case is relevant here. I mean, in this=20 >> case, >> the visited network is the one that is multihomed, not the NEMO. In >> this case, the MR will be just on more node within the multihomed >> visited network. I don't have a strong opinion on this, just that i=20= >> was >> puzzled when i saw it there, since this doesn't fail into my=20 >> definition >> of nemo multihoming. anyway... > > The impact of case (ii) are mostly concerned with a general multihomed > mobile node. Since the operation of NEMO Basic Support is largely=20 > based > on Mobile IPv6, concerns of multihomed mobile node would impact a=20 > mobile > router as well. So, for completeness, we feel it is necessary to = voice > it out. Later in the issues section, we should have pointed that > concerns for the case (ii) are not NEMO-Specific, and recommends that > NEMO to be compatible with whatever solutions other WG comes up with. > ok >> >> >> Section 4.3 Ingress Filtering states that: >> >> A simple solution is to require all >> MNNs to set their default router to the MR that advertises the=20= >> MNP >> the MNNs configured their addresses from. >> >> Now this is not simple as it seems. >> What if you have the following configuration >> >> >> +----+ +-----+ >> | MR1| | MR2 | >> +----+ +-----+ >> | | >> ----------------------- >> | >> +----+ >> | R | >> +----+ >> | >> ----------------- >> LAN2 >> >> What is R supposed to advertise in LAN? I guess that in order to = apply >> this approach in this configuration you will need to add an = additional >> router in LAN2 so that you have two routers so that each one can >> advertise a different prefix (this basically means that you will need >> to build as many paralel netwroks as you have prefixes (this is not >> what i would call simple) >> I guess that simply adding that in some configurations like the one i >> depicted above this mechanism is not good would be enough > > Hmm, let's explore this a bit further. Router R is also an MNN on the > NEMO, yes? So it should follow the same rule. Now R can advertise=20 > both > prefixes, but it must add a route to its routing table so that all > packets with source prefix P1 is routed to MR1, and all packet with > source prefix P2 is routed to MR2 (assuming MR1 advertises P1 and MR2 > advertises P2). > > Would this work? > indeed, but this essentially means that you are adopting source address=20= depedendent (SAD) routing within the nemo, which one of the general=20 approaches that you can use for dealing with ingress filtering in=20 multihomed environments. Now, this is not as simple as it seems since basically you are changing=20= the routing paradigm within the network, which may have unforeseen=20 consequences (i am not trying to spread fud here, just re-stating some=20= concerns that were expressed during the discussions of these topics in=20= multi6) In addition, R does no need to be a MR, it just need to implement SAD=20 routing, no need for the complete MR functionality. So, this problem is general to all mutlihomed networks, and the=20 approaches imho are the same whether the network is mobile or not. for=20= general approaches to the ingress filtering problem in multihomed=20 networks, please refer to draft-huitema-multi6-ingress-filtering-00 > >> Next, in the same section it is stated that: >> >> For a possible approach, see [12]. >> >> I haven't read the latest version of this draft, but i don't know how >> this draft can help here, i mean the problem here is a problem with >> source address selection not with destiantion. I mean you need a >> mechanism to convey the hosts the following information: for a source >> address with prefix P1, you must use a give router for forwarding.=20 >> Last >> version i read of 12, it stated that: for a destination address the=20= >> use >> router X, which is different and not what is needed. am i missing >> something? besides, the previous comment still holds here. i.e. the >> configuration depicted above is not trivially supported. >> >> Then, it is stated that: >> >> If the tunnel to HA1 is broken, packets would be sent through=20= >> the >> tunnel to HA1 are diverted through the tunnel to HA2. >> >> Well, i guess this is not only a problem with ingress filtering but >> also about fault tolerance. I mean, even if there were no ingress >> filtering in place, the reply packets addressed to the address that >> contains the prefix corresponding to the HA that is down wouldn't=20 >> reach >> the nemo, becuase of the failure. with ingress filtering neither >> forward packet will flow, i agree, but the main issue is related with >> the failure not with the ingress filtering imho >> >> Then i suggest a minor change of wording where it is stated that: >> >> If HA2 (or >> some border gateway in the domain of HA2) performs ingress >> filtering, packets with source address configured from MNP P1=20= >> may >> be discarded. >> >> s/may/will >> i mean if there is ingress filtering in place, then the packet will=20= >> be >> discarded for sure :-) > > agree :). > > >> >> Later on, it is stated that >> >> To avoid ingress filtering mechanisms dropping packets in such >> situations, MR(s) can stop advertising P1. This would prevent=20 >> MNNs >> from using the address auto-configured on this prefix. >> >> Now for this you need additional stuff: >> first you need a mechanism to detect the failure that is addressed >> later on on the draft (i would suggest a reference to the next=20 >> section) > OK. > >> Second you need to use something like router renumbering or dhcp=20 >> prefix >> delegation when the nemo has more than one link, since Router >> advertisment is link scoped. > > OK. But most of this occurs in normal site multihoming, so I guess = the > best approach for us is to provide more extensive reference to all the > work done in multi6. > agree, but most of the items above also fall into this category. For=20 instance all the ingress filtering problems, source address selection=20 issues, failure detection mechanisms also are common with multi6 ones. I think that you have try to do this in the new version of the draft, i=20= will comment on that on another message. >> >> I mean, all this ingress filtering stuff is not so easily solved in=20= >> the >> general case, imho in some configurations you will need or: >> - a mesh of tunnels between the MR >> - source address dependetn routing in the nemo > >> see draft-huitema-multi6-ingress-filtering-00.txt for more details >> > >> Section 4.4 Failure Detection it is stated that >> >> There are other failure modes to consider as well, such as=20 >> failure at >> home agent, failure at access routers, or in general failure of a >> link or node along the path from the mobile router to the home=20 >> agent. >> By the nature of the routing infrastructure, failure of=20 >> intermediate >> nodes or links are recovered by the the routing infrastructure by >> choosing a different route. >> >> >> this is clearly not the case in multihoming. I mean in the case where >> the multihomed nemo has multiple prefixes and each one is associated >> with a different home link, the communication will be preserved by >> using a differnet address that is routed through a different home >> network, In this case, you need to change addresses, so the routing >> infrastructure will not do the trick. >> I mean, in the other failure modes you cannot assume that the problem >> will be solved by the routing infrastructure (if not multi6 would be >> out of work :-) > > I think you misinterpret that statement, or equally probable, we did=20= > not > write the statement clearly. What it mean is that for failure that > occurs in routing infrastructure, the routing infrastructure would > recover itself ... since IETF designed it to self-healing. I guess we > should re-write the statement to clearly state that. > Well, i think that the problem is more complex than this, let me try to=20= expand on this. Suppose that we have a (*,n,n) nemo, where each HA is located is a=20 different home network, which has a different global prefix. So this=20 means that if there is a failure in one of the home networks, the nemo=20= is reachable through the alternative home netwrok, but using an=20 alternative address/prefix. Now suppose that an outage occurs in the routing infrastructure that=20 affects the path between the Internet and one of the Home networks, As=20= you say, the routing system will attempt to obtain alternative paths.=20 More precisely, this means that BGP will identify the outage, identify=20= alternative paths and the reconverge to the alternative route. The=20 problem is that this may take a while (180 sec is the recommended value=20= for BGP to detect an outage, then you need to reconverge, which may=20 take also a while) Now, in this scenario, probably the multihoming mechanisms of the nemo=20= will react faster than the routing system in some cases. so probably=20 even if the outage can be recovered through the routing system,=20 multihoming mechanisms will provide a better response and react faster.=20= Makes sense? I mean, multihoming mechanisms of multi6 are end to end, so there are=20 no failures modes that are not covered by them (by definition) >> Next you have a typo in >> >> For those failures that can't be >> receovered (such a failure of the access router), a heartbeadt >> ^ > > thanks, it is corrected in version -02. > >> Now, i am not sure that sections 4.7 MR Synchronization and 4.8 >> Prefix Delegation are really needed. >> I mean the issues presented in this section are: >> >> For doing so, the issues discussed below must be addressed, >> preferably dynamically. >> >> I am not sure that MR sync and Prefix delegation MUST be addressed, >> imho this depends on the solution you are considering. I can easily >> think a host based solution that doesn't requires MR sync. >> >> In section 4.10 Source Address Selection i think that a big issue is >> missing w.r.t. fault tolerance. I mean, in the case that the source >> address is linked to a given HA, then the source address selection=20 >> will >> impact the fault tolerance capabilities, since if the source address >> corresponding to the HA that is down is picked, the return packets >> won't make it. So you need to use the source address selection >> mechanism to obtain fault tolerance. all this consideration is = missing >> here, and imho it is very important. >> for additional considerations on this, please refer to >> draft-huitema-multi6-addr-selection-00.txt > > Thanks, we will read the draft and add appropriate considerations wrt=20= > to > source address selection. >> >> section 4.11 Impact on the Routing Infrastructure >> i simply suggest to remove it. I mean, i don't think that multiple >> routes to a nemo will be announced in the DFZ. If this is the case, >> multi6 has failed, and for now, we are a bit more optimistic :-) > > OK, unless there is any strong objection against removing this issue. > >> Finally, separate the references in normative informative > > Hmmm... is that necessary? I mean, the draft itself is an > informational document. I think so, but i guess the chairs can tell us about this. > > > > Once again, I apologize for missing this mail last November. Rest > assure we would addressed the concerns you have in the -03 version. > no problem, thanks for the draft. I will try to comment on the v3 soon. Regards, marcelo > /rgds > /cwng > From nemo-bounces@ietf.org Mon Feb 28 21:29:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04740 for ; Mon, 28 Feb 2005 21:29:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5x6E-0004cZ-5T; Mon, 28 Feb 2005 21:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5x6A-0004cH-Oi for nemo@megatron.ietf.org; Mon, 28 Feb 2005 21:27:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04553 for ; Mon, 28 Feb 2005 21:26:56 -0500 (EST) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5x71-00075j-Cx for nemo@ietf.org; Mon, 28 Feb 2005 21:27:52 -0500 Received: from mozart.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j212NPNq013065; Tue, 1 Mar 2005 10:23:25 +0800 (SGT) Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 59FB3300BC1; Tue, 1 Mar 2005 10:39:55 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-02.txt From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: <704f80d0def10daef1a8c4d570c65c1f@it.uc3m.es> References: <200502222106.QAA21649@ietf.org> <72f0a85ad43327f48abfec959488595c@it.uc3m.es> <1109252502.19951.68.camel@bach.psl.com.sg> <704f80d0def10daef1a8c4d570c65c1f@it.uc3m.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Date: Tue, 01 Mar 2005 10:39:55 +0800 Message-Id: <1109644795.9286.17.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit Cc: nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Marcelo, On Sat, 2005-02-26 at 21:28 +0100, marcelo bagnulo braun wrote: > Hi Chan-Wah, > > -- 8< consensus portions snipped >8 -- > >> > >> > >> Section 4.3 Ingress Filtering states that: > >> > >> A simple solution is to require all > >> MNNs to set their default router to the MR that advertises the > >> MNP > >> the MNNs configured their addresses from. > >> > >> Now this is not simple as it seems. > >> What if you have the following configuration > >> > >> > >> +----+ +-----+ > >> | MR1| | MR2 | > >> +----+ +-----+ > >> | | > >> ----------------------- > >> | > >> +----+ > >> | R | > >> +----+ > >> | > >> ----------------- > >> LAN2 > >> > >> What is R supposed to advertise in LAN? I guess that in order to apply > >> this approach in this configuration you will need to add an additional > >> router in LAN2 so that you have two routers so that each one can > >> advertise a different prefix (this basically means that you will need > >> to build as many paralel netwroks as you have prefixes (this is not > >> what i would call simple) > >> I guess that simply adding that in some configurations like the one i > >> depicted above this mechanism is not good would be enough > > > > Hmm, let's explore this a bit further. Router R is also an MNN on the > > NEMO, yes? So it should follow the same rule. Now R can advertise > > both > > prefixes, but it must add a route to its routing table so that all > > packets with source prefix P1 is routed to MR1, and all packet with > > source prefix P2 is routed to MR2 (assuming MR1 advertises P1 and MR2 > > advertises P2). > > > > Would this work? > > > > indeed, but this essentially means that you are adopting source address > depedendent (SAD) routing within the nemo, which one of the general > approaches that you can use for dealing with ingress filtering in > multihomed environments. Yes, in fact, having normal MMNs (host) to use different default routers corresponding to different source address prefix is also a form of SAD-routing. > Now, this is not as simple as it seems since basically you are changing > the routing paradigm within the network, which may have unforeseen > consequences (i am not trying to spread fud here, just re-stating some > concerns that were expressed during the discussions of these topics in > multi6) > > In addition, R does no need to be a MR, it just need to implement SAD > routing, no need for the complete MR functionality. > > So, this problem is general to all mutlihomed networks, and the > approaches imho are the same whether the network is mobile or not. for > general approaches to the ingress filtering problem in multihomed > networks, please refer to draft-huitema-multi6-ingress-filtering-00 > Agreed. How about we rewriting the statement to: A possible approach to solving this is to employ some kind of source address dependent routing in the MNNs (such as requiring MNNs to set their default router to the MR that advertises the MNP the MNNs configured their address from). There are certain issues and considerations associated with such an approach, and the readers are referred to [draft-huitema] for a more detailed analysis. -- 8< consensus portions snipped >8 -- > >> > >> Later on, it is stated that > >> > >> To avoid ingress filtering mechanisms dropping packets in such > >> situations, MR(s) can stop advertising P1. This would prevent > >> MNNs > >> from using the address auto-configured on this prefix. > >> > >> Now for this you need additional stuff: > >> first you need a mechanism to detect the failure that is addressed > >> later on on the draft (i would suggest a reference to the next > >> section) > > OK. > > > >> Second you need to use something like router renumbering or dhcp > >> prefix > >> delegation when the nemo has more than one link, since Router > >> advertisment is link scoped. > > > > OK. But most of this occurs in normal site multihoming, so I guess the > > best approach for us is to provide more extensive reference to all the > > work done in multi6. > > > > agree, but most of the items above also fall into this category. For > instance all the ingress filtering problems, source address selection > issues, failure detection mechanisms also are common with multi6 ones. > Yes, in the next version, we would reference more extensively to the work done in multi6. > I think that you have try to do this in the new version of the draft, i > will comment on that on another message. > > >> > >> I mean, all this ingress filtering stuff is not so easily solved in > >> the > >> general case, imho in some configurations you will need or: > >> - a mesh of tunnels between the MR > >> - source address dependetn routing in the nemo > > > >> see draft-huitema-multi6-ingress-filtering-00.txt for more details > >> > > > >> Section 4.4 Failure Detection it is stated that > >> > >> There are other failure modes to consider as well, such as > >> failure at > >> home agent, failure at access routers, or in general failure of a > >> link or node along the path from the mobile router to the home > >> agent. > >> By the nature of the routing infrastructure, failure of > >> intermediate > >> nodes or links are recovered by the the routing infrastructure by > >> choosing a different route. > >> > >> > >> this is clearly not the case in multihoming. I mean in the case where > >> the multihomed nemo has multiple prefixes and each one is associated > >> with a different home link, the communication will be preserved by > >> using a differnet address that is routed through a different home > >> network, In this case, you need to change addresses, so the routing > >> infrastructure will not do the trick. > >> I mean, in the other failure modes you cannot assume that the problem > >> will be solved by the routing infrastructure (if not multi6 would be > >> out of work :-) > > > > I think you misinterpret that statement, or equally probable, we did > > not > > write the statement clearly. What it mean is that for failure that > > occurs in routing infrastructure, the routing infrastructure would > > recover itself ... since IETF designed it to self-healing. I guess we > > should re-write the statement to clearly state that. > > > > Well, i think that the problem is more complex than this, let me try to > expand on this. > > Suppose that we have a (*,n,n) nemo, where each HA is located is a > different home network, which has a different global prefix. So this > means that if there is a failure in one of the home networks, the nemo > is reachable through the alternative home netwrok, but using an > alternative address/prefix. > > Now suppose that an outage occurs in the routing infrastructure that > affects the path between the Internet and one of the Home networks, As > you say, the routing system will attempt to obtain alternative paths. > More precisely, this means that BGP will identify the outage, identify > alternative paths and the reconverge to the alternative route. The > problem is that this may take a while (180 sec is the recommended value > for BGP to detect an outage, then you need to reconverge, which may > take also a while) > > Now, in this scenario, probably the multihoming mechanisms of the nemo > will react faster than the routing system in some cases. so probably > even if the outage can be recovered through the routing system, > multihoming mechanisms will provide a better response and react faster. > Makes sense? > > I mean, multihoming mechanisms of multi6 are end to end, so there are > no failures modes that are not covered by them (by definition) > That I concur. So, may I suggest that we add a few statements after the original text to describe that (1) recovery would be faster by using multihoming mechanism than to rely on routing infrastructure, and (2) NEMO WG should adopt any multihoming solution developed by multi6. > >> Finally, separate the references in normative informative > > > > Hmmm... is that necessary? I mean, the draft itself is an > > informational document. > > I think so, but i guess the chairs can tell us about this. > Would the chairs care to comment? /rgds /cwng