From nemo-bounces@ietf.org Mon Nov 1 01:41:39 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 BAA13050 for ; Mon, 1 Nov 2004 01:41:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COVpJ-0001xP-7x; Mon, 01 Nov 2004 01:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COVoC-0001kp-Fc for nemo@megatron.ietf.org; Mon, 01 Nov 2004 01:36:53 -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 BAA12735 for ; Mon, 1 Nov 2004 01:36: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 1COW2n-0006lb-5o for nemo@ietf.org; Mon, 01 Nov 2004 01:51:58 -0500 Received: from iseran.local (net56-dhcp-234.sfc.keio.ac.jp [133.27.57.234]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 2AF7A4C069; Mon, 1 Nov 2004 15:35:53 +0900 (JST) Date: Mon, 1 Nov 2004 15:38:30 +0900 From: Thierry Ernst To: Chan-Wah NG Subject: Re: [nemo] NEMO Agenda CFP Message-Id: <20041101153830.4d282795.ernst@sfc.wide.ad.jp> In-Reply-To: <1099190424.10501.8.camel@localhost> References: <20041028144917.24906a7c.ernst@sfc.wide.ad.jp> <1099190424.10501.8.camel@localhost> 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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, tj@kniveton.com 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 ChanWah, OK for the 1st draft, but the second is a solution, not a discussion about pb statement. Am I mistaken ? Thierry > draft-thubert-nemo-ro-taxonomy-03.txt: > I understand that we have presenetd this draft previously, however, as > this version is a major update, I'll like to do a brief description of > it. > > draft-ng-nemo-rrnp-00.txt: > This is not a RO solution, but a mechanism for potential RO solution to > make use of. It also raises some security concerns on the use of > network prefixes in RO. > > I wouldn't need anything more than 5 mins for each of them. > > /rgds > /cwng > > > > On Thu, 2004-10-28 at 13:49, Thierry Ernst wrote: > > Dear all, > > > > The NEMO WG is currently scheduled a 2h-slot at Washington, Wednesday > > 13.00-15.00. > > > > At least the following items will be included in the agenda: > > - WG status > > - draft-ietf-nemo-basic-support > > - draft-ietf-nemo-mib > > - draft-ietf-nemo-home-network-models > > - draft-ietf-nemo-multihoming-issues > > - TAHI announcement > > - possible re-chartering > > - prefix delegation > > > > > > If you would like a timeslot for a topic not listed above, please send > > a request to both chairs by the end of this week showing: > > - topic > > - draft name and title if appropriate > > - time length > > - what issue do you intend to discuss > > - how does it fall into the above listed priorities of the WG or one of > > the NEMO charter item > > > > Requests will be honored based on available time, priorities of the NEMO > > WG, and DISCUSSION ARISING ON THE MAILING LIST before the meeting. In > > case several people want to discuss similar issues, we would rather > > advocate a discussion on the ML and one single person summarizing the > > issues during the meeting. > > > > Only drafts previously announced on the NEMO ML will be considered for > > slots. > > > > > > The NEMO WG Chairs. > > > > > > > From nemo-bounces@ietf.org Mon Nov 1 01:48:54 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 BAA13347 for ; Mon, 1 Nov 2004 01:48:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COVyP-0002b2-Dx; Mon, 01 Nov 2004 01:47:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COVxU-0002Vd-Fi for nemo@megatron.ietf.org; Mon, 01 Nov 2004 01:46: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 BAA13211 for ; Mon, 1 Nov 2004 01:46:27 -0500 (EST) Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COWCH-0006vy-4Q for nemo@ietf.org; Mon, 01 Nov 2004 02:01:49 -0500 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 iA16gwXL029636; Mon, 1 Nov 2004 14:42:58 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id C4150B23F11; Mon, 1 Nov 2004 14:48:42 +0800 (SGT) Subject: Re: [nemo] NEMO Agenda CFP From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20041101153830.4d282795.ernst@sfc.wide.ad.jp> References: <20041028144917.24906a7c.ernst@sfc.wide.ad.jp> <1099190424.10501.8.camel@localhost> <20041101153830.4d282795.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Laboratories Message-Id: <1099291722.24133.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 01 Nov 2004 14:48:42 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "T.J. Kniveton" 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 Thierry, Well, I choose not to view RRNP as a RO solution, but one can of-course view it that way. It discusses the security issue of sending prefixes in binding update to any entity other than HA, and proposed a mechanism to address that issue. /rgds /cwng On Mon, 2004-11-01 at 14:38, Thierry Ernst wrote: > Dear ChanWah, > > OK for the 1st draft, but the second is a solution, not a discussion > about pb statement. Am I mistaken ? > > Thierry > > > > > draft-thubert-nemo-ro-taxonomy-03.txt: > > I understand that we have presenetd this draft previously, however, as > > this version is a major update, I'll like to do a brief description of > > it. > > > > draft-ng-nemo-rrnp-00.txt: > > This is not a RO solution, but a mechanism for potential RO solution to > > make use of. It also raises some security concerns on the use of > > network prefixes in RO. > > > > I wouldn't need anything more than 5 mins for each of them. > > > > /rgds > > /cwng > > > > > > > > On Thu, 2004-10-28 at 13:49, Thierry Ernst wrote: > > > Dear all, > > > > > > The NEMO WG is currently scheduled a 2h-slot at Washington, Wednesday > > > 13.00-15.00. > > > > > > At least the following items will be included in the agenda: > > > - WG status > > > - draft-ietf-nemo-basic-support > > > - draft-ietf-nemo-mib > > > - draft-ietf-nemo-home-network-models > > > - draft-ietf-nemo-multihoming-issues > > > - TAHI announcement > > > - possible re-chartering > > > - prefix delegation > > > > > > > > > If you would like a timeslot for a topic not listed above, please send > > > a request to both chairs by the end of this week showing: > > > - topic > > > - draft name and title if appropriate > > > - time length > > > - what issue do you intend to discuss > > > - how does it fall into the above listed priorities of the WG or one of > > > the NEMO charter item > > > > > > Requests will be honored based on available time, priorities of the NEMO > > > WG, and DISCUSSION ARISING ON THE MAILING LIST before the meeting. In > > > case several people want to discuss similar issues, we would rather > > > advocate a discussion on the ML and one single person summarizing the > > > issues during the meeting. > > > > > > Only drafts previously announced on the NEMO ML will be considered for > > > slots. > > > > > > > > > The NEMO WG Chairs. > > > > > > > > > > > > From mailman-bounces@ietf.org Mon Nov 1 07:18:22 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 HAA23252 for ; Mon, 1 Nov 2004 07:18: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 1COZVa-0005D4-79 for nemo-archive@lists.ietf.org; Mon, 01 Nov 2004 05:33:54 -0500 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: Mon, 01 Nov 2004 05:13:08 -0500 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 Mon Nov 1 12:59:20 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 MAA10026 for ; Mon, 1 Nov 2004 12:59: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 1COg4C-00009z-Fb; Mon, 01 Nov 2004 12:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfjr-0003gr-51 for nemo@megatron.ietf.org; Mon, 01 Nov 2004 12:13: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 MAA05090 for ; Mon, 1 Nov 2004 12:13: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 1COfyl-0004eQ-J0 for nemo@ietf.org; Mon, 01 Nov 2004 12:28:29 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2004 18:31:30 +0100 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 iA1HBrvl010209; Mon, 1 Nov 2004 18:12:26 +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.0); Mon, 1 Nov 2004 18:12:09 +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] NEMO Agenda CFP Date: Mon, 1 Nov 2004 18:12:03 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC3CC638@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] NEMO Agenda CFP Thread-Index: AcS/3vs+kmowVNsKR86kR9gJ10NcDgAVqYqA From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah Ng" , "Thierry Ernst" X-OriginalArrivalTime: 01 Nov 2004 17:12:09.0323 (UTC) FILETIME=[EBB083B0:01C4C035] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , "T.J. Kniveton" 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: I understand that the second draft is half solution space. But then, I also believe that some hints about the solutions that are being considered and the problems that are found are very educational to understand the NEMO RO problem set. So, if there's time left, I'd support Chan Wah for presenting the issues that he has isolated... Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Chan-Wah Ng > Sent: lundi 1 novembre 2004 07:49 > To: Thierry Ernst > Cc: IETF NEMO WG; T.J. Kniveton > Subject: Re: [nemo] NEMO Agenda CFP >=20 > Hello Thierry, >=20 > Well, I choose not to view RRNP as a RO solution, but one can of-course > view it that way. It discusses the security issue of sending prefixes > in binding update to any entity other than HA, and proposed a mechanism > to address that issue. >=20 > /rgds > /cwng >=20 >=20 > On Mon, 2004-11-01 at 14:38, Thierry Ernst wrote: > > Dear ChanWah, > > > > OK for the 1st draft, but the second is a solution, not a discussion > > about pb statement. Am I mistaken ? > > > > Thierry > > > > > > > > > draft-thubert-nemo-ro-taxonomy-03.txt: > > > I understand that we have presenetd this draft previously, however, as > > > this version is a major update, I'll like to do a brief description of > > > it. > > > > > > draft-ng-nemo-rrnp-00.txt: > > > This is not a RO solution, but a mechanism for potential RO solution to > > > make use of. It also raises some security concerns on the use of > > > network prefixes in RO. > > > > > > I wouldn't need anything more than 5 mins for each of them. > > > > > > /rgds > > > /cwng > > > > > > > > > > > > On Thu, 2004-10-28 at 13:49, Thierry Ernst wrote: > > > > Dear all, > > > > > > > > The NEMO WG is currently scheduled a 2h-slot at Washington, Wednesday > > > > 13.00-15.00. > > > > > > > > At least the following items will be included in the agenda: > > > > - WG status > > > > - draft-ietf-nemo-basic-support > > > > - draft-ietf-nemo-mib > > > > - draft-ietf-nemo-home-network-models > > > > - draft-ietf-nemo-multihoming-issues > > > > - TAHI announcement > > > > - possible re-chartering > > > > - prefix delegation > > > > > > > > > > > > If you would like a timeslot for a topic not listed above, please send > > > > a request to both chairs by the end of this week showing: > > > > - topic > > > > - draft name and title if appropriate > > > > - time length > > > > - what issue do you intend to discuss > > > > - how does it fall into the above listed priorities of the WG or one of > > > > the NEMO charter item > > > > > > > > Requests will be honored based on available time, priorities of the NEMO > > > > WG, and DISCUSSION ARISING ON THE MAILING LIST before the meeting. In > > > > case several people want to discuss similar issues, we would rather > > > > advocate a discussion on the ML and one single person summarizing the > > > > issues during the meeting. > > > > > > > > Only drafts previously announced on the NEMO ML will be considered for > > > > slots. > > > > > > > > > > > > The NEMO WG Chairs. > > > > > > > > > > > > > > > > > >=20 From nemo-bounces@ietf.org Mon Nov 1 13:19:23 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 NAA14244 for ; Mon, 1 Nov 2004 13:19: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 1COg9U-0002L0-Lz; Mon, 01 Nov 2004 12:39:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfwQ-0004fq-E3 for nemo@megatron.ietf.org; Mon, 01 Nov 2004 12:26: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 MAA06216 for ; Mon, 1 Nov 2004 12:26:00 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgBM-0004wM-0w for nemo@ietf.org; Mon, 01 Nov 2004 12:41:29 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2004 18:44:31 +0100 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 iA1HPQvL012922; Mon, 1 Nov 2004 18:25:27 +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.0); Mon, 1 Nov 2004 18:25:19 +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] issue 44 Date: Mon, 1 Nov 2004 18:25:13 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC3CC646@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] issue 44 Thread-Index: AcS+Dg752TzqPcojRQSd+MKKwbvFJgCJ/4NA From: "Pascal Thubert \(pthubert\)" To: "Erik Nordmark" , "Ryuji Wakikawa" X-OriginalArrivalTime: 01 Nov 2004 17:25:19.0011 (UTC) FILETIME=[C2615730:01C4C037] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, 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 Content-Transfer-Encoding: quoted-printable Yes, I agree we should consider this in the study for the first revision.=20 OTOH, this doesn't prevent NEMO operations in any fashion. In fact, I expect that the HA, when finding such a problem, should raise a trap or an management alert of some sort; the good thing is that the management is sitting on the HA side... So the involvement of the MR might be more needed at the time to fix the problem (reconfiguring the MR?) then at the time of the error detection / analysis. Also, something might come around in the meantime that addresses this problem. For instance=20 http://www.mobilenetworks.org/nemo/drafts/draft-kniveton-nemo-prefix-del -00.txt has a per prefix ack and a check procedure for implicit prefixes. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: samedi 30 octobre 2004 01:01 > To: Ryuji Wakikawa > Cc: nemo@ietf.org; Vijay Devarapalli > Subject: Re: [nemo] issue 44 >=20 > Ryuji Wakikawa wrote: > > > > I prefer option 1 (do nothing). > > > > I agree that option 2 is useful for debugging and operation. > > But, we need more consideration before going with option 2. > > > > For example, MR sends BU with 2001:a::/48, > > but only 2001:a:b::/64 is valid. > > How can HA include offending prefixes in BA? >=20 > It would tell you that 2001:a::/48 was invalid. > Thus it would only be useful when there are multiple prefixes in the BU. >=20 > Erik From nemo-bounces@ietf.org Mon Nov 1 13:26:24 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 NAA15133 for ; Mon, 1 Nov 2004 13:26: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 1COgaK-0005pT-Jb; Mon, 01 Nov 2004 13:07:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COg62-0001V0-BT for nemo@megatron.ietf.org; Mon, 01 Nov 2004 12:35:58 -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 MAA07560 for ; Mon, 1 Nov 2004 12:35:56 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgKz-0005GM-1E for nemo@ietf.org; Mon, 01 Nov 2004 12:51:25 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2004 18:54:28 +0100 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 iA1HZNvL015227; Mon, 1 Nov 2004 18:35:23 +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.0); Mon, 1 Nov 2004 18:35:13 +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] RO taxonomy Date: Mon, 1 Nov 2004 18:35:06 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC3CC64D@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO taxonomy Thread-Index: AcS92cLXHAnyITZsS2yqnBSdX5fvBwCXh+oQ From: "Pascal Thubert \(pthubert\)" To: "Erik Nordmark" X-OriginalArrivalTime: 01 Nov 2004 17:35:13.0484 (UTC) FILETIME=[24B6B8C0:01C4C039] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , marcelo bagnulo braun , Chan-Wah NG , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= 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: Erik Nordmark [mailto:erik.nordmark@sun.com] > Sent: vendredi 29 octobre 2004 19:08 > To: Pascal Thubert (pthubert) > Cc: IETF NEMO WG; marcelo bagnulo braun; Carlos Jes=FAs Bernardos = Cano; Chan-Wah NG > Subject: Re: [nemo] RO taxonomy >=20 > Pascal Thubert (pthubert) wrote: >=20 >=20 > > 5. Obsolete BU > > > > If the Binding messages are sent asynchronously by each MR, = then, > > when the relative position of MRs and/or the TLMR point of > > attachment change rapidly, the image of Mobile Network that = the > > CN maintains is highly unstable. If only one BU in the chain = is > > obsolete due to the movement of an intermediate MR, the > > connectivity may be lost. >=20 > It also isn't clear to me how such an approach would work when = multiple > MRs move at the same time. With a tree of AR->MR1->MR2->MNN, > if MR1 changes AR at the same time as MR2 changes from MR1, wouldn't = the > fact that each "layer" tries to independently signal the CN make = things > very flaky; some part of one layers 6 packet BU exchange with the CN > might be lost due to the layers above also moving. >=20 > > A conclusion is that the path information must be somehow = aggregated > > to provide the CN with consistent snapshots of the full path = across > > the Mobile Network. This can be achieved by an IPv6 form of = loose > > source / record route header, that we introduce here as a Reverse > > Routing Header >=20 > Another possible way, in the case when the CN is modified, would be to > have the MNN learn the list of CoA from announcements (e.g. in RAs) = from > the chain of MRs above it. > That way the MNN can reliably learn the list, and then the MNN can = pass > the list to the CN in a BU. Right. Actually that way has been proposed in a draft as an improvement = to the RRH. A lot happened on the side of the mainstream in the last 2 = years :) After discussion in this ML, the result of the change seemed = quite identical to the original RRH in terms of security, though a tiny = bit more complex with a bit more latency. So the RRH process was not = modified.=20 Note that the draft still mentions MRHA only and was not extended to CN, = though it's pretty straightforward... waiting for WG attention, when we = are ready for it as a group :) >=20 > But I think the case when the CN isn't modified is about as easy; the > MNN would instead of sending a BU to the CN with the list, it will = send > a BU to the CN which points at the top MR's COLA, and a BU to that MR > which points it at the CoA of the next MR in the tree, etc. > Thus the MNN learns the path of MRs the packets need to traverse and > creates bindings in each MR indicating the next hop. > (MNN->CN path and HAO left as an exercise for the reader :-) >=20 Or all the MRs could register to the root, and we are back to the LMM = story. =20 Pascal From nemo-bounces@ietf.org Mon Nov 1 20:17:11 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 UAA29207 for ; Mon, 1 Nov 2004 20:17: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 1COnF4-0000Qu-D8; Mon, 01 Nov 2004 20:13:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COmwf-00007i-Dn for nemo@megatron.ietf.org; Mon, 01 Nov 2004 19:54:45 -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 TAA27759 for ; Mon, 1 Nov 2004 19:54:42 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnBf-0002GU-8N for nemo@ietf.org; Mon, 01 Nov 2004 20:10:16 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 170664C07F for ; Tue, 2 Nov 2004 09:54:04 +0900 (JST) Date: Tue, 2 Nov 2004 09:56:41 +0900 From: Thierry Ernst To: nemo Message-Id: <20041102095641.08d71f09.ernst@sfc.wide.ad.jp> 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: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [nemo] Draft authors - Just 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 Content-Transfer-Encoding: 7bit Dear all, I've seen some drafts with "nemo" in the draft name advertised on the i-d-announce ML, but not on the NEMO ML. Does it make any sense to publish a draft without informing the WG ? Just wondering. Thierry From nemo-bounces@ietf.org Wed Nov 3 21:40: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 VAA16407 for ; Wed, 3 Nov 2004 21:40: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 1CPXTn-0005ep-LN; Wed, 03 Nov 2004 21:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPXM3-0003zF-Vt for nemo@megatron.ietf.org; Wed, 03 Nov 2004 21:28: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 VAA15309 for ; Wed, 3 Nov 2004 21:28:01 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPXbR-0006GE-Ql for nemo@ietf.org; Wed, 03 Nov 2004 21:44:01 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id F21F64C0AF for ; Thu, 4 Nov 2004 11:27:17 +0900 (JST) Date: Thu, 4 Nov 2004 11:29:57 +0900 From: Thierry Ernst To: nemo Message-Id: <20041104112957.3028dbac.ernst@sfc.wide.ad.jp> 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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Basic Support IPR from CISCO 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, CISCO statement on NEMO Basic Support has changed. Please check http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support-03.txt I think that this doesn't prevent anymore the integration of NEMO Basic Support code in distribution such as KAME's BSD style or USAGI/MIPL's open source. I would like to thank CISCO guys at the Sophia-Antipolis research center for there careful and sensitive answer to our concerns on their previous statement. Thierry. From nemo-bounces@ietf.org Thu Nov 4 03:06: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 DAA24521 for ; Thu, 4 Nov 2004 03:06: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 1CPccC-0005XR-Jg; Thu, 04 Nov 2004 03:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPcYD-00056S-2b for nemo@megatron.ietf.org; Thu, 04 Nov 2004 03:00:58 -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 DAA23872 for ; Thu, 4 Nov 2004 03:00:55 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPcng-0004pZ-SQ for nemo@ietf.org; Thu, 04 Nov 2004 03:16:57 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 4F76D4C0AA for ; Thu, 4 Nov 2004 17:00:16 +0900 (JST) Date: Thu, 4 Nov 2004 17:02:55 +0900 From: Thierry Ernst To: nemo Message-Id: <20041104170255.12d00571.ernst@sfc.wide.ad.jp> 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO minutes, Jabber, etc 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, A couple of questions to the persons present at the meeting and those not present to the meeting: - Is there anyone on this list planning to participate remotely ? - If yes, how ? Jabber ? - If yes, is there anyone physically attending the NEMO slot to serve as a jabber scribe ? - Can we get some volunteer for taking notes ? Thanks in advance, Thierry From nemo-bounces@ietf.org Thu Nov 4 21:35:39 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 VAA08243 for ; Thu, 4 Nov 2004 21:35:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPtvT-0007tL-CY; Thu, 04 Nov 2004 21:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPtuB-0007ak-W1 for nemo@megatron.ietf.org; Thu, 04 Nov 2004 21:32:48 -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 VAA08106 for ; Thu, 4 Nov 2004 21:32:45 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPu9p-0006US-Cv for nemo@ietf.org; Thu, 04 Nov 2004 21:48:57 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C5ED94C0B1 for ; Fri, 5 Nov 2004 11:32:15 +0900 (JST) Date: Fri, 5 Nov 2004 11:34:55 +0900 From: Thierry Ernst To: nemo Message-Id: <20041105113455.21b5d660.ernst@sfc.wide.ad.jp> 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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO WG agenda 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 agenda, Please find the lattest version of our agenda at http://www.mobilenetworks.org/nemo/ietf61/nemo-ietf61-agenda.txt. Current version below (subject to changes). Thierry. # NEMO WG Wed 13:00-15:00, 61th IETF Meeting San Francisco, November 2004 # http://www.ietf.org/html.charters/nemo-charter.html # Draft NEMO WG Agenda, as of Nov.01 2004 # The up-to-date version of this agenda will be posted on # http://www.mobilenetworks.org/nemo/ietf61/nemo-ietf61-agenda.txt # All NEMO WG related drafts can be found on http://www.mobilenetworks.org/nemo 1. Agenda, welcoming, etc .................................................... 05mins Chairs 2. NEMO WG Status............................................................. 05mins Chairs http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-02.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-03.txt 4 NEMO MIB Design ........................................................... 05mins Sri Gundavelli "NEMO Management Information Base" http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt 5. Announcement: 6th TAHI interop test event ................................. 05mins Yukiyo Akisada 6. NEMO Home Network Models (draft status) ................................... 05mins Pascal Thubert http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-01.txt 7. Prefix Delegation ......................................................... 15mins TJ Kniveton 8. NEMO Multihoming Issues ................................................... 20mins "Analysis of Multihoming in Network Mobility Support" http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-01.txt 9. NEMO RO Problem Statement ................................................. 30mins "NEMO Route Optimization Problem Statement" http://www.ietf.org/internet-drafts/draft-clausen-nemo-ro-problem-statement-00.txt Thomas Clausen / Ryuji Wakikawa "NEMO RO Pb Statement, Requirements and Evaluation Considerations" http://www.ietf.org/internet-drafts/draft-zhao-nemo-ro-ps-00.txt Fan Zhao "RO with Nested CNs" http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt Masafumi Watari / Thierry Ernst "Update of "Taxonomy of RO models in the NEMO context" http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-03.txt Pascal Thubert / ChanWah NG 10. Securing Prefix in Binding Updates ........................................ 05mins ChanWah NG "Extending Return Routability Procedure for Network Prefix (RRNP)" http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt 11. Conclusions and Next Steps ................................................ 10mins From nemo-bounces@ietf.org Mon Nov 8 04:57:03 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 EAA16027 for ; Mon, 8 Nov 2004 04:57: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 1CR65S-00035L-QF; Mon, 08 Nov 2004 04:45:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR5vv-0001it-UY for nemo@megatron.ietf.org; Mon, 08 Nov 2004 04:35: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 EAA14585 for ; Mon, 8 Nov 2004 04:35:29 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR5wN-0003O0-Aa for nemo@ietf.org; Mon, 08 Nov 2004 04:36:03 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B0A6E2DC4C; Mon, 8 Nov 2004 10:34:52 +0100 (CET) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id 6A7F62DC35; Mon, 8 Nov 2004 10:34:52 +0100 (CET) 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="=-QeJnHvY8xMU1lPd4yVVZ" Organization: Universidad Carlos III de Madrid Message-Id: <1099906490.2545.12.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 08 Nov 2004 10:34:50 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Ryuji Wakikawa Subject: [nemo] Comments on draft-clausen-nemo-ro-problem-statement-00.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 --=-QeJnHvY8xMU1lPd4yVVZ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Ryuji, First of all, thanks for submitting the draft. Your draft seems to address the problem of the Internet-to-NEMO communication and the NEMO-to-NEMO communication when nesting is involved, using a MANET approach. I agree with you that in the NEMO-to-NEMO approach, having the MRs in a nested-NEMO running an Ad-Hoc routing protocol would help to avoid traversing the Internet and also avoid the encapsulation. On the other hand, I don't see that clear how this would help the Internet-to-NEMO, at least as it is now described in the current version of your draft. The draft says: "Additionally, this would also ease the Internet-to-NEMO scenario. In order to deliver an IP datagram to a node in the nested NEMO network, only a path to the access router between the nested NEMO network and the Internet would be required: once an IP datagram arrives in the nested NEMO network, the routing tables in the mobile routers, as provided by OLSR, would allow direct routing to the destination. Thus, there would no longer be a requirement to do nested encapsula- tion on each logical hop (i.e. each transversal of a Home Agent) in order to be able to decapsulate and correctly forward IP datagrams in the nested NEMO network. Thus even if no route optimizations are performed in the Internet-to- NEMO scenario, an overhead reduction can still be achieved through much lower encapsulation requirements." How this improvements are achieved? If a CN in the Internet sends a packet to a MNN that is connected to a nested-NEMO, the packet would traverse the HAs of every MR in the nested-NEMO until the MNN is finally reached. Therefore, I don't see how this encapsulation would be avoided, without making any additional change to the MR and/or HA and/or CN. Am I missing something? Thanks in advance. Kind Regards, 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 --=-QeJnHvY8xMU1lPd4yVVZ 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) iD8DBQBBjz265vKyPtrWqkARAlpJAKDOWmd8lYxdXDr40/M6xA3TrY5ZnACfYBEG NH//Keks9FgFPrDkhzK81VM= =PkyI -----END PGP SIGNATURE----- --=-QeJnHvY8xMU1lPd4yVVZ-- From nemo-bounces@ietf.org Mon Nov 8 07:03:29 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 HAA25827 for ; Mon, 8 Nov 2004 07:03:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8As-0004Sx-8U; Mon, 08 Nov 2004 06:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR85t-0003tD-Di for nemo@megatron.ietf.org; Mon, 08 Nov 2004 06:53: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 GAA25035 for ; Mon, 8 Nov 2004 06:53:54 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR86P-00067w-FC for nemo@ietf.org; Mon, 08 Nov 2004 06:54:30 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2004 13:14:31 +0100 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 iA8Bqovp010422 for ; Mon, 8 Nov 2004 12:53:21 +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.0); Mon, 8 Nov 2004 12:52:23 +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 Date: Mon, 8 Nov 2004 12:52:19 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC413C2A@xmb-ams-337.emea.cisco.com> Thread-Topic: RO: what have we learnt so far? Thread-Index: AcTFiWaQP5TSrJbOT4qrX1SFeesHkg== From: "Pascal Thubert \(pthubert\)" To: "IETF NEMO WG" X-OriginalArrivalTime: 08 Nov 2004 11:52:23.0297 (UTC) FILETIME=[68D18710:01C4C589] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RO: what have we learnt so far? 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: As you know, the RO problem has been around since NEMO stated, and so have been related drafts.=20 As a group, we have focussed on delivering basic support, but still people could not help working on RO. And we learnt quite a few things overtime. - We have distinguished various problems to be addressed, and categorized the (tenths of) solutions that were proposed. We also have clues about the specific pro/cons of those numerous solutions. - We have found that before optimizing the tunnels and data path of a nested tree of MRs, we should make sure that we build the tree and that the tree is optimized in shape in the first place. We also know that a MR might not want to attach anywhere and that some clues might be needed. We can not just make as if we were 3 years ago, can we? I believe that we can and we should give more food for thought then just "what's the problem here?". This is why the taxonomy is now built in 3 major parts, plus appendix. The problem statement is obviously the 1st of the 3 major parts. The bestiary of the solutions types comes next, and finally the pro/cons. The specific solutions are introduced only in appendix. Some refs are still missing (like MIRON, sorry), but then again, it's a work in progress. Pascal From nemo-bounces@ietf.org Mon Nov 8 14:18:27 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 OAA16685 for ; Mon, 8 Nov 2004 14:18:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREcT-0008FE-EN; Mon, 08 Nov 2004 13:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREXw-0006aF-4R for nemo@megatron.ietf.org; Mon, 08 Nov 2004 13:47: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 NAA11773 for ; Mon, 8 Nov 2004 13:47:18 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREYW-0001P9-8D for nemo@ietf.org; Mon, 08 Nov 2004 13:47:57 -0500 Received: from iseran.local (unknown [130.129.132.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B06B64C08C; Tue, 9 Nov 2004 03:46:30 +0900 (JST) Date: Tue, 9 Nov 2004 03:49:11 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] NEMO WG agenda Message-Id: <20041109034911.58f5d214.ernst@sfc.wide.ad.jp> In-Reply-To: <20041105113455.21b5d660.ernst@sfc.wide.ad.jp> References: <20041105113455.21b5d660.ernst@sfc.wide.ad.jp> 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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: t-sfc , tj 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, To all presenters, please send you slides to TJ and myself. - Pleas name your slides like this: nemo-ietf61-topic-PresenterName.pdf - Please send a .pdf if you can - Please add a version number if you ever send multiple copies. - We will put the slides on http://www.mobilenetworks.org/nemo/ietf61 hopefully before the meeting, so that potential remote people can follow. Please let us know if you intend to follow the meeting remotely, and how. Thierry. From nemo-bounces@ietf.org Mon Nov 8 17:59: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 RAA13965 for ; Mon, 8 Nov 2004 17:59: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 1CRIMG-0007zr-LI; Mon, 08 Nov 2004 17:51:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRI4R-0003Su-Sf for nemo@megatron.ietf.org; Mon, 08 Nov 2004 17:33: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 RAA10917 for ; Mon, 8 Nov 2004 17:33:05 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRI51-0008Gq-KA for nemo@ietf.org; Mon, 08 Nov 2004 17:33:46 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iA8MYQnQ024015; Mon, 8 Nov 2004 15:34:26 -0700 (MST) Received: from [10.182.46.78] (mvp-10-182-46-78.am.mot.com [10.182.46.78]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id iA8MWso8024399; Mon, 8 Nov 2004 16:32:55 -0600 Message-ID: <418FF416.60007@motorola.com> Date: Mon, 08 Nov 2004 23:32:54 +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: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RO: what have we learnt so far? References: <7892795E1A87F04CADFCCF41FADD00FC413C2A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC413C2A@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Pascal Thubert (pthubert) wrote: > - We have found that before optimizing the tunnels and data path of a > nested tree of MRs, we should make sure that we build the tree and > that the tree is optimized in shape in the first place. Pascal, do we agree that, in a nested aggregation of moving networks, they can form _any_ arbitrary graph and that the "tree" you mention is more about the logical view that is formed when looking for shortest paths, and less about how the MR's hardware-ly link to each other? Do we agree that there may be no actual tree other than in the mind of the human describing how the shortest paths are built? Do we agree that every MR may have its own limited view of the network (which view may be a tree) and that this view has nothing to do with the physical hardware topology on which this _spanning_ tree is built? > We also know that a MR might not want to attach anywhere and that > some clues might be needed. MR selecting its attachment point is very much like CARD - Candidate Access Router Discovery. I don't think MR is different than MH when needing to attach, and selecting a better or a worse AR based on synchronized information that those AR's may broadcast. I don't think MR's need take care when attaching such as to ensure they form a tree. I think they should attach to wherever they can attach first, with as many interfaces as they can. After attaching, I think they should exchange information to each other, and propagate the similar information received from other similar MR's. Once all this information is propagated, every MR may build tables with its own logical view of the network, and find paths with the help of these tables. Do you think this is wrong? > We can not just make as if we were 3 years ago, can we? I believe > that we can and we should give more food for thought then just > "what's the problem here?". "Tree Discovery" as is now forces the forming of an aggregation of moving networks that MUST have the physical link of a tree. This is simply not scalable for a network. So while "Tree Discovery" may solve a problem that is important, it may itself introduce much bigger problems than it actually solves. Am I wrong somewhere? And of course we can discuss this also face-to-face here. Alex From nemo-bounces@ietf.org Tue Nov 9 07:15:33 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 HAA17424 for ; Tue, 9 Nov 2004 07:15: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 1CRUrp-0000aB-3U; Tue, 09 Nov 2004 07:12:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUod-0008LU-6n for nemo@megatron.ietf.org; Tue, 09 Nov 2004 07:09:40 -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 HAA16844 for ; Tue, 9 Nov 2004 07:09:35 -0500 (EST) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRUpM-00013k-8r for nemo@ietf.org; Tue, 09 Nov 2004 07:10:25 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CDCE73018B; Tue, 9 Nov 2004 13:09:05 +0100 (CET) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 6DC76301F7; Tue, 9 Nov 2004 13:09:05 +0100 (CET) Subject: Re: [nemo] RO: what have we learnt so far? From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" , cwng@psl.com.sg In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC413C2A@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC413C2A@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LJ/pHCU/VFsBnpHx4utA" Organization: Universidad Carlos III de Madrid Message-Id: <1100002144.2453.58.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 09 Nov 2004 13:09:05 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 --=-LJ/pHCU/VFsBnpHx4utA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Dear Pascal, I've read the draft and I've some comments. First, thanks for the new version of the draft. I think that this new version is much better than the previous one and it's closer to the charter requirements. Here they are my comments (I also include some minor typos I've found): - Section 2.2. It says "effects of sub-optimal routing with NEMO Basic Support is amplified" I think it should be "effects of sub-optimal routing with NEMO Basic Support are amplified" - Section 2.4. The title is "Communications within a Mobile Networks". I think it should be "Communications within a Mobile Network" - Section 3.2. I'd remove any reference to a specific proposed solution in the text, like [10] or [11], as IMHO in this section you are describing the solution space, but without referring to any specific proposed solution. IMHO, the actual structure of the draft is fine, it first presents the problem space, then the solution space and finally, in the annex, proposed solutions are presented, mapped to the taxonomy presented in the solution space. - Section 3.2. It says "through dome". I think it should be "through some" - Section 3.3. I'd would add a bullet with solutions based on Ad-Hoc routing in the nested NEMO (e.g. something similar to the solution described in draft-clausen-nemo-ro-problem-statement-00.txt). IMHO, providing a globally reachable IPv6 address to every MR in the nested topology (to be used as MR's CoA) and then using an Ad-Hoc routing protocol to route the packets within the nested NEMO would be a possible solution to avoid the encapsulation due nesting. - Section 4.1.4. It says "In general, it is desirable to keep the number of nodes that require new functionalities to be kept as small as possible". I think it should be "In general, it is desirable to keep the number of nodes that require new functionalities as small as possible" And a last comment/question: you said in the mail, that MIRON reference is still missing... what do you mean? Because in your draft is reference [15] Kind Regards, Carlos J. El lun, 08-11-2004 a las 12:52, Pascal Thubert (pthubert) escribi=F3: > Hi: >=20 > As you know, the RO problem has been around since NEMO stated, and so > have been related drafts.=20 >=20 > As a group, we have focussed on delivering basic support, but still > people could not help working on RO. And we learnt quite a few things > overtime. >=20 > - We have distinguished various problems to be addressed, and > categorized the (tenths of) solutions that were proposed. We also have > clues about the specific pro/cons of those numerous solutions. >=20 > - We have found that before optimizing the tunnels and data path of a > nested tree of MRs, we should make sure that we build the tree and that > the tree is optimized in shape in the first place. We also know that a > MR might not want to attach anywhere and that some clues might be > needed. >=20 > We can not just make as if we were 3 years ago, can we? I believe that > we can and we should give more food for thought then just "what's the > problem here?". >=20 > This is why the taxonomy is now built in 3 major parts, plus appendix. > The problem statement is obviously the 1st of the 3 major parts. The > bestiary of the solutions types comes next, and finally the pro/cons. > The specific solutions are introduced only in appendix. Some refs are > still missing (like MIRON, sorry), but then again, it's a work in > progress. >=20 > Pascal --=20 Carlos Jes=FAs Bernardos Cano - http://www.netcoms.net GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-LJ/pHCU/VFsBnpHx4utA 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) iD8DBQBBkLNf5vKyPtrWqkARAtkmAJ9pZf+sdBEAY+17t1pmWhJpjHJoRgCgrrWM LPIMiewcJbG1zOiaKw9tRiQ= =7b8u -----END PGP SIGNATURE----- --=-LJ/pHCU/VFsBnpHx4utA-- From nemo-bounces@ietf.org Tue Nov 9 09:28:06 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 JAA01532 for ; Tue, 9 Nov 2004 09:28:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWvT-0004fI-Mq; Tue, 09 Nov 2004 09:24:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWjV-00026S-OF for nemo@megatron.ietf.org; Tue, 09 Nov 2004 09:12:29 -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 JAA29750 for ; Tue, 9 Nov 2004 09:12:27 -0500 (EST) Received: from [130.129.132.111] (helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWkC-0004WW-Rj for nemo@ietf.org; Tue, 09 Nov 2004 09:13:16 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 650A38004F for ; Tue, 9 Nov 2004 22:26:11 +0800 (SGT) From: Chan-Wah NG To: IETF NEMO WG Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1100010370.9642.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 09 Nov 2004 22:26:11 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [nemo] Multihoming Issues To be Presented Wednesday 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, During the Multihoming slot on Wednesday afternoon, we will be polling the room to check what are the problems listed in the draft that the WG feels should be worked on, either by some other WG, or by the NEMO WG if the problem is is directly related to the NEMO Charter. So, it would be much more productive if folks would come prepared (that is, read the draft, esp section 4). Thanks, /rgds /cwng From nemo-bounces@ietf.org Tue Nov 9 09:34:10 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 JAA02080 for ; Tue, 9 Nov 2004 09:34: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 1CRWxU-0006dZ-52; Tue, 09 Nov 2004 09:26:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWvC-0004Zh-NF for nemo@megatron.ietf.org; Tue, 09 Nov 2004 09:24: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 JAA01200 for ; Tue, 9 Nov 2004 09:24:32 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWvu-0004rG-2s for nemo@ietf.org; Tue, 09 Nov 2004 09:25:21 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2004 15:45:05 +0100 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 iA9EN7vf005188; Tue, 9 Nov 2004 15:23:33 +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.0); Tue, 9 Nov 2004 15:23:04 +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] RO: what have we learnt so far? Date: Tue, 9 Nov 2004 15:22:49 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC414175@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO: what have we learnt so far? Thread-Index: AcTGVO3QYsgDlqBoSKGSwUTnq1fx5wAD8DVQ From: "Pascal Thubert \(pthubert\)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , X-OriginalArrivalTime: 09 Nov 2004 14:23:04.0922 (UTC) FILETIME=[A075C3A0:01C4C667] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable 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 Hi Carlos :) Thanks a lot for this review. Chan-Wah and I discussed quite a bit on = the light of other Pb Statement drafts and we agree that the MANET based = approach did not get a fair treatment in ours. We need to improve on = that, maybe comparing with LMM based approaches, which provide quite = similar results - the "flatten" the nested tree from the standpoint of = the outside. For LMM based (say DHCPv6PD+NEMO), you need a LMM enabled node close the = AR. This would have to be deployed pervasively, on the Access Provider = side. But there's no need for a new standard to deploy on the MR side = since both PD and NEMO are used as is. The only addition that could be = needed is about locating the LMM box. OTOH, for MANET based, the difficulty is opposite: you need all nodes to = agree on a given MANET, one that can transport prefixes and provides a = solution for the default route; but a gateway might or might not be = needed on the Access Provider side, hopefully not. As a result, we see that the adoption of one approach vs. the other = could depend on the deployment. For a vertical, it could be doable to = force a same MANET in all boxes. For a consumer service, it could be = easier that the SP deploys LMM boxes around. Comments anybody? BTW, yes, we have a ref on MIRON and other drafts but we lacked some = naming them at the right place in the appendix. Next version will be = better. Hopefully we'll have some experience from you in there as well = :) Pascal > -----Original Message----- > From: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Sent: mardi 9 novembre 2004 13:09 > To: Pascal Thubert (pthubert); cwng@psl.com.sg > Cc: IETF NEMO WG > Subject: Re: [nemo] RO: what have we learnt so far? >=20 > Dear Pascal, >=20 > I've read the draft and I've some comments. >=20 > First, thanks for the new version of the draft. I think that this new > version is much better than the previous one and it's closer to the > charter requirements. >=20 > Here they are my comments (I also include some minor typos I've = found): >=20 > - Section 2.2. It says "effects of sub-optimal routing with NEMO = Basic > Support is amplified" I think it should be "effects of > sub-optimal routing with NEMO Basic Support are amplified" > - Section 2.4. The title is "Communications within a Mobile = Networks". > I think it should be "Communications within a Mobile Network" > - Section 3.2. I'd remove any reference to a specific proposed = solution > in the text, like [10] or [11], as IMHO in this section you are > describing the solution space, but without referring to any specific > proposed solution. IMHO, the actual structure of the draft is fine, it > first presents the problem space, then the solution space and finally, > in the annex, proposed solutions are presented, mapped to the taxonomy > presented in the solution space. > - Section 3.2. It says "through dome". I think it should be "through > some" > - Section 3.3. I'd would add a bullet with solutions based on Ad-Hoc > routing in the nested NEMO (e.g. something similar to the solution > described in draft-clausen-nemo-ro-problem-statement-00.txt). IMHO, > providing a globally reachable IPv6 address to every MR in the nested > topology (to be used as MR's CoA) and then using an Ad-Hoc routing > protocol to route the packets within the nested NEMO would be a = possible > solution to avoid the encapsulation due nesting. > - Section 4.1.4. It says "In general, it is desirable to keep the > number of nodes that require new functionalities to be kept as small = as > possible". I think it should be "In general, it is desirable to keep = the > number of nodes that require new functionalities as small as possible" >=20 > And a last comment/question: you said in the mail, that MIRON = reference > is still missing... what do you mean? Because in your draft is = reference > [15] >=20 > Kind Regards, >=20 > Carlos J. >=20 > El lun, 08-11-2004 a las 12:52, Pascal Thubert (pthubert) escribi=F3: > > Hi: > > > > As you know, the RO problem has been around since NEMO stated, and = so > > have been related drafts. > > > > As a group, we have focussed on delivering basic support, but still > > people could not help working on RO. And we learnt quite a few = things > > overtime. > > > > - We have distinguished various problems to be addressed, and > > categorized the (tenths of) solutions that were proposed. We also = have > > clues about the specific pro/cons of those numerous solutions. > > > > - We have found that before optimizing the tunnels and data path of = a > > nested tree of MRs, we should make sure that we build the tree and = that > > the tree is optimized in shape in the first place. We also know that = a > > MR might not want to attach anywhere and that some clues might be > > needed. > > > > We can not just make as if we were 3 years ago, can we? I believe = that > > we can and we should give more food for thought then just "what's = the > > problem here?". > > > > This is why the taxonomy is now built in 3 major parts, plus = appendix. > > The problem statement is obviously the 1st of the 3 major parts. The > > bestiary of the solutions types comes next, and finally the = pro/cons. > > The specific solutions are introduced only in appendix. Some refs = are > > still missing (like MIRON, sorry), but then again, it's a work in > > progress. > > > > Pascal > -- > Carlos Jes=FAs Bernardos Cano - http://www.netcoms.net > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 From nemo-bounces@ietf.org Tue Nov 9 13:43:25 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 NAA28941 for ; Tue, 9 Nov 2004 13:43:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRapX-0000Ci-EG; Tue, 09 Nov 2004 13:34:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRaoL-0008Ka-9r for nemo@megatron.ietf.org; Tue, 09 Nov 2004 13:33: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 NAA28024 for ; Tue, 9 Nov 2004 13:33:41 -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 1CRap8-0002ur-Lc for nemo@ietf.org; Tue, 09 Nov 2004 13:34:35 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id A85C6625B; Tue, 9 Nov 2004 10:33:03 -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 38966-08; Tue, 9 Nov 2004 10:33:02 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id BB504624E; Tue, 9 Nov 2004 10:33:02 -0800 (PST) Received: from [130.129.67.39] (unknown [130.129.67.39]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 319BC6232; Tue, 9 Nov 2004 10:32:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Date: Tue, 9 Nov 2004 13:33:02 -0500 To: IETF NEMO WG X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: "Pascal Thubert \(pthubert\)" , Vijay Devarapalli , Alexandru Petrescu , Ryuji Wakikawa , Margaret Wasserman , Thierry Ernst , Erik Nordmark Subject: [nemo] How to proceed with edits after IESG approval 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 To the NEMO WG, Between the time the NEMO Basic Support draft was considered "ready for RFC" (by the working group, IETF general community, and IESG), and now (when it has not yet been published as an RFC), there has been a number of good changes, improvements, and corrections proposed. Some of them came this summer, and have been discussed for a while on the WG mailing list and at the last IETF. Others were brought up more recently, after the document entered the RFC Editor's Queue and as various processes have progressed, such as IANA assignments, and have been discussed at shorter length on the mailing list. There are many valid topics listed in the Issues List; however, at this point the document is still proceeding through the RFC Editor's Queue, and the working group now has to decide how to handle these change while minimizing disruption. There is a wide spectrum here, ranging from complete rejection of all changes (hopefully deferring them until a later revision) at one extreme, to making the draft perfect by including any changes that would improve the document, in effect yanking it from the queue, at the other. As WG chairs, we have to strike a balance for change control so that on one hand, critical problems can still be addressed so the WG does not publish something it will later regret, and on the other hand that the process doesn't cyclically extend to infinity. We have met with the document authors and AD to discuss this, and we have been instructed that the AUTH48 process (i.e. the only remaining chance to affect the text of the eventual RFC) is intended to make typographical fixes, updates to contact info, etc., and is not intended as a general editing phase. We are to err on the side of conservatism. Remember, this is the first draft of the RFC and will not be 100.0000% perfect. To reach the best conclusion, we are asking the document authors to classify the list of changes according to severity/impact and what can/should be addressed at this point, deferring the rest of the changes for the revision (-bis) process which many RFCs go through. There will be more info presented at the meeting tomorrow. Thanks, -TJ & Thierry From nemo-bounces@ietf.org Tue Nov 9 14:06: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 OAA01749 for ; Tue, 9 Nov 2004 14:06: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 1CRbEm-0005vq-W6; Tue, 09 Nov 2004 14:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRb8n-0004ja-Da for nemo@megatron.ietf.org; Tue, 09 Nov 2004 13:54:53 -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 NAA00242 for ; Tue, 9 Nov 2004 13:54:51 -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 1CRb9a-0003Tv-5i for nemo@ietf.org; Tue, 09 Nov 2004 13:55:43 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 94E4F6220 for ; Tue, 9 Nov 2004 10:54:19 -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 39218-09 for ; Tue, 9 Nov 2004 10:54:18 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id AD49461B6; Tue, 9 Nov 2004 10:54:18 -0800 (PST) Received: from [130.129.67.39] (unknown [130.129.67.39]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 17FC860F5 for ; Tue, 9 Nov 2004 10:54:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF NEMO WG From: "T.J.Kniveton" Date: Tue, 9 Nov 2004 13:54:18 -0500 X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [nemo] Minute takers for the meeting 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 Can someone please volunteer to take minutes and/or jabber notes for the NEMO meeting tomorrow? It will speed up the beginning of the meeting, since we need this before we can start. The notes don't have to be perfect, but if we can get a couple of people to volunteer now, you would get some good karma points. TJ From nemo-bounces@ietf.org Tue Nov 9 14:39:29 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 OAA04465 for ; Tue, 9 Nov 2004 14:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbn7-0003WF-9n; Tue, 09 Nov 2004 14:36:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbkG-00039w-4l for nemo@megatron.ietf.org; Tue, 09 Nov 2004 14:33:36 -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 OAA04071 for ; Tue, 9 Nov 2004 14:33:34 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbl3-0004Pb-10 for nemo@ietf.org; Tue, 09 Nov 2004 14:34:26 -0500 Received: from iseran.local (unknown [130.129.132.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D3AA84C091 for ; Wed, 10 Nov 2004 04:32:57 +0900 (JST) Date: Wed, 10 Nov 2004 04:35:40 +0900 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20041110043540.5540ffb8.ernst@sfc.wide.ad.jp> 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: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Subject: [nemo] Final Agenda for NEMO Meeting 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, This is the final agenda for tomorrow meeting. Please find inline all the documents that you should read/know about, including Issues Lists and IPRs. NEMO chairs, TJ and Thierry. # NEMO WG Wed 13:00-15:00, 61th IETF Meeting San Francisco, November 2004 # http://www.ietf.org/html.charters/nemo-charter.html # FINAL NEMO WG Agenda, as of Nov.08 2004, 2pm # The up-to-date version of this agenda will be posted on # http://www.mobilenetworks.org/nemo/ietf61/nemo-ietf61-agenda.txt # All NEMO WG related drafts can be found on http://www.mobilenetworks.org/nemo 1. Agenda, welcoming, etc .................................................... 05mins Chairs 2. NEMO WG Status............................................................. 05mins Chairs Terminology and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-02.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-03.txt Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo NEMO Home Network Model http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-01.txt IPRs on NEMO Basic Support CISCO new statemant: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=497 CISCO old statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=135 NOKIA statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=136 3. NEMO Basic Support (draft status).......................................... 20mins Vijay Devarapalli http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html 4 NEMO MIB Design ........................................................... 05mins Sri Gundavelli "NEMO Management Information Base" http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt 5. Announcement: 6th TAHI interop test event ................................. 05mins Yukiyo Akisada 6. Prefix Delegation ......................................................... 10mins TJ Kniveton http://www.ietf.org/internet-drafts/draft-kniveton-nemo-prefix-delegation-00.txt 7. NEMO Multihoming Issues ................................................... 25mins "Analysis of Multihoming in Network Mobility Support" http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-01.txt Draft Issues: http://www.mobilenetworks/org/nemo/draft-ietf-nemo-multihoming-issues ChanWah Ng (10mins) Discussion (5mins) "Global HAHA" http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.txt http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-spec-00.txt http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-01.txt Pascal Thubert (10mins) 8. NEMO RO Problem Statement ................................................. 30mins "NEMO Route Optimization Problem Statement" http://www.ietf.org/internet-drafts/draft-clausen-nemo-ro-problem-statement-00.txt Thomas Clausen / Ryuji Wakikawa "NEMO RO Pb Statement, Requirements and Evaluation Considerations" http://www.ietf.org/internet-drafts/draft-zhao-nemo-ro-ps-00.txt Fan Zhao "RO with Nested CNs" http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt Masafumi Watari / Thierry Ernst Update of "Taxonomy of RO models in the NEMO context" http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-03.txt Pascal Thubert / ChanWah NG 9. Securing Prefix in Binding Updates ........................................ 05mins ChanWah NG "Extending Return Routability Procedure for Network Prefix (RRNP)" http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt 10. Conclusions and Next Steps ................................................ 10mins From nemo-bounces@ietf.org Tue Nov 9 14:59:54 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 OAA06038 for ; Tue, 9 Nov 2004 14:59:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbwE-00054Q-1O; Tue, 09 Nov 2004 14:45:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbvJ-0004tN-Jr for nemo@megatron.ietf.org; Tue, 09 Nov 2004 14:45: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 OAA04851 for ; Tue, 9 Nov 2004 14:44:59 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbw4-0004dN-Ms for nemo@ietf.org; Tue, 09 Nov 2004 14:45:52 -0500 Received: from jurassic.eng.sun.com ([129.146.83.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iA9Jiu7q006659; Tue, 9 Nov 2004 11:44:56 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA9JitTU213494; Tue, 9 Nov 2004 11:44:55 -0800 (PST) Message-ID: <41911E6B.4060302@sun.com> Date: Tue, 09 Nov 2004 11:45:47 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday References: <1100010370.9642.6.camel@localhost> In-Reply-To: <1100010370.9642.6.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Chan-Wah NG wrote: > Hello All, > > During the Multihoming slot on Wednesday afternoon, we will be polling > the room to check what are the problems listed in the draft that the WG > feels should be worked on, either by some other WG, or by the NEMO WG if > the problem is is directly related to the NEMO Charter. I'd be curious what folks think is the relationship between Nemo specific multihoming and the work being done in the MULTI6 WG. It seems like the latter would could be layered on top of Nemo basic support and provide e2e redundant paths. Erik From nemo-bounces@ietf.org Tue Nov 9 15:31: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 PAA10154 for ; Tue, 9 Nov 2004 15:31: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 1CRcZk-0001Jm-H7; Tue, 09 Nov 2004 15:26:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcQx-0003gk-On for nemo@megatron.ietf.org; Tue, 09 Nov 2004 15:17: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 PAA08604 for ; Tue, 9 Nov 2004 15:17:41 -0500 (EST) Message-Id: <200411092017.PAA08604@ietf.org> Received: from hdflem01.fl.hostdepot.net ([66.242.128.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRcRb-0005QG-4A for nemo@ietf.org; Tue, 09 Nov 2004 15:18:34 -0500 Received: from vaio (unverified [24.7.189.114]) by hdflem01.fl.hostdepot.net (Vircom SMTPRS 3.2.315.0) with ESMTP id ; Tue, 9 Nov 2004 15:16:28 -0500 From: "Dr Harsh Verma" To: "'Thierry Ernst'" , Subject: RE: [nemo] Final Agenda for NEMO Meeting Date: Tue, 9 Nov 2004 12:16:43 -0800 Organization: Glocol MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.5207 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcTGk7wCLIIdhAAqTkK6Gwu+71GNsgAAooMA In-Reply-To: <20041110043540.5540ffb8.ernst@sfc.wide.ad.jp> X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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 I guess, in the Agenda you want to replace: 61th IETF Meeting San Francisco, November 2004... I believe it is at Washington DC.. Harsh Verma Director, R&D Glocol Inc California -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst Sent: Tuesday, November 09, 2004 11:36 AM To: nemo@ietf.org Subject: [nemo] Final Agenda for NEMO Meeting Dear all, This is the final agenda for tomorrow meeting. Please find inline all the documents that you should read/know about, including Issues Lists and IPRs. NEMO chairs, TJ and Thierry. # NEMO WG Wed 13:00-15:00, 61th IETF Meeting San Francisco, November 2004 # http://www.ietf.org/html.charters/nemo-charter.html # FINAL NEMO WG Agenda, as of Nov.08 2004, 2pm # The up-to-date version of this agenda will be posted on # http://www.mobilenetworks.org/nemo/ietf61/nemo-ietf61-agenda.txt # All NEMO WG related drafts can be found on http://www.mobilenetworks.org/nemo 1. Agenda, welcoming, etc .................................................... 05mins Chairs 2. NEMO WG Status............................................................. 05mins Chairs Terminology and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-02.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-03.txt Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo NEMO Home Network Model http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-01.t xt IPRs on NEMO Basic Support CISCO new statemant: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=497 CISCO old statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=135 NOKIA statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=136 3. NEMO Basic Support (draft status).......................................... 20mins Vijay Devarapalli http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html 4 NEMO MIB Design ........................................................... 05mins Sri Gundavelli "NEMO Management Information Base" http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt 5. Announcement: 6th TAHI interop test event ................................. 05mins Yukiyo Akisada 6. Prefix Delegation ......................................................... 10mins TJ Kniveton http://www.ietf.org/internet-drafts/draft-kniveton-nemo-prefix-delegation-00 .txt 7. NEMO Multihoming Issues ................................................... 25mins "Analysis of Multihoming in Network Mobility Support" http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-01.tx t Draft Issues: http://www.mobilenetworks/org/nemo/draft-ietf-nemo-multihoming-issues ChanWah Ng (10mins) Discussion (5mins) "Global HAHA" http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.txt http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-spec-00.tx t http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-01.txt Pascal Thubert (10mins) 8. NEMO RO Problem Statement ................................................. 30mins "NEMO Route Optimization Problem Statement" http://www.ietf.org/internet-drafts/draft-clausen-nemo-ro-problem-statement- 00.txt Thomas Clausen / Ryuji Wakikawa "NEMO RO Pb Statement, Requirements and Evaluation Considerations" http://www.ietf.org/internet-drafts/draft-zhao-nemo-ro-ps-00.txt Fan Zhao "RO with Nested CNs" http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt Masafumi Watari / Thierry Ernst Update of "Taxonomy of RO models in the NEMO context" http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-03.txt Pascal Thubert / ChanWah NG 9. Securing Prefix in Binding Updates ........................................ 05mins ChanWah NG "Extending Return Routability Procedure for Network Prefix (RRNP)" http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt 10. Conclusions and Next Steps ................................................ 10mins From nemo-bounces@ietf.org Tue Nov 9 15:33:43 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 PAA10280 for ; Tue, 9 Nov 2004 15:33: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 1CRcZm-0001Lh-AG; Tue, 09 Nov 2004 15:26:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcSc-0004RZ-M1 for nemo@megatron.ietf.org; Tue, 09 Nov 2004 15:19: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 PAA08782 for ; Tue, 9 Nov 2004 15:19:23 -0500 (EST) Message-Id: <200411092019.PAA08782@ietf.org> Received: from hdflem01.fl.hostdepot.net ([66.242.128.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRcTO-0005S0-RN for nemo@ietf.org; Tue, 09 Nov 2004 15:20:15 -0500 Received: from vaio (unverified [24.7.189.114]) by hdflem01.fl.hostdepot.net (Vircom SMTPRS 3.2.315.0) with ESMTP id ; Tue, 9 Nov 2004 15:18:35 -0500 From: "Dr Harsh Verma" To: "'Dr Harsh Verma'" , "'Thierry Ernst'" , Subject: RE: [nemo] Final Agenda for NEMO Meeting Date: Tue, 9 Nov 2004 12:18:51 -0800 Organization: Glocol MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.5207 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcTGk7wCLIIdhAAqTkK6Gwu+71GNsgAAooMAAAC0fsA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 I guess, in the Agenda you want to replace: San Francisco by Washington DC .. :-) Harsh Verma -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst Sent: Tuesday, November 09, 2004 11:36 AM To: nemo@ietf.org Subject: [nemo] Final Agenda for NEMO Meeting Dear all, This is the final agenda for tomorrow meeting. Please find inline all the documents that you should read/know about, including Issues Lists and IPRs. NEMO chairs, TJ and Thierry. # NEMO WG Wed 13:00-15:00, 61th IETF Meeting San Francisco, November 2004 # http://www.ietf.org/html.charters/nemo-charter.html # FINAL NEMO WG Agenda, as of Nov.08 2004, 2pm # The up-to-date version of this agenda will be posted on # http://www.mobilenetworks.org/nemo/ietf61/nemo-ietf61-agenda.txt # All NEMO WG related drafts can be found on http://www.mobilenetworks.org/nemo 1. Agenda, welcoming, etc .................................................... 05mins Chairs 2. NEMO WG Status............................................................. 05mins Chairs Terminology and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-02.txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-03.txt Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo NEMO Home Network Model http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-01.t xt IPRs on NEMO Basic Support CISCO new statemant: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=497 CISCO old statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=135 NOKIA statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=136 3. NEMO Basic Support (draft status).......................................... 20mins Vijay Devarapalli http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-03.txt Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html 4 NEMO MIB Design ........................................................... 05mins Sri Gundavelli "NEMO Management Information Base" http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt 5. Announcement: 6th TAHI interop test event ................................. 05mins Yukiyo Akisada 6. Prefix Delegation ......................................................... 10mins TJ Kniveton http://www.ietf.org/internet-drafts/draft-kniveton-nemo-prefix-delegation-00 .txt 7. NEMO Multihoming Issues ................................................... 25mins "Analysis of Multihoming in Network Mobility Support" http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-01.tx t Draft Issues: http://www.mobilenetworks/org/nemo/draft-ietf-nemo-multihoming-issues ChanWah Ng (10mins) Discussion (5mins) "Global HAHA" http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.txt http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-spec-00.tx t http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-01.txt Pascal Thubert (10mins) 8. NEMO RO Problem Statement ................................................. 30mins "NEMO Route Optimization Problem Statement" http://www.ietf.org/internet-drafts/draft-clausen-nemo-ro-problem-statement- 00.txt Thomas Clausen / Ryuji Wakikawa "NEMO RO Pb Statement, Requirements and Evaluation Considerations" http://www.ietf.org/internet-drafts/draft-zhao-nemo-ro-ps-00.txt Fan Zhao "RO with Nested CNs" http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt Masafumi Watari / Thierry Ernst Update of "Taxonomy of RO models in the NEMO context" http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-03.txt Pascal Thubert / ChanWah NG 9. Securing Prefix in Binding Updates ........................................ 05mins ChanWah NG "Extending Return Routability Procedure for Network Prefix (RRNP)" http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-00.txt 10. Conclusions and Next Steps ................................................ 10mins From nemo-bounces@ietf.org Tue Nov 9 18:18: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 SAA26479 for ; Tue, 9 Nov 2004 18:18: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 1CRfEa-0006YP-4H; Tue, 09 Nov 2004 18:17:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRf9H-000468-WC for nemo@megatron.ietf.org; Tue, 09 Nov 2004 18:11:40 -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 SAA25507 for ; Tue, 9 Nov 2004 18:11:36 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRfA7-0001IQ-QW for nemo@ietf.org; Tue, 09 Nov 2004 18:12:32 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iA9ND6nQ003294; Tue, 9 Nov 2004 16:13:06 -0700 (MST) Received: from [10.182.46.16] (mvp-10-182-46-16.am.mot.com [10.182.46.16]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id iA9NBYYj017355; Tue, 9 Nov 2004 17:11:35 -0600 Message-ID: <41914EA0.20008@motorola.com> Date: Wed, 10 Nov 2004 00:11:28 +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: Thierry Ernst Subject: Re: [nemo] NEMO Basic Support IPR from CISCO References: <20041104112957.3028dbac.ernst@sfc.wide.ad.jp> In-Reply-To: <20041104112957.3028dbac.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090807030006050208050405" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 This is a cryptographically signed message in MIME format. --------------ms090807030006050208050405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > CISCO statement on NEMO Basic Support has changed. Thanks Thierry and Cisco affiliates who made this change possible. In the mean time, the NEMO BAsic Support draft has also changed a lot. It includes more and more specific language on using dynamic routing protocol with NEMO. These modifs were introduced mainly as remarks from IESG and WG members not affiliated with Cisco. So, my question is, does the Cisco statement cover these changes too? Additionally, it is also good to know whether the related Nokia NEMO IPR covers this. The reason I am asking is to figure out whether it is worth working on having a dynamic routing protocol with NEMO, i.e. without infringing IPR. Alex --------------ms090807030006050208050405 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 GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEx MDkyMzExMjhaMCMGCSqGSIb3DQEJBDEWBBSZ2L/dWkNUkbBJKhJmS7b+mrTHKTBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYC1bmjyR/3JUiT3R4o/AsEgBjyQggAMe1pcl0ix m0gRFkHiYxiQo0jzF7jKrFhpI9BI8xJTxpwBKm4nMxekZ+hlgO1cJSeYlcJO75dTiOpAvi4t 78Q/mYLvJAHWzrlwsF9RE+Wr0iGC87nG6fxDUQEZeHFhKRfNIWJA7wv8WkyUjgAAAAAAAA== --------------ms090807030006050208050405-- From nemo-bounces@ietf.org Tue Nov 9 18:28:22 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 SAA27510 for ; Tue, 9 Nov 2004 18:28: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 1CRfMG-0000Ua-Sc; Tue, 09 Nov 2004 18:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRfGb-0007OJ-4q for nemo@megatron.ietf.org; Tue, 09 Nov 2004 18:19: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 SAA26549 for ; Tue, 9 Nov 2004 18:19:10 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRfHR-0001Sv-Bj for nemo@ietf.org; Tue, 09 Nov 2004 18:20:05 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iA9NKfnQ008940 for ; Tue, 9 Nov 2004 16:20:41 -0700 (MST) Received: from [10.182.46.16] (mvp-10-182-46-16.am.mot.com [10.182.46.16]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id iA9NJAYj025342 for ; Tue, 9 Nov 2004 17:19:10 -0600 Message-ID: <41915068.5040709@motorola.com> Date: Wed, 10 Nov 2004 00:19:04 +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: 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="------------enigC187A7E28DEB642C686AF48E" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [nemo] regarding IPR on draft-ng-nemo-rrnp-00.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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC187A7E28DEB642C686AF48E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Informally speaking, there may be IPR related draft-ng-nemo-rrnp-00.txt, IPR whose co-author I am. I do not know about authors of the draft itself and I did not participate in writing this particular draft. The reason I'm writing this is because this kind of information should be one of the essential criteria when WG chooses how to work on a WG item (in addition - and after - the considerations on feasibility, Internet stability, Security, in this relative order). Alex --------------enigC187A7E28DEB642C686AF48E 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 iD8DBQFBkVBtMmC0w56zj54RAq0aAJ4rPyBjJ/HUmHf51Ip2XGbW6ue/9wCfV+Bj AWdEo/L+lfnpIgker53CAvk= =dbAZ -----END PGP SIGNATURE----- --------------enigC187A7E28DEB642C686AF48E-- From nemo-bounces@ietf.org Tue Nov 9 18:48:16 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 SAA29671 for ; Tue, 9 Nov 2004 18:48:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRfde-0004SP-M1; Tue, 09 Nov 2004 18:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRfbo-0004DK-0i for nemo@megatron.ietf.org; Tue, 09 Nov 2004 18:41: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 SAA29091 for ; Tue, 9 Nov 2004 18:41:04 -0500 (EST) Received: from s-utl01-dcpop.stsn.com ([63.240.218.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CRfce-0001y4-B4 for nemo@ietf.org; Tue, 09 Nov 2004 18:42:00 -0500 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110918405608336 for ; Tue, 09 Nov 2004 18:40:56 -0500 Received: from [10.67.87.203] ([10.67.87.203]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Nov 2004 18:40:56 -0500 In-Reply-To: <41915068.5040709@motorola.com> References: <41915068.5040709@motorola.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] regarding IPR on draft-ng-nemo-rrnp-00.txt Date: Tue, 9 Nov 2004 18:40:51 -0500 To: Alexandru Petrescu X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 09 Nov 2004 23:40:56.0844 (UTC) FILETIME=[8F47BCC0:01C4C6B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Please see this RFC: http://www.ietf.org/rfc/rfc3668.txt Especially, section 6.1 TJ On Nov 9, 2004, at 6:19 PM, Alexandru Petrescu wrote: > Informally speaking, there may be IPR related > draft-ng-nemo-rrnp-00.txt, > IPR whose co-author I am. I do not know about authors of the draft > itself and I did not participate in writing this particular draft. > > The reason I'm writing this is because this kind of information should > be one of the essential criteria when WG chooses how to work on a WG > item (in addition - and after - the considerations on feasibility, > Internet stability, Security, in this relative order). > > Alex > From nemo-bounces@ietf.org Tue Nov 9 23:14:18 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 XAA20234 for ; Tue, 9 Nov 2004 23:14: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 1CRjqd-0005wg-Vs; Tue, 09 Nov 2004 23:12:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRjok-0005cl-EX for nemo@megatron.ietf.org; Tue, 09 Nov 2004 23:10:47 -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 XAA19717 for ; Tue, 9 Nov 2004 23:10:17 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRjpA-0007AE-09 for nemo@ietf.org; Tue, 09 Nov 2004 23:11:15 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAA4BfnQ014744; Tue, 9 Nov 2004 21:11:41 -0700 (MST) Received: from [10.182.47.41] (mvp-10-182-47-41.am.mot.com [10.182.47.41]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id iAA48uFG002834; Tue, 9 Nov 2004 22:08:57 -0600 Message-ID: <419194A0.3020701@motorola.com> Date: Wed, 10 Nov 2004 05:10:08 +0100 From: Christophe Janneteau User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday References: <1100010370.9642.6.camel@localhost> In-Reply-To: <1100010370.9642.6.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 Hi Chan-Wah, and co-authors, Thanks for the updated draft-ietf-nemo-multihoming-issues-01.txt. I find the classification useful. Here are some comments: In section 2.1 (1,1,1): Single MR, Single HA, Single MNP --------------------------------------------------------- The terminology draft (5.2) defines a multihomed MR as: "a router is multihomed when it has several IPv6 addresses to choose between, i.e. in the following cases when the MR is either: multi-prefixed: multiple prefixes are advertised on the link(s) a MR's egress interface is attached to, or. multi-interfaced: the MR has multiple egress interfaces to choose between, on the same link or not." While section 2 of multihoming draft defines a multihomed MR as: "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, or (iii) the MR is equipped with multiple interfaces. In such a case, the MR would have a combination of Home Address / Care-of Address pairs." ==> The two defition differs. There may be a need to update the terminology draft to cover (i) as well. In addition 2.1 reads: "A bi-directional tunnel may be established between each pair of Home Address / Care-of address if the MR is itself multihomed." This sentence is confusing in the case multiple prefixes are advertised on the visited link but only one is advertised on the home link. Indeed: - MR would be multihomed according to the definition, and has multiple CoAs, but - only 1 tunnel can be established at a time, between the unique HoA and the selected CoA; because NEMO/MIP does not allow multiple CoAs to be associated with a same HoA AFAIK. ==> Sentence could be replaced with "A bi-directional tunnel may be established for each Home Address of the MR if multiple prefixes are advertised one the MR's home link." In 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP -------------------------------------------------------- " No assumptions are made on whether or not the HAs belongs to the same administrative domain. However, the MRs advertises the same MNP." ==> How can HAs from different administrative domains advertise routes to the same MNP? Seems to me that the only possible scenario is the one where all HAs are in the same domain. This is ackwonledged in 4.6 and 4.11 but there may be a need for a ref to these sections in 2.7, to avoid mislead the reader. In 3.1: -------- For case "z=N: Multihomed mobile networks with multiple MNPs": "Example: a car with a prefix taken from home (personal traffic transit on this prefix and is paid by the owner) and one that belongs to the car manufacturer (maintenance traffic is paid by the car-manufacturer). This will typically be a (1,1,n)." ==> In general I assume car manufacturer and personal ISP would be different administrative domains, hence with different HAs. So the example seems more like an (1,n,n) to me. In 4.7 MR Synchronization --------------------------- "In the (n,*,n) case, a MR relaying the advertisement of the MNP from another failed MR." ==> Do we really want that? Would it not be better to just let the addresses die? In 4.12 Nested Mobile Networks ------------------------------- "As such, a solution to prevent an infinite loop must be provided." ==> An infinite loop of what? Motivation is unclear IMHO. In A.1.2 Subscriber/Provider Model ------------------------------------- "For the S/mP model, the following configurations are likely to be deployed: o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single MNP" ==> Same comment as for 2.7: 4.6 and 4.11 highlight issues of such configurations, which makes them _not_ likely to be deployed IMHO. In A.2 Problem-Oriented Approach ---------------------------------- "o Shinkansen: Single MNP Advertised by MR(s) This is the case where one MNP is announced by different MRs. This is equivalent to the case of z=n, i.e. the (1,*,n) mobile network." ==> Should be (n,*,1), right? Christophe. Chan-Wah NG wrote: > Hello All, > > During the Multihoming slot on Wednesday afternoon, we will be polling > the room to check what are the problems listed in the draft that the WG > feels should be worked on, either by some other WG, or by the NEMO WG if > the problem is is directly related to the NEMO Charter. > > So, it would be much more productive if folks would come prepared (that > is, read the draft, esp section 4). > > Thanks, > > /rgds > /cwng > > > From nemo-bounces@ietf.org Wed Nov 10 00:59:19 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 AAA27670 for ; Wed, 10 Nov 2004 00:59: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 1CRlR1-0005Kb-7t; Wed, 10 Nov 2004 00:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRlPU-00058P-6x for nemo@megatron.ietf.org; Wed, 10 Nov 2004 00:52:48 -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 AAA27200 for ; Wed, 10 Nov 2004 00:52:44 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRlQN-0000oR-Nm for nemo@ietf.org; Wed, 10 Nov 2004 00:53:44 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAA5sEnQ008161; Tue, 9 Nov 2004 22:54:14 -0700 (MST) Received: from [10.182.47.137] (mvp-10-182-47-137.am.mot.com [10.182.47.137]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id iAA5pRFG029215; Tue, 9 Nov 2004 23:51:28 -0600 Message-ID: <4191ACA9.9060200@motorola.com> Date: Wed, 10 Nov 2004 06:52:41 +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" References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Vijay Devarapalli , Ryuji Wakikawa , Margaret Wasserman , Thierry Ernst , Erik Nordmark Subject: [nemo] Re: How to proceed with edits after IESG approval 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 T.J.Kniveton wrote: > As WG chairs, we have to strike a balance for change control so that on > one hand, critical problems can still be addressed so the WG does not > publish something it will later regret, and on the other hand that the > process doesn't cyclically extend to infinity. Let me add to this. We should also question whether we'd better like a short RFC with an easily countable number of issues or a bigger RFC with uncountable issues. Alex From nemo-bounces@ietf.org Wed Nov 10 07:32:47 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 HAA29861 for ; Wed, 10 Nov 2004 07:32:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRrbk-0000Rt-Kh; Wed, 10 Nov 2004 07:29:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRrbK-0000Mf-On for nemo@megatron.ietf.org; Wed, 10 Nov 2004 07:29: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 HAA29562 for ; Wed, 10 Nov 2004 07:29:25 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRrcG-0000Jn-TE for nemo@ietf.org; Wed, 10 Nov 2004 07:30:25 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 230F32E02E; Wed, 10 Nov 2004 13:28:50 +0100 (CET) Received: from [163.117.252.222] (vpn-252-222.uc3m.es [163.117.252.222]) by smtp02.uc3m.es (Postfix) with ESMTP id 0B7172E00F; Wed, 10 Nov 2004 13:28:49 +0100 (CET) In-Reply-To: <41911E6B.4060302@sun.com> References: <1100010370.9642.6.camel@localhost> <41911E6B.4060302@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday Date: Wed, 10 Nov 2004 13:28:49 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Chan-Wah NG 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 Erik, El 09/11/2004, a las 20:45, Erik Nordmark escribi=F3: > Chan-Wah NG wrote: >> Hello All, >> During the Multihoming slot on Wednesday afternoon, we will be = polling >> the room to check what are the problems listed in the draft that the=20= >> WG >> feels should be worked on, either by some other WG, or by the NEMO WG=20= >> if >> the problem is is directly related to the NEMO Charter. > > I'd be curious what folks think is the relationship between Nemo=20 > specific multihoming and the work being done in the MULTI6 WG. > It seems like the latter would could be layered on top of Nemo basic=20= > support and provide e2e redundant paths. > I guess that it depends on the partiuclar nemo multihoming scenario=20 that you are considering... I mean, in multi6 the basic assumption is that there are multiple=20 prefixes in the multihomed site and that those are related to one of=20 the exits. I guess that this is true for some of the cases of nemo multihoming but=20= not in other cases (for instance imagine a nemo with two MR and a=20 single HA, and a single prefix) So in the case where there are multiple prefixes available and this=20 prefixes belong to different HAs then, i guess that the multi6 solution=20= would do the trick, but in the other hand, if you have a single prefix=20= in the nemo, or when both HAs can route any of the available prefixes=20 (for instance they are both connected to the same HA) then i am not=20 sure multi6 protocol will be that useful I guess that there are two main reasosn for the differences between=20 multi6 and nemo multihoming i.e.: - the support for ubiquity (this is well stated in the draft BTW). i=20 mean in nemo multihoming, it is very likely that the direct link of the=20= nemo is the one that will fail (not becuase of a failure, but because=20 different media are available at different moments) so i guess that it=20= would make sense to optimize this particular case, and that there will=20= be configurations that mistly wnat to obtain this particular feature. - the need for policing is probably much more significant (Hesham=20 brought this up a long time ago AFAICT) if you have the typical example=20= of a GPRS and a WLAN connections, it is probably not the same to send=20 stuff on either one. Moreover, you probably don't want to fall back all=20= your communications to the WLAN if the GPRS connection fails (for=20 example) I guess that in the multi6 scenario it is not so common to see=20= such big differences in capacity and charging, so the stress in these=20 issues is probably very different I guess that the first step would be to identify the different nemo=20 multihoming scenarios and see which one of them are properly served=20 with a multi6 solution... regards, marcelo > Erik > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Wed Nov 10 11:46:39 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 LAA29314 for ; Wed, 10 Nov 2004 11:46:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvXu-0006Nr-Qx; Wed, 10 Nov 2004 11:42:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvQv-0004zO-8h for nemo@megatron.ietf.org; Wed, 10 Nov 2004 11:34: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 LAA28193 for ; Wed, 10 Nov 2004 11:34:54 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvRt-0006o0-Jr for nemo@ietf.org; Wed, 10 Nov 2004 11:35:59 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAAG6cX19741; Wed, 10 Nov 2004 08:06:38 -0800 X-mProtect: <200411101606> Nokia Silicon Valley Messaging Protection Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpd0p18sj; Wed, 10 Nov 2004 08:06:37 PST Message-ID: <41924301.2020502@iprg.nokia.com> Date: Wed, 10 Nov 2004 08:34:09 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: "T.J.Kniveton" , Ryuji Wakikawa , Alexandru Petrescu , Margaret Wasserman , Thierry Ernst , Erik Nordmark , "Pascal Thubert \(pthubert\)" Subject: [nemo] Proposed changes (was Re: How to proceed with edits after IESG approval) 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 T.J.Kniveton wrote: > To reach the best conclusion, we are asking the document authors to > classify the list of changes according to severity/impact and what > can/should be addressed at this point, deferring the rest of the changes > for the revision (-bis) process which many RFCs go through. There will > be more info presented at the meeting tomorrow. here are the changes classified into various categories. http://people.nokia.net/vijayd/nemo/changes.html let me know if there are any comments. Vijay From nemo-bounces@ietf.org Wed Nov 10 11:48:44 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 LAA29637 for ; Wed, 10 Nov 2004 11:48: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 1CRvY1-0006P1-Gh; Wed, 10 Nov 2004 11:42:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvRY-00055q-91 for nemo@megatron.ietf.org; Wed, 10 Nov 2004 11:35:36 -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 LAA28228 for ; Wed, 10 Nov 2004 11:35:33 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvSW-0006pJ-Kk for nemo@ietf.org; Wed, 10 Nov 2004 11:36:38 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAAG7HW20751; Wed, 10 Nov 2004 08:07:17 -0800 X-mProtect: <200411101607> Nokia Silicon Valley Messaging Protection Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpdCuMtiE; Wed, 10 Nov 2004 08:07:16 PST Message-ID: <41924329.3060605@iprg.nokia.com> Date: Wed, 10 Nov 2004 08:34:49 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "T.J.Kniveton" , Ryuji Wakikawa , Alexandru Petrescu , Margaret Wasserman , Thierry Ernst , Erik Nordmark , "Pascal Thubert \(pthubert\)" Subject: [nemo] Proposed changes (was Re: How to proceed with edits after IESG approval) 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 T.J.Kniveton wrote: > To reach the best conclusion, we are asking the document authors to > classify the list of changes according to severity/impact and what > can/should be addressed at this point, deferring the rest of the changes > for the revision (-bis) process which many RFCs go through. There will > be more info presented at the meeting tomorrow. here are the changes classified into various categories. http://people.nokia.net/vijayd/nemo/changes.html let me know if there are any comments. Vijay From nemo-bounces@ietf.org Wed Nov 10 20:51:19 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 UAA00282 for ; Wed, 10 Nov 2004 20:51: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 1CS45q-0004Qa-GI; Wed, 10 Nov 2004 20:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS42M-0003kV-Gk for nemo@megatron.ietf.org; Wed, 10 Nov 2004 20:46: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 UAA29771 for ; Wed, 10 Nov 2004 20:46:08 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS43Q-000501-L2 for nemo@ietf.org; Wed, 10 Nov 2004 20:47:17 -0500 Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAB1k67q026996; Wed, 10 Nov 2004 17:46:07 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAB1k57n413360; Wed, 10 Nov 2004 17:46:06 -0800 (PST) Message-ID: <4192C490.2040600@sun.com> Date: Wed, 10 Nov 2004 17:46:56 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday References: <1100010370.9642.6.camel@localhost> <41911E6B.4060302@sun.com> <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> In-Reply-To: <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Chan-Wah NG 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 marcelo bagnulo braun wrote: > I guess that it depends on the partiuclar nemo multihoming scenario that > you are considering... > > I mean, in multi6 the basic assumption is that there are multiple > prefixes in the multihomed site and that those are related to one of the > exits. Not necessarily "exits", but that there is some likelihood that some failures would affect the routing to one prefix but not the other. > I guess that this is true for some of the cases of nemo multihoming but > not in other cases (for instance imagine a nemo with two MR and a single > HA, and a single prefix) In that case you have limited diversity both between the CN and HA, and the MR and HA, since they all 1) need to get to a single HA and 2) the HA has only one address. > So in the case where there are multiple prefixes available and this > prefixes belong to different HAs then, i guess that the multi6 solution > would do the trick, but in the other hand, if you have a single prefix > in the nemo, or when both HAs can route any of the available prefixes > (for instance they are both connected to the same HA) then i am not sure > multi6 protocol will be that useful Yes, I understand one can make a reasonable case for HA-MR redundant paths using some MIP/Nemo specific technology. But that doesn't translate to applying the same mechanism to CN-MR redundant paths when Nemo RO is done; in that case I think one should just use Multi6. > I guess that there are two main reasosn for the differences between > multi6 and nemo multihoming i.e.: > - the support for ubiquity (this is well stated in the draft BTW). i > mean in nemo multihoming, it is very likely that the direct link of the > nemo is the one that will fail (not becuase of a failure, but because > different media are available at different moments) so i guess that it > would make sense to optimize this particular case, and that there will > be configurations that mistly wnat to obtain this particular feature. Yes, but when doing RO (to an unmodified MIPv6 CN) you would then loose that feature. Thus bidirectional tunneling will have better availability that a route optimized path. > - the need for policing is probably much more significant (Hesham > brought this up a long time ago AFAICT) if you have the typical example > of a GPRS and a WLAN connections, it is probably not the same to send > stuff on either one. Moreover, you probably don't want to fall back all > your communications to the WLAN if the GPRS connection fails (for > example) I guess that in the multi6 scenario it is not so common to see > such big differences in capacity and charging, so the stress in these > issues is probably very different And how is this Nemo specific? With a vanilla IPv4 laptop with WLAN+GPRS I have exactly the same issue. > I guess that the first step would be to identify the different nemo > multihoming scenarios and see which one of them are properly served with > a multi6 solution... That would make sense. Thanks, Erik From nemo-bounces@ietf.org Wed Nov 10 21:35:50 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 VAA03433 for ; Wed, 10 Nov 2004 21:35: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 1CS4fj-0003Vv-AB; Wed, 10 Nov 2004 21:26:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4Zb-0002Tt-Br for nemo@megatron.ietf.org; Wed, 10 Nov 2004 21:20:31 -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 VAA02274 for ; Wed, 10 Nov 2004 21:20:29 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4af-0005eU-5m for nemo@ietf.org; Wed, 10 Nov 2004 21:21:38 -0500 Received: from iseran.local (unknown [130.129.132.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6911C4C0A9; Thu, 11 Nov 2004 11:19:50 +0900 (JST) Date: Thu, 11 Nov 2004 11:22:33 +0900 From: Thierry Ernst To: Christophe Janneteau Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday Message-Id: <20041111112233.039e7d5d.ernst@sfc.wide.ad.jp> In-Reply-To: <419194A0.3020701@motorola.com> References: <1100010370.9642.6.camel@localhost> <419194A0.3020701@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: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, cwng@psl.com.sg 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 Thanks Christophe, I will fix that and make the drafts consistent. Thierry. On Wed, 10 Nov 2004 05:10:08 +0100 Christophe Janneteau wrote: > Hi Chan-Wah, and co-authors, > > Thanks for the updated draft-ietf-nemo-multihoming-issues-01.txt. I find > the classification useful. Here are some comments: > > In section 2.1 (1,1,1): Single MR, Single HA, Single MNP > --------------------------------------------------------- > > The terminology draft (5.2) defines a multihomed MR as: > > "a router is > multihomed when it has several IPv6 addresses to choose between, i.e. > in the following cases when the MR is either: > > multi-prefixed: multiple prefixes are advertised on the link(s) a > MR's egress interface is attached to, or. > > multi-interfaced: the MR has multiple egress interfaces to choose > between, on the same link or not." > > While section 2 of multihoming draft defines a multihomed MR as: > > "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, or (iii) the MR is equipped with > multiple interfaces. In such a case, the MR would have a combination > of Home Address / Care-of Address pairs." > > ==> The two defition differs. There may be a need to update the > terminology draft to cover (i) as well. > > In addition 2.1 reads: > > "A bi-directional tunnel may be established between each pair of Home > Address / Care-of address if the MR is itself multihomed." > > This sentence is confusing in the case multiple prefixes are advertised > on the visited link but only one is advertised on the home link. Indeed: > - MR would be multihomed according to the definition, and has > multiple CoAs, but > - only 1 tunnel can be established at a time, between the unique HoA > and the selected CoA; because NEMO/MIP does not allow multiple CoAs to > be associated with a same HoA AFAIK. > > ==> Sentence could be replaced with "A bi-directional tunnel may be > established for each Home Address of the MR if multiple prefixes are > advertised one the MR's home link." > > In 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP > -------------------------------------------------------- > " No assumptions are made on whether or not the HAs > belongs to the same administrative domain. However, the MRs > advertises the same MNP." > > ==> How can HAs from different administrative domains advertise routes > to the same MNP? Seems to me that the only possible scenario is the one > where all HAs are in the same domain. This is ackwonledged in 4.6 and > 4.11 but there may be a need for a ref to these sections in 2.7, to > avoid mislead the reader. > > In 3.1: > -------- > > For case "z=N: Multihomed mobile networks with multiple MNPs": > > "Example: a car with a prefix taken from home (personal traffic > transit on this prefix and is paid by the owner) and one that > belongs to the car manufacturer (maintenance traffic is paid by > the car-manufacturer). This will typically be a (1,1,n)." > > ==> In general I assume car manufacturer and personal ISP would be > different administrative domains, hence with different HAs. So the > example seems more like an (1,n,n) to me. > > > In 4.7 MR Synchronization > --------------------------- > "In the (n,*,n) case, a MR relaying the advertisement of the MNP > from another failed MR." > > ==> Do we really want that? Would it not be better to just let the > addresses die? > > In 4.12 Nested Mobile Networks > ------------------------------- > "As such, a solution to prevent an infinite loop must be provided." > ==> An infinite loop of what? Motivation is unclear IMHO. > > > In A.1.2 Subscriber/Provider Model > ------------------------------------- > > "For the S/mP model, the following configurations are likely to be > deployed: > > o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single > MNP" > > ==> Same comment as for 2.7: 4.6 and 4.11 highlight issues of such > configurations, which makes them _not_ likely to be deployed IMHO. > > > In A.2 Problem-Oriented Approach > ---------------------------------- > "o Shinkansen: Single MNP Advertised by MR(s) > > This is the case where one MNP is announced by different MRs. > This is equivalent to the case of z=n, i.e. the (1,*,n) mobile > network." > > ==> Should be (n,*,1), right? > > > Christophe. > > > Chan-Wah NG wrote: > > Hello All, > > > > During the Multihoming slot on Wednesday afternoon, we will be polling > > the room to check what are the problems listed in the draft that the WG > > feels should be worked on, either by some other WG, or by the NEMO WG if > > the problem is is directly related to the NEMO Charter. > > > > So, it would be much more productive if folks would come prepared (that > > is, read the draft, esp section 4). > > > > Thanks From nemo-bounces@ietf.org Wed Nov 10 22:24:37 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 WAA07580 for ; Wed, 10 Nov 2004 22:24:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5X1-0005hs-Cx; Wed, 10 Nov 2004 22:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5WO-0005YR-Hs for nemo@megatron.ietf.org; Wed, 10 Nov 2004 22:21: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 WAA07415 for ; Wed, 10 Nov 2004 22:21:14 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS5XP-0006oc-88 for nemo@ietf.org; Wed, 10 Nov 2004 22:22:24 -0500 Received: from iseran.local (unknown [130.129.132.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 65AAD4C0A9 for ; Thu, 11 Nov 2004 12:20:37 +0900 (JST) Date: Thu, 11 Nov 2004 12:23:10 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday Message-Id: <20041111122310.56a882ad.ernst@sfc.wide.ad.jp> In-Reply-To: <4192C490.2040600@sun.com> References: <1100010370.9642.6.camel@localhost> <41911E6B.4060302@sun.com> <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> <4192C490.2040600@sun.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: fb6060cb60c0cea16e3f7219e40a0a81 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 > > I guess that this is true for some of the cases of nemo multihoming but > > not in other cases (for instance imagine a nemo with two MR and a single > > HA, and a single prefix) > > In that case you have limited diversity both between the CN and HA, and > the MR and HA, since they all 1) need to get to a single HA and 2) the > HA has only one address. This is right, but in mobility environment, what matters is that access to the fixed network is not reliable, whereas HA is one order of magnitude more reliable. > > So in the case where there are multiple prefixes available and this > > prefixes belong to different HAs then, i guess that the multi6 solution > > would do the trick, but in the other hand, if you have a single prefix > > in the nemo, or when both HAs can route any of the available prefixes > > (for instance they are both connected to the same HA) then i am not sure > > multi6 protocol will be that useful > > Yes, I understand one can make a reasonable case for HA-MR redundant > paths using some MIP/Nemo specific technology. > But that doesn't translate to applying the same mechanism to CN-MR > redundant paths when Nemo RO is done; in that case I think one should > just use Multi6. I agree with you (provided we do decide to work on RO ;-). However, for some of the cases, what would matter the most is the ability to register multiple CoAs or multiple MNPs with a HA, and in this case MIP/NEMO are rather good candidates to make it work. > > I guess that there are two main reasosn for the differences between > > multi6 and nemo multihoming i.e.: > > - the support for ubiquity (this is well stated in the draft BTW). i > > mean in nemo multihoming, it is very likely that the direct link of the > > nemo is the one that will fail (not becuase of a failure, but because > > different media are available at different moments) so i guess that it > > would make sense to optimize this particular case, and that there will > > be configurations that mistly wnat to obtain this particular feature. > > Yes, but when doing RO (to an unmodified MIPv6 CN) you would then loose > that feature. Thus bidirectional tunneling will have better availability > that a route optimized path. > > > - the need for policing is probably much more significant (Hesham > > brought this up a long time ago AFAICT) if you have the typical example > > of a GPRS and a WLAN connections, it is probably not the same to send > > stuff on either one. Moreover, you probably don't want to fall back all > > your communications to the WLAN if the GPRS connection fails (for > > example) I guess that in the multi6 scenario it is not so common to see > > such big differences in capacity and charging, so the stress in these > > issues is probably very different > > And how is this Nemo specific? > With a vanilla IPv4 laptop with WLAN+GPRS I have exactly the same issue. But if MR has multiple egress interfaces, it also has multiple CoAs which need to be registered with the HA. This is rather NEMO/MIP specific. May be more MIP than NEMO. That's what I want to talk about tomorrow in the MIP6 WG (i will speak instead of Nicolas Montavont who is not here). > > I guess that the first step would be to identify the different nemo > > multihoming scenarios and see which one of them are properly served with > > a multi6 solution... > > That would make sense. I think there is rough consensus on such an approach. I haven't seen anyone defending the opposite approach. Thierry. From nemo-bounces@ietf.org Wed Nov 10 22:41:53 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 WAA09135 for ; Wed, 10 Nov 2004 22:41: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 1CS5ob-000843-Oq; Wed, 10 Nov 2004 22:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5gk-0007EQ-Di for nemo@megatron.ietf.org; Wed, 10 Nov 2004 22:31:58 -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 WAA08135 for ; Wed, 10 Nov 2004 22:31:55 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS5ho-0006xz-Lr for nemo@ietf.org; Wed, 10 Nov 2004 22:33:06 -0500 Received: from jurassic.eng.sun.com ([129.146.82.37]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAB3Vtui007913; Wed, 10 Nov 2004 20:31:55 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAB3Vscx481386; Wed, 10 Nov 2004 19:31:54 -0800 (PST) Message-ID: <4192DD5D.4080205@sun.com> Date: Wed, 10 Nov 2004 19:32:45 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday References: <1100010370.9642.6.camel@localhost> <41911E6B.4060302@sun.com> <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> <4192C490.2040600@sun.com> <20041111122310.56a882ad.ernst@sfc.wide.ad.jp> In-Reply-To: <20041111122310.56a882ad.ernst@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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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 Thierry Ernst wrote: >>>I guess that the first step would be to identify the different nemo >>>multihoming scenarios and see which one of them are properly served with >>>a multi6 solution... >> >>That would make sense. > > > I think there is rough consensus on such an approach. I haven't seen > anyone defending the opposite approach. Looking at *nemo* drafts that talk about multihoming I find one sentence mentioning multi6, which is what lead me to think that things are a bit too disconnected. Erik From nemo-bounces@ietf.org Thu Nov 11 08:22: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 IAA08342 for ; Thu, 11 Nov 2004 08: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 1CSErw-0001JH-Hh; Thu, 11 Nov 2004 08:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSEq4-00016L-Cr for nemo@megatron.ietf.org; Thu, 11 Nov 2004 08:18:12 -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 IAA07668 for ; Thu, 11 Nov 2004 08:18:11 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSErD-0001fK-Sv for nemo@ietf.org; Thu, 11 Nov 2004 08:19:25 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 11 Nov 2004 14:39:44 +0100 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 iABDHNvT010116; Thu, 11 Nov 2004 14:17:36 +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.0); Thu, 11 Nov 2004 14:17:33 +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: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Date: Thu, 11 Nov 2004 14:17:30 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC4148F5@xmb-ams-337.emea.cisco.com> Thread-Topic: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Thread-Index: AcS91b3VANCRuy1KRmeuLIDQEEMlRwKGSONA From: "Pascal Thubert \(pthubert\)" To: "Erik Nordmark" X-OriginalArrivalTime: 11 Nov 2004 13:17:33.0659 (UTC) FILETIME=[CE1222B0:01C4C7F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Vijay Devarapalli , Ville Nuorvala 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 > Pascal Thubert (pthubert) wrote: >=20 > > Well, there is a difference: we can (and must) put a restriction in the > > usage of the extended RH2. And that restriction is to go down the nested > > tree only. In particular if the source routed path in the RH2 is strict > > (not loose), we can force that the next entry in the RH is actually part > > of an MNP of the MR that processes the RH2. This is explicitly what the > > RRH draft says. >=20 > How would the strict restriction work when the mobile network (imagine a > large cruise ship) has one or more layers of regular routers, and then > the passangers arrive with their PANs that have their MRs? >=20 > A strict routing check assumes that all the routers are listed. >=20 Oups, sorry Erik I realize I never answered that. The way we have done it for strict is exactly following the pseudo code in the RRH draft (we need a connected route to the next hop, and that requires a chain of RRH compliant hops). In loose mode, we use a route lookup. Like, we must have a route to the next entry in the RH2 that is not a NEMO (default?) route. I could write book ;) but since RRH is not being considered by the GW for the time being, there's no point wasting people's time. But if you wish, I'd be glad to discuss that. There's a lot more to RRH then meets the eye. The world did not freeze the day NEMO as a WG decided to focus on basic. We as a WG could afford some catching now. In fact, that is one goal if the taxonomy draft, and dismissing that could be a huge waste. Pascal From nemo-bounces@ietf.org Thu Nov 11 09:19: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 JAA13367 for ; Thu, 11 Nov 2004 09:19: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 1CSFjv-0003Sg-BD; Thu, 11 Nov 2004 09:15:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSFgd-0002TH-HS for nemo@megatron.ietf.org; Thu, 11 Nov 2004 09:12:31 -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 JAA12818 for ; Thu, 11 Nov 2004 09:12:29 -0500 (EST) Received: from [130.129.132.111] (helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSFhn-0002xZ-LA for nemo@ietf.org; Thu, 11 Nov 2004 09:13:44 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 797E683200; Thu, 11 Nov 2004 22:15:17 +0800 (SGT) Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday From: Chan-Wah NG To: Erik Nordmark In-Reply-To: <4192DD5D.4080205@sun.com> References: <1100010370.9642.6.camel@localhost> <41911E6B.4060302@sun.com> <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> <4192C490.2040600@sun.com> <20041111122310.56a882ad.ernst@sfc.wide.ad.jp> <4192DD5D.4080205@sun.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1100182516.9029.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 11 Nov 2004 22:15:17 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Thierry Ernst 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 Erik, (and Thierry) Mind if I hop on to the discussion? On Thu, 2004-11-11 at 11:32, Erik Nordmark wrote: > Thierry Ernst wrote: > > >>>I guess that the first step would be to identify the different nemo > >>>multihoming scenarios and see which one of them are properly served with > >>>a multi6 solution... > >> > >>That would make sense. > > > > > > I think there is rough consensus on such an approach. I haven't seen > > anyone defending the opposite approach. > > Looking at *nemo* drafts that talk about multihoming I find one sentence > mentioning multi6, which is what lead me to think that things are a bit > too disconnected. > Hmm... can't interpret from your above sentence whether you feel that multi6 is mentioned too few or too many times. I tend to agree that we have not actually sit down and inspect carefully which problem falls into different working groups domain (multi6, mipv6, etc). That will be the one of main item on my plans for -02. I tend to agree with Marcelo that we can't simple classify each sub-section of section 4 as a domain of XXX WG, so most likely there would need to be a finer grain of partitioning. /rgds /cwng From nemo-bounces@ietf.org Thu Nov 11 10:51:54 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 KAA24774 for ; Thu, 11 Nov 2004 10:51:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSH2K-0001R8-Tw; Thu, 11 Nov 2004 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSH0d-0000uH-KK for nemo@megatron.ietf.org; Thu, 11 Nov 2004 10:37: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 KAA23457 for ; Thu, 11 Nov 2004 10:37:13 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSH1l-0004z6-5i for nemo@ietf.org; Thu, 11 Nov 2004 10:38:29 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 09A002E03F; Thu, 11 Nov 2004 16:36:37 +0100 (CET) Received: from [163.117.252.222] (vpn-252-222.uc3m.es [163.117.252.222]) by smtp02.uc3m.es (Postfix) with ESMTP id 973CE2E04B; Thu, 11 Nov 2004 16:36:33 +0100 (CET) In-Reply-To: <4192DD5D.4080205@sun.com> References: <1100010370.9642.6.camel@localhost> <41911E6B.4060302@sun.com> <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> <4192C490.2040600@sun.com> <20041111122310.56a882ad.ernst@sfc.wide.ad.jp> <4192DD5D.4080205@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <75CD14E4-33F7-11D9-8179-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday Date: Thu, 11 Nov 2004 16:36:31 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: nemo , Thierry Ernst 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 El 11/11/2004, a las 4:32, Erik Nordmark escribi=F3: > Thierry Ernst wrote: > >>>> I guess that the first step would be to identify the different nemo=20= >>>> multihoming scenarios and see which one of them are properly served=20= >>>> with a multi6 solution... >>> >>> That would make sense. >> I think there is rough consensus on such an approach. I haven't seen >> anyone defending the opposite approach. > > Looking at *nemo* drafts that talk about multihoming I find one=20 > sentence mentioning multi6, which is what lead me to think that things=20= > are a bit too disconnected. > yep, but until now, there wasn't remotely clear how a multi6 solution=20 would be, so i guess the lack of multi6 reference cannot be blamed. OTOH, now that we have a hint of how a multi6 solution may be, we can=20 move forward into this multi6-nemo integration i guess, so we should=20 do this now that is more possible regards, marcelo > Erik > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Thu Nov 11 11:08:30 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 LAA26295 for ; Thu, 11 Nov 2004 11:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHMo-0005gP-Ge; Thu, 11 Nov 2004 11:00:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHJr-0004sg-PE for nemo@megatron.ietf.org; Thu, 11 Nov 2004 10:57: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 KAA25417 for ; Thu, 11 Nov 2004 10:57:05 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHL3-0005RC-6e for nemo@ietf.org; Thu, 11 Nov 2004 10:58:22 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iABFwLnQ014283; Thu, 11 Nov 2004 08:58:21 -0700 (MST) Received: from [10.180.34.247] (mvp-10-180-34-247.am.mot.com [10.180.34.247]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id iABFtXFG019314; Thu, 11 Nov 2004 09:55:33 -0600 Message-ID: <41938BB2.3060104@motorola.com> Date: Thu, 11 Nov 2004 16:56:34 +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: "Pascal Thubert (pthubert)" Subject: Re: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) References: <7892795E1A87F04CADFCCF41FADD00FC4148F5@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC4148F5@xmb-ams-337.emea.cisco.com> 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="------------enig6FD95893EB370869FD8EA200" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, Vijay Devarapalli , Ville Nuorvala , Erik Nordmark 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) --------------enig6FD95893EB370869FD8EA200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The world did not freeze the day NEMO as a WG decided to focus on > basic. Oh didn't it :-) > We as a WG could afford some catching now. In fact, that is one goal > if the taxonomy draft, and dismissing that could be a huge waste. Pascal, the taxonomy draft-03 is a nice piece of work. I had a detalied look over it yesterday and wanted to make a detalied review later, but since you talk about it now, may I give high-level remarks. The WG item on problem statement is good to be short 3-5 pages IMHO. How about deciding in advance about the max number of pages and stick to that. The current draft could be shortened by removing entirely the comparative analysis of the various solutions, maybe that could be a separate draft. IMHO only the abstract and the 1st section are exactly problem statement. If this is done, then it is no longer a "taxonomy" draft, it becomes more of a "problem statement" draft. The draft could be further shortened by reducing the big encapsulation/long path illustrations from 3 MR's to 2. IT is enough for a reader to interpret the meaning of it by just using 1 and 2 example MR's. The logical extension from one and two to $n$ happens in the reader's mind as easy as the extension from one and two and three to $n$ and the description is shorter if only two MR's. This reduction also reduces the risk of introducing spec errors. Such an error is already there: HAofMR5 is talked about but not pictured; instead MR6 is pictured but not talked about. Second, there is a specific problem of NEMO Basic Support named "cross-over" tunnels, mentioned at http://tinyurl.com/4z4kc see Section B.6; there it is shown how a specific mobility configuration (HA in the moving network and moving networks exchanging their positions) is not supported by NEMO BAsic Support. I see this mobility configuration problem as an important problem on the protocol itself, I mean the protocol does not support such a configuration. In addition, there may be other similar mobility configurations that are not supported by NEMO Basic Support. Finally, about the current draft taxonomy 03 and Security Considerations. There are important Security problems when discussing RO for NEMO; at the same time many security aspects of various solutions have been discussed, but I'd keep these out of this document. In the WG RO item I'd only mention a unique Security Considerations section that only says what are the security risks of having a prefix at CN. Not to say the draft does not do it, but that the draft has too many security risks described, each attach to a single solution; it's too scattered. Alex --------------enig6FD95893EB370869FD8EA200 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 iD8DBQFBk4u4MmC0w56zj54RAmtNAKDv3S2J+a4EUq3vJ6ClQ6M1XEVMYQCfS3a+ DHO2hFSg35rCZepzCq93d88= =0KkK -----END PGP SIGNATURE----- --------------enig6FD95893EB370869FD8EA200-- From nemo-bounces@ietf.org Thu Nov 11 11:52:22 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 LAA00834 for ; Thu, 11 Nov 2004 11:52: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 1CSI40-0006XU-1B; Thu, 11 Nov 2004 11:44:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHtw-0004Jx-Fx for nemo@megatron.ietf.org; Thu, 11 Nov 2004 11: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 LAA28795 for ; Thu, 11 Nov 2004 11:34:22 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHv8-0006HB-Hy for nemo@ietf.org; Thu, 11 Nov 2004 11:35:39 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 11 Nov 2004 17:55:58 +0100 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 iABGXCvt028400; Thu, 11 Nov 2004 17:33:49 +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.0); Thu, 11 Nov 2004 17:33:16 +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: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Date: Thu, 11 Nov 2004 17:33:13 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC451A3A@xmb-ams-337.emea.cisco.com> Thread-Topic: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Thread-Index: AcTIBxpBHAT9lyNHS3uH8Qdnm0dkVQAATVMg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 11 Nov 2004 16:33:16.0418 (UTC) FILETIME=[254CF620:01C4C80C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Vijay Devarapalli , Ville Nuorvala , Erik Nordmark 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 Alex. This is exactly the kind of comments we need.=20 > Pascal, the taxonomy draft-03 is a nice piece of work. I had a detalied > look over it yesterday and wanted to make a detalied review later, but > since you talk about it now, may I give high-level remarks. >=20 > The WG item on problem statement is good to be short 3-5 pages IMHO. > How about deciding in advance about the max number of pages and stick > to that. Maybe it's a problemS statement, though. Understanding this might help accept the prospect that we might not come up with THE solution; and that we might come up with something a bit thicker then usual. Unless we make several problem statementS. But I do not feel too comfortable with that... because we might be able to come up with a core technology that helps in most cases, and additional specific things that complete the picture, as opposed to completely separate solutions.=20 > The current draft could be shortened by removing entirely the > comparative analysis of the various solutions, maybe that could be a > separate draft. IMHO only the abstract and the 1st section are exactly > > If this is done, then it is no longer a "taxonomy" draft, it becomes > more of a "problem statement" draft.> problem statement. Yes, that would be my hopeful interpretation of Erik's word. But then, what do we do with the second part? A NEMO RO "BCP" ? Does the WG want to support that effort of does it die with 03? >=20 > The draft could be further shortened by reducing the big > encapsulation/long path illustrations from 3 MR's to 2. IT is enough > for a reader to interpret the meaning of it by just using 1 and 2 > example MR's. The logical extension from one and two to $n$ happens in > the reader's mind as easy as the extension from one and two and three to > $n$ and the description is shorter if only two MR's. This reduction > also reduces the risk of introducing spec errors. Such an error is > already there: HAofMR5 is talked about but not pictured; instead MR6 is > pictured but not talked about. Yes. I need to review all cases but this counds like a very good, constructive comment. > Second, there is a specific problem of NEMO Basic Support named > "cross-over" tunnels, mentioned at http://tinyurl.com/4z4kc see Section > B.6; there it is shown how a specific mobility configuration (HA in the > moving network and moving networks exchanging their positions) is not > supported by NEMO BAsic Support. I see this mobility configuration > problem as an important problem on the protocol itself, I mean the > protocol does not support such a configuration. In addition, there may > be other similar mobility configurations that are not supported by NEMO > Basic Support. Good point. I hate myself for forgetting it :) It should be there in the next version. Is that really a RO problem, or is that a NEMO problem that RO could/should solve? > Finally, about the current draft taxonomy 03 and Security > Considerations. There are important Security problems when discussing > RO for NEMO; at the same time many security aspects of various solutions > have been discussed, but I'd keep these out of this document. In the WG > RO item I'd only mention a unique Security Considerations section that > only says what are the security risks of having a prefix at CN. Not to > say the draft does not do it, but that the draft has too many security > risks described, each attach to a single solution; it's too scattered. >=20 I believe we need to mention the security issues that some RO cases might open, for instance things similar to what MIP6 has with CN, and for which the RR test is what it is today, as part of the problem. But NEMO could allow alternate approaches (such as the infrastructure doing the job) for which the RR problem disappears, at the expense of an imperfect RO. I believe that ISPs might end up deploying some infrastructure RO, implementing their own set of requirements. And that in the other end, opensource/consumer products will implement something for mobile peer to peer, router to router, with a different set of requirement. That they might not trust each other for doing the job right well, and that both could end up running over one another, or concurrently, or what. It could be nice if we could understand these requirements and at least build a set of common tools that could be adapted in both worlds and at least not kill each other... Pascal From nemo-bounces@ietf.org Thu Nov 11 15:53: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 PAA26200 for ; Thu, 11 Nov 2004 15:53:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLpk-0004G8-Ut; Thu, 11 Nov 2004 15:46:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLh1-0007gC-RY for nemo@megatron.ietf.org; Thu, 11 Nov 2004 15:37: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 PAA23916 for ; Thu, 11 Nov 2004 15:37:18 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLiG-00045g-3U for nemo@ietf.org; Thu, 11 Nov 2004 15:38:36 -0500 Received: from jurassic.eng.sun.com ([129.146.88.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iABKbHui018818; Thu, 11 Nov 2004 13:37:17 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABKbGJw226180; Thu, 11 Nov 2004 12:37:16 -0800 (PST) Message-ID: <4193C50D.2070709@sun.com> Date: Thu, 11 Nov 2004 12:01:17 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday References: <1100010370.9642.6.camel@localhost> <41911E6B.4060302@sun.com> <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> <4192C490.2040600@sun.com> <20041111122310.56a882ad.ernst@sfc.wide.ad.jp> <4192DD5D.4080205@sun.com> <1100182516.9029.7.camel@localhost> In-Reply-To: <1100182516.9029.7.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Thierry Ernst 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 Chan-Wah NG wrote: > Hmm... can't interpret from your above sentence whether you feel that > multi6 is mentioned too few or too many times. It isn't the mention that is needed; it is the work to figure out the relationship between Nemo-specific multihoming support and generic multi6 support. Erik > I tend to agree that we have not actually sit down and inspect carefully > which problem falls into different working groups domain (multi6, mipv6, > etc). That will be the one of main item on my plans for -02. I tend to > agree with Marcelo that we can't simple classify each sub-section of > section 4 as a domain of XXX WG, so most likely there would need to be a > finer grain of partitioning. > > /rgds > /cwng > From nemo-bounces@ietf.org Thu Nov 11 16:47:40 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 QAA02211 for ; Thu, 11 Nov 2004 16:47: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 1CSMXz-00056e-8Z; Thu, 11 Nov 2004 16:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMRg-0002MD-2h for nemo@megatron.ietf.org; Thu, 11 Nov 2004 16:25: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 QAA29962 for ; Thu, 11 Nov 2004 16:25:30 -0500 (EST) Received: from [130.129.67.218] (helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMSu-0005da-Mc for nemo@ietf.org; Thu, 11 Nov 2004 16:26:49 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 254719E54D; Fri, 12 Nov 2004 05:35:30 +0800 (SGT) Subject: Re: [nemo] Multihoming Issues To be Presented Wednesday From: Chan-Wah NG To: Erik Nordmark In-Reply-To: <4193C50D.2070709@sun.com> References: <1100010370.9642.6.camel@localhost> <41911E6B.4060302@sun.com> <12BFDD17-3314-11D9-8179-000D93ACD0FE@it> <4192C490.2040600@sun.com> <20041111122310.56a882ad.ernst@sfc.wide.ad.jp> <4192DD5D.4080205@sun.com> <1100182516.9029.7.camel@localhost> <4193C50D.2070709@sun.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1100208929.9494.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 12 Nov 2004 05:35:29 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Thierry Ernst 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 Fri, 2004-11-12 at 04:01, Erik Nordmark wrote: > Chan-Wah NG wrote: > > > Hmm... can't interpret from your above sentence whether you feel that > > multi6 is mentioned too few or too many times. > > It isn't the mention that is needed; it is the work to figure out the > relationship between Nemo-specific multihoming support and generic > multi6 support. > Yep, then we are in agreement here -- that's precisely what I intend to do for -02. /rgds /cwng From nemo-bounces@ietf.org Thu Nov 11 17:57:27 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 RAA09182 for ; Thu, 11 Nov 2004 17:57:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNiy-0001Sa-18; Thu, 11 Nov 2004 17:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNdQ-0007vI-Ux for nemo@megatron.ietf.org; Thu, 11 Nov 2004 17:41:45 -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 RAA07894 for ; Thu, 11 Nov 2004 17:41:42 -0500 (EST) Received: from [130.129.67.218] (helo=mozart.psl.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNed-0007kz-9M for nemo@ietf.org; Thu, 11 Nov 2004 17:43:02 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 940289E54D; Fri, 12 Nov 2004 06:51:38 +0800 (SGT) Subject: Re: (was Re: Multiple address in RH type 2, now back to:) [nemo] RO taxonomy From: Chan-Wah NG To: Alexandru Petrescu In-Reply-To: <41938BB2.3060104@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC4148F5@xmb-ams-337.emea.cisco.com> <41938BB2.3060104@motorola.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1100213497.9502.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 12 Nov 2004 06:51:37 +0800 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Vijay Devarapalli , Erik Nordmark , Ville Nuorvala 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 Alex, Thank you for reading the draft immediately after the WG session, and I appreciate you comments. It is these comments that allow us to improve our work. If I recall, you were the one who referred us to the WG charter. Contents of version -03 of the ro-taxonomy draft is exactly tailored according to what is spelt out in the WG charter. (Unless the WG charter is once again changed and I wasn't aware of ....) Now people are complaining the draft is too long. >From the WG charter, we are not required to come up with a *short* problem statement draft. We are, however, required to come up with a *detailed* problem statement *and* looks at various approaches to solving the problem. I am not against a concise problem statement draft that is short and sweet. I like that too. In fact, I would say that the problem statement section of the draft-ro-taxonomy is quite short (3-5 pages, as you and Hesham suggested). If the WG changes the charter to reflect that, I will gladly copy and paste the appropriate sections from ro-taxonomy-03.txt to a new short problem statement draft. However, IMHO, we should not remove the WG charter on coming up with an informational document on ro solution space analysis. It is a useful document that records the WG experiences on the route optimization solution space. If the WG wants a short problem statement draft, then let's have a WG problem statement draft *and* a WG solution-space-analysis draft. About your last comment on secuirty risks, I agree we should have a general security consdierations text that is not solution-space specific. I will add this in -04. But, I will not remove the security risks discussions specific to each approach. Again, as pointed out by the WG charter (the charter that I know of, anyway): "security considerations for the various approaches will also be considered". /rgds /cwng On Thu, 2004-11-11 at 23:56, Alexandru Petrescu wrote: > Pascal Thubert (pthubert) wrote: > > The world did not freeze the day NEMO as a WG decided to focus on > > basic. > > Oh didn't it :-) > > > We as a WG could afford some catching now. In fact, that is one goal > > if the taxonomy draft, and dismissing that could be a huge waste. > > Pascal, the taxonomy draft-03 is a nice piece of work. I had a detalied > look over it yesterday and wanted to make a detalied review later, but > since you talk about it now, may I give high-level remarks. > > The WG item on problem statement is good to be short 3-5 pages IMHO. > How about deciding in advance about the max number of pages and stick > to that. > > The current draft could be shortened by removing entirely the > comparative analysis of the various solutions, maybe that could be a > separate draft. IMHO only the abstract and the 1st section are exactly > problem statement. > > If this is done, then it is no longer a "taxonomy" draft, it becomes > more of a "problem statement" draft. > > The draft could be further shortened by reducing the big > encapsulation/long path illustrations from 3 MR's to 2. IT is enough > for a reader to interpret the meaning of it by just using 1 and 2 > example MR's. The logical extension from one and two to $n$ happens in > the reader's mind as easy as the extension from one and two and three to > $n$ and the description is shorter if only two MR's. This reduction > also reduces the risk of introducing spec errors. Such an error is > already there: HAofMR5 is talked about but not pictured; instead MR6 is > pictured but not talked about. > > Second, there is a specific problem of NEMO Basic Support named > "cross-over" tunnels, mentioned at http://tinyurl.com/4z4kc see Section > B.6; there it is shown how a specific mobility configuration (HA in the > moving network and moving networks exchanging their positions) is not > supported by NEMO BAsic Support. I see this mobility configuration > problem as an important problem on the protocol itself, I mean the > protocol does not support such a configuration. In addition, there may > be other similar mobility configurations that are not supported by NEMO > Basic Support. > > Finally, about the current draft taxonomy 03 and Security > Considerations. There are important Security problems when discussing > RO for NEMO; at the same time many security aspects of various solutions > have been discussed, but I'd keep these out of this document. In the WG > RO item I'd only mention a unique Security Considerations section that > only says what are the security risks of having a prefix at CN. Not to > say the draft does not do it, but that the draft has too many security > risks described, each attach to a single solution; it's too scattered. > > Alex From nemo-bounces@ietf.org Thu Nov 11 18:38: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 SAA14770 for ; Thu, 11 Nov 2004 18:38: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 1CSORB-0001WV-CY; Thu, 11 Nov 2004 18:33:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSOPZ-0000jO-6T for nemo@megatron.ietf.org; Thu, 11 Nov 2004 18:31:29 -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 SAA14151 for ; Thu, 11 Nov 2004 18:31:26 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSOQo-0000cQ-R6 for nemo@ietf.org; Thu, 11 Nov 2004 18:32:47 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Nov 2004 00:53:09 +0100 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 iABNUgua014146; Fri, 12 Nov 2004 00:30:53 +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.0); Fri, 12 Nov 2004 00:30:40 +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: [nemo]RO taxonomy Date: Fri, 12 Nov 2004 00:21:37 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC451AF5@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo]RO taxonomy Thread-Index: AcTIP9n4DuUrz7CDT5qfzZ2HpjVCNgAAq+8g From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah NG" , "Alexandru Petrescu" X-OriginalArrivalTime: 11 Nov 2004 23:30:40.0664 (UTC) FILETIME=[74D5A180:01C4C846] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Erik Nordmark 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 I agree with Chan Wah.=20 Also, Alex mentioned at the WG that the draft might be written a partial way, implicitly promoting some solutions. And that for that reason, it could not be used as a base for the WG draft, as proposed by the chairs. But then, Alex did not come up with any specific on this in his following (and appreciated) review.=20 So I have questions for the WG: Q1 Should we split?=20 Q2 Is the doc fair enough WRT possible approaches? Q3 And BTW did we miss any? Unless they are so pervasive that it can not be fixed, I suggest we fix whichever partiality issues is found (if any), incorporate the relevant text from the other drafts (mostly the MANET aspect that was really understated) and propose the doc again for WG consideration, either on one or 2 pieces. Pascal > -----Original Message----- > From: Chan-Wah NG [mailto:cwng@psl.com.sg] > Sent: jeudi 11 novembre 2004 23:52 > To: Alexandru Petrescu > Cc: Pascal Thubert (pthubert); IETF NEMO WG; Vijay Devarapalli; Ville Nuorvala; Erik Nordmark > Subject: Re: (was Re: Multiple address in RH type 2, now back to:) [nemo]RO taxonomy >=20 > Hello Alex, >=20 > Thank you for reading the draft immediately after the WG session, and I > appreciate you comments. It is these comments that allow us to improve > our work. >=20 > If I recall, you were the one who referred us to the WG charter. > Contents of version -03 of the ro-taxonomy draft is exactly tailored > according to what is spelt out in the WG charter. (Unless the WG charter > is once again changed and I wasn't aware of ....) >=20 > Now people are complaining the draft is too long. >=20 > >From the WG charter, we are not required to come up with a *short* > problem statement draft. We are, however, required to come up with a > *detailed* problem statement *and* looks at various approaches to > solving the problem. >=20 > I am not against a concise problem statement draft that is short and > sweet. I like that too. In fact, I would say that the problem > statement section of the draft-ro-taxonomy is quite short (3-5 pages, as > you and Hesham suggested). If the WG changes the charter to reflect > that, I will gladly copy and paste the appropriate sections from > ro-taxonomy-03.txt to a new short problem statement draft. >=20 > However, IMHO, we should not remove the WG charter on coming up with an > informational document on ro solution space analysis. It is a useful > document that records the WG experiences on the route optimization > solution space. If the WG wants a short problem statement draft, then > let's have a WG problem statement draft *and* a WG > solution-space-analysis draft. >=20 > About your last comment on secuirty risks, I agree we should have a > general security consdierations text that is not solution-space > specific. I will add this in -04. But, I will not remove the security > risks discussions specific to each approach. Again, as pointed out by > the WG charter (the charter that I know of, anyway): "security > considerations for the various approaches will also be considered". >=20 > /rgds > /cwng >=20 > On Thu, 2004-11-11 at 23:56, Alexandru Petrescu wrote: > > Pascal Thubert (pthubert) wrote: > > > The world did not freeze the day NEMO as a WG decided to focus on > > > basic. > > > > Oh didn't it :-) > > > > > We as a WG could afford some catching now. In fact, that is one goal > > > if the taxonomy draft, and dismissing that could be a huge waste. > > > > Pascal, the taxonomy draft-03 is a nice piece of work. I had a detalied > > look over it yesterday and wanted to make a detalied review later, but > > since you talk about it now, may I give high-level remarks. > > > > The WG item on problem statement is good to be short 3-5 pages IMHO. > > How about deciding in advance about the max number of pages and stick > > to that. > > > > The current draft could be shortened by removing entirely the > > comparative analysis of the various solutions, maybe that could be a > > separate draft. IMHO only the abstract and the 1st section are exactly > > problem statement. > > > > If this is done, then it is no longer a "taxonomy" draft, it becomes > > more of a "problem statement" draft. > > > > The draft could be further shortened by reducing the big > > encapsulation/long path illustrations from 3 MR's to 2. IT is enough > > for a reader to interpret the meaning of it by just using 1 and 2 > > example MR's. The logical extension from one and two to $n$ happens in > > the reader's mind as easy as the extension from one and two and three to > > $n$ and the description is shorter if only two MR's. This reduction > > also reduces the risk of introducing spec errors. Such an error is > > already there: HAofMR5 is talked about but not pictured; instead MR6 is > > pictured but not talked about. > > > > Second, there is a specific problem of NEMO Basic Support named > > "cross-over" tunnels, mentioned at http://tinyurl.com/4z4kc see Section > > B.6; there it is shown how a specific mobility configuration (HA in the > > moving network and moving networks exchanging their positions) is not > > supported by NEMO BAsic Support. I see this mobility configuration > > problem as an important problem on the protocol itself, I mean the > > protocol does not support such a configuration. In addition, there may > > be other similar mobility configurations that are not supported by NEMO > > Basic Support. > > > > Finally, about the current draft taxonomy 03 and Security > > Considerations. There are important Security problems when discussing > > RO for NEMO; at the same time many security aspects of various solutions > > have been discussed, but I'd keep these out of this document. In the WG > > RO item I'd only mention a unique Security Considerations section that > > only says what are the security risks of having a prefix at CN. Not to > > say the draft does not do it, but that the draft has too many security > > risks described, each attach to a single solution; it's too scattered. > > > > Alex From nemo-bounces@ietf.org Fri Nov 12 00:54:22 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 AAA15067 for ; Fri, 12 Nov 2004 00:54: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 1CSULq-00030e-OL; Fri, 12 Nov 2004 00:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSULT-0002tS-2u for nemo@megatron.ietf.org; Fri, 12 Nov 2004 00:51:39 -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 AAA14879 for ; Fri, 12 Nov 2004 00:51:36 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSUMl-0007yP-8i for nemo@ietf.org; Fri, 12 Nov 2004 00:53:00 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id iAC5heM9015699; Thu, 11 Nov 2004 22:43:40 -0700 (MST) Received: from [10.182.46.24] (mvp-10-182-46-24.am.mot.com [10.182.46.24]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id iAC5pB2U012454; Thu, 11 Nov 2004 23:51:13 -0600 Message-ID: <41944F60.6030009@motorola.com> Date: Fri, 12 Nov 2004 06:51:28 +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: Chan-Wah NG Subject: Re: (was Re: Multiple address in RH type 2, now back to:) [nemo] RO taxonomy References: <7892795E1A87F04CADFCCF41FADD00FC4148F5@xmb-ams-337.emea.cisco.com> <41938BB2.3060104@motorola.com> <1100213497.9502.31.camel@localhost> In-Reply-To: <1100213497.9502.31.camel@localhost> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , "Pascal Thubert \(pthubert\)" , Vijay Devarapalli , Erik Nordmark , Ville Nuorvala 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 Chan-Wah NG wrote: > If I recall, you were the one who referred us to the WG charter. > Contents of version -03 of the ro-taxonomy draft is exactly tailored > according to what is spelt out in the WG charter. (Unless the WG > charter is once again changed and I wasn't aware of ....) > > Now people are complaining the draft is too long. I agree. The Charter says too about discussing analysis of solution space in the Problem draft. I realize that is hard to do though. >> From the WG charter, we are not required to come up with a *short* > problem statement draft. We are, however, required to come up with a > *detailed* problem statement *and* looks at various approaches to > solving the problem. I agree. > I am not against a concise problem statement draft that is short and > sweet. I like that too. In fact, I would say that the problem > statement section of the draft-ro-taxonomy is quite short (3-5 pages, > as you and Hesham suggested). If the WG changes the charter to > reflect that, I will gladly copy and paste the appropriate sections > from ro-taxonomy-03.txt to a new short problem statement draft. > > However, IMHO, we should not remove the WG charter on coming up with > an informational document on ro solution space analysis. It is a > useful document that records the WG experiences on the route > optimization solution space. If the WG wants a short problem > statement draft, then let's have a WG problem statement draft *and* a > WG solution-space-analysis draft. I agree. > About your last comment on secuirty risks, I agree we should have a > general security consdierations text that is not solution-space > specific. I will add this in -04. But, I will not remove the > security risks discussions specific to each approach. Again, as > pointed out by the WG charter (the charter that I know of, anyway): > "security considerations for the various approaches will also be > considered". I agree. Alex From nemo-bounces@ietf.org Fri Nov 12 01:57: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 BAA19643 for ; Fri, 12 Nov 2004 01:57:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSVEH-0002ya-MN; Fri, 12 Nov 2004 01:48:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSVCI-0002fI-LM for nemo@megatron.ietf.org; Fri, 12 Nov 2004 01:46:14 -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 BAA18993 for ; Fri, 12 Nov 2004 01:46:08 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSVDW-0000ZA-Lq for nemo@ietf.org; Fri, 12 Nov 2004 01:47:32 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id iAC6lMeN025944; Thu, 11 Nov 2004 23:47:22 -0700 (MST) Received: from [10.182.46.24] (mvp-10-182-46-24.am.mot.com [10.182.46.24]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id iAC6bp1K032471; Fri, 12 Nov 2004 00:37:52 -0600 Message-ID: <41945C22.2050500@motorola.com> Date: Fri, 12 Nov 2004 07:45:54 +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: "Pascal Thubert (pthubert)" Subject: Re: [nemo]RO taxonomy References: <7892795E1A87F04CADFCCF41FADD00FC451AF5@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC451AF5@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Erik Nordmark , Chan-Wah NG 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 Pascal Thubert (pthubert) wrote: > I agree with Chan Wah. And I agree with both of you. > Also, Alex mentioned at the WG that the draft might be written a > partial way, implicitly promoting some solutions. And that for that > reason, it could not be used as a base for the WG draft, as proposed > by the chairs. But then, Alex did not come up with any specific on > this in his following (and appreciated) review. Pascal, there was a misunderstanding, sorry for that, let me explain. Very often during discussions in this WG you've claimed that RRH and Tree Discovery are a panacea for all RO needs. And not to mention HAHA, and now Global HAHA which was presented in the multi-homing slot. It is mostly to these remarks that I reacted. The current draft is called draft-thubert-taxonomy and I read several of draft-thubert-something and did my homework and commented on the mailing list only to get very little real communication. This is my personal oppinion. It is on the other hand that draft-thubert-taxonomy-03 is a radical change since my last read (maybe 02) and thank you for that. I wonder if this is due to the change in authorship, but I don't necessarily need a response. It was an error from my part to qualify the partiality of draft-thubert-taxonomy-03. Alex From nemo-bounces@ietf.org Fri Nov 12 02:12: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 CAA02614 for ; Fri, 12 Nov 2004 02:12:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSVWb-000886-Je; Fri, 12 Nov 2004 02:07:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSVVI-0007lv-O3 for nemo@megatron.ietf.org; Fri, 12 Nov 2004 02:05:53 -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 CAA25918 for ; Fri, 12 Nov 2004 02:05:50 -0500 (EST) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSVWZ-0000tW-6o for nemo@ietf.org; Fri, 12 Nov 2004 02:07:14 -0500 Received: from lymeon.ucdavis.edu (lymeon.ucdavis.edu [169.237.104.171]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAC75eLu009811; Thu, 11 Nov 2004 23:05:40 -0800 (PST) Received: from lymeon.ucdavis.edu (localhost [127.0.0.1]) by lymeon.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAC75e3k029073; Thu, 11 Nov 2004 23:05:40 -0800 (PST) Received: (from www@localhost) by lymeon.ucdavis.edu (8.12.10/8.12.9/Submit) id iAC75dWp029072; Thu, 11 Nov 2004 23:05:39 -0800 (PST) Date: Thu, 11 Nov 2004 23:05:39 -0800 (PST) Message-Id: <200411120705.iAC75dWp029072@lymeon.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [64.8.195.10] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [nemo] What kind of NEMO RO problem WG document we would like to see 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 NEMO WG members, IMHO, draft-thubert-nemo-ro-taxonomy-03 is far from what NEMO RO problem Wg document should be. (Sorry, Pascal and Chan-Wah, please see the following text and my another email about comments on your solution space analysis part.) I feel at this moment WG should consider What kind of NEMO RO problem WG document we would like to see rather than which draft should be picked as the WG item. Once we reach the consensus on that, we can go back to see if any existing draft meets or is close to meet our needs then it can become WG document without question, otherwise if there is no one, we have to work on the new document that we want to see. We already have four NEMo RO problem related drafts that all are good inputs to the WG document. It is inefficient if we spend the duplicate efforts on the same subject. Below is my vision about NEMO RO problem WG document: 1. NEMO RO problem draft should be written in an abstract way rather than solution-specific. (from calos's email on the ML if I am not wrong.) 2. It does not matter how many pages the problem statement part should be, but it must be to the core of the problem. 3. The solution "space" analysis part must not just simply list the previouly proposed solutions. 4. It should be able to analyze the complete solution space including the proposed and the new ones. (The completeness should be assured in certain level.) 5. The method to categorize the solution space must be able to make one category not intersect with any other category (mutual exclusive). 6. The solution space analysis does not judge on the strength and weakness of each solution. 7. The security analysis should be general rather than being solution- specific. Also it should be easy to apply to each solution. 8. The solution space analysis part must focus on the core idea because there could be an infinite number of solutions that are in the different forms. We also have to think about the content of WG document. BTW my presentation slides in IETF 61 is available at http://wwwcsif.cs.ucdavis.edu/ zhaofa/NEMORO/ietf61.ppt. I am very sorry I have not finished updating my draft. If anyone is interested, I will be very happy to talk about it in more details on ML. The biggest update is to use the vector to categorize the solution space. And also we show that it is possible to extend the solution achieving RO when CN is not under the same NEMO network to achieve the RO when CN is under the same NEMO network, which could be an alternative to MANET. I will make my new draft available ASAP. Your comments are very welcomed. Sincerely, fan From nemo-bounces@ietf.org Fri Nov 12 02:21:06 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 CAA05247 for ; Fri, 12 Nov 2004 02:21:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSVg9-0003M6-9N; Fri, 12 Nov 2004 02:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSVbl-0001Ax-Uf for nemo@megatron.ietf.org; Fri, 12 Nov 2004 02:12: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 CAA02443 for ; Fri, 12 Nov 2004 02:12:32 -0500 (EST) Received: from losangeles.ucdavis.edu ([169.237.104.159]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSVd5-0000z3-Bv for nemo@ietf.org; Fri, 12 Nov 2004 02:13:55 -0500 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by losangeles.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAC7CNUY023968; Thu, 11 Nov 2004 23:12:29 -0800 (PST) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAC79K7m006579; Thu, 11 Nov 2004 23:09:20 -0800 (PST) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id iAC79KKi006578; Thu, 11 Nov 2004 23:09:20 -0800 (PST) Date: Thu, 11 Nov 2004 23:09:20 -0800 (PST) Message-Id: <200411120709.iAC79KKi006578@tremex.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [64.8.195.10] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [nemo] comments on solution space analysis part in 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 Dear Pascal and Chan-Wah, I have some comments on the draft-thubert-nemo-ro-taxonomy-03. I will focus on solution space analysis part as we already have discussed on the problem statement part before. Section 3. Solution Space of NEMO Route Optimization "Shorter Delay", "Reduced Consumption of Overall Network Resources", "Less Susceptibility to Link Failure", "Greater Data Efficiency" are the benefits of RO, which should be in the problem statement part, but not in the solution space analysis part. " There are multiple proposals for providing various forms of route optimizations for NEMO (see Appendix A). " Please delete the appendix. As some proposals are incomplete, even some does not work. What's more, some proposals look different but actually using the same core idea. "3.1 MR-to-CN Optimization" "3.2 Infrastructure Optimization" "3.3 Nested Tunnels Optimization" "3.4 MIPv6-over-NEMO Optimization" "3.5 Intra-NEMO Optimization" The solution space analysis part is organized like in the problem statement part to me. I do not see any logic behind the way you use to categorize the solution space. Remember that the different problem scenarios do not mean the different solutions (core ideas). "Binding Update with Network Prefix" and "MR as a Proxy" use the same idea to me and are described in a too specific way. "Infrastructure Optimization" I do not understand why "MR-to-CN optimization" does not possibly fall into this category. "Nested Tunnels Optimization" "Nested tunnels" is not the core of nemo ro problem and it sounds too specific too. It could make one reader wonder why other tunnel- reduction methods are not listed. "MIPv6-over-NEMO Optimization" A lot of duplications for me. 4. Analysis of Solution Space 4.1 General Considerations of RO Solution The content describes the tradeoffs similar with the section of "the related tradeoffs" in the draft-zhao-nemo-ro-ps-00.txt. :-) Our draft also has other tradeoffs. 4.1.1 Additional Signaling Overhead The text of BU sould specific to me. The text of BU storm should belong to problem statement part. 4.1.2 Increased Protocol Complexity I understand your point. However it seems to me the scalability issue has more impacts on power and processing resources than the protocol complexity. 4.1.3 Mobility Awareness "it will be difficult for mobile network nodes to control the decision of having this tradeoff" Is that also the case for VMN? 4.1.4 New Functionalities "Correspondent Nodes It is generally undesirable for correspondent nodes to be required to implement new functionalities." I do not agree. It depends on the type of CN. 4.1.5 Other Considerations If you think they are not "tradeoff", they should not be under this section. 4.2 Specific Types of RO Solution "Many of the tradeoffs discussed previously in Section 4.2 are dependent on the actual route optimization approach." Please give an example that one solution does not have one of the tradeoffs above. If there is one, your discussion about tradeoff is not general. Some text seems like a evaluation to me. I recall one email on the ML before states that the problem draft should not judge on the quality of the solution. There are a lot of redundency too because of the way the draft used to categorize the solution space. I prefer a general security consideration also. Overall, the solution space part does not analyze the space completely and does not categorize the solution space into mutual exclusive categories. My personal oponion is that this draft needs some fundmental changes Thus I agree that WG should work on a new WG document based on the existing documents in order to be more productive. Sincerely, fan From nemo-bounces@ietf.org Fri Nov 12 02:23:33 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 CAA05539 for ; Fri, 12 Nov 2004 02:23: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 1CSVk7-0005RL-U8; Fri, 12 Nov 2004 02:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSVgs-0003ej-8i for nemo@megatron.ietf.org; Fri, 12 Nov 2004 02:17:50 -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 CAA04837 for ; Fri, 12 Nov 2004 02:17:47 -0500 (EST) Received: from bern.ucdavis.edu ([169.237.104.167]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSViA-00014D-7C for nemo@ietf.org; Fri, 12 Nov 2004 02:19:11 -0500 Received: from syrphus.ucdavis.edu (syrphus.ucdavis.edu [169.237.104.152]) by bern.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAC7Hhuv017674; Thu, 11 Nov 2004 23:17:44 -0800 (PST) Received: from syrphus.ucdavis.edu (localhost [127.0.0.1]) by syrphus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAC7Hhc3013998; Thu, 11 Nov 2004 23:17:43 -0800 (PST) Received: (from www@localhost) by syrphus.ucdavis.edu (8.12.10/8.12.9/Submit) id iAC7HhO0013997; Thu, 11 Nov 2004 23:17:43 -0800 (PST) Date: Thu, 11 Nov 2004 23:17:43 -0800 (PST) Message-Id: <200411120717.iAC7HhO0013997@syrphus.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [64.8.195.10] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [nemo] The correct url of slides 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, Sorry, the url for my presentation is http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ietf61.ppt. Sincerely, fan From nemo-bounces@ietf.org Fri Nov 12 03:50:26 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 DAA11271 for ; Fri, 12 Nov 2004 03:50: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 1CSX6J-0002fA-Mh; Fri, 12 Nov 2004 03:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSX27-000284-KG for nemo@megatron.ietf.org; Fri, 12 Nov 2004 03:43: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 DAA10573 for ; Fri, 12 Nov 2004 03:43:49 -0500 (EST) Received: from tripoli.ucdavis.edu ([169.237.104.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSX3Q-0002Ss-Te for nemo@ietf.org; Fri, 12 Nov 2004 03:45:14 -0500 Received: from lymeon.ucdavis.edu (lymeon.ucdavis.edu [169.237.104.171]) by tripoli.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAC8gilm015636; Fri, 12 Nov 2004 00:42:45 -0800 (PST) Received: from lymeon.ucdavis.edu (localhost [127.0.0.1]) by lymeon.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAC8gi3k002298; Fri, 12 Nov 2004 00:42:44 -0800 (PST) Received: (from www@localhost) by lymeon.ucdavis.edu (8.12.10/8.12.9/Submit) id iAC8gbum002297; Fri, 12 Nov 2004 00:42:37 -0800 (PST) Date: Fri, 12 Nov 2004 00:42:37 -0800 (PST) Message-Id: <200411120842.iAC8gbum002297@lymeon.ucdavis.edu> To: "Pascal Thubert (pthubert)" , Chan-Wah NG , Alexandru Petrescu Subject: RE: [nemo]RO taxonomy From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [64.8.195.10] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MathPlayer 2.0) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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 > So I have questions for the WG: > > Q1 Should we split? It is OK for me to put problem statement and solution space analysis in one document. > Q2 Is the doc fair enough WRT possible approaches? The solution space analysis should be complete. Please see my other emails. > Q3 And BTW did we miss any? You might miss some new solutions. Please see my slides. As the result is still preliminary, it might be too early to talk about it. Sincerely, fan > > Unless they are so pervasive that it can not be fixed, I suggest we fix > whichever partiality issues is found (if any), incorporate the relevant > text from the other drafts (mostly the MANET aspect that was really > understated) and propose the doc again for WG consideration, either on > one or 2 pieces. > > Pascal > > > -----Original Message----- > > From: Chan-Wah NG [mailto:cwng@psl.com.sg] > > Sent: jeudi 11 novembre 2004 23:52 > > To: Alexandru Petrescu > > Cc: Pascal Thubert (pthubert); IETF NEMO WG; Vijay Devarapalli; Ville > Nuorvala; Erik Nordmark > > Subject: Re: (was Re: Multiple address in RH type 2, now back to:) > [nemo]RO taxonomy > > > > Hello Alex, > > > > Thank you for reading the draft immediately after the WG session, and > I > > appreciate you comments. It is these comments that allow us to > improve > > our work. > > > > If I recall, you were the one who referred us to the WG charter. > > Contents of version -03 of the ro-taxonomy draft is exactly tailored > > according to what is spelt out in the WG charter. (Unless the WG > charter > > is once again changed and I wasn't aware of ....) > > > > Now people are complaining the draft is too long. > > > > >From the WG charter, we are not required to come up with a *short* > > problem statement draft. We are, however, required to come up with a > > *detailed* problem statement *and* looks at various approaches to > > solving the problem. > > > > I am not against a concise problem statement draft that is short and > > sweet. I like that too. In fact, I would say that the problem > > statement section of the draft-ro-taxonomy is quite short (3-5 pages, > as > > you and Hesham suggested). If the WG changes the charter to reflect > > that, I will gladly copy and paste the appropriate sections from > > ro-taxonomy-03.txt to a new short problem statement draft. > > > > However, IMHO, we should not remove the WG charter on coming up with > an > > informational document on ro solution space analysis. It is a useful > > document that records the WG experiences on the route optimization > > solution space. If the WG wants a short problem statement draft, then > > let's have a WG problem statement draft *and* a WG > > solution-space-analysis draft. > > > > About your last comment on secuirty risks, I agree we should have a > > general security consdierations text that is not solution-space > > specific. I will add this in -04. But, I will not remove the > security > > risks discussions specific to each approach. Again, as pointed out by > > the WG charter (the charter that I know of, anyway): "security > > considerations for the various approaches will also be considered". > > > > /rgds > > /cwng > > > > On Thu, 2004-11-11 at 23:56, Alexandru Petrescu wrote: > > > Pascal Thubert (pthubert) wrote: > > > > The world did not freeze the day NEMO as a WG decided to focus on > > > > basic. > > > > > > Oh didn't it :-) > > > > > > > We as a WG could afford some catching now. In fact, that is one > goal > > > > if the taxonomy draft, and dismissing that could be a huge waste. > > > > > > Pascal, the taxonomy draft-03 is a nice piece of work. I had a > detalied > > > look over it yesterday and wanted to make a detalied review later, > but > > > since you talk about it now, may I give high-level remarks. > > > > > > The WG item on problem statement is good to be short 3-5 pages IMHO. > > > How about deciding in advance about the max number of pages and > stick > > > to that. > > > > > > The current draft could be shortened by removing entirely the > > > comparative analysis of the various solutions, maybe that could be a > > > separate draft. IMHO only the abstract and the 1st section are > exactly > > > problem statement. > > > > > > If this is done, then it is no longer a "taxonomy" draft, it becomes > > > more of a "problem statement" draft. > > > > > > The draft could be further shortened by reducing the big > > > encapsulation/long path illustrations from 3 MR's to 2. IT is > enough > > > for a reader to interpret the meaning of it by just using 1 and 2 > > > example MR's. The logical extension from one and two to $n$ > happens in > > > the reader's mind as easy as the extension from one and two and > three to > > > $n$ and the description is shorter if only two MR's. This reduction > > > also reduces the risk of introducing spec errors. Such an error is > > > already there: HAofMR5 is talked about but not pictured; instead MR6 > is > > > pictured but not talked about. > > > > > > Second, there is a specific problem of NEMO Basic Support named > > > "cross-over" tunnels, mentioned at http://tinyurl.com/4z4kc see > Section > > > B.6; there it is shown how a specific mobility configuration (HA in > the > > > moving network and moving networks exchanging their positions) is > not > > > supported by NEMO BAsic Support. I see this mobility configuration > > > problem as an important problem on the protocol itself, I mean the > > > protocol does not support such a configuration. In addition, there > may > > > be other similar mobility configurations that are not supported by > NEMO > > > Basic Support. > > > > > > Finally, about the current draft taxonomy 03 and Security > > > Considerations. There are important Security problems when > discussing > > > RO for NEMO; at the same time many security aspects of various > solutions > > > have been discussed, but I'd keep these out of this document. In > the WG > > > RO item I'd only mention a unique Security Considerations section > that > > > only says what are the security risks of having a prefix at CN. Not > to > > > say the draft does not do it, but that the draft has too many > security > > > risks described, each attach to a single solution; it's too > scattered. > > > > > > Alex > > > From nemo-bounces@ietf.org Fri Nov 12 06:09:29 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 GAA20154 for ; Fri, 12 Nov 2004 06:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSZHX-0005Vw-Gz; Fri, 12 Nov 2004 06:07:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSZH6-0005PS-KP for nemo@megatron.ietf.org; Fri, 12 Nov 2004 06:07: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 GAA20062 for ; Fri, 12 Nov 2004 06:07:25 -0500 (EST) Received: from s-utl01-dcpop.stsn.com ([63.240.218.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSZIS-0005BL-Lu for nemo@ietf.org; Fri, 12 Nov 2004 06:08:53 -0500 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004111206072418601 for ; Fri, 12 Nov 2004 06:07:24 -0500 Received: from mozart.psl.com.sg ([10.67.86.196]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Nov 2004 06:07:24 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 5DFCED963E; Fri, 12 Nov 2004 19:17:13 +0800 (SGT) Subject: Re: [nemo] What kind of NEMO RO problem WG document we would like to see From: Chan-Wah NG To: Fan Zhao In-Reply-To: <200411120705.iAC75dWp029072@lymeon.ucdavis.edu> References: <200411120705.iAC75dWp029072@lymeon.ucdavis.edu> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Fri, 12 Nov 2004 19:17:12 +0800 Message-Id: <1100258232.6292.46.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2004 11:07:24.0737 (UTC) FILETIME=[CA00F310:01C4C8A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Fan, On Thu, 2004-11-11 at 23:05 -0800, Fan Zhao wrote: > IMHO, draft-thubert-nemo-ro-taxonomy-03 is far from what NEMO RO problem > Wg document > should be. (Sorry, Pascal and Chan-Wah, please see the following text and > my another > email about comments on your solution space analysis part.) Don't have to be sorry, you are entitled to your own opinion. > > I feel at this moment WG should consider What > kind of NEMO RO problem WG document we would like to see rather than > which > draft should be picked as the WG item. Once we reach the consensus on > that, > we can go back to see if any existing draft meets or is close to meet our > needs > then it can become WG document without question, otherwise if there is no > one, > we have to work on the new document that we want to see. We already have > four > NEMo RO problem related drafts that all are good inputs to the WG > document. > It is inefficient if we spend the duplicate efforts on the same subject. > I agree with you ... partially. Without setting up a new WG document, your proposal on first listing the contents and structure of the WG document will ultimately lead to all authors of the four drafts submitting four different drafts based on the same contents and structure, ... and that is a duplicate of effort. It is not necessary a bad thing, since that way, it is easier to merge all 4 drafts. I am just saying that your point on less/no duplicate efforts is unlikely to happen. > Below is my vision about NEMO RO problem WG document: As I mentioned, you are welcomed to describe your opinions, but ultimately, we must use the WG charter as the guideline to be adhered to. So, in general, I agree with your list, until those parts that are not in agreement to what the current charter states. > 1. NEMO RO problem draft should be written in an abstract way rather than > solution-specific. > (from calos's email on the ML if I am not wrong.) > 2. It does not matter how many pages the problem statement part should > be, but it must be > to the core of the problem. > 3. The solution "space" analysis part must not just simply list the > previouly proposed > > solutions. > 4. It should be able to analyze the complete solution space including the > proposed and the new ones. (The completeness should be assured in certain > level.) > 5. The method to categorize the solution space must be able to make one > category not > intersect with any other category (mutual exclusive). That may be desirable, but difficult to achieve. It runs the risk of being in conflict with your point #4 above. To strictly demand mutual exclusiveness will often leads to incompleteness. To me, having mutual exclusive approach is only something that is preferable, but not of high priority. Instead it is the completeness that we should try to achieve. (Your choice of words "should" in #4 and "must" in #5 seems to indicate you felt otherwise). What advantages does mutual exclusive solution space partitioning gives us? > > 6. The solution space analysis does not judge on the strength and > weakness of each solution. An analysis should try to be as objective as possible. That goes without saying. But what is the use of an analysis if it does not points out the relative strength and weakness of each approach? (I prefer to use the term 'approach' rather than 'solution', as the latter can often be interpreted as the 'solution described in draft-foo-bar-xx.txt'). Instead, I think what you are trying to say is that the analysis should not try to steer readers into thinking one approach is better than the other. The best way to ahieve this is for it to list the weakness and strength of each approach. True, the initial version of that analysis may reflect only the views of the author, and seems not impartial. But through peer reviews, we would ultimately leads to a piece of analysis to reflect the true streangth and weakness of an approach. > 7. The security analysis should be general rather than being solution- > specific. Also it > > should be easy to apply to each solution. Nope. Not according to the WG charter. There should be a general security consideration section that will applies to most (if not all) approaches, that I agree. But why insisting on no security consideration for specific approach puzzles me. > 8. The solution space analysis part must focus on the core idea because > there could be an infinite number of solutions that are in the different > forms. > You then run into the danger of being too vague. There is a reason why different solutions are being proposed that seems to carry the same core idea. Often, this occurs because one proposal improves some small deficencies of a previous proposal (while at the same time containing new deficiencies). It is through documenting these subtle differences that we would be documenting the WG's experiecne on route optimization. > Your comments are very welcomed. > Oh, you will definitely get my comments once I get back to my own time-zone. Can't think critically with a highly-caffinated mind .... ;) /rgds /cwng From nemo-bounces@ietf.org Fri Nov 12 06:47:39 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 GAA22546 for ; Fri, 12 Nov 2004 06:47:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSZsV-0002rI-4j; Fri, 12 Nov 2004 06:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSZqw-0002eW-U5 for nemo@megatron.ietf.org; Fri, 12 Nov 2004 06:44:31 -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 GAA22322 for ; Fri, 12 Nov 2004 06:44:27 -0500 (EST) Received: from s-utl01-dcpop.stsn.com ([63.240.218.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSZsG-0005pL-1P for nemo@ietf.org; Fri, 12 Nov 2004 06:45:55 -0500 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004111206442531032 for ; Fri, 12 Nov 2004 06:44:25 -0500 Received: from mozart.psl.com.sg ([10.67.86.196]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Nov 2004 06:44:26 -0500 Received: from localhost (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id 3C43ED963E; Fri, 12 Nov 2004 19:54:50 +0800 (SGT) Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft From: Chan-Wah NG To: Fan Zhao In-Reply-To: <200411120709.iAC79KKi006578@tremex.ucdavis.edu> References: <200411120709.iAC79KKi006578@tremex.ucdavis.edu> Content-Type: text/plain Organization: Panasonic Singapore Labs Date: Fri, 12 Nov 2004 19:54:49 +0800 Message-Id: <1100260489.6293.84.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2004 11:44:26.0317 (UTC) FILETIME=[F62B27D0:01C4C8AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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 On Thu, 2004-11-11 at 23:09 -0800, Fan Zhao wrote: > Dear Pascal and Chan-Wah, > > I have some comments on the draft-thubert-nemo-ro-taxonomy-03. > I will focus on solution space analysis part as we already have > discussed on the problem statement part before. > > Section 3. Solution Space of NEMO Route Optimization > "Shorter Delay", "Reduced Consumption of Overall Network Resources", > "Less Susceptibility to Link Failure", "Greater Data Efficiency" > are the benefits of RO, which should be in the problem statement part, > but not > in the solution space analysis part. > Sure, we could have just created a new "benefits of RO" section. > " There are multiple proposals for providing various forms of route > optimizations for NEMO (see Appendix A). " > Please delete the appendix. As some proposals are incomplete, even some > does not work. What's more, some proposals look different but actually > using > the same core idea. Perhaps, but that is not up to us to judge. The readers have to decide for themselves whether the individual proposals work or not. An appendix is an appendix. It is something that you could do without. I view the work done on ro-taxonomy-03.txt as a survey/review of what is the current state of RO solutions, and it felt incomplete without reference to all the proposals that have been made. > > "3.1 MR-to-CN Optimization" "3.2 Infrastructure Optimization" > "3.3 Nested Tunnels Optimization" "3.4 MIPv6-over-NEMO Optimization" > "3.5 Intra-NEMO Optimization" > The solution space analysis part is organized like in the problem > statement part > to me. I do not see any logic behind the way you use to categorize the > solution space. > Remember that the different problem scenarios do not mean the different > solutions (core ideas). > > "Binding Update with Network Prefix" and "MR as a Proxy" use the same > idea to me and are > described in a too specific way. > Same idea? Are you sure? They may be solving the same problem (which is why we put them into the same "MR-to-CN" optimization, but they are entirely different. The former requires the MR to send prefix information to CN, the latter requires the MR to pretend to be the MNN. The core idea is quite different to me. > "Infrastructure Optimization" I do not understand why "MR-to-CN > optimization" does not > possibly fall into this category. > Because it doesn't. Infrastructure optimization means some third party entity in the infrastructure takes part in the optimization. > "Nested Tunnels Optimization" > "Nested tunnels" is not the core of nemo ro problem and it > sounds too specific too. It could make one reader wonder why other tunnel- > reduction > methods are not listed. > Nested tunnel optimization is to reduce tunnel ... what other tunnel-reduction method you have in mind that does not fit into the descriptions of nested tunnel optimizations? > "MIPv6-over-NEMO Optimization" > A lot of duplications for me. > Perhaps. > 4. Analysis of Solution Space > > 4.1 General Considerations of RO Solution > The content describes the tradeoffs similar with the section of "the > related tradeoffs" > in the draft-zhao-nemo-ro-ps-00.txt. :-) Our draft also has other > tradeoffs. > True, that's an area where we can supplement each other. > 4.1.1 Additional Signaling Overhead > The text of BU sould specific to me. The text of BU storm should belong > to problem statement > part. > problem statement? Why? It is not a problem of NEMO Basic Support. It is a potential problem certain RO approaches might face. > 4.1.2 Increased Protocol Complexity > I understand your point. However it seems to me the scalability issue has > more impacts on > power and processing resources than the protocol complexity. Thank you for pointing out that, I will reflect that on the next update. > > 4.1.3 Mobility Awareness > "it will be difficult for mobile network nodes to control the decision of > having > this tradeoff" > > Is that also the case for VMN? > Now you are going into approach specific area. In the general considerations, we just list out issues that in general an approach might have to overcome. > 4.1.4 New Functionalities > "Correspondent Nodes > It is generally undesirable for correspondent nodes to be required > to implement new functionalities." > > I do not agree. It depends on the type of CN. > Perhaps. I tend to believe that the statement reflect what most people feel. I might update the text to show that it depends on the type of CN. > 4.1.5 Other Considerations > If you think they are not "tradeoff", they should not be under this > section. > Why not? I did not say section 4.1 is a trade-off discussion section. > 4.2 Specific Types of RO Solution > "Many of the tradeoffs discussed previously in Section 4.2 are > dependent on the actual route optimization approach." > Please give an example that one solution does not have one of the > tradeoffs above. > If there is one, your discussion about tradeoff is not general. You applied too strictly an interpretation of the meaning of "general". > > Some text seems like a evaluation to me. I recall one email on the ML > before > states that the problem draft should not judge on the quality of the > solution. Perhaps, I am sorry if I give the impression of 'judging the quality of the' approach (again, I prefer to use the term approach rather than solution). It is not my intention. > There are a lot of redundency too because of the way the draft used to > categorize the > solution space. Perhaps, but I would like to see a different categorization that is (a) mutually exclusive, (b) complete, and (c) useful. For me, the prioirty is in the revese order ... a catgorization scheme should first be useful, and then strive to be complete, and finally preferably with minimal duplication. > I prefer a general security consideration also. > Me too, and I have already promised a general security consideration section in my previous posts. > Overall, the solution space part does not analyze the space completely and > does not categorize the solution space into mutual exclusive categories. As I've mentioned, I strive to be complete, and not mutually exclusive. My feeling is that we are very close to a complete description, once we feel in the parts on MANET as an RO appraoch. /rgds /cwng From nemo-bounces@ietf.org Fri Nov 12 08:53:35 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 IAA02745 for ; Fri, 12 Nov 2004 08:53: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 1CSbnU-0005Qw-LZ; Fri, 12 Nov 2004 08:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSbgF-00046k-7u for nemo@megatron.ietf.org; Fri, 12 Nov 2004 08:41: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 IAA01881 for ; Fri, 12 Nov 2004 08:41:33 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSbhc-0008Vx-0T for nemo@ietf.org; Fri, 12 Nov 2004 08:43:01 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Nov 2004 15:03:25 +0100 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 iACDeluS026566; Fri, 12 Nov 2004 14:40:59 +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.0); Fri, 12 Nov 2004 14:40:25 +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] What kind of NEMO RO problem WG document we would like to see Date: Fri, 12 Nov 2004 14:40:17 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC451D02@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] What kind of NEMO RO problem WG document we would like to see Thread-Index: AcTIhwzWETE80CebSuat2Gpf23x7gwAL86wg From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , X-OriginalArrivalTime: 12 Nov 2004 13:40:25.0261 (UTC) FILETIME=[2A05BDD0:01C4C8BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 >=20 > Dear NEMO WG members, >=20 > IMHO, draft-thubert-nemo-ro-taxonomy-03 is far from what NEMO RO problem > Wg document > should be. (Sorry, Pascal and Chan-Wah, please see the following text and > my another > email about comments on your solution space analysis part.) >=20 > I feel at this moment WG should consider What > kind of NEMO RO problem WG document we would like to see rather than > which > draft should be picked as the WG item. Once we reach the consensus on > that, > we can go back to see if any existing draft meets or is close to meet our > needs > then it can become WG document without question, otherwise if there is no > one, > we have to work on the new document that we want to see. We already have > four > NEMo RO problem related drafts that all are good inputs to the WG > document. > It is inefficient if we spend the duplicate efforts on the same subject. >=20 > Below is my vision about NEMO RO problem WG document: > 1. NEMO RO problem draft should be written in an abstract way rather than > solution-specific. > (from calos's email on the ML if I am not wrong.) Yes, I do not think we are in contradiction here, are we? This is why we moved solutions to appendix. Like the bibliography, it's a tentative for additional help and time saving to the reader. > 2. It does not matter how many pages the problem statement part should > be, but it must be > to the core of the problem. I'm not sure that there is A problem to be singled out. Otherwise, there's a lot of space between one liners and a book. One liners might tend to be opaque and books could cause endless controversies because there's always a sentence here or a word there that's not perfect, while the core content could be diluted. I tend to agree that a reasonably short text is what we need here to get a correct understanding and yet reach consensus: Facts, but no literature. > 3. The solution "space" analysis part must not just simply list the > previouly proposed solutions. Looks nice, but what's the limit? The imagination of the WG, maybe?=20 Basically, all the domains that we as a group could think off and was willing to share was more or less explored in the last 2-3 years, in the form of solution proposals, and somewhat discussed already on the ML; this gave us some ground for the pro/cons/tradeoffs/applicability discussion. This is why the solution space that we explore looks like the space of existing proposals made a bit more abstract. But that's a consequence, not a goal. The taxonomy draft has been there for 2 years for the ML to comment and propose additions. We received help from academic, ISP and corporate people. If you see some space that was not covered please speak up. It will be added if there's a rough consensus that it makes any sense. But I do not see benefits in starting it all over. > 4. It should be able to analyze the complete solution space including the > proposed and the new ones. (The completeness should be assured in certain > level.) The problem is that we do not not what's not invented yet. A WG doc is a state of the art and of the understanding of a WG at the time of its publication. Does not mean it's forever perfect. Does NOT aim at LIMITING the acceptable solution to a given space, either. But rather at helping the thought / creation process and saving newcomers time. Long as it's a draft, we are ready to add novelty anytime. Thomas' draft showed us that we did not treat MANET in a fair enough fashion. Good! We are working together on improving things, we'll add MANET text in the next issue, and this started an interesting discussion on the comparison of LMM and MANET based approaches, as they seem to provide similar benefits. > 5. The method to categorize the solution space must be able to make one > category not > intersect with any other category (mutual exclusive). Yes, that would be nice. Making a single category achieves that. But might leave things out. I understand your proposition like let's make a document that shows the solution space of everything yet to be invented, and then partition it in non overlapping categories. There are names like GRAAL for that sort of things; the rest of us do what we can in the time frame we have. I read your draft and I liked it very much. IMHO, it's a good start, we must keep it and build on it. The way I read it, I found it relevant as a foudation for a requirement draft more then a problem statement. We are not there already, since we did not recharter or anything.=20 On the to-be-discussed side, some things were a bit cryptic to me, like the reason why you discuss the data-plane method thing, and why you want to formalize the nested NEMO in a PS draft. Also, I'm not sure we want to mix RO and multihoming (the DAG thing). > 6. The solution space analysis does not judge on the strength and > weakness of each solution. We disagree here (I have to disagree somewhere ain't it true?). I see the PS/solution space draft as a tool, not as a limiting boundary (as opposed to the requirements will be specifying what we have to cover). I believe that the pro/cons/tradeoffs/applicability discussion is at the core of the value of that tool. > 7. The security analysis should be general rather than being solution- > specific. Also it should be easy to apply to each solution. You might want to list of the threats in the world in a separate chapter, or maybe in an encyclopedia. But the problems to be addressed are inherent to the solution space. Examples in the nested nemo case: trust in MANET approach, MITM/Time-shifting attacks in MR-proxy, etc... > 8. The solution space analysis part must focus on the core idea because > there could be an infinite number of solutions that are in the different > forms. We did not find them all, then :) But yes, we tried to abstract things and leave the specifics to the solution drafts in reference and eventually appendix. The only solution that we really detail is Erik's text on proxy. The reason is that it's very educational. Again, this is a tool, not a book of law. > We also have to think about the content of WG document. >=20 And word your thoughts to the ML :) Pascal From nemo-bounces@ietf.org Fri Nov 12 09:42:54 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 JAA07322 for ; Fri, 12 Nov 2004 09:42:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScU1-0008NV-QT; Fri, 12 Nov 2004 09:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScNw-0006qU-Fm for nemo@megatron.ietf.org; Fri, 12 Nov 2004 09:26:44 -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 JAA05839 for ; Fri, 12 Nov 2004 09:26:42 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScPH-0001AO-EO for nemo@ietf.org; Fri, 12 Nov 2004 09:28:10 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Nov 2004 15:48:33 +0100 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 iACEPfui006819; Fri, 12 Nov 2004 15:26:06 +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.0); Fri, 12 Nov 2004 15:26:01 +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] RO: what have we learnt so far? Date: Fri, 12 Nov 2004 15:25:58 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC451D38@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RO: what have we learnt so far? Thread-Index: AcTF4vBK5XLJdg4RTMaSOk4JkE133QC3hN4g From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 12 Nov 2004 14:26:01.0834 (UTC) FILETIME=[8925A4A0:01C4C8C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Ryuji Wakikawa 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: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: lundi 8 novembre 2004 23:33 > To: Pascal Thubert (pthubert) > Cc: IETF NEMO WG > Subject: Re: [nemo] RO: what have we learnt so far? >=20 > Pascal Thubert (pthubert) wrote: > > - We have found that before optimizing the tunnels and data path of a > > nested tree of MRs, we should make sure that we build the tree and > > that the tree is optimized in shape in the first place. >=20 > Pascal, do we agree that, in a nested aggregation of moving networks, > they can form _any_ arbitrary graph and that the "tree" you mention is > more about the logical view that is formed when looking for shortest > paths, and less about how the MR's hardware-ly link to each other? Do > we agree that there may be no actual tree other than in the mind of the > human describing how the shortest paths are built? Do we agree that > every MR may have its own limited view of the network (which view may be > a tree) and that this view has nothing to do with the physical hardware > topology on which this _spanning_ tree is built? YES > > We also know that a MR might not want to attach anywhere and that > > some clues might be needed. >=20 > MR selecting its attachment point is very much like CARD - Candidate > Access Router Discovery. I don't think MR is different than MH when > needing to attach, and selecting a better or a worse AR based on > synchronized information that those AR's may broadcast. Yes. Making MH aware of a Nested NEMO or a mesh could improve the overall operation. > I don't think MR's need take care when attaching such as to ensure they > form a tree. I think they should attach to wherever they can attach > first, with as many interfaces as they can. After attaching, I think > they should exchange information to each other, and propagate the > similar information received from other similar MR's. Once all this > information is propagated, every MR may build tables with its own > logical view of the network, and find paths with the help of these tables. How many interfaces (radios?) do you think the MR has? As many as adjacent MRs? If that was so, then yes, they can form a MANET, and if that MANET provides a default route out, we are done. We will improve the RO taxonomy draft to describe that.=20 You might see TD as a specific MANET, very fast because it's dedicated to the default route.=20 But actually, the MR MIGHT NOT have enough interfaces. If so, attaching the radio to the right AP(s) might be critical. >=20 > Do you think this is wrong? I think it was based on inadequate assumptions. > > We can not just make as if we were 3 years ago, can we? I believe > > that we can and we should give more food for thought then just > > "what's the problem here?". >=20 > "Tree Discovery" as is now forces the forming of an aggregation of > moving networks that MUST have the physical link of a tree. This is > simply not scalable for a network. You seem to be mixing problems here. TD does not cover internal RO within the nested nemo. The tree comes from the fact that at the moment, NEMO forms a single primary CareOf address, so the NEMO nested structure IS A TREE. When we have more then one CoA, we'll build overlapping trees, forming a DAG, as FAN explains in PS draft, when they all exit at the same root.=20 > So while "Tree Discovery" may solve a problem that is important, it may > itself introduce much bigger problems than it actually solves. >=20 > Am I wrong somewhere? And of course we can discuss this also > face-to-face here. >=20 I think that THIS discussion is relevant on the ML. I do not understand from your text that TD introduces any problem. NEMO MRs have to form a tree, it's not TD's fault. Pascal From nemo-bounces@ietf.org Fri Nov 12 10:07:03 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 KAA09586 for ; Fri, 12 Nov 2004 10:07: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 1CScsd-0005bH-30; Fri, 12 Nov 2004 09:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSclR-0003dr-Sl for nemo@megatron.ietf.org; Fri, 12 Nov 2004 09:51: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 JAA07883 for ; Fri, 12 Nov 2004 09:50:59 -0500 (EST) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScmp-0001li-Ah for nemo@ietf.org; Fri, 12 Nov 2004 09:52:28 -0500 Received: from trust ([130.129.135.30]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id iACErG9M026350; Fri, 12 Nov 2004 23:53:17 +0900 (KST) (envelope-from eun@mmlab.snu.ac.kr) Message-Id: <200411121453.iACErG9M026350@mmlab.snu.ac.kr> From: "Eun Kyoung PAIK" To: "'Chan-Wah NG'" , "'Fan Zhao'" Subject: RE: [nemo] What kind of NEMO RO problem WG document we would liketo see Date: Fri, 12 Nov 2004 23:50:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTIqJYC400mD55fTza9zg1is+uM7gAG/xwA In-Reply-To: <1100258232.6292.46.camel@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Hi Fan and all, Please see in line comments. > > 6. The solution space analysis does not judge on the strength and > > weakness of each solution. > > An analysis should try to be as objective as possible. That goes > without saying. But what is the use of an analysis if it does not > points out the relative strength and weakness of each approach? (I > prefer to use the term 'approach' rather than 'solution', as the latter > can often be interpreted as the 'solution described in > draft-foo-bar-xx.txt'). Instead, I think what you are trying to say is > that the analysis should not try to steer readers into thinking one > approach is better than the other. The best way to ahieve this is for > it to list the weakness and strength of each approach. True, the > initial version of that analysis may reflect only the views of the > author, and seems not impartial. But through peer reviews, we would > ultimately leads to a piece of analysis to reflect the true streangth > and weakness of an approach. I also think that the list of the weakness and strength of each approach support is useful in this draft, since this draft is for problem statement (not for requirements). > > 7. The security analysis should be general rather than being solution- > > specific. Also it > > should be easy to apply to each solution. > > Nope. Not according to the WG charter. There should be a general > security consideration section that will applies to most (if not all) > approaches, that I agree. But why insisting on no security > consideration for specific approach puzzles me. As Pascal commented, let's distinguish the term 'solution' and 'approach'. This draft is not supposed to analyze security in terms of any specific solution (draft-xx-.txt), but will consider security with the various approaches (as stated in NEMO WG charter). Regards, Eun From nemo-bounces@ietf.org Fri Nov 12 10:08:14 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 KAA09763 for ; Fri, 12 Nov 2004 10:08:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScsu-0005es-SD; Fri, 12 Nov 2004 09:58:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScn9-00044E-2J for nemo@megatron.ietf.org; Fri, 12 Nov 2004 09:52:47 -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 JAA08031 for ; Fri, 12 Nov 2004 09:52:44 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScoW-0001na-GN for nemo@ietf.org; Fri, 12 Nov 2004 09:54:13 -0500 Received: from iseran.local (unknown [130.129.132.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6609D4C0AA for ; Fri, 12 Nov 2004 23:52:11 +0900 (JST) Date: Fri, 12 Nov 2004 23:54:56 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] The correct url of slides Message-Id: <20041112235456.69e9a021.ernst@sfc.wide.ad.jp> In-Reply-To: <200411120717.iAC7HhO0013997@syrphus.ucdavis.edu> References: <200411120717.iAC7HhO0013997@syrphus.ucdavis.edu> 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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Fan, all presentation materials are located, as always, on the NEMO web page (http://www.mobilenetworks.org/nemo/ietf61) Thierry. On Thu, 11 Nov 2004 23:17:43 -0800 (PST) "Fan Zhao" wrote: > > Dear all, > > Sorry, the url for my presentation is > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ietf61.ppt. From nemo-bounces@ietf.org Fri Nov 12 10:12:53 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 KAA10622 for ; Fri, 12 Nov 2004 10:12: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 1CSd4R-0003Tc-Lr; Fri, 12 Nov 2004 10:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScxa-0000Af-CC for nemo@megatron.ietf.org; Fri, 12 Nov 2004 10:03: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 KAA09087 for ; Fri, 12 Nov 2004 10:03:31 -0500 (EST) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScyv-00023J-0Z for nemo@ietf.org; Fri, 12 Nov 2004 10:05:00 -0500 Received: from mmlab.snu.ac.kr (localhost.snu.ac.kr [127.0.0.1]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id iACF5q9M026618; Sat, 13 Nov 2004 00:05:52 +0900 (KST) (envelope-from eun@mmlab.snu.ac.kr) Received: (from eun@localhost) by mmlab.snu.ac.kr (8.12.10/8.12.10/Submit) id iACF5nxX026617; Sat, 13 Nov 2004 00:05:49 +0900 (KST) (envelope-from eun) Date: Sat, 13 Nov 2004 00:05:49 +0900 From: "E.K. Paik" To: Chan-Wah NG Subject: Re: [nemo] What kind of NEMO RO problem WG document we would like to see Message-ID: <20041112150549.GA26546@mmlab.snu.ac.kr> References: <200411120705.iAC75dWp029072@lymeon.ucdavis.edu> <1100258232.6292.46.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <1100258232.6292.46.camel@localhost> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Hi Fan and all, Please see in line comments. > > 6. The solution space analysis does not judge on the strength and > > weakness of each solution. > > An analysis should try to be as objective as possible. That goes > without saying. But what is the use of an analysis if it does not > points out the relative strength and weakness of each approach? (I > prefer to use the term 'approach' rather than 'solution', as the latter > can often be interpreted as the 'solution described in > draft-foo-bar-xx.txt'). Instead, I think what you are trying to say is > that the analysis should not try to steer readers into thinking one > approach is better than the other. The best way to ahieve this is for > it to list the weakness and strength of each approach. True, the > initial version of that analysis may reflect only the views of the > author, and seems not impartial. But through peer reviews, we would > ultimately leads to a piece of analysis to reflect the true streangth > and weakness of an approach. I also think that the list of the weakness and strength of each approach support is useful in this draft, since this draft is for problem statement (not for requirements). > > 7. The security analysis should be general rather than being solution- > > specific. Also it > > > > should be easy to apply to each solution. > > Nope. Not according to the WG charter. There should be a general > security consideration section that will applies to most (if not all) > approaches, that I agree. But why insisting on no security > consideration for specific approach puzzles me. As Pascal commented, let's distinguish the term 'solution' and 'approach'. This draft is not supposed to analyze security in terms of any specific solution (draft-xx-.txt), but will consider security with the various approaches (as stated in NEMO WG charter). Regards, Eun From nemo-bounces@ietf.org Fri Nov 12 10:52:39 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 KAA14268 for ; Fri, 12 Nov 2004 10:52:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdep-0005dc-Ja; Fri, 12 Nov 2004 10:48:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdPW-0001wI-OY for nemo@megatron.ietf.org; Fri, 12 Nov 2004 10:32: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 KAA12814 for ; Fri, 12 Nov 2004 10:32:24 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdQt-0002jg-6U for nemo@ietf.org; Fri, 12 Nov 2004 10:33:53 -0500 Received: from iseran.local (unknown [130.129.132.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1FDCB4C0AA for ; Sat, 13 Nov 2004 00:31:52 +0900 (JST) Date: Sat, 13 Nov 2004 00:34:29 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] What kind of NEMO RO problem WG document we would like to see Message-Id: <20041113003429.270e91a7.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC451D02@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC451D02@xmb-ams-337.emea.cisco.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: cd3fc8e909678b38737fc606dec187f0 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 Hi, > > 2. It does not matter how many pages the problem statement part should > > be, but it must be > > to the core of the problem. > > I'm not sure that there is A problem to be singled out. Otherwise, > there's a lot of space between one liners and a book. One liners might > tend to be opaque and books could cause endless controversies because > there's always a sentence here or a word there that's not perfect, while > the core content could be diluted. I tend to agree that a reasonably > short text is what we need here to get a correct understanding and yet > reach consensus: Facts, but no literature. I agree the problem is difficult to describe, but also, the more we look into solutions, the more we find problems .... So, IMHU, we should start by the 1st thing 1st. What's the problem if we don't have solutions i.e. what are the problem we want to solve (-> avoid multiple tunneling; avoid extremely sub-optimal routing, etc. More below). And then only, investigate the potentials issues causes by proposed solutions (note that I call this "issues" and not "problem" so that we can draw a line between the 2). BU Storm is such an issue, introduced by a specific type of solution. See more below under point 4. > > 3. The solution "space" analysis part must not just simply list the > > previouly proposed solutions. > > Looks nice, but what's the limit? The imagination of the WG, maybe? > > Basically, all the domains that we as a group could think off and was > willing to share was more or less explored in the last 2-3 years, in the > form of solution proposals, and somewhat discussed already on the ML; > this gave us some ground for the pro/cons/tradeoffs/applicability > discussion. This is why the solution space that we explore looks like > the space of existing proposals made a bit more abstract. But that's a > consequence, not a goal. > > The taxonomy draft has been there for 2 years for the ML to comment and > propose additions. We received help from academic, ISP and corporate > people. If you see some space that was not covered please speak up. It > will be added if there's a rough consensus that it makes any sense. But > I do not see benefits in starting it all over. I don't understand this thread as a "starting over". I rather understand it as making sure the expected contents of the WG draft. I think there is a divergence on what people think should be included, so let's speak about that, and not in a lengthy way, because we have some expertise on the topic, haven't we ? > > 4. It should be able to analyze the complete solution space including > the > > proposed and the new ones. (The completeness should be assured in > certain > > level.) > > The problem is that we do not not what's not invented yet. A WG doc is a > state of the art and of the understanding of a WG at the time of its > publication. Does not mean it's forever perfect. Does NOT aim at > LIMITING the acceptable solution to a given space, either. But rather at > helping the thought / creation process and saving newcomers time. I tend to agree with Pascal here, for 2 reasons: - there are other proposals that have been published in conferences and journals, but not submitted to the IETF - more proposals will be made But, all solutions don't address the same problems, and do we have a comprehensive view of what the problem is ? About problems, but me "BU storm" is a problem with a specific solution type in mind. I would call this problem as a "2nd level problems". On the other hand, the problem listed in draft-watari-nemo-nested-cn-00.txt are "1st levels problems". The draft is a starting point with no solutions in mind (it presents the problem from the NEMO Basic Support perspective). Any problem statement should start from there. According to me, 1st level problems are: - multiple encapsulation in nested networks - extremely sub-optimal routing - two VMNs in a NEMO cannot initiate communication if no tunnel is set up between root-MR and HA Is there other "1st level problems" ? > Long as it's a draft, we are ready to add novelty anytime. Thomas' draft > showed us that we did not treat MANET in a fair enough fashion. Good! We > are working together on improving things, we'll add MANET text in the > next issue, and this started an interesting discussion on the comparison > of LMM and MANET based approaches, as they seem to provide similar > benefits. Well, Pascal, this is a good intention, but don't you think that, from the other draft authors perspective, it may look like cutting the herb under their feet and making your draft a de facto WG doc ? Just wanted to point this out. > > 5. The method to categorize the solution space must be able to make > one > > category not > > intersect with any other category (mutual exclusive). > > Yes, that would be nice. Making a single category achieves that. But > might leave things out. I understand your proposition like let's make a > document that shows the solution space of everything yet to be invented, > and then partition it in non overlapping categories. There are names > like GRAAL for that sort of things; the rest of us do what we can in the > time frame we have. > > I read your draft and I liked it very much. IMHO, it's a good start, we > must keep it and build on it. The way I read it, I found it relevant as > a foudation for a requirement draft more then a problem statement. We > are not there already, since we did not recharter or anything. I tend to agree here too that requirements are too early at this stage, since we haven't decided to produce solutions for RO. > On the to-be-discussed side, some things were a bit cryptic to me, like > the reason why you discuss the data-plane method thing, and why you want > to formalize the nested NEMO in a PS draft. Also, I'm not sure we want > to mix RO and multihoming (the DAG thing). > > > 6. The solution space analysis does not judge on the strength and > > weakness of each solution. > > We disagree here (I have to disagree somewhere ain't it true?). I see > the PS/solution space draft as a tool, not as a limiting boundary (as > opposed to the requirements will be specifying what we have to cover). I > believe that the pro/cons/tradeoffs/applicability discussion is at the > core of the value of that tool. > > > > 7. The security analysis should be general rather than being solution- > > specific. Also it should be easy to apply to each solution. > > You might want to list of the threats in the world in a separate > chapter, or maybe in an encyclopedia. But the problems to be addressed > are inherent to the solution space. Examples in the nested nemo case: > trust in MANET approach, MITM/Time-shifting attacks in MR-proxy, etc... > > > > 8. The solution space analysis part must focus on the core idea > because > > there could be an infinite number of solutions that are in the > different > > forms. > > We did not find them all, then :) But yes, we tried to abstract things > and leave the specifics to the solution drafts in reference and > eventually appendix. The only solution that we really detail is Erik's > text on proxy. The reason is that it's very educational. Again, this is > a tool, not a book of law. > > > We also have to think about the content of WG document. > > > And word your thoughts to the ML :)\ Thierry. From nemo-bounces@ietf.org Fri Nov 12 11:46: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 LAA19236 for ; Fri, 12 Nov 2004 11:46: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 1CSeXe-0003BG-8N; Fri, 12 Nov 2004 11:44:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSePA-0001UI-9c for nemo@megatron.ietf.org; Fri, 12 Nov 2004 11:36: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 LAA18302 for ; Fri, 12 Nov 2004 11:36:05 -0500 (EST) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeQZ-0004GR-2A for nemo@ietf.org; Fri, 12 Nov 2004 11:37:36 -0500 Received: from trust ([130.129.135.30]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id iACGcN9M027949; Sat, 13 Nov 2004 01:38:24 +0900 (KST) (envelope-from eun@mmlab.snu.ac.kr) Message-Id: <200411121638.iACGcN9M027949@mmlab.snu.ac.kr> From: "Eun Kyoung PAIK" To: "'Christophe Janneteau'" , "'Chan-Wah NG'" Subject: RE: [nemo] Multihoming Issues To be Presented Wednesday Date: Sat, 13 Nov 2004 01:36:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTG3EegbBjnx+XKSFS7NHkFF2QZeQB9oWTg In-Reply-To: <419194A0.3020701@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 Hi Christophe, Thank you for your comments. Please see in line comments. > In section 2.1 (1,1,1): Single MR, Single HA, Single MNP > --------------------------------------------------------- > > The terminology draft (5.2) defines a multihomed MR as: > > "a router is > multihomed when it has several IPv6 addresses to choose between, i.e. > in the following cases when the MR is either: > > multi-prefixed: multiple prefixes are advertised on the link(s) a > MR's egress interface is attached to, or. > > multi-interfaced: the MR has multiple egress interfaces to choose > between, on the same link or not." > > While section 2 of multihoming draft defines a multihomed MR as: > > "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, or (iii) the MR is equipped with > multiple interfaces. In such a case, the MR would have a combination > of Home Address / Care-of Address pairs." > > ==> The two defition differs. There may be a need to update the > terminology draft to cover (i) as well. Actually, the meaning of each definition was the same, e.g. (i) and (ii) fall into 'multi-prefixed' case since MR's egress interface can attach to home/visited link. If readers are confusing, we can re-write them in the same manner. > > In addition 2.1 reads: > > "A bi-directional tunnel may be established between each pair of Home > Address / Care-of address if the MR is itself multihomed." > > This sentence is confusing in the case multiple prefixes are advertised > on the visited link but only one is advertised on the home link. Indeed: > - MR would be multihomed according to the definition, and has > multiple CoAs, but > - only 1 tunnel can be established at a time, between the unique HoA > and the selected CoA; because NEMO/MIP does not allow multiple CoAs to > be associated with a same HoA AFAIK. That's why we illustrate it as one of issues in this draft so that we need a/some solution(s) for it. :-) > ==> Sentence could be replaced with "A bi-directional tunnel may be > established for each Home Address of the MR if multiple prefixes are > advertised one the MR's home link." > > In 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP > -------------------------------------------------------- > " No assumptions are made on whether or not the HAs > belongs to the same administrative domain. However, the MRs > advertises the same MNP." > > ==> How can HAs from different administrative domains advertise routes > to the same MNP? Seems to me that the only possible scenario is the one > where all HAs are in the same domain. This is ackwonledged in 4.6 and > 4.11 but there may be a need for a ref to these sections in 2.7, to > avoid mislead the reader. > > In 3.1: > -------- > > For case "z=N: Multihomed mobile networks with multiple MNPs": > > "Example: a car with a prefix taken from home (personal traffic > transit on this prefix and is paid by the owner) and one that > belongs to the car manufacturer (maintenance traffic is paid by > the car-manufacturer). This will typically be a (1,1,n)." > > ==> In general I assume car manufacturer and personal ISP would be > different administrative domains, hence with different HAs. So the > example seems more like an (1,n,n) to me. Make sense. Usually, one scenario does not fall into only one configuration. > In 4.7 MR Synchronization > --------------------------- > "In the (n,*,n) case, a MR relaying the advertisement of the MNP > from another failed MR." > > ==> Do we really want that? Would it not be better to just let the > addresses die? We think it is one of the benefits of multihoming. > In 4.12 Nested Mobile Networks > ------------------------------- > "As such, a solution to prevent an infinite loop must be provided." > ==> An infinite loop of what? Motivation is unclear IMHO. An infinite loop of associating with mobile routers. > In A.1.2 Subscriber/Provider Model > ------------------------------------- > > "For the S/mP model, the following configurations are likely to be > deployed: > > o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single > MNP" > > ==> Same comment as for 2.7: 4.6 and 4.11 highlight issues of such > configurations, which makes them _not_ likely to be deployed IMHO. That's why we move it to the appendix. We want hear from WG and reach a consensus which scenario is more likely being deployed. > In A.2 Problem-Oriented Approach > ---------------------------------- > "o Shinkansen: Single MNP Advertised by MR(s) > > This is the case where one MNP is announced by different MRs. > This is equivalent to the case of z=n, i.e. the (1,*,n) mobile > network." > > ==> Should be (n,*,1), right? Right. :-) Regards, Eun From nemo-bounces@ietf.org Fri Nov 12 12:04: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 MAA20500 for ; Fri, 12 Nov 2004 12:04: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 1CSehZ-0005G5-In; Fri, 12 Nov 2004 11:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSeZi-0003sP-LS for nemo@megatron.ietf.org; Fri, 12 Nov 2004 11:47: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 LAA19260 for ; Fri, 12 Nov 2004 11:47:00 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeb8-0004Ud-6b for nemo@ietf.org; Fri, 12 Nov 2004 11:48:30 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Nov 2004 18:08:56 +0100 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 iACGk6uk008718; Fri, 12 Nov 2004 17:46:28 +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.0); Fri, 12 Nov 2004 17:46: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] What kind of NEMO RO problem WG document we would liketo see Date: Fri, 12 Nov 2004 17:46:13 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC451DF5@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] What kind of NEMO RO problem WG document we would liketo see Thread-Index: AcTIz6arIvKECCkHQ7uh3/E2CAY2ZgAARIhg From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , "nemo" X-OriginalArrivalTime: 12 Nov 2004 16:46:18.0328 (UTC) FILETIME=[21C4B580:01C4C8D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 Thierry :) >=20 > > > 2. It does not matter how many pages the problem statement part should > > > be, but it must be > > > to the core of the problem. > > > > I'm not sure that there is A problem to be singled out. Otherwise, > > there's a lot of space between one liners and a book. One liners might > > tend to be opaque and books could cause endless controversies because > > there's always a sentence here or a word there that's not perfect, while > > the core content could be diluted. I tend to agree that a reasonably > > short text is what we need here to get a correct understanding and yet > > reach consensus: Facts, but no literature. >=20 > I agree the problem is difficult to describe, but also, the more we look > into solutions, the more we find problems .... So, IMHU, we should > start by the 1st thing 1st. What's the problem if we don't have > solutions i.e. what are the problem we want to solve (-> avoid multiple > tunneling; avoid extremely sub-optimal routing, etc. More below). And > then only, investigate the potentials issues causes by proposed > solutions (note that I call this "issues" and not "problem" so that we > can draw a line between the 2). BU Storm is such an issue, introduced by > a specific type of solution. >=20 YES :) This is the exact structure of the doc. Part 1 is problem statement, then come the solution space and the issues (I'd rather say pro/con/tradeoffs) with the known approaches. The approaches are sorted out by applicability, which is imperfect since sometimes a solution could apply cross domain. But there are advantages on doing things that way; in particular, this form helps the reader structure out his understanding of a globally complex problem. > See more below under point 4. >=20 >=20 > > > 3. The solution "space" analysis part must not just simply list the > > > previouly proposed solutions. > > > > Looks nice, but what's the limit? The imagination of the WG, maybe? > > > > Basically, all the domains that we as a group could think off and was > > willing to share was more or less explored in the last 2-3 years, in the > > form of solution proposals, and somewhat discussed already on the ML; > > this gave us some ground for the pro/cons/tradeoffs/applicability > > discussion. This is why the solution space that we explore looks like > > the space of existing proposals made a bit more abstract. But that's a > > consequence, not a goal. > > > > The taxonomy draft has been there for 2 years for the ML to comment and > > propose additions. We received help from academic, ISP and corporate > > people. If you see some space that was not covered please speak up. It > > will be added if there's a rough consensus that it makes any sense. But > > I do not see benefits in starting it all over. >=20 > I don't understand this thread as a "starting over". I rather understand > it as making sure the expected contents of the WG draft. I think there > is a divergence on what people think should be included, so let's speak > about that, and not in a lengthy way, because we have some expertise on > the topic, haven't we ? Cool. We need to have a target date, though. >=20 > > > 4. It should be able to analyze the complete solution space including > > the > > > proposed and the new ones. (The completeness should be assured in > > certain > > > level.) > > > > The problem is that we do not not what's not invented yet. A WG doc is a > > state of the art and of the understanding of a WG at the time of its > > publication. Does not mean it's forever perfect. Does NOT aim at > > LIMITING the acceptable solution to a given space, either. But rather at > > helping the thought / creation process and saving newcomers time. >=20 > I tend to agree with Pascal here, for 2 reasons: > - there are other proposals that have been published in conferences and > journals, but not submitted to the IETF > - more proposals will be made >=20 > But, all solutions don't address the same problems, and do we have a > comprehensive view of what the problem is ? The PS aims at building that. We are beginning the WG draft, not finalizing it... We never know when we have a comprehensive view, do we? We do our best, the rest is hopeful thinking. Do you understand what I mean :?) >=20 > About problems, but me "BU storm" is a problem with a specific solution > type in mind. I would call this problem as a "2nd level problems". On > the other hand, the problem listed in draft-watari-nemo-nested-cn-00.txt > are "1st levels problems". The draft is a starting point with no > solutions in mind (it presents the problem from the NEMO Basic Support > perspective). Any problem statement should start from there. >=20 > According to me, 1st level problems are: > - multiple encapsulation in nested networks > - extremely sub-optimal routing > - two VMNs in a NEMO cannot initiate communication if no tunnel is set > up between root-MR and HA >=20 > Is there other "1st level problems" ? >=20 We add latency and fragmentation which you are not listing here, give it some context and structure... and it's all done in 4 pages. >=20 > > Long as it's a draft, we are ready to add novelty anytime. Thomas' draft > > showed us that we did not treat MANET in a fair enough fashion. Good! We > > are working together on improving things, we'll add MANET text in the > > next issue, and this started an interesting discussion on the comparison > > of LMM and MANET based approaches, as they seem to provide similar > > benefits. >=20 > Well, Pascal, this is a good intention, but don't you think that, from > the other draft authors perspective, it may look like cutting the herb > under their feet and making your draft a de facto WG doc ? Just wanted > to point this out. >=20 I'm not the one who proposed to use the taxonomy as base (in fact, it's Ryuji, who is a co-author of one of the alternate drafts). But there are reasons to do that. There's quite a bit of experience in there (it's v03 already)... and the more people describe what the WG draft should be, the more I see it converging on the exact reasons why the taxonomy draft has its current shape and content... Including this mail ;) So, whatever we say about the base of the WG doc, I expect it will not be very different from the taxonomy. As a consequence, we intend to keep improving it, and to offer it as our contribution to the WG doc we are ready and form an editorial group. Pascal From nemo-bounces@ietf.org Fri Nov 12 12:04:53 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 MAA20538 for ; Fri, 12 Nov 2004 12:04: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 1CSeha-0005Gf-2i; Fri, 12 Nov 2004 11:55:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSeZj-0003sl-HH for nemo@megatron.ietf.org; Fri, 12 Nov 2004 11:47: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 LAA19265 for ; Fri, 12 Nov 2004 11:47: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 1CSeb9-0004Ud-6C for nemo@ietf.org; Fri, 12 Nov 2004 11:48:31 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Nov 2004 18:09:15 +0100 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 iACGkauW008786; Fri, 12 Nov 2004 17:46:46 +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.0); Fri, 12 Nov 2004 17:46:39 +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] comments on solution space analysis part in taxonomy draft Date: Fri, 12 Nov 2004 17:46:36 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on solution space analysis part in taxonomy draft Thread-Index: AcTIrX8bkUr2wBnNQNS7VVRtood5CwAISvPg From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah NG" , "Fan Zhao" X-OriginalArrivalTime: 12 Nov 2004 16:46:39.0547 (UTC) FILETIME=[2E6A78B0:01C4C8D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 > > Overall, the solution space part does not analyze the space completely and > > does not categorize the solution space into mutual exclusive categories. >=20 > As I've mentioned, I strive to be complete, and not mutually exclusive. > My feeling is that we are very close to a complete description, once we > feel in the parts on MANET as an RO appraoch. >=20 Agreed. We have a little duplication and we can improve some of it. This is not last call yet, is it :?) We have been encouraging people to speak up if they think something is missing for quite some time. If the doc serves as source for the WG document, then maybe more people will feel encouraged to contribute even more to the discussion and propose additional content. That question was raised by the chairs and delayed because of accusations of partiality that now seem to be unfounded. On the ML, Fan expressed his opposition on some grounds that we are discussing currently.=20 As of now, I strongly feel the taxonomy draft is a good base and that the cost of starting over is not justified by the arguments that were produced and the alternates that were outlined.=20 Pascal From nemo-bounces@ietf.org Fri Nov 12 14:28:44 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 OAA04411 for ; Fri, 12 Nov 2004 14:28: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 1CSh4c-0000eX-K8; Fri, 12 Nov 2004 14:27:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSgzF-0007yi-Cr for nemo@megatron.ietf.org; Fri, 12 Nov 2004 14:21:33 -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 OAA03917 for ; Fri, 12 Nov 2004 14:21:31 -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 1CSh0g-0000BE-13 for nemo@ietf.org; Fri, 12 Nov 2004 14:23:02 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id D6F816218; Fri, 12 Nov 2004 11:20:49 -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 77161-08; Fri, 12 Nov 2004 11:20:48 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id ED9C36195; Fri, 12 Nov 2004 11:20:48 -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 111DE60F5; Fri, 12 Nov 2004 11:20:45 -0800 (PST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <012CAB80-34E0-11D9-8AE2-000A95DA08F2@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft Date: Fri, 12 Nov 2004 11:21:08 -0800 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Chan-Wah NG 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 Well, the concern is a valid one.. but it should only be raised by someone who has read the latest version of the draft. -TJ On Nov 12, 2004, at 8:46 AM, Pascal Thubert (pthubert) wrote: > That question was raised by the chairs and delayed because of > accusations of partiality that now seem to be unfounded. On the ML, Fan > expressed his opposition on some grounds that we are discussing > currently. From nemo-bounces@ietf.org Sun Nov 14 05:46:22 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 FAA27624 for ; Sun, 14 Nov 2004 05:46: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 1CTHmP-0006kF-VW; Sun, 14 Nov 2004 05:38:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTHee-0005gv-87 for nemo@megatron.ietf.org; Sun, 14 Nov 2004 05:30:44 -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 FAA26805 for ; Sun, 14 Nov 2004 05:30:41 -0500 (EST) Received: from berlin.ucdavis.edu ([169.237.104.158]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTHgP-0006nm-A2 for nemo@ietf.org; Sun, 14 Nov 2004 05:32:34 -0500 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by berlin.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAEAUcE4014564; Sun, 14 Nov 2004 02:30:38 -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 iAEAUbgb001790; Sun, 14 Nov 2004 02:30:37 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id iAEAUbpj001789; Sun, 14 Nov 2004 02:30:37 -0800 (PST) Date: Sun, 14 Nov 2004 02:30:37 -0800 (PST) Message-Id: <200411141030.iAEAUbpj001789@phaenicia.ucdavis.edu> To: Chan-Wah NG Subject: Re: [nemo] What kind of NEMO RO problem WG document we would like to see 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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 Hi Chan-Wah, Please see my reply in line. Thanks. Sincerely, fan > Hello Fan, > > > I feel at this moment WG should consider What > > kind of NEMO RO problem WG document we would like to see rather than > > which > > draft should be picked as the WG item. Once we reach the consensus on > > that, > > we can go back to see if any existing draft meets or is close to meet our > > needs > > then it can become WG document without question, otherwise if there is no > > one, > > we have to work on the new document that we want to see. We already have > > four > > NEMo RO problem related drafts that all are good inputs to the WG > > document. > > It is inefficient if we spend the duplicate efforts on the same subject. > > > > I agree with you ... partially. Without setting up a new WG document, > your proposal on first listing the contents and structure of the WG > document will ultimately lead to all authors of the four drafts > submitting four different drafts based on the same contents and > structure, ... and that is a duplicate of effort. > I agree to set up a new WG document. But we have to be careful to choose the base (if we decide to do that) otherwise we probably have to make modifications later again and agian. In this thread I want to focus on the high-level views about what NEMO RO WG document should be rather than the content and structure which should be the next stage. IMHO the problem statement part is quite well understood. But the solution space analysis part needs to be baked more. > It is not necessary a bad thing, since that way, it is easier to merge > all 4 drafts. I am just saying that your point on less/no duplicate > efforts is unlikely to happen. > > > > Below is my vision about NEMO RO problem WG document: > > As I mentioned, you are welcomed to describe your opinions, but > ultimately, we must use the WG charter as the guideline to be adhered > to. So, in general, I agree with your list, until those parts that are > not in agreement to what the current charter states. > Sure. I definitely agree that we have to adhere to the charter. But also remember the charter is made some time ago (I do not know when.) and we are keeping improving our understanding about NEMO RO since then. So let's adhere to the charter and don't forget to address the new issues and needs if necessary. Secondly, the charter defines the scope of work (problem statement, approach analysis, tradeoff and security consideration etc.) but there are ways and ways to do that. There is no doubt that different method generates the different quality of work. What I argue about draft- taxonomy in another email is that the method used to analyze the solution space is on the weak side. See also http://www1.ietf.org/mail- archive/web/nemo/current/msg01689.html, Thierry has raised his concerns about the completeness (Am I right, Thierry?). So I want to describe the desirable properties in this email. If you read my slides, you will find the vector could be used to describe the solution space completely and in a mutual exclusive way. > > 1. NEMO RO problem draft should be written in an abstract way rather than > > solution-specific. > > (from calos's email on the ML if I am not wrong.) > > 2. It does not matter how many pages the problem statement part should > > be, but it must be > > to the core of the problem. > > 3. The solution "space" analysis part must not just simply list the > > previouly proposed > > > > solutions. > > 4. It should be able to analyze the complete solution space including the > > proposed and the new ones. (The completeness should be assured in certain > > level.) > > 5. The method to categorize the solution space must be able to make one > > category not > > intersect with any other category (mutual exclusive). > > That may be desirable, but difficult to achieve. Nothing is easy and nothing is impossible. Let's try our best. > It runs the risk of > being in conflict with your point #4 above. To strictly demand mutual > exclusiveness will often leads to incompleteness. I do not understand why. Can you explain about it? > To me, having mutual > exclusive approach is only something that is preferable, but not of high > priority. Instead it is the completeness that we should try to achieve. > (Your choice of words "should" in #4 and "must" in #5 seems to indicate > you felt otherwise). > Mutual exclusion avoids the duplication and redundency. Also it provides the clear comparison and contrast between the different categories. The completeness and mutual exclusion are independent and equally important. > What advantages does mutual exclusive solution space partitioning gives > us? > The ideal solution space partition should look like this: Base on a certain criterion, the whole solution space is partitioned into for exmaple A and B. And based on another criterion, A is partitioned into for example, A1 and A2. B is partitioned into for example B1, B2 and B3 based on the same or a different criterion. In this way it is easy to see the commonness and difference among the solutions and avoids the duplicated analysis. > > > > 6. The solution space analysis does not judge on the strength and > > weakness of each solution. > > An analysis should try to be as objective as possible. That goes > without saying. But what is the use of an analysis if it does not > points out the relative strength and weakness of each approach? The reasons I list this are 1) IMHO this might be the way going into the details of solution too much. Also since you have to have the detailed solution in mind, your analysis does not include the new solution, which voids the completeness. 2) I do not see how your taxonomy draft can give a thorough evaulation without any formly defined qualifier. It could generate a lot of emails like "comments on the evaluation part". http://www1.ietf.org/mail-archive/web/nemo/current/msg01677.html http://www1.ietf.org/mail-archive/web/nemo/current/msg01689.html http://www1.ietf.org/mail-archive/web/nemo/current/msg01692.html (Thierry and Pascal if I misunderstand your email, please correct me.) 3) As when I was writing this email, I recall the similar concerns expressed on the ML. (http://www1.ietf.org/mail-archive/web/nemo/current/msg01657.html, http://www1.ietf.org/mail-archive/web/nemo/current/msg01681.html, Am I right, Alex?) I am not saying it is impossible that the evaluation can not be done nicely in a reasonable level of fairness and correctness. But at this point, as we have not understood the whole solution space, it might be too early to do it. > (I prefer to use the term 'approach' rather than 'solution', as the latter > can often be interpreted as the 'solution described in > draft-foo-bar-xx.txt'). Do you mean "approach" is a kind of mechanism to solve the RO problem, right? As Thierry also suggests the term of "issue". My understanding about the differences between "issue" and "approach" is that "approach" tries to solve the whole NEMO RO problem while "issue" is related to only some part of problem. > Instead, I think what you are trying to say is > that the analysis should not try to steer readers into thinking one > approach is better than the other. Yes, this is too. > The best way to ahieve this is for > it to list the weakness and strength of each approach. But following this line of thinking, it could still make the readers into thinking one is better than another. > True, the > initial version of that analysis may reflect only the views of the > author, and seems not impartial. But through peer reviews, we would > ultimately leads to a piece of analysis to reflect the true streangth > and weakness of an approach. > > > 7. The security analysis should be general rather than being solution- > > specific. Also it > > > > should be easy to apply to each solution. > > Nope. Not according to the WG charter. There should be a general > security consideration section that will applies to most (if not all) > approaches, that I agree. But why insisting on no security > consideration for specific approach puzzles me. > The security consideration is kind of evaluation too. So my arguments about #6 also applies here. The charter says "Furthermore, security considerations for the various approaches will also be considered." My understanding is that the charter does not limit the security consideration to be based on each specific approach either. So let'd think about it after the complete solution space is done. Some security issue might be specific to approach. > > 8. The solution space analysis part must focus on the core idea because > > there could be an infinite number of solutions that are in the different > > forms. > > > > You then run into the danger of being too vague. There is a reason why > different solutions are being proposed that seems to carry the same core > idea. Often, this occurs because one proposal improves some small > deficencies of a previous proposal (while at the same time containing > new deficiencies). It is through documenting these subtle differences > that we would be documenting the WG's experiecne on route optimization. > Then you run into the danger of being too lenthy and not well-structured. :-) I understand there must be differences between various solutions. But if the difference is just minor, will you list them in the first class? The core idea should be grasped firstly and then come the second-tier differences, and so on till a reasonable level of granularity. For me the RO solution just has to do the two things: 1) set up the Anchor Point close to CN or MNN 2) inform the Anchor Point of the full binding information to either the Internet infrastructure or a specific router. > > > > Your comments are very welcomed. > > > > Oh, you will definitely get my comments once I get back to my own > time-zone. Can't think critically with a highly-caffinated mind .... ;) > Thanks. Look forward to hearing from you. > /rgds > /cwng From nemo-bounces@ietf.org Sun Nov 14 05:51:10 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 FAA27967 for ; Sun, 14 Nov 2004 05:51: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 1CTHs8-0007aX-LU; Sun, 14 Nov 2004 05:44:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTHlS-0006c0-AI for nemo@megatron.ietf.org; Sun, 14 Nov 2004 05:37: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 FAA27198 for ; Sun, 14 Nov 2004 05:37:43 -0500 (EST) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTHnD-00073V-Je for nemo@ietf.org; Sun, 14 Nov 2004 05:39:36 -0500 Received: from syrphus.ucdavis.edu (syrphus.ucdavis.edu [169.237.104.152]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAEAbfNL027610; Sun, 14 Nov 2004 02:37:41 -0800 (PST) Received: from syrphus.ucdavis.edu (localhost [127.0.0.1]) by syrphus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAEAbftE017645; Sun, 14 Nov 2004 02:37:41 -0800 (PST) Received: (from www@localhost) by syrphus.ucdavis.edu (8.12.10/8.12.9/Submit) id iAEAbfx3017644; Sun, 14 Nov 2004 02:37:41 -0800 (PST) Date: Sun, 14 Nov 2004 02:37:41 -0800 (PST) Message-Id: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> To: Chan-Wah NG Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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, Chan-Wah, > On Thu, 2004-11-11 at 23:09 -0800, Fan Zhao wrote: > > Dear Pascal and Chan-Wah, > > > > I have some comments on the draft-thubert-nemo-ro-taxonomy-03. > > I will focus on solution space analysis part as we already have > > discussed on the problem statement part before. > > > > Section 3. Solution Space of NEMO Route Optimization > > "Shorter Delay", "Reduced Consumption of Overall Network Resources", > > "Less Susceptibility to Link Failure", "Greater Data Efficiency" > > are the benefits of RO, which should be in the problem statement part, > > but not > > in the solution space analysis part. > > > > Sure, we could have just created a new "benefits of RO" section. OK. > > > " There are multiple proposals for providing various forms of route > > optimizations for NEMO (see Appendix A). " > > Please delete the appendix. As some proposals are incomplete, even some > > does not work. What's more, some proposals look different but actually > > using > > the same core idea. > > Perhaps, but that is not up to us to judge. The readers have to decide > for themselves whether the individual proposals work or not. An > appendix is an appendix. It is something that you could do without. I > view the work done on ro-taxonomy-03.txt as a survey/review of what is > the current state of RO solutions, and it felt incomplete without > reference to all the proposals that have been made. > It is fine with me if you want to write your draft as a survey. But IMHO, the NEMO RO peoblem WG document should not be just a survey. The analysis of the complete solution space is one of the key values of this WG document. > > > > "3.1 MR-to-CN Optimization" "3.2 Infrastructure Optimization" > > "3.3 Nested Tunnels Optimization" "3.4 MIPv6-over-NEMO Optimization" > > "3.5 Intra-NEMO Optimization" > > The solution space analysis part is organized like in the problem > > statement part > > to me. I do not see any logic behind the way you use to categorize the > > solution space. > > Remember that the different problem scenarios do not mean the different > > solutions (core ideas). > > > > "Binding Update with Network Prefix" and "MR as a Proxy" use the same > > idea to me and are > > described in a too specific way. > > > Same idea? Are you sure? They may be solving the same problem (which > is why we put them into the same "MR-to-CN" optimization, but they are > entirely different. The former requires the MR to send prefix > information to CN, the latter requires the MR to pretend to be the MNN. > The core idea is quite different to me. > 1) The idea of these two is to distribute the binding information between HoA and MNP/CoA to CN. Although they extend the MIP6 RO procedure in the different ways, these kind of differences are secondary in the context of NEMO RO. 2) You want to "describe the solution space of route optimization by listing different types of approach to route optimization." So your approach listed in this sub-section has to solve the problem you describe in the problem statement part. However, I do not see how "Binding Update with Network Prefix" and "MR as a Proxy" solve the problem completely including in the nested NEMO and intra-NEMO cases. Do you agree? 3) I can immediately come up with two "MR-to-CN optimization" approaches: 3.1 MR does not send CoTi and HoTi on behalf of the MNN, instead it intercepts the CoTi and HoTi sent by the MNN and changes the source IP address in CoTi into its CoA. The rest is as same as in "MR as a proxy" 3.2 MR sends a probing packet in the outbound direction to collect the full path information to the Internet. The information about the upstream router is either recorded in the reply message or carried by each individual message like traceroute. Finally MR registers this information with CN. What do you think? > > "Infrastructure Optimization" I do not understand why "MR-to-CN > > optimization" does not > > possibly fall into this category. > > > > Because it doesn't. Infrastructure optimization means some third party > entity in the infrastructure takes part in the optimization. > So you'd better change the title. Because you list "Infrastructure Optimization" and "MR-to-CN optimization" in parallel, the reader may wonder why the path between MR and CN may not be in the infrastructure. And again, the approach under this section does not solve the NEMO RO problem completely. > > "Nested Tunnels Optimization" > > "Nested tunnels" is not the core of nemo ro problem and it > > sounds too specific too. It could make one reader wonder why other tunnel- > > reduction > > methods are not listed. > > > > Nested tunnel optimization is to reduce tunnel ... what other > tunnel-reduction method you have in mind that does not fit into the > descriptions of nested tunnel optimizations? > As I describe before, MR sends a probing packet to collect the full path information to the Internet and registers it with CN, thus the data packet only carries the information in the routing header alike payload without tunnel. Does it fit into this category or MR-to-CN category? Since you list "MR-to-CN optimization", "Infrastructure Optimization" and "Nested Tunnels Optimization" in parallel, what is the criterion you used to differentiate the approaches into different types? And again, the approach under this section does not solve the NEMO RO problem completely. > > "MIPv6-over-NEMO Optimization" > > A lot of duplications for me. > > > > Perhaps. > OK. > > > 4. Analysis of Solution Space > > > > 4.1 General Considerations of RO Solution > > The content describes the tradeoffs similar with the section of "the > > related tradeoffs" > > in the draft-zhao-nemo-ro-ps-00.txt. :-) Our draft also has other > > tradeoffs. > > > > True, that's an area where we can supplement each other. > OK. > > > 4.1.1 Additional Signaling Overhead > > The text of BU sould specific to me. The text of BU storm should belong > > to problem statement > > part. > > > > problem statement? Why? It is not a problem of NEMO Basic Support. It > is a potential problem certain RO approaches might face. > If you look into the problem closely, the number of BU packets in NEMO basic support is as same as in the NEMO RO if no method is used to reduce the number of BU packets. If this is not the problem of NEMO basic support, why it can become the problem in NEMO RO? So originally in NEMO basic support protocol the number of BU packets can not be reduced, but NEMO RO can look into this problem and find a way to reduce the overhead. > > 4.1.2 Increased Protocol Complexity > > I understand your point. However it seems to me the scalability issue has > > more impacts on > > power and processing resources than the protocol complexity. > > Thank you for pointing out that, I will reflect that on the next update. > OK. > > > > > 4.1.3 Mobility Awareness > > "it will be difficult for mobile network nodes to control the decision of > > having > > this tradeoff" > > > > Is that also the case for VMN? > > > > Now you are going into approach specific area. In the general > considerations, we just list out issues that in general an approach > might have to overcome. > I understand what you mean. But just be careful to use the term accurately. > > > 4.1.4 New Functionalities > > "Correspondent Nodes > > It is generally undesirable for correspondent nodes to be required > > to implement new functionalities." > > > > I do not agree. It depends on the type of CN. > > > > Perhaps. I tend to believe that the statement reflect what most people > feel. I might update the text to show that it depends on the type of > CN. > OK. > > > 4.1.5 Other Considerations > > If you think they are not "tradeoff", they should not be under this > > section. > > > > Why not? I did not say section 4.1 is a trade-off discussion section. > So this is a cost discussion section? Sorry I am so confused. "one would expect the costs described in the following sub-sections to be incurred." "Additional Signaling Overhead" "Increased Protocol Complexity" "Mobility Awareness ?" "New Functionalities ?" "Compatibility with NEMO Basic Support?" "In-Plane Signaling versus Off-Plane Signaling ?" > > > 4.2 Specific Types of RO Solution > > "Many of the tradeoffs discussed previously in Section 4.2 are > > dependent on the actual route optimization approach." > > Please give an example that one solution does not have one of the > > tradeoffs above. > > If there is one, your discussion about tradeoff is not general. > > You applied too strictly an interpretation of the meaning of > "general". > > > > > Some text seems like a evaluation to me. I recall one email on the ML > > before > > states that the problem draft should not judge on the quality of the > > solution. > > Perhaps, I am sorry if I give the impression of 'judging the quality of > the' approach (again, I prefer to use the term approach rather than > solution). It is not my intention. > OK. > > There are a lot of redundency too because of the way the draft used to > > categorize the > > solution space. > > Perhaps, but I would like to see a different categorization that is (a) > mutually exclusive, (b) complete, and (c) useful. For me, the prioirty > is in the revese order ... a catgorization scheme should first be > useful, and then strive to be complete, and finally preferably with > minimal duplication. > I am working on it. > > I prefer a general security consideration also. > > > > Me too, and I have already promised a general security consideration > section in my previous posts. > > > Overall, the solution space part does not analyze the space completely and > > does not categorize the solution space into mutual exclusive categories. > > As I've mentioned, I strive to be complete, and not mutually exclusive. > My feeling is that we are very close to a complete description, once we > feel in the parts on MANET as an RO appraoch. > How can you prove the completeness? > /rgds > /cwng From nemo-bounces@ietf.org Sun Nov 14 06:01: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 GAA28502 for ; Sun, 14 Nov 2004 06:01:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTI0r-0000Je-0q; Sun, 14 Nov 2004 05:53:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTHsq-0007iL-KR for nemo@megatron.ietf.org; Sun, 14 Nov 2004 05:45: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 FAA27545 for ; Sun, 14 Nov 2004 05:45:22 -0500 (EST) Received: from amsterdam.ucdavis.edu ([169.237.104.160]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTHuc-0007IN-8c for nemo@ietf.org; Sun, 14 Nov 2004 05:47:14 -0500 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by amsterdam.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAEAjKbq023612; Sun, 14 Nov 2004 02:45:20 -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 iAEAjKgb002129; Sun, 14 Nov 2004 02:45:20 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id iAEAjK2l002128; Sun, 14 Nov 2004 02:45:20 -0800 (PST) Date: Sun, 14 Nov 2004 02:45:20 -0800 (PST) Message-Id: <200411141045.iAEAjK2l002128@phaenicia.ucdavis.edu> To: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: RE: [nemo] What kind of NEMO RO problem WG document we would like to see 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 Pascal, Please see my comments in line. Thanks. Sincerely, fan > > > Below is my vision about NEMO RO problem WG document: > > 1. NEMO RO problem draft should be written in an abstract way rather > than > > solution-specific. > > (from calos's email on the ML if I am not wrong.) > > Yes, I do not think we are in contradiction here, are we? This is why we > moved solutions to appendix. Like the bibliography, it's a tentative for > additional help and time saving to the reader. > That is a good move. > > 2. It does not matter how many pages the problem statement part should > > be, but it must be > > to the core of the problem. > > I'm not sure that there is A problem to be singled out. Otherwise, > there's a lot of space between one liners and a book. One liners might > tend to be opaque and books could cause endless controversies because > there's always a sentence here or a word there that's not perfect, while > the core content could be diluted. I tend to agree that a reasonably > short text is what we need here to get a correct understanding and yet > reach consensus: Facts, but no literature. > OK. I think we are almost there regarding to the NEMO RO problem. NEMO RO problem has two parts, one is inherited from Mip6 RO problem, the other is due to the nested mobility levels. > > 3. The solution "space" analysis part must not just simply list the > > previouly proposed solutions. > > Looks nice, but what's the limit? The imagination of the WG, maybe? > > Basically, all the domains that we as a group could think off and was > willing to share was more or less explored in the last 2-3 years, in the > form of solution proposals, and somewhat discussed already on the ML; > this gave us some ground for the pro/cons/tradeoffs/applicability > discussion. This is why the solution space that we explore looks like > the space of existing proposals made a bit more abstract. But that's a > consequence, not a goal. > > The taxonomy draft has been there for 2 years for the ML to comment and > propose additions. We received help from academic, ISP and corporate > people. If you see some space that was not covered please speak up. It > will be added if there's a rough consensus that it makes any sense. But > I do not see benefits in starting it all over. > My point is that because it is hard to say the solution space is completely explored, then WG document should analyze the solution space rather than just listing. The analysis gives us a deep understanding on what is driving the solutions, which is easier to handle than the various forms of solutions. The results of analysis in return will help us to discover the new solutions. > > 4. It should be able to analyze the complete solution space including > the > > proposed and the new ones. (The completeness should be assured in > certain > > level.) > > The problem is that we do not not what's not invented yet. A WG doc is a > state of the art and of the understanding of a WG at the time of its > publication. Does not mean it's forever perfect. Does NOT aim at > LIMITING the acceptable solution to a given space, either. But rather at > helping the thought / creation process and saving newcomers time. > Agree. That is why I mean the completeness should be assured in a certain level. We can decide what level it is. But we have to prepare how to answer once outside reviewers ask about it. > Long as it's a draft, we are ready to add novelty anytime. Thomas' draft > showed us that we did not treat MANET in a fair enough fashion. Good! We > are working together on improving things, we'll add MANET text in the > next issue, and this started an interesting discussion on the comparison > of LMM and MANET based approaches, as they seem to provide similar > benefits. > > > 5. The method to categorize the solution space must be able to make > one > > category not > > intersect with any other category (mutual exclusive). > > Yes, that would be nice. Making a single category achieves that. But > might leave things out. I understand your proposition like let's make a > document that shows the solution space of everything yet to be invented, > and then partition it in non overlapping categories. There are names > like GRAAL for that sort of things; the rest of us do what we can in the > time frame we have. > > I read your draft and I liked it very much. IMHO, it's a good start, we > must keep it and build on it. The way I read it, I found it relevant as > a foudation for a requirement draft more then a problem statement. We > are not there already, since we did not recharter or anything. > I agree with you that it is too early to talk about the requirements. But most pages are talking about the problem statement though. > On the to-be-discussed side, some things were a bit cryptic to me, like > the reason why you discuss the data-plane method thing, and why you want > to formalize the nested NEMO in a PS draft. Also, I'm not sure we want > to mix RO and multihoming (the DAG thing). I am going through a learning procedure. Right now when I read my draft again, I also feel unsatisfied. I might be wrong about the statement of data-plane method. And the formalization things is not necessary in the ps. And then I want to make it sure I consider the various configurations (multihoming). > > > 6. The solution space analysis does not judge on the strength and > > weakness of each solution. > > We disagree here (I have to disagree somewhere ain't it true?). I see > the PS/solution space draft as a tool, not as a limiting boundary (as > opposed to the requirements will be specifying what we have to cover). I > believe that the pro/cons/tradeoffs/applicability discussion is at the > core of the value of that tool. > OK. My concern is that it tends to make the reader believe one is better than another. And since you have to know the details of solution, so it might be better to do it after we have the good understanding about the solution space. Also some qualfier could help make a fair and thorough evaluation. > > > 7. The security analysis should be general rather than being solution- > > specific. Also it should be easy to apply to each solution. > > You might want to list of the threats in the world in a separate > chapter, or maybe in an encyclopedia. But the problems to be addressed > are inherent to the solution space. Examples in the nested nemo case: > trust in MANET approach, MITM/Time-shifting attacks in MR-proxy, etc... > Yes, there might be some threats specific to the solution. Again, security consideration is kind of evaluation too. > > > 8. The solution space analysis part must focus on the core idea > because > > there could be an infinite number of solutions that are in the > different > > forms. > > We did not find them all, then :) But yes, we tried to abstract things > and leave the specifics to the solution drafts in reference and > eventually appendix. The only solution that we really detail is Erik's > text on proxy. The reason is that it's very educational. Again, this is > a tool, not a book of law. > I do not if you think the following is correct or not: the Ro solution just 1) makes anchor point close to either MNN or CN 2) informs the anchor point of the full path information to either the Internet or a specific router. > > We also have to think about the content of WG document. > > > And word your thoughts to the ML :) > Ok, I will once the thread starts. > Pascal > > From nemo-bounces@ietf.org Sun Nov 14 06:05:38 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 GAA28779 for ; Sun, 14 Nov 2004 06:05: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 1CTI1b-0000Pc-Ut; Sun, 14 Nov 2004 05:54:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTHv1-00080i-TT for nemo@megatron.ietf.org; Sun, 14 Nov 2004 05:47:40 -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 FAA27723 for ; Sun, 14 Nov 2004 05:47:37 -0500 (EST) Received: from tripoli.ucdavis.edu ([169.237.104.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTHwm-0007PZ-Ec for nemo@ietf.org; Sun, 14 Nov 2004 05:49:29 -0500 Received: from diometes.ucdavis.edu (diometes.ucdavis.edu [169.237.104.180]) by tripoli.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAEAlUK1004295; Sun, 14 Nov 2004 02:47:31 -0800 (PST) Received: from diometes.ucdavis.edu (localhost [127.0.0.1]) by diometes.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAEAlU0Q025618; Sun, 14 Nov 2004 02:47:30 -0800 (PST) Received: (from www@localhost) by diometes.ucdavis.edu (8.12.10/8.12.9/Submit) id iAEAlUiE025617; Sun, 14 Nov 2004 02:47:30 -0800 (PST) Date: Sun, 14 Nov 2004 02:47:30 -0800 (PST) Message-Id: <200411141047.iAEAlUiE025617@diometes.ucdavis.edu> To: Eun Kyoung PAIK , "'Chan-Wah NG'" Subject: RE: [nemo] What kind of NEMO RO problem WG document we would liketo see 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Eun, Thanks for providing your comments. Please see my reply below. Thanks. Sincerely, fan > Hi Fan and all, > > Please see in line comments. > > > > 6. The solution space analysis does not judge on the strength and > > > weakness of each solution. > > > > An analysis should try to be as objective as possible. That goes > > without saying. But what is the use of an analysis if it does not > > points out the relative strength and weakness of each approach? (I > > prefer to use the term 'approach' rather than 'solution', as the latter > > can often be interpreted as the 'solution described in > > draft-foo-bar-xx.txt'). Instead, I think what you are trying to say is > > that the analysis should not try to steer readers into thinking one > > approach is better than the other. The best way to ahieve this is for > > it to list the weakness and strength of each approach. True, the > > initial version of that analysis may reflect only the views of the > > author, and seems not impartial. But through peer reviews, we would > > ultimately leads to a piece of analysis to reflect the true streangth > > and weakness of an approach. > > I also think that the list of the weakness and strength of each approach > support is useful in this draft, since this draft is for problem statement > (not for requirements). > OK. Then we have to know the details of approach and consider the qualifiers. > > > 7. The security analysis should be general rather than being solution- > > > specific. Also it > > > should be easy to apply to each solution. > > > > Nope. Not according to the WG charter. There should be a general > > security consideration section that will applies to most (if not all) > > approaches, that I agree. But why insisting on no security > > consideration for specific approach puzzles me. > > As Pascal commented, let's distinguish the term 'solution' and 'approach'. > This draft is not supposed to analyze security in terms of any specific > solution (draft-xx-.txt), but will consider security with the various > approaches (as stated in NEMO WG charter). > BTW does "approach" mean a kind of mechanism to solve the NEMO RO problem here? It is used just because we do not want the readers to link the term of "solution" with draft-xx.txt. Right? > Regards, > Eun > From nemo-bounces@ietf.org Sun Nov 14 06:07: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 GAA29135 for ; Sun, 14 Nov 2004 06:07:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTI5g-0001e3-9c; Sun, 14 Nov 2004 05:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTHwG-0008H3-UN for nemo@megatron.ietf.org; Sun, 14 Nov 2004 05:48: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 FAA27785 for ; Sun, 14 Nov 2004 05:48:54 -0500 (EST) Received: from berlin.ucdavis.edu ([169.237.104.158]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTHy1-0007WH-Jt for nemo@ietf.org; Sun, 14 Nov 2004 05:50:46 -0500 Received: from andrena.ucdavis.edu (andrena.ucdavis.edu [169.237.104.181]) by berlin.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAEAmpE4015979; Sun, 14 Nov 2004 02:48:52 -0800 (PST) Received: from andrena.ucdavis.edu (localhost [127.0.0.1]) by andrena.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAEAmpOf013013; Sun, 14 Nov 2004 02:48:51 -0800 (PST) Received: (from www@localhost) by andrena.ucdavis.edu (8.12.10/8.12.9/Submit) id iAEAmpxl013012; Sun, 14 Nov 2004 02:48:51 -0800 (PST) Date: Sun, 14 Nov 2004 02:48:51 -0800 (PST) Message-Id: <200411141048.iAEAmpxl013012@andrena.ucdavis.edu> To: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] The correct url of slides 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Thierry, Thanks for providing the link. Best regards, fan > Fan, all presentation materials are located, as always, on the NEMO web > page (http://www.mobilenetworks.org/nemo/ietf61) > > Thierry. > > On Thu, 11 Nov 2004 23:17:43 -0800 (PST) > "Fan Zhao" wrote: > > > > > Dear all, > > > > Sorry, the url for my presentation is > > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ietf61.ppt. > From nemo-bounces@ietf.org Sun Nov 14 06:43:20 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 GAA01760 for ; Sun, 14 Nov 2004 06:43:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTIfU-0008FN-Ug; Sun, 14 Nov 2004 06:35:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTIYM-0007QD-99 for nemo@megatron.ietf.org; Sun, 14 Nov 2004 06:28:18 -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 GAA00516 for ; Sun, 14 Nov 2004 06:28:15 -0500 (EST) Received: from bern.ucdavis.edu ([169.237.104.167]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTIa8-0000j2-3C for nemo@ietf.org; Sun, 14 Nov 2004 06:30:08 -0500 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by bern.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAEBSDwh023887; Sun, 14 Nov 2004 03:28:14 -0800 (PST) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAEBSDbU011598; Sun, 14 Nov 2004 03:28:13 -0800 (PST) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id iAEBSD8H011597; Sun, 14 Nov 2004 03:28:13 -0800 (PST) Date: Sun, 14 Nov 2004 03:28:13 -0800 (PST) Message-Id: <200411141128.iAEBSD8H011597@tremex.ucdavis.edu> To: Fan Zhao , Chan-Wah NG Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Hi Chan-Wah, I am sorry I would like to readdress the BU storm issue. Please see below. Sincerely, fan > > > 4.1.1 Additional Signaling Overhead > > > The text of BU sould specific to me. The text of BU storm should > belong > > > to problem statement > > > part. > > > > > > > problem statement? Why? It is not a problem of NEMO Basic Support. It > > is a potential problem certain RO approaches might face. > > > If you look into the problem closely, the number of BU packets in NEMO > basic support is as same as in the NEMO RO if no method is used to reduce > the number of BU packets. If this is not the problem of NEMO basic > support, why it can become the problem in NEMO RO? So originally in NEMO > basic support protocol the number of BU packets can not be reduced, but > NEMO RO can look into this problem and find a way to reduce the overhead. > The words above only assume the situation where the nested network is formed in a short period. I realize that when one intermediate MR moves, there is no such BU storm in the NEMO basic support. So let me put it in this way, BU storm is a potential problem that a RO solution may have; a similar phenomenon may also happen when the nested NEMO network is formed in a very short period (note that either in RO or nemo basic support, MR has to wait until the upstream MR finishes the BU procedure.). The text in draft-taxonomy compares the signal overhead with the data traffic overhead, I think it is not necessary, the signal overhead must have to be reduced if possible no matter the volume of data traffic. From nemo-bounces@ietf.org Sun Nov 14 14:11:45 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 OAA03599 for ; Sun, 14 Nov 2004 14:11:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTPbS-0005yL-Q1; Sun, 14 Nov 2004 13:59:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTPZJ-0005jh-Hd for nemo@megatron.ietf.org; Sun, 14 Nov 2004 13:57: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 NAA02454 for ; Sun, 14 Nov 2004 13:57:43 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTPb9-0003EG-0B for nemo@ietf.org; Sun, 14 Nov 2004 13:59:39 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAEIx93B025354; Sun, 14 Nov 2004 11:59:09 -0700 (MST) Received: from [10.181.32.22] (mvp-10-181-32-22.ea.mot.com [10.181.32.22]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id iAEIvaim029588; Sun, 14 Nov 2004 12:57:37 -0600 Message-ID: <4197AA9F.4050909@motorola.com> Date: Sun, 14 Nov 2004 19:57:35 +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: Fan Zhao Subject: Re: [nemo] What kind of NEMO RO problem WG document we would like to see References: <200411141030.iAEAUbpj001789@phaenicia.ucdavis.edu> In-Reply-To: <200411141030.iAEAUbpj001789@phaenicia.ucdavis.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Chan-Wah NG 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 Fan Zhao wrote: >>An analysis should try to be as objective as possible. That goes >>without saying. But what is the use of an analysis if it does not >>points out the relative strength and weakness of each approach? [...] > 3) As when I was writing this email, I recall the similar concerns > expressed on the ML. > (http://www1.ietf.org/mail-archive/web/nemo/current/msg01657.html, > http://www1.ietf.org/mail-archive/web/nemo/current/msg01681.html First, everyone can, and should, write any draft one likes. But if one wants to have a draft useful for the WG, i.e. a WG item, then think what exactly can be re-used from the draft. IMHO, a draft author should think as if it is _not_ him or her that will actually use it, but somebody else. Very often the link between the person who writes a draft and the person that actually uses it is very loose, never met, no email conversation, etc. So don't expect everyone to embrace what the RO problem statement draft says just because it's a WG item. Risking being blunt, let me give examples: there was often a tendency to force the requirements and terminology drafts as strict precursors and strict guidelines for the Basic Support. What actually happened is that both drafts were refined simultaneously, and that currently there are inconsistencies. They're mostly in agreement but: some requirements were written after some of the Basic Support ideas were put on paper, and some terminology is defined but not useful for the Basic Support. Another more humble example is a security analysis draft on Mobile IPv6 and proposals for secure RO to which I remotely participated somehow. When I did I was thinking the same, that _that_ draft will be the guideline for the ultimate secure RO solution. Well, not so! And for good reason. My personal bottom line is that problem statement and analysis of solution space drafts are done in order to show that we - as a WG - do understand the actual problem and are capable of working on a IETF solution. Would anyone care if that particular WG item does not actually become an RFC? And of course, even if a good understanding of the problem exists - there still needs to be a deployment need for it, without which it's all just another academic exercise. Until we figure this out, why don't we just have a short PRoblem Statement (no solution analysis) draft, float it around and get consensus and positive feedback on it. End of blah-blah let me get back with some specific comments on the draft. Alex From nemo-bounces@ietf.org Sun Nov 14 14:32: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 OAA05175 for ; Sun, 14 Nov 2004 14:32: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 1CTQ0X-0000A5-Jj; Sun, 14 Nov 2004 14:25:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTPyF-0008QD-Nm for nemo@megatron.ietf.org; Sun, 14 Nov 2004 14:23:31 -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 OAA04201 for ; Sun, 14 Nov 2004 14:23:30 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTQ05-0004HZ-2a for nemo@ietf.org; Sun, 14 Nov 2004 14:25:26 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id iAEJR8LG002910; Sun, 14 Nov 2004 12:27:08 -0700 (MST) Received: from [10.181.32.22] (mvp-10-181-32-22.ea.mot.com [10.181.32.22]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iAEHMopO006765; Sun, 14 Nov 2004 11:22:51 -0600 Message-ID: <4197B0A4.3030903@motorola.com> Date: Sun, 14 Nov 2004 20:23:16 +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] comments on solution space analysis part in taxonomy draft References: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> <012CAB80-34E0-11D9-8AE2-000A95DA08F2@kniveton.com> In-Reply-To: <012CAB80-34E0-11D9-8AE2-000A95DA08F2@kniveton.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Chan-Wah NG 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 T.J.Kniveton wrote: > Well, the concern is a valid one.. but it should only be raised by > someone who has read the latest version of the draft. Well, here I am, have just read some parts of the draft. These comments are not exhaustive, and I do not comment on advancement of this particular draft, and don't comment to the draft in its entirety. Within the Problem Statement, I think the draft fails to mention that optimal routes for NEMO could be obtained by injecting routes in the visited domain but that brings in other bigger problem. This problem is also one of the reasons why Mobile IP for hosts was developped the way it was, but I think it deserves brief mentioning in a NEMO RO PS (Problem Statement, not Proposed Standard, not PostScript) document too. Or maybe this problem is already too basic to be mentioned here. I don't like the term "pinball routing" I like it better "multi-angular" routing. If you know of a reference to prior use of this term "pinball routing" please let me know. Section 2.3: "When a MIPv6 mn joins a mobile network it becomes a VMN". I think it is also valid to say "When a MIPv6 mn joins a mobile network it becomes a LMN". The VMN and LMN terms offer no useful distinction here. BEtter use MH or MR or MN, it is sufficient to my reading. Section 3.2 Infrastructure Optimization fails to mention BGP. But it does mention HAHA as a potential Infrastructure Optimization (to my understanding, HAHA is _not_ known to work even on paper, so why mentioning it at all). What are "Mobile Routers forming a fleet"? "Possible nodes that are required to be changed include: ..." why does the list include VMN and not include LMN? Isn't it because there is no clear distinction between LMN and VMN? So again better just use MH, MR or MN. So in section 4.2.2 Infrastructure Optimization, if we do this, we need a method to Discover Correspondent Routers, right? Do you know of such a method? I've only partially read the draft, comments welcome. Alex From nemo-bounces@ietf.org Mon Nov 15 04:22:26 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 EAA10048 for ; Mon, 15 Nov 2004 04:22: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 1CTd1d-0000VP-LJ; Mon, 15 Nov 2004 04:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTcx0-0000HW-NH for nemo@megatron.ietf.org; Mon, 15 Nov 2004 04:15:06 -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 EAA09618 for ; Mon, 15 Nov 2004 04:15:04 -0500 (EST) Received: from web25002.mail.ukl.yahoo.com ([217.12.10.38]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CTcyy-0002sG-ER for nemo@ietf.org; Mon, 15 Nov 2004 04:17:09 -0500 Received: (qmail 51553 invoked by uid 60001); 15 Nov 2004 09:14:34 -0000 Message-ID: <20041115091434.51551.qmail@web25002.mail.ukl.yahoo.com> Received: from [131.254.253.27] by web25002.mail.ukl.yahoo.com via HTTP; Mon, 15 Nov 2004 10:14:34 CET Date: Mon, 15 Nov 2004 10:14:34 +0100 (CET) From: Mazen TLAIS Subject: [nemo] new draft: resource reservation for nemo To: IETF NEMO WG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA09618 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, We have submitted a new draft that introduces a resource reservation protocol for NEMO networks.=20 Degradation or forced service termination may occur because of frequent handoffs that may occur within NEMO networks. This paper presents a resource reservation scheme aiming at supporting quality of service guaranty. We focus on a reservation protocol adapted to NEMO specifications. For doing so, we use a generic signaling protocol that may exploit advantages of both reservation protocols; IntServ and DiffServ. http://www.ietf.org/internet-drafts/draft-tlais-nemo-resource-reservation= -00.txt Your comments are appreciated. Best regards Mazen TLAIS =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 Mon Nov 15 06:27:32 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 GAA17416 for ; Mon, 15 Nov 2004 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 1CTezb-00059c-DF; Mon, 15 Nov 2004 06:25:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTeyx-00056o-RP for nemo@megatron.ietf.org; Mon, 15 Nov 2004 06:25: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 GAA17267 for ; Mon, 15 Nov 2004 06:25:13 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTf0m-0004r3-MN for nemo@ietf.org; Mon, 15 Nov 2004 06:27:19 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 15 Nov 2004 12:47:50 +0100 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 iAFBO3ug017868; Mon, 15 Nov 2004 12:24:28 +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.0); Mon, 15 Nov 2004 12:24:10 +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] What kind of NEMO RO problem WG document we would liketosee Date: Mon, 15 Nov 2004 12:24:04 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC4520D9@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] What kind of NEMO RO problem WG document we would liketosee Thread-Index: AcTKOgneU1j4ACHtQaSfav5h7RunDwAyvo0Q From: "Pascal Thubert \(pthubert\)" To: "Fan Zhao" , "Eun Kyoung PAIK" , "Chan-Wah NG" X-OriginalArrivalTime: 15 Nov 2004 11:24:10.0911 (UTC) FILETIME=[A0F82AF0:01C4CB05] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > > As Pascal commented, let's distinguish the term 'solution' > and 'approach'. > > This draft is not supposed to analyze security in terms of any specific > > solution (draft-xx-.txt), but will consider security with the various > > approaches (as stated in NEMO WG charter). > > > BTW does "approach" mean a kind of mechanism to solve the NEMO RO problem > here? It is used just because we do not want the readers to link the term > of "solution" with draft-xx.txt. Right? >=20 No, actually it's more like a category, a type, an abstraction that encompasses a number of related solutions. For instance: Source routing, MANET and Anchor Point are approaches for the nested NEMO case.=20 Pascal From nemo-bounces@ietf.org Mon Nov 15 06:47: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 GAA18546 for ; Mon, 15 Nov 2004 06:47: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 1CTfIy-0006RK-TC; Mon, 15 Nov 2004 06:45:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTfII-0006Ng-VO for nemo@megatron.ietf.org; Mon, 15 Nov 2004 06:45: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 GAA18414 for ; Mon, 15 Nov 2004 06:45:12 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTfKI-00058u-6u for nemo@ietf.org; Mon, 15 Nov 2004 06:47:18 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 15 Nov 2004 13:07:58 +0100 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 iAFBiKuO021341; Mon, 15 Nov 2004 12:44:21 +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.0); Mon, 15 Nov 2004 12:43:33 +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] comments on solution space analysis part in taxonomy draft Date: Mon, 15 Nov 2004 12:40:32 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC4520FC@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on solution space analysis part in taxonomy draft Thread-Index: AcTKf3Io0h+LuFK0SCGKN1hcyRp7HAAhqVvg From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "T.J.Kniveton" X-OriginalArrivalTime: 15 Nov 2004 11:43:33.0639 (UTC) FILETIME=[56026170:01C4CB08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Chan-Wah NG 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 > I don't like the term "pinball routing" I like it better "multi-angular" > routing. If you know of a reference to prior use of this term "pinball > routing" please let me know. Try: http://www.google.com/search?hl=3Den&q=3D%22pinball+routing%22&btnG=3DGoo= gle+S earch=20 >=20 > Section 2.3: "When a MIPv6 mn joins a mobile network it becomes a VMN". > I think it is also valid to say "When a MIPv6 mn joins a mobile network > it becomes a LMN". The VMN and LMN terms offer no useful distinction > here. BEtter use MH or MR or MN, it is sufficient to my reading. I think it's just the definition...=20 >=20 > Section 3.2 Infrastructure Optimization fails to mention BGP. But it > does mention HAHA as a potential Infrastructure Optimization (to my > understanding, HAHA is _not_ known to work even on paper, so why > mentioning it at all). Do you mean that mobility should interfere with BGP in the infra > What are "Mobile Routers forming a fleet"? It might be useful to distinguish swarming movement and solid movement.=20 A fleet moves mostly as a solid, with little inner (relative) movement. >=20 > "Possible nodes that are required to be changed include: ..." why does > the list include VMN and not include LMN? Isn't it because there is no > clear distinction between LMN and VMN? So again better just use MH, MR > or MN. >=20 > So in section 4.2.2 Infrastructure Optimization, if we do this, we need > a method to Discover Correspondent Routers, right? Do you know of such > a method? >=20 Right, it's one of the problems to be solved, so it's listed. ORC proposes a solution. There should be others, hopefully.=20 Pascal From nemo-bounces@ietf.org Mon Nov 15 09:00: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 JAA25622 for ; Mon, 15 Nov 2004 09:00:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CThKl-00031b-GF; Mon, 15 Nov 2004 08:55:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CThJl-0002rb-WA for nemo@megatron.ietf.org; Mon, 15 Nov 2004 08:54:54 -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 IAA25319 for ; Mon, 15 Nov 2004 08:54:52 -0500 (EST) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CThLj-0007Qq-Fr for nemo@ietf.org; Mon, 15 Nov 2004 08:56:58 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id iAFDsekO004293; Mon, 15 Nov 2004 06:54:41 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id iAFDkX4K005144; Mon, 15 Nov 2004 07:46:34 -0600 Message-ID: <4198B51B.4020601@motorola.com> Date: Mon, 15 Nov 2004 14:54:35 +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: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft References: <7892795E1A87F04CADFCCF41FADD00FC4520FC@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC4520FC@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "T.J.Kniveton" , Chan-Wah NG 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 Pascal Thubert (pthubert) wrote: >>Section 3.2 Infrastructure Optimization fails to mention BGP. But it >>does mention HAHA as a potential Infrastructure Optimization (to my >>understanding, HAHA is _not_ known to work even on paper, so why >>mentioning it at all). > > Do you mean that mobility should interfere with BGP in the infra I don't mean that BGP should interfere with mobility. I don't comment on a kind of solution or what should be done. I just mean that optimal paths can be obtained by injecting routes (and not use Mobile IP). I also mean that using routes directly can not scale to the size of the bigger Internet, but can work ok within small domains. I also refer to a BGP for NEMO presentation which I've seen slides on the web and to which I've already sent an URL. And also refer to some BGP discussion that happened here earlier. Alex From nemo-bounces@ietf.org Tue Nov 16 04:31:11 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 EAA08317 for ; Tue, 16 Nov 2004 04:31: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 1CTzZD-0000qy-PQ; Tue, 16 Nov 2004 04:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTzVR-0000Hb-U7 for nemo@megatron.ietf.org; Tue, 16 Nov 2004 04:20:12 -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 EAA07463 for ; Tue, 16 Nov 2004 04:20:08 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTzXb-0008VT-ED for nemo@ietf.org; Tue, 16 Nov 2004 04:22:24 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 16 Nov 2004 10:43:11 +0100 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 iAG9J9eW028107; Tue, 16 Nov 2004 10:19:33 +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); Tue, 16 Nov 2004 10:19:32 +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] comments on solution space analysis part in taxonomy draft Date: Tue, 16 Nov 2004 10:19:29 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC4524DA@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on solution space analysis part in taxonomy draft Thread-Index: AcTLGrI5qYqqits1RiyJ9GKEdWnKwwAoenYw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Nov 2004 09:19:32.0072 (UTC) FILETIME=[61A5A680:01C4CBBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, "T.J.Kniveton" , Chan-Wah NG 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 > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Sent: lundi 15 novembre 2004 14:55 > To: Pascal Thubert (pthubert) > Cc: T.J.Kniveton; nemo@ietf.org; Chan-Wah NG > Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft >=20 > Pascal Thubert (pthubert) wrote: > >>Section 3.2 Infrastructure Optimization fails to mention BGP. But it > >>does mention HAHA as a potential Infrastructure Optimization (to my > >>understanding, HAHA is _not_ known to work even on paper, so why > >>mentioning it at all). > > > > Do you mean that mobility should interfere with BGP in the infra >=20 > I don't mean that BGP should interfere with mobility. I don't comment > on a kind of solution or what should be done. I just mean that optimal > paths can be obtained by injecting routes (and not use Mobile IP). I > also mean that using routes directly can not scale to the size of the > bigger Internet, but can work ok within small domains. >=20 > I also refer to a BGP for NEMO presentation which I've seen slides on > the web and to which I've already sent an URL. And also refer to some > BGP discussion that happened here earlier. Agreed; there is no reason the RESTRICT the usage of NEMO when we can avoid it. Also, some changes in BGP might be useful that would not cause leakage in runtime as the MR moves. Also, in some cases, we might use BGP to link NEMOs as well as opposed to grow a single, larger NEMO, which could become unmanageable. This might be seen as a MANET problem, but it's something that we could benefit from. Pascal From nemo-bounces@ietf.org Tue Nov 16 11:27: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 LAA15554 for ; Tue, 16 Nov 2004 11:27: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 1CU62M-0003FC-Il; Tue, 16 Nov 2004 11:18:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU60i-0002j5-LH for nemo@megatron.ietf.org; Tue, 16 Nov 2004 11:16: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 LAA14400 for ; Tue, 16 Nov 2004 11:16:47 -0500 (EST) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU62r-0000qo-Vj for nemo@ietf.org; Tue, 16 Nov 2004 11:19:08 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7BD38302C9 for ; Tue, 16 Nov 2004 17:16:08 +0100 (CET) Received: from triangulo.it.uc3m.es (triangulo.it.uc3m.es [163.117.139.109]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 66BF6302C5 for ; Tue, 16 Nov 2004 17:16:08 +0100 (CET) Received: from [163.117.140.45] (escorpion.it.uc3m.es [163.117.140.45]) by triangulo.it.uc3m.es (8.13.1/8.13.1/Debian-13) with ESMTP id iAGGG7Mr012119 for ; Tue, 16 Nov 2004 17:16:07 +0100 From: Antonio de la Oliva Delgado To: nemo@ietf.org Content-Type: text/plain Message-Id: <1100622563.26359.11.camel@escorpion> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Tue, 16 Nov 2004 17:29:24 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Subject: [nemo] Problems in the rfc 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 all, We are implementing the NEMO Basic Support Protocol within the framework of the DAIDALOS European project. When dealing with the BU message format part of the I-D, we have found that, IMHO, there is some text that is not completely clear for a developer. The section 4.1 says: "A new flag (R) is included in the Binding Update to indicate to the Home Agent if 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " Reference [1] (RFC3775) says the following about the BU message format: "The Binding Update uses the MH Type value 5. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " The bit M is not defined in RFC3775 or in the Nemo draft, but in the HMIPv6 I-D (draft-ietf-mipshop-hmipv6-03.txt). Therefore, I would suggest to reflect in the current text of the NEMO Basic Support protocol, some reference about the HMIPv6 specification. Kind Regards, Antonio de la Oliva Carlos J. From nemo-bounces@ietf.org Tue Nov 16 12:27:33 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 MAA21896 for ; Tue, 16 Nov 2004 12:27: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 1CU74w-0006cu-Rx; Tue, 16 Nov 2004 12:25:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6md-0001lT-Rl for nemo@megatron.ietf.org; Tue, 16 Nov 2004 12:06:23 -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 MAA19774 for ; Tue, 16 Nov 2004 12:06:20 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6oh-00025B-2n for nemo@ietf.org; Tue, 16 Nov 2004 12:08:42 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7D6CA414EE for ; Tue, 16 Nov 2004 18:05:37 +0100 (CET) Received: from triangulo.it.uc3m.es (triangulo.it.uc3m.es [163.117.139.109]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 6A13F414EA for ; Tue, 16 Nov 2004 18:05:37 +0100 (CET) Received: from [163.117.140.45] (escorpion.it.uc3m.es [163.117.140.45]) by triangulo.it.uc3m.es (8.13.1/8.13.1/Debian-13) with ESMTP id iAGH5afm022491 for ; Tue, 16 Nov 2004 18:05:36 +0100 From: Antonio de la Oliva Delgado To: nemo@ietf.org Content-Type: text/plain Message-Id: <1100625533.26359.15.camel@escorpion> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Tue, 16 Nov 2004 18:18:54 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Subject: [nemo] Problems in rfc 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 all, We are implementing the NEMO Basic Support Protocol within the framework of the DAIDALOS European project. When dealing with the BU message format part of the I-D, we have found that, IMHO, there is some text that is not completely clear for a developer. The section 4.1 says: "A new flag (R) is included in the Binding Update to indicate to the Home Agent if 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " Reference [1] (RFC3775) says the following about the BU message format: "The Binding Update uses the MH Type value 5. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " The bit M is not defined in RFC3775 or in the Nemo draft, but in the HMIPv6 I-D (draft-ietf-mipshop-hmipv6-03.txt). Therefore, I would suggest to reflect in the current text of the NEMO Basic Support protocol, some reference about the HMIPv6 specification. Kind Regards, Antonio de la Oliva Carlos J. From nemo-bounces@ietf.org Tue Nov 16 12:28: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 MAA22030 for ; Tue, 16 Nov 2004 12:28:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU74y-0006et-6F; Tue, 16 Nov 2004 12:25:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6o5-0001ww-Iq for nemo@megatron.ietf.org; Tue, 16 Nov 2004 12:07:53 -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 MAA19907 for ; Tue, 16 Nov 2004 12:07:51 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6qJ-00029S-B1 for nemo@ietf.org; Tue, 16 Nov 2004 12:10:13 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id iAGH7cp2029533; Tue, 16 Nov 2004 10:07:44 -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 iAGH7Ixt031035; Tue, 16 Nov 2004 11:07:19 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id BB9DA88CF71; Tue, 16 Nov 2004 18:07:35 +0100 (CET) Message-ID: <419A33D7.7010409@motorola.com> Date: Tue, 16 Nov 2004 18:07:35 +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: Antonio de la Oliva Delgado Subject: Re: [nemo] Problems in the draft-03 References: <1100622563.26359.11.camel@escorpion> In-Reply-To: <1100622563.26359.11.camel@escorpion> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Antonio, thanks for the message and for looking at implementing. You're right that the M bit comes before the R bit and that HMIPv6 is not referenced in the NEMO document and thanks for pointing this out. An explanation of this affair may be that neither the NEMO document nor the HMIPv6 document are currently RFCs. They're both in the RFC queue, with a certain level of consensus roughness achieved. So it's difficult to reference each other right now. It is usual to refer a draft from a draft, and an RFC from a draft, but one would avoid referring a draft from an RFC, no? We've had a number of other remarks on text of the NEMO basic support draft-03 that are also important and we've had the option of either applying all the agreed changes on the current draft-03 or maybe wait for it to become an RFC and re-issue rfcbis. Vijay and Chairs can tell more about this, it's a gray area for me at this point. Alex Antonio de la Oliva Delgado wrote: > Hi all, > > We are implementing the NEMO Basic Support Protocol within the > framework of the DAIDALOS European project. When dealing with the BU > message format part of the I-D, we have found that, IMHO, there is > some text that is not completely clear for a developer. The section > 4.1 says: > > "A new flag (R) is included in the Binding Update to indicate to the > Home Agent if 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | . . . > Mobility options . . > . | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " > > Reference [1] (RFC3775) says the following about the BU message > format: > > "The Binding Update uses the MH Type value 5. When this value is > indicated in the MH Type field, the format of the Message Data field > in the Mobility Header is as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K| Reserved | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | . . . > Mobility options . . > . | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " > > The bit M is not defined in RFC3775 or in the Nemo draft, but in the > HMIPv6 I-D (draft-ietf-mipshop-hmipv6-03.txt). > > Therefore, I would suggest to reflect in the current text of the NEMO > Basic Support protocol, some reference about the HMIPv6 > specification. > > Kind Regards, Antonio de la Oliva Carlos J. > > From nemo-bounces@ietf.org Tue Nov 16 13:32:33 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 NAA27635 for ; Tue, 16 Nov 2004 13:32: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 1CU852-000360-Hh; Tue, 16 Nov 2004 13:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7sn-00012V-3r for nemo@megatron.ietf.org; Tue, 16 Nov 2004 13:16: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 NAA26345 for ; Tue, 16 Nov 2004 13:16:46 -0500 (EST) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7v1-0003xP-1h for nemo@ietf.org; Tue, 16 Nov 2004 13:19:09 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 84239303BF for ; Tue, 16 Nov 2004 19:16:13 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp03.uc3m.es (Postfix) with ESMTP id 6D6EB303BC for ; Tue, 16 Nov 2004 19:16:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <9A5868F6-37FB-11D9-AEEC-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed To: nemo WG From: marcelo bagnulo braun Date: Tue, 16 Nov 2004 19:16:14 +0100 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Subject: [nemo] about draft-ietf-nemo-multihoming-issues-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 Content-Transfer-Encoding: 7bit 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... 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 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 :-) 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) 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. 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 :-) Next you have a typo in For those failures that can't be receovered (such a failure of the access router), a heartbeadt ^ 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 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 :-) Finally, separate the references in normative informative Regards, marcelo ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Wed Nov 17 03:38: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 DAA28134 for ; Wed, 17 Nov 2004 03:38: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 1CULFy-0002ZF-MC; Wed, 17 Nov 2004 03:33:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CULEP-0002IT-JY for nemo@megatron.ietf.org; Wed, 17 Nov 2004 03:32:01 -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 DAA27408 for ; Wed, 17 Nov 2004 03:31:59 -0500 (EST) Received: from bb219-74-24-182.singnet.com.sg ([219.74.24.182] helo=fox.magix.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CULGl-0002I0-PP for nemo@ietf.org; Wed, 17 Nov 2004 03:34:28 -0500 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 80BAE177EFA; Wed, 17 Nov 2004 16:31:24 +0800 (SGT) Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft From: Chan-Wah NG To: Alexandru Petrescu In-Reply-To: <4197B0A4.3030903@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> <012CAB80-34E0-11D9-8AE2-000A95DA08F2@kniveton.com> <4197B0A4.3030903@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 17 Nov 2004 16:31:24 +0800 Message-Id: <1100680284.10509.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "T.J. Kniveton" , Pascal Thubert 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 Alex, Sorry to jump in late .... On Sun, 2004-11-14 at 20:23 +0100, Alexandru Petrescu wrote: > Within the Problem Statement, I think the draft fails to mention that > optimal routes for NEMO could be obtained by injecting routes in the > visited domain but that brings in other bigger problem. This problem is > also one of the reasons why Mobile IP for hosts was developped the way > it was, but I think it deserves brief mentioning in a NEMO RO PS > (Problem Statement, not Proposed Standard, not PostScript) document too. > Or maybe this problem is already too basic to be mentioned here. > That doesn't sounds like a problem statement to me. It sounds mre like an issue arising from a particular RO approach. true, it is possible to inject routes to achieve route optimization, and the current ro-taxonmy-03 draft did not list it. I will do so for later version (see below). Or, to use the terms Thierry used, its not a core problem for the need of RO. > Section 3.2 Infrastructure Optimization fails to mention BGP. But it > does mention HAHA as a potential Infrastructure Optimization (to my > understanding, HAHA is _not_ known to work even on paper, so why > mentioning it at all). > Yep ... that's exactly where I will add what I said above. > What are "Mobile Routers forming a fleet"? > > "Possible nodes that are required to be changed include: ..." why does > the list include VMN and not include LMN? Isn't it because there is no > clear distinction between LMN and VMN? So again better just use MH, MR > or MN. > > So in section 4.2.2 Infrastructure Optimization, if we do this, we need > a method to Discover Correspondent Routers, right? Do you know of such > a method? Not really, though there have been some mechanism suggested, such as having a multicast address for correspondent router group. And "The nedd for CR discovery mechanism" issue is listed in the draft. /rgds /cwng From nemo-bounces@ietf.org Wed Nov 17 04:35:54 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 EAA04562 for ; Wed, 17 Nov 2004 04:35:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUM2R-0003Mq-OQ; Wed, 17 Nov 2004 04:23:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUM0H-0002cb-K0 for nemo@megatron.ietf.org; Wed, 17 Nov 2004 04:21:30 -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 EAA02961 for ; Wed, 17 Nov 2004 04:21:27 -0500 (EST) Received: from bb219-74-24-182.singnet.com.sg ([219.74.24.182] helo=fox.magix.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUM2e-0003b5-Q0 for nemo@ietf.org; Wed, 17 Nov 2004 04:23:57 -0500 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 071F6177F54; Wed, 17 Nov 2004 17:20:58 +0800 (SGT) Subject: Re: [nemo] What kind of NEMO RO problem WG document we would like to see From: Chan-Wah NG To: Fan Zhao In-Reply-To: <200411141030.iAEAUbpj001789@phaenicia.ucdavis.edu> References: <200411141030.iAEAUbpj001789@phaenicia.ucdavis.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 17 Nov 2004 17:20:57 +0800 Message-Id: <1100683257.10488.34.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 Fan, Sorry for replying late. See reponses in-line: /rgds /cwng On Sun, 2004-11-14 at 02:30 -0800, Fan Zhao wrote: > > It runs the risk of > > being in conflict with your point #4 above. To strictly demand mutual > > exclusiveness will often leads to incompleteness. > I do not understand why. Can you explain about it? > By strictly demanding mutual exclusivity, you are demanding the division of an area into two non-overlapping areas. It runs a risk of having area not covered by the two areas. > > To me, having mutual > > exclusive approach is only something that is preferable, but not of high > > priority. Instead it is the completeness that we should try to achieve. > > (Your choice of words "should" in #4 and "must" in #5 seems to indicate > > you felt otherwise). > > > Mutual exclusion avoids the duplication and redundency. Also it provides > the clear comparison and contrast between the different categories. The > completeness and mutual exclusion are independent and equally important. > I am not saying mutual exlcusivity is not good. I like mutual exlusivity, but not at the expense of completeness is my point. > > What advantages does mutual exclusive solution space partitioning gives > > us? > > > The ideal solution space partition should look like this: > > Base on a certain criterion, the whole solution space is partitioned into > for exmaple A and B. And based on another criterion, A is partitioned > into for example, A1 and A2. B is partitioned into for example B1, B2 and > B3 based on the same or a different criterion. In this way it is easy to > see the commonness and difference among the solutions and avoids the > duplicated analysis. AH ... your a and B do overlaps, don't they? SO what you are proposing is this, suppose we come up wth 2 criteria, A and B, so you would partitioned the solution space into 4 quadrants: Q1: A & B, Q2: !A & B, Q3: A & !B, and Q4: !A & !B. Right? Interesting proposal, seems to be along the line of the way we classify mutlihoming cases ... > > > > > > > 6. The solution space analysis does not judge on the strength and > > > weakness of each solution. > > > > An analysis should try to be as objective as possible. That goes > > without saying. But what is the use of an analysis if it does not > > points out the relative strength and weakness of each approach? > > The reasons I list this are > > 1) IMHO this might be the way going into the details of solution too > much. Also since you have to have the detailed solution in mind, your > analysis does not include the new solution, which voids the completeness. > Nope, given what you have defined in the solution space you are describing, an analysis should point out the strength and weakness of that solution space. For instance, your solution space might be: a; require sending of BU with prefix to CN, !a: does not require sending of BU to CN. Then it should point out that (a) requires changes to CN, which is generally undesirable. > 2) I do not see how your taxonomy draft can give a thorough evaulation > without any formly defined qualifier. It could generate a lot of emails > like "comments on the evaluation part". > http://www1.ietf.org/mail-archive/web/nemo/current/msg01677.html > http://www1.ietf.org/mail-archive/web/nemo/current/msg01689.html > http://www1.ietf.org/mail-archive/web/nemo/current/msg01692.html > (Thierry and Pascal if I misunderstand your email, please correct me.) > No, we are not trying to evaluate solutions. That's not the purpose of the solution space analysis. It simply is an analysis to help whatever WG (new, or the re-chartered NEMO WG) that is going to develop and specify a standardized NEMO Extended Support. > 3) As when I was writing this email, I recall the similar concerns > expressed on the ML. > (http://www1.ietf.org/mail-archive/web/nemo/current/msg01657.html, > http://www1.ietf.org/mail-archive/web/nemo/current/msg01681.html, Am I > right, Alex?) > I am not saying it is impossible that the evaluation can not be done > nicely in a reasonable level of fairness and correctness. But at this > point, as we have not understood the whole solution space, it might be > too early to do it. > > > (I prefer to use the term 'approach' rather than 'solution', as the > latter > > can often be interpreted as the 'solution described in > > draft-foo-bar-xx.txt'). > Do you mean "approach" is a kind of mechanism to solve the RO problem, > right? As Thierry also suggests the term of "issue". My understanding > about the differences between "issue" and "approach" is that "approach" > tries to solve the whole NEMO RO problem while "issue" is related to only > some part of problem. > Nope, for me, "approach" is a general way to solve a particular problem (like solve this problem using routing header), a "solution" is draft-xxx-xxxx that specifies details of an approach (like use Reverse Routing Header). If you like, you can call "solution" a "proposal". My understanding of what Thierry is concerned is the confusion of issues and problems. He want to use "problems" to refer to problem with NEMO Basic Support that leads to the need for RO; and "issues" to refer to the potential problems that a particular RO approach might face. /rgds /cwng From nemo-bounces@ietf.org Wed Nov 17 04:42:43 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 EAA05255 for ; Wed, 17 Nov 2004 04:42: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 1CUMFQ-0006nF-Sh; Wed, 17 Nov 2004 04:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUMDL-0005xK-Ux for nemo@megatron.ietf.org; Wed, 17 Nov 2004 04:34: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 EAA04443 for ; Wed, 17 Nov 2004 04:34:57 -0500 (EST) Received: from bb219-74-24-182.singnet.com.sg ([219.74.24.182] helo=fox.magix.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUMFj-0003xH-8F for nemo@ietf.org; Wed, 17 Nov 2004 04:37:28 -0500 Received: by fox.magix.com.sg (Postfix, from userid 1000) id 7251B177F54; Wed, 17 Nov 2004 17:34:26 +0800 (SGT) Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft From: Chan-Wah NG To: Fan Zhao In-Reply-To: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> References: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 17 Nov 2004 17:34:26 +0800 Message-Id: <1100684066.10489.47.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 On Sun, 2004-11-14 at 02:37 -0800, Fan Zhao wrote: > > > > > " There are multiple proposals for providing various forms of route > > > optimizations for NEMO (see Appendix A). " > > > Please delete the appendix. As some proposals are incomplete, even > some > > > does not work. What's more, some proposals look different but > actually > > > using > > > the same core idea. > > > > Perhaps, but that is not up to us to judge. The readers have to decide > > for themselves whether the individual proposals work or not. An > > appendix is an appendix. It is something that you could do without. I > > view the work done on ro-taxonomy-03.txt as a survey/review of what is > > the current state of RO solutions, and it felt incomplete without > > reference to all the proposals that have been made. > > > It is fine with me if you want to write your draft as a survey. But IMHO, > the NEMO RO peoblem WG document should not be just a survey. The analysis > of the complete solution space is one of the key values of this WG > document. You are now putting words into my mouth. No, i mean the appendix (and not the whole draft) is a review of the current state of RO solutions. > > > > > > > "3.1 MR-to-CN Optimization" "3.2 Infrastructure Optimization" > > > "3.3 Nested Tunnels Optimization" "3.4 MIPv6-over-NEMO Optimization" > > > "3.5 Intra-NEMO Optimization" > > > The solution space analysis part is organized like in the problem > > > statement part > > > to me. I do not see any logic behind the way you use to categorize > the > > > solution space. > > > Remember that the different problem scenarios do not mean the > different > > > solutions (core ideas). > > > > > > "Binding Update with Network Prefix" and "MR as a Proxy" use the same > > > idea to me and are > > > described in a too specific way. > > > > > Same idea? Are you sure? They may be solving the same problem (which > > is why we put them into the same "MR-to-CN" optimization, but they are > > entirely different. The former requires the MR to send prefix > > information to CN, the latter requires the MR to pretend to be the MNN. > > The core idea is quite different to me. > > > 1) The idea of these two is to distribute the binding information between > HoA and MNP/CoA to CN. Although they extend the MIP6 RO procedure in the > different ways, these kind of differences are secondary in the context of > NEMO RO. > 2) You want to "describe the solution space of route optimization by > listing different types of approach to route optimization." > So your approach listed in this sub-section has to solve the problem you > describe in the problem statement part. However, I do not see > how "Binding Update with Network Prefix" and "MR as a Proxy" solve the > problem completely including in the nested NEMO and intra-NEMO cases. Do > you agree? > 3) I can immediately come up with two "MR-to-CN optimization" approaches: > 3.1 MR does not send CoTi and HoTi on behalf of the MNN, instead it > intercepts the CoTi and HoTi sent by the MNN and changes the source IP > address in CoTi into its CoA. The rest is as same as in "MR as a proxy" > Agree, the part on MR as a Proxy is too detailed, (and the weak reason I offer is due to the short time from the idea popping up in the ML to the submission deadline). It will be changed in the next version. > > > "Infrastructure Optimization" I do not understand why "MR-to-CN > > > optimization" does not > > > possibly fall into this category. > > > > > > > Because it doesn't. Infrastructure optimization means some third party > > entity in the infrastructure takes part in the optimization. > > > So you'd better change the title. Because you list "Infrastructure > Optimization" and "MR-to-CN optimization" in parallel, the reader may > wonder why the path between MR and CN may not be in the infrastructure. > And again, the approach under this section does not solve the NEMO RO > problem completely. > > > > "Nested Tunnels Optimization" > > > "Nested tunnels" is not the core of nemo ro problem and it > > > sounds too specific too. It could make one reader wonder why other > tunnel- > > > reduction > > > methods are not listed. > > > > > > > Nested tunnel optimization is to reduce tunnel ... what other > > tunnel-reduction method you have in mind that does not fit into the > > descriptions of nested tunnel optimizations? > > > As I describe before, MR sends a probing packet to collect the full path > information to the Internet and registers it with CN, thus the data > packet only carries the information in the routing header alike payload > without tunnel. Does it fit into this category or MR-to-CN category? > > Since you list "MR-to-CN optimization", "Infrastructure Optimization" > and "Nested Tunnels Optimization" in parallel, what is the criterion you > used to differentiate the approaches into different types? > > And again, the approach under this section does not solve the NEMO RO > problem completely. > > > 4.1.1 Additional Signaling Overhead > > > The text of BU sould specific to me. The text of BU storm should > belong > > > to problem statement > > > part. > > > > > > > problem statement? Why? It is not a problem of NEMO Basic Support. It > > is a potential problem certain RO approaches might face. > > > If you look into the problem closely, the number of BU packets in NEMO > basic support is as same as in the NEMO RO if no method is used to reduce > the number of BU packets. If this is not the problem of NEMO basic > support, why it can become the problem in NEMO RO? So originally in NEMO > basic support protocol the number of BU packets can not be reduced, but > NEMO RO can look into this problem and find a way to reduce the overhead. I asaw you've retracted your objection in another mail. SO does this means that you agree BU_Storm should be an "issue" of RO solution, rather than a "problem " of NEMO Basic Support? > > > > As I've mentioned, I strive to be complete, and not mutually exclusive. > > My feeling is that we are very close to a complete description, once we > > feel in the parts on MANET as an RO appraoch. > > > How can you prove the completeness? > I don't. I disprove it by counter-example, and then add that counter example to the solution space, making it more complete everytime I do that. /rgds /cwng From nemo-bounces@ietf.org Wed Nov 17 06: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 GAA14171 for ; Wed, 17 Nov 2004 06:23:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUNnI-0000Vg-Ay; Wed, 17 Nov 2004 06:16:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUNi7-000782-FL for nemo@megatron.ietf.org; Wed, 17 Nov 2004 06:10: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 GAA13158 for ; Wed, 17 Nov 2004 06:10:48 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUNkV-0005zg-81 for nemo@ietf.org; Wed, 17 Nov 2004 06:13:20 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2004 12:34:13 +0100 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 iAHB9gek003375; Wed, 17 Nov 2004 12:10:15 +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); Wed, 17 Nov 2004 12:10: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] comments on solution space analysis part in taxonomy draft Date: Wed, 17 Nov 2004 12:10:09 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC4972F5@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] comments on solution space analysis part in taxonomy draft Thread-Index: AcTMieRLelHFyu+cRY+auBZUD4RIBQAC32bw From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah NG" , "Fan Zhao" X-OriginalArrivalTime: 17 Nov 2004 11:10:14.0917 (UTC) FILETIME=[03811B50:01C4CC96] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Dear Fan: > > How can you prove the completeness? > > >=20 > I don't. I disprove it by counter-example, and then add that counter example to the solution > space, making it more complete everytime I do that. I will not take that argument. I could try to accept the exclusiveness theory, but completeness seems hard to prove. We rely on the WG to pop up with anything we could have missed. EG Thierry's PhD on multicast BU (Sorry Thierry:) . This is not an academic exercise, either. We chose to trade a bit of redundancy for the sake of clarity. We have a limited overlap with the classification by applicability. Maybe it's better then holes.=20 Pascal From nemo-bounces@ietf.org Wed Nov 17 11:14: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 LAA13917 for ; Wed, 17 Nov 2004 11:14:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSKc-0003YA-7C; Wed, 17 Nov 2004 11:06:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSII-0002tr-6e for nemo@megatron.ietf.org; Wed, 17 Nov 2004 11:04:30 -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 LAA12134 for ; Wed, 17 Nov 2004 11:04:27 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSKj-0004Rw-JI for nemo@ietf.org; Wed, 17 Nov 2004 11:07:01 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAHG5x3B029359; Wed, 17 Nov 2004 09:05:59 -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 iAHG4PGa027889; Wed, 17 Nov 2004 10:04:25 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id ECF428A358D; Wed, 17 Nov 2004 17:04:24 +0100 (CET) Message-ID: <419B7688.3080508@motorola.com> Date: Wed, 17 Nov 2004 17:04:24 +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: Chan-Wah NG Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft References: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> <1100684066.10489.47.camel@localhost> In-Reply-To: <1100684066.10489.47.camel@localhost> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Chan-Wah NG wrote: > Agree, the part on MR as a Proxy is too detailed, (and the weak reason I > offer is due to the short time from the idea popping up in the ML to the > submission deadline). There was long discussion about how LFN would "delegate trust" to MR to do such RO operations on its behalf, check http://www.mobilenetworks.org/nemo/archives/monet-arch-feb02-oct02.txt and search for "delegation", or "trust delegation". Alex From nemo-bounces@ietf.org Wed Nov 17 12:02:14 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 MAA19499 for ; Wed, 17 Nov 2004 12:02:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSxv-0005hw-Q6; Wed, 17 Nov 2004 11:47:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSth-0004Jt-Le for nemo@megatron.ietf.org; Wed, 17 Nov 2004 11:43:09 -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 LAA17377 for ; Wed, 17 Nov 2004 11:43:06 -0500 (EST) Received: from bb219-74-19-78.singnet.com.sg ([219.74.19.78] helo=fox.magix.com.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSw6-0005fv-HG for nemo@ietf.org; Wed, 17 Nov 2004 11:45:41 -0500 Received: by fox.magix.com.sg (Postfix, from userid 1000) id C574B2C3D6C; Thu, 18 Nov 2004 00:42:31 +0800 (SGT) Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft From: Chan-Wah NG To: Alexandru Petrescu In-Reply-To: <419B7688.3080508@motorola.com> References: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> <1100684066.10489.47.camel@localhost> <419B7688.3080508@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 18 Nov 2004 00:42:31 +0800 Message-Id: <1100709751.10015.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 On Wed, 2004-11-17 at 17:04 +0100, Alexandru Petrescu wrote: > Chan-Wah NG wrote: > > Agree, the part on MR as a Proxy is too detailed, (and the weak reason I > > offer is due to the short time from the idea popping up in the ML to the > > submission deadline). > > There was long discussion about how LFN would "delegate trust" to MR to > do such RO operations on its behalf, check > http://www.mobilenetworks.org/nemo/archives/monet-arch-feb02-oct02.txt > and search for "delegation", or "trust delegation". > Okay, Alex, now you blast my weak reason/excuse to oblivion! :) Yep, I admit it was negligence on my part for deciding to write on the MR as a proxy approach the taxonomy very near the deadline, and Erik's summary was so much easier to "extract" than the whole thread on trust delegation ... /rgds /cwng From nemo-bounces@ietf.org Wed Nov 17 12:23: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 MAA21561 for ; Wed, 17 Nov 2004 12:23:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTCL-0000eh-H4; Wed, 17 Nov 2004 12:02:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUT1I-0006bX-LT for nemo@megatron.ietf.org; Wed, 17 Nov 2004 11:51: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 LAA18324 for ; Wed, 17 Nov 2004 11:50:57 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUT3j-0005wD-F2 for nemo@ietf.org; Wed, 17 Nov 2004 11:53:32 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAHGqU3B024121; Wed, 17 Nov 2004 09:52:30 -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 iAHGouvH028882; Wed, 17 Nov 2004 10:50:56 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4055C8A358D; Wed, 17 Nov 2004 17:50:56 +0100 (CET) Message-ID: <419B816F.6050006@motorola.com> Date: Wed, 17 Nov 2004 17:50:55 +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: Chan-Wah NG Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft References: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> <1100684066.10489.47.camel@localhost> <419B7688.3080508@motorola.com> <1100709751.10015.8.camel@localhost> In-Reply-To: <1100709751.10015.8.camel@localhost> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Chan-Wah NG wrote: > On Wed, 2004-11-17 at 17:04 +0100, Alexandru Petrescu wrote: > >> Chan-Wah NG wrote: >> >>> Agree, the part on MR as a Proxy is too detailed, (and the weak >>> reason I offer is due to the short time from the idea popping up >>> in the ML to the submission deadline). >> >> There was long discussion about how LFN would "delegate trust" to >> MR to do such RO operations on its behalf, check >> http://www.mobilenetworks.org/nemo/archives/monet-arch-feb02-oct02.txt >> and search for "delegation", or "trust delegation". >> > > > Okay, Alex, now you blast my weak reason/excuse to oblivion! :) No no! Just to say that if you need more on this particular topic maybe there could be found some... no intention to blast whatever! :-) > Yep, I admit it was negligence on my part for deciding to write on > the MR as a proxy approach the taxonomy very near the deadline, and > Erik's summary was so much easier to "extract" than the whole thread > on trust delegation ... That is right, and in addition there should be mention somewhere that MR doing RO on behalf of LFN means that LFN trust somehow MR to do so. Alex From nemo-bounces@ietf.org Wed Nov 17 13:30:20 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 NAA27659 for ; Wed, 17 Nov 2004 13:30:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUVq-0003aL-PO; Wed, 17 Nov 2004 13:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUTJ-0003EG-UH for nemo@megatron.ietf.org; Wed, 17 Nov 2004 13:24:01 -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 NAA27182 for ; Wed, 17 Nov 2004 13:23:58 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUVm-0008ME-FM for nemo@ietf.org; Wed, 17 Nov 2004 13:26:34 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAHIPV3B002249 for ; Wed, 17 Nov 2004 11:25:31 -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 iAHIMhSO009305 for ; Wed, 17 Nov 2004 12:22:43 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B0F728A358D for ; Wed, 17 Nov 2004 19:23:57 +0100 (CET) Message-ID: <419B973D.3000709@motorola.com> Date: Wed, 17 Nov 2004 19:23:57 +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: nemo@ietf.org X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [nemo] My simple thoughts on HAHA 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 HAHA is a method for MR to change its HA from a remote one to a closer one. It implies that paths from CN to MR's HoA are changed from reaching the oldHA to reaching the newHA. These changes are presumably done with a dynamic routing protocol. HAHA also involves synchronizing the BCs of the two HAs such as to both know the current MR's CoA. HAHA is presumably justified _only_ if the IP distance CN-oHA + oHA-MR is much longer than CN-nHA + nHA-MR. Add to this that the IP distance oHA-nHA must be small in order to allow for route updates to not explose routing tables. The distances CN-oHA and CN-nHA are potentially both much larger than the distance oHA-nHA, which should be small. To me, this means that: if you can use route updates to update paths to MR, and if the new paths are _much_ shorter, then use this and there is no need to use Mobile IP too. Any comments greatly appreciated, take this as my humble oppinion, and also note that there was/is a similar but still very different effort within mip4 WG (Dynamic Assignment of the HA) to which I contributed some discussion and on some points I've learned from them. http://www.atm.tut.fi/list-archive/MIPv4/msg00043.html Alex From nemo-bounces@ietf.org Wed Nov 17 13:40:18 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 NAA28431 for ; Wed, 17 Nov 2004 13:40: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 1CUUhA-0005jX-5Z; Wed, 17 Nov 2004 13:38:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSlq-0002FP-8i for nemo@megatron.ietf.org; Wed, 17 Nov 2004 11:35: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 LAA16328 for ; Wed, 17 Nov 2004 11:34:59 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSoH-0005O2-Mz for nemo@ietf.org; Wed, 17 Nov 2004 11:37:34 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA04748; Wed, 17 Nov 2004 10:34:29 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iAHGYTt29059; Wed, 17 Nov 2004 08:34:29 -0800 (PST) Received: from XCH-NW-31.nw.nos.boeing.com ([192.48.4.105]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 08:34:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] Announcing the Global HAHA draft Date: Wed, 17 Nov 2004 08:34:29 -0800 Message-ID: Thread-Topic: [nemo] Announcing the Global HAHA draft Thread-Index: AcSvbX6+v05xk+qZQQypTDE+NEAcpQbxx2jQ From: "Dul, Andrew L" To: X-OriginalArrivalTime: 17 Nov 2004 16:34:29.0347 (UTC) FILETIME=[4F3F8B30:01C4CCC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 17 Nov 2004 13:38:18 -0500 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 Pascal, I'd like to introduce myself, I'm a member of the Connexion by Boeing networking team and have been following the NEMO list for about 8 months or so at this point. I'll have to apologize for not being completely up-to-date on all the drafts within the working group as I have other work pulling me in other directions. :) I was unable to attend the ietf meeting last week, I hope to be able to attend in the future to discuss this with the working group. I was just able to review the slides that you presented at the meeting. Were there any interesting comments at the meeting regarding global-haha that you could summarize to the list? In the mean time, I hope my comments below are helpful in starting the discussion. I'd like to thank you & others for producing the global-haha draft. I do think it makes sense to split the drafts since from my perspective a global mobility solution may be quite different than one that is even optimized for regional mobility. =20 I think one of the reasons why you haven't seen a lot of interest on this draft is that the truly global mobility market is really very small. The aircraft industry also tends to move quite slow compared with the speed of technology & adoption in the "Internet" space. When I think about the objects that are really truly globally mobile in most cases they are limited to aircraft, maritime vessels, & people. Even when you think about people further, we are mostly regionally mobile. Sure we travel to different parts of the globe but most of us are generally only regionally mobile, and when we are outside of our normal region we are often there for only shorter periods of time. Jet aircraft are somewhat unique in that they can traverse the entire globe within a single day. =20 As I read through the draft (4.1.1.) I can see areas where the tunneling in a global environment can still cause a large increase in latency. Consider the following case. Service provider A has a ground global-haha network that an aircraft attach to in London & Sydney, in this case the aircraft is owned by company Z with operations in Chicago served by Service provider B. The plane is on the ground in Sydney and maintenance staff are using the onboard IP phone to talk to operations staff in Chicago. Given a set of BGP routing tables it is possible that the path through the London HA would be a perceived best path from Chicago. In this case the call would be routed from Chicago to London to Sydney instead of directly to Sydney. In the v4 world we have used a BGP rehoming solution that can largely negate this issue. At this point it is unclear to me if a similar rehoming solution is possible or desirable in the multihomed v6 world. This also may be too much of a corner case but it is nonetheless an interesting case. In my opinion I believe that for a global mobility standard to be truly successful it must allow for the mobile networks to roam between service providers & BGP ASNs. This aspect brings up another whole set of issues with address allocation, v6 multi-homing, and integration with BGP. (Which maybe outside the scope of the NEMO charter?) I also note that many of these issues are still not finalized in the v6 world from my current readings. Authentication & Authorization for MR's to the mesh between ASNs is also a consideration. As Terry Davis one of my colleagues stated in a previous mail, it is likely that the aircraft networks will be connected to a number of other networks via different mechanisms, some of them will be satellite based, some air-to-ground, and some ground-to-ground when the aircraft is between flights. Specifically for the ground-to-ground links it is unlikely that a single service provider would be able to provide global coverage at any large majority of world airports. =20 Thanks for your time, Andrew ----------------------- Andrew L. Dul Network Design Engineer=09 ConneXion by Boeing(SM)=20 > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Monday, October 11, 2004 1:37 AM > To: vijay.devarapalli@nokia.com; ryuji@sfc.wide.ad.jp > Cc: nemo > Subject: [nemo] Announcing the Global HAHA draft >=20 >=20 > As a result of the discussions at the previous IETF and in the ML, we=20 > decided to split the HAHA draft in a local part that covers intra-site > load balancing and high availability, and a global part that enables=20 > the geographical distribution of Home over the Internet. >=20 > The version 00 of the global HAHA draft is now available at: >=20 http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.tx t Pascal From nemo-bounces@ietf.org Wed Nov 17 14:03: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 OAA29874 for ; Wed, 17 Nov 2004 14:03: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 1CUUxH-000195-Le; Wed, 17 Nov 2004 13:54:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUwi-00010a-7n for nemo@megatron.ietf.org; Wed, 17 Nov 2004 13:54: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 NAA29423 for ; Wed, 17 Nov 2004 13:54:22 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUzB-0000UA-18 for nemo@ietf.org; Wed, 17 Nov 2004 13:56:57 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAHIPf703031; Wed, 17 Nov 2004 10:25:41 -0800 X-mProtect: <200411171825> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141167.americas.nokia.com (172.18.141.167, claiming to be "[172.18.141.167]") by darkstar.iprg.nokia.com smtpdmwqHOb; Wed, 17 Nov 2004 10:25:39 PST Message-ID: <419B9E2B.1080905@iprg.nokia.com> Date: Wed, 17 Nov 2004 10:53:31 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Problems in the draft-03 References: <1100622563.26359.11.camel@escorpion> <419A33D7.7010409@motorola.com> In-Reply-To: <419A33D7.7010409@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 you can have internet drafts in Informative references. I will add HMIPv6 to the informative references section (since you dont need to know HMIPv6 to implement NEMO). Vijay Alexandru Petrescu wrote: > Antonio, thanks for the message and for looking at implementing. > > You're right that the M bit comes before the R bit and that HMIPv6 is > not referenced in the NEMO document and thanks for pointing this out. > An explanation of this affair may be that neither the NEMO document nor > the HMIPv6 document are currently RFCs. They're both in the RFC queue, > with a certain level of consensus roughness achieved. So it's difficult > to reference each other right now. It is usual to refer a draft from a > draft, and an RFC from a draft, but one would avoid referring a draft > from an RFC, no? > > We've had a number of other remarks on text of the NEMO basic support > draft-03 that are also important and we've had the option of either > applying all the agreed changes on the current draft-03 or maybe wait > for it to become an RFC and re-issue rfcbis. Vijay and Chairs can tell > more about this, it's a gray area for me at this point. > > Alex > > Antonio de la Oliva Delgado wrote: > >> Hi all, >> >> We are implementing the NEMO Basic Support Protocol within the >> framework of the DAIDALOS European project. When dealing with the BU >> message format part of the I-D, we have found that, IMHO, there is >> some text that is not completely clear for a developer. The section >> 4.1 says: >> >> "A new flag (R) is included in the Binding Update to indicate to the >> Home Agent if 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 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> | . . . >> Mobility options . . >> . | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " >> >> Reference [1] (RFC3775) says the following about the BU message >> format: >> >> "The Binding Update uses the MH Type value 5. When this value is >> indicated in the MH Type field, the format of the Message Data field >> in the Mobility Header is as follows: >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A|H|L|K| Reserved | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> | . . . >> Mobility options . . >> . | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " >> >> The bit M is not defined in RFC3775 or in the Nemo draft, but in the >> HMIPv6 I-D (draft-ietf-mipshop-hmipv6-03.txt). >> >> Therefore, I would suggest to reflect in the current text of the NEMO >> Basic Support protocol, some reference about the HMIPv6 >> specification. >> >> Kind Regards, Antonio de la Oliva Carlos J. >> >> > > From nemo-bounces@ietf.org Wed Nov 17 19:27:04 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 TAA06390 for ; Wed, 17 Nov 2004 19:27: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 1CUa6I-0001Sz-Ft; Wed, 17 Nov 2004 19:24:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUa21-0000Fv-Lx for nemo@megatron.ietf.org; Wed, 17 Nov 2004 19:20:14 -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 TAA05675 for ; Wed, 17 Nov 2004 19:20:10 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUa4W-0001hM-De for nemo@ietf.org; Wed, 17 Nov 2004 19:22:49 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAI0JXnG013417; Thu, 18 Nov 2004 09:19:33 +0900 Date: Thu, 18 Nov 2004 09:01:21 +0900 Message-ID: From: Ryuji Wakikawa To: fanzhao@ucdavis.edu Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft In-Reply-To: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> References: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> 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: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org, cwng@psl.com.sg 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 Fan At Sun, 14 Nov 2004 02:37:41 -0800 (PST), Fan Zhao wrote: > > > > > > "3.1 MR-to-CN Optimization" "3.2 Infrastructure Optimization" > > > "3.3 Nested Tunnels Optimization" "3.4 MIPv6-over-NEMO Optimization" > > > "3.5 Intra-NEMO Optimization" > > > The solution space analysis part is organized like in the problem > > > statement part > > > to me. I do not see any logic behind the way you use to categorize > the > > > solution space. > > > Remember that the different problem scenarios do not mean the > different > > > solutions (core ideas). > > > > > > "Binding Update with Network Prefix" and "MR as a Proxy" use the same > > > idea to me and are > > > described in a too specific way. > > > > > Same idea? Are you sure? They may be solving the same problem (which > > is why we put them into the same "MR-to-CN" optimization, but they are > > entirely different. The former requires the MR to send prefix > > information to CN, the latter requires the MR to pretend to be the MNN. > > The core idea is quite different to me. > > > 1) The idea of these two is to distribute the binding information between > HoA and MNP/CoA to CN. Although they extend the MIP6 RO procedure in the > different ways, these kind of differences are secondary in the context of > NEMO RO. In the case of "MR as a Proxy", MR sends MNN-address and MR-CoA (not HoA/MNP/CoA) to CN as a MIP binding. Binding information registering to CN is different. But I agree with Fan that the text in the draft is very solution specific. > > > "Infrastructure Optimization" I do not understand why "MR-to-CN > > > optimization" does not > > > possibly fall into this category. > > > > > > > Because it doesn't. Infrastructure optimization means some third party > > entity in the infrastructure takes part in the optimization. > > > So you'd better change the title. Because you list "Infrastructure > Optimization" and "MR-to-CN optimization" in parallel, the reader may > wonder why the path between MR and CN may not be in the infrastructure. > And again, the approach under this section does not solve the NEMO RO > problem completely. I believe Pascal wanted to classify whether end nodes involve RO procedure or not :-) What do you mean the approach does not solve the NEMO RO completely? These approaches may not solve RO issues completely, but they improve NEMO performance in certain level. It is very important to know which approach can solve which issue. With knowing possible approaches, we can judge whether WG needs the approach or not. > > > 4.1.1 Additional Signaling Overhead > > > The text of BU sould specific to me. The text of BU storm should > belong > > > to problem statement > > > part. > > > > > > > problem statement? Why? It is not a problem of NEMO Basic Support. It > > is a potential problem certain RO approaches might face. > > > If you look into the problem closely, the number of BU packets in NEMO > basic support is as same as in the NEMO RO if no method is used to reduce > the number of BU packets. If this is not the problem of NEMO basic > support, why it can become the problem in NEMO RO? So originally in NEMO > basic support protocol the number of BU packets can not be reduced, but > NEMO RO can look into this problem and find a way to reduce the overhead. I can not get your point. In the NEMO basic, MR sends single BU to HA. If MR decided to send BU to CNs, #of BU is increased as #of CNs. regards, ryuji From nemo-bounces@ietf.org Wed Nov 17 19:29: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 TAA06562 for ; Wed, 17 Nov 2004 19:29:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUa6J-0001TJ-0b; Wed, 17 Nov 2004 19:24:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUa22-0000GX-7g for nemo@megatron.ietf.org; Wed, 17 Nov 2004 19:20:14 -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 TAA05678 for ; Wed, 17 Nov 2004 19:20:10 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUa4X-0001hZ-QV for nemo@ietf.org; Wed, 17 Nov 2004 19:22:50 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAI0JQnG013414; Thu, 18 Nov 2004 09:19:26 +0900 Date: Thu, 18 Nov 2004 08:33:51 +0900 Message-ID: From: Ryuji Wakikawa To: pthubert@cisco.com Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, cwng@psl.com.sg 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 Pascal. At Fri, 12 Nov 2004 17:46:36 +0100, pascal wrote: > > > > > > Overall, the solution space part does not analyze the space > completely and > > > does not categorize the solution space into mutual exclusive > categories. > > > > As I've mentioned, I strive to be complete, and not mutually > exclusive. > > My feeling is that we are very close to a complete description, once > we > > feel in the parts on MANET as an RO appraoch. > > > Agreed. We have a little duplication and we can improve some of it. This > is not last call yet, is it :?) not yet:-p > We have been encouraging people to speak up if they think something is > missing for quite some time. If the doc serves as source for the WG > document, then maybe more people will feel encouraged to contribute even > more to the discussion and propose additional content. I supports taxonomy draft as a WG document. Although there are several texts saying particular solution, we can improve it after it being WG document. I want to merge exisiting PS drafts to this taxonomy. draft-watari has many clasification of nested case and draft-clausen explains possiblity of exchanging routes between MRs. regards, ryuji > That question was raised by the chairs and delayed because of > accusations of partiality that now seem to be unfounded. On the ML, Fan > expressed his opposition on some grounds that we are discussing > currently. > > As of now, I strongly feel the taxonomy draft is a good base and that > the cost of starting over is not justified by the arguments that were > produced and the alternates that were outlined. > > Pascal From nemo-bounces@ietf.org Wed Nov 17 19:30:29 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 TAA06796 for ; Wed, 17 Nov 2004 19:30:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUa70-0001hi-OD; Wed, 17 Nov 2004 19:25:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUa35-0000Sl-3C for nemo@megatron.ietf.org; Wed, 17 Nov 2004 19:21:19 -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 TAA05764 for ; Wed, 17 Nov 2004 19:21:15 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUa5Z-0001j4-NC for nemo@ietf.org; Wed, 17 Nov 2004 19:23:54 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAI0JcnG013423; Thu, 18 Nov 2004 09:19:38 +0900 Date: Thu, 18 Nov 2004 09:12:43 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft In-Reply-To: <4197B0A4.3030903@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> <012CAB80-34E0-11D9-8AE2-000A95DA08F2@kniveton.com> <4197B0A4.3030903@motorola.com> 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: ea4ac80f790299f943f0a53be7e1a21a Cc: nemo@ietf.org, tj@kniveton.com, pthubert@cisco.com, cwng@psl.com.sg 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 Alex At Sun, 14 Nov 2004 20:23:16 +0100, Alexandru Petrescu wrote: > Within the Problem Statement, I think the draft fails to mention that > optimal routes for NEMO could be obtained by injecting routes in the > visited domain but that brings in other bigger problem. This problem is > also one of the reasons why Mobile IP for hosts was developped the way > it was, but I think it deserves brief mentioning in a NEMO RO PS > (Problem Statement, not Proposed Standard, not PostScript) document too. > Or maybe this problem is already too basic to be mentioned here. draft-clausen provides some thoughts on how MR can inject routes for nesting case. > So in section 4.2.2 Infrastructure Optimization, if we do this, we need > a method to Discover Correspondent Routers, right? Do you know of such > a method? The discovery of CR is not always necessary. For example, CR can be statically configured to MR. If I have CR in my home, MR can always send BU to CR no matter my mobile network communicates to my home. regards, ryuji From nemo-bounces@ietf.org Thu Nov 18 01:08: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 BAA03237 for ; Thu, 18 Nov 2004 01:08:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUfP3-0001Yk-Ln; Thu, 18 Nov 2004 01:04:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUfMU-0000x2-8E for nemo@megatron.ietf.org; Thu, 18 Nov 2004 01:01: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 BAA02953 for ; Thu, 18 Nov 2004 01:01:40 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUfP2-0000SM-Cn for nemo@ietf.org; Thu, 18 Nov 2004 01:04:21 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAI60tnG017431; Thu, 18 Nov 2004 15:00:55 +0900 Date: Thu, 18 Nov 2004 15:00:50 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] My simple thoughts on HAHA In-Reply-To: <419B973D.3000709@motorola.com> References: <419B973D.3000709@motorola.com> 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: 769a46790fb42fbb0b0cc700c82f7081 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 Alex Thanks for comments. At Wed, 17 Nov 2004 19:23:57 +0100, Alexandru Petrescu wrote: > > HAHA is a method for MR to change its HA from a remote one to a closer > one. It implies that paths from CN to MR's HoA are changed from > reaching the oldHA to reaching the newHA. These changes are presumably > done with a dynamic routing protocol. HAHA also involves synchronizing > the BCs of the two HAs such as to both know the current MR's CoA. I believe you read the global-HAHA draft. > HAHA is presumably justified _only_ if the IP distance CN-oHA + oHA-MR > is much longer than CN-nHA + nHA-MR. Yes for path improvement. > Add to this that the IP distance oHA-nHA must be small in order to > allow for route updates to not explose routing tables. Can you clarify this? The distance of oHA and nHA is not critical. > To me, this means that: if you can use route updates to update paths to > MR, and if the new paths are _much_ shorter, then use this and there is > no need to use Mobile IP too. When HA propagates the home network prefix to the Internet, the route entry is never changed unless HA changes its address. (The route is relatively stable). On the other hand, the path to MR is changed according to MR's movement. Propagation of route updaes from MR is not doable. We still need MobileIP. > Any comments greatly appreciated, take this as my humble oppinion, and > also note that there was/is a similar but still very different effort > within mip4 WG (Dynamic Assignment of the HA) to which I contributed > some discussion and on some points I've learned from them. > http://www.atm.tut.fi/list-archive/MIPv4/msg00043.html Thanks for reference. regards, ryuji From nemo-bounces@ietf.org Thu Nov 18 02:25: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 CAA24051 for ; Thu, 18 Nov 2004 02:25:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgdt-0008Ti-PY; Thu, 18 Nov 2004 02:23:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgb5-0006yF-AI for nemo@megatron.ietf.org; Thu, 18 Nov 2004 02:20: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 CAA23442 for ; Thu, 18 Nov 2004 02:20:49 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUgde-0001yQ-4b for nemo@ietf.org; Thu, 18 Nov 2004 02:23:30 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAI7JvnG018352; Thu, 18 Nov 2004 16:20:16 +0900 Date: Thu, 18 Nov 2004 16:19:52 +0900 Message-ID: From: Ryuji Wakikawa To: cjbc@it.uc3m.es In-Reply-To: <1099906490.2545.12.camel@acorde> References: <1099906490.2545.12.camel@acorde> 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, ryuji@sfc.wide.ad.jp Subject: [nemo] Re: Comments on draft-clausen-nemo-ro-problem-statement-00.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: quoted-printable Hello Carlos Sorry for late reply. You are right.=20 We can not achieve an optimal route for Internet-toNEMO only with MANET. In the Internet-to-"Nested"NEMO case, MANET can help optmized routing for a few hops (that are inside nested NEMO). For example, if nested MR sends BU with root-MR's CoA, packets are directly reached to root-MR and root-MR can route packets to the nested MR by MANET. You may be interested in ORC draft. http://www1.ietf.org/internet-drafts/draft-wakikawa-nemo-orc-00.txt thanks ryuji At Mon, 08 Nov 2004 10:34:50 +0100, Carlos Jes=C3=BAs Bernardos Cano wrote: >=20 > [1 ] > Hi Ryuji, >=20 > First of all, thanks for submitting the draft. >=20 > Your draft seems to address the problem of the Internet-to-NEMO > communication and the NEMO-to-NEMO communication when nesting is > involved, using a MANET approach. I agree with you that in the > NEMO-to-NEMO approach, having the MRs in a nested-NEMO running an Ad-Hoc > routing protocol would help to avoid traversing the Internet and also > avoid the encapsulation. On the other hand, I don't see that clear how > this would help the Internet-to-NEMO, at least as it is now described in > the current version of your draft. >=20 > The draft says: >=20 > "Additionally, this would also ease the Internet-to-NEMO scenario. In > order to deliver an IP datagram to a node in the nested NEMO network, > only a path to the access router between the nested NEMO network and > the Internet would be required: once an IP datagram arrives in the > nested NEMO network, the routing tables in the mobile routers, as > provided by OLSR, would allow direct routing to the destination. > Thus, there would no longer be a requirement to do nested encapsula- > tion on each logical hop (i.e. each transversal of a Home Agent) in > order to be able to decapsulate and correctly forward IP datagrams in > the nested NEMO network. >=20 >=20 > Thus even if no route optimizations are performed in the Internet-to- > NEMO scenario, an overhead reduction can still be achieved through > much lower encapsulation requirements." >=20 > How this improvements are achieved? If a CN in the Internet sends a > packet to a MNN that is connected to a nested-NEMO, the packet would > traverse the HAs of every MR in the nested-NEMO until the MNN is finally > reached. Therefore, I don't see how this encapsulation would be avoided, > without making any additional change to the MR and/or HA and/or CN. Am I > missing something? >=20 > Thanks in advance. >=20 > Kind Regards, >=20 > Carlos J. >=20 > --=20 > Carlos Jes=C3=BAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > [2 Esta parte del mensaje est=C3=A1 firmada digitalmente ] >=20 From nemo-bounces@ietf.org Thu Nov 18 02:28:22 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 CAA24483 for ; Thu, 18 Nov 2004 02:28: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 1CUgdu-0008UE-Hj; Thu, 18 Nov 2004 02:23:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgbI-000784-Dz for nemo@megatron.ietf.org; Thu, 18 Nov 2004 02:21: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 CAA23473 for ; Thu, 18 Nov 2004 02:21:02 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUgdr-0001yd-5e for nemo@ietf.org; Thu, 18 Nov 2004 02:23:44 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAI7KQnG018370; Thu, 18 Nov 2004 16:20:26 +0900 Date: Thu, 18 Nov 2004 15:43:32 +0900 Message-ID: From: Ryuji Wakikawa To: andrew.l.dul@boeing.com Subject: Re: [nemo] Announcing the Global HAHA draft 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: 6ffdee8af20de249c24731d8414917d3 Cc: nemo@ietf.org, pthubert@cisco.com 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 Andrew At Wed, 17 Nov 2004 08:34:29 -0800, Dul, Andrew L wrote: > > Hello Pascal, > > I'd like to introduce myself, I'm a member of the Connexion by Boeing > networking team and have been following the NEMO list for about 8 months > or so at this point. I'll have to apologize for not being completely > up-to-date on all the drafts within the working group as I have other > work pulling me in other directions. :) I was unable to attend the > ietf meeting last week, I hope to be able to attend in the future to > discuss this with the working group. I was just able to review the > slides that you presented at the meeting. Were there any interesting > comments at the meeting regarding global-haha that you could summarize > to the list? > > In the mean time, I hope my comments below are helpful in starting the > discussion. > > I'd like to thank you & others for producing the global-haha draft. I > do think it makes sense to split the drafts since from my perspective a > global mobility solution may be quite different than one that is even > optimized for regional mobility. > > I think one of the reasons why you haven't seen a lot of interest on > this draft is that the truly global mobility market is really very > small. The aircraft industry also tends to move quite slow compared > with the speed of technology & adoption in the "Internet" space. When I > think about the objects that are really truly globally mobile in most > cases they are limited to aircraft, maritime vessels, & people. Even > when you think about people further, we are mostly regionally mobile. > Sure we travel to different parts of the globe but most of us are > generally only regionally mobile, and when we are outside of our normal > region we are often there for only shorter periods of time. Jet > aircraft are somewhat unique in that they can traverse the entire globe > within a single day. The airplane is perfectly applicable scenario. There are also useful cases without globally physical movements. For example, automobile industry is also interested in this topic. When considering Europe automobile market, where can they put HA? 1 HA for each country? Commercial tracks often drive beyond countries. If I got Japanese car in Europe, MNP might be configured with the home network in Japan. > As I read through the draft (4.1.1.) I can see areas where the tunneling > in a global environment can still cause a large increase in latency. > Consider the following case. Service provider A has a ground > global-haha network that an aircraft attach to in London & Sydney, in > this case the aircraft is owned by company Z with operations in Chicago > served by Service provider B. The plane is on the ground in Sydney and > maintenance staff are using the onboard IP phone to talk to operations > staff in Chicago. Given a set of BGP routing tables it is possible > that the path through the London HA would be a perceived best path from > Chicago. In this case the call would be routed from Chicago to London > to Sydney instead of directly to Sydney. In the v4 world we have used a > BGP rehoming solution that can largely negate this issue. At this point > it is unclear to me if a similar rehoming solution is possible or > desirable in the multihomed v6 world. This also may be too much of a > corner case but it is nonetheless an interesting case. Isn't it possible that service provider B joins the global-haha network of service provider A? And if service provider A advertise the same prefix from London and Sydney to BGP, operator in Chicago should pick the path via Sydney (when IP distance is really shorter). > In my opinion I believe that for a global mobility standard to be truly > successful it must allow for the mobile networks to roam between service > providers & BGP ASNs. This aspect brings up another whole set of issues > with address allocation, v6 multi-homing, and integration with BGP. > (Which maybe outside the scope of the NEMO charter?) I also note that > many of these issues are still not finalized in the v6 world from my > current readings. Authentication & Authorization for MR's to the mesh > between ASNs is also a consideration. As Terry Davis one of my > colleagues stated in a previous mail, it is likely that the aircraft > networks will be connected to a number of other networks via different > mechanisms, some of them will be satellite based, some air-to-ground, > and some ground-to-ground when the aircraft is between flights. > Specifically for the ground-to-ground links it is unlikely that a single > service provider would be able to provide global coverage at any large > majority of world airports. Global-HAHA enables full HA operations on IP layer. It means we can put HAs over ASN if each HA advertise the same home network prefix by BGP. It might be possible to see some super ISP beyond ASN for globally mobility in near future:-) regards, ryuji > Thanks for your time, > Andrew > > > ----------------------- > Andrew L. Dul > Network Design Engineer > ConneXion by Boeing(SM) > > > > > -----Original Message----- > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > Sent: Monday, October 11, 2004 1:37 AM > > To: vijay.devarapalli@nokia.com; ryuji@sfc.wide.ad.jp > > Cc: nemo > > Subject: [nemo] Announcing the Global HAHA draft > > > > > > As a result of the discussions at the previous IETF and in the ML, we > > decided to split the HAHA draft in a local part that covers intra-site > > > load balancing and high availability, and a global part that enables > > the geographical distribution of Home over the Internet. > > > > The version 00 of the global HAHA draft is now available at: > > > > http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.tx > t > > Pascal > From nemo-bounces@ietf.org Thu Nov 18 04:03:21 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 EAA02495 for ; Thu, 18 Nov 2004 04:03:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUi8C-0000Im-4f; Thu, 18 Nov 2004 03:59:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUi6k-0008Cr-BN for nemo@megatron.ietf.org; Thu, 18 Nov 2004 03:57:39 -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 DAA02087 for ; Thu, 18 Nov 2004 03:57: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 1CUi9J-0003r9-Jo for nemo@ietf.org; Thu, 18 Nov 2004 04:00:19 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2004 10:03:52 +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 iAI8uxeG028452; Thu, 18 Nov 2004 09:56:59 +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, 18 Nov 2004 09:56:59 +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: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt Date: Thu, 18 Nov 2004 09:56:56 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC497703@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt Thread-Index: AcTNP/4di5tkAfAFRo2rB/O3qI6hnwACNH3g From: "Pascal Thubert \(pthubert\)" To: "Ryuji Wakikawa" , , "Greg Daley" X-OriginalArrivalTime: 18 Nov 2004 08:56:59.0023 (UTC) FILETIME=[8FFE41F0:01C4CD4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 Right. I believe that there is a great interest in digging more into a MANET = based solutions.=20 But We can not say 'any MANET' will do. We must explicit what our = priorities are and what features we care for. And we must come back with = a single MANET version so there's a chance to get standard track one = day. Example of requirements: 1) The MObile Adhoc for NEMO should primarily focus on providing a = default route to the infrastructure for each node. 2) Then it should provide the capability for routers to exchange routes = and communicate even if a connection to the infrastructure is not = available. 3) It should allow the formation of a nested NEMO in a controlled = fashion. In particular, it should be possible to form specific groups, = control the size and other topological criteria.=20 4) There should be a solution to interconnect nested NEMOs as opposed to = forming ever larger structures. 5) The Protocol must fit in a nested NEMO solution where redistribution = of the NEMO prefixes into the infrastructure is not required. In that = solution, Mobile Routers can form a NEMO CareOf address from an address = or a prefix that is topologically correct at the edge of the nested = NEMO. 6) ... In my mind,=20 1) is more in the proactive side since it is the most important route = for NEMO.=20 2) means that our specific MANET must exchange prefixes, but does not = imply it should be proactive. In fact, in many scenarios, it is not used = at all (eg. Individuals in Bus, trains, etc...) . But in some scenarios, = it is mandatory and has to cope with some good degree of inner mobility = (eg. Earthquake). So It see that as either on-demand, or in a LORA = space, to limit the operational cost.=20 I'm not sure that from the current charter, the NEMO list is the right = place to discuss all this, though... sorry about that. Pascal > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of Ryuji Wakikawa > Sent: jeudi 18 novembre 2004 08:20 > To: cjbc@it.uc3m.es > Cc: nemo@ietf.org; ryuji@sfc.wide.ad.jp > Subject: [nemo] Re: Comments = ondraft-clausen-nemo-ro-problem-statement-00.txt >=20 >=20 > Hello Carlos >=20 > Sorry for late reply. >=20 > You are right. >=20 > We can not achieve an optimal route for Internet-toNEMO only with > MANET. In the Internet-to-"Nested"NEMO case, MANET can help optmized > routing for a few hops (that are inside nested NEMO). >=20 > For example, if nested MR sends BU with root-MR's CoA, packets are > directly reached to root-MR and root-MR can route packets to the > nested MR by MANET. You may be interested in ORC draft. > http://www1.ietf.org/internet-drafts/draft-wakikawa-nemo-orc-00.txt >=20 > thanks > ryuji >=20 >=20 >=20 > At Mon, 08 Nov 2004 10:34:50 +0100, > Carlos Jes=FAs Bernardos Cano wrote: > > > > [1 ] > > Hi Ryuji, > > > > First of all, thanks for submitting the draft. > > > > Your draft seems to address the problem of the Internet-to-NEMO > > communication and the NEMO-to-NEMO communication when nesting is > > involved, using a MANET approach. I agree with you that in the > > NEMO-to-NEMO approach, having the MRs in a nested-NEMO running an = Ad-Hoc > > routing protocol would help to avoid traversing the Internet and = also > > avoid the encapsulation. On the other hand, I don't see that clear = how > > this would help the Internet-to-NEMO, at least as it is now = described in > > the current version of your draft. > > > > The draft says: > > > > "Additionally, this would also ease the Internet-to-NEMO = scenario. In > > order to deliver an IP datagram to a node in the nested NEMO = network, > > only a path to the access router between the nested NEMO network = and > > the Internet would be required: once an IP datagram arrives in = the > > nested NEMO network, the routing tables in the mobile routers, as > > provided by OLSR, would allow direct routing to the destination. > > Thus, there would no longer be a requirement to do nested = encapsula- > > tion on each logical hop (i.e. each transversal of a Home Agent) = in > > order to be able to decapsulate and correctly forward IP = datagrams in > > the nested NEMO network. > > > > > > Thus even if no route optimizations are performed in the = Internet-to- > > NEMO scenario, an overhead reduction can still be achieved = through > > much lower encapsulation requirements." > > > > How this improvements are achieved? If a CN in the Internet sends a > > packet to a MNN that is connected to a nested-NEMO, the packet would > > traverse the HAs of every MR in the nested-NEMO until the MNN is = finally > > reached. Therefore, I don't see how this encapsulation would be = avoided, > > without making any additional change to the MR and/or HA and/or CN. = Am I > > missing something? > > > > Thanks in advance. > > > > Kind Regards, > > > > Carlos J. > > > > -- > > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > > [2 Esta parte del mensaje est=E1 firmada digitalmente = ] > > From nemo-bounces@ietf.org Thu Nov 18 04:57:13 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 EAA07066 for ; Thu, 18 Nov 2004 04:57: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 1CUixY-0003Ep-5G; Thu, 18 Nov 2004 04:52:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUiwW-0002mT-DX for nemo@megatron.ietf.org; Thu, 18 Nov 2004 04:51: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 EAA06581 for ; Thu, 18 Nov 2004 04:51:05 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUiz6-000565-8d for nemo@ietf.org; Thu, 18 Nov 2004 04:53:49 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id iAI9r96i011155; Thu, 18 Nov 2004 02:53:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id iAI9mPi7030984; Thu, 18 Nov 2004 03:48:25 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 62C7B8A3C6C; Thu, 18 Nov 2004 10:51:02 +0100 (CET) Message-ID: <419C7085.2070905@motorola.com> Date: Thu, 18 Nov 2004 10:51:01 +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: Ryuji Wakikawa Subject: Re: [nemo] My simple thoughts on HAHA References: <419B973D.3000709@motorola.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Ryuji, thanks for your remarks. I have some remarks, see below. I agree with you half half. Ryuji Wakikawa wrote: > Alexandru Petrescu wrote: > >> HAHA is a method for MR to change its HA from a remote one to a >> closer one. It implies that paths from CN to MR's HoA are changed >> from reaching the oldHA to reaching the newHA. These changes are >> presumably done with a dynamic routing protocol. HAHA also >> involves synchronizing the BCs of the two HAs such as to both know >> the current MR's CoA. > > I believe you read the global-HAHA draft. Yes. I think my remarks pertain to both drafts (HAHA and global HAHA). >> HAHA is presumably justified _only_ if the IP distance CN-oHA + >> oHA-MR is much longer than CN-nHA + nHA-MR. > > Yes for path improvement. Is there another justification and need for HAHA other than path improvement? >> Add to this that the IP distance oHA-nHA must be small in order to >> allow for route updates to not explose routing tables. > > Can you clarify this? The distance of oHA and nHA is not critical. Thanks for asking. I have a set of remarks that I usually give when discussing HAHA, but it's a bit long. Feel free to skip. I think the IP distance between oHA and nHA must be small in order for route updates to take be able to take effects. I mean the IP distance, and not the physical distance. IP distance is the number of IP hops. The larger the IP distance, the smaller chances are that you can use route updates. Obviously, one can have oHA and nHA very far away physically (different continents) but still very close in terms of IP, maybe even neighbours. One can also have oHA and nHA near each other but with very long IP distances between them. In my oppinion, it is on these apparent contradictions that HAHA relies. On one hand it says: because you're in London you're obviously closer to London HA than Melbourne HA (physical distance), on another hand it assumes both HAs are close in IP terms (such as route updates are possible). >> To me, this means that: if you can use route updates to update >> paths to MR, and if the new paths are _much_ shorter, then use this >> and there is no need to use Mobile IP too. > > > When HA propagates the home network prefix to the Internet, the route > entry is never changed unless HA changes its address. (The route is > relatively stable). Ok, I see. But there must be two routes of this kind of stable route, no? There must be one stable route towards the HoA proxy-ND'ed by oHA and another stable route towards the HoA proxy-ND'ed by nHA, no? And packets from CN to the MR must actually be duplicated to both of these paths, no? > On the other hand, the path to MR is changed according to MR's > movement. Propagation of route updaes from MR is not doable. We still > need MobileIP. I agree that route updates from MR is not doable. I agree we need Mobile IP. What I mean is that if we use Mobile IP (and not route updates) then HAHA (route updates between oHA and nHA and BC sync) can not bring any significant benefit in path improvement. The distances CN-HA and HA-MR are potentially much larger than the distance oHA-nHA (the one that is reduced). Alex From nemo-bounces@ietf.org Thu Nov 18 05:02:03 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 FAA07673 for ; Thu, 18 Nov 2004 05:02: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 1CUj5g-0004aq-5L; Thu, 18 Nov 2004 05:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUj3c-0004GX-Kx for nemo@megatron.ietf.org; Thu, 18 Nov 2004 04:58:29 -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 EAA07280 for ; Thu, 18 Nov 2004 04:58:26 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUj6C-0005HV-Nc for nemo@ietf.org; Thu, 18 Nov 2004 05:01:10 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id iAI9wOua014916; Thu, 18 Nov 2004 02:58:25 -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 iAI9w4q7014280; Thu, 18 Nov 2004 03:58:05 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 192888A3C6C; Thu, 18 Nov 2004 10:58:22 +0100 (CET) Message-ID: <419C723C.6000506@motorola.com> Date: Thu, 18 Nov 2004 10:58:20 +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: Ryuji Wakikawa Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft References: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> <012CAB80-34E0-11D9-8AE2-000A95DA08F2@kniveton.com> <4197B0A4.3030903@motorola.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, tj@kniveton.com, pthubert@cisco.com, cwng@psl.com.sg 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 Ryuji Wakikawa wrote: > Hi Alex > > At Sun, 14 Nov 2004 20:23:16 +0100, > Alexandru Petrescu wrote: > > > >>Within the Problem Statement, I think the draft fails to mention that >>optimal routes for NEMO could be obtained by injecting routes in the >>visited domain but that brings in other bigger problem. This problem is >>also one of the reasons why Mobile IP for hosts was developped the way >>it was, but I think it deserves brief mentioning in a NEMO RO PS >>(Problem Statement, not Proposed Standard, not PostScript) document too. >> Or maybe this problem is already too basic to be mentioned here. > > > draft-clausen provides some thoughts on how MR can inject routes for > nesting case. Yes, I mean more than that. Route updates in the nesting case may be an approach to be investigated as a solution, but route updates to the larger Internet, no. Right? Alex From nemo-bounces@ietf.org Thu Nov 18 07:59: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 HAA21350 for ; Thu, 18 Nov 2004 07:59: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 1CUlqz-0000dZ-1V; Thu, 18 Nov 2004 07:57:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUleQ-0006gY-VZ for nemo@megatron.ietf.org; Thu, 18 Nov 2004 07:44:39 -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 HAA20335 for ; Thu, 18 Nov 2004 07:44:37 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUlh2-00007c-DG for nemo@ietf.org; Thu, 18 Nov 2004 07:47:21 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2004 13:50:56 +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 iAIChSem021569; Thu, 18 Nov 2004 13:44:03 +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, 18 Nov 2004 13:43:58 +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] My simple thoughts on HAHA Date: Thu, 18 Nov 2004 13:43:56 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC497894@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] My simple thoughts on HAHA Thread-Index: AcTNVRvGrp4jel2RT921sy8wQkUf5wAFaEBw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "Ryuji Wakikawa" X-OriginalArrivalTime: 18 Nov 2004 12:43:58.0213 (UTC) FILETIME=[45A9BB50:01C4CD6C] 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 > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: jeudi 18 novembre 2004 10:51 > To: Ryuji Wakikawa > Cc: nemo@ietf.org > Subject: Re: [nemo] My simple thoughts on HAHA >=20 > Hello Ryuji, thanks for your remarks. I have some remarks, see below. > I agree with you half half. >=20 > Ryuji Wakikawa wrote: > > Alexandru Petrescu wrote: > > > >> HAHA is a method for MR to change its HA from a remote one to a > >> closer one. It implies that paths from CN to MR's HoA are changed > >> from reaching the oldHA to reaching the newHA. These changes are > >> presumably done with a dynamic routing protocol. HAHA also > >> involves synchronizing the BCs of the two HAs such as to both know > >> the current MR's CoA. > > > > I believe you read the global-HAHA draft. >=20 > Yes. I think my remarks pertain to both drafts (HAHA and global HAHA). Surprisingly enough, this is not at all what the global HAHA draft says. The draft says that the CN reaches Home via the closest point of presence, so if CN does not move, then this does not change. MR keeps its MNP, and the MNP information is distributed by a routing protocol over a mesh of tunnels between HAs. The CN is not supposed to see the MR HoA (it's just a binding ID), unless it is formed from the MNP. The whole concept of Home link is gone.=20 Maybe a second reading? Pascal From nemo-bounces@ietf.org Thu Nov 18 08:07:16 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 IAA22121 for ; Thu, 18 Nov 2004 08:07:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUlwp-00027a-HU; Thu, 18 Nov 2004 08:03:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUlte-0001Lz-GC for nemo@megatron.ietf.org; Thu, 18 Nov 2004 08:00: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 IAA21450 for ; Thu, 18 Nov 2004 08:00:20 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUlwH-0000aQ-2u for nemo@ietf.org; Thu, 18 Nov 2004 08:03:05 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id iAID0Iua028487; Thu, 18 Nov 2004 06:00:18 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id iAICqBTk017746; Thu, 18 Nov 2004 06:52:12 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7251B85C461; Thu, 18 Nov 2004 14:00:15 +0100 (CET) Message-ID: <419C9CDF.40202@motorola.com> Date: Thu, 18 Nov 2004 14:00:15 +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: "Pascal Thubert (pthubert)" Subject: Re: [nemo] My simple thoughts on global HAHA References: <7892795E1A87F04CADFCCF41FADD00FC497894@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC497894@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Ryuji Wakikawa 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 Pascal Thubert (pthubert) wrote: >>>> HAHA is a method for MR to change its HA from a remote one to a >>>> closer one. It implies that paths from CN to MR's HoA are >>>> changed from reaching the oldHA to reaching the newHA. These >>>> changes are presumably done with a dynamic routing protocol. >>>> HAHA also involves synchronizing the BCs of the two HAs such as >>>> to both know the current MR's CoA. >>> >>> I believe you read the global-HAHA draft. >> >> Yes. I think my remarks pertain to both drafts (HAHA and global > > HAHA). > > Surprisingly enough, this is not at all what the global HAHA draft > says. The draft says that the CN reaches Home via the closest point > of presence, so if CN does not move, then this does not change. MR > keeps its MNP, and the MNP information is distributed by a routing > protocol over a mesh of tunnels between HAs. I do not see how MNP valid at one site can be advertised by another site, even if it is requested to do so by the routing protocol that runs over the mesh of tunnels between HAs. I mean, if site1 advertises MNP to the Internet and oHA is in this site1, then it is impossible for site2 to advertise the same MNP to the Internet, even if oHA asks nHA (in site2) to do so, asked via a tunnel. _If_ it were possible for site2 to advertise this same MNP once MR changed its HA, then there were no need of Mobile IP at all (and no need of tunneling HA to MR and no unoptimal paths). Do you kind of half agree with this? > The CN is not supposed to see the MR HoA (it's just a binding ID), > unless it is formed from the MNP. I think there are too many things forced at once. I don't understand what is a binding ID and I don't see how the HoA of MR is formed from the MNP (other than a specialized need). > The whole concept of Home link is gone. I have difficulty grasping the fact that the whole concept of the Home link is gone. > Maybe a second reading? I can do that. I am sure also that you will indicate that I should read the Home Network Models, which is a WG item, and which I've already read and that I've remarked on. I can do that too. Alex From nemo-bounces@ietf.org Thu Nov 18 09:25: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 JAA27875 for ; Thu, 18 Nov 2004 09:25: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 1CUn7J-0004c4-FX; Thu, 18 Nov 2004 09:18:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUmuu-0000CW-HI for nemo@megatron.ietf.org; Thu, 18 Nov 2004 09:05:44 -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 JAA26432 for ; Thu, 18 Nov 2004 09:05:42 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUmxX-0001zn-F3 for nemo@ietf.org; Thu, 18 Nov 2004 09:08:27 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAIE7E3B006577 for ; Thu, 18 Nov 2004 07:07:14 -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 iAIE5eGa010913 for ; Thu, 18 Nov 2004 08:05:41 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8E88185C461 for ; Thu, 18 Nov 2004 15:05:40 +0100 (CET) Message-ID: <419CAC34.6020100@motorola.com> Date: Thu, 18 Nov 2004 15:05:40 +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: nemo@ietf.org X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Subject: [nemo] Questions and remarks on Home Network Models 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 Pascal, here are some new comments on the Home Network Models draft, especially on the section on Extended Home Networks. Overall, I think I understand large parts of the draft and seem ok to me, but there are other small parts to which I don't agree, or maybe reformulation may be needed. What do you think? > NEMO extends the concept of Home so that it is not only a flat subnet > composed of Home Addresses but an aggregation that is itself > subnetted in mobile and Home Networks. This sounds interesting, so during all my reading I'm looking to understand this concept. > As an example, say that the aggregation has a global routing prefix > of m = 48 bits (A:B:C::/48), with subnet ID size of n = 16 bits ( n + > m = 64). > > Say that a Mobile Router, MR1, owns the MNP A:B:C:1::/64: With NEMO > Basic Support, and depending on the deployment, MR1 may register > using a Home Address from the Home network, A:B:C:0::1, say, or a > Home Address, A:B:C:1::1, say, from one of its MNPs. > > In a given deployment, one subnet may be reserved for the Home Link > (say A:B:C:0::/64) while the others are attributed to Mobile Routers > as Mobile Networks (as A:B:C:1::/64 for MR1). I understand this. Maybe in the last line you meant Mobile Network Prefixes instead of Mobile Networks? > Another approach could be to configure the Aggregation of Mobile > Networks as the subnet on the Home Link, and let the Mobile Routers > manage the overlapping networks. Does this approach cover the case where the home link has RAs with /48 and the MNPs have each RAs with /64? If this approach covers this case then I agree with it. Otherwise, I don't understand it. Section 4 Extended Home Network: I partially agree with this model to work, see below. However, I still do not understand why is it called "Extended", what does it extend more exactly? Is there a non-extended home network model? > o The Home and the MNPs are tailored to allow for IPv6 Stateless > Address Autoconfiguration with typical interface identifier length > for the type of interface (can be for example /64). Sidenote: a prefix advertised by RA should not necessarily be /64 in order for the address autoconf to work with IID /64. The prefix in RA can also be /48 or anywhere between /48 and /64. Implementations do this. Do you agree with this? > o The prefix length of the Extended Home Network is shorter than > that of the Home Network and the MNPs, since it is an aggregation > (can be for example /48). When I read this I think that maybe "Extended Home Network" should stand for the Moving Networks, the Home Link _and_ the HA that acts as a Gateway for that Home Link to the Internet, is it so? > o Alternatively, a Mobile Router could also form a Home Address from > one of its prefixes and use it to register, performing its own DAD > on its ingress network. It is not clear to me how this can happen, I think it can not happen at all correctly. Or maybe let's put it this way: maybe there is a form of Home Network, that is not extended, and where MR always uses a Home Address derived from the prefix on the home link, and not derived from its MNP. I think such a deployment is easy to do. If you agree with this, maybe this kind of Home Network deserves its own section, right before the section describing the Extended Home Network. What do you think? Alex From nemo-bounces@ietf.org Thu Nov 18 09:38:13 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 JAA28947 for ; Thu, 18 Nov 2004 09:38:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnOH-0001NK-AX; Thu, 18 Nov 2004 09:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnEu-0007Ku-FA for nemo@megatron.ietf.org; Thu, 18 Nov 2004 09:26: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 JAA27905 for ; Thu, 18 Nov 2004 09:26:22 -0500 (EST) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnHV-0002Ra-KV for nemo@ietf.org; Thu, 18 Nov 2004 09:29:08 -0500 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id F0FA05D0BB; Thu, 18 Nov 2004 23:25:49 +0900 (JST) Date: Thu, 18 Nov 2004 23:25:41 +0900 (JST) Message-Id: <20041118.232541.85362138.watari@sfc.wide.ad.jp> To: ryuji@sfc.wide.ad.jp Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft From: Masafumi Watari In-Reply-To: References: <7892795E1A87F04CADFCCF41FADD00FC451DF7@xmb-ams-337.emea.cisco.com> Organization: Keio University X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, pthubert@cisco.com, cwng@psl.com.sg 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 Pascal and all, On Thu, 18 Nov 2004 08:33:51 +0900, Ryuji Wakikawa wrote: > Hello Pascal. > > At Fri, 12 Nov 2004 17:46:36 +0100, > pascal wrote: > > > > > > > > > Overall, the solution space part does not analyze the space > > completely and > > > > does not categorize the solution space into mutual exclusive > > categories. > > > > > > As I've mentioned, I strive to be complete, and not mutually > > exclusive. > > > My feeling is that we are very close to a complete description, once > > we > > > feel in the parts on MANET as an RO appraoch. > > > > > Agreed. We have a little duplication and we can improve some of it. This > > is not last call yet, is it :?) > > not yet:-p > > > We have been encouraging people to speak up if they think something is > > missing for quite some time. If the doc serves as source for the WG > > document, then maybe more people will feel encouraged to contribute even > > more to the discussion and propose additional content. > > I supports taxonomy draft as a WG document. > Although there are several texts saying particular solution, we can > improve it after it being WG document. > > I want to merge exisiting PS drafts to this taxonomy. > draft-watari has many clasification of nested case and draft-clausen > explains possiblity of exchanging routes between MRs. I second Ryuji on this. The pb statement part of the new taxonomy draft is well documented and shaped. However, the nested cases of draft-watari-nemo-nested-cn-00.txt is only added as a reference, so they need to be merged if we were to proceed. OTOH, I prefer to have the taxonomy draft separated with the solution space. I'm not so much concerned with the length of the document, but with all the discussion going on recently on the ML, and considering that fact that more solutions should appear, it will take longer for the problem space to settle. If new problems arise later, we can go back and add them on the pb statement. Afterall, I think it would be a lot easier that way then referring to a single document on two issues like we are doing now. watari > regards, > ryuji > > > > That question was raised by the chairs and delayed because of > > accusations of partiality that now seem to be unfounded. On the ML, Fan > > expressed his opposition on some grounds that we are discussing > > currently. > > > > As of now, I strongly feel the taxonomy draft is a good base and that > > the cost of starting over is not justified by the arguments that were > > produced and the alternates that were outlined. > > > > Pascal > From nemo-bounces@ietf.org Thu Nov 18 09:55:45 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 JAA00016 for ; Thu, 18 Nov 2004 09:55:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnWl-0003al-LT; Thu, 18 Nov 2004 09:44:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnTk-0002nQ-2j for nemo@megatron.ietf.org; Thu, 18 Nov 2004 09:41:44 -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 JAA29242 for ; Thu, 18 Nov 2004 09:41:41 -0500 (EST) Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnWL-0002nN-O0 for nemo@ietf.org; Thu, 18 Nov 2004 09:44:27 -0500 Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 90C1B5D329; Thu, 18 Nov 2004 23:41:05 +0900 (JST) Date: Thu, 18 Nov 2004 23:40:56 +0900 (JST) Message-Id: <20041118.234056.39208525.watari@sfc.wide.ad.jp> To: fanzhao@ucdavis.edu Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft From: Masafumi Watari In-Reply-To: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> References: <200411141037.iAEAbfx3017644@syrphus.ucdavis.edu> Organization: Keio University X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, cwng@psl.com.sg 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 Fan, Chang-Wah On Sun, 14 Nov 2004 02:37:41 -0800 (PST), "Fan Zhao" wrote: > > > "Infrastructure Optimization" I do not understand why "MR-to-CN > > > optimization" does not > > > possibly fall into this category. > > > > > > > Because it doesn't. Infrastructure optimization means some third party > > entity in the infrastructure takes part in the optimization. > > > So you'd better change the title. Because you list "Infrastructure > Optimization" and "MR-to-CN optimization" in parallel, the reader may > wonder why the path between MR and CN may not be in the infrastructure. > And again, the approach under this section does not solve the NEMO RO > problem completely. > > > > "Nested Tunnels Optimization" > > > "Nested tunnels" is not the core of nemo ro problem and it > > > sounds too specific too. It could make one reader wonder why other > tunnel- > > > reduction > > > methods are not listed. > > > > > > > Nested tunnel optimization is to reduce tunnel ... what other > > tunnel-reduction method you have in mind that does not fit into the > > descriptions of nested tunnel optimizations? > > > As I describe before, MR sends a probing packet to collect the full path > information to the Internet and registers it with CN, thus the data > packet only carries the information in the routing header alike payload > without tunnel. Does it fit into this category or MR-to-CN category? > > Since you list "MR-to-CN optimization", "Infrastructure Optimization" > and "Nested Tunnels Optimization" in parallel, what is the criterion you > used to differentiate the approaches into different types? I agree with Fan on this. Nested Tunnel optimization should not be listed parallel with the other optimization, since they are different problems. I don't see how you catagorized these, and they were hard to read. For example, reading the text for "MR-to CN optimization", you must be assuming that CNs are located at the infrastructure, right? Wouldn't they involve other solutions if the CN is also nested? watari > And again, the approach under this section does not solve the NEMO RO > problem completely. > > > > "MIPv6-over-NEMO Optimization" > > > A lot of duplications for me. > > > > > > > Perhaps. > > > OK. > > > > > > 4. Analysis of Solution Space > > > > > > 4.1 General Considerations of RO Solution > > > The content describes the tradeoffs similar with the section of "the > > > related tradeoffs" > > > in the draft-zhao-nemo-ro-ps-00.txt. :-) Our draft also has other > > > tradeoffs. > > > > > > > True, that's an area where we can supplement each other. > > > OK. > > > > > > 4.1.1 Additional Signaling Overhead > > > The text of BU sould specific to me. The text of BU storm should > belong > > > to problem statement > > > part. > > > > > > > problem statement? Why? It is not a problem of NEMO Basic Support. It > > is a potential problem certain RO approaches might face. > > > If you look into the problem closely, the number of BU packets in NEMO > basic support is as same as in the NEMO RO if no method is used to reduce > the number of BU packets. If this is not the problem of NEMO basic > support, why it can become the problem in NEMO RO? So originally in NEMO > basic support protocol the number of BU packets can not be reduced, but > NEMO RO can look into this problem and find a way to reduce the overhead. > > > > 4.1.2 Increased Protocol Complexity > > > I understand your point. However it seems to me the scalability issue > has > > > more impacts on > > > power and processing resources than the protocol complexity. > > > > Thank you for pointing out that, I will reflect that on the next update. > > > OK. > > > > > > > > > 4.1.3 Mobility Awareness > > > "it will be difficult for mobile network nodes to control the > decision of > > > having > > > this tradeoff" > > > > > > Is that also the case for VMN? > > > > > > > Now you are going into approach specific area. In the general > > considerations, we just list out issues that in general an approach > > might have to overcome. > > > I understand what you mean. But just be careful to use the term > accurately. > > > > > > 4.1.4 New Functionalities > > > "Correspondent Nodes > > > It is generally undesirable for correspondent nodes to be > required > > > to implement new functionalities." > > > > > > I do not agree. It depends on the type of CN. > > > > > > > Perhaps. I tend to believe that the statement reflect what most people > > feel. I might update the text to show that it depends on the type of > > CN. > > > OK. > > > > > 4.1.5 Other Considerations > > > If you think they are not "tradeoff", they should not be under this > > > section. > > > > > > > Why not? I did not say section 4.1 is a trade-off discussion section. > > > So this is a cost discussion section? Sorry I am so confused. > "one would expect the costs described in the following sub-sections to be > incurred." > "Additional Signaling Overhead" "Increased Protocol Complexity" > "Mobility Awareness ?" "New Functionalities ?" "Compatibility with NEMO > Basic Support?" "In-Plane Signaling versus Off-Plane Signaling ?" > > > > > > 4.2 Specific Types of RO Solution > > > "Many of the tradeoffs discussed previously in Section 4.2 are > > > dependent on the actual route optimization approach." > > > Please give an example that one solution does not have one of the > > > tradeoffs above. > > > If there is one, your discussion about tradeoff is not general. > > > > You applied too strictly an interpretation of the meaning of > > "general". > > > > > > > > Some text seems like a evaluation to me. I recall one email on the ML > > > before > > > states that the problem draft should not judge on the quality of the > > > solution. > > > > Perhaps, I am sorry if I give the impression of 'judging the quality of > > the' approach (again, I prefer to use the term approach rather than > > solution). It is not my intention. > > > OK. > > > There are a lot of redundency too because of the way the draft used > to > > > categorize the > > > solution space. > > > > Perhaps, but I would like to see a different categorization that is (a) > > mutually exclusive, (b) complete, and (c) useful. For me, the prioirty > > is in the revese order ... a catgorization scheme should first be > > useful, and then strive to be complete, and finally preferably with > > minimal duplication. > > > I am working on it. > > > > I prefer a general security consideration also. > > > > > > > Me too, and I have already promised a general security consideration > > section in my previous posts. > > > > > Overall, the solution space part does not analyze the space > completely and > > > does not categorize the solution space into mutual exclusive > categories. > > > > As I've mentioned, I strive to be complete, and not mutually exclusive. > > My feeling is that we are very close to a complete description, once we > > feel in the parts on MANET as an RO appraoch. > > > How can you prove the completeness? > > > /rgds > > /cwng > From nemo-bounces@ietf.org Thu Nov 18 13:19: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 NAA18544 for ; Thu, 18 Nov 2004 13:19: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 1CUqhj-0007vp-Ed; Thu, 18 Nov 2004 13:08:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUqXm-0004vC-KV for nemo@megatron.ietf.org; Thu, 18 Nov 2004 12:58:06 -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 MAA16582 for ; Thu, 18 Nov 2004 12:58:03 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqaR-0007Rw-Id for nemo@ietf.org; Thu, 18 Nov 2004 13:00:52 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2004 19:04:28 +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 iAIHuwem012512; Thu, 18 Nov 2004 18:57: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, 18 Nov 2004 18:57:26 +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] Announcing the Global HAHA draft Date: Thu, 18 Nov 2004 18:57:24 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC497A1E@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Announcing the Global HAHA draft Thread-Index: AcSvbX6+v05xk+qZQQypTDE+NEAcpQbxx2jQAJdDJWA= From: "Pascal Thubert \(pthubert\)" To: "Dul, Andrew L" X-OriginalArrivalTime: 18 Nov 2004 17:57:26.0861 (UTC) FILETIME=[107DA7D0:01C4CD98] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 Andrew :) =20 Thanks a lot for all this. > Hello Pascal, >=20 > I'd like to introduce myself, I'm a member of the Connexion by Boeing > networking team and have been following the NEMO list for about 8 months > or so at this point. I'll have to apologize for not being completely > up-to-date on all the drafts within the working group as I have other > work pulling me in other directions. :) I was unable to attend the > ietf meeting last week, I hope to be able to attend in the future to > discuss this with the working group. I was just able to review the > slides that you presented at the meeting. Were there any interesting > comments at the meeting regarding global-haha that you could summarize > to the list? >=20 > In the mean time, I hope my comments below are helpful in starting the > discussion. >=20 > I'd like to thank you & others for producing the global-haha draft. I > do think it makes sense to split the drafts since from my perspective a > global mobility solution may be quite different than one that is even > optimized for regional mobility. >=20 :) > I think one of the reasons why you haven't seen a lot of interest on > this draft is that the truly global mobility market is really very > small. The aircraft industry also tends to move quite slow compared > with the speed of technology & adoption in the "Internet" space. When I > think about the objects that are really truly globally mobile in most > cases they are limited to aircraft, maritime vessels, & people. Even > when you think about people further, we are mostly regionally mobile. > Sure we travel to different parts of the globe but most of us are > generally only regionally mobile, and when we are outside of our normal > region we are often there for only shorter periods of time. Jet > aircraft are somewhat unique in that they can traverse the entire globe > within a single day. >=20 Right. And so do Jet Users :) So the problem would apply to mobile IP telephony as well, wouldn't it? > As I read through the draft (4.1.1.) I can see areas where the tunneling > in a global environment can still cause a large increase in latency. > Consider the following case. Service provider A has a ground > global-haha network that an aircraft attach to in London & Sydney, in > this case the aircraft is owned by company Z with operations in Chicago > served by Service provider B. The plane is on the ground in Sydney and > maintenance staff are using the onboard IP phone to talk to operations > staff in Chicago. Given a set of BGP routing tables it is possible > that the path through the London HA would be a perceived best path from > Chicago. In this case the call would be routed from Chicago to London > to Sydney instead of directly to Sydney. In the v4 world we have used a > BGP rehoming solution that can largely negate this issue. At this point > it is unclear to me if a similar rehoming solution is possible or > desirable in the multihomed v6 world. This also may be too much of a > corner case but it is nonetheless an interesting case. >=20 > In my opinion I believe that for a global mobility standard to be truly > successful it must allow for the mobile networks to roam between service > providers & BGP ASNs. This aspect brings up another whole set of issues Right. I believe that the satellite sites should proxy for roaming (other SP) clients as well, and must be able to establish RO tunnels with satellites that belong to other SPs. The latter part could be either proactive like BGP, reactive like a form of NHRP or a mix of the 2. The former seems to be the core of your question: The equivalent already happens already with mobile phones. It is a matter of SP agreements and roaming features in radius (proxy radius), that sort of things. In the HAHA case, this means that a satellite might not only inject Home routes for its ISP into the local fabric, but also Home routes for other ISPs for whom agreements exist and which would not own its own satellite close by. So the phone in the plane would proxy in Sydney, and the proxy would form a primary binding with a HA, that could be cross ISP, in Chicago. The return path, which seems to be the problem you address, would be following the primary binding path, to Sydney.=20 > with address allocation, v6 multi-homing, and integration with BGP. > (Which maybe outside the scope of the NEMO charter?) I also note that Right. If this takes off ( :) ) we might create a HAHA list. Depends on you... There is a number of problems to be solved... > many of these issues are still not finalized in the v6 world from my > current readings. Authentication & Authorization for MR's to the mesh > between ASNs is also a consideration. As Terry Davis one of my > colleagues stated in a previous mail, it is likely that the aircraft > networks will be connected to a number of other networks via different > mechanisms, some of them will be satellite based, some air-to-ground, > and some ground-to-ground when the aircraft is between flights. > Specifically for the ground-to-ground links it is unlikely that a single > service provider would be able to provide global coverage at any large > majority of world airports. >=20 Right. The discussion should involve SP people I guess. Pascal From nemo-bounces@ietf.org Thu Nov 18 15:29:45 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 PAA03574 for ; Thu, 18 Nov 2004 15:29: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 1CUslb-000256-C8; Thu, 18 Nov 2004 15:20:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsah-0004B5-L5 for nemo@megatron.ietf.org; Thu, 18 Nov 2004 15:09: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 PAA00390 for ; Thu, 18 Nov 2004 15:09:13 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsdN-0002Jk-8R for nemo@ietf.org; Thu, 18 Nov 2004 15:12:02 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAIK8TnG026935; Fri, 19 Nov 2004 05:08:29 +0900 Date: Fri, 19 Nov 2004 05:08:20 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] My simple thoughts on HAHA In-Reply-To: <419C7085.2070905@motorola.com> References: <419B973D.3000709@motorola.com> <419C7085.2070905@motorola.com> 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: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Alex At Thu, 18 Nov 2004 10:51:01 +0100, Alexandru Petrescu wrote: > > Hello Ryuji, thanks for your remarks. I have some remarks, see below. > I agree with you half half. :-) > Ryuji Wakikawa wrote: > > Alexandru Petrescu wrote: > > > >> HAHA is a method for MR to change its HA from a remote one to a > >> closer one. It implies that paths from CN to MR's HoA are changed > >> from reaching the oldHA to reaching the newHA. These changes are > >> presumably done with a dynamic routing protocol. HAHA also > >> involves synchronizing the BCs of the two HAs such as to both know > >> the current MR's CoA. > > > > I believe you read the global-HAHA draft. > > Yes. I think my remarks pertain to both drafts (HAHA and global HAHA). > > >> HAHA is presumably justified _only_ if the IP distance CN-oHA + > >> oHA-MR is much longer than CN-nHA + nHA-MR. > > > > Yes for path improvement. > > Is there another justification and need for HAHA other than path > improvement? Yes, of course. You can check the presentation slide presented in NEMO WG. http://www.mobilenetworks.org/nemo/ietf58/slides/ > >> Add to this that the IP distance oHA-nHA must be small in order to > >> allow for route updates to not explose routing tables. > > > > Can you clarify this? The distance of oHA and nHA is not critical. > > Thanks for asking. I have a set of remarks that I usually give when > discussing HAHA, but it's a bit long. Feel free to skip. > > I think the IP distance between oHA and nHA must be small in order for > route updates to take be able to take effects. I mean the IP distance, > and not the physical distance. IP distance is the number of IP hops. > The larger the IP distance, the smaller chances are that you can use > route updates. > > Obviously, one can have oHA and nHA very far away physically (different > continents) but still very close in terms of IP, maybe even neighbours. > One can also have oHA and nHA near each other but with very long IP > distances between them. > > In my oppinion, it is on these apparent contradictions that HAHA relies. > On one hand it says: because you're in London you're obviously closer > to London HA than Melbourne HA (physical distance), on another hand it > assumes both HAs are close in IP terms (such as route updates are possible). Which route updates are you talking about? Binding synchrnoization or route update for the home network prefix? > >> To me, this means that: if you can use route updates to update > >> paths to MR, and if the new paths are _much_ shorter, then use this > >> and there is no need to use Mobile IP too. > > > > > > When HA propagates the home network prefix to the Internet, the route > > entry is never changed unless HA changes its address. (The route is > > relatively stable). > > Ok, I see. But there must be two routes of this kind of stable route, > no? There must be one stable route towards the HoA proxy-ND'ed by oHA > and another stable route towards the HoA proxy-ND'ed by nHA, no? And what is HoA proxy-NDed? HA only advertise the whole mobile network prefix to the Internet. Among HAs, they may exchange route of certain MNP. > packets from CN to the MR must actually be duplicated to both of these > paths, no? duplication? no. > > On the other hand, the path to MR is changed according to MR's > > movement. Propagation of route updaes from MR is not doable. We still > > need MobileIP. > > I agree that route updates from MR is not doable. I agree we need > Mobile IP. > > What I mean is that if we use Mobile IP (and not route updates) then > HAHA (route updates between oHA and nHA and BC sync) can not bring any > significant benefit in path improvement. The distances CN-HA and HA-MR AFAIK, You statement is wrong:-p > are potentially much larger than the distance oHA-nHA (the one that is > reduced). For example, with HAHA, MR supposes to associate with the closer HA. It means HA-MR distance becomes shorter. CN's packet will be interecepted by the nearest HA from CN. Thus, CN-HA path gets shorter. There is another operation to bypass oHA-nHA tunnel. MR associates with the closer HA (nHA) and uses it for deliverying packets to the Internet. On the other hand, MR receives packets meant for its MNP tunneled by the closer HA of CN. path from MR to CN MR - HA =============> CN tunnel path from CN to MR MR <==============HA - CN tunnel regards, ryuji From nemo-bounces@ietf.org Thu Nov 18 16:37: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 QAA18556 for ; Thu, 18 Nov 2004 16:37:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUteK-0003tq-21; Thu, 18 Nov 2004 16:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsrR-0006Wa-8N for nemo@megatron.ietf.org; Thu, 18 Nov 2004 15:26:33 -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 PAA03319 for ; Thu, 18 Nov 2004 15:26:30 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsu7-0002r3-8y for nemo@ietf.org; Thu, 18 Nov 2004 15:29:20 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAIKOgnG027083; Fri, 19 Nov 2004 05:24:42 +0900 Date: Fri, 19 Nov 2004 05:24:36 +0900 Message-ID: From: Ryuji Wakikawa To: pthubert@cisco.com Subject: Re: [nemo] Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC497703@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC497703@xmb-ams-337.emea.cisco.com> 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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, ryuji@sfc.wide.ad.jp, Greg.Daley@eng.monash.edu.au, cjbc@it.uc3m.es 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 At Thu, 18 Nov 2004 09:56:56 +0100, pascal wrote: >=20 > Right. >=20 > I believe that there is a great interest in digging more into a MANET bas= ed solutions.=20 >=20 > But We can not say 'any MANET' will do. We must explicit what our > priorities are and what features we care for. And we must come back > with a single MANET version so there's a chance to get standard > track one day. I did not say "any MANET";-) The draft is problem statement and tries to expose the possibility of MANET to some NEMO issue. > Example of requirements: >=20 > 1) The MObile Adhoc for NEMO should primarily focus on providing a > default route to the infrastructure for each node. This feature is discussed at MANET WG. > 2) Then it should provide the capability for routers to exchange > routes and communicate even if a connection to the infrastructure > is not available. Yes, it is MANET's original feature. > 3) It should allow the formation of a nested NEMO in a controlled > fashion. In particular, it should be possible to form specific > groups, control the size and other topological criteria. Yes, this is operational.=20 > 4) There should be a solution to interconnect nested NEMOs as > opposed to forming ever larger structures. aggregation? > 5) The Protocol must fit in a nested NEMO solution where > redistribution of the NEMO prefixes into the infrastructure is > not required. In that solution, Mobile Routers can form a NEMO > CareOf address from an address or a prefix that is topologically > correct at the edge of the nested NEMO. which address is used for CoA? > 6) ... >=20 >=20 > In my mind,=20 >=20 > 1) is more in the proactive side since it is the most important route for= NEMO.=20 ok > 2) means that our specific MANET must exchange prefixes, but does > 2) not imply it should be proactive. In fact, in many scenarios, it > 2) is not used at all (eg. Individuals in Bus, trains, etc...) . But > 2) in some scenarios, it is mandatory and has to cope with some good > 2) degree of inner mobility (eg. Earthquake). So It see that as > 2) either on-demand, or in a LORA space, to limit the operational > 2) cost. The overhead depends on which MANET routing is used for MR and how big mane= t is. > I'm not sure that from the current charter, the NEMO list is the > right place to discuss all this, though... sorry about that. well, the discussion of RO solution is not begun yet, too. But it might be true that we need more thoughts on this with people from NEMO and MANET WG. regards, ryuji > Pascal >=20 >=20 > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of= Ryuji Wakikawa > > Sent: jeudi 18 novembre 2004 08:20 > > To: cjbc@it.uc3m.es > > Cc: nemo@ietf.org; ryuji@sfc.wide.ad.jp > > Subject: [nemo] Re: Comments ondraft-clausen-nemo-ro-problem-statement-= 00.txt > >=20 > >=20 > > Hello Carlos > >=20 > > Sorry for late reply. > >=20 > > You are right. > >=20 > > We can not achieve an optimal route for Internet-toNEMO only with > > MANET. In the Internet-to-"Nested"NEMO case, MANET can help optmized > > routing for a few hops (that are inside nested NEMO). > >=20 > > For example, if nested MR sends BU with root-MR's CoA, packets are > > directly reached to root-MR and root-MR can route packets to the > > nested MR by MANET. You may be interested in ORC draft. > > http://www1.ietf.org/internet-drafts/draft-wakikawa-nemo-orc-00.txt > >=20 > > thanks > > ryuji > >=20 > >=20 > >=20 > > At Mon, 08 Nov 2004 10:34:50 +0100, > > Carlos Jes=FAs Bernardos Cano wrote: > > > > > > [1 ] > > > Hi Ryuji, > > > > > > First of all, thanks for submitting the draft. > > > > > > Your draft seems to address the problem of the Internet-to-NEMO > > > communication and the NEMO-to-NEMO communication when nesting is > > > involved, using a MANET approach. I agree with you that in the > > > NEMO-to-NEMO approach, having the MRs in a nested-NEMO running an Ad-= Hoc > > > routing protocol would help to avoid traversing the Internet and also > > > avoid the encapsulation. On the other hand, I don't see that clear how > > > this would help the Internet-to-NEMO, at least as it is now described= in > > > the current version of your draft. > > > > > > The draft says: > > > > > > "Additionally, this would also ease the Internet-to-NEMO scenario.= In > > > order to deliver an IP datagram to a node in the nested NEMO netwo= rk, > > > only a path to the access router between the nested NEMO network a= nd > > > the Internet would be required: once an IP datagram arrives in the > > > nested NEMO network, the routing tables in the mobile routers, as > > > provided by OLSR, would allow direct routing to the destination. > > > Thus, there would no longer be a requirement to do nested encapsul= a- > > > tion on each logical hop (i.e. each transversal of a Home Agent) in > > > order to be able to decapsulate and correctly forward IP datagrams= in > > > the nested NEMO network. > > > > > > > > > Thus even if no route optimizations are performed in the Internet-= to- > > > NEMO scenario, an overhead reduction can still be achieved through > > > much lower encapsulation requirements." > > > > > > How this improvements are achieved? If a CN in the Internet sends a > > > packet to a MNN that is connected to a nested-NEMO, the packet would > > > traverse the HAs of every MR in the nested-NEMO until the MNN is fina= lly > > > reached. Therefore, I don't see how this encapsulation would be avoid= ed, > > > without making any additional change to the MR and/or HA and/or CN. A= m I > > > missing something? > > > > > > Thanks in advance. > > > > > > Kind Regards, > > > > > > Carlos J. > > > > > > -- > > > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > > GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 > > > [2 Esta parte del mensaje est=E1 firmada digitalmente ] > > > >=20 From nemo-bounces@ietf.org Thu Nov 18 17:03: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 RAA22835 for ; Thu, 18 Nov 2004 17:03: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 1CUu4J-00072g-9m; Thu, 18 Nov 2004 16:43:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtvp-0001WK-PF for nemo@megatron.ietf.org; Thu, 18 Nov 2004 16:35:09 -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 QAA18166 for ; Thu, 18 Nov 2004 16:35:06 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtyT-0007Ql-H0 for nemo@ietf.org; Thu, 18 Nov 2004 16:37:57 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id iAILaWPw026192; Thu, 18 Nov 2004 14:36:32 -0700 (MST) Received: from [10.181.32.180] (mvp-10-181-32-180.ea.mot.com [10.181.32.180]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id iAILYdq7000988; Thu, 18 Nov 2004 15:34:40 -0600 Message-ID: <419D157F.7060704@motorola.com> Date: Thu, 18 Nov 2004 22:34:55 +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: Ryuji Wakikawa Subject: Re: [nemo] My simple thoughts on HAHA References: <419B973D.3000709@motorola.com> <419C7085.2070905@motorola.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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 Ryuji Wakikawa wrote: > Hello Alex Hey Ryuji! Thanks for your answers. If I'm not clear somewhere, please tell me. >> Is there another justification and need for HAHA other than path >> improvement? > > Yes, of course. You can check the presentation slide presented in > NEMO WG. http://www.mobilenetworks.org/nemo/ietf58/slides/ These slides spell to me "Load Balancing and High Availability and Optimal Paths (RO) are all goals of HAHA". Am I wrong? If I am not wrong then I'd suggest: -make sure HAHA targets load balancing and thus remove all reference to HAHA from the Problem Statement draft or -make sure HAHA targets RO, keep HAHA in the RO PS draft, and remove Load Balancing and High Availability from the slides you reference above. The PS draft should not describe HA Load Balancing problems, no? >>>> Add to this that the IP distance oHA-nHA must be small in order >>>> to allow for route updates to not explose routing tables. >>> >>> Can you clarify this? The distance of oHA and nHA is not >>> critical. >> >> Thanks for asking. I have a set of remarks that I usually give >> when discussing HAHA, but it's a bit long. Feel free to skip. >> >> I think the IP distance between oHA and nHA must be small in order >> for route updates to take be able to take effects. I mean the IP >> distance, and not the physical distance. IP distance is the number >> of IP hops. The larger the IP distance, the smaller chances are >> that you can use route updates. >> >> Obviously, one can have oHA and nHA very far away physically >> (different continents) but still very close in terms of IP, maybe >> even neighbours. One can also have oHA and nHA near each other but >> with very long IP distances between them. >> >> In my oppinion, it is on these apparent contradictions that HAHA >> relies. On one hand it says: because you're in London you're >> obviously closer to London HA than Melbourne HA (physical >> distance), on another hand it assumes both HAs are close in IP >> terms (such as route updates are possible). > > > Which route updates are you talking about? Binding synchrnoization or > route update for the home network prefix? Route updates that update the routes towards MNP and route updates that update the routes towards HoA. Not the Binding Sync messages. >>>> To me, this means that: if you can use route updates to update >>>> paths to MR, and if the new paths are _much_ shorter, then use >>>> this and there is no need to use Mobile IP too. >>> >>> >>> When HA propagates the home network prefix to the Internet, the >>> route entry is never changed unless HA changes its address. (The >>> route is relatively stable). >> >> Ok, I see. But there must be two routes of this kind of stable >> route, no? There must be one stable route towards the HoA >> proxy-ND'ed by oHA and another stable route towards the HoA >> proxy-ND'ed by nHA, no? And > > > what is HoA proxy-NDed? A stable route towards the Home Address for which the new Home Agent is entitled to do proxy Neighbour Discovery. > HA only advertise the whole mobile network prefix to the Internet. > Among HAs, they may exchange route of certain MNP. The HA advertises the super-prefix (/48 home link out of which /64s are derived) to the Internet. This super-prefix can not change when the MR attaches to a new HA. Do we agree on this? May I call this the Home Network model? (not the Extended Home Network model). I do not see why oHA and nHA would exchange routes (actually nHA sends a route update to oHA) towards MNP. oHA and nHA exchanging MNPs is worthless if these MNPs are not advertised towards the Internet too. >> packets from CN to the MR must actually be duplicated to both of >> these paths, no? > > duplication? no. Ok! We agree! So a packet from CN towards a fixed Home Address will take a unique definite path, it won't be multicasted. This path must lead to one HA. If one needs to modify this path to lead to another new HA, then a route update in the Internet is necessary, no? >>> On the other hand, the path to MR is changed according to MR's >>> movement. Propagation of route updaes from MR is not doable. We >>> still need MobileIP. >> >> I agree that route updates from MR is not doable. I agree we need >> Mobile IP. Me too. Route updates from MR, or from HA, or from CN to the Internet can probably not cope with the number of MRs and the number of routers in between. >> What I mean is that if we use Mobile IP (and not route updates) >> then HAHA (route updates between oHA and nHA and BC sync) can not >> bring any significant benefit in path improvement. > > AFAIK, You statement is wrong:-p To me, it's simply right. If one uses Mobile IP it is because numerous path updates in the Internet are not possible (the path updates that would be generated by numerous mobiles moving around). If path updates _are_ possible, then Mobile IP is not needed. Why would one update a path, and at the same time bother to use MR-HA tunnels? >> are potentially much larger than the distance oHA-nHA (the one that >> is reduced). > > For example, with HAHA, MR supposes to associate with the closer HA. It is useful for MR to associate with the closer HA _only_ if this HA can also intercept packets addressed from CN to the HoA that was valid at the old HA, no? > It means HA-MR distance becomes shorter. Yes, the path nHA-MR may be shorter than oHA-MR. However, it is not enough for _that_ path to be shorter in order to be beneficial. RO does not look at shortening the HA-MR paths, but at CN-MR paths. SO you want the path CN-nHA-MR to be much shorter than the path CN-oHA-MR. The path oHA-nHA must be small such as to allow for route updates (if route updates, not BC syncs, are used between HAs) are used. If HAHA eliminates that short oHA-nHA path then there is no benefit in using it because it is much smaller than what the CN-HA or HA-MR paths may become. > CN's packet will be interecepted by the nearest HA from CN. This assumes that your nHA is nearer the CN than the oHA, and at the same time that the nHA is nearer the MR than the oHA, and at the same time that a Home Address is reachable at both HAs. Am I right? Or does it only assume that whatever HA is closer to CN can intercept a packet towards HoA and forward it to the current HA? If this is what you meant, then all HAs must be able to intercept a certain HoA and at the same time when this inter-HA forwarding takes place it induces new angles to the multi-angular paths. This one-HA-close-to-any-CN-and-wherever-MR-goes may also be possible in some closed system. This is a possibility indeed. It still stays a small system. > Thus, CN-HA path gets shorter. Yes, it may be shortened by 1 or 2 IP hops with a total distance of 10 hops. Like RO reducing the path from 10 hops to 9 hops. I don't think the PS draft should look into these solutions, it's too much effort for too little achievement. > There is another operation to bypass oHA-nHA tunnel. MR associates > with the closer HA (nHA) and uses it for deliverying packets to the > Internet. On the other hand, MR receives packets meant for its MNP > tunneled by the closer HA of CN. > > path from MR to CN MR - HA =============> CN tunnel > > path from CN to MR MR <==============HA - CN tunnel Great! So we end up with a smaller triangular routing, not the maximum triangular routing CN-HA-MR. This looks to me like an intermediate step on an RO scale. The goal of RO should be to have straight paths MR-CN, not through some other HA, even if closer, no? If you do this little triangle, why would MR bother to bind its HoA to its CoA at nHA? It would not need to send binding updates at all to nHA, just tunnel packets to CN, no need of Mobile IP, no? Alex From nemo-bounces@ietf.org Thu Nov 18 17:13:20 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 RAA24235 for ; Thu, 18 Nov 2004 17:13:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuPG-000617-SB; Thu, 18 Nov 2004 17:05:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUu8W-0000Q4-Dg for nemo@megatron.ietf.org; Thu, 18 Nov 2004 16:48:17 -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 QAA20648 for ; Thu, 18 Nov 2004 16:48:13 -0500 (EST) Received: from losangeles.ucdavis.edu ([169.237.104.159]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuBD-00081Y-3D for nemo@ietf.org; Thu, 18 Nov 2004 16:51:03 -0500 Received: from citheronia.ucdavis.edu (citheronia.ucdavis.edu [169.237.104.183]) by losangeles.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAILm7Ts019080; Thu, 18 Nov 2004 13:48:11 -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 iAILm6Zo015372; Thu, 18 Nov 2004 13:48:06 -0800 (PST) Received: (from www@localhost) by citheronia.ucdavis.edu (8.12.10/8.12.9/Submit) id iAILm6ns015371; Thu, 18 Nov 2004 13:48:06 -0800 (PST) Date: Thu, 18 Nov 2004 13:48:06 -0800 (PST) Message-Id: <200411182148.iAILm6ns015371@citheronia.ucdavis.edu> To: Chan-Wah NG Subject: Re: [nemo] What kind of NEMO RO problem WG document we would like to see 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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 Hi Chan-Wah, Thanks for your reply. Please see my reply bleow. Sincerely, fan > Hello Fan, > > Sorry for replying late. See reponses in-line: > > /rgds > /cwng > > On Sun, 2004-11-14 at 02:30 -0800, Fan Zhao wrote: > > > It runs the risk of > > > being in conflict with your point #4 above. To strictly demand mutual > > > exclusiveness will often leads to incompleteness. > > I do not understand why. Can you explain about it? > > > > By strictly demanding mutual exclusivity, you are demanding the division > of an area into two non-overlapping areas. It runs a risk of having > area not covered by the two areas. > Not necessarily. For example, your multi-homing draft and Watari & Thierry's nested_cn draft have done a very nice work in the categorization. > > > To me, having mutual > > > exclusive approach is only something that is preferable, but not of high > > > priority. Instead it is the completeness that we should try to achieve. > > > (Your choice of words "should" in #4 and "must" in #5 seems to indicate > > > you felt otherwise). > > > > > Mutual exclusion avoids the duplication and redundency. Also it provides > > the clear comparison and contrast between the different categories. The > > completeness and mutual exclusion are independent and equally important. > > > > I am not saying mutual exlcusivity is not good. I like mutual > exlusivity, but not at the expense of completeness is my point. > > > > What advantages does mutual exclusive solution space partitioning gives > > > us? > > > > > The ideal solution space partition should look like this: > > > > Base on a certain criterion, the whole solution space is partitioned into > > for exmaple A and B. And based on another criterion, A is partitioned > > into for example, A1 and A2. B is partitioned into for example B1, B2 and > > B3 based on the same or a different criterion. In this way it is easy to > > see the commonness and difference among the solutions and avoids the > > duplicated analysis. > > AH ... your a and B do overlaps, don't they? SO what you are proposing > is this, suppose we come up wth 2 criteria, A and B, so you would > partitioned the solution space into 4 quadrants: Q1: A & B, Q2: !A & B, > Q3: A & !B, and Q4: !A & !B. > > Right? Interesting proposal, seems to be along the line of the way we > classify mutlihoming cases ... > That could be a possible way given the appropriate criteria. Actually what is in my mind right now is this kind of line of thinking: 1) From the NEMO RO problem described and analyzed before, we can deduce what NEMO RO solution is expected to do (not solution specific) For example, NEMO RO solution is expected to answer the following questions: i) how to achieve the full binding information between Home_Address/Home_Network_Prefix and the point of attachment to a specific router (AR when CN is not under the same nested NEMO network and the first common MR when CN is under the same nested NEMO network.) ii) how to transfer this information from HA/MR to CN/CR/other routers (other MR/AR) that is close to MNN/CN. iii) How to route the data packet based on the available full binding information. (i and ii are usually closely related, so I combine them by a vector in my slides.) 2) The "approaches" are categorized based on i, ii, and iii described above. And the associated issues are analyzed. i) includes a) Home_address/Home_network_prefix: This kind of information is available to MR and HA. a1. MR/HA could register MNP with CN by a similar RR test. Possible issues: Strength: ... Weakeness: scope ... a2. Registering HoA ... b) The information about the point of attachment b1. the point of attachment to AR c1. Each MR's CoA is attached to one payload thus a sequence of CoAs is formed. (like in RRH and PCH draft.) c2. Prefix delegation/remapping. (like in PD and ND-proxy draft) c3. The extended Route Advertisement message. c4. Manet c5. MR sends the probing packet c6. include the parent MR's CoA in the BU packet (partial approach) c7. recursively proxy the child MR/MNN's RO message (like "MR as a proxy" in taxonomy draft) c8. CN deduces from a sequence of BU packets or BC entries. b2. the point of attachment to MR Similar with the methods in b1 (maybe not including the last one c8). And the issues for each approach (from c1 to c8). ii) includes a) from HA to CN/CR b) from HA to other_MR/AR c) from MR to CN/CR d) from MR to other_MR/AR And issues for each approach iii) includes a) IP-in-IP issues: b) routing header issues: may require the extension and the processing on each router either in the Internet or inside the nested NEMO c) Combination of a and b issues: This might be incomplete and just want to show what I think. In the original taxonomy draft, it seems to me it is going into the approach analysis part directly from the problem statement part. I feel there is a gap in between. It might be better to have a conclusion saying what the NEMO RO solution is expected to do given the problem statement and analysis we made, which is not only a natual result of problem statement and analysis, but also serves our purpose by making a PS draft: to show we understand the problem well and are able to solve it. After that we categorize the approach space based on that statement and analyze the possible issues. In this way, I hope that even later the new approaches come out, it is easy to find the correct place in our categorization for them. > > > > > > > > > > 6. The solution space analysis does not judge on the strength and > > > > weakness of each solution. > > > > > > An analysis should try to be as objective as possible. That goes > > > without saying. But what is the use of an analysis if it does not > > > points out the relative strength and weakness of each approach? > > > > The reasons I list this are > > > > 1) IMHO this might be the way going into the details of solution too > > much. Also since you have to have the detailed solution in mind, your > > analysis does not include the new solution, which voids the completeness. > > > Nope, given what you have defined in the solution space you are > describing, an analysis should point out the strength and weakness of > that solution space. For instance, your solution space might be: > > a; require sending of BU with prefix to CN, > !a: does not require sending of BU to CN. > > Then it should point out that (a) requires changes to CN, which is > generally undesirable. > > > 2) I do not see how your taxonomy draft can give a thorough evaulation > > without any formly defined qualifier. It could generate a lot of emails > > like "comments on the evaluation part". > > http://www1.ietf.org/mail-archive/web/nemo/current/msg01677.html > > http://www1.ietf.org/mail-archive/web/nemo/current/msg01689.html > > http://www1.ietf.org/mail-archive/web/nemo/current/msg01692.html > > (Thierry and Pascal if I misunderstand your email, please correct me.) > > > > No, we are not trying to evaluate solutions. That's not the purpose of > the solution space analysis. It simply is an analysis to help whatever > WG (new, or the re-chartered NEMO WG) that is going to develop and > specify a standardized NEMO Extended Support. > > > 3) As when I was writing this email, I recall the similar concerns > > expressed on the ML. > > (http://www1.ietf.org/mail-archive/web/nemo/current/msg01657.html, > > http://www1.ietf.org/mail-archive/web/nemo/current/msg01681.html, Am I > > right, Alex?) > > I am not saying it is impossible that the evaluation can not be done > > nicely in a reasonable level of fairness and correctness. But at this > > point, as we have not understood the whole solution space, it might be > > too early to do it. > > > > > (I prefer to use the term 'approach' rather than 'solution', as the > > latter > > > can often be interpreted as the 'solution described in > > > draft-foo-bar-xx.txt'). > > Do you mean "approach" is a kind of mechanism to solve the RO problem, > > right? As Thierry also suggests the term of "issue". My understanding > > about the differences between "issue" and "approach" is that "approach" > > tries to solve the whole NEMO RO problem while "issue" is related to only > > some part of problem. > > > > Nope, for me, "approach" is a general way to solve a particular problem > (like solve this problem using routing header), a "solution" is > draft-xxx-xxxx that specifies details of an approach (like use Reverse > Routing Header). If you like, you can call "solution" a "proposal". > > My understanding of what Thierry is concerned is the confusion of issues > and problems. He want to use "problems" to refer to problem with NEMO > Basic Support that leads to the need for RO; and "issues" to refer to > the potential problems that a particular RO approach might face. > OK, that sounds good. It helps clarify a lot of confusions. > /rgds > /cwng > From nemo-bounces@ietf.org Thu Nov 18 17:16:21 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 RAA24507 for ; Thu, 18 Nov 2004 17:16: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 1CUuQR-0006tf-8X; Thu, 18 Nov 2004 17:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuDO-0002hj-AY for nemo@megatron.ietf.org; Thu, 18 Nov 2004 16:53:19 -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 QAA21430 for ; Thu, 18 Nov 2004 16:53:14 -0500 (EST) Received: from berlin.ucdavis.edu ([169.237.104.158]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuG3-0008Ho-Qy for nemo@ietf.org; Thu, 18 Nov 2004 16:56:05 -0500 Received: from cucujus.ucdavis.edu (cucujus.ucdavis.edu [169.237.104.179]) by berlin.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAILrC6G005718; Thu, 18 Nov 2004 13:53:12 -0800 (PST) Received: from cucujus.ucdavis.edu (localhost [127.0.0.1]) by cucujus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iAILrCu2027083; Thu, 18 Nov 2004 13:53:12 -0800 (PST) Received: (from www@localhost) by cucujus.ucdavis.edu (8.12.10/8.12.9/Submit) id iAILrBCm027082; Thu, 18 Nov 2004 13:53:11 -0800 (PST) Date: Thu, 18 Nov 2004 13:53:11 -0800 (PST) Message-Id: <200411182153.iAILrBCm027082@cucujus.ucdavis.edu> To: Chan-Wah NG Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 Hi Chan-Wah, > On Sun, 2004-11-14 at 02:37 -0800, Fan Zhao wrote: > > > > > > > " There are multiple proposals for providing various forms of route > > > > optimizations for NEMO (see Appendix A). " > > > > Please delete the appendix. As some proposals are incomplete, even > > some > > > > does not work. What's more, some proposals look different but > > actually > > > > using > > > > the same core idea. > > > > > > Perhaps, but that is not up to us to judge. The readers have to decide > > > for themselves whether the individual proposals work or not. An > > > appendix is an appendix. It is something that you could do without. I > > > view the work done on ro-taxonomy-03.txt as a survey/review of what is > > > the current state of RO solutions, and it felt incomplete without > > > reference to all the proposals that have been made. > > > > > It is fine with me if you want to write your draft as a survey. But IMHO, > > the NEMO RO peoblem WG document should not be just a survey. The analysis > > of the complete solution space is one of the key values of this WG > > document. > > You are now putting words into my mouth. No, i mean the appendix (and > not the whole draft) is a review of the current state of RO solutions. > Sorry for the misunderstanding. > > > > > > > > > > "3.1 MR-to-CN Optimization" "3.2 Infrastructure Optimization" > > > > "3.3 Nested Tunnels Optimization" "3.4 MIPv6-over-NEMO Optimization" > > > > "3.5 Intra-NEMO Optimization" > > > > The solution space analysis part is organized like in the problem > > > > statement part > > > > to me. I do not see any logic behind the way you use to categorize > > the > > > > solution space. > > > > Remember that the different problem scenarios do not mean the > > different > > > > solutions (core ideas). > > > > > > > > "Binding Update with Network Prefix" and "MR as a Proxy" use the same > > > > idea to me and are > > > > described in a too specific way. > > > > > > > Same idea? Are you sure? They may be solving the same problem (which > > > is why we put them into the same "MR-to-CN" optimization, but they are > > > entirely different. The former requires the MR to send prefix > > > information to CN, the latter requires the MR to pretend to be the MNN. > > > The core idea is quite different to me. > > > > > 1) The idea of these two is to distribute the binding information between > > HoA and MNP/CoA to CN. Although they extend the MIP6 RO procedure in the > > different ways, these kind of differences are secondary in the context of > > NEMO RO. > > 2) You want to "describe the solution space of route optimization by > > listing different types of approach to route optimization." > > So your approach listed in this sub-section has to solve the problem you > > describe in the problem statement part. However, I do not see > > how "Binding Update with Network Prefix" and "MR as a Proxy" solve the > > problem completely including in the nested NEMO and intra-NEMO cases. Do > > you agree? > > 3) I can immediately come up with two "MR-to-CN optimization" approaches: > > 3.1 MR does not send CoTi and HoTi on behalf of the MNN, instead it > > intercepts the CoTi and HoTi sent by the MNN and changes the source IP > > address in CoTi into its CoA. The rest is as same as in "MR as a proxy" > > > Agree, the part on MR as a Proxy is too detailed, (and the weak reason I > offer is due to the short time from the idea popping up in the ML to the > submission deadline). It will be changed in the next version. > OK. > > > > > "Infrastructure Optimization" I do not understand why "MR-to-CN > > > > optimization" does not > > > > possibly fall into this category. > > > > > > > > > > Because it doesn't. Infrastructure optimization means some third party > > > entity in the infrastructure takes part in the optimization. > > > > > So you'd better change the title. Because you list "Infrastructure > > Optimization" and "MR-to-CN optimization" in parallel, the reader may > > wonder why the path between MR and CN may not be in the infrastructure. > > And again, the approach under this section does not solve the NEMO RO > > problem completely. > > > > > > "Nested Tunnels Optimization" > > > > "Nested tunnels" is not the core of nemo ro problem and it > > > > sounds too specific too. It could make one reader wonder why other > > tunnel- > > > > reduction > > > > methods are not listed. > > > > > > > > > > Nested tunnel optimization is to reduce tunnel ... what other > > > tunnel-reduction method you have in mind that does not fit into the > > > descriptions of nested tunnel optimizations? > > > > > As I describe before, MR sends a probing packet to collect the full path > > information to the Internet and registers it with CN, thus the data > > packet only carries the information in the routing header alike payload > > without tunnel. Does it fit into this category or MR-to-CN category? > > > > Since you list "MR-to-CN optimization", "Infrastructure Optimization" > > and "Nested Tunnels Optimization" in parallel, what is the criterion you > > used to differentiate the approaches into different types? > > > > And again, the approach under this section does not solve the NEMO RO > > problem completely. > > > > > > 4.1.1 Additional Signaling Overhead > > > > The text of BU sould specific to me. The text of BU storm should > > belong > > > > to problem statement > > > > part. > > > > > > > > > > problem statement? Why? It is not a problem of NEMO Basic Support. It > > > is a potential problem certain RO approaches might face. > > > > > If you look into the problem closely, the number of BU packets in NEMO > > basic support is as same as in the NEMO RO if no method is used to reduce > > the number of BU packets. If this is not the problem of NEMO basic > > support, why it can become the problem in NEMO RO? So originally in NEMO > > basic support protocol the number of BU packets can not be reduced, but > > NEMO RO can look into this problem and find a way to reduce the overhead. > > I asaw you've retracted your objection in another mail. SO does this > means that you agree BU_Storm should be an "issue" of RO solution, > rather than a "problem " of NEMO Basic Support? > Yes, I agree that "BU_Storm" is an issue of RO solution. > > > > > > As I've mentioned, I strive to be complete, and not mutually exclusive. > > > My feeling is that we are very close to a complete description, once we > > > feel in the parts on MANET as an RO appraoch. > > > > > How can you prove the completeness? > > > > I don't. I disprove it by counter-example, and then add that counter example to the solution space, making it more complete everytime I do that. > > /rgds > /cwng > From nemo-bounces@ietf.org Thu Nov 18 17:25:11 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 RAA25692 for ; Thu, 18 Nov 2004 17:25: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 1CUuZX-0002pz-8j; Thu, 18 Nov 2004 17: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 1CUuRe-0007fv-73 for nemo@megatron.ietf.org; Thu, 18 Nov 2004 17:08: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 RAA23567 for ; Thu, 18 Nov 2004 17:07:59 -0500 (EST) Received: from lisbon.ucdavis.edu ([169.237.104.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuUI-0000Ku-Mz for nemo@ietf.org; Thu, 18 Nov 2004 17:10:50 -0500 Received: from citheronia.ucdavis.edu (citheronia.ucdavis.edu [169.237.104.183]) by lisbon.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iAIM7tSQ007553; Thu, 18 Nov 2004 14:07:55 -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 iAIM7tZo016341; Thu, 18 Nov 2004 14:07:55 -0800 (PST) Received: (from www@localhost) by citheronia.ucdavis.edu (8.12.10/8.12.9/Submit) id iAIM7sqQ016340; Thu, 18 Nov 2004 14:07:54 -0800 (PST) Date: Thu, 18 Nov 2004 14:07:54 -0800 (PST) Message-Id: <200411182207.iAIM7sqQ016340@citheronia.ucdavis.edu> To: Ryuji Wakikawa Subject: Re: [nemo] comments on solution space analysis part in taxonomy draft 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; SV1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: nemo@ietf.org, cwng@psl.com.sg 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 Ryuji, Thanks for your reply. Please see below. Thanks. Sincerely, fan > > Hi Fan > > At Sun, 14 Nov 2004 02:37:41 -0800 (PST), > Fan Zhao wrote: > > > > > > > > > > > "3.1 MR-to-CN Optimization" "3.2 Infrastructure Optimization" > > > > "3.3 Nested Tunnels Optimization" "3.4 MIPv6-over-NEMO Optimization" > > > > "3.5 Intra-NEMO Optimization" > > > > The solution space analysis part is organized like in the problem > > > > statement part > > > > to me. I do not see any logic behind the way you use to categorize > > the > > > > solution space. > > > > Remember that the different problem scenarios do not mean the > > different > > > > solutions (core ideas). > > > > > > > > "Binding Update with Network Prefix" and "MR as a Proxy" use the same > > > > idea to me and are > > > > described in a too specific way. > > > > > > > Same idea? Are you sure? They may be solving the same problem (which > > > is why we put them into the same "MR-to-CN" optimization, but they are > > > entirely different. The former requires the MR to send prefix > > > information to CN, the latter requires the MR to pretend to be the MNN. > > > The core idea is quite different to me. > > > > > 1) The idea of these two is to distribute the binding information between > > HoA and MNP/CoA to CN. Although they extend the MIP6 RO procedure in the > > different ways, these kind of differences are secondary in the context of > > NEMO RO. > > In the case of "MR as a Proxy", MR sends MNN-address and MR-CoA (not > HoA/MNP/CoA) to CN as a MIP binding. Binding information registering > to CN is different. > Yes, the content of binding information is different. > But I agree with Fan that the text in the draft is very solution specific. > > > > > "Infrastructure Optimization" I do not understand why "MR-to-CN > > > > optimization" does not > > > > possibly fall into this category. > > > > > > > > > > Because it doesn't. Infrastructure optimization means some third party > > > entity in the infrastructure takes part in the optimization. > > > > > So you'd better change the title. Because you list "Infrastructure > > Optimization" and "MR-to-CN optimization" in parallel, the reader may > > wonder why the path between MR and CN may not be in the infrastructure. > > And again, the approach under this section does not solve the NEMO RO > > problem completely. > > I believe Pascal wanted to classify whether end nodes involve RO procedure or not :-) > OK. > What do you mean the approach does not solve the NEMO RO completely? > These approaches may not solve RO issues completely, but they improve > NEMO performance in certain level. It is very important to know which > approach can solve which issue. With knowing possible approaches, we > can judge whether WG needs the approach or not. > I think I misunderstand what the "approach" means before. But it might be necessary to point out what types of "approaches" are needed to form a "solution" to solve the whole NEMO RO problem. > > > > 4.1.1 Additional Signaling Overhead > > > > The text of BU sould specific to me. The text of BU storm should > > belong > > > > to problem statement > > > > part. > > > > > > > > > > problem statement? Why? It is not a problem of NEMO Basic Support. It > > > is a potential problem certain RO approaches might face. > > > > > If you look into the problem closely, the number of BU packets in NEMO > > basic support is as same as in the NEMO RO if no method is used to reduce > > the number of BU packets. If this is not the problem of NEMO basic > > support, why it can become the problem in NEMO RO? So originally in NEMO > > basic support protocol the number of BU packets can not be reduced, but > > NEMO RO can look into this problem and find a way to reduce the overhead. > > I can not get your point. > In the NEMO basic, MR sends single BU to HA. > If MR decided to send BU to CNs, #of BU is increased as #of CNs. > OK, I agree. > regards, > ryuji > From nemo-bounces@ietf.org Fri Nov 19 01:21:23 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 BAA08758 for ; Fri, 19 Nov 2004 01:21: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 1CV26w-0007vx-5d; Fri, 19 Nov 2004 01:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV24s-0007bt-88 for nemo@megatron.ietf.org; Fri, 19 Nov 2004 01:17: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 BAA08327 for ; Fri, 19 Nov 2004 01:17:01 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV27c-0003Ai-UB for nemo@ietf.org; Fri, 19 Nov 2004 01:19:54 -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 iAJ6GJnG001422; Fri, 19 Nov 2004 15:16:21 +0900 Date: Fri, 19 Nov 2004 15:16:17 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] My simple thoughts on HAHA In-Reply-To: <419D157F.7060704@motorola.com> References: <419B973D.3000709@motorola.com> <419C7085.2070905@motorola.com> <419D157F.7060704@motorola.com> 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: 17bdfcaea25d1444baef0e24abc38874 Cc: nemo@ietf.org, ryuji@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 Hello Alex At Thu, 18 Nov 2004 22:34:55 +0100, Alexandru Petrescu wrote: > > Ryuji Wakikawa wrote: > > > Hello Alex > > Hey Ryuji! Thanks for your answers. If I'm not clear somewhere, please > tell me. > > >> Is there another justification and need for HAHA other than path > >> improvement? > > > > Yes, of course. You can check the presentation slide presented in > > NEMO WG. http://www.mobilenetworks.org/nemo/ietf58/slides/ > > These slides spell to me "Load Balancing and High Availability and > Optimal Paths (RO) are all goals of HAHA". Am I wrong? Yes. > If I am not wrong then I'd suggest: > -make sure HAHA targets load balancing and thus remove all reference to > HAHA from the Problem Statement draft or > -make sure HAHA targets RO, keep HAHA in the RO PS draft, and remove > Load Balancing and High Availability from the slides you reference > above. Thanks for input. Let me clarify what authors are trying at this point. We try to separate the HAHA draft after we got comments that HAHA has too many things in single draft. Thus, we first define the base specification (protocol part) in the haha-protocol and protocol usage and operations into another draft (haha-globa is just one of). We couldnot complete other operational drafts for loadbalance/redundancy at this point. > The PS draft should not describe HA Load Balancing problems, no? > > >>>> Add to this that the IP distance oHA-nHA must be small in order > >>>> to allow for route updates to not explose routing tables. > >>> > >>> Can you clarify this? The distance of oHA and nHA is not > >>> critical. > >> > >> Thanks for asking. I have a set of remarks that I usually give > >> when discussing HAHA, but it's a bit long. Feel free to skip. > >> > >> I think the IP distance between oHA and nHA must be small in order > >> for route updates to take be able to take effects. I mean the IP > >> distance, and not the physical distance. IP distance is the number > >> of IP hops. The larger the IP distance, the smaller chances are > >> that you can use route updates. > >> > >> Obviously, one can have oHA and nHA very far away physically > >> (different continents) but still very close in terms of IP, maybe > >> even neighbours. One can also have oHA and nHA near each other but > >> with very long IP distances between them. > >> > >> In my oppinion, it is on these apparent contradictions that HAHA > >> relies. On one hand it says: because you're in London you're > >> obviously closer to London HA than Melbourne HA (physical > >> distance), on another hand it assumes both HAs are close in IP > >> terms (such as route updates are possible). > > > > > > Which route updates are you talking about? Binding synchrnoization or > > route update for the home network prefix? > > Route updates that update the routes towards MNP and route updates that > update the routes towards HoA. Not the Binding Sync messages. > > >>>> To me, this means that: if you can use route updates to update > >>>> paths to MR, and if the new paths are _much_ shorter, then use > >>>> this and there is no need to use Mobile IP too. > >>> > >>> > >>> When HA propagates the home network prefix to the Internet, the > >>> route entry is never changed unless HA changes its address. (The > >>> route is relatively stable). > >> > >> Ok, I see. But there must be two routes of this kind of stable > >> route, no? There must be one stable route towards the HoA > >> proxy-ND'ed by oHA and another stable route towards the HoA > >> proxy-ND'ed by nHA, no? And > > > > > > what is HoA proxy-NDed? > > A stable route towards the Home Address for which the new Home Agent is > entitled to do proxy Neighbour Discovery. > > > HA only advertise the whole mobile network prefix to the Internet. > > Among HAs, they may exchange route of certain MNP. > > The HA advertises the super-prefix (/48 home link out of which /64s are > derived) to the Internet. This super-prefix can not change when the MR > attaches to a new HA. Do we agree on this? May I call this the Home > Network model? (not the Extended Home Network model). > > I do not see why oHA and nHA would exchange routes (actually nHA sends a > route update to oHA) towards MNP. oHA and nHA exchanging MNPs is > worthless if these MNPs are not advertised towards the Internet too. I think what you miss here is that each HA advertise the same super-prefix to the Internet. The route for the same prefix is advertised from different network. For example, packets from CN1 may reach to oHA, but others from CN2 may reach to nHA. Please refer the base spec ( draft-wakikawa-mip6-nemo-haha-spec-00.txt) for more info. > >> packets from CN to the MR must actually be duplicated to both of > >> these paths, no? > > > > duplication? no. > > Ok! We agree! So a packet from CN towards a fixed Home Address will > take a unique definite path, it won't be multicasted. This path must > lead to one HA. If one needs to modify this path to lead to another new > HA, then a route update in the Internet is necessary, no? No... Since multiple HAs have the same super-prefix and advertise the same prefix to the Internet. > >>> On the other hand, the path to MR is changed according to MR's > >>> movement. Propagation of route updaes from MR is not doable. We > >>> still need MobileIP. > >> > >> I agree that route updates from MR is not doable. I agree we need > >> Mobile IP. > > Me too. Route updates from MR, or from HA, or from CN to the Internet > can probably not cope with the number of MRs and the number of routers > in between. > > >> What I mean is that if we use Mobile IP (and not route updates) > >> then HAHA (route updates between oHA and nHA and BC sync) can not > >> bring any significant benefit in path improvement. > > > > AFAIK, You statement is wrong:-p > > To me, it's simply right. If one uses Mobile IP it is because numerous > path updates in the Internet are not possible (the path updates that > would be generated by numerous mobiles moving around). If path updates > _are_ possible, then Mobile IP is not needed. Why would one update a > path, and at the same time bother to use MR-HA tunnels? > > >> are potentially much larger than the distance oHA-nHA (the one that > >> is reduced). > > > > For example, with HAHA, MR supposes to associate with the closer HA. > > It is useful for MR to associate with the closer HA _only_ if this HA > can also intercept packets addressed from CN to the HoA that was valid > at the old HA, no? Alex, HoA is never changed on the HAHA. Even if each HA is located at different links, this is transparent to MR. > > It means HA-MR distance becomes shorter. > > Yes, the path nHA-MR may be shorter than oHA-MR. However, it is not > enough for _that_ path to be shorter in order to be beneficial. RO does > not look at shortening the HA-MR paths, but at CN-MR paths. SO you want > the path CN-nHA-MR to be much shorter than the path CN-oHA-MR. The path > oHA-nHA must be small such as to allow for route updates (if route > updates, not BC syncs, are used between HAs) are used. If HAHA > eliminates that short oHA-nHA path then there is no benefit in using it > because it is much smaller than what the CN-HA or HA-MR paths may become. Well, as I wrote in previous mail, the path between CN and MR can be different in each direction. From CN->MR, you can use CN-oHA-MR path if it is shorter. In other direction, you can use MR-nHA-CN if it's shorter, too. > > CN's packet will be interecepted by the nearest HA from CN. > > This assumes that your nHA is nearer the CN than the oHA, and at > the same time that the nHA is nearer the MR than the oHA, and at the > same time that a Home Address is reachable at both HAs. Am I right? Yes. > Or does it only assume that whatever HA is closer to CN can intercept a > packet towards HoA and forward it to the current HA? If this is what > you meant, then all HAs must be able to intercept a certain HoA and at > the same time when this inter-HA forwarding takes place it induces new > angles to the multi-angular paths. This is YES, too. This is already specified in the HAHA-global draft. You don't need ProxyND to intercept packets for NEMO, since packet is intercepted by using routing table. > This one-HA-close-to-any-CN-and-wherever-MR-goes may also be possible in > some closed system. This is a possibility indeed. It still stays a > small system. > > > Thus, CN-HA path gets shorter. > > Yes, it may be shortened by 1 or 2 IP hops with a total distance of 10 > hops. Like RO reducing the path from 10 hops to 9 hops. I don't think > the PS draft should look into these solutions, it's too much effort for > too little achievement. I can not agree with this argument. How many hops you can reduce totally depends on topology (where HAs are configured). > > There is another operation to bypass oHA-nHA tunnel. MR associates > > with the closer HA (nHA) and uses it for deliverying packets to the > > Internet. On the other hand, MR receives packets meant for its MNP > > tunneled by the closer HA of CN. > > > > path from MR to CN MR - HA =============> CN tunnel > > > > path from CN to MR MR <==============HA - CN tunnel > > Great! So we end up with a smaller triangular routing, not the maximum > triangular routing CN-HA-MR. This looks to me like an intermediate step > on an RO scale. The goal of RO should be to have straight paths MR-CN, > not through some other HA, even if closer, no? If HA is on the path from CN to MR, it is not critical except for tunnel. (But most of RO solution relies on tunnel). In the current Internet, many packets are routed through one of IXP. If HA is located at IXPs, the redundant path can be kept minimum. When HA is just on the way to MR from CN, do you see critical overhead? > If you do this little triangle, why would MR bother to bind its HoA to > its CoA at nHA? It would not need to send binding updates at all to > nHA, just tunnel packets to CN, no need of Mobile IP, no? MR basically sends single BU to HAs all the time. That's why we introduce binding synchronization in HAHA. regards, ryuji From nemo-bounces@ietf.org Fri Nov 19 03:57: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 DAA06262 for ; Fri, 19 Nov 2004 03:57:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV4Yo-0003cF-Oe; Fri, 19 Nov 2004 03:56:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV4Rh-0002RG-BK for nemo@megatron.ietf.org; Fri, 19 Nov 2004 03:48: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 DAA05713 for ; Fri, 19 Nov 2004 03:48:43 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV4UT-0006Bp-IA for nemo@ietf.org; Fri, 19 Nov 2004 03:51:38 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2004 09:55:18 +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 iAJ8liea018687; Fri, 19 Nov 2004 09:48:06 +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, 19 Nov 2004 09:48:05 +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: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt Date: Fri, 19 Nov 2004 09:48:02 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC497B2F@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt Thread-Index: AcTNrNtBweCdPzWRTj2kA4AHHEbXwQAZZgrg From: "Pascal Thubert \(pthubert\)" To: "Ryuji Wakikawa" X-OriginalArrivalTime: 19 Nov 2004 08:48:05.0225 (UTC) FILETIME=[7C3CE590:01C4CE14] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Greg.Daley@eng.monash.edu.au, cjbc@it.uc3m.es 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 Ryuji > > > > But We can not say 'any MANET' will do. We must explicit what our > > priorities are and what features we care for. And we must come back > > with a single MANET version so there's a chance to get standard > > track one day. >=20 > I did not say "any MANET";-) Never meant you did :) >=20 > The draft is problem statement and tries to expose the possibility of > MANET to some NEMO issue. >=20 Right: there's the high level perspective (the problem statement level) where we say " MANET here can do this and that for NEMO" and the detailed level where we would actually characterize the features in the instance that would fit the problem best. I'm afraid I'm going too deep in the latter for the sake of the current charter. It's still an interesting discussion. If people are interested in pursuing it, maybe we could set up a separate list? =20 > well, the discussion of RO solution is not begun yet, too. > But it might be true that we need more thoughts on this with people > from NEMO and MANET WG. Agreed. Pascal From nemo-bounces@ietf.org Fri Nov 19 05:19:58 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 FAA13000 for ; Fri, 19 Nov 2004 05:19: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 1CV5nq-0002WF-Ls; Fri, 19 Nov 2004 05:15:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV5aR-0008VI-IH for nemo@megatron.ietf.org; Fri, 19 Nov 2004 05:01: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 FAA11607 for ; Fri, 19 Nov 2004 05:01:49 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV5dE-00085Z-Cf for nemo@ietf.org; Fri, 19 Nov 2004 05:04:45 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAJA3KNu028410; Fri, 19 Nov 2004 03:03:20 -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 iAJA1kvH013001; Fri, 19 Nov 2004 04:01:47 -0600 Received: from [10.161.201.129] (zfr01-2129.crm.mot.com [10.161.201.129]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4612885C461; Fri, 19 Nov 2004 11:01:46 +0100 (CET) Message-ID: <419DC489.9040305@motorola.com> Date: Fri, 19 Nov 2004 11:01:45 +0100 From: Christophe Janneteau User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , Ryuji Wakikawa , nemo@ietf.org Subject: Re: [nemo] My simple thoughts on HAHA References: <7892795E1A87F04CADFCCF41FADD00FC497894@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC497894@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Alexandru Petrescu 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 Ryuji, Pascal, Alex, Sorry to jump into the discussion.... Pascal Thubert (pthubert) wrote: > The draft says that the CN reaches Home via the closest point of > presence, so if CN does not move, then this does not change. MR keeps > its MNP, and the MNP information is distributed by a routing protocol > over a mesh of tunnels between HAs. The CN is not supposed to see the MR > HoA (it's just a binding ID), unless it is formed from the MNP. The > whole concept of Home link is gone. In my understanding of HAHA, several HAs will annouce a route in an _internetwork_ to the same MNP. The packet sent by CN (addressed to a node of MNP) will reach the closest HA (e.g. HA annoucing MNP with the smallest metric). And HA will tunnel the packet to MR. Correct? Now the question is: what type of internetwork are we talking about? 1- The global Internet?, or 2- Only a site? in which case all HA would belong to the same site, and there would be only one route advertised from the site gateway to the Internet. I think 1 would be an issue, especially for IPv6 (see multi6 work). No? In other words, what are the realist deployement scenarios targeted by the draft? Thanks Christophe From nemo-bounces@ietf.org Fri Nov 19 05:54:43 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 FAA15581 for ; Fri, 19 Nov 2004 05: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 1CV6Nh-0001HB-1X; Fri, 19 Nov 2004 05:52:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV6Hk-0000HC-SE for nemo@megatron.ietf.org; Fri, 19 Nov 2004 05:46:36 -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 FAA14877 for ; Fri, 19 Nov 2004 05:46:34 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV6KW-0000Yb-0T for nemo@ietf.org; Fri, 19 Nov 2004 05:49:31 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id iAJAkVua010025; Fri, 19 Nov 2004 03:46:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iAJ8k0Tp010058; Fri, 19 Nov 2004 02:46:00 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id ABC9585C461; Fri, 19 Nov 2004 11:46:28 +0100 (CET) Message-ID: <419DCF02.5080105@motorola.com> Date: Fri, 19 Nov 2004 11:46:26 +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: Ryuji Wakikawa Subject: Re: [nemo] My simple thoughts on HAHA References: <419B973D.3000709@motorola.com> <419C7085.2070905@motorola.com> <419D157F.7060704@motorola.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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 Ryuji, thank you for replies, it is good to know. Ryuji Wakikawa wrote: > Let me clarify what authors are trying at this point. We try to > separate the HAHA draft after we got comments that HAHA has too many > things in single draft. Thus, we first define the base specification > (protocol part) in the haha-protocol and protocol usage and > operations into another draft (haha-globa is just one of). We > couldnot complete other operational drafts for loadbalance/redundancy > at this point. Ryuji it seems to me this is a good approach. It is good to split in spec and usage documents. HAHA as I understand it is a protocol that may solve some problems within some systems. The HAHA base spec may specify a benefit-agnostic universal protocol and the HAHA usage drafts may exemplify what are its RO benefits, its Load Balance benefits, its Multi-Homing benefits on a per-item basis and so on, am I right? However, I do not see a direct link between HAHA and the NEMO Working Group. There has never been a NEMO Problem Statement that would require a solution like HAHA. There is nothing in the Charter (AFAIK) about requiring HAHA. There is no HAHA Problem Statement. Secondly, many of the potential benefits of HAHA are valid to MH too. Thus I suggest maybe the mip6 WG is better interested first, and if they need it, then maybe NEMO needs it too. But I do not find it a good approach to push it here first. Thus, until Authors write the HAHA usage draft that pertains to RO benefits exclusively, it may not be necessary to cite or refer HAHA in the NEMO RO Problem Statement. > I think what you miss here is that each HA advertise the same > super-prefix to the Internet. The route for the same prefix is > advertised from different network. For example, packets from CN1 may > reach to oHA, but others from CN2 may reach to nHA. Ryuji, I think I can understand that. But, the problem that HAHA was trying to solve was like "it's unwise to attach to Melbourne HA if you're in London" and the solution was "please attach to London HA because closer". That problem and solution says nothing about where the CN is placed. It may very well be that there is HA near where you are but the CN is near where your old HA is. In this case, HAHA not only does not bring benefits, but it may actually _induce_ longer paths. No? > Please refer the base spec ( > draft-wakikawa-mip6-nemo-haha-spec-00.txt) for more info. Please take your time refer me to a specific paragraph in that draft. >> Ok! We agree! So a packet from CN towards a fixed Home Address >> will take a unique definite path, it won't be multicasted. This >> path must lead to one HA. If one needs to modify this path to lead >> to another new HA, then a route update in the Internet is >> necessary, no? > > > No... Since multiple HAs have the same super-prefix and advertise the > same prefix to the Internet. This is a particular case. It does mean to me a lot about multi-homing. >> It is useful for MR to associate with the closer HA _only_ if this >> HA can also intercept packets addressed from CN to the HoA that was >> valid at the old HA, no? > > Alex, HoA is never changed on the HAHA. Even if each HA is located at > different links, this is transparent to MR. Ryuji, a HoA that is valid at two different HAs is a very special kind of scenario to me. >>> It means HA-MR distance becomes shorter. >> >> Yes, the path nHA-MR may be shorter than oHA-MR. However, it is >> not enough for _that_ path to be shorter in order to be beneficial. >> RO does not look at shortening the HA-MR paths, but at CN-MR paths. >> SO you want the path CN-nHA-MR to be much shorter than the path >> CN-oHA-MR. The path oHA-nHA must be small such as to allow for >> route updates (if route updates, not BC syncs, are used between >> HAs) are used. If HAHA eliminates that short oHA-nHA path then >> there is no benefit in using it because it is much smaller than >> what the CN-HA or HA-MR paths may become. > > > Well, as I wrote in previous mail, the path between CN and MR can be > different in each direction. From CN->MR, you can use CN-oHA-MR path > if it is shorter. In other direction, you can use MR-nHA-CN if it's > shorter, too. I see what you mean. It still lacks logic, it's like saying that the path between two points is shorter in one direction and longer in the other direction; or that there are two different shortest paths between two points depending on the direction (if it's shortest in one direction it should be shortest in the reverse direction too). >> This assumes that your nHA is nearer the CN than the oHA, and at >> the same time that the nHA is nearer the MR than the oHA, and at >> the same time that a Home Address is reachable at both HAs. Am I >> right? > > > Yes. Look, if you believe this is correct, I believe this can not be achieved, because an MR does not choose its CNs. It's the user who chooses a CN. The MR may choose its HA, but the CN is chosen by the user. And the CN may be _any_ end node in the Internet. >> Or does it only assume that whatever HA is closer to CN can >> intercept a packet towards HoA and forward it to the current HA? >> If this is what you meant, then all HAs must be able to intercept a >> certain HoA and at the same time when this inter-HA forwarding >> takes place it induces new angles to the multi-angular paths. > > > This is YES, too. This is already specified in the HAHA-global draft. > You don't need ProxyND to intercept packets for NEMO, since packet > is intercepted by using routing table. Look, I think we are in a very large disagreement here, but we may discuss this on another thread. Basically, NEMO Basic Support doesn't say "you don't need proxyND" and it does not forbid it either. >> This one-HA-close-to-any-CN-and-wherever-MR-goes may also be >> possible in some closed system. This is a possibility indeed. It >> still stays a small system. >> >> >>> Thus, CN-HA path gets shorter. >> >> Yes, it may be shortened by 1 or 2 IP hops with a total distance of >> 10 hops. Like RO reducing the path from 10 hops to 9 hops. I >> don't think the PS draft should look into these solutions, it's too >> much effort for too little achievement. > > > I can not agree with this argument. How many hops you can reduce > totally depends on topology (where HAs are configured). It depends on the HA topology and on where the CNs are placed too. >>> There is another operation to bypass oHA-nHA tunnel. MR >>> associates with the closer HA (nHA) and uses it for deliverying >>> packets to the Internet. On the other hand, MR receives packets >>> meant for its MNP tunneled by the closer HA of CN. >>> >>> path from MR to CN MR - HA =============> CN tunnel >>> >>> path from CN to MR MR <==============HA - CN tunnel >> >> Great! So we end up with a smaller triangular routing, not the >> maximum triangular routing CN-HA-MR. This looks to me like an >> intermediate step on an RO scale. The goal of RO should be to have >> straight paths MR-CN, not through some other HA, even if closer, >> no? > > > If HA is on the path from CN to MR, it is not critical except for > tunnel. (But most of RO solution relies on tunnel). In the current > Internet, many packets are routed through one of IXP. If HA is > located at IXPs, the redundant path can be kept minimum. Ryuji, I think we have a larger disagreement here. I do not believe that having HA in the IXP and without using Proxy-ND is in the scope of NEMO. I really think what you say may be possible, maybe even recommendable to do in order to achieve shorter paths, but I don't think we can do this in NEMO. This is not Routing Area. > When HA is just on the way to MR from CN, do you see critical > overhead? I see unnecessary overhead because encapsulation. >> If you do this little triangle, why would MR bother to bind its HoA >> to its CoA at nHA? It would not need to send binding updates at >> all to nHA, just tunnel packets to CN, no need of Mobile IP, no? > > > MR basically sends single BU to HAs all the time. That's why we > introduce binding synchronization in HAHA. Yes, I knew that. Alex From nemo-bounces@ietf.org Fri Nov 19 08:46:03 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 IAA01724 for ; Fri, 19 Nov 2004 08:46: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 1CV8xs-0003Pc-Qc; Fri, 19 Nov 2004 08:38:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV8qE-00022a-Kd for nemo@megatron.ietf.org; Fri, 19 Nov 2004 08:30: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 IAA00099 for ; Fri, 19 Nov 2004 08:30:21 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV8t3-0004MC-C4 for nemo@ietf.org; Fri, 19 Nov 2004 08:33:18 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id iAJDMIGX023824 for ; Fri, 19 Nov 2004 06:22:18 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id iAJDMD4V019408 for ; Fri, 19 Nov 2004 07:22:14 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4FC1C8A3C70 for ; Fri, 19 Nov 2004 14:30:17 +0100 (CET) Message-ID: <419DF568.6050205@motorola.com> Date: Fri, 19 Nov 2004 14:30:16 +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: nemo@ietf.org X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [nemo] Question on HAHA, about deployment of HAs 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 Ryuji, does HAHA assume that in order to bring good benefits in path reduction, one would need to deploy a HA near every CN that MR may write to, and another HA near any place MR may roam to? Or does it just assume that HA is present at a few large intersection nodes like IXP? Does HAHA couple with CR of ORC? CR of ORC assumes that benefits are gained when a CR is deployed near CN. Thanks, Alex From nemo-bounces@ietf.org Fri Nov 19 09:06:38 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 JAA03439 for ; Fri, 19 Nov 2004 09:06:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV9DK-0007ZZ-Rh; Fri, 19 Nov 2004 08:54:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV99T-0006Wt-Qd for nemo@megatron.ietf.org; Fri, 19 Nov 2004 08: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 IAA02081 for ; Fri, 19 Nov 2004 08:50:14 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV9CI-0004nR-Ol for nemo@ietf.org; Fri, 19 Nov 2004 08:53:12 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2004 14:56:52 +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 iAJDn5ei003986; Fri, 19 Nov 2004 14:49:39 +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, 19 Nov 2004 14:49:37 +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] My simple thoughts on HAHA Date: Fri, 19 Nov 2004 14:49:33 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC497CCD@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] My simple thoughts on HAHA Thread-Index: AcTOHthSaZT+xuKhQEKsKx+dhVZFlwAH0y0Q From: "Pascal Thubert \(pthubert\)" To: "Christophe Janneteau" , "Ryuji Wakikawa" , X-OriginalArrivalTime: 19 Nov 2004 13:49:37.0393 (UTC) FILETIME=[9C02A610:01C4CE3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: Alexandru Petrescu 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: Christophe Janneteau [mailto:Christophe.Janneteau@motorola.com] > Sent: vendredi 19 novembre 2004 11:02 > To: Pascal Thubert (pthubert); Ryuji Wakikawa; nemo@ietf.org > Cc: Alexandru Petrescu > Subject: Re: [nemo] My simple thoughts on HAHA >=20 > Ryuji, Pascal, Alex, >=20 > Sorry to jump into the discussion.... >=20 > Pascal Thubert (pthubert) wrote: > > The draft says that the CN reaches Home via the closest point of > > presence, so if CN does not move, then this does not change. MR keeps > > its MNP, and the MNP information is distributed by a routing protocol > > over a mesh of tunnels between HAs. The CN is not supposed to see the MR > > HoA (it's just a binding ID), unless it is formed from the MNP. The > > whole concept of Home link is gone. >=20 > In my understanding of HAHA, several HAs will annouce a route in an > _internetwork_ to the same MNP. The packet sent by CN (addressed to a > node of MNP) will reach the closest HA (e.g. HA annoucing MNP with the > smallest metric). And HA will tunnel the packet to MR. Correct? >=20 > Now the question is: what type of internetwork are we talking about? > 1- The global Internet?, or > 2- Only a site? in which case all HA would belong to the same site, and > there would be only one route advertised from the site gateway to the > Internet. >=20 > I think 1 would be an issue, especially for IPv6 (see multi6 work). No? Could you please elaborate? >=20 > In other words, what are the realist deployement scenarios targeted by > the draft? >=20 I guess the draft is very simplistic compared to what the deployment would be, for many aspect. Each ISP would have at least its mobile routing plane. They would interconnect and form one or more 'global home's. And common proxies would advertise these aggregations.=20 Whether its' realistic or not depends on the business model behind it. It seems feasible. Pascal From nemo-bounces@ietf.org Fri Nov 19 10:01:16 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 KAA08327 for ; Fri, 19 Nov 2004 10:01:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVA7a-00058J-81; Fri, 19 Nov 2004 09:52:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVA2s-0003uJ-Ci for nemo@megatron.ietf.org; Fri, 19 Nov 2004 09:47:30 -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 JAA07047 for ; Fri, 19 Nov 2004 09:47:28 -0500 (EST) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVA5i-00069i-Rx for nemo@ietf.org; Fri, 19 Nov 2004 09:50:27 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id iAJElRtQ008472; Fri, 19 Nov 2004 07:47:28 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iAJCkuTp007717; Fri, 19 Nov 2004 06:46:57 -0600 Received: from [10.161.201.129] (zfr01-2129.crm.mot.com [10.161.201.129]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 34B4E8A3C6C; Fri, 19 Nov 2004 15:47:25 +0100 (CET) Message-ID: <419E077B.4020909@motorola.com> Date: Fri, 19 Nov 2004 15:47:23 +0100 From: Christophe Janneteau User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] My simple thoughts on HAHA References: <7892795E1A87F04CADFCCF41FADD00FC497CCD@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC497CCD@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Ryuji Wakikawa , Alexandru Petrescu 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 Pascal, Please read below.... Pascal Thubert (pthubert) wrote: > >> -----Original Message----- From: Christophe Janneteau >> [mailto:Christophe.Janneteau@motorola.com] Sent: vendredi 19 >> novembre 2004 11:02 To: Pascal Thubert (pthubert); Ryuji Wakikawa; >> nemo@ietf.org Cc: Alexandru Petrescu Subject: Re: [nemo] My simple >> thoughts on HAHA >> >> Ryuji, Pascal, Alex, >> >> Sorry to jump into the discussion.... >> >> Pascal Thubert (pthubert) wrote: >> >>> The draft says that the CN reaches Home via the closest point of >>> presence, so if CN does not move, then this does not change. MR > > keeps > >>> its MNP, and the MNP information is distributed by a routing > > protocol > >>> over a mesh of tunnels between HAs. The CN is not supposed to see >>> > > the MR > >>> HoA (it's just a binding ID), unless it is formed from the MNP. >>> The whole concept of Home link is gone. >> >> In my understanding of HAHA, several HAs will annouce a route in an >> _internetwork_ to the same MNP. The packet sent by CN (addressed >> to a node of MNP) will reach the closest HA (e.g. HA annoucing MNP >> with the smallest metric). And HA will tunnel the packet to MR. >> Correct? >> >> Now the question is: what type of internetwork are we talking >> about? 1- The global Internet?, or 2- Only a site? in which case >> all HA would belong to the same site, > > and > >> there would be only one route advertised from the site gateway to >> the Internet. >> >> I think 1 would be an issue, especially for IPv6 (see multi6 work). >> > > No? > > Could you please elaborate? In case 1, several HAs in _different_ sites would announce a route for the same MNP in the Internet, possibly up to the default free zone (DFZ). When the number of MNPs announced in this way in the DFZ becomes large, the DFZ becomes overloaded with these routes (scalability issues). While it seems that such route injection in the DFZ is a common approach in IPv4 to support multi-homing, it is also desirable to find more scalable ways to support multi-homing in IPv6. This is what the multi6 WG is working on AFAIK. The charter provides a good description of the issue. In my understanding the HAHA approach in case 1 would rely on the fact that (as for IPv4) route injection in the DFZ is possible. But this may not be the recommended approach for IPv6 however. What do you think? Christophe From nemo-bounces@ietf.org Fri Nov 19 10:30:47 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 KAA12265 for ; Fri, 19 Nov 2004 10:30:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVAgN-00011C-EI; Fri, 19 Nov 2004 10:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVATp-0005hK-8k for nemo@megatron.ietf.org; Fri, 19 Nov 2004 10:15: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 KAA10334 for ; Fri, 19 Nov 2004 10:15: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 1CVAWf-0006mA-I0 for nemo@ietf.org; Fri, 19 Nov 2004 10:18:18 -0500 Received: from iseran.local (ZB125130.ppp.dion.ne.jp [219.125.125.130]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1FB734C0BB for ; Sat, 20 Nov 2004 00:14:35 +0900 (JST) Date: Sat, 20 Nov 2004 00:17:02 +0900 From: Thierry Ernst To: nemo Subject: Re: [nemo] My simple thoughts on HAHA Message-Id: <20041120001702.621c3ebd.ernst@sfc.wide.ad.jp> In-Reply-To: <419DCF02.5080105@motorola.com> References: <419B973D.3000709@motorola.com> <419C7085.2070905@motorola.com> <419D157F.7060704@motorola.com> <419DCF02.5080105@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.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 On Fri, 19 Nov 2004 11:46:26 +0100 Alexandru Petrescu wrote: > Ryuji it seems to me this is a good approach. It is good to split in > spec and usage documents. HAHA as I understand it is a protocol that > may solve some problems within some systems. The HAHA base spec may > specify a benefit-agnostic universal protocol and the HAHA usage drafts > may exemplify what are its RO benefits, its Load Balance benefits, its > Multi-Homing benefits on a per-item basis and so on, am I right? > > However, I do not see a direct link between HAHA and the NEMO Working > Group. There has never been a NEMO Problem Statement that would require > a solution like HAHA. There is nothing in the Charter (AFAIK) about > requiring HAHA. There is no HAHA Problem Statement. What's the point here, Alex ? It is correct that this is not in the charter, but are you suggesting that this discussion should be happening on the NEMO ML because it's not a charter item ? > Secondly, many of the potential benefits of HAHA are valid to MH too. > Thus I suggest maybe the mip6 WG is better interested first, and if they > need it, then maybe NEMO needs it too. But I do not find it a good > approach to push it here first. > > Thus, until Authors write the HAHA usage draft that pertains to RO > benefits exclusively, it may not be necessary to cite or refer HAHA in > the NEMO RO Problem Statement. Alex, I totally disagree here. If the RO PS is about studying potential approaches (which is still doubtul), I don't see why some potential solutions should be excluded from the analysis. Potential solutions don't even have to be proposed at the IETF. Thierry From nemo-bounces@ietf.org Fri Nov 19 11:38: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 LAA19023 for ; Fri, 19 Nov 2004 11:38:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBah-0007X2-F8; Fri, 19 Nov 2004 11:26:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBTV-000591-6T for nemo@megatron.ietf.org; Fri, 19 Nov 2004 11:19: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 LAA17043 for ; Fri, 19 Nov 2004 11:19:02 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVBWJ-0008JD-99 for nemo@ietf.org; Fri, 19 Nov 2004 11:22:02 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id iAJGKVqK012048; Fri, 19 Nov 2004 09:20:31 -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 iAJGIeq7016384; Fri, 19 Nov 2004 10:18:41 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 61E8C8A3C6C; Fri, 19 Nov 2004 17:18:57 +0100 (CET) Message-ID: <419E1CF1.5010902@motorola.com> Date: Fri, 19 Nov 2004 17:18:57 +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: Thierry Ernst Subject: Re: [nemo] My simple thoughts on HAHA References: <419B973D.3000709@motorola.com> <419C7085.2070905@motorola.com> <419D157F.7060704@motorola.com> <419DCF02.5080105@motorola.com> <20041120001702.621c3ebd.ernst@sfc.wide.ad.jp> In-Reply-To: <20041120001702.621c3ebd.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit 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 Thierry, let me clarify my message, Thierry Ernst wrote: >> Ryuji it seems to me this is a good approach. It is good to split >> in spec and usage documents. HAHA as I understand it is a >> protocol that may solve some problems within some systems. The >> HAHA base spec may specify a benefit-agnostic universal protocol >> and the HAHA usage drafts may exemplify what are its RO benefits, >> its Load Balance benefits, its Multi-Homing benefits on a per-item >> basis and so on, am I right? >> >> However, I do not see a direct link between HAHA and the NEMO >> Working Group. There has never been a NEMO Problem Statement that >> would require a solution like HAHA. There is nothing in the >> Charter (AFAIK) about requiring HAHA. There is no HAHA Problem >> Statement. > > What's the point here, Alex ? It is correct that this is not in the > charter, but are you suggesting that this discussion should be > happening on the NEMO ML because it's not a charter item ? No I did not try to say that. Chairs decide what discussion is appropriate. I just said that there is no HAHA problem statement and that HAHA is not in the Charter. >> Secondly, many of the potential benefits of HAHA are valid to MH >> too. Thus I suggest maybe the mip6 WG is better interested first, >> and if they need it, then maybe NEMO needs it too. But I do not >> find it a good approach to push it here first. >> >> Thus, until Authors write the HAHA usage draft that pertains to RO >> benefits exclusively, it may not be necessary to cite or refer HAHA >> in the NEMO RO Problem Statement. > > > Alex, I totally disagree here. If the RO PS is about studying > potential approaches (which is still doubtul), I don't see why some > potential solutions should be excluded from the analysis. Potential > solutions don't even have to be proposed at the IETF. Thierry, you're right it is still doubtful whether the RO PS item studies potential approaches as it does now. However, there should be a difference when analyzing and referencing the potential solutions. For example parts of RFC's that specifically may help with NEMO RO should be given priority over parts of individual drafts, IMHO. More specifically, it is strange to see section 3.2 Infrastructure Optimization describes an optimization in terms of the "C-side" router (ok, not the "CR" of ORC) when it's clear to me that if any such optimization is to take place it should spell "BGP" or "OSPF" at least (my oppinion). If we let a specific RO PS analyze all possibly imaginable solutions, and we'd still like it to be non-partial, then the draft risks to become real big. There are and always will still be things that have _not_ been discussed recently, and that are _not_ parts of the taxonomy draft, and that someone may like to include one day in the RO PS. One thing that comes to mind is "renumbering", or "router renumbering RR". Finally, let me re-say I agree that Chairs decide what's being discussed or not. Alex From nemo-bounces@ietf.org Fri Nov 19 11: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 LAA19608 for ; Fri, 19 Nov 2004 11:43:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBoC-0003Hz-6F; Fri, 19 Nov 2004 11:40:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBgX-0000su-H3 for nemo@megatron.ietf.org; Fri, 19 Nov 2004 11:32:33 -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 LAA18341 for ; Fri, 19 Nov 2004 11:32:30 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVBjO-00009l-4A for nemo@ietf.org; Fri, 19 Nov 2004 11:35:30 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2004 17:39:12 +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 iAJGVaea016343; Fri, 19 Nov 2004 17:31:58 +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, 19 Nov 2004 17:31:56 +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] My simple thoughts on HAHA Date: Fri, 19 Nov 2004 17:31:40 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC497D9B@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] My simple thoughts on HAHA Thread-Index: AcTORriBAWGJpEGDT7WFQynStpL61wABf/SQ From: "Pascal Thubert \(pthubert\)" To: "Christophe Janneteau" X-OriginalArrivalTime: 19 Nov 2004 16:31:56.0034 (UTC) FILETIME=[48B15620:01C4CE55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Ryuji Wakikawa , Alexandru Petrescu 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: Christophe Janneteau [mailto:Christophe.Janneteau@motorola.com] > Sent: vendredi 19 novembre 2004 15:47 > To: Pascal Thubert (pthubert) > Cc: Ryuji Wakikawa; nemo@ietf.org; Alexandru Petrescu > Subject: Re: [nemo] My simple thoughts on HAHA >=20 > Pascal, >=20 > Please read below.... >=20 > Pascal Thubert (pthubert) wrote: > > > >> -----Original Message----- From: Christophe Janneteau > >> [mailto:Christophe.Janneteau@motorola.com] Sent: vendredi 19 > >> novembre 2004 11:02 To: Pascal Thubert (pthubert); Ryuji Wakikawa; > >> nemo@ietf.org Cc: Alexandru Petrescu Subject: Re: [nemo] My simple > >> thoughts on HAHA > >> > >> Ryuji, Pascal, Alex, > >> > >> Sorry to jump into the discussion.... > >> > >> Pascal Thubert (pthubert) wrote: > >> > >>> The draft says that the CN reaches Home via the closest point of > >>> presence, so if CN does not move, then this does not change. MR > > > > keeps > > > >>> its MNP, and the MNP information is distributed by a routing > > > > protocol > > > >>> over a mesh of tunnels between HAs. The CN is not supposed to see > >>> > > > > the MR > > > >>> HoA (it's just a binding ID), unless it is formed from the MNP. > >>> The whole concept of Home link is gone. > >> > >> In my understanding of HAHA, several HAs will annouce a route in an > >> _internetwork_ to the same MNP. The packet sent by CN (addressed > >> to a node of MNP) will reach the closest HA (e.g. HA annoucing MNP > >> with the smallest metric). And HA will tunnel the packet to MR. > >> Correct? > >> > >> Now the question is: what type of internetwork are we talking > >> about? 1- The global Internet?, or 2- Only a site? in which case > >> all HA would belong to the same site, > > > > and > > > >> there would be only one route advertised from the site gateway to > >> the Internet. > >> > >> I think 1 would be an issue, especially for IPv6 (see multi6 work). > >> > > > > No? > > > > Could you please elaborate? >=20 > In case 1, several HAs in _different_ sites would announce a route for > the same MNP in the Internet, possibly up to the default free zone > (DFZ). When the number of MNPs announced in this way in the DFZ becomes > large, the DFZ becomes overloaded with these routes (scalability issues). >=20 > While it seems that such route injection in the DFZ is a common approach > in IPv4 to support multi-homing, it is also desirable to find more > scalable ways to support multi-homing in IPv6. This is what the multi6 > WG is working on AFAIK. The charter provides a good description of the > issue. >=20 > In my understanding the HAHA approach in case 1 would rely on the fact > that (as for IPv4) route injection in the DFZ is possible. But this may > not be the recommended approach for IPv6 however. >=20 > What do you think? First, this does not need to create any new area nb into the DFZ.=20 But if your question is about a potential fragmentation of the ISP aggregation, then it's possible. WRT multi6, I'm not too sure it compares. Depends on which home we are talking about. I wrote this draft with (4G VoIP capable) ISPs in mind, managing a Home Network as part of their services, as opposed to sites which would be given an address block to make a Home of it. So that would not be the same order of magnitude. They could partition that home into mobile address blocks for the corporate customers, but that's another story (eg, mobile home). An ISP would split its mobile and non mobile worlds, and they would be advertised separately. That could up-to double the size of the DFZ tables. A non mobile aggregation would be advertised from its location. A mobile aggregation would be advertised from all of the owner SP locations. BGP routers would keep the closest one anyway, as usual. Maybe a checking on multipath operations here and there, but it should be OK. The way I see it (but I'm not network architect): BGP should be configured to filter out mobile routes if they are injected by proxies on behalf of partner ISPs. So if ISP B proxies for ISP A, B's proxy HAs will inject A's mobile aggregation into B's AS - and reciprocally A will do the same for B. But those routes will not leak into eBGP. So A and B do not have agreements, then the nearest reachable proxy for a MR from A within B's AS will be in the closest of A's ASes. Pascal From nemo-bounces@ietf.org Fri Nov 19 16:51: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 QAA28149 for ; Fri, 19 Nov 2004 16:51: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 1CVGMx-0005cR-MB; Fri, 19 Nov 2004 16:32:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVFmD-00041B-Po for nemo@megatron.ietf.org; Fri, 19 Nov 2004 15:54: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 PAA15735 for ; Fri, 19 Nov 2004 15:54:36 -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 1CVFp1-0007M6-CJ for nemo@ietf.org; Fri, 19 Nov 2004 15:57:38 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id A832C6220 for ; Fri, 19 Nov 2004 12:52:52 -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 56302-02 for ; Fri, 19 Nov 2004 12:52:51 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id C3C456219; Fri, 19 Nov 2004 12:52:51 -0800 (PST) Received: from www.kniveton.com (localhost [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 419C86122 for ; Fri, 19 Nov 2004 12:52:40 -0800 (PST) Received: from 200.55.70.208 (SquirrelMail authenticated user tj); by www.kniveton.com with HTTP; Fri, 19 Nov 2004 12:52:40 -0800 (PST) Message-ID: <4841.200.55.70.208.1100897560.squirrel@200.55.70.208> Date: Fri, 19 Nov 2004 12:52:40 -0800 (PST) From: "T.J. Kniveton" To: nemo@ietf.org User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at deimos.multihop.net Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: quoted-printable Subject: [nemo] Call for comments: Issues list 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 If anyone has any comments on the issue list Vijay posted, please speak u= p now. We are planning on moving forward very soon. TJ From nemo-bounces@ietf.org Sat Nov 20 12:37:22 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 MAA10564 for ; Sat, 20 Nov 2004 12:37: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 1CVYy8-00011e-JA; Sat, 20 Nov 2004 12:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVYep-0003f2-36 for nemo@megatron.ietf.org; Sat, 20 Nov 2004 12:04:19 -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 MAA07989 for ; Sat, 20 Nov 2004 12:04:15 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVYht-0000v0-Dv for nemo@ietf.org; Sat, 20 Nov 2004 12:07:29 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 366EF417C0 for ; Sat, 20 Nov 2004 18:03:47 +0100 (CET) Received: from [163.117.252.29] (unknown [163.117.252.29]) by smtp01.uc3m.es (Postfix) with ESMTP id 4EB0C417C5 for ; Sat, 20 Nov 2004 18:03:46 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <228D823E-3B16-11D9-84BB-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed To: nemo WG From: marcelo bagnulo braun Date: Sat, 20 Nov 2004 18:03:43 +0100 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [nemo] draft-bagnulo-nemo-multi6-00.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 Hi all, I have just submitted a draft containing a preliminary analysis of the application of multi6 to nemo multihoming. The idea is to identify the configurations where multi6 can be provide the multihoming support required by nemo. You can find it at: http://www.it.uc3m.es/marcelo/draft-bagnulo-nemo-multi6-00.txt Comments are appreciated regards, marcelo ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Sat Nov 20 19:39:01 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 TAA12198 for ; Sat, 20 Nov 2004 19:39: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 1CVfXS-0006Wg-Bc; Sat, 20 Nov 2004 19:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVfN6-0004NG-Ut for nemo@megatron.ietf.org; Sat, 20 Nov 2004 19:14:29 -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 TAA11127 for ; Sat, 20 Nov 2004 19:14:25 -0500 (EST) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVfQF-0001Lb-1P for nemo@ietf.org; Sat, 20 Nov 2004 19:17:43 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id iAL0EQ5W024985; Sat, 20 Nov 2004 17:14:26 -0700 (MST) Received: from [10.181.32.45] (mvp-10-181-32-45.ea.mot.com [10.181.32.45]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iAKMDrTp000805; Sat, 20 Nov 2004 16:13:54 -0600 Message-ID: <419FDDDD.8060004@motorola.com> Date: Sun, 21 Nov 2004 01:14:21 +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: "Dul, Andrew L" Subject: Re: [nemo] Announcing the Global HAHA draft References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, pthubert@cisco.com 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 Andrew, I'm following up on this message because somewhere in it you invite for comments so I do. Let me introduce myself, I'm a member of a lab with Motorola. I have an interest in moving networks (groupings of hosts that move homegeneously). The application space I'm looking at is relatively less precise than what Connexion by Boeing where they seem to have a very precise scenario and need. Dul, Andrew L wrote: > slides that you presented at the meeting. Were there any interesting > comments at the meeting regarding global-haha that you could > summarize to the list? Well, I wanted to comment more on global-haha, but there was a sudden change in scoping of the presentation so my comments were not really relevant. > I think one of the reasons why you haven't seen a lot of interest on > this draft is that the truly global mobility market is really very > small. Well, I have two comments here. One is that I think there is much interest in global haha in the context of NEMO, and I think I've seen interest in similar HA-HA comments in other mobility-related working groups as well (mip4). The other comment is about the market size. An average person where I live spends 100euros/year for mobile phone communication but may spend an order of magnitude more for travelling by plane. More persons speak on the mobile than travelling, but actual money spent may be similar. And some may even spend 4 orders of magnitude more in order to travel very far. > phone to talk to operations staff in Chicago. Given a set of BGP > routing tables Sydney. In the v4 world we have used a BGP rehoming > solution that can largely negate this issue. I just wanted to mention that I've just read somewhere that when BGP routes are allowed to be injected at several ISPs they must be at most or longer than /19 (v4 space). Is it so? Which leads me to think in an actual plane no more than 2^13 IP addresses or similar. Which may be more than enough when considering WLAN web in plane (max 555 seats), but may not be sufficient if sensors want to talk too. "Sensors" may not talk IP soon due to memory footprint, but maybe PDAs near laptops want, or maybe Bluetooth headsets, or similar. And this reasoning only if NAT is not used on the main router aboard. If it is, which I'm curious to know, then indeed things are different. > At this point it is unclear to me if a similar rehoming solution is > possible or desirable in the multihomed v6 world. This also may be > too much of a corner case but it is nonetheless an interesting case. YEs, I guess so, a case that I'm interested to know. For example, is it that the router onboard talks BGP, or the one on the ground? I also wanted to say it seems to me that passenger trajectories are usually known knowns (not random as in mobile handset trajectories). And I have the feeling this may ease the impact of route injection may have on the core routing tables. For example, if the ground router at the destination knows the plane shows above at exactly 02h55gmt then it could prepare in advance something for it. This may be far off what BGP can do, I;m not knowledgeable, just floating an idea. > In my opinion I believe that for a global mobility standard to be > truly successful it must allow for the mobile networks to roam > between service providers & BGP ASNs. This aspect brings up another > whole set of issues with address allocation, v6 multi-homing, and > integration with BGP. (Which maybe outside the scope of the NEMO > charter?) I think it is out of the scope of the present time. But I do think that more information about an actual deployment of networks that move is really useful, at least for me. In exchange, I have other examples of deployments of networks that move that I can describe, that don't use Mobile IP either, but have similar pre-known trajectories: trains. > I also note that many of these issues are still not finalized in the > v6 world from my current readings. Authentication & Authorization > for MR's to the mesh between ASNs is also a consideration. As Terry > Davis one of my colleagues stated in a previous mail, it is likely > that the aircraft networks will be connected to a number of other > networks via different mechanisms, some of them will be satellite > based, some air-to-ground, and some ground-to-ground when the > aircraft is between flights. The diversity of networks to which a plane may need to connect may induce the use of Mobile IP. However, Mobile IPv6 for NEMO does not have RO, so some paths may be unoptimal. If on the other hand if the plane can connect to a limited number of places with BGP then routes seem to me to be more or less optimal. Alex From nemo-bounces@ietf.org Mon Nov 22 05:50:45 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 FAA15336 for ; Mon, 22 Nov 2004 05:50: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 1CWBf1-0008W4-NP; Mon, 22 Nov 2004 05:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWBed-0008QL-K4 for nemo@megatron.ietf.org; Mon, 22 Nov 2004 05:42:45 -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 FAA14144 for ; Mon, 22 Nov 2004 05:42:40 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWBf0-0002Sk-Ez for nemo@ietf.org; Mon, 22 Nov 2004 05:43:07 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAMAerNi029757; Mon, 22 Nov 2004 03:40:53 -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 iAMAdIhZ027421; Mon, 22 Nov 2004 04:39:19 -0600 Received: from [10.161.201.129] (zfr01-2129.crm.mot.com [10.161.201.129]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9B3438A3A64; Mon, 22 Nov 2004 11:39:18 +0100 (CET) Message-ID: <41A1C1D5.5030503@motorola.com> Date: Mon, 22 Nov 2004 11:39:17 +0100 From: Christophe Janneteau User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Impact of HAHA route injection (was Re: [nemo] My simple thoughts on HAHA) References: <7892795E1A87F04CADFCCF41FADD00FC497D9B@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC497D9B@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Ryuji Wakikawa , Alexandru Petrescu 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 Pascal, Thanks a lot for your fast and detailed answer :) Below are some additional comments/questions... Pascal Thubert (pthubert) wrote: > >>-----Original Message----- >>From: Christophe Janneteau [mailto:Christophe.Janneteau@motorola.com] >>Sent: vendredi 19 novembre 2004 15:47 >>To: Pascal Thubert (pthubert) >>Cc: Ryuji Wakikawa; nemo@ietf.org; Alexandru Petrescu >>Subject: Re: [nemo] My simple thoughts on HAHA >> >>Pascal, >> >>Please read below.... >> >>Pascal Thubert (pthubert) wrote: >> >>>>-----Original Message----- From: Christophe Janneteau >>>>[mailto:Christophe.Janneteau@motorola.com] Sent: vendredi 19 >>>>novembre 2004 11:02 To: Pascal Thubert (pthubert); Ryuji Wakikawa; >>>>nemo@ietf.org Cc: Alexandru Petrescu Subject: Re: [nemo] My simple >>>>thoughts on HAHA >>>> >>>>Ryuji, Pascal, Alex, >>>> >>>>Sorry to jump into the discussion.... >>>> >>>>Pascal Thubert (pthubert) wrote: >>>> >>>> >>>>>The draft says that the CN reaches Home via the closest point of >>>>>presence, so if CN does not move, then this does not change. MR >>> >>>keeps >>> >>> >>>>>its MNP, and the MNP information is distributed by a routing >>> >>>protocol >>> >>> >>>>>over a mesh of tunnels between HAs. The CN is not supposed to see >>>>> >>> >>>the MR >>> >>> >>>>>HoA (it's just a binding ID), unless it is formed from the MNP. >>>>>The whole concept of Home link is gone. >>>> >>>>In my understanding of HAHA, several HAs will annouce a route in an >>>> _internetwork_ to the same MNP. The packet sent by CN (addressed >>>>to a node of MNP) will reach the closest HA (e.g. HA annoucing MNP >>>>with the smallest metric). And HA will tunnel the packet to MR. >>>>Correct? >>>> >>>>Now the question is: what type of internetwork are we talking >>>>about? 1- The global Internet?, or 2- Only a site? in which case >>>>all HA would belong to the same site, >>> >>>and >>> >>> >>>>there would be only one route advertised from the site gateway to >>>>the Internet. >>>> >>>>I think 1 would be an issue, especially for IPv6 (see multi6 work). >>>> >>> >>>No? >>> >>>Could you please elaborate? >> >>In case 1, several HAs in _different_ sites would announce a route for >>the same MNP in the Internet, possibly up to the default free zone >>(DFZ). When the number of MNPs announced in this way in the DFZ > > becomes > >>large, the DFZ becomes overloaded with these routes (scalability > > issues). > >>While it seems that such route injection in the DFZ is a common > > approach > >>in IPv4 to support multi-homing, it is also desirable to find more >>scalable ways to support multi-homing in IPv6. This is what the multi6 >>WG is working on AFAIK. The charter provides a good description of the >>issue. >> >>In my understanding the HAHA approach in case 1 would rely on the fact >>that (as for IPv4) route injection in the DFZ is possible. But this > > may > >>not be the recommended approach for IPv6 however. >> >>What do you think? > > > > First, this does not need to create any new area nb into the DFZ. > > But if your question is about a potential fragmentation of the ISP > aggregation, then it's possible. WRT multi6, I'm not too sure it > compares. Depends on which home we are talking about. I wrote this draft > with (4G VoIP capable) ISPs in mind, managing a Home Network as part of > their services, as opposed to sites which would be given an address > block to make a Home of it. So that would not be the same order of > magnitude. They could partition that home into mobile address blocks for > the corporate customers, but that's another story (eg, mobile home). > > An ISP would split its mobile and non mobile worlds, and they would be > advertised separately. That could up-to double the size of the DFZ > tables. A non mobile aggregation would be advertised from its location. > A mobile aggregation would be advertised from all of the owner SP > locations. BGP routers would keep the closest one anyway, as usual. > Maybe a checking on multipath operations here and there, but it should > be OK. Is my reading correct that the "doubling" of the size of the DFZ tables would be due to the fact that mobile aggregation are advertised from multiple locations with HAHA? In that case, I am still wondering whether HAHA, as a global route optimization solution, is worth such an impact on the DFZ. I can see HAHA as an interesting feature, as long as we are able to control its impact on the Internet as a whole. Such control seems easy if HAHA is deployed in a single site. It seems also doable to use HAHA between different sites that share the same ISP (so that MNP routes aggregate at this ISP, and does not go deeper in the Internet). On the other hand, IMHO, it is not possible to control the impact of HAHA "multiple route injection" if used between any site....with potentially significant impact on the Internet routing tables. If the above is correct (please correct me if not :) then it seems important IMHO to explicitly list such issues in the draft, and recommend the use of HAHA only in specific / well-controlled environments. A technical solution preventing any mis-usage of HAHA could also be needed. > The way I see it (but I'm not network architect): > > BGP should be configured to filter out mobile routes if they are > injected by proxies on behalf of partner ISPs. So if ISP B proxies for > ISP A, B's proxy HAs will inject A's mobile aggregation into B's AS - > and reciprocally A will do the same for B. But those routes will not > leak into eBGP. If the mobile routes for ISP-A (e.g. MNP-A) does not leak into ISP-B's eBGP, then only one route for MNP-A will be exposed in the Internet (i.e. towards ISP-A), which is fine. On the other hand, because of that, it seems to me that all packets from any CN in the Internet (but CNs in ISP-B) will reach A's HA. While only CNs in ISP-B will reach B's HA proxying the MNP-A. Thus HAHA RO capability is only enabled for CN-in-ISP-B, but not for all nodes in the Internet. Right? I am asking this just to make sure my understanding is correct, I don't think such "restricted" RO support is an issue since it is possible that (in specific deployement scenarios) one want to enable RO only for a certain set of CNs (e.g. CN-in-ISP-B) but not for all of them. Thanks, Christophe. From nemo-bounces@ietf.org Tue Nov 23 05:29:35 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 FAA24625 for ; Tue, 23 Nov 2004 05:29: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 1CWXsY-0004N3-Uc; Tue, 23 Nov 2004 05:26:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXn2-0003RO-A7 for nemo@megatron.ietf.org; Tue, 23 Nov 2004 05:20: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 FAA24095 for ; Tue, 23 Nov 2004 05:20:48 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXqU-0000ay-Qk for nemo@ietf.org; Tue, 23 Nov 2004 05:24:37 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 79D912DC20 for ; Tue, 23 Nov 2004 11:20:07 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp02.uc3m.es (Postfix) with ESMTP id 376F02DC65 for ; Tue, 23 Nov 2004 11:20:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <3F54034C-3D39-11D9-84BB-000D93ACD0FE@it> Content-Type: text/plain; charset=US-ASCII; format=flowed To: nemo WG From: marcelo bagnulo braun Date: Tue, 23 Nov 2004 11:20:06 +0100 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Subject: [nemo] Fwd: I-D ACTION:draft-bagnulo-nemo-multi6-00.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 The draft is available in the ID directories now regards, marcelo Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 22 de noviembre de 2004 21:37:50 GMT+01:00 > Para: i-d-announce@ietf.org > Asunto: I-D ACTION:draft-bagnulo-nemo-multi6-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Application of a multi6 protocol to nemo > Author(s) : M. Bagnulo > Filename : draft-bagnulo-nemo-multi6-00.txt > Pages : 11 > Date : 2004-11-22 > > The goal of this note is to analyze the possible application of a > multi6 protocol to provide nemo multihoming support. We will first > state the basic assumptions behind a multi6 protocol design and then > we will analyze each of the multihoming configurations for nemo > described in [1] in order to determine if the multi6 can provide the > support required. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-nemo-multi6-00.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-bagnulo-nemo-multi6-00.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-bagnulo-nemo-multi6-00.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. > Content-Type: text/plain > Content-ID: <2004-11-22160159.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From nemo-bounces@ietf.org Tue Nov 23 09:58:11 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 JAA16980 for ; Tue, 23 Nov 2004 09:58: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 1CWbtn-0003DA-8y; Tue, 23 Nov 2004 09:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbgu-0007dn-PG for nemo@megatron.ietf.org; Tue, 23 Nov 2004 09:30: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 JAA13980 for ; Tue, 23 Nov 2004 09:30:46 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbkZ-0008LZ-6e for nemo@ietf.org; Tue, 23 Nov 2004 09:34:37 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2004 15:38:38 +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 iANETjDC024475; Tue, 23 Nov 2004 15:30:11 +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); Tue, 23 Nov 2004 15:30: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: Impact of HAHA route injection (was Re: [nemo] My simple thoughts on HAHA) Date: Tue, 23 Nov 2004 15:29:57 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC4D748E@xmb-ams-337.emea.cisco.com> Thread-Topic: Impact of HAHA route injection (was Re: [nemo] My simple thoughts on HAHA) Thread-Index: AcTQf40oQmBefipxQt+6Ub6IXTFpiwAHhFrA From: "Pascal Thubert \(pthubert\)" To: "Christophe Janneteau" X-OriginalArrivalTime: 23 Nov 2004 14:30:08.0239 (UTC) FILETIME=[EE8F4FF0:01C4D168] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Ryuji Wakikawa , Alexandru Petrescu 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 > > > > > > First, this does not need to create any new area nb into the DFZ. > > > > But if your question is about a potential fragmentation of the ISP > > aggregation, then it's possible. WRT multi6, I'm not too sure it > > compares. Depends on which home we are talking about. I wrote this draft > > with (4G VoIP capable) ISPs in mind, managing a Home Network as part of > > their services, as opposed to sites which would be given an address > > block to make a Home of it. So that would not be the same order of > > magnitude. They could partition that home into mobile address blocks for > > the corporate customers, but that's another story (eg, mobile home). > > > > An ISP would split its mobile and non mobile worlds, and they would be > > advertised separately. That could up-to double the size of the DFZ > > tables. A non mobile aggregation would be advertised from its location. > > A mobile aggregation would be advertised from all of the owner SP > > locations. BGP routers would keep the closest one anyway, as usual. > > Maybe a checking on multipath operations here and there, but it should > > be OK. >=20 > Is my reading correct that the "doubling" of the size of the DFZ tables > would be due to the fact that mobile aggregation are advertised from > multiple locations with HAHA? >=20 > In that case, I am still wondering whether HAHA, as a global route > optimization solution, is worth such an impact on the DFZ. Right.=20 That would be if all the SPs split their networks to make a half mobile. The key is that the non mobile part is not advertised the same way in BGP then the mobile part. Whether it's worth it is not mine to judge. Depends if SPs want to control/manage the mobility of their phones and use an infrastructure based solution. And if so, and if the cost is not affordable, we'll have to find an alternate to global HAHA. I think it's at least a good exercise. >=20 > I can see HAHA as an interesting feature, as long as we are able to > control its impact on the Internet as a whole. Such control seems easy > if HAHA is deployed in a single site. It seems also doable to use HAHA > between different sites that share the same ISP (so that MNP routes > aggregate at this ISP, and does not go deeper in the Internet). On the > other hand, IMHO, it is not possible to control the impact of HAHA > "multiple route injection" if used between any site....with potentially > significant impact on the Internet routing tables. Note that the multiple injections are for the ISP aggregations, not per MNPs, right? The impact of the mobility is hidden within one ISP "VPN". And that could be on-demand (secondary bindings). >=20 > If the above is correct (please correct me if not :) then it seems > important IMHO to explicitly list such issues in the draft, and > recommend the use of HAHA only in specific / well-controlled > environments. A technical solution preventing any mis-usage of HAHA > could also be needed. >=20 Right. HAHA and global in particular are going deep in hopes and consequences. Being fully L3 is a major step. It's way beyond the current charter of NEMO. If a WG is formed that takes it, I'm sure it will require more then one doc to cover it and usage applicability will be key. > > The way I see it (but I'm not network architect): > > > > BGP should be configured to filter out mobile routes if they are > > injected by proxies on behalf of partner ISPs. So if ISP B proxies for > > ISP A, B's proxy HAs will inject A's mobile aggregation into B's AS - > > and reciprocally A will do the same for B. But those routes will not > > leak into eBGP. >=20 >=20 > If the mobile routes for ISP-A (e.g. MNP-A) does not leak into ISP-B's > eBGP, then only one route for MNP-A will be exposed in the Internet > (i.e. towards ISP-A), which is fine. >=20 > On the other hand, because of that, it seems to me that all packets from > any CN in the Internet (but CNs in ISP-B) will reach A's HA. While only > CNs in ISP-B will reach B's HA proxying the MNP-A. Thus HAHA RO > capability is only enabled for CN-in-ISP-B, but not for all nodes in the > Internet. Right? >=20 The idea would be that the proxies can RO using a route projection. So if CN_X has a proxy that is trusted by ISP A then a proxy for MR_A can establish RO with CN_X. If I understand well your case, the problem you are evoking is more like when MR_A is roaming into domain_X. In which case it will not find a proxy locally. > I am asking this just to make sure my understanding is correct, I don't > think such "restricted" RO support is an issue since it is possible that > (in specific deployement scenarios) one want to enable RO only for a > certain set of CNs (e.g. CN-in-ISP-B) but not for all of them. >=20 >=20 Agreed. Note that in the case of voice, many providers ended up with cross-agreements :) Pascal From nemo-bounces@ietf.org Wed Nov 24 01:10:04 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 BAA18483 for ; Wed, 24 Nov 2004 01:10:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqKd-0001qS-D8; Wed, 24 Nov 2004 01:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqGV-00013s-DK for nemo@megatron.ietf.org; Wed, 24 Nov 2004 01:04:31 -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 BAA18257 for ; Wed, 24 Nov 2004 01:04:30 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWqKE-00010X-Tt for nemo@ietf.org; Wed, 24 Nov 2004 01:08:27 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAO63UnG010989; Wed, 24 Nov 2004 15:03:31 +0900 Date: Wed, 24 Nov 2004 15:03:22 +0900 Message-ID: From: Ryuji Wakikawa To: pthubert@cisco.com Subject: Re: [nemo] Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC497B2F@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC497B2F@xmb-ams-337.emea.cisco.com> 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: nemo@ietf.org, ryuji@sfc.wide.ad.jp, cjbc@it.uc3m.es, Greg.Daley@eng.monash.edu.au 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 Pascal At Fri, 19 Nov 2004 09:48:02 +0100, pascal wrote: > > Hi Ryuji > > > > > > > But We can not say 'any MANET' will do. We must explicit what our > > > priorities are and what features we care for. And we must come back > > > with a single MANET version so there's a chance to get standard > > > track one day. > > > > I did not say "any MANET";-) > > > Never meant you did :) > > > > > The draft is problem statement and tries to expose the possibility of > > MANET to some NEMO issue. > > > > Right: there's the high level perspective (the problem statement level) > where we say " MANET here can do this and that for NEMO" and the > detailed level where we would actually characterize the features in the > instance that would fit the problem best. I'm afraid I'm going too deep > in the latter for the sake of the current charter. It's still an > interesting discussion. If people are interested in pursuing it, maybe > we could set up a separate list? I believe the part of RO discussion (for nested case) contains routing issue. This is why we brought up the MANET problem staement draft. However, MANET protocols might be too big for these issues. There must be several different approaches (like TD) for this routing issue. And the approaches must be fit to NEMO basic support, too. regards, ryuji > > > > well, the discussion of RO solution is not begun yet, too. > > But it might be true that we need more thoughts on this with people > > from NEMO and MANET WG. > > Agreed. > > Pascal From nemo-bounces@ietf.org Wed Nov 24 02:27:57 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 CAA15419 for ; Wed, 24 Nov 2004 02:27:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrXx-0001o6-6f; Wed, 24 Nov 2004 02:26:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrTR-00082W-O1 for nemo@megatron.ietf.org; Wed, 24 Nov 2004 02:21:58 -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 CAA10642 for ; Wed, 24 Nov 2004 02:21:55 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrXF-0002XE-JO for nemo@ietf.org; Wed, 24 Nov 2004 02:25:54 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAO7LNnG012014; Wed, 24 Nov 2004 16:21:23 +0900 Date: Wed, 24 Nov 2004 16:10:37 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] My simple thoughts on HAHA In-Reply-To: <419DCF02.5080105@motorola.com> References: <419B973D.3000709@motorola.com> <419C7085.2070905@motorola.com> <419D157F.7060704@motorola.com> <419DCF02.5080105@motorola.com> 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: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: nemo@ietf.org, ryuji@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 Hello Alex sorry for late reply. At Fri, 19 Nov 2004 11:46:26 +0100, Alexandru Petrescu wrote: > > Ryuji, thank you for replies, it is good to know. > > Ryuji Wakikawa wrote: > > Let me clarify what authors are trying at this point. We try to > > separate the HAHA draft after we got comments that HAHA has too many > > things in single draft. Thus, we first define the base specification > > (protocol part) in the haha-protocol and protocol usage and > > operations into another draft (haha-globa is just one of). We > > couldnot complete other operational drafts for loadbalance/redundancy > > at this point. > > Ryuji it seems to me this is a good approach. It is good to split in > spec and usage documents. HAHA as I understand it is a protocol that > may solve some problems within some systems. The HAHA base spec may > specify a benefit-agnostic universal protocol and the HAHA usage drafts > may exemplify what are its RO benefits, its Load Balance benefits, its > Multi-Homing benefits on a per-item basis and so on, am I right? > > However, I do not see a direct link between HAHA and the NEMO Working > Group. There has never been a NEMO Problem Statement that would require > a solution like HAHA. There is nothing in the Charter (AFAIK) about > requiring HAHA. There is no HAHA Problem Statement. > > Secondly, many of the potential benefits of HAHA are valid to MH too. > Thus I suggest maybe the mip6 WG is better interested first, and if they > need it, then maybe NEMO needs it too. But I do not find it a good > approach to push it here first. There is a problem statement related to MIP6 HAHA. draft-jfaizan-mipv6-ha-reliability-01.txt We tried to discuss HAHA (global HAHA) in NEMO, since this usage is applicable to NEMO. We don't have any intention to work on HAHA only at NEMO WG. If you look at the previous HAHA drafts, we submitted to both MIP6/NEMO WG. We gave presentation at MIP6 WG, too. > Thus, until Authors write the HAHA usage draft that pertains to RO > benefits exclusively, it may not be necessary to cite or refer HAHA in > the NEMO RO Problem Statement. > > > I think what you miss here is that each HA advertise the same > > super-prefix to the Internet. The route for the same prefix is > > advertised from different network. For example, packets from CN1 may > > reach to oHA, but others from CN2 may reach to nHA. > > Ryuji, I think I can understand that. But, the problem that HAHA was > trying to solve was like "it's unwise to attach to Melbourne HA if > you're in London" and the solution was "please attach to London HA > because closer". That problem and solution says nothing about where the > CN is placed. It may very well be that there is HA near where you are > but the CN is near where your old HA is. In this case, HAHA not only > does not bring benefits, but it may actually _induce_ longer paths. > > No? This can be solved by operations and configurations where you configure HAs on the Internet. > >>> It means HA-MR distance becomes shorter. > >> > >> Yes, the path nHA-MR may be shorter than oHA-MR. However, it is > >> not enough for _that_ path to be shorter in order to be beneficial. > >> RO does not look at shortening the HA-MR paths, but at CN-MR paths. > >> SO you want the path CN-nHA-MR to be much shorter than the path > >> CN-oHA-MR. The path oHA-nHA must be small such as to allow for > >> route updates (if route updates, not BC syncs, are used between > >> HAs) are used. If HAHA eliminates that short oHA-nHA path then > >> there is no benefit in using it because it is much smaller than > >> what the CN-HA or HA-MR paths may become. > > > > > > Well, as I wrote in previous mail, the path between CN and MR can be > > different in each direction. From CN->MR, you can use CN-oHA-MR path > > if it is shorter. In other direction, you can use MR-nHA-CN if it's > > shorter, too. > > I see what you mean. It still lacks logic, it's like saying that the > path between two points is shorter in one direction and longer in the > other direction; or that there are two different shortest paths between > two points depending on the direction (if it's shortest in one direction > it should be shortest in the reverse direction too). Both paths can be shorten. > >> This assumes that your nHA is nearer the CN than the oHA, and at > >> the same time that the nHA is nearer the MR than the oHA, and at > >> the same time that a Home Address is reachable at both HAs. Am I > >> right? > > > > > > Yes. > > Look, if you believe this is correct, I believe this can not be > achieved, because an MR does not choose its CNs. It's the user who > chooses a CN. The MR may choose its HA, but the CN is chosen by the > user. And the CN may be _any_ end node in the Internet. That's why HAHA can distribute HAs to the Internet. > >> Or does it only assume that whatever HA is closer to CN can > >> intercept a packet towards HoA and forward it to the current HA? > >> If this is what you meant, then all HAs must be able to intercept a > >> certain HoA and at the same time when this inter-HA forwarding > >> takes place it induces new angles to the multi-angular paths. > > > > > > This is YES, too. This is already specified in the HAHA-global draft. > > You don't need ProxyND to intercept packets for NEMO, since packet > > is intercepted by using routing table. > > Look, I think we are in a very large disagreement here, but we may > discuss this on another thread. Basically, NEMO Basic Support doesn't > say "you don't need proxyND" and it does not forbid it either. My point is NEMO can be configured in this way with aggregated home network. > >>> There is another operation to bypass oHA-nHA tunnel. MR > >>> associates with the closer HA (nHA) and uses it for deliverying > >>> packets to the Internet. On the other hand, MR receives packets > >>> meant for its MNP tunneled by the closer HA of CN. > >>> > >>> path from MR to CN MR - HA =============> CN tunnel > >>> > >>> path from CN to MR MR <==============HA - CN tunnel > >> > >> Great! So we end up with a smaller triangular routing, not the > >> maximum triangular routing CN-HA-MR. This looks to me like an > >> intermediate step on an RO scale. The goal of RO should be to have > >> straight paths MR-CN, not through some other HA, even if closer, > >> no? > > > > > > If HA is on the path from CN to MR, it is not critical except for > > tunnel. (But most of RO solution relies on tunnel). In the current > > Internet, many packets are routed through one of IXP. If HA is > > located at IXPs, the redundant path can be kept minimum. > > Ryuji, I think we have a larger disagreement here. I do not believe > that having HA in the IXP and without using Proxy-ND is in the scope of > NEMO. I really think what you say may be possible, maybe even > recommendable to do in order to achieve shorter paths, but I don't think > we can do this in NEMO. This is not Routing Area. HAHA is not about having HA in IXP without proxy ND. This is just one of HAHA configurations. Whether we discuss new topic or not must be decided by WG. I did presentation at San Diego IETF to ask whether NEMO WG is interested in this topic or not. AFAIK, many people in the meeting is interested. The chairs advised us to keep HAHA discussion in NEMO WG. > > When HA is just on the way to MR from CN, do you see critical > > overhead? > > I see unnecessary overhead because encapsulation. Although nobody know NEMO extend, NEMO Basic always tunnels packets at least:-) regards, ryuji From nemo-bounces@ietf.org Wed Nov 24 03:22:38 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 DAA26757 for ; Wed, 24 Nov 2004 03:22:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWsKi-0001Im-Cc; Wed, 24 Nov 2004 03:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWsC7-0007MI-C2 for nemo@megatron.ietf.org; Wed, 24 Nov 2004 03:08: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 DAA25314 for ; Wed, 24 Nov 2004 03:08: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 1CWsFv-0000KH-Bb for nemo@ietf.org; Wed, 24 Nov 2004 03:12:04 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2004 09:16:12 +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 iAO87MD4029677; Wed, 24 Nov 2004 09:07:30 +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); Wed, 24 Nov 2004 09:07:28 +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: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt Date: Wed, 24 Nov 2004 09:07:25 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC4D76C0@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt Thread-Index: AcTR6196Rba2PWFQSdqTe9knTeS9+QAEItiA From: "Pascal Thubert \(pthubert\)" To: "Ryuji Wakikawa" X-OriginalArrivalTime: 24 Nov 2004 08:07:28.0009 (UTC) FILETIME=[A39BFF90:01C4D1FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, cjbc@it.uc3m.es, Greg.Daley@eng.monash.edu.au 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 > > > > Right: there's the high level perspective (the problem statement level) > > where we say " MANET here can do this and that for NEMO" and the > > detailed level where we would actually characterize the features in the > > instance that would fit the problem best. I'm afraid I'm going too deep > > in the latter for the sake of the current charter. It's still an > > interesting discussion. If people are interested in pursuing it, maybe > > we could set up a separate list? >=20 > I believe the part of RO discussion (for nested case) contains routing > issue. This is why we brought up the MANET problem staement draft. > However, MANET protocols might be too big for these issues. There > must be several different approaches (like TD) for this routing > issue. And the approaches must be fit to NEMO basic support, too. >=20 > > Agreed. I would be interested to follow up this discussion with parties interested in the specific problem of MANET applicability for the nested wireless routers sharing an internet connection. Obviously, nested NEMO is a foremost use case, but the question also applies to other domains such as meshed networking.=20 I believe we should set up a separate list for this discussion, and see if people from various horizons (MANET, NEMO, Mesh) are interested in moving forward. What do you think? Pascal From nemo-bounces@ietf.org Thu Nov 25 09:25: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 JAA15808 for ; Thu, 25 Nov 2004 09:25: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 1CXKWg-0000w2-Aw; Thu, 25 Nov 2004 09:23:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXKPk-0007tA-E7 for nemo@megatron.ietf.org; Thu, 25 Nov 2004 09:16: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 JAA15115 for ; Thu, 25 Nov 2004 09:16:02 -0500 (EST) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXKTp-0004iP-Gf for nemo@ietf.org; Thu, 25 Nov 2004 09:20:17 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 78D06305BB; Thu, 25 Nov 2004 15:15:26 +0100 (CET) Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 0CE21305B7; Thu, 25 Nov 2004 15:15:26 +0100 (CET) Subject: RE: [nemo] Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC4D76C0@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC4D76C0@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GKJqoUpIbxBGw5O0ubO/" Organization: Universidad Carlos III de Madrid Message-Id: <1101392138.2596.45.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 25 Nov 2004 15:15:38 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nemo@ietf.org, Ryuji Wakikawa , Greg.Daley@eng.monash.edu.au 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 --=-GKJqoUpIbxBGw5O0ubO/ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Pascal, and all > Agreed. I would be interested to follow up this discussion with parties > interested in the specific problem of MANET applicability for the nested > wireless routers sharing an internet connection. Obviously, nested NEMO > is a foremost use case, but the question also applies to other domains > such as meshed networking.=20 >=20 > I believe we should set up a separate list for this discussion, and see > if people from various horizons (MANET, NEMO, Mesh) are interested in > moving forward. What do you think? I support your idea. In fact, I'm very interested on those topics. Kind Regards, Carlos J. >=20 > Pascal --=20 Carlos Jes=FAs Bernardos Cano - http://www.netcoms.net GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-GKJqoUpIbxBGw5O0ubO/ 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) iD8DBQBBpekK5vKyPtrWqkARArgIAJwPZ3Pv5qdW5BYIEoZVvUtu4DX27ACdEAoo W75ODga3JdsAoWLJlp5k4RM= =1CXT -----END PGP SIGNATURE----- --=-GKJqoUpIbxBGw5O0ubO/-- From nemo-bounces@ietf.org Sun Nov 28 20:16:26 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 UAA04575 for ; Sun, 28 Nov 2004 20:16: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 1CYa3k-0001um-OH; Sun, 28 Nov 2004 20:10:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYXRL-0005k8-Pt; Sun, 28 Nov 2004 17:22:44 -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 RAA21158; Sun, 28 Nov 2004 17:22:41 -0500 (EST) Received: from rome.ucdavis.edu ([169.237.104.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYXW7-00078x-HV; Sun, 28 Nov 2004 17:27:40 -0500 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by rome.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iASMMW4a022966; Sun, 28 Nov 2004 14:22:33 -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 iASMMWE1009821; Sun, 28 Nov 2004 14:22:32 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id iASMMVNR009820; Sun, 28 Nov 2004 14:22:31 -0800 (PST) Date: Sun, 28 Nov 2004 14:22:31 -0800 (PST) Message-Id: <200411282222.iASMMVNR009820@phaenicia.ucdavis.edu> To: fanzhao@ucdavis.edu 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.41 X-Spam-Score: 2.4 (++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-Mailman-Approved-At: Sun, 28 Nov 2004 20:10:31 -0500 Cc: nemo@ietf.org, mip6@ietf.org, mipshop@ietf.org, mip4@ietf.org, multi6@ops.ietf.org, v6ops@ops.ietf.org, mobopts@irtf.org, manet@ietf.org, hipsec@honor.trusecure.com Subject: [nemo] Call for Papers: IEEE JSAC MRNM 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 PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications and models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com From nemo-bounces@ietf.org Mon Nov 29 11:00:38 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 LAA04119 for ; Mon, 29 Nov 2004 11:00:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnke-0006IA-7n; Mon, 29 Nov 2004 10:47:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYnXK-0003co-6Q for nemo@megatron.ietf.org; Mon, 29 Nov 2004 10:33: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 KAA01829 for ; Mon, 29 Nov 2004 10:33:56 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYncE-0004Gv-Pj for nemo@ietf.org; Mon, 29 Nov 2004 10:39:04 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Nov 2004 07:37:49 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iATFXM9N009401; Mon, 29 Nov 2004 07:33:22 -0800 (PST) Received: from dshell-w2k02.cisco.com (rtp-vpn1-175.cisco.com [10.82.224.175]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA17482; Mon, 29 Nov 2004 07:33:20 -0800 (PST) Message-Id: <4.3.2.7.2.20041129102934.00c60d10@lint.cisco.com> X-Sender: dshell@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Nov 2004 10:33:18 -0500 To: Carlos =?iso-8859-1?Q?Jes=FAs?= Bernardos Cano From: Daniel Shell Subject: RE: [nemo] Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt In-Reply-To: <1101392138.2596.45.camel@acorde> References: <7892795E1A87F04CADFCCF41FADD00FC4D76C0@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC4D76C0@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" , Ryuji Wakikawa , Greg.Daley@eng.monash.edu.au 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 All I would like to see this list generated. It would be very useful to have discussion with the MANET group and Mesh along with NEMO and see if we can integrate these various solutions. As I deploy Mobile networking for my customers base the more tools I have the better the solution. Thanks for your efforts. At 03:15 PM 11/25/2004 +0100, Carlos Jes=FAs Bernardos Cano wrote: >Hi Pascal, and all > > > > Agreed. I would be interested to follow up this discussion with parties > > interested in the specific problem of MANET applicability for the nested > > wireless routers sharing an internet connection. Obviously, nested NEMO > > is a foremost use case, but the question also applies to other domains > > such as meshed networking. > > > > I believe we should set up a separate list for this discussion, and see > > if people from various horizons (MANET, NEMO, Mesh) are interested in > > moving forward. What do you think? > > I support your idea. In fact, I'm very interested on those topics. > > Kind Regards, > > Carlos J. > > > > > Pascal >-- >Carlos Jes=FAs Bernardos Cano - http://www.netcoms.net >GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 Dan Shell Government Service Unit CISCO Systems IP mobility/Wireless/Satellite 440 331 5663 From nemo-bounces@ietf.org Mon Nov 29 14:51:44 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 OAA24310 for ; Mon, 29 Nov 2004 14:51: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 1CYrSG-00085i-8r; Mon, 29 Nov 2004 14:45:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrOU-0007bn-GU for nemo@megatron.ietf.org; Mon, 29 Nov 2004 14:41:06 -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 OAA23421 for ; Mon, 29 Nov 2004 14:41:05 -0500 (EST) Received: from outbound.kcl.ac.uk ([137.73.2.214]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrTO-0001LR-Qb for nemo@ietf.org; Mon, 29 Nov 2004 14:46:14 -0500 Received: from relay3.kcl.ac.uk ([137.73.2.218] helo=elder) by outbound.kcl.ac.uk outbound with esmtp (TLSv1:DHE-RSA-AES256-SHA:256) id 1CYrNb-00070f-Eg for nemo@ietf.org; Mon, 29 Nov 2004 19:40:11 +0000 Received: from hazel.kcl.ac.uk ([137.73.2.28] helo=localhost) by elder smtphack with esmtp id 1CYrNL-00064u-Pq for nemo@ietf.org; Mon, 29 Nov 2004 19:39:56 +0000 Received: from 137.73.10.17 ([137.73.10.17]) by impmail.kcl.ac.uk (IMP) with HTTP for ; Mon, 29 Nov 2004 19:39:55 +0000 Message-ID: <1101757195.41ab7b0b9c7ed@impmail.kcl.ac.uk> Date: Mon, 29 Nov 2004 19:39:55 +0000 From: uma.shanker@kcl.ac.uk To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-KCLOriginating-IP: 137.73.10.17 X-KCLSpamScore: 2 X-KCLRealSpamScore: 0.2 X-KCLZStatus: 2 X-KCLSpamReport: NO_REAL_NAME=0.16 X-KCL-MailScanner: Found to be clean X-MailScanner-From: kksg0549@kcl.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 8bit Subject: [nemo] NEMO Scenario in bigger Leaf Network 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: 8bit Hello, I am just a reader of Nemo discussion. At this point I am interested in the NEMO based bigger Leaf network scenario. e.g. Network having a mutliple MR's. Are there any real scenario exists. I have seen only one paper which really talk about this point [T.Oiwa, A network mobility protocol based on LIN6]. I assume maximum of 2-3 hierarchical MR's in any scenario. Alos, if the this hierarchy increases, then we have yet another categories of problems in routing, handover etc. -- regards, Uma Shanker uma.shanker@kcl.ac.uk Centre for Telecommunications Research King's College London, University of London 26-29 Drury Lane, London WC2B 5RL --- RFC-793,TCP.Section:2.10. Robustness Principle: TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.