From mailman-bounces@ietf.org Wed Sep 1 09:51:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12842 for ; Wed, 1 Sep 2004 09:51:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2RKp-0002Ty-SP for nemo-archive@lists.ietf.org; Wed, 01 Sep 2004 05:23:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: nemo-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Sep 2004 05:05:59 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From nemo-bounces@ietf.org Wed Sep 1 12:35:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05960 for ; Wed, 1 Sep 2004 12:35:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMg-0005rv-HJ; Wed, 01 Sep 2004 11:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VGg-0004Mb-Cq for nemo@megatron.ietf.org; Wed, 01 Sep 2004 09:35:18 -0400 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 JAA06994 for ; Wed, 1 Sep 2004 09:35:14 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2TSR-0000Iy-89 for nemo@ietf.org; Wed, 01 Sep 2004 07:39:20 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 99C0280019D for ; Wed, 1 Sep 2004 14:36:16 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i81BaGSf023385 for ; Wed, 1 Sep 2004 14:36:16 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i81BaGAC023381 for ; Wed, 1 Sep 2004 14:36:16 +0300 Date: Wed, 1 Sep 2004 14:36:16 +0300 (EEST) From: Ville Nuorvala To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [nemo] Aggregated prefixes and Proxy ND 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, while reading draft-ietf-nemo-basic-support-pre04.txt I started wondering about how the HA actually should perform Proxy ND on behalf of the MR. The thing is of course straight forward if the MR's HoA is from a prefix advertised on the home link, but it all gets a bit complicated if it's from a prefix that the MR advertises on its ingress interface. Since the HoA will never be on the same link as the HA, should the HA still do the DAD probe and perform Proxy ND for it? Then again, I guess there isn't any harm in doing that, so perhaps it's ok for the HA to always do Proxy ND for the MR. 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 Wed Sep 1 13:04:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10957 for ; Wed, 1 Sep 2004 13:04:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XWn-0005GO-Mj; Wed, 01 Sep 2004 12:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2WAX-0001rL-Hq for nemo@megatron.ietf.org; Wed, 01 Sep 2004 10:33:01 -0400 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 KAA18991 for ; Wed, 1 Sep 2004 10:32:58 -0400 (EDT) Received: from web25009.mail.ukl.yahoo.com ([217.12.10.45]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2WCi-0002qV-St for nemo@ietf.org; Wed, 01 Sep 2004 10:35:18 -0400 Message-ID: <20040901143227.7628.qmail@web25009.mail.ukl.yahoo.com> Received: from [137.194.192.231] by web25009.mail.ukl.yahoo.com via HTTP; Wed, 01 Sep 2004 16:32:27 CEST Date: Wed, 1 Sep 2004 16:32:27 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: Re: [nemo] new draft To: Mattias Pettersson In-Reply-To: <41321906.5040604@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA18991 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: quoted-printable --- Mattias Pettersson a =E9crit :=20 >=20 >=20 > Mazen TLAIS wrote: > > Hi Mattias, > >=20 > > Here are some responses for your comments > >=20 > >=20 > >>You seem to assume that there is a suitable point > in > >>a typical access=20 > >>network where an ARC can be placed. From your > draft > >>I can't be sure what=20 > >>security relationships that are required, but if > the > >>ARC needs security=20 > >>relationships with many ARs this in general > creates > >>scalability=20 > >>problems. > >=20 > > Updating messages sent by MR to ARC need=20 > > security relationships. I'm not sure about ARs. > >=20 > >=20 > >=20 > >>My general assumption is that in order to > >>benefit from=20 > >>multihoming, an MR would connect to various access > >>networks of different=20 > >>technologies. That would mean that ARs belong to > >>different domains. The=20 > >>nature of multihoming is to connect to the network > >>in topological=20 > >>locations far from each other, often even > completely > >>unrelated=20 > >>locations. That is what makes the placement of an > >>ARC difficult, as it=20 > >>is meant to be near the different ARs. But I may > >>have misinterpreted=20 > >>your architecture. > >=20 > > If the AR is registered within an ARC, then=20 > > this later can manage the AR. It's not a location > > question. >=20 > Continuing my assumption that there is a need for > security associations=20 > between AR and ARC, if an AR is located in a > different administrative=20 > domain than where the ARC is located, this generally > creates scalability=20 > problems. >=20 > Maybe you can line out what messages each entity > sends to other=20 > entities, and what state change each message will > cause at the receiver?=20 > Any state change must be authorized. =20 When a MR sends a registration message (HRMMN_RegReq)to AR, this later must send to ARC a message (HRMMN_ARC_Cache_Update)to update the ARC's cache (ARC_Cache). ARC must authentificate the received message, then it refreshes its cache to take into account the flows of the novel MR. Moreover, a MR sends to ARC a list of detected ARs in its neighborhood (HRMMN_ARC_Cache_Update message). ARC must authentificate the received message, then it calculates preferences values that must be send to MR in the acknowlodgement message(HRMMN_ARC_Cache_ Acknowledgment message). I think that we need to authententificate and ensure the integrity of the received messages. Mazen =09 =09 =09 Vous manquez d=92espace pour stocker vos mails ?=20 Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les nouveau= t=E9s pour dialoguer instantan=E9ment avec vos amis. A t=E9l=E9charger gr= atuitement sur http://fr.messenger.yahoo.com From nemo-bounces@ietf.org Wed Sep 1 14:09:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17158 for ; Wed, 1 Sep 2004 14:09:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ZGs-0005Fa-H4; Wed, 01 Sep 2004 13:51:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2YGG-0007WE-Vx for nemo@megatron.ietf.org; Wed, 01 Sep 2004 12:47:05 -0400 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 MAA07717 for ; Wed, 1 Sep 2004 12:47:01 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2YIJ-0003jL-Fb for nemo@ietf.org; Wed, 01 Sep 2004 12:49:23 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i81GkmlU020105 for ; Wed, 1 Sep 2004 18:46:52 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 18:46:48 +0200 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id R841YQV4; Wed, 1 Sep 2004 18:46:48 +0200 Message-ID: <4135FCF8.4080200@ericsson.com> Date: Wed, 01 Sep 2004 18:46:48 +0200 X-Sybari-Trust: 3006abc3 477d8de1 10ae7dd3 00000139 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ville Nuorvala Subject: Re: [nemo] Aggregated prefixes and Proxy ND References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2004 16:46:48.0522 (UTC) FILETIME=[4605F2A0:01C49043] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Ville Nuorvala wrote: > Hi, > > while reading draft-ietf-nemo-basic-support-pre04.txt I started > wondering > about how the HA actually should perform Proxy ND on behalf of the MR. > > The thing is of course straight forward if the MR's HoA is from a prefix > advertised on the home link, but it all gets a bit complicated if it's > from a prefix that the MR advertises on its ingress interface. > > Since the HoA will never be on the same link as the HA, should the HA > still do the DAD probe and perform Proxy ND for it? Then again, I guess > there isn't any harm in doing that, so perhaps it's ok for the HA to > always do Proxy ND for the MR. If the MR's HoA is derived from the MNP, it does not belong to the home link, and no node attached on the home link will ever assume it is on-link, thus never do ND address resolution for it. An implementation of IPv6/ND shouldn't even allow ND proxying for off-link prefixes. This is my interpretation. /Mattias From nemo-bounces@ietf.org Wed Sep 1 15:23:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23551 for ; Wed, 1 Sep 2004 15:23:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2aPz-0004dX-UW; Wed, 01 Sep 2004 15:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2aC1-0005II-1Q for nemo@megatron.ietf.org; Wed, 01 Sep 2004 14:50:49 -0400 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 OAA20768 for ; Wed, 1 Sep 2004 14:50:44 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2aEC-0005wp-Uz for nemo@ietf.org; Wed, 01 Sep 2004 14:53:08 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i81Iofbb022862; Wed, 1 Sep 2004 11:50:42 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i81IogsR027053; Wed, 1 Sep 2004 13:50:42 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 98FB28A3C64; Wed, 1 Sep 2004 20:50:41 +0200 (CEST) Message-ID: <413619EB.5080609@motorola.com> Date: Wed, 01 Sep 2004 20:50:19 +0200 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: Ville Nuorvala Subject: Re: [nemo] Aggregated prefixes and Proxy ND References: In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F714541DA93483D0FB4E6A0" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F714541DA93483D0FB4E6A0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ville Nuorvala wrote: > while reading draft-ietf-nemo-basic-support-pre04.txt I started > wondering about how the HA actually should perform Proxy ND on behalf > of the MR. > > The thing is of course straight forward if the MR's HoA is from a > prefix advertised on the home link, but it all gets a bit complicated > if it's from a prefix that the MR advertises on its ingress > interface. I agree. > Since the HoA will never be on the same link as the HA, should the HA > still do the DAD probe and perform Proxy ND for it? My personal view is no. But there may be particular cases where it's yes. Co-authors may help clarify; reasons I remember relate to RO, like "RO is easier if HoA from ingress". You may want to find a usually used thing that overstretches or breaks when HA does proxy ND and DAD for the HoA of the ingress. If you find it, state it here and see... For example, I don't know... Alex --------------enig3F714541DA93483D0FB4E6A0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNhoBMmC0w56zj54RAv7kAJ4+VaYCEDeJApOE63mOLhfxLjniagCfRZ4m IRVKV2CaBzmj2LFwSkWWBjM= =O43e -----END PGP SIGNATURE----- --------------enig3F714541DA93483D0FB4E6A0-- From nemo-bounces@ietf.org Thu Sep 2 08:27:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27842 for ; Thu, 2 Sep 2004 08:27:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qQc-0006hu-GK; Thu, 02 Sep 2004 08:10:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qLr-0004MQ-BS for nemo@megatron.ietf.org; Thu, 02 Sep 2004 08:06:03 -0400 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 IAA25842 for ; Thu, 2 Sep 2004 08:06:02 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2qOF-000549-Ju for nemo@ietf.org; Thu, 02 Sep 2004 08:08:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2004 14:09:51 +0200 X-BrightmailFiltered: true 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 i82C59Cv013662; Thu, 2 Sep 2004 14:05:28 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 14:05:26 +0200 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] new draft Date: Thu, 2 Sep 2004 14:05:19 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC14E5D7@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] new draft Thread-Index: AcSF24cGtxp2WNNASZyIbWQlBteiiAK7/EOA From: "Pascal Thubert \(pthubert\)" To: "Mazen TLAIS" , "IETF NEMO WG" X-OriginalArrivalTime: 02 Sep 2004 12:05:26.0260 (UTC) FILETIME=[21D2F340:01C490E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: "Sri Gundavelli \(sgundave\)" 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 Mazen: I believe that it is pretty natural for a Mobile Router to own more than one egress interface. Typically today, you'll find MRs with a modem and a 802.11 interfaces. It is also expected that you'll find some proprietary logic for a MR to select its interface and its AR over that interface. Sometimes, it's as obvious as: .11 is fast and free, modem is slow and expensive... guess what, modem has a lower priority then WIFI. On the other hand, potential ARs may be on a same (or same type of) egress interface, but they might provide uneven services (nesting level, security, bandwidth). I would really like to see a draft that examines that problem and makes recommendations on how MRs should behave, what should be customizable in the AR selection, etc... if you're interested :) For current implementations or trials, a set of tools are available: RFC 2461: RA is the base tool for all. Proves to be a little slow for mobility RFC 3775: improves ND making RA faster and more verbose. DNA: should go further in NUD but still, the AR is the horizon. =20 draft-ietf-ipv6-router-selection-05.txt helps the node (the MR in our case) select its attachment router based on a preference, and routes if you are lucky enough to find an AR that has a more specific route to home. The draft does not say how the routers negotiate that in the backend and I believe it's a good thing. draft-thubert-tree-discovery-00.txt adds information for nested MRs, and since TD forms trees, Route Information Option from draft-ietf-ipv6-router-selection-05.txt can safely be proxied. Also, it is expected that more metrics - such as bandwidth - will be added to TD to help MRs make even more educated decisions. All have the concept that the MR makes the final decision for AR selection. This can be based on the actual reachability, bandwidth ... it gets by trying the ARs. This can be based on node policies. An external box does not know about all this.=20 Note also that the problem you address is valid for any multihomed node, e.g. a web server. So, conceptually, I'm not too keen in pushing that draft the way it's presented, in terms of architecture and in terms of WG. On the other hand, I agree that there is a need for a gateway that would be placed like the ARC. One example, as we all know it, is a HA for LMM. See draft-droms-nemo-dhcpv6-pd-01.txt for a NEMO version of it. I agree that the reservations can not placed end to end because it's hard to move them when the MR moves, and that it would be cool to place reservations in loose hops, like: MR<->LMM<->HA<->HA<->LMM<->MR Or MR<->LMM<->CR So again, I would like to see a draft describing which functions to place in such gateway... I would also like to see extensions to http://www.ietf.org/internet-drafts/draft-jang-dhc-haopt-00.txt to help locate that gateway and find out about its capabilities, as opposed to overload RAs over and over. What do you think? Pascal From nemo-bounces@ietf.org Thu Sep 2 08:54:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29822 for ; Thu, 2 Sep 2004 08:54:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2r2z-0000K2-2q; Thu, 02 Sep 2004 08:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2q8I-00055u-BW for nemo@megatron.ietf.org; Thu, 02 Sep 2004 07:52:02 -0400 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 HAA24895 for ; Thu, 2 Sep 2004 07:52:01 -0400 (EDT) Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2qAg-00041M-Df for nemo@ietf.org; Thu, 02 Sep 2004 07:54:30 -0400 Received: (qmail 461 invoked for bounce); 2 Sep 2004 11:52:08 -0000 Received: from unknown (HELO ?130.79.90.171?) (montavont@unknown) by unknown with SMTP; 2 Sep 2004 11:52:08 -0000 Message-ID: <4136ED3C.6010802@clarinet.u-strasbg.fr> Date: Thu, 02 Sep 2004 11:51:56 +0200 From: Nicolas Montavont User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040830) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] Question on TD References: <7892795E1A87F04CADFCCF41FADD00FC104334@xmb-ams-337.emea.cisco.com> <20040901.003735.74751084.watari@sfc.wide.ad.jp> In-Reply-To: <20040901.003735.74751084.watari@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA24895 X-Mailman-Approved-At: Thu, 02 Sep 2004 08:50:35 -0400 Cc: nemo@ietf.org, pthubert@cisco.com, ernst@sfc.wide.ad.jp 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 all, Sorry for the late reply... I don't think we should remove the multihoming case in the draft. If we agree that we need new option(s) to discover and build trees, it is also important to forward useful information to MNNs for their=20 configuration. As you point out, in a nested NEMO, several encapsulations might be neede= d. So, if we could forward the MR's level in RAs, this information may help=20 the MNNs to choose their default router, before configuring anything=20 (MNNs establishes L2 link and then began the level 3 configuration). My point here is to consider the nested NEMO issue in its globality: how=20 to avoid loops, how to build the trees, how to recover from a failure,=20 how to optimize the route selection and so on. Nicolas Masafumi Watari wrote: >Hi all, > >On Tue, 31 Aug 2004 14:24:20 +0200, >"Pascal Thubert (pthubert)" wrote: > > =20 > >>I agree that the multihoming case in the draft may not be the most appr= opriate and we might remove it for simplicity (Nicolas, what do you think= ?). >> >>There's still something that surprises me. In the discussions, it seems= that the nested tree is taken for granted and then NEMO can start. Here,= the MN is connected to the MR, etc... >> >>Well actually that's not granted at all. This tree has to be establishe= d and maintained. A VMR permanently does its 'DNA' and might change its A= R at any time...and that AR can be a MR as well -> a MAR. The question at= DNA level might be 'am I connected to the same link'. But for nested NEM= O, you want to know what's behind a MAR before you even try it. For insta= nce the level of nesting, or whether you can get to the infrastructure, e= tc... >> =20 >> > >You mean, a MR would want to know where the MAR is connected behind, >and not what's behind a MAR, correct? > >I don't know how to assure that AR or MAR actually provides a path to >the infrastructure, but knowing the level of nesting before trying to >connect to is important to avoid forming the nest itself. We all know >that the more deeper the nest gets, the more delay it causes to >packets and the less MTU we have. If there is more MRs than the MTU >allows in a tree without any loops, thats what I think is the real >problem of nested NEMO. In that sense, TD is one of the solution to >solve the forming of such state. > >BTW, if we allow a fixed router to be attached behind a MR, those >routers must also provide the TIO with TD. > >Masafumi Watari > > =20 > >>Pascal >> >> =20 >> >>>-----Original Message----- >>>From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf O= f Thierry Ernst >>>Sent: mardi 31 ao=FBt 2004 05:57 >>>To: nemo@ietf.org >>>Subject: Re: [nemo] Question on TD >>> >>> >>>Hi, >>> >>> =20 >>> >>>>"When the NEMO where the MN is connected to is multihomed, the MN may >>>>have the choice between several AR to be its default router" >>>> >>>>What does this mean? >>>> =20 >>>> >>>I concur, 'what does it mean' ? If a MN attaches to the NEMO (and thus >>>becomes a VMN from our terminology), its default router is the MR (or >>>one of the MR if the NEMO is multihomed (cases [n,*,1] from >>>http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues= -00.txt). >>>The AR is the default router of the MR. >>> >>> =20 >>> >>>>If MNis connected to a NEMO then it is connected, so it has no choice >>>>between several AR's. MN has a default router already. It's that >>>>NEMO's TLMR that has choice, no? >>>> >>>>Or maybe it is meant that MN may use one of the two MR's (TLMR's) as = its >>>>default route? >>>> =20 >>>> >>>in which case the default router of the VMN would still be one of the >>>root-MRs (what some people call TLMR - note that the decision at IETF6= 0 >>>is to remove this term and solely use root-MR). >>> >>>Thierr >>> >y > =20 > From nemo-bounces@ietf.org Thu Sep 2 09:26:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02118 for ; Thu, 2 Sep 2004 09:26:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rWO-0007dZ-M6; Thu, 02 Sep 2004 09:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rKv-0002Ba-Hf for nemo@megatron.ietf.org; Thu, 02 Sep 2004 09:09:09 -0400 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 JAA00873 for ; Thu, 2 Sep 2004 09:09:08 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2rNJ-0001x4-Ct for nemo@ietf.org; Thu, 02 Sep 2004 09:11:38 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2004 15:12:57 +0200 X-BrightmailFiltered: true 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 i82D7X1a026025; Thu, 2 Sep 2004 15:08:34 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 15:08:17 +0200 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] Aggregated prefixes and Proxy ND Date: Thu, 2 Sep 2004 15:08:13 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC14E615@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Aggregated prefixes and Proxy ND Thread-Index: AcSQQerfN0hYs30KR6SS38uSMq2zBAAfT+0A From: "Pascal Thubert \(pthubert\)" To: "Ville Nuorvala" , X-OriginalArrivalTime: 02 Sep 2004 13:08:17.0828 (UTC) FILETIME=[E9DA8E40:01C490ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Ville :) > Since the HoA will never be on the same link as the HA, should the HA > still do the DAD probe and perform Proxy ND for it? Then again, I guess > there isn't any harm in doing that, so perhaps it's ok for the HA to > always do Proxy ND for the MR. I'm not sure that the nemo basic support spec should say anything about that; but the home network model, definitely, because this depends no the model being deployed. NEMO has extended the MIP concept of Home. Depending on the model, Home might be applied on a virtual or a physical link. Or Home might just be an aggregation that is declared to the HA configuration in terms of routes. What is supported depends on the implementation. If Home is not applied on a physical link, then obviously there is no DAD. Conceptually, there is a movement out of ND dependencies. MIP6 is based on ND, NEMO has remnants of that when the home link is applied on a physical link, HAHA protocol gets rid of that completely. In fine, the idea is that the home address would end up being used as a unique ID, and NEMO could a route to the MNP over a tunnel that ends at the Care-Of Address, the whole thing being correlated by the home address. The fact that the home address is on a home link, on an MNP, or just any form of unique ID would be inconsequential. But for now with nemo basic support: the Home Addresses being part of the MNPs is not a problem is the link is virtual or if Home is configured outside of a link for your implementation - as opposed to MIP6 where home is on a link.=20 If Home has to be configured on a physical link for your HA to recognize it as home, then yes you may have to perform DAD. This is needed at least in the case of aggregated home network, if your implementation supports it. If the MR is at home, the MR bridges the packets to the MNPs and yes, if the MR is at home, then, virtually, all the MNNs are on the home link, so, in particular, the MR home address can be reached for DAD. In the case of the extended home network, if the MR Home Addresses is taken from the MNP, the home address is not expected on the home link in any case, and as you point out, DAD would useless. But then the MR can never come back home, either. In my mind, the expectation for extended home network is that you take the home address from the home link, not from the MNP. Pascal From nemo-bounces@ietf.org Thu Sep 2 14:33:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26118 for ; Thu, 2 Sep 2004 14:33:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2wCM-00051R-SH; Thu, 02 Sep 2004 14:20:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2wA2-0003xA-KA for nemo@megatron.ietf.org; Thu, 02 Sep 2004 14:18:14 -0400 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 OAA25320 for ; Thu, 2 Sep 2004 14:18:13 -0400 (EDT) Received: from web25006.mail.ukl.yahoo.com ([217.12.10.42]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C2wCQ-000230-Cw for nemo@ietf.org; Thu, 02 Sep 2004 14:20:46 -0400 Message-ID: <20040902181738.81419.qmail@web25006.mail.ukl.yahoo.com> Received: from [137.194.192.231] by web25006.mail.ukl.yahoo.com via HTTP; Thu, 02 Sep 2004 20:17:38 CEST Date: Thu, 2 Sep 2004 20:17:38 +0200 (CEST) From: =?iso-8859-1?q?Mazen=20TLAIS?= Subject: RE: [nemo] new draft To: "Pascal Thubert \(pthubert\)" , IETF NEMO WG In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC14E5D7@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA25320 Cc: "Sri Gundavelli \(sgundave\)" 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 --- "Pascal Thubert (pthubert)" a =E9crit :=20 > Hi Mazen: >=20 > I believe that it is pretty natural for a Mobile > Router to own more than > one egress interface. Typically today, you'll find > MRs with a modem and > a 802.11 interfaces. >=20 > It is also expected that you'll find some > proprietary logic for a MR to > select its interface and its AR over that interface. > Sometimes, it's as > obvious as: .11 is fast and free, modem is slow and > expensive... guess > what, modem has a lower priority then WIFI. >=20 > On the other hand, potential ARs may be on a same > (or same type of) > egress interface, but they might provide uneven > services (nesting level, > security, bandwidth). I would really like to see a > draft that examines > that problem and makes recommendations on how MRs > should behave, what > should be customizable in the AR selection, etc... > if you're interested > :) >=20 > For current implementations or trials, a set of > tools are available: >=20 > RFC 2461: RA is the base tool for all. Proves to be > a little slow for > mobility >=20 > RFC 3775: improves ND making RA faster and more > verbose. >=20 > DNA: should go further in NUD but still, the AR is > the horizon. =20 >=20 > draft-ietf-ipv6-router-selection-05.txt helps the > node (the MR in our > case) select its attachment router based on a > preference, and routes if > you are lucky enough to find an AR that has a more > specific route to > home. The draft does not say how the routers > negotiate that in the > backend and I believe it's a good thing. >=20 > draft-thubert-tree-discovery-00.txt adds information > for nested MRs, and > since TD forms trees, Route Information Option from > draft-ietf-ipv6-router-selection-05.txt can safely > be proxied. Also, it > is expected that more metrics - such as bandwidth - > will be added to TD > to help MRs make even more educated decisions. >=20 > All have the concept that the MR makes the final > decision for AR > selection. This can be based on the actual > reachability, bandwidth ... > it gets by trying the ARs. This can be based on node > policies. An > external box does not know about all this.=20 >=20 > Note also that the problem you address is valid for > any multihomed node, > e.g. a web server. I completely agree with you, this problem is more and more important and I'm so interested to work on the AR selection for multihomed nodes. I see a usual case where the nodes are multihomed like in the forth generation networks and I think that there is not enough research on this scenario. =20 =20 > So, conceptually, I'm not too keen in pushing that > draft the way it's > presented, in terms of architecture and in terms of > WG. Our choice of the WG is related on the resource reservation protocol adapted for NEMO networks. We think that ARC is needed for such protocol. I did not understand what did you mean by architecture, is it the place of the ARC in the NEMO hierarchy? the function of the ARC? or the entities' communications? > On the other hand, I agree that there is a need for > a gateway that would > be placed like the ARC. > One example, as we all know it, is a HA for LMM. See > draft-droms-nemo-dhcpv6-pd-01.txt for a NEMO version > of it. > > I agree that the reservations can not placed end to > end because it's > hard to move them when the MR moves, and that it > would be cool to place > reservations in loose hops, like: >=20 > MR<->LMM<->HA<->HA<->LMM<->MR > Or > MR<->LMM<->CR >=20 > So again, I would like to see a draft describing > which functions to > place in such gateway... > I would also like to see extensions to > http://www.ietf.org/internet-drafts/draft-jang-dhc->haopt-00.txt > to help > locate that gateway and find out about its > capabilities, as opposed to > overload RAs over and over. I agree that we don't have to overload RAs, I will read that draft and maybe we can find a suitable=20 way to locate the gateway. > What do you think? :), I see that ARC functionalities are diverse. ARC may be useful for AR selection, handover, resource reservation, service continuity and many other applications. I think that we can work to improve such architecture. Thanks for your comments Regards Mazen =09 =09 =09 Vous manquez d=92espace pour stocker vos mails ?=20 Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les nouveau= t=E9s pour dialoguer instantan=E9ment avec vos amis. A t=E9l=E9charger gr= atuitement sur http://fr.messenger.yahoo.com From nemo-bounces@ietf.org Tue Sep 14 10:13:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12578 for ; Tue, 14 Sep 2004 10:13:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7DvR-0005tW-90; Tue, 14 Sep 2004 10:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7DjW-00010T-6T for nemo@megatron.ietf.org; Tue, 14 Sep 2004 09:52:34 -0400 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 JAA10480 for ; Tue, 14 Sep 2004 09:52:32 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7DoP-0006lX-Sb for nemo@ietf.org; Tue, 14 Sep 2004 09:57:39 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0A0993A32F for ; Tue, 14 Sep 2004 15:52:00 +0200 (CEST) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp01.uc3m.es (Postfix) with ESMTP id C74F63A2F6 for ; Tue, 14 Sep 2004 15:51:59 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: nemo@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LVCHSpvVy006wwIx+/B3" Organization: Universidad Carlos III de Madrid Message-Id: <1095169934.2436.54.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Sep 2004 15:52:14 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [nemo] IETF60 NEMO minutes 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 --=-LVCHSpvVy006wwIx+/B3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, Are the minutes from last IETF NEMO meeting available? Thanks a lot. Carlos J. --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-LVCHSpvVy006wwIx+/B3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBRveO5vKyPtrWqkARAjWtAJ4g5YTSca2Yp6ZHlag1iBvn5FHdWQCgsr9z 1ELsSUK3Ag7mGo9DO3g1LTk= =8E0c -----END PGP SIGNATURE----- --=-LVCHSpvVy006wwIx+/B3-- From nemo-bounces@ietf.org Thu Sep 16 08:52:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08795 for ; Thu, 16 Sep 2004 08:52:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7vgp-000181-TF; Thu, 16 Sep 2004 08:48:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7vXS-00007p-O4 for nemo@megatron.ietf.org; Thu, 16 Sep 2004 08:39:02 -0400 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 IAA08002 for ; Thu, 16 Sep 2004 08:39:00 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7vcl-0007Um-NJ for nemo@ietf.org; Thu, 16 Sep 2004 08:44:33 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i8GCdFvb014523 for ; Thu, 16 Sep 2004 05:39:15 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i8GCcv1J008889 for ; Thu, 16 Sep 2004 07:38:58 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 727368A3584 for ; Thu, 16 Sep 2004 14:38:57 +0200 (CEST) Message-ID: <4149895A.5080901@motorola.com> Date: Thu, 16 Sep 2004 14:38:50 +0200 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: IETF NEMO WG X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigECF2DB2083344A7AC2D4926A" X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [nemo] list admin stuff: when subscribing use a meaningful email address 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECF2DB2083344A7AC2D4926A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I'm addressing this message to all potential new subscribers to the NEMO mailing list (this list), but not to the existing subscribers. When subscribing to the NEMO list, please use a meaningful email address that reflects somehow your identity. Email addresses containing first name and/or last name are the ideal choices. Also, good choices may contain the string "nemo" or "ietf" or "software" or "protocol" or "hacking" or similar in the name part. Even "temple of saint nemo" sounds good. Very bad choices are constituted by some apparently random strings, such as "xnpqmcnf@expanets.com" or "xqdjjxyzz@knology.net" or other strings usually generated by mass UCE such as "thirdman77@yahoo.co.jp" or "pacificlotto2004@yahoo.com". I'm continuously banning subscription of such bad email addresses, on a first come first served basis; but I never ban subscriptions of meaningful addresses, such as "jennifer@eyou.com". In case of problem subscribing to the NEMO list, please write to nemo-admin@ietf.org, Chairs and myself are aliased to it. Thanks, Alex --------------enigECF2DB2083344A7AC2D4926A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBSYlhMmC0w56zj54RAu90AJ4lF0ibA2VL3kT38iGgypj26RCniQCgysrY zdH7KekSutzJuM5Rpae4YN4= =K607 -----END PGP SIGNATURE----- --------------enigECF2DB2083344A7AC2D4926A-- From nemo-bounces@ietf.org Tue Sep 21 01:43:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27885 for ; Tue, 21 Sep 2004 01:43:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9dPK-0003oY-Ob; Tue, 21 Sep 2004 01:41:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9dNA-0003Rw-Vg for nemo@megatron.ietf.org; Tue, 21 Sep 2004 01:39:28 -0400 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 BAA27590 for ; Tue, 21 Sep 2004 01:39:27 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9dTS-00038N-RL for nemo@ietf.org; Tue, 21 Sep 2004 01:45:59 -0400 Received: from beethoven.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 i8L5aNMe023765 for ; Tue, 21 Sep 2004 13:36:23 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 4A512B23EBF for ; Tue, 21 Sep 2004 13:43:30 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1095745409.9269.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 21 Sep 2004 13:43:29 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [nemo] RO Taxonomy 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, In the San Diego meeting, there has been mention of the RO Problem Space Analysis WG item. As most should be aware, Pascal, Molteni, Ohnishi, Eun-Kyoung and myself have been working (or had worked on) the RO Taxonomy draft. I believe I am speaking for the co-authors as well when I say that it is my intention to have this piece of work fulfill the role of the working group item. However, I remember there has been comment on the draft lacking some aspects, and perhaps too solution specific. It is thus my intention to update the draft to best meet the WG requirement. Like to ask the WG on their opinions of what is still lacking for the draft to be put forth as the RO Problem Space analysis. All comments are greatly appreciated. /rgds /cwng From nemo-bounces@ietf.org Tue Sep 21 22:08:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21409 for ; Tue, 21 Sep 2004 22:08:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9wVi-000830-RC; Tue, 21 Sep 2004 22:05:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9wS3-0007Mr-7D for nemo@megatron.ietf.org; Tue, 21 Sep 2004 22:01:47 -0400 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 WAA21125 for ; Tue, 21 Sep 2004 22:01:44 -0400 (EDT) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9wYV-0003JK-On for nemo@ietf.org; Tue, 21 Sep 2004 22:08:28 -0400 Received: from beethoven.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 i8M1wfNl014044; Wed, 22 Sep 2004 09:58:41 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 3D039B23EBF; Wed, 22 Sep 2004 10:05:45 +0800 (SGT) Subject: Re: [nemo] RO Taxonomy From: Chan-Wah Ng To: Vijay Devarapalli In-Reply-To: <4150B30C.60305@iprg.nokia.com> References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1095818744.17421.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 22 Sep 2004 10:05:44 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Wed, 2004-09-22 at 07:02, Vijay Devarapalli wrote: > the current draft seems to havd expired. > Right, another reason for us to update it ;) Please find the draft in http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ro-taxonomy-02.txt /rgds /cwng > vijay > > Chan-Wah Ng wrote: > > Hello all, > > > > In the San Diego meeting, there has been mention of the RO Problem Space > > Analysis WG item. As most should be aware, Pascal, Molteni, Ohnishi, > > Eun-Kyoung and myself have been working (or had worked on) the RO > > Taxonomy draft. I believe I am speaking for the co-authors as well when > > I say that it is my intention to have this piece of work fulfill the > > role of the working group item. However, I remember there has been > > comment on the draft lacking some aspects, and perhaps too solution > > specific. > > > > It is thus my intention to update the draft to best meet the WG > > requirement. Like to ask the WG on their opinions of what is still > > lacking for the draft to be put forth as the RO Problem Space analysis. > > All comments are greatly appreciated. > > > > /rgds > > /cwng > > > > > > > > > > From nemo-bounces@ietf.org Thu Sep 30 08:35:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15703 for ; Thu, 30 Sep 2004 08:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD075-0006em-PT; Thu, 30 Sep 2004 08:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD02q-0005dE-Sa for nemo@megatron.ietf.org; Thu, 30 Sep 2004 08:28:25 -0400 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 IAA15258 for ; Thu, 30 Sep 2004 08:28:23 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD0B5-0006GR-UY for nemo@ietf.org; Thu, 30 Sep 2004 08:36:56 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i8UCLDOc009784; Thu, 30 Sep 2004 05:21:14 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i8UCS1ot029202; Thu, 30 Sep 2004 07:28:02 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0127E863819; Thu, 30 Sep 2004 14:28:17 +0200 (CEST) Message-ID: <415BFBD6.9000701@motorola.com> Date: Thu, 30 Sep 2004 14:28:06 +0200 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: Chan-Wah Ng Subject: Re: [nemo] RO Taxonomy References: <1095745409.9269.14.camel@localhost> <4150B30C.60305@iprg.nokia.com> <1095818744.17421.2.camel@localhost> In-Reply-To: <1095818744.17421.2.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig910E2DFD3407D67F762FDC3E" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: IETF NEMO WG , Vijay Devarapalli 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig910E2DFD3407D67F762FDC3E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The Charter item does not require for an RO Taxonomy (classification). It requires for a problem definition first so let's define the problem. Chan-Wah Ng wrote: > http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ro-taxonomy-02.txt > > >>> As most should be aware, Pascal, Molteni, Ohnishi, Eun-Kyoung and >>> myself have been working (or had worked on) the RO Taxonomy >>> draft. I believe I am speaking for the co-authors as well when I >>> say that it is my intention If you were speaking for your co-authors as well you would have said "it is our intention" and not "it is my intention". Whose intention is it in fact? >>> to have this piece of work fulfill the role of the working group >>> item. I am against this draft becoming the NEMO WG item for route optimization. In short, it is more like describing solutions than actually describing problems, it spends much text in classifying those solutions, "taxonomy". I have more arguments below. >>> However, I remember there has been comment on the draft lacking >>> some aspects, and perhaps too solution specific. I agree. >>> It is thus my intention to update the draft to best meet the WG >>> requirement. So start with the respective charter item. I think some parts of the draft address the charter item while some others go way beyond it. >>> Like to ask the WG on their opinions of what is still lacking for >>> the draft to be put forth as the RO Problem Space analysis. All >>> comments are greatly appreciated. Thanks for asking. The respective charter item is the following: > An informational document which specifies a detailed problem > statement for route optimization and looks at various approaches to > solving this problem. So: first describe the problem. The problem is that paths are artificially long. They are longer than if MIP6 were not used. The problem is worse than with Mobile IPv6 for hosts because multiple HA's are involved (MIP6 for hosts involves "triangular" paths, MIP6 for routers involves "multi-angular" paths). Your "Pinball" routing is your figurative way of understanding my "multi-angular" routing. I suggest the latter term for the terminology document. The NEMO RO problem is not the same as the multiple encapsulation problem. The too-big-packets-because-too-many-headers problem has solutions like compress-those-headers aka ROHC. It may be that a NEMO RO solution reduces the headers size too but that's only a side effect. Solving the NEMO RO problem should at least reduce the path lengths but it is not requiring to reduce the packet sizes. The charter does not require to define Mobility Transparency either, while the draft does it in three versions. The charter does not require dealing with multi-homing and NEMO RO, the draft deals. > This document will look into the issues and tradeoffs involved in > making the network's movement visible to some nodes, by optionally > making them "NEMO aware". The draft describes (in section Mobility transparency and RO) how some nodes are NEMO-aware. That's ok and needed. But I don't see the good description satisfying the charter. First, "end-to-end" principle is mentioned, should have the reference. I don't understand how not passing mobility from MR to CN breaks the e2e principle. Second, having nodes that are NEMO-aware is used as a solution to achieve "mobility transparency". The charter does not require "mobility transparency". It requires a description of the issues and tradeoffs involved making the network's movement visible to some nodes, NEMO-aware. Id' better write it like this: "In order to develop a solution for the problem describe in this document, it might be needed that some nodes become NEMO aware. The CN may be required to interpret bindings between a full address and a partial prefix (instead of between 2 full addresses). The advantage of this is that it may help achieve RO for all LFN's under MR but the tradeoffs are: (1) successful attackers may reroute traffic of an entire prefix (2) it is difficult to use RR tests for all addresses within a prefix." This would be the idea how to write it, but more detailed it should be. > The interaction between route optimization and IP routing will also > be described in this document. So it should. > Furthermore, security considerations for the various approaches will > also be considered. So it should. Alex --------------enig910E2DFD3407D67F762FDC3E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBW/vgMmC0w56zj54RArCQAJ93ywWMjMahTsagGk5cw3/1AsVtjgCg8Zpb q43xIyEbmpa5IwMjl/stkYI= =FbWQ -----END PGP SIGNATURE----- --------------enig910E2DFD3407D67F762FDC3E-- From nemo-bounces@ietf.org Thu Sep 30 10:47:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27300 for ; Thu, 30 Sep 2004 10:47:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD25b-0001Uw-Ab; Thu, 30 Sep 2004 10:39:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD1nV-0004Q3-CN for nemo@megatron.ietf.org; Thu, 30 Sep 2004 10:20:41 -0400 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 KAA25051 for ; Thu, 30 Sep 2004 10:20:38 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD1vj-0000mO-Iw for nemo@ietf.org; Thu, 30 Sep 2004 10:29:13 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i8UELpDx006066; Thu, 30 Sep 2004 07:21:51 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i8UEKYmY012739; Thu, 30 Sep 2004 09:20:35 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2B0EF8A3584; Thu, 30 Sep 2004 16:20:34 +0200 (CEST) Message-ID: <415C162C.9020202@motorola.com> Date: Thu, 30 Sep 2004 16:20:28 +0200 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: Chan-Wah Ng References: <1095745409.9269.14.camel@localhost> In-Reply-To: <1095745409.9269.14.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6319C73F7E3E3B7A4AA7D75E" X-Spam-Score: 0.7 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: IETF NEMO WG Subject: [nemo] Re: more comments on the RO Taxonomy draft 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6319C73F7E3E3B7A4AA7D75E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chan-Wah Ng wrote: > Like to ask the WG on their opinions of what is still lacking for the > draft to be put forth as the RO Problem Space analysis. All comments > are greatly appreciated. Dear Chan-Wah, I've read the draft in more detail and I have several comments. I've hesitated before sending them, because they may look too harsh, but then you say that all comments are greatly appreciated so I'm sending them. I think the draft has some good parts and some badly explained parts and some unnecessary parts. > between nodes in a mobile network and their correspodnet nodes. correspondent. > route optimization with corresponding nodes initiated bu mobile by for bu. > 3. performing RO over the routing infrastructure involving > optimizing the route between two routers situated near to each end > point, instead of end-to-end; Last words should be "instead of end-to-end RO" and "end-to-end RO" should be defined somewhere. Where is it defined? google "end-to-end" the first entry is right so you're lucky. "End-to-end" is like saying that your app talks to my app, and that your app does not talk to my kernel. _That_ is "end-to-end". Ping is not "end-to-end" because your app talks to my kernel. But better rely on that paper's explanation and on that of RFC 3724 "The Rise of the Middle and the Future of End-to-End" and of RFC 3439 "Architectural Guidelines". "End-to-end" is not adapted for what you're trying to say, to my taste. I think what you're trying to say with "end-to-end RO" is more like "keep the network dumb" or "empower the end user" or "keep soft state in the network" or "fate-sharing" similar. I don't have a reference handy for this, but the term "end-to-end" is so much used and so badly so often that I'd take no risk and not use it at all. > Lastly, route optimizations involving nested mobile networks are > explored. This involves minimizing the number of tunnels required > when there is multiple levels of nesting. One can achieve minimal tunnels without actually offering shorter paths, with ROHC. The two goals are different. > This scenario is useful when a lot of MNNs in a mobile network is > communicating with a few "MNN's are communicating", not the "lot is communicating". > In such cases the MR only needs to send one binding update (BU) to > optimized the route between CN and a few MNNs. "optimize" instead. If an MNN is actually a VMN, it is not sufficient for MR to send a BU to CN, the comm still goes to that VMN's HA. Better use "LFN" instead of "MNN". > A major issue with this form of optimization is that the end-to-end > principle of the MIPv6 Reverse Routability (RR) test is broken. What is the "e2e principle of the MIPv6 RR test(s)"? RFC 3775 Mobile IPv6 has no such principle... RFC 3775 Mobile IPv6 has another end-to-end mentioning of end-to-end IPsec, but it is not an end-to-end RR. So the reader is not convinced this is a "major issue"; and also it's called Return not Reverse. > If not, the optimization may be limited to triangular routing > MR->CN->HA->MR. better: "optimization would be limited to only eliminating the CN-HA and HA-MR edges of the MR-CN-HA triangular path." What's "triangular routing" by the way? Is it that all 3 edges are used to send packets? Is it that only two edges are used so? (a prior version of MIP6 was wrongly using sending packets MN-CN and receiving CN-HA-MN, so that was "triangular"; current MIP6 w/o RO is bi-angular path because there's no CN-MN path and there's CN-HA and HA-MN). > When a Mobile Node visits a Mobile Network, the best Route > Optimization is obtained if the path in the Infrastructure is the > same as if the Mobile Network was attached at the attachment point of > the Mobile Router (i.e., there is not additional Tunneling that is > linked to NEMO). I don't understand this. The Mobile Network _is_ attached at the attachment point of the Mobile Router, yet routes are not optimal. > In this model, both the LFN behind the MR and the Correspondent can > be MIP agnostic. The CN can not be MIP agnostic because RFC 3775 requires it to be a MIP believer. The CN may be NEMO-agnostic, and not be NEMO-aware. > The goal is to locate the closest (BGP) gateway for a Correspondent > that is located outside of the domain, and tunnel between the MR and > that gateway as opposed to the Home Agent for that specific > Correspondent. There is a reference for BGP and mobile networks at a this year's NANOG by Cisco I believe, find it. "4.2 Correspondent Router" But earlier the draft was talking about "C-side routers". What's the difference? > The Core Routers for the network of the Correspondent are all CRs. Yes, because CR stands for Core Router. Or? > M-side routers What do you call an edge router to which MR visits and that also serves a CN? Is it a CM-side router? What is an MR to which two MR's visit whose LFN's talk to each other? is this AR a CM-side router? > 5.1 Nested Tunnels Optimization ... > > With no Nested Tunnels Optimization, we would have three > bi-directional nested tunnels > > Such a solution introduces the following problems: > > "Pinball" routing What _is_ Nested Tunnels Optimization? What "solution" introduces the pinball routing? By your logic it would mean that Nested Tunnels Optimization is a solution to the problem of having three bi-directional nested tunnels and this solution (supposedly eliminating the too many tunnels) induces pinball routing! Is this what is meant? > On the other hand, with a Nested Tunnel Optimization, we would have > at most one bi-directional tunnel outside the Mobile Network Partially agree. It is possible to have such a NT Optimization and haveat most zero (instead of one) tunnels, at least within an aggregation of moving networks. Zero-encapsulation RO for nested NEMO. > Mobile Aggregation > > This model applies to a category of problems were the Mobile Networks > share a same administration and consistently move together (e.g. a > fleet at sea). In this model, there is a cascade of Home Agents. This is called a "large moving network" and it has only one HA and one TLMR. By any chance, is "Mobile Aggregation" having a direct link with the "home network models" draft? > The Reverse Routing Header (RRH) approach avoids the multiple > encapsulation Depends what you call encapsulation. RRH, and any routing header for that matter, is already a form of encapsulation because it adds data fields to a pure base header. Of course, multiple encapsulation by adding multiple 40byte base headers is worse than multiple encapsulation by adding only 16byte addresses, but still, one can't say RRH is avoiding multiple encapsulation. > The prefix delegation approach [7] is somewhat to HMIPv6 what Nemo is > to MIPv6. So use AR-PD with HMIPv6 and HA-PD with NEMO. The text on the prefix delegation approach should describe first HA-PD (HA sending prefixes to MR) and second AR-PD (AR sending prefixes to MR). > Although optimization within a mobile network is not within the > charter of the NEMO working group, it might be insightful to discuss > such optimizations. Optimization within a moving network is as much in the NEMO charter as optimization outside of it: define the problem. > These approaches are generally difficult to secure unless all the > Mobile Routers and Visiting Mobile Node belong to a same > administrative domain and share predefined Security Associations. Finally something to which I agree wholehartedly. Something to which can be added "true if no widely deployed security infrastructure". > 1. Binding Update storm Is this stormy or more windy? Because I know a paper simulating this stuff and finding it to be more windy. > 4. Missing BU > > If a CN doesn't receive the full set of PSBU sent by the MR, it will > not be able to infer the full path to a node inside the nested Mobile > Network. The RH will be incomplete and the packet may or may not be > delivered. Ok but don't try to make the BU-BAck exchanges any more reliable than currently is. > 6.3 Mobile Access router selection Remove this. This is CARD. This is specified, Seamoby is closed. > 6.5 Multihoming stuff Remove this, it's not required by this charter item. > 6.5 Mobility Transparency Remove this, it's not required by this charter item. However, the effects of some nodes being NEMO-aware is required and this section has discussion about this. So maybe write a new section keeping those. > 1) The RR test prevents a MR-LFN dichotomy on the Mobile Side, What is a "MR-LFN dichotomy"? Alex --------------enig6319C73F7E3E3B7A4AA7D75E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBXBYxMmC0w56zj54RArNBAJ91Go99F3wn/8oNfHq3KoVtGJ1mxQCeNTFc rwN9/dKb0hAkW3oM5uHk6LU= =gDIF -----END PGP SIGNATURE----- --------------enig6319C73F7E3E3B7A4AA7D75E-- From nemo-bounces@ietf.org Thu Sep 30 13:13:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11010 for ; Thu, 30 Sep 2004 13:13:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD4De-00050a-7C; Thu, 30 Sep 2004 12:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD3u0-0007z5-JC for nemo@megatron.ietf.org; Thu, 30 Sep 2004 12:35:33 -0400 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 MAA07004 for ; Thu, 30 Sep 2004 12:35:29 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD42H-0004MN-RB for nemo@ietf.org; Thu, 30 Sep 2004 12:44:06 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i8UGajDx028935; Thu, 30 Sep 2004 09:36:45 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i8UGYI51023567; Thu, 30 Sep 2004 11:34:19 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 965538A3C61; Thu, 30 Sep 2004 18:35:28 +0200 (CEST) Message-ID: <415C35CB.1040502@motorola.com> Date: Thu, 30 Sep 2004 18:35:23 +0200 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: IETF NEMO WG X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig686FD2359937AE46BB12975F" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Thierry Ernst , "T.J. Kniveton" Subject: [nemo] minutes SD available, for whoever is wondering 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig686FD2359937AE46BB12975F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is normally announced by Chairs, sorry for interfering. The minutes of the last meeting in San Diego are available on the NEMO website, since some time now. For whoever is wondering. Thanks, Alex --------------enig686FD2359937AE46BB12975F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBXDXQMmC0w56zj54RAqLQAKC7nruMOhHbAVbEkZsSR7gjPj+08gCg41OO 7bfE8jh0pPilR9W0iAU47Yg= =+EJ+ -----END PGP SIGNATURE----- --------------enig686FD2359937AE46BB12975F-- From nemo-bounces@ietf.org Thu Sep 30 22:00:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23203 for ; Thu, 30 Sep 2004 22:00:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDCUF-0007Oi-OS; Thu, 30 Sep 2004 21:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDCOC-0004cl-R4 for nemo@megatron.ietf.org; Thu, 30 Sep 2004 21:39:16 -0400 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 VAA22198 for ; Thu, 30 Sep 2004 21:39:13 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDCWY-00012b-7y for nemo@ietf.org; Thu, 30 Sep 2004 21:47:54 -0400 Received: from vis101b.inria.fr (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 47B884C0B1 for ; Fri, 1 Oct 2004 10:38:44 +0900 (JST) Date: Fri, 1 Oct 2004 10:40:58 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20041001104058.413a823f.ernst@sfc.wide.ad.jp> In-Reply-To: <415C35CB.1040502@motorola.com> References: <415C35CB.1040502@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [nemo] Re: minutes SD available - on agenda for Washington 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, On Thu, 30 Sep 2004 18:35:23 +0200 Alexandru Petrescu wrote: > This is normally announced by Chairs, sorry for interfering. > > The minutes of the last meeting in San Diego are available on the NEMO > website, since some time now. For whoever is wondering. Well, this is also available on the official IETF proceeding web site. Together with all slides. I assume every body knows about that, but we could certainly have posted a note on the ML, right. For next IETF, I've just asked a 2h slot. We don't yet have any agenda; I personaly think it should include the following items: - WG doc status - Prefix delegation for NEMO Basic Support - RO problem statement (not "solutions") - Multihoming problem statement - HAHA - WG charter If there are other subjects that you think should be discussed, I would recommend to first initiate a discussion on the ML; we can certainly add more topics based on interest. Thierry.