From yuiyuiyuichan@ocn.ne.jp Mon Sep 11 03:22:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMg7L-0001Du-Bz for NEMO-ARCHIVE@LISTS.IETF.ORG; Mon, 11 Sep 2006 03:22:07 -0400 Received: from [222.172.19.137] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMg7I-00069I-AT for NEMO-ARCHIVE@LISTS.IETF.ORG; Mon, 11 Sep 2006 03:22:07 -0400 Received: from yqgqjxwksp9 (unknown [35.6.111.141]) by smtp39 (Coremail) with SMTP id W4OtL1loBp1sRhss.1 for ; Mon, 11 Sep 2006 15:22:12 +0800 (CST) X-Originating-IP: [35.6.111.141] Subject: =?iso-2022-jp?B?GyRCJDMkbCRHJEkkJiRHJDckZyQmGyhC?= From: =?shift-jis?B?guSCog==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 $B5.J}$O$*6b$b=w$b(BSEX$B$bBg9%$-$G$O$"$j$^$;$s$+!)$=$l$,0l5$$K$OB(0)$$!"5U1o$r4uK>$7$F$k;v$,%"%s%1!<%HD4::$GJ,$+$j$^$7$?!#(B $B6C$/Dx!"4JC1$K%"%]$,; Thu, 14 Sep 2006 00:14:32 -0700 (PDT) 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 k8E7EWi9002246 for ; Thu, 14 Sep 2006 00:14:32 -0700 (PDT) Received: (from www@localhost) by diometes.ucdavis.edu (8.12.10/8.12.9/Submit) id k8E7EW8n002245; Thu, 14 Sep 2006 00:14:32 -0700 (PDT) Date: Thu, 14 Sep 2006 00:14:32 -0700 (PDT) Message-Id: <200609140714.k8E7EW8n002245@diometes.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@pop24.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [67.169.108.120] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [nemo] Table of Content of 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: , Errors-To: nemo-bounces@ietf.org (Apologies if you receive multiple copies of this message) FYI, below are the contents of IEEE Journal on Selected Areas in Communications (J-SAC) SEPTEMBER 2006 VOLUME 24 NUMBER 9 ISACEM (ISSN 0733-8716) MOBILE ROUTERS AND NETWORK MOBILITY B. Sarikaya, S. F. Wu, G. Dommety, C. Castelluccia, T. Ernst, and C. E. Perkins PAPERS Measuring and Improving the Performance of Network Mobility Management in IPv6 Networks .....H. Petander, E. Perera, K.-C. Lan, and A. Seneviratne A Novel SIP-Based Route Optimization for Network Mobility .....C.-M. Huang, C.-H. Lee, and J.-R. Zheng Performance Enhancement of On-Board Communication Networks Using Outage Prediction .....A. Baig, L. Libman, and M. Hassan Design and Experimental Evaluation of a Route Optimization Solution for NEMO .....M. Calderón, C. J. Bernardos, M. Bagnulo, I. Soto, and A. de la Oliva Route Optimization Using Tree Information Option for Nested Mobile Networks .....H. Cho, T. Kwon, and Y. Choi LR-AKE-Based AAA for Network Mobility (NEMO) Over Wireless Links .....H. Fathi, S. Shin, K. Kobara, S. S. Chakraborty, H. Imai, and R. Prasad Multiple Key Sharing and Distribution Scheme With Threshold for NEMO Group Communications .....Y. Jiang, C. Lin, M. Shi, and X. Shen The Global In-Flight Internet .....E. Sakhaee and A. Jamalipour Reactive Handover Optimization in IPv6-Based Mobile Networks .....Y.-H. Han, J. Choi, and S.-H. Hwang The link to this issue, http://www.jsac.ucsd.edu/TOC/2006/Sep06.html, will be updated soon. From nemo-bounces@ietf.org Thu Sep 14 06:54:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNoqq-0003Va-5V; Thu, 14 Sep 2006 06:53:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNoqp-0003VN-9L for nemo@ietf.org; Thu, 14 Sep 2006 06:53:47 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNoqm-0000Nz-SN for nemo@ietf.org; Thu, 14 Sep 2006 06:53:47 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8EArZGd026311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Sep 2006 12:53:36 +0200 Date: Thu, 14 Sep 2006 12:53:35 +0200 From: Thierry Ernst To: ml-nemo Message-Id: <20060914125335.29b1559e.thierry.ernst@inria.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-j-chkmail-Score: MSGID : 450934AF.002 on concorde : j-chkmail score : X : 0/20 1 X-Miltered: at concorde with ID 450934AF.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [nemo] WG Doc Status Follow Up 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: , Errors-To: nemo-bounces@ietf.org Dear all, In Montreal, we said WGLC would be issued shortly after the meeting for some drafts and that other drafts would be sent to the IESG. Reminder about Montreal meeting: http://www3.ietf.org/proceedings/06jul/index.html http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf This has not been done yet, so I will do it now. Please follow up on the WGLC that will be issued for the multihoming and the NEMOv4 drafts. - Thierry. From nemo-bounces@ietf.org Thu Sep 14 07:42:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpbi-00038P-UI; Thu, 14 Sep 2006 07:42:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpbg-00037Z-EG for nemo@ietf.org; Thu, 14 Sep 2006 07:42:12 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNpb3-0001eH-IF for nemo@ietf.org; Thu, 14 Sep 2006 07:41:34 -0400 Received: from dhcp-rocq-97.inria.fr (guest-rocq-135145.inria.fr [128.93.135.145]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8EBfWIQ023583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Sep 2006 13:41:32 +0200 Date: Thu, 14 Sep 2006 13:41:31 +0200 From: Thierry Ernst To: ml-nemo Message-Id: <20060914134131.5d9c8052.thierry.ernst@inria.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45093FEC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [nemo] WGLC NEMOv4 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: , Errors-To: nemo-bounces@ietf.org Dear all, Authors of IPv4 Network Mobility (NEMO) Basic Support Protocol http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-01.txt have expressed confidence that the document is ready for a NEMO Working Group Last Call. So, please send your comment on the draft between now and the expiration of this WGLC Sept 30. For each new issue you may raise, please pick up a meaningful subject line bearing the prefix "WGLC NEMOv4: YOUR_TEXT". Abstract: This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. Thierry. From nemo-bounces@ietf.org Thu Sep 14 07:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpct-0003We-ND; Thu, 14 Sep 2006 07:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpc1-0003Dl-Vq for nemo@ietf.org; Thu, 14 Sep 2006 07:42:33 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNpPt-0000gq-2p for nemo@ietf.org; Thu, 14 Sep 2006 07:30:05 -0400 Received: from dhcp-rocq-97.inria.fr (guest-rocq-135145.inria.fr [128.93.135.145]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8EBTn5R021987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Sep 2006 13:29:50 +0200 Date: Thu, 14 Sep 2006 13:29:49 +0200 From: Thierry Ernst To: ml-nemo Message-Id: <20060914132949.2c63fb33.thierry.ernst@inria.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45093D2D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [nemo] WGLC Multihoming Issues 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: , Errors-To: nemo-bounces@ietf.org Dear all, Authors of Analysis of Multihoming in Network Mobility Support http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-06.txt have expressed confidence that the document is ready for a NEMO Working Group Last Call. So, please send your comment on the draft between now and the expiration of this WGLC Sept 30. For each new issue you may raise, please pick up a meaningful subject line bearing the prefix "WGLC Multihoming Issues: YOUR_TEXT". Abstract: This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. For history purposes, the covered issues are listed and resolved on http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ so you may look at that page first before commenting. Thierry. From nemo-bounces@ietf.org Thu Sep 14 08:42:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNqXo-0006BG-K8; Thu, 14 Sep 2006 08:42:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNqXm-0006BB-J2 for nemo@ietf.org; Thu, 14 Sep 2006 08:42:14 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNqXl-0002jI-90 for nemo@ietf.org; Thu, 14 Sep 2006 08:42:14 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k8ECgCFT025318; Thu, 14 Sep 2006 05:42:12 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k8ECgB2J007113; Thu, 14 Sep 2006 07:42:11 -0500 (CDT) Message-ID: <45094E21.80407@motorola.com> Date: Thu, 14 Sep 2006 14:42:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst References: <20060914134131.5d9c8052.thierry.ernst@inria.fr> In-Reply-To: <20060914134131.5d9c8052.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ml-nemo Subject: [nemo] WGLC NEMOv4: interoperability needs 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: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Dear all, > > Authors of IPv4 Network Mobility (NEMO) Basic Support Protocol > http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-01.txt > have expressed confidence that the document is ready for a NEMO > Working Group Last Call. > > So, please send your comment on the draft between now and the > expiration of this WGLC Sept 30. For each new issue you may raise, > please pick up a meaningful subject line bearing the prefix "WGLC > NEMOv4: YOUR_TEXT". Thanks Thierry for issuing this WGLC. Let me add interoperability remarks on NEMOv4. The protocol is ready for implementation and for interoperability tests. We have an internal complete draft-01 NEMOv4 implementation derived from Dynamics, running on linux MR and HA. We used WireShark protocol analyzer for development (similar to Ethereal, see wireshark.org). The NEMOv4 WireShark packet-mip.c is available upon request, which displays NEMOv4 packets correctly. For this implementation (and analyzer) we used the numbers in draft-00 document, and we really need the numbers assigned by IANA in order to perform interoperability with other implementations. Alex > > Abstract: This document describes the support of Mobile Networks, as > defined in Mobile IPv4, by the Mobile Router and Home Agent. A > Mobile Router is responsible for the mobility of one or more network > segments or subnets moving together. The Mobile Router hides its > mobility from the nodes on the mobile network. The nodes on the > Mobile Network may be fixed in relationship to the Mobile Router and > may not have any mobility function. > > Extensions to Mobile IPv4 are introduced to support Mobile Networks. > > > Thierry. > > From nemo-bounces@ietf.org Thu Sep 14 13:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNvEK-0000wF-IV; Thu, 14 Sep 2006 13:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNvEI-0000wA-IK for nemo@ietf.org; Thu, 14 Sep 2006 13:42:26 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNvEH-0004zc-8e for nemo@ietf.org; Thu, 14 Sep 2006 13:42:26 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 10:41:29 -0700 Message-ID: <450993B6.8020801@azairenet.com> Date: Thu, 14 Sep 2006 10:39:02 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] WG Doc Status Follow Up References: <20060914125335.29b1559e.thierry.ernst@inria.fr> In-Reply-To: <20060914125335.29b1559e.thierry.ernst@inria.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Sep 2006 17:41:29.0316 (UTC) FILETIME=[0273A240:01C6D825] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ml-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: , Errors-To: nemo-bounces@ietf.org Hi Thierry, what about the terminology, requirements and DHCP based prefix delegation drafts? all three seem to have expired. the charter milestones say these documents should have been sent to the IESG more than a year ago. all these documents are important for NEMO basic support. Vijay Thierry Ernst wrote: > Dear all, > > In Montreal, we said WGLC would be issued shortly after the meeting for > some drafts and that other drafts would be sent to the IESG. > > Reminder about Montreal meeting: > http://www3.ietf.org/proceedings/06jul/index.html > http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf > > This has not been done yet, so I will do it now. Please follow up on the > WGLC that will be issued for the multihoming and the NEMOv4 drafts. - > > > Thierry. > > > From nemo-bounces@ietf.org Fri Sep 15 04:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO8iu-00058b-2l; Fri, 15 Sep 2006 04:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO8it-00058G-9u for nemo@ietf.org; Fri, 15 Sep 2006 04:06:55 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO8io-0003ws-RD for nemo@ietf.org; Fri, 15 Sep 2006 04:06:55 -0400 Received: from dhcp-rocq-97.inria.fr (guest-rocq-135145.inria.fr [128.93.135.145]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8F86VXl002770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Sep 2006 10:06:31 +0200 Date: Fri, 15 Sep 2006 10:06:31 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] WG Doc Status Follow Up Message-Id: <20060915100631.0c829f4d.thierry.ernst@inria.fr> In-Reply-To: <450993B6.8020801@azairenet.com> References: <20060914125335.29b1559e.thierry.ernst@inria.fr> <450993B6.8020801@azairenet.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 450A5F07.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Errors-To: nemo-bounces@ietf.org Hi Vijay, Terminology and Requirements docs are still in my hand, so I need to re-issue the docs and send them ASAP to IESG. Regarding the DHCP draft, we need an update from the authors - and if it corresponds to our need a WGLC can be issued. Thierrry. On Thu, 14 Sep 2006 10:39:02 -0700 Vijay Devarapalli wrote: > Hi Thierry, > > what about the terminology, requirements and DHCP based > prefix delegation drafts? all three seem to have expired. > the charter milestones say these documents should have > been sent to the IESG more than a year ago. > > all these documents are important for NEMO basic support. > > Vijay > > Thierry Ernst wrote: > > Dear all, > > > > In Montreal, we said WGLC would be issued shortly after the meeting for > > some drafts and that other drafts would be sent to the IESG. > > > > Reminder about Montreal meeting: > > http://www3.ietf.org/proceedings/06jul/index.html > > http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf > > > > This has not been done yet, so I will do it now. Please follow up on the > > WGLC that will be issued for the multihoming and the NEMOv4 drafts. - > > > > > > Thierry. > > > > > > > > -- Thierry ERNST, PhD http://www.nautilus6.org/~thierry IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair -- INRIA Rocquencourt Project-Team IMARA, France. +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Fri Sep 15 10:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOEz8-0006ky-LE; Fri, 15 Sep 2006 10:48:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOEz7-0006kj-4t for nemo@ietf.org; Fri, 15 Sep 2006 10:48:05 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOEz2-0006GF-QC for nemo@ietf.org; Fri, 15 Sep 2006 10:48:05 -0400 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] WG Doc Status Follow Up Date: Fri, 15 Sep 2006 07:47:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] WG Doc Status Follow Up Thread-Index: AcbYnhsdgFXqyxEgS3qlD9NkbTWZqgANu4uA From: "Vijay Devarapalli" To: "Thierry Ernst" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: rdroms@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: , Errors-To: nemo-bounces@ietf.org > Terminology and Requirements docs are still in my hand, so I need to > re-issue the docs and send them ASAP to IESG.=20 have they been last called? I don't remember. > Regarding the=20 > DHCP draft, > we need an update from the authors - and if it corresponds to=20 > our need a > WGLC can be issued.=20 there was WG consensus to progress this document a long=20 time ago. Ralph, can you please re-submit draft-ietf-nemo-dhcpv6-pd? it has expired. Vijay >=20 > Thierrry. >=20 >=20 > On Thu, 14 Sep 2006 10:39:02 -0700 > Vijay Devarapalli wrote: >=20 > > Hi Thierry, > >=20 > > what about the terminology, requirements and DHCP based > > prefix delegation drafts? all three seem to have expired. > > the charter milestones say these documents should have > > been sent to the IESG more than a year ago. > >=20 > > all these documents are important for NEMO basic support. > >=20 > > Vijay > >=20 > > Thierry Ernst wrote: > > > Dear all, > > >=20 > > > In Montreal, we said WGLC would be issued shortly after=20 > the meeting for > > > some drafts and that other drafts would be sent to the IESG.=20 > > >=20 > > > Reminder about Montreal meeting: > > > http://www3.ietf.org/proceedings/06jul/index.html > > > http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf > > >=20 > > > This has not been done yet, so I will do it now. Please=20 > follow up on the > > > WGLC that will be issued for the multihoming and the=20 > NEMOv4 drafts. -=20 > > >=20 > > >=20 > > > Thierry. > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 > --=20 > Thierry ERNST, PhD > http://www.nautilus6.org/~thierry > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > -- > INRIA Rocquencourt Project-Team IMARA, France. > +33 1 39 63 59 30 (office) >=20 >=20 >=20 From nemo-bounces@ietf.org Fri Sep 15 11:35:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFiz-0002IW-N8; Fri, 15 Sep 2006 11:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFiy-0002I5-U0 for nemo@ietf.org; Fri, 15 Sep 2006 11:35:28 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFiw-0002LN-GH for nemo@ietf.org; Fri, 15 Sep 2006 11:35:28 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8FFZDvc014862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Sep 2006 17:35:13 +0200 Date: Fri, 15 Sep 2006 17:35:14 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] WG Doc Status Follow Up Message-Id: <20060915173514.747013ee.thierry.ernst@inria.fr> In-Reply-To: References: Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 450AC831.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: rdroms@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: , Errors-To: nemo-bounces@ietf.org Hi, > > Terminology and Requirements docs are still in my hand, so I need to > > re-issue the docs and send them ASAP to IESG. > > have they been last called? I don't remember. Yes. Looonnnng time ago, indeed. I can re-issue a LC if someone is concerned, though. > > > Regarding the > > DHCP draft, > > we need an update from the authors - and if it corresponds to > > our need a > > WGLC can be issued. > > there was WG consensus to progress this document a long > time ago. > > Ralph, can you please re-submit draft-ietf-nemo-dhcpv6-pd? > it has expired. There was a consensus about the doc and some update to come, but the update was not actually done. Thanks, Thierry > Vijay > > > > > Thierrry. > > > > > > On Thu, 14 Sep 2006 10:39:02 -0700 > > Vijay Devarapalli wrote: > > > > > Hi Thierry, > > > > > > what about the terminology, requirements and DHCP based > > > prefix delegation drafts? all three seem to have expired. > > > the charter milestones say these documents should have > > > been sent to the IESG more than a year ago. > > > > > > all these documents are important for NEMO basic support. > > > > > > Vijay > > > > > > Thierry Ernst wrote: > > > > Dear all, > > > > > > > > In Montreal, we said WGLC would be issued shortly after > > the meeting for > > > > some drafts and that other drafts would be sent to the IESG. > > > > > > > > Reminder about Montreal meeting: > > > > http://www3.ietf.org/proceedings/06jul/index.html > > > > http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf > > > > > > > > This has not been done yet, so I will do it now. Please > > follow up on the > > > > WGLC that will be issued for the multihoming and the > > NEMOv4 drafts. - > > > > > > > > > > > > Thierry. > > > > > > > > > > > > > > > > > > > > > > > > -- > > Thierry ERNST, PhD > > http://www.nautilus6.org/~thierry > > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > > -- > > INRIA Rocquencourt Project-Team IMARA, France. > > +33 1 39 63 59 30 (office) > > > > > > > > -- Thierry ERNST, PhD http://www.nautilus6.org/~thierry IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair -- INRIA Rocquencourt Project-Team IMARA, France. +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Mon Sep 18 10:50:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKRh-00029i-B0; Mon, 18 Sep 2006 10:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKRe-00029O-LK; Mon, 18 Sep 2006 10:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPKRe-0007Hm-E6; Mon, 18 Sep 2006 10:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 642ED26E4E; Mon, 18 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GPKRe-00049x-9i; Mon, 18 Sep 2006 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Sep 2006 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-space-analysis-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Route Optimization Solution Space Analysis Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-ro-space-analysis-03.txt Pages : 43 Date : 2006-9-18 With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-ro-space-analysis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-18095311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-ro-space-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-18095311.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Mon Sep 18 10:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKSF-0002H9-LW; Mon, 18 Sep 2006 10:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKSA-0002EN-M2; Mon, 18 Sep 2006 10:50:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPKSA-0007WP-Jq; Mon, 18 Sep 2006 10:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GPKS8-0007iV-IO; Mon, 18 Sep 2006 10:50:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 799E92AC42; Mon, 18 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GPKRe-00049r-8T; Mon, 18 Sep 2006 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Sep 2006 10:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-problem-statement-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Route Optimization Problem Statement Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-ro-problem-statement-03.txt Pages : 29 Date : 2006-9-18 With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems, and provides for the motivation behind Route Optimization (RO) for NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-ro-problem-statement-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-18094856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-ro-problem-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-18094856.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Tue Sep 19 22:31:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPrqf-0000Bq-De; Tue, 19 Sep 2006 22:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPrnX-000734-Dw for nemo@ietf.org; Tue, 19 Sep 2006 22:26:51 -0400 Received: from h-74-0-36-190.snfccasy.covad.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPrjs-00066B-FF for nemo@ietf.org; Tue, 19 Sep 2006 22:23:09 -0400 Received: by deimos.multihop.net (Postfix, from userid 1013) id 64B008ABBC0; Tue, 19 Sep 2006 19:22:17 -0700 (PDT) X-Spam-Score: -2.2 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 Received: from [IPv6:::1] (localhost [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 345918ABAC2 for ; Tue, 19 Sep 2006 19:22:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ml-nemo WG From: "T.J. Kniveton" Date: Tue, 19 Sep 2006 19:18:10 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [nemo] Charter update, continued 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: , Errors-To: nemo-bounces@ietf.org Hi folks, I'm back.. Here is the current version of the charter. I am still making changes, and need to modify the milestones section. But wanted to share what's there now and see if there are any comments. Please send comments directly to me, for the moment, and when I have the next version we can discuss it on the list. http://www.mobilenetworks.org/nemo/charter2_3.txt TJ From nemo-bounces@ietf.org Wed Sep 20 12:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4sn-0007uH-Bv; Wed, 20 Sep 2006 12:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4sl-0007p1-QZ; Wed, 20 Sep 2006 12:25:07 -0400 Received: from bureau-de-poste.utcc.utoronto.ca ([128.100.132.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ4oZ-00035s-Lw; Wed, 20 Sep 2006 12:20:49 -0400 Received: from qew.cs.toronto.edu ([128.100.2.15] EHLO [127.0.0.1] ident: delara [port 57245]) by bureau-de-poste.utcc.utoronto.ca with ESMTP id <429699-18946>; Wed, 20 Sep 2006 12:18:05 -0400 Message-ID: <451169A0.2010109@cs.toronto.edu> Date: Wed, 20 Sep 2006 12:17:36 -0400 From: Eyal de Lara User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet@ietf.org, nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [nemo] HotMobile 2007 Call for Papers 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: , Errors-To: nemo-bounces@ietf.org ********************************************************************* *My sincere apologies if you receive multiple copies of this posting* ********************************************************************* CALL FOR PAPERS HotMobile 2007: The 8th IEEE Workshop on Mobile Computing Systems and Applications http://www.cs.toronto.edu/hotmobile2007/ Westin La Paloma, Tucson, Arizona February 26-27, 2007 Submission Deadline: Oct 2, 2006 ---------------------------------------------------------------------- Dear Colleagues, I encourage you to submit your hot mobile computing research ideas and early results to HotMobile 2007. The deadline is Oct 2, 2006. Please find the detailed call-for-paper at the following web site. http://www.cs.toronto.edu/hotmobile2007/ HotMobile is the former WMCSA workshop which has a highly interactive format that is ideal for submission and discussion of early mobile work. The topics range from mobile applications to system support and to user studies. Also, Tucson is a beautiful place to visit and an ideal setting for the conference. We have assembled an excellent set of program committee members as follows: Eyal de Lara, University of Toronto, Canada (TPC Chair) Rajesh Krishna Balan, Singapore Management University, Singapore Michael Beigl, TU Braunschweig, Germany Gaetano Borriello, University of Washington, US Jason Flinn, University of Michigan, US Jeffrey Hightower, Intel Research Seattle, US Jason Hong, Carnegie-Mellon University, US David B. Johnson, Rice University, US Anthony D. Joseph, UC Berkeley, US Natalia Marmasse, Google Inc., Israel Konstantina Papagiannaki, Intel Research Cambridge, UK M. Satyanarayanan, CMU, US Bill Schilit, Intel Corporation, US Doug Terry, Microsoft Research, US Leendert van Doorn, IBM T.J. Watson Research Center, US We look forward to your submissions! Best regards, Eyal de Lara Assistant Professor Department of Computer Science University of Toronto 40 St. George Street, Office 4270 Toronto, Ontario M5S 2E4 Tel: 416 9468656 Fax: 416 9784765 email: delara@cs.toronto.edu Web: www.cs.toronto.edu/~delara From nemo-bounces@ietf.org Thu Sep 21 04:46:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKBo-00010O-6T; Thu, 21 Sep 2006 04:45:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQKBm-000102-Ti for nemo@ietf.org; Thu, 21 Sep 2006 04:45:46 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQKBh-0000xb-2x for nemo@ietf.org; Thu, 21 Sep 2006 04:45:46 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 10:45:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] WGLC Multihoming Issues Date: Thu, 21 Sep 2006 10:45:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] WGLC Multihoming Issues Thread-Index: AcbX8xGNZW9NPhSXRM6Zed4SOhHnMAFZzY+g From: "KLAMM Frederic RD-CORE-CAE" To: "ml-nemo" X-OriginalArrivalTime: 21 Sep 2006 08:45:39.0556 (UTC) FILETIME=[5097D240:01C6DD5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Errors-To: nemo-bounces@ietf.org Hi all, I would simply cut =A73 (that wouldn't affect other parts the draft): Because : 1. =A73 is based on assertions of = draft-ietf-monami6-multihoming-motivation-scenario-00, which one is a = less advanced document (as far as IETF process is concerned) and may = still change (this is work in progress)! 2. It's probably really difficult to find deployment scenarios. But IMHO = the assertions listed bellow (considering their definitions) can't be = aligned as if they were at the same level. 1. Permanent and Ubiquitous Access 2. Reliability 3. Load Sharing 4. Load Balancing/Flow Distribution 5. Preference Settings 6. Aggregate Bandwidth 3 and 4 are well-identifiable mechanisms 2 and 6 are immediate results of using some mechanisms :they are either = responses or side-effects (6 is at least a side effect of 3) 1 is even more abstract, it's rather a global target :=20 permanency is neared when you obtain 2, 6 and ..., thanks to 3, 4 = ...and others? ubiquity has been defined relative to mutiple interface technologies, = but this is only one step towards the common sense of ubiquity : = wherever you are, you get the net. A quality cellular network on a large given territory offers permanency = and ubiquity. And I don't see why a quality mobile IPv6 service wouldn't = have the same features in the future, provided that IPv6 is deployed. This would mean that 1 is nothing but the ultime target of a mobility = service...(?) I also see (roughly) {1,2,3,4,6} linked to the base IP mobility service. = And {5} linked to the would-be set of value-added services enriching the = base mobility service.=20 Of course I may have completly misunderstood. In this case, I may not be = the only one? And I'll be glad to have an explanation of why this = alignement of assertions is coherent. Regards Frederic > -----Message d'origine----- > De : Thierry Ernst [mailto:thierry.ernst@inria.fr]=20 > Envoy=E9 : jeudi 14 septembre 2006 13:30 > =C0 : ml-nemo > Objet : [nemo] WGLC Multihoming Issues >=20 >=20 > Dear all, >=20 > Authors of > Analysis of Multihoming in Network Mobility Support=20 > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihomin > g-issues-06.txt > have expressed confidence that the document is ready for a=20 > NEMO Working Group Last Call. >=20 > So, please send your comment on the draft between now and the=20 > expiration of this WGLC Sept 30. For each new issue you may=20 > raise, please pick up a meaningful subject line bearing the=20 > prefix "WGLC Multihoming Issues: > YOUR_TEXT". >=20 > Abstract: > This document is an analysis of multihoming in the context=20 > of network > mobility (NEMO) in IPv6. As there are many situations in which > mobile networks may be multihomed, a taxonomy is proposed=20 > to classify > the possible configurations. The possible deployment scenarios of > multihomed mobile networks are described together with the=20 > associated > issues when network mobility is supported by RFC 3963 (NEMO Basic > Support). Recommendations are offered on how to address these > issues. >=20 >=20 > For history purposes, the covered issues are listed and=20 > resolved on=20 > http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ > so you may look at that page first before commenting. >=20 >=20 > Thierry. >=20 >=20 From nemo-bounces@ietf.org Thu Sep 21 09:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOyV-0008KG-Bu; Thu, 21 Sep 2006 09:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOyT-0008Hh-PN for nemo@ietf.org; Thu, 21 Sep 2006 09:52:21 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQOyB-0001Zc-3a for nemo@ietf.org; Thu, 21 Sep 2006 09:52:21 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 15:52:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Sep 2006 15:51:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC Multihoming Issues: removing "Deployment Scenarios and Prerequisites" ? Thread-Index: AcbX8xGNZW9NPhSXRM6Zed4SOhHnMAFZzY+gAAbuxEA= From: "KLAMM Frederic RD-CORE-CAE" To: "ml-nemo" X-OriginalArrivalTime: 21 Sep 2006 13:52:00.0748 (UTC) FILETIME=[1CA322C0:01C6DD85] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [nemo] WGLC Multihoming Issues: removing "Deployment Scenarios and Prerequisites" ? 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: , Errors-To: nemo-bounces@ietf.org [Sorry for resending: same message as previous, prefixed by "WGLC..." as = required in the LC message] WGLC Multihoming Issues: removing "Deployment Scenarios and = Prerequisites" Hi all, I would simply cut =A73 (that wouldn't affect other parts the draft): Because : 1. =A73 is based on assertions of = draft-ietf-monami6-multihoming-motivation-scenario-00, which one is a = less advanced document (as far as IETF process is concerned) and may = still change (this is work in progress)! 2. It's probably really difficult to find deployment scenarios. But IMHO = the assertions listed bellow (considering their definitions) can't be = aligned as if they were at the same level. 1. Permanent and Ubiquitous Access 2. Reliability 3. Load Sharing 4. Load Balancing/Flow Distribution 5. Preference Settings 6. Aggregate Bandwidth 3 and 4 are well-identifiable mechanisms 2 and 6 are immediate results of using some mechanisms :they are either = responses or side-effects (6 is at least a side effect of 3) 1 is even more abstract, it's rather a global target :=20 permanency is neared when you obtain 2, 6 and ..., thanks to 3, 4 = ...and others? ubiquity has been defined relative to mutiple interface technologies, = but this is only one step towards the common sense of ubiquity : = wherever you are, you get the net. A quality cellular network on a large given territory offers permanency = and ubiquity. And I don't see why a quality mobile IPv6 service wouldn't = have the same features in the future, provided that IPv6 is deployed. This would mean that 1 is nothing but the ultime target of a mobility = service...(?) I also see (roughly) {1,2,3,4,6} linked to the base IP mobility service. = And {5} linked to the would-be set of value-added services enriching the = base mobility service.=20 Of course I may have completly misunderstood. In this case, I may not be = the only one? And I'll be glad to have an explanation of why this = alignement of assertions is coherent. Regards Frederic =20 > > -----Message d'origine----- > > De : Thierry Ernst [mailto:thierry.ernst@inria.fr] Envoy=E9 :=20 > jeudi 14=20 > > septembre 2006 13:30 =C0 : ml-nemo Objet : [nemo] WGLC Multihoming=20 > > Issues > >=20 > >=20 > > Dear all, > >=20 > > Authors of > > Analysis of Multihoming in Network Mobility Support=20 > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihomin > > g-issues-06.txt > > have expressed confidence that the document is ready for a NEMO=20 > > Working Group Last Call. > >=20 > > So, please send your comment on the draft between now and the=20 > > expiration of this WGLC Sept 30. For each new issue you may raise,=20 > > please pick up a meaningful subject line bearing the prefix "WGLC=20 > > Multihoming Issues: > > YOUR_TEXT". > >=20 > > Abstract: > > This document is an analysis of multihoming in the context of=20 > > network > > mobility (NEMO) in IPv6. As there are many situations in which > > mobile networks may be multihomed, a taxonomy is proposed to=20 > > classify > > the possible configurations. The possible deployment=20 > scenarios of > > multihomed mobile networks are described together with the=20 > > associated > > issues when network mobility is supported by RFC 3963 (NEMO Basic > > Support). Recommendations are offered on how to address these > > issues. > >=20 > >=20 > > For history purposes, the covered issues are listed and resolved on=20 > >=20 > http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ > > so you may look at that page first before commenting. > >=20 > >=20 > > Thierry. > >=20 > >=20 >=20 >=20 From nemo-bounces@ietf.org Fri Sep 22 05:03:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQgvT-0003m2-UN; Fri, 22 Sep 2006 05:02:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQgvT-0003lx-9e for nemo@ietf.org; Fri, 22 Sep 2006 05:02:27 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQgvO-0000it-Jr for nemo@ietf.org; Fri, 22 Sep 2006 05:02:27 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k8M92Cvf017863; Fri, 22 Sep 2006 02:02:16 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k8M92AeD014680; Fri, 22 Sep 2006 04:02:11 -0500 (CDT) Message-ID: <4513A691.7040407@motorola.com> Date: Fri, 22 Sep 2006 11:02:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: v4 (was: [nemo] Charter update, continued) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ml-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: , Errors-To: nemo-bounces@ietf.org T.J. Kniveton wrote: > Hi folks, I'm back.. > > Here is the current version of the charter. I am still making > changes, and need to modify the milestones section. But wanted to > share what's there now and see if there are any comments. > > Please send comments directly to me, for the moment, and when I have > the next version we can discuss it on the list. > > http://www.mobilenetworks.org/nemo/charter2_3.txt TJ, thanks for posting the new Charter proposal. There is one specific item I would like to ask in this message: "- Work with the Mobile IPv4 working group to hand over work on IPv4-only NEMO solutions." Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call through this WG, supposedly ending September 30th. How do you (and WG members) see transition to the MIP4 WG? I see it as being finalised here and submitted to IESG, and only then eventually taken on by the MIP4 WG. Thanks, Alex From nemo-bounces@ietf.org Fri Sep 22 05:34:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQhQp-0000XM-Uq; Fri, 22 Sep 2006 05:34:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQhQn-0000PS-SQ for nemo@ietf.org; Fri, 22 Sep 2006 05:34:49 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQhQj-0007h6-KU for nemo@ietf.org; Fri, 22 Sep 2006 05:34:49 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k8M9YjsA023468; Fri, 22 Sep 2006 02:34:45 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k8M9Yip5005589; Fri, 22 Sep 2006 04:34:44 -0500 (CDT) Message-ID: <4513AE33.1090506@motorola.com> Date: Fri, 22 Sep 2006 11:34:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ml-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: , Errors-To: nemo-bounces@ietf.org T.J. Kniveton wrote: > Hi folks, I'm back.. > > Here is the current version of the charter. I am still making > changes, and need to modify the milestones section. But wanted to > share what's there now and see if there are any comments. > > Please send comments directly to me, for the moment, and when I have > the next version we can discuss it on the list. > > http://www.mobilenetworks.org/nemo/charter2_3.txt Another remark on the Charter2_3. It has an item: "??? 2006 Submit -00 draft on Route Optimization for geographically distributed HAs" However, this is not currently a WG item (so can't be considered as "finishing ongoing WG documents") and has no other textual description in charter2_3. What is it about? Is it draft-wakikawa-mip6-nemo-haha-01.txt or draft-wakikawa-mip6-nemo-haha-spec-00? We've had a long discussion previously about the need and feasibility of HAHA protocols. There may have been many conclusions, I don't remember all. Alex From nemo-bounces@ietf.org Fri Sep 22 06:42:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQiUA-0004BF-Nr; Fri, 22 Sep 2006 06:42:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQiU9-0004BA-Qu for nemo@ietf.org; Fri, 22 Sep 2006 06:42:21 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQiU1-0002Ir-Dt for nemo@ietf.org; Fri, 22 Sep 2006 06:42:21 -0400 Received: from iseran-2.local ([193.249.204.147]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8MAfj2T023956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Sep 2006 12:41:50 +0200 Date: Fri, 22 Sep 2006 12:41:34 +0200 From: Thierry Ernst To: Alexandru Petrescu Subject: Re: v4 (was: [nemo] Charter update, continued) Message-Id: <20060922124134.4c3c5aff.thierry.ernst@inria.fr> In-Reply-To: <4513A691.7040407@motorola.com> References: <4513A691.7040407@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4513BDE9.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: , Errors-To: nemo-bounces@ietf.org Hi Alex, Thanks for the comment. I don't know what was TJ's intention in this sentence, but I propose to remove it from the charter. It was agreed at last july that the MIPv4 work should be done in the MIP4 WG, and that the NEMO WG is just going to complete it's work on the NEMOv4 Informational draft which is - as explained by Alex - going to be sent to the IESG. Since it's an informational draft, we don't expect any more CPU time from the NEMO WG so mentioning it in the new charter is pointless IMHO. Thierry. On Fri, 22 Sep 2006 11:02:09 +0200 Alexandru Petrescu wrote: > T.J. Kniveton wrote: > > Hi folks, I'm back.. > > > > Here is the current version of the charter. I am still making > > changes, and need to modify the milestones section. But wanted to > > share what's there now and see if there are any comments. > > > > Please send comments directly to me, for the moment, and when I have > > the next version we can discuss it on the list. > > > > http://www.mobilenetworks.org/nemo/charter2_3.txt > > TJ, thanks for posting the new Charter proposal. There is one specific > item I would like to ask in this message: > > "- Work with the Mobile IPv4 working group to hand over work on > IPv4-only NEMO solutions." > > Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call > through this WG, supposedly ending September 30th. How do you (and WG > members) see transition to the MIP4 WG? > > I see it as being finalised here and submitted to IESG, and only then > eventually taken on by the MIP4 WG. > > Thanks, > > Alex > -- Thierry ERNST, PhD http://www.nautilus6.org/~thierry IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair -- INRIA Rocquencourt Project-Team IMARA, France. +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Fri Sep 22 09:02:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkf6-00077M-D8; Fri, 22 Sep 2006 09:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkf5-00077E-5S for nemo@ietf.org; Fri, 22 Sep 2006 09:01:47 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQkez-0007ju-PL for nemo@ietf.org; Fri, 22 Sep 2006 09:01:47 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8MD1dZ2009040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Sep 2006 06:01:40 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8MD1VvY020813; Fri, 22 Sep 2006 06:01:31 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 06:01:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 (was: [nemo] Charter update, continued) Date: Fri, 22 Sep 2006 06:01:05 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A1E8C02@NAEX14.na.qualcomm.com> In-Reply-To: <20060922124134.4c3c5aff.thierry.ernst@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v4 (was: [nemo] Charter update, continued) thread-index: AcbeM+6iO7Ci+T1sSY+smOtwmHzd0AAEeEpA From: "Tsirtsis, George" To: "Thierry Ernst" , "Alexandru Petrescu" X-OriginalArrivalTime: 22 Sep 2006 13:01:04.0911 (UTC) FILETIME=[29A129F0:01C6DE47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org, Pete McCann , tj@kniveton.com, Henrik Levkowetz 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: , Errors-To: nemo-bounces@ietf.org If this work is taken over by MIPv4 shouldn't MIPv4 decide whether to make this Informational or standards track?=20 Since MIPv4 WG is more interested in this work we might be able to go through peer review of this work more properly there. George > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Friday, September 22, 2006 6:42 AM > To: Alexandru Petrescu > Cc: nemo@ietf.org; tj@kniveton.com > Subject: Re: v4 (was: [nemo] Charter update, continued) >=20 >=20 > Hi Alex, >=20 > Thanks for the comment. >=20 > I don't know what was TJ's intention in this sentence, but I propose to > remove it from the charter. >=20 > It was agreed at last july that the MIPv4 work should be done in the > MIP4 WG, and that the NEMO WG is just going to complete it's work on the > NEMOv4 Informational draft which is - as explained by Alex - going to be > sent to the IESG. Since it's an informational draft, we don't expect any > more CPU time from the NEMO WG so mentioning it in the new charter is > pointless IMHO. >=20 > Thierry. >=20 > On Fri, 22 Sep 2006 11:02:09 +0200 > Alexandru Petrescu wrote: >=20 > > T.J. Kniveton wrote: > > > Hi folks, I'm back.. > > > > > > Here is the current version of the charter. I am still making > > > changes, and need to modify the milestones section. But wanted to > > > share what's there now and see if there are any comments. > > > > > > Please send comments directly to me, for the moment, and when I have > > > the next version we can discuss it on the list. > > > > > > http://www.mobilenetworks.org/nemo/charter2_3.txt > > > > TJ, thanks for posting the new Charter proposal. There is one specific > > item I would like to ask in this message: > > > > "- Work with the Mobile IPv4 working group to hand over work on > > IPv4-only NEMO solutions." > > > > Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call > > through this WG, supposedly ending September 30th. How do you (and WG > > members) see transition to the MIP4 WG? > > > > I see it as being finalised here and submitted to IESG, and only then > > eventually taken on by the MIP4 WG. > > > > Thanks, > > > > Alex > > >=20 >=20 > -- > Thierry ERNST, PhD > http://www.nautilus6.org/~thierry > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > -- > INRIA Rocquencourt Project-Team IMARA, France. > +33 1 39 63 59 30 (office) >=20 From nemo-bounces@ietf.org Fri Sep 22 10:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQliP-0003cF-SG; Fri, 22 Sep 2006 10:09:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQliN-0003by-Qu for nemo@ietf.org; Fri, 22 Sep 2006 10:09:15 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQliM-0002eI-GY for nemo@ietf.org; Fri, 22 Sep 2006 10:09:15 -0400 Received: from [192.168.1.102] ([24.6.251.221]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 07:07:51 -0700 Message-ID: <4513EE37.4010703@azairenet.com> Date: Fri, 22 Sep 2006 07:07:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Alexandru Petrescu References: <4513A691.7040407@motorola.com> In-Reply-To: <4513A691.7040407@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2006 14:07:51.0246 (UTC) FILETIME=[7D975EE0:01C6DE50] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ml-nemo WG , mccap@petoni.org, "T.J. Kniveton" , Henrik Levkowetz Subject: [nemo] Re: v4 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: , Errors-To: nemo-bounces@ietf.org Alexandru Petrescu wrote: > TJ, thanks for posting the new Charter proposal. There is one specific > item I would like to ask in this message: > > "- Work with the Mobile IPv4 working group to hand over work on > IPv4-only NEMO solutions." > > Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call > through this WG, supposedly ending September 30th. How do you (and WG > members) see transition to the MIP4 WG? at the last IETF, the MIP4 WG expressed willingness to take on this document and even standardize it as a proposed standard. process wise, it is simple. the authors just need to submit the draft to the MIP4 WG. the NEMO WG chairs just need to remove this draft from the NEMO charter. > I see it as being finalised here and submitted to IESG, and only then > eventually taken on by the MIP4 WG. there is no need to do this. I would favor doing this in the MIP4 WG and let the MIP4 WG decided whether it will be Informational or Standards track. Vijay From nemo-bounces@ietf.org Fri Sep 22 10:33:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQm5Q-0007v8-BH; Fri, 22 Sep 2006 10:33:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQm5P-0007v3-Al for nemo@ietf.org; Fri, 22 Sep 2006 10:33:03 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQm5N-0001m3-Ub for nemo@ietf.org; Fri, 22 Sep 2006 10:33:03 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id k8MEWw7M020211; Fri, 22 Sep 2006 07:32:58 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k8MEWpjI026073; Fri, 22 Sep 2006 09:32:53 -0500 (CDT) Message-ID: <4513F410.80809@motorola.com> Date: Fri, 22 Sep 2006 16:32:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli References: <4513A691.7040407@motorola.com> <4513EE37.4010703@azairenet.com> In-Reply-To: <4513EE37.4010703@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ml-nemo WG , mccap@petoni.org, "T.J. Kniveton" , Henrik Levkowetz Subject: [nemo] Re: v4 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: , Errors-To: nemo-bounces@ietf.org Sounds feasible, thanks for all the suggestions, I would even prefer it if it were not for the following: I would rather prefer it sent to IESG from here than from MIP4. IESG is used with network mobility documents coming from here. I would not prefer delays coming from misunderstanding by IESG answering questions: where was it developped? where was it LC'ed? who sends it? The double answer to this makes it - probably - difficult to understand. It may also be that it can go to IESG from MIP4 relatively smoothly - I do not know. I think we need advice from AD about how to proceed with the least bottlenecks. Thanks, Alex Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> TJ, thanks for posting the new Charter proposal. There is one >> specific item I would like to ask in this message: >> >> "- Work with the Mobile IPv4 working group to hand over work on >> IPv4-only NEMO solutions." >> >> Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call >> through this WG, supposedly ending September 30th. How do you (and >> WG members) see transition to the MIP4 WG? > > at the last IETF, the MIP4 WG expressed willingness to take on this > document and even standardize it as a proposed standard. > > process wise, it is simple. the authors just need to submit the draft > to the MIP4 WG. the NEMO WG chairs just need to remove this draft > from the NEMO charter. > >> I see it as being finalised here and submitted to IESG, and only >> then eventually taken on by the MIP4 WG. > > there is no need to do this. > > I would favor doing this in the MIP4 WG and let the MIP4 WG decided > whether it will be Informational or Standards track. > > Vijay > From nemo-bounces@ietf.org Fri Sep 22 10:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmBm-0002Nm-7D; Fri, 22 Sep 2006 10:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmBk-0002H7-CT for nemo@ietf.org; Fri, 22 Sep 2006 10:39:36 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQmBb-0003Gy-TM for nemo@ietf.org; Fri, 22 Sep 2006 10:39:36 -0400 Received: from iseran-2.local ([80.10.35.45]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8MEcY3d023894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Sep 2006 16:39:08 +0200 Date: Fri, 22 Sep 2006 16:38:23 +0200 From: Thierry Ernst To: Alexandru Petrescu Subject: Re: [nemo] Re: v4 Message-Id: <20060922163823.4a1ccd3b.thierry.ernst@inria.fr> In-Reply-To: <4513F410.80809@motorola.com> References: <4513A691.7040407@motorola.com> <4513EE37.4010703@azairenet.com> <4513F410.80809@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 4513F56A.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: nemo@ietf.org, mccap@petoni.org, tj@kniveton.com, vijay.devarapalli@AzaireNet.com, henrik@levkowetz.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: , Errors-To: nemo-bounces@ietf.org I think what said Vijay is the right thing to do. Just submit the draft in MIP4 and let the group decide what to do. Alternatively, keeps it as informational in the NEMO WG and sends it to the IESG as is after the LC is over. I prefer the former. Thierry On Fri, 22 Sep 2006 16:32:48 +0200 Alexandru Petrescu wrote: > Sounds feasible, thanks for all the suggestions, I would even prefer it > if it were not for the following: > > I would rather prefer it sent to IESG from here than from MIP4. IESG is > used with network mobility documents coming from here. I would not > prefer delays coming from misunderstanding by IESG answering > questions: where was it developped? where was it LC'ed? who sends it? > The double answer to this makes it - probably - difficult to understand. > > It may also be that it can go to IESG from MIP4 relatively smoothly - I > do not know. > > I think we need advice from AD about how to proceed with the least > bottlenecks. > > Thanks, > > Alex > > Vijay Devarapalli wrote: > > Alexandru Petrescu wrote: > >> TJ, thanks for posting the new Charter proposal. There is one > >> specific item I would like to ask in this message: > >> > >> "- Work with the Mobile IPv4 working group to hand over work on > >> IPv4-only NEMO solutions." > >> > >> Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call > >> through this WG, supposedly ending September 30th. How do you (and > >> WG members) see transition to the MIP4 WG? > > > > at the last IETF, the MIP4 WG expressed willingness to take on this > > document and even standardize it as a proposed standard. > > > > process wise, it is simple. the authors just need to submit the draft > > to the MIP4 WG. the NEMO WG chairs just need to remove this draft > > from the NEMO charter. > > > >> I see it as being finalised here and submitted to IESG, and only > >> then eventually taken on by the MIP4 WG. > > > > there is no need to do this. > > > > I would favor doing this in the MIP4 WG and let the MIP4 WG decided > > whether it will be Informational or Standards track. > > > > Vijay > > > > -- Thierry ERNST, PhD http://www.nautilus6.org/~thierry IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair -- INRIA Rocquencourt Project-Team IMARA, France. +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Fri Sep 22 10:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmTY-0001up-6r; Fri, 22 Sep 2006 10:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQmTW-0001uc-OX for nemo@ietf.org; Fri, 22 Sep 2006 10:57:58 -0400 Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQmTV-0007FE-F2 for nemo@ietf.org; Fri, 22 Sep 2006 10:57:58 -0400 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 1ACAB37EA6; Fri, 22 Sep 2006 16:57:46 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 0C9C337E58; Fri, 22 Sep 2006 16:57:46 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A765B37E4B; Fri, 22 Sep 2006 16:57:53 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GQmTO-0004fH-WA; Fri, 22 Sep 2006 16:57:51 +0200 Message-ID: <4513F9EC.7020906@levkowetz.com> Date: Fri, 22 Sep 2006 16:57:48 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Vijay Devarapalli References: <4513A691.7040407@motorola.com> <4513EE37.4010703@azairenet.com> In-Reply-To: <4513EE37.4010703@azairenet.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ml-nemo WG , mccap@petoni.org, "T.J. Kniveton" , Alexandru Petrescu Subject: [nemo] Re: v4 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: , Errors-To: nemo-bounces@ietf.org Below: on 2006-09-22 16:07 Vijay Devarapalli said the following: > Alexandru Petrescu wrote: >> TJ, thanks for posting the new Charter proposal. There is one specific >> item I would like to ask in this message: >> >> "- Work with the Mobile IPv4 working group to hand over work on >> IPv4-only NEMO solutions." >> >> Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call >> through this WG, supposedly ending September 30th. How do you (and WG >> members) see transition to the MIP4 WG? > > at the last IETF, the MIP4 WG expressed willingness > to take on this document and even standardize it as > a proposed standard. > > process wise, it is simple. the authors just need > to submit the draft to the MIP4 WG. the NEMO WG > chairs just need to remove this draft from the NEMO > charter. > >> I see it as being finalised here and submitted to IESG, and only then >> eventually taken on by the MIP4 WG. > > there is no need to do this. > > I would favor doing this in the MIP4 WG and let the > MIP4 WG decided whether it will be Informational or > Standards track. Yes, that would make the most sense to me. Henrik From nemo-bounces@ietf.org Fri Sep 22 12:54:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQoH5-0002TB-P7; Fri, 22 Sep 2006 12:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQoH4-0002T6-5w for nemo@ietf.org; Fri, 22 Sep 2006 12:53:14 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQoGz-0006gF-O7 for nemo@ietf.org; Fri, 22 Sep 2006 12:53:14 -0400 Message-ID: <064f01c6de67$b6fbc970$526015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tsirtsis, George" , "Thierry Ernst" , "Alexandru Petrescu" References: <7EB20EA0938B4D42A2D82689365C9B7A1E8C02@NAEX14.na.qualcomm.com> Subject: Re: v4 (was: [nemo] Charter update, continued) Date: Fri, 22 Sep 2006 09:54:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: nemo@ietf.org, Pete McCann , tj@kniveton.com, Henrik Levkowetz 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: , Errors-To: nemo-bounces@ietf.org Yes, I agree. If the NEMO WG wants to move this to MIPv4, then it is up to the MIPv4 WG to decide the document publication status. jak ----- Original Message ----- From: "Tsirtsis, George" To: "Thierry Ernst" ; "Alexandru Petrescu" Cc: ; "Pete McCann" ; ; "Henrik Levkowetz" Sent: Friday, September 22, 2006 6:01 AM Subject: RE: v4 (was: [nemo] Charter update, continued) If this work is taken over by MIPv4 shouldn't MIPv4 decide whether to make this Informational or standards track? Since MIPv4 WG is more interested in this work we might be able to go through peer review of this work more properly there. George > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Friday, September 22, 2006 6:42 AM > To: Alexandru Petrescu > Cc: nemo@ietf.org; tj@kniveton.com > Subject: Re: v4 (was: [nemo] Charter update, continued) > > > Hi Alex, > > Thanks for the comment. > > I don't know what was TJ's intention in this sentence, but I propose to > remove it from the charter. > > It was agreed at last july that the MIPv4 work should be done in the > MIP4 WG, and that the NEMO WG is just going to complete it's work on the > NEMOv4 Informational draft which is - as explained by Alex - going to be > sent to the IESG. Since it's an informational draft, we don't expect any > more CPU time from the NEMO WG so mentioning it in the new charter is > pointless IMHO. > > Thierry. > > On Fri, 22 Sep 2006 11:02:09 +0200 > Alexandru Petrescu wrote: > > > T.J. Kniveton wrote: > > > Hi folks, I'm back.. > > > > > > Here is the current version of the charter. I am still making > > > changes, and need to modify the milestones section. But wanted to > > > share what's there now and see if there are any comments. > > > > > > Please send comments directly to me, for the moment, and when I have > > > the next version we can discuss it on the list. > > > > > > http://www.mobilenetworks.org/nemo/charter2_3.txt > > > > TJ, thanks for posting the new Charter proposal. There is one specific > > item I would like to ask in this message: > > > > "- Work with the Mobile IPv4 working group to hand over work on > > IPv4-only NEMO solutions." > > > > Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call > > through this WG, supposedly ending September 30th. How do you (and WG > > members) see transition to the MIP4 WG? > > > > I see it as being finalised here and submitted to IESG, and only then > > eventually taken on by the MIP4 WG. > > > > Thanks, > > > > Alex > > > > > -- > Thierry ERNST, PhD > http://www.nautilus6.org/~thierry > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > -- > INRIA Rocquencourt Project-Team IMARA, France. > +33 1 39 63 59 30 (office) > From nemo-bounces@ietf.org Fri Sep 22 14:59:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQqE9-0004mE-98; Fri, 22 Sep 2006 14:58:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQqE7-0004m4-SY for nemo@ietf.org; Fri, 22 Sep 2006 14:58:19 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQqE3-0006BF-Fs for nemo@ietf.org; Fri, 22 Sep 2006 14:58:19 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8MIvnUF025396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Sep 2006 11:57:50 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8MIvmOf025886; Fri, 22 Sep 2006 11:57:48 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 11:57:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 (was: [nemo] Charter update, continued) Date: Fri, 22 Sep 2006 11:57:47 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A1E8C9A@NAEX14.na.qualcomm.com> In-Reply-To: <064f01c6de67$b6fbc970$526015ac@dcml.docomolabsusa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v4 (was: [nemo] Charter update, continued) thread-index: AcbeZ5ahQEQ8AGcQRWCaz5C5EC4VrwADtJQA From: "Tsirtsis, George" To: "James Kempf" , "Thierry Ernst" , "Alexandru Petrescu" X-OriginalArrivalTime: 22 Sep 2006 18:57:48.0179 (UTC) FILETIME=[FEF8AE30:01C6DE78] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: nemo@ietf.org, Pete McCann , tj@kniveton.com, Henrik Levkowetz 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: , Errors-To: nemo-bounces@ietf.org The only problem is that MIP4 WG needs another re-chartering to make NEMOv4 work its own. It would be nice if this is done promptly so that the NEMOv4 base draft does not find itself in limbo. George=20 > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, September 22, 2006 12:54 PM > To: Tsirtsis, George; Thierry Ernst; Alexandru Petrescu > Cc: nemo@ietf.org; Pete McCann; tj@kniveton.com; Henrik Levkowetz > Subject: Re: v4 (was: [nemo] Charter update, continued) >=20 > Yes, I agree. If the NEMO WG wants to move this to MIPv4, then it is up to > the MIPv4 WG to decide the document publication status. >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Tsirtsis, George" > To: "Thierry Ernst" ; "Alexandru Petrescu" > > Cc: ; "Pete McCann" ; ; > "Henrik Levkowetz" > Sent: Friday, September 22, 2006 6:01 AM > Subject: RE: v4 (was: [nemo] Charter update, continued) >=20 >=20 > If this work is taken over by MIPv4 shouldn't MIPv4 decide whether to > make this Informational or standards track? >=20 > Since MIPv4 WG is more interested in this work we might be able to go > through peer review of this work more properly there. >=20 > George >=20 > > -----Original Message----- > > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > > Sent: Friday, September 22, 2006 6:42 AM > > To: Alexandru Petrescu > > Cc: nemo@ietf.org; tj@kniveton.com > > Subject: Re: v4 (was: [nemo] Charter update, continued) > > > > > > Hi Alex, > > > > Thanks for the comment. > > > > I don't know what was TJ's intention in this sentence, but I propose > to > > remove it from the charter. > > > > It was agreed at last july that the MIPv4 work should be done in the > > MIP4 WG, and that the NEMO WG is just going to complete it's work on > the > > NEMOv4 Informational draft which is - as explained by Alex - going to > be > > sent to the IESG. Since it's an informational draft, we don't expect > any > > more CPU time from the NEMO WG so mentioning it in the new charter is > > pointless IMHO. > > > > Thierry. > > > > On Fri, 22 Sep 2006 11:02:09 +0200 > > Alexandru Petrescu wrote: > > > > > T.J. Kniveton wrote: > > > > Hi folks, I'm back.. > > > > > > > > Here is the current version of the charter. I am still making > > > > changes, and need to modify the milestones section. But wanted to > > > > share what's there now and see if there are any comments. > > > > > > > > Please send comments directly to me, for the moment, and when I > have > > > > the next version we can discuss it on the list. > > > > > > > > http://www.mobilenetworks.org/nemo/charter2_3.txt > > > > > > TJ, thanks for posting the new Charter proposal. There is one > specific > > > item I would like to ask in this message: > > > > > > "- Work with the Mobile IPv4 working group to hand over work on > > > IPv4-only NEMO solutions." > > > > > > Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call > > > through this WG, supposedly ending September 30th. How do you (and > WG > > > members) see transition to the MIP4 WG? > > > > > > I see it as being finalised here and submitted to IESG, and only > then > > > eventually taken on by the MIP4 WG. > > > > > > Thanks, > > > > > > Alex > > > > > > > > > -- > > Thierry ERNST, PhD > > http://www.nautilus6.org/~thierry > > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > > -- > > INRIA Rocquencourt Project-Team IMARA, France. > > +33 1 39 63 59 30 (office) > > >=20 From nemo-bounces@ietf.org Fri Sep 22 17:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsG0-0006YS-O2; Fri, 22 Sep 2006 17:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsFz-0006WJ-RR for nemo@ietf.org; Fri, 22 Sep 2006 17:08:23 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQsFv-00071b-C9 for nemo@ietf.org; Fri, 22 Sep 2006 17:08:23 -0400 Message-ID: <078401c6de8b$66221d50$526015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tsirtsis, George" , "Thierry Ernst" , "Alexandru Petrescu" References: <7EB20EA0938B4D42A2D82689365C9B7A1E8C9A@NAEX14.na.qualcomm.com> Subject: Re: v4 (was: [nemo] Charter update, continued) Date: Fri, 22 Sep 2006 14:09:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: nemo@ietf.org, Pete McCann , tj@kniveton.com, Henrik Levkowetz 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: , Errors-To: nemo-bounces@ietf.org If that is the only item that needs to get into their charter, it shouldn't require a lot of discussion. Or is there some amount of controversy in the MIPv4 WG about whether or not it should be taken up? jak ----- Original Message ----- From: "Tsirtsis, George" To: "James Kempf" ; "Thierry Ernst" ; "Alexandru Petrescu" Cc: ; "Pete McCann" ; ; "Henrik Levkowetz" Sent: Friday, September 22, 2006 11:57 AM Subject: RE: v4 (was: [nemo] Charter update, continued) The only problem is that MIP4 WG needs another re-chartering to make NEMOv4 work its own. It would be nice if this is done promptly so that the NEMOv4 base draft does not find itself in limbo. George > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, September 22, 2006 12:54 PM > To: Tsirtsis, George; Thierry Ernst; Alexandru Petrescu > Cc: nemo@ietf.org; Pete McCann; tj@kniveton.com; Henrik Levkowetz > Subject: Re: v4 (was: [nemo] Charter update, continued) > > Yes, I agree. If the NEMO WG wants to move this to MIPv4, then it is up to > the MIPv4 WG to decide the document publication status. > > jak > > > ----- Original Message ----- > From: "Tsirtsis, George" > To: "Thierry Ernst" ; "Alexandru Petrescu" > > Cc: ; "Pete McCann" ; ; > "Henrik Levkowetz" > Sent: Friday, September 22, 2006 6:01 AM > Subject: RE: v4 (was: [nemo] Charter update, continued) > > > If this work is taken over by MIPv4 shouldn't MIPv4 decide whether to > make this Informational or standards track? > > Since MIPv4 WG is more interested in this work we might be able to go > through peer review of this work more properly there. > > George > > > -----Original Message----- > > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > > Sent: Friday, September 22, 2006 6:42 AM > > To: Alexandru Petrescu > > Cc: nemo@ietf.org; tj@kniveton.com > > Subject: Re: v4 (was: [nemo] Charter update, continued) > > > > > > Hi Alex, > > > > Thanks for the comment. > > > > I don't know what was TJ's intention in this sentence, but I propose > to > > remove it from the charter. > > > > It was agreed at last july that the MIPv4 work should be done in the > > MIP4 WG, and that the NEMO WG is just going to complete it's work on > the > > NEMOv4 Informational draft which is - as explained by Alex - going to > be > > sent to the IESG. Since it's an informational draft, we don't expect > any > > more CPU time from the NEMO WG so mentioning it in the new charter is > > pointless IMHO. > > > > Thierry. > > > > On Fri, 22 Sep 2006 11:02:09 +0200 > > Alexandru Petrescu wrote: > > > > > T.J. Kniveton wrote: > > > > Hi folks, I'm back.. > > > > > > > > Here is the current version of the charter. I am still making > > > > changes, and need to modify the milestones section. But wanted to > > > > share what's there now and see if there are any comments. > > > > > > > > Please send comments directly to me, for the moment, and when I > have > > > > the next version we can discuss it on the list. > > > > > > > > http://www.mobilenetworks.org/nemo/charter2_3.txt > > > > > > TJ, thanks for posting the new Charter proposal. There is one > specific > > > item I would like to ask in this message: > > > > > > "- Work with the Mobile IPv4 working group to hand over work on > > > IPv4-only NEMO solutions." > > > > > > Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call > > > through this WG, supposedly ending September 30th. How do you (and > WG > > > members) see transition to the MIP4 WG? > > > > > > I see it as being finalised here and submitted to IESG, and only > then > > > eventually taken on by the MIP4 WG. > > > > > > Thanks, > > > > > > Alex > > > > > > > > > -- > > Thierry ERNST, PhD > > http://www.nautilus6.org/~thierry > > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > > -- > > INRIA Rocquencourt Project-Team IMARA, France. > > +33 1 39 63 59 30 (office) > > > From nemo-bounces@ietf.org Fri Sep 22 17:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsV5-0004iQ-Hz; Fri, 22 Sep 2006 17:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsV4-0004iK-9e for nemo@ietf.org; Fri, 22 Sep 2006 17:23:58 -0400 Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQsUy-0000xc-ML for nemo@ietf.org; Fri, 22 Sep 2006 17:23:58 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 1549937EB0; Fri, 22 Sep 2006 23:23:41 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 065FD37E80; Fri, 22 Sep 2006 23:23:41 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BB7DD37E45; Fri, 22 Sep 2006 23:23:48 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GQsUt-0003yd-HL; Fri, 22 Sep 2006 23:23:47 +0200 Message-ID: <4514545B.9050105@levkowetz.com> Date: Fri, 22 Sep 2006 23:23:39 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: James Kempf Subject: Re: v4 (was: [nemo] Charter update, continued) References: <7EB20EA0938B4D42A2D82689365C9B7A1E8C9A@NAEX14.na.qualcomm.com> <078401c6de8b$66221d50$526015ac@dcml.docomolabsusa.com> In-Reply-To: <078401c6de8b$66221d50$526015ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: nemo@ietf.org, Alexandru Petrescu , Thierry Ernst , tj@kniveton.com, Pete McCann 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: , Errors-To: nemo-bounces@ietf.org Hi James, on 2006-09-22 23:09 James Kempf said the following: > If that is the only item that needs to get into their charter, it shouldn't > require a lot of discussion. Or is there some amount of controversy in the > MIPv4 WG about whether or not it should be taken up? Nope. This was discussed in the MIP4 meeting in Montreal, and there was clear consensus on taking this on, and there has been no contrary comments on the mailing list later. The MIP4 minutes from Montreal reflects this consensus clearly, as well as the expressed intention of putting this into a revised charter: http://tools.ietf.org/wg/mip4/minutes?item=minutes66.html Regards, Henrik > jak > > ----- Original Message ----- > From: "Tsirtsis, George" > To: "James Kempf" ; "Thierry Ernst" > ; "Alexandru Petrescu" > > Cc: ; "Pete McCann" ; ; > "Henrik Levkowetz" > Sent: Friday, September 22, 2006 11:57 AM > Subject: RE: v4 (was: [nemo] Charter update, continued) > > > The only problem is that MIP4 WG needs another re-chartering to make > NEMOv4 work its own. It would be nice if this is done promptly so that > the NEMOv4 base draft does not find itself in limbo. > > George > >> -----Original Message----- >> From: James Kempf [mailto:kempf@docomolabs-usa.com] >> Sent: Friday, September 22, 2006 12:54 PM >> To: Tsirtsis, George; Thierry Ernst; Alexandru Petrescu >> Cc: nemo@ietf.org; Pete McCann; tj@kniveton.com; Henrik Levkowetz >> Subject: Re: v4 (was: [nemo] Charter update, continued) >> >> Yes, I agree. If the NEMO WG wants to move this to MIPv4, then it is > up to >> the MIPv4 WG to decide the document publication status. >> >> jak >> >> >> ----- Original Message ----- >> From: "Tsirtsis, George" >> To: "Thierry Ernst" ; "Alexandru Petrescu" >> >> Cc: ; "Pete McCann" ; > ; >> "Henrik Levkowetz" >> Sent: Friday, September 22, 2006 6:01 AM >> Subject: RE: v4 (was: [nemo] Charter update, continued) >> >> >> If this work is taken over by MIPv4 shouldn't MIPv4 decide whether to >> make this Informational or standards track? >> >> Since MIPv4 WG is more interested in this work we might be able to go >> through peer review of this work more properly there. >> >> George >> >> > -----Original Message----- >> > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] >> > Sent: Friday, September 22, 2006 6:42 AM >> > To: Alexandru Petrescu >> > Cc: nemo@ietf.org; tj@kniveton.com >> > Subject: Re: v4 (was: [nemo] Charter update, continued) >> > >> > >> > Hi Alex, >> > >> > Thanks for the comment. >> > >> > I don't know what was TJ's intention in this sentence, but I propose >> to >> > remove it from the charter. >> > >> > It was agreed at last july that the MIPv4 work should be done in the >> > MIP4 WG, and that the NEMO WG is just going to complete it's work on >> the >> > NEMOv4 Informational draft which is - as explained by Alex - going > to >> be >> > sent to the IESG. Since it's an informational draft, we don't expect >> any >> > more CPU time from the NEMO WG so mentioning it in the new charter > is >> > pointless IMHO. >> > >> > Thierry. >> > >> > On Fri, 22 Sep 2006 11:02:09 +0200 >> > Alexandru Petrescu wrote: >> > >> > > T.J. Kniveton wrote: >> > > > Hi folks, I'm back.. >> > > > >> > > > Here is the current version of the charter. I am still making >> > > > changes, and need to modify the milestones section. But wanted > to >> > > > share what's there now and see if there are any comments. >> > > > >> > > > Please send comments directly to me, for the moment, and when I >> have >> > > > the next version we can discuss it on the list. >> > > > >> > > > http://www.mobilenetworks.org/nemo/charter2_3.txt >> > > >> > > TJ, thanks for posting the new Charter proposal. There is one >> specific >> > > item I would like to ask in this message: >> > > >> > > "- Work with the Mobile IPv4 working group to hand over work on >> > > IPv4-only NEMO solutions." >> > > >> > > Currently the NEMOv4 INFORMATIONAL spec is undergoing a Last Call >> > > through this WG, supposedly ending September 30th. How do you > (and >> WG >> > > members) see transition to the MIP4 WG? >> > > >> > > I see it as being finalised here and submitted to IESG, and only >> then >> > > eventually taken on by the MIP4 WG. >> > > >> > > Thanks, >> > > >> > > Alex >> > > >> > >> > >> > -- >> > Thierry ERNST, PhD >> > http://www.nautilus6.org/~thierry >> > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair >> > -- >> > INRIA Rocquencourt Project-Team IMARA, France. >> > +33 1 39 63 59 30 (office) >> > >> > > From nemo-bounces@ietf.org Sun Sep 24 11:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRVpd-0001QY-Ao; Sun, 24 Sep 2006 11:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRVpb-0001QS-Ru for nemo@ietf.org; Sun, 24 Sep 2006 11:23:47 -0400 Received: from scrubby.nicta.com.au ([203.143.174.70] helo=mail.nicta.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRVpa-0001Wm-Ds for nemo@ietf.org; Sun, 24 Sep 2006 11:23:47 -0400 Received: from mail.nicta.com.au (localhost [127.0.0.1]) by localhost.nicta.com.au (Postfix) with ESMTP id 72B8DCE02C for ; Mon, 25 Sep 2006 01:23:45 +1000 (EST) Received: from nicta-atp-mail.in.nicta.com.au (nicta-atp-mail.in.nicta.com.au [129.94.151.12]) by mail.nicta.com.au (Postfix) with ESMTP id 61152CE023 for ; Mon, 25 Sep 2006 01:23:45 +1000 (EST) 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] Charter update, continued X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 25 Sep 2006 01:23:45 +1000 Message-ID: <09D3F703EF3B0A4CBE28449EA9F3D32003EC31BE@nicta-atp-mail.in.nicta.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Charter update, continued Thread-Index: AcbcXV0KZkLVbhbZTtWvc7N6LanAmwDkAlGw From: "Eranga Perera" To: "T.J. Kniveton" , "ml-nemo WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 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: , Errors-To: nemo-bounces@ietf.org Hi TJ/All, The current charter has only a milestone for RO for geographically distributed HAs. However, it would be good to include RO for VMNs enabled by advertising the FNP by the MR.=0D What do you think? Eranga=0D > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com] > Sent: Wednesday, 20 September 2006 12:18 PM > To: ml-nemo WG > Subject: [nemo] Charter update, continued >=0D > Hi folks, I'm back.. >=0D > Here is the current version of the charter. I am still making > changes, and need to modify the milestones section. But wanted to > share what's there now and see if there are any comments. >=0D > Please send comments directly to me, for the moment, and when I have > the next version we can discuss it on the list. >=0D > http://www.mobilenetworks.org/nemo/charter2_3.txt >=0D > TJ -------------------------------------------------------------------------- This email and any attachments may be confidential. They may contain= legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed. From nemo-bounces@ietf.org Mon Sep 25 04:15:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRlcC-0001Og-K0; Mon, 25 Sep 2006 04:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRlcA-0001Mj-QX for nemo@ietf.org; Mon, 25 Sep 2006 04:14:59 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRlc6-0005qU-3L for nemo@ietf.org; Mon, 25 Sep 2006 04:14:58 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E38AB15DC5; Mon, 25 Sep 2006 10:14:52 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp03.uc3m.es (Postfix) with ESMTP id 306F81607F; Mon, 25 Sep 2006 10:14:50 +0200 (CEST) In-Reply-To: <4513AE33.1090506@motorola.com> References: <4513AE33.1090506@motorola.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 10:15:36 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ml-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: , Errors-To: nemo-bounces@ietf.org My understanding of the comments in the last meeting was that we were=20 going _first_ to identify what are the relevant scenarios for which we=20= need to design RO solutions and their requirements and only _after_=20 that we are going to work in actual solutions. I mean, my recollection of Thierry's suggestion was to have a first=20 rechartering where we include items about identifying relevant=20 scenarios and requirements for RO and when this is done a new=20 recharter, to include the design of solutions for the identified=20 scenarios As i previously mentioned here, i think it is very hard to evaluate how=20= approapriate a solution is if we don't have explicitly fleshed out what=20= the problem and requiremnets are So i would suggest to remove the item Submit -00 draft on Route Optimization for geographically distributed=20 HAs And to include an item about providing a new ID -00 about identifying=20 scenarios and requirements for RO Regards, marcelo El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: > T.J. Kniveton wrote: >> Hi folks, I'm back.. >> Here is the current version of the charter. I am still making >> changes, and need to modify the milestones section. But wanted to >> share what's there now and see if there are any comments. >> Please send comments directly to me, for the moment, and when I have >> the next version we can discuss it on the list. >> http://www.mobilenetworks.org/nemo/charter2_3.txt > > Another remark on the Charter2_3. It has an item: > "??? 2006 Submit -00 draft on Route Optimization for > geographically distributed HAs" > > However, this is not currently a WG item (so can't be considered as > "finishing ongoing WG documents") and has no other textual description > in charter2_3. What is it about? Is it > draft-wakikawa-mip6-nemo-haha-01.txt or > draft-wakikawa-mip6-nemo-haha-spec-00? > > We've had a long discussion previously about the need and feasibility=20= > of > HAHA protocols. There may have been many conclusions, I don't=20 > remember > all. > > Alex > From nemo-bounces@ietf.org Mon Sep 25 04:25:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRlmW-0005cu-3q; Mon, 25 Sep 2006 04:25:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRlmU-0005cp-VU for nemo@ietf.org; Mon, 25 Sep 2006 04:25:38 -0400 Received: from scrubby.nicta.com.au ([203.143.174.70] helo=mail.nicta.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRlmT-0008Fo-8U for nemo@ietf.org; Mon, 25 Sep 2006 04:25:38 -0400 Received: from mail.nicta.com.au (localhost [127.0.0.1]) by localhost.nicta.com.au (Postfix) with ESMTP id C042ACE031 for ; Mon, 25 Sep 2006 18:25:35 +1000 (EST) Received: from nicta-atp-mail.in.nicta.com.au (nicta-atp-mail.in.nicta.com.au [129.94.151.12]) by mail.nicta.com.au (Postfix) with ESMTP id 7408CCE00B for ; Mon, 25 Sep 2006 18:25:35 +1000 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 18:25:35 +1000 Message-ID: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33D2@nicta-atp-mail.in.nicta.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Thread-Index: AcbgezZ+HNWyNt+bSvaM7z/5yfEqDAAAILYg From: "Eranga Perera" To: "marcelo bagnulo braun" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ml-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: , Errors-To: nemo-bounces@ietf.org Marcelo,=0D I fully agree with your suggestion. This way everyone will get a chance to= voice out what they think needs addressing within the scope of RO.=0D Cheers, Eranga > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Monday, 25 September 2006 6:16 PM > To: Alexandru Petrescu > Cc: ml-nemo WG; T.J. Kniveton > Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > update,continued) >=0D > My understanding of the comments in the last meeting was that we were > going _first_ to identify what are the relevant scenarios for which we > need to design RO solutions and their requirements and only _after_ > that we are going to work in actual solutions. >=0D > I mean, my recollection of Thierry's suggestion was to have a first > rechartering where we include items about identifying relevant > scenarios and requirements for RO and when this is done a new > recharter, to include the design of solutions for the identified > scenarios >=0D > As i previously mentioned here, i think it is very hard to evaluate how > approapriate a solution is if we don't have explicitly fleshed out what > the problem and requiremnets are >=0D > So i would suggest to remove the item >=0D > Submit -00 draft on Route Optimization for geographically distributed > HAs >=0D > And to include an item about providing a new ID -00 about identifying > scenarios and requirements for RO >=0D > Regards, marcelo >=0D >=0D > El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: >=0D > > T.J. Kniveton wrote: > >> Hi folks, I'm back.. > >> Here is the current version of the charter. I am still making > >> changes, and need to modify the milestones section. But wanted to > >> share what's there now and see if there are any comments. > >> Please send comments directly to me, for the moment, and when I have > >> the next version we can discuss it on the list. > >> http://www.mobilenetworks.org/nemo/charter2_3.txt > > > > Another remark on the Charter2_3. It has an item: > > "??? 2006 Submit -00 draft on Route Optimization for > > geographically distributed HAs" > > > > However, this is not currently a WG item (so can't be considered as > > "finishing ongoing WG documents") and has no other textual description > > in charter2_3. What is it about? Is it > > draft-wakikawa-mip6-nemo-haha-01.txt or > > draft-wakikawa-mip6-nemo-haha-spec-00? > > > > We've had a long discussion previously about the need and feasibility > > of > > HAHA protocols. There may have been many conclusions, I don't > > remember > > all. > > > > Alex > > >=0D -------------------------------------------------------------------------- This email and any attachments may be confidential. They may contain= legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed. From nemo-bounces@ietf.org Mon Sep 25 04:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRlx2-0002BZ-B5; Mon, 25 Sep 2006 04:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRlx0-0002BU-Mh for nemo@ietf.org; Mon, 25 Sep 2006 04:36:30 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRlwz-0001do-0v for nemo@ietf.org; Mon, 25 Sep 2006 04:36:30 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 259DE1767D; Mon, 25 Sep 2006 10:36:28 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp03.uc3m.es (Postfix) with ESMTP id 6D592176C5; Mon, 25 Sep 2006 10:36:20 +0200 (CEST) In-Reply-To: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33D2@nicta-atp-mail.in.nicta.com.au> References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33D2@nicta-atp-mail.in.nicta.com.au> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <222b59dc58e12375781459cd7f487d21@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 10:37:06 +0200 To: "Eranga Perera" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: ml-nemo WG , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org El 25/09/2006, a las 10:25, Eranga Perera escribi=F3: > > Marcelo, > I fully agree with your suggestion. This way everyone will get a =20 > chance to voice out what they think needs addressing within the scope =20= > of RO. > a subtle point here, i would prefer to hear from actual potential users =20= of the RO solutions (like the people from the aviation or car industry =20= or others) rather than random opinions about what different apporach =20 should be better in the abstract i mean, what i would think is that way forward, i to get the potential =20= users, like aviation or car industry, to define their problem and the =20= requirements in an draft and then based on this define solutions for =20 the identified problems that i what i think should be in the charter, itmes to produce =20 scenarrios and requiremets for RO Regards, marcelo > Cheers, > Eranga > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, 25 September 2006 6:16 PM >> To: Alexandru Petrescu >> Cc: ml-nemo WG; T.J. Kniveton >> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter >> update,continued) >> >> My understanding of the comments in the last meeting was that we were >> going _first_ to identify what are the relevant scenarios for which = we >> need to design RO solutions and their requirements and only _after_ >> that we are going to work in actual solutions. >> >> I mean, my recollection of Thierry's suggestion was to have a first >> rechartering where we include items about identifying relevant >> scenarios and requirements for RO and when this is done a new >> recharter, to include the design of solutions for the identified >> scenarios >> >> As i previously mentioned here, i think it is very hard to evaluate =20= >> how >> approapriate a solution is if we don't have explicitly fleshed out =20= >> what >> the problem and requiremnets are >> >> So i would suggest to remove the item >> >> Submit -00 draft on Route Optimization for geographically distributed >> HAs >> >> And to include an item about providing a new ID -00 about identifying >> scenarios and requirements for RO >> >> Regards, marcelo >> >> >> El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: >> >>> T.J. Kniveton wrote: >>>> Hi folks, I'm back.. >>>> Here is the current version of the charter. I am still making >>>> changes, and need to modify the milestones section. But wanted to >>>> share what's there now and see if there are any comments. >>>> Please send comments directly to me, for the moment, and when I = have >>>> the next version we can discuss it on the list. >>>> http://www.mobilenetworks.org/nemo/charter2_3.txt >>> >>> Another remark on the Charter2_3. It has an item: >>> "??? 2006 Submit -00 draft on Route Optimization for >>> geographically distributed HAs" >>> >>> However, this is not currently a WG item (so can't be considered as >>> "finishing ongoing WG documents") and has no other textual =20 >>> description >>> in charter2_3. What is it about? Is it >>> draft-wakikawa-mip6-nemo-haha-01.txt or >>> draft-wakikawa-mip6-nemo-haha-spec-00? >>> >>> We've had a long discussion previously about the need and = feasibility >>> of >>> HAHA protocols. There may have been many conclusions, I don't >>> remember >>> all. >>> >>> Alex >>> >> > > > > = -----------------------------------------------------------------------=20= > --- > This email and any attachments may be confidential. They may contain =20= > legally > privileged information or copyright material. You should not read, =20 > copy, > use or disclose them without authorisation. If you are not an intended > recipient, please contact us at once by return email and then delete =20= > both > messages. We do not accept liability in connection with computer = virus, > data corruption, delay, interruption, unauthorised access or =20 > unauthorised > amendment. This notice should not be removed. > From nemo-bounces@ietf.org Mon Sep 25 05:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRmJl-0002aU-Uy; Mon, 25 Sep 2006 05:00:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRmJj-0002aJ-W5 for nemo@ietf.org; Mon, 25 Sep 2006 05:00:00 -0400 Received: from scrubby.nicta.com.au ([203.143.174.70] helo=mail.nicta.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRmJh-0004Mt-4I for nemo@ietf.org; Mon, 25 Sep 2006 04:59:59 -0400 Received: from mail.nicta.com.au (localhost [127.0.0.1]) by localhost.nicta.com.au (Postfix) with ESMTP id 1F11DCE01C for ; Mon, 25 Sep 2006 18:59:51 +1000 (EST) Received: from nicta-atp-mail.in.nicta.com.au (nicta-atp-mail.in.nicta.com.au [129.94.151.12]) by mail.nicta.com.au (Postfix) with ESMTP id E6664CDFE2 for ; Mon, 25 Sep 2006 18:59:50 +1000 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E080.F5AA5F14" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 18:59:50 +1000 Message-ID: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Thread-Index: AcbgfbPo2R781JjYT3eaFnuE9akj+gAAjeiw From: "Eranga Perera" To: "marcelo bagnulo braun" X-Spam-Score: 0.0 (/) X-Scan-Signature: dc66614367938496c5de3fbca71f9060 Cc: ml-nemo WG , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E080.F5AA5F14 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 As for opinions from actual users of RO solutions would be good. = However, if such comments are not forthcoming, then I don't think it is = a too difficult task to come up with realistic scenarios and = requirements.=20 =20 The point is by only rechartering for handling geographically = distributed HAs, other cases can not be voiced at all.=20 =20 -eranga =20 =20 =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Monday, 25 September 2006 6:37 PM > To: Eranga Perera > Cc: Alexandru Petrescu; ml-nemo WG; T.J. Kniveton > Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > update,continued) >=20 >=20 > El 25/09/2006, a las 10:25, Eranga Perera escribi=F3: >=20 > > > > Marcelo, > > I fully agree with your suggestion. This way everyone will get a > > chance to voice out what they think needs addressing within the = scope > > of RO. > > >=20 > a subtle point here, i would prefer to hear from actual potential = users > of the RO solutions (like the people from the aviation or car industry > or others) rather than random opinions about what different apporach > should be better in the abstract >=20 > i mean, what i would think is that way forward, i to get the potential > users, like aviation or car industry, to define their problem and the > requirements in an draft and then based on this define solutions for > the identified problems >=20 > that i what i think should be in the charter, itmes to produce > scenarrios and requiremets for RO >=20 > Regards, marcelo >=20 >=20 >=20 > > Cheers, > > Eranga > > > >> -----Original Message----- > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >> Sent: Monday, 25 September 2006 6:16 PM > >> To: Alexandru Petrescu > >> Cc: ml-nemo WG; T.J. Kniveton > >> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > >> update,continued) > >> > >> My understanding of the comments in the last meeting was that we = were > >> going _first_ to identify what are the relevant scenarios for which = we > >> need to design RO solutions and their requirements and only _after_ > >> that we are going to work in actual solutions. > >> > >> I mean, my recollection of Thierry's suggestion was to have a first > >> rechartering where we include items about identifying relevant > >> scenarios and requirements for RO and when this is done a new > >> recharter, to include the design of solutions for the identified > >> scenarios > >> > >> As i previously mentioned here, i think it is very hard to evaluate > >> how > >> approapriate a solution is if we don't have explicitly fleshed out > >> what > >> the problem and requiremnets are > >> > >> So i would suggest to remove the item > >> > >> Submit -00 draft on Route Optimization for geographically = distributed > >> HAs > >> > >> And to include an item about providing a new ID -00 about = identifying > >> scenarios and requirements for RO > >> > >> Regards, marcelo > >> > >> > >> El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: > >> > >>> T.J. Kniveton wrote: > >>>> Hi folks, I'm back.. > >>>> Here is the current version of the charter. I am still making > >>>> changes, and need to modify the milestones section. But wanted to > >>>> share what's there now and see if there are any comments. > >>>> Please send comments directly to me, for the moment, and when I = have > >>>> the next version we can discuss it on the list. > >>>> http://www.mobilenetworks.org/nemo/charter2_3.txt > >>> > >>> Another remark on the Charter2_3. It has an item: > >>> "??? 2006 Submit -00 draft on Route Optimization for > >>> geographically distributed HAs" > >>> > >>> However, this is not currently a WG item (so can't be considered = as > >>> "finishing ongoing WG documents") and has no other textual > >>> description > >>> in charter2_3. What is it about? Is it > >>> draft-wakikawa-mip6-nemo-haha-01.txt or > >>> draft-wakikawa-mip6-nemo-haha-spec-00? > >>> > >>> We've had a long discussion previously about the need and = feasibility > >>> of > >>> HAHA protocols. There may have been many conclusions, I don't > >>> remember > >>> all. > >>> > >>> Alex > >>> > >> > > > > > > > > = ----------------------------------------------------------------------- > > --- > > This email and any attachments may be confidential. They may contain > > legally > > privileged information or copyright material. You should not read, > > copy, > > use or disclose them without authorisation. If you are not an = intended > > recipient, please contact us at once by return email and then delete > > both > > messages. We do not accept liability in connection with computer = virus, > > data corruption, delay, interruption, unauthorised access or > > unauthorised > > amendment. This notice should not be removed. > > =20 ------_=_NextPart_001_01C6E080.F5AA5F14 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

As for opinions from actual users of RO solutions would be good. = However, if such comments are not forthcoming, then I don't think it is a too = difficult task to come up with realistic scenarios and requirements. =

 

The point is by only rechartering for = handling geographically distributed HAs, other cases can not be voiced at all. =

 

-eranga

 

 

 

> -----Original = Message-----

> From: marcelo bagnulo = braun [mailto:marcelo@it.uc3m.es]

> Sent: Monday, 25 September = 2006 6:37 PM

> To: Eranga Perera

> Cc: Alexandru Petrescu; = ml-nemo WG; T.J. Kniveton

> Subject: Re: RO for = geographically dist'd HAs (was: [nemo] Charter

> update,continued)

>

>

> El 25/09/2006, a las 10:25, Eranga Perera escribi=F3:

>

> >

> > Marcelo,

> > I fully agree with your suggestion. This way everyone = will get a

> > chance to voice out what they think needs addressing = within the scope

> > of RO.

> >

>

> a subtle point here, i would prefer to hear from actual = potential users

> of the RO solutions (like the people from the aviation or = car industry

> or others) rather than random opinions about what different apporach

> should be better in the = abstract

>

> i mean, what i would think is that way forward, i to get = the potential

> users, like aviation or car industry, to define their = problem and the

> requirements in an draft and then based on this define = solutions for

> the identified problems

>

> that i what i think should be in the charter, itmes to = produce

> scenarrios and requiremets for RO

>

> Regards, marcelo

>

>

>

> > Cheers,

> > Eranga

> >

> >> -----Original Message-----

> >> From: marcelo bagnulo braun = [mailto:marcelo@it.uc3m.es]

> >> Sent: Monday, 25 September 2006 6:16 = PM

> >> To: Alexandru Petrescu

> >> Cc: ml-nemo WG; T.J. Kniveton

> >> Subject: Re: RO for geographically dist'd HAs = (was: [nemo] Charter

> >> update,continued)

> >>

> >> My understanding of the comments in the last = meeting was that we were

> >> going _first_ to identify what are the relevant = scenarios for which we

> >> need to design RO solutions and their requirements = and only _after_

> >> that we are going to work in actual = solutions.

> >>

> >> I mean, my recollection of Thierry's suggestion = was to have a first

> >> rechartering where we include items about = identifying relevant

> >> scenarios and requirements for RO and when this is = done a new

> >> recharter, to include the design of solutions for = the identified

> >> scenarios

> >>

> >> As i previously mentioned here, i think it is very = hard to evaluate

> >> how

> >> approapriate a solution is if we don't have = explicitly fleshed out

> >> what

> >> the problem and requiremnets are

> >>

> >> So i would suggest to remove the = item

> >>

> >> Submit -00 draft on Route Optimization for = geographically distributed

> >> HAs

> >>

> >> And to include an item about providing a new ID = -00 about identifying

> >> scenarios and requirements for = RO

> >>

> >> Regards, marcelo

> >>

> >>

> >> El 22/09/2006, a las 11:34, Alexandru Petrescu = escribi=F3:

> >>

> >>> T.J. Kniveton wrote:

> >>>> Hi folks, I'm back..

> >>>> Here is the current version of the = charter. I am still making

> >>>> changes, and need to modify the milestones section. But wanted to

> >>>> share what's there now and see if there = are any comments.

> >>>> Please send comments directly to me, for = the moment, and when I have

> >>>> the next version we can discuss it on the = list.

> >>>> = http://www.mobilenetworks.org/nemo/charter2_3.txt

> >>>

> >>> Another remark on the Charter2_3.=A0 It has an = item:

> >>> "??? 2006=A0=A0=A0=A0=A0=A0=A0=A0 Submit = -00 draft on Route Optimization for

> >>> = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 geographically = distributed HAs"

> >>>

> >>> However, this is not currently a WG item (so = can't be considered as

> >>> "finishing ongoing WG documents") = and has no other textual

> >>> description

> >>> in charter2_3.=A0 What is it about?=A0 Is = it

> >>> draft-wakikawa-mip6-nemo-haha-01.txt = or

> >>> = draft-wakikawa-mip6-nemo-haha-spec-00?

> >>>

> >>> We've had a long discussion previously about = the need and feasibility

> >>> of

> >>>=A0 HAHA protocols.=A0 There may have been many conclusions, I don't

> >>> remember

> >>> all.

> >>>

> >>> Alex

> >>>

> >>

> >

> >

> >

> > -----------------------------------------------------------------------

> > ---

> > This email and any attachments may be confidential. = They may contain

> > legally

> > privileged information or copyright material. You = should not read,

> > copy,

> > use or disclose them without authorisation. If you are = not an intended

> > recipient, please contact us at once by return email = and then delete

> > both

> > messages. We do not accept liability in connection = with computer virus,

> > data corruption, delay, interruption, unauthorised = access or

> > unauthorised

> > amendment. This notice should not be = removed.

> >

 

------_=_NextPart_001_01C6E080.F5AA5F14-- From nemo-bounces@ietf.org Mon Sep 25 05:29:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRmlJ-0005LT-2P; Mon, 25 Sep 2006 05:28:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRmlH-0005LF-Li for nemo@ietf.org; Mon, 25 Sep 2006 05:28:27 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRmlG-0000Qr-UK for nemo@ietf.org; Mon, 25 Sep 2006 05:28:27 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8P9SNvj008064; Mon, 25 Sep 2006 18:28:23 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8P9SPk15870; Mon, 25 Sep 2006 18:28:25 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id k8P9SNq13893; Mon, 25 Sep 2006 18:28:24 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 17:27:29 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 5FBB9D4221; Mon, 25 Sep 2006 17:30:28 +0800 (SGT) Subject: Re: [nemo] WGLC Multihoming Issues: removing "Deployment Scenarios and Prerequisites" ? From: Chan-Wah Ng To: KLAMM Frederic RD-CORE-CAE In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 17:30:27 +0800 Message-Id: <1159176627.982.271.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 25 Sep 2006 09:27:29.0363 (UTC) FILETIME=[D234FA30:01C6E084] X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: ml-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: , Errors-To: nemo-bounces@ietf.org Hello Frederic, Thanks for the comment. I agree with you that the alignment of the 6 listed "benefits and goals" are clearly not on the same level in that one may encompass another, or one may overlap with another. Some are more of a goal (eg. ubiquity), while others are more of a means to achieve goal. It is difficult and often subjective to clearly differentiate between a goal and benefit, which is clearly demonstrated with your comments. =20 However, we are not attempting to do so. We are merely trying to list the possible benefits and goals different people have when deploying a multihomed mobile network. Person A may have the objective of having ubiquity in mind, person B may have the objective of having more bandwidth in mind, and person C may have the objective of being able to choose how each flow is distributed in mind. That's all we are attempting to illustrate. IMHO, there is no value in dissecting the benefits of multihoming into a set of distinct, atomic, constituents. The purpose of Section 3 is to discuss the possible benefits a multihomed NEMO will bring and what is required to achieve these benefits. If without such motivations, then one would question why bother analysing the deployment issues of a multihomed mobile network. /rgds /cwng On Thu, 2006-09-21 at 15:51 +0200, KLAMM Frederic RD-CORE-CAE wrote: > [Sorry for resending: same message as previous, prefixed by "WGLC..." as = required in the LC message] >=20 > WGLC Multihoming Issues: removing "Deployment Scenarios and Prerequisites= " >=20 > Hi all, >=20 > I would simply cut =C2=A73 (that wouldn't affect other parts the draft): > Because : > 1. =C2=A73 is based on assertions of draft-ietf-monami6-multihoming-motiv= ation-scenario-00, which one is a less advanced document (as far as IETF pr= ocess is concerned) and may still change (this is work in progress)! >=20 > 2. It's probably really difficult to find deployment scenarios. But IMHO = the assertions listed bellow (considering their definitions) can't be align= ed as if they were at the same level. > 1. Permanent and Ubiquitous Access > 2. Reliability > 3. Load Sharing > 4. Load Balancing/Flow Distribution > 5. Preference Settings > 6. Aggregate Bandwidth >=20 > 3 and 4 are well-identifiable mechanisms > 2 and 6 are immediate results of using some mechanisms :they are either r= esponses or side-effects (6 is at least a side effect of 3) > 1 is even more abstract, it's rather a global target :=20 > permanency is neared when you obtain 2, 6 and ..., thanks to 3, 4 ...and= others? > ubiquity has been defined relative to mutiple interface technologies, b= ut this is only one step towards the common sense of ubiquity : wherever yo= u are, you get the net. > A quality cellular network on a large given territory offers permanency a= nd ubiquity. And I don't see why a quality mobile IPv6 service wouldn't hav= e the same features in the future, provided that IPv6 is deployed. > This would mean that 1 is nothing but the ultime target of a mobility ser= vice...(?) >=20 > I also see (roughly) {1,2,3,4,6} linked to the base IP mobility service. = And {5} linked to the would-be set of value-added services enriching the ba= se mobility service.=20 > Of course I may have completly misunderstood. In this case, I may not be = the only one? And I'll be glad to have an explanation of why this alignemen= t of assertions is coherent. >=20 > Regards > Frederic >=20 >=20 > =20 > > > -----Message d'origine----- > > > De : Thierry Ernst [mailto:thierry.ernst@inria.fr] Envoy=C3=A9 :=20 > > jeudi 14=20 > > > septembre 2006 13:30 =C3=80 : ml-nemo Objet : [nemo] WGLC Multihoming= =20 > > > Issues > > >=20 > > >=20 > > > Dear all, > > >=20 > > > Authors of > > > Analysis of Multihoming in Network Mobility Support=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihomin > > > g-issues-06.txt > > > have expressed confidence that the document is ready for a NEMO=20 > > > Working Group Last Call. > > >=20 > > > So, please send your comment on the draft between now and the=20 > > > expiration of this WGLC Sept 30. For each new issue you may raise,=20 > > > please pick up a meaningful subject line bearing the prefix "WGLC=20 > > > Multihoming Issues: > > > YOUR_TEXT". > > >=20 > > > Abstract: > > > This document is an analysis of multihoming in the context of=20 > > > network > > > mobility (NEMO) in IPv6. As there are many situations in which > > > mobile networks may be multihomed, a taxonomy is proposed to=20 > > > classify > > > the possible configurations. The possible deployment=20 > > scenarios of > > > multihomed mobile networks are described together with the=20 > > > associated > > > issues when network mobility is supported by RFC 3963 (NEMO Basic > > > Support). Recommendations are offered on how to address these > > > issues. > > >=20 > > >=20 > > > For history purposes, the covered issues are listed and resolved on=20 > > >=20 > > http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ > > > so you may look at that page first before commenting. > > >=20 > > >=20 > > > Thierry. > > >=20 > > >=20 > >=20 > >=20 >=20 From nemo-bounces@ietf.org Mon Sep 25 05:31:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRmoO-00076v-Jn; Mon, 25 Sep 2006 05:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRmoO-00075C-0l for nemo@ietf.org; Mon, 25 Sep 2006 05:31:40 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRmoN-0000wo-DR for nemo@ietf.org; Mon, 25 Sep 2006 05:31:39 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 69742E2B86; Mon, 25 Sep 2006 11:31:38 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp01.uc3m.es (Postfix) with ESMTP id 34C78E2B84; Mon, 25 Sep 2006 11:31:37 +0200 (CEST) In-Reply-To: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 11:32:23 +0200 To: "Eranga Perera" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: ml-nemo WG , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org I am afraid i disagree completelly, I we cannot find users for the RO solutions we shouldn't be working on =20= this and we should close the wg until a real problem is identified. defining solution when we don't have any users that need it, makes no =20= sense to me potential users are the ones that define the problem and provide =20 requirements, not merely opinions. Regards, marcelo El 25/09/2006, a las 10:59, Eranga Perera escribi=F3: > > =A0 > As for opinions from actual users of RO solutions would be good. =20 > However, if such comments are not forthcoming, then I don't think it =20= > is a too difficult task to come up with realistic scenarios and =20 > requirements. > =A0 > The point is by only rechartering for handling geographically =20 > distributed HAs, other cases can not be voiced at all. > =A0 > -eranga > =A0 > =A0 > =A0 > > -----Original Message----- > > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > Sent: Monday, 25 September 2006 6:37 PM > > To: Eranga Perera > > Cc: Alexandru Petrescu; ml-nemo WG; T.J. Kniveton > > Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > > update,continued) > > > > > > El 25/09/2006, a las 10:25, Eranga Perera escribi=F3: > > > > > > > > Marcelo, > > > I fully agree with your suggestion. This way everyone will get a > > > chance to voice out what they think needs addressing within the =20= > scope > > > of RO. > > > > > > > a subtle point here, i would prefer to hear from actual potential =20= > users > > of the RO solutions (like the people from the aviation or car =20 > industry > > or others) rather than random opinions about what different apporach > > should be better in the abstract > > > > i mean, what i would think is that way forward, i to get the =20 > potential > > users, like aviation or car industry, to define their problem and = the > > requirements in an draft and then based on this define solutions for > > the identified problems > > > > that i what i think should be in the charter, itmes to produce > > scenarrios and requiremets for RO > > > > Regards, marcelo > > > > > > > > > Cheers, > > > Eranga > > > > > >> -----Original Message----- > > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > >> Sent: Monday, 25 September 2006 6:16 PM > > >> To: Alexandru Petrescu > > >> Cc: ml-nemo WG; T.J. Kniveton > > >> Subject: Re: RO for geographically dist'd HAs (was: [nemo] = Charter > > >> update,continued) > > >> > > >> My understanding of the comments in the last meeting was that we =20= > were > > >> going _first_ to identify what are the relevant scenarios for =20 > which we > > >> need to design RO solutions and their requirements and only =20 > _after_ > > >> that we are going to work in actual solutions. > > >> > > >> I mean, my recollection of Thierry's suggestion was to have a =20 > first > > >> rechartering where we include items about identifying relevant > > >> scenarios and requirements for RO and when this is done a new > > >> recharter, to include the design of solutions for the identified > > >> scenarios > > >> > > >> As i previously mentioned here, i think it is very hard to =20 > evaluate > > >> how > > >> approapriate a solution is if we don't have explicitly fleshed = out > > >> what > > >> the problem and requiremnets are > > >> > > >> So i would suggest to remove the item > > >> > > >> Submit -00 draft on Route Optimization for geographically =20 > distributed > > >> HAs > > >> > > >> And to include an item about providing a new ID -00 about =20 > identifying > > >> scenarios and requirements for RO > > >> > > >> Regards, marcelo > > >> > > >> > > >> El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: > > >> > > >>> T.J. Kniveton wrote: > > >>>> Hi folks, I'm back.. > > >>>> Here is the current version of the charter. I am still making > > >>>> changes, and need to modify the milestones section. But wanted =20= > to > > >>>> share what's there now and see if there are any comments. > > >>>> Please send comments directly to me, for the moment, and when I = =20 > have > > >>>> the next version we can discuss it on the list. > > >>>> http://www.mobilenetworks.org/nemo/charter2_3.txt > > >>> > > >>> Another remark on the Charter2_3.=A0 It has an item: > > >>> "??? 2006=A0=A0=A0=A0=A0=A0=A0=A0 Submit -00 draft on Route = Optimization for > > >>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = geographically distributed HAs" > > >>> > > >>> However, this is not currently a WG item (so can't be considered = =20 > as > > >>> "finishing ongoing WG documents") and has no other textual > > >>> description > > >>> in charter2_3.=A0 What is it about?=A0 Is it > > >>> draft-wakikawa-mip6-nemo-haha-01.txt or > > >>> draft-wakikawa-mip6-nemo-haha-spec-00? > > >>> > > >>> We've had a long discussion previously about the need and =20 > feasibility > > >>> of > > >>>=A0 HAHA protocols.=A0 There may have been many conclusions, I = don't > > >>> remember > > >>> all. > > >>> > > >>> Alex > > >>> > > >> > > > > > > > > > > > > =20 > = ----------------------------------------------------------------------- > > > --- > > > This email and any attachments may be confidential. They may =20 > contain > > > legally > > > privileged information or copyright material. You should not read, > > > copy, > > > use or disclose them without authorisation. If you are not an =20 > intended > > > recipient, please contact us at once by return email and then =20 > delete > > > both > > > messages. We do not accept liability in connection with computer =20= > virus, > > > data corruption, delay, interruption, unauthorised access or > > > unauthorised > > > amendment. This notice should not be removed. > > > > =A0 From nemo-bounces@ietf.org Mon Sep 25 05:54:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRnA3-0007wm-U6; Mon, 25 Sep 2006 05:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRnA2-0007wh-Rg for nemo@ietf.org; Mon, 25 Sep 2006 05:54:02 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRnA2-0005uC-4a for nemo@ietf.org; Mon, 25 Sep 2006 05:54:02 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k8P9rxCi009535; Mon, 25 Sep 2006 18:53:59 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8P9s0k28009; Mon, 25 Sep 2006 18:54:00 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id k8P9rv510282; Mon, 25 Sep 2006 18:53:57 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 17:48:48 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 2ECEBD4221; Mon, 25 Sep 2006 17:51:48 +0800 (SGT) Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 17:51:47 +0800 Message-Id: <1159177908.982.283.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 25 Sep 2006 09:48:49.0028 (UTC) FILETIME=[CCF25C40:01C6E087] X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org Hello all, I have to disagree on the part of problem definition. The problem has already been defined. The WG has already produced a problem statement draft which has passed WGLC. What is missing, which I do agree, is real requirements. Requirements such as the acceptable signaling overhead, whether the MNNs should be aware of the network mobility, whether the MNNs can implement new functionalities to support a RO solution, etc. Now the car industry may have a set of requirements, the aviation industry may have another set, and the digital broadcast industry may have yet another set. If the world was a prefect ideal one, a single solution would suffice to solve the problem of route optimization and fulfill all requirements. Alas such a world doesn't exist. So, we do the next best thing. We have different types of solution catered for different set of requirements. Selection of the approach can be based on the solution space analysis that the WG has produced. But first, we need to get those requirements. =20 /rgds /cwng On Mon, 2006-09-25 at 11:32 +0200, marcelo bagnulo braun wrote: > I am afraid i disagree completelly, >=20 > I we cannot find users for the RO solutions we shouldn't be working on =20 > this and we should close the wg until a real problem is identified. >=20 > defining solution when we don't have any users that need it, makes no =20 > sense to me >=20 > potential users are the ones that define the problem and provide =20 > requirements, not merely opinions. >=20 > Regards, marcelo >=20 >=20 > El 25/09/2006, a las 10:59, Eranga Perera escribi=C3=B3: >=20 > > > > =20 > > As for opinions from actual users of RO solutions would be good. =20 > > However, if such comments are not forthcoming, then I don't think it =20 > > is a too difficult task to come up with realistic scenarios and =20 > > requirements. > > =20 > > The point is by only rechartering for handling geographically =20 > > distributed HAs, other cases can not be voiced at all. > > =20 > > -eranga > > =20 > > =20 > > =20 > > > -----Original Message----- > > > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > > Sent: Monday, 25 September 2006 6:37 PM > > > To: Eranga Perera > > > Cc: Alexandru Petrescu; ml-nemo WG; T.J. Kniveton > > > Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > > > update,continued) > > > > > > > > > El 25/09/2006, a las 10:25, Eranga Perera escribi=C3=B3: > > > > > > > > > > > Marcelo, > > > > I fully agree with your suggestion. This way everyone will get a > > > > chance to voice out what they think needs addressing within the =20 > > scope > > > > of RO. > > > > > > > > > > a subtle point here, i would prefer to hear from actual potential =20 > > users > > > of the RO solutions (like the people from the aviation or car =20 > > industry > > > or others) rather than random opinions about what different apporach > > > should be better in the abstract > > > > > > i mean, what i would think is that way forward, i to get the =20 > > potential > > > users, like aviation or car industry, to define their problem and the > > > requirements in an draft and then based on this define solutions for > > > the identified problems > > > > > > that i what i think should be in the charter, itmes to produce > > > scenarrios and requiremets for RO > > > > > > Regards, marcelo > > > > > > > > > > > > > Cheers, > > > > Eranga > > > > > > > >> -----Original Message----- > > > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > > >> Sent: Monday, 25 September 2006 6:16 PM > > > >> To: Alexandru Petrescu > > > >> Cc: ml-nemo WG; T.J. Kniveton > > > >> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > > > >> update,continued) > > > >> > > > >> My understanding of the comments in the last meeting was that we =20 > > were > > > >> going _first_ to identify what are the relevant scenarios for =20 > > which we > > > >> need to design RO solutions and their requirements and only =20 > > _after_ > > > >> that we are going to work in actual solutions. > > > >> > > > >> I mean, my recollection of Thierry's suggestion was to have a =20 > > first > > > >> rechartering where we include items about identifying relevant > > > >> scenarios and requirements for RO and when this is done a new > > > >> recharter, to include the design of solutions for the identified > > > >> scenarios > > > >> > > > >> As i previously mentioned here, i think it is very hard to =20 > > evaluate > > > >> how > > > >> approapriate a solution is if we don't have explicitly fleshed out > > > >> what > > > >> the problem and requiremnets are > > > >> > > > >> So i would suggest to remove the item > > > >> > > > >> Submit -00 draft on Route Optimization for geographically =20 > > distributed > > > >> HAs > > > >> > > > >> And to include an item about providing a new ID -00 about =20 > > identifying > > > >> scenarios and requirements for RO > > > >> > > > >> Regards, marcelo > > > >> > > > >> > > > >> El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=C3=B3: > > > >> > > > >>> T.J. Kniveton wrote: > > > >>>> Hi folks, I'm back.. > > > >>>> Here is the current version of the charter. I am still making > > > >>>> changes, and need to modify the milestones section. But wanted =20 > > to > > > >>>> share what's there now and see if there are any comments. > > > >>>> Please send comments directly to me, for the moment, and when I = =20 > > have > > > >>>> the next version we can discuss it on the list. > > > >>>> http://www.mobilenetworks.org/nemo/charter2_3.txt > > > >>> > > > >>> Another remark on the Charter2_3. It has an item: > > > >>> "??? 2006 Submit -00 draft on Route Optimization for > > > >>> geographically distributed HAs" > > > >>> > > > >>> However, this is not currently a WG item (so can't be considered = =20 > > as > > > >>> "finishing ongoing WG documents") and has no other textual > > > >>> description > > > >>> in charter2_3. What is it about? Is it > > > >>> draft-wakikawa-mip6-nemo-haha-01.txt or > > > >>> draft-wakikawa-mip6-nemo-haha-spec-00? > > > >>> > > > >>> We've had a long discussion previously about the need and =20 > > feasibility > > > >>> of > > > >>> HAHA protocols. There may have been many conclusions, I don't > > > >>> remember > > > >>> all. > > > >>> > > > >>> Alex > > > >>> > > > >> > > > > > > > > > > > > > > > > =20 > > ----------------------------------------------------------------------- > > > > --- > > > > This email and any attachments may be confidential. They may =20 > > contain > > > > legally > > > > privileged information or copyright material. You should not read, > > > > copy, > > > > use or disclose them without authorisation. If you are not an =20 > > intended > > > > recipient, please contact us at once by return email and then =20 > > delete > > > > both > > > > messages. We do not accept liability in connection with computer =20 > > virus, > > > > data corruption, delay, interruption, unauthorised access or > > > > unauthorised > > > > amendment. This notice should not be removed. > > > > > > =20 >=20 >=20 From nemo-bounces@ietf.org Mon Sep 25 06:03:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRnIl-0002sB-Pj; Mon, 25 Sep 2006 06:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRnIl-0002s4-2P for nemo@ietf.org; Mon, 25 Sep 2006 06:03:03 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRnIj-00088d-BB for nemo@ietf.org; Mon, 25 Sep 2006 06:03:03 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 28C4A17321; Mon, 25 Sep 2006 12:03:00 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp03.uc3m.es (Postfix) with ESMTP id 4E967174F1; Mon, 25 Sep 2006 12:02:59 +0200 (CEST) In-Reply-To: <1159177908.982.283.camel@localhost> References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 12:03:45 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org El 25/09/2006, a las 11:51, Chan-Wah Ng escribi=F3: > Hello all, > > I have to disagree on the part of problem definition. The problem has > already been defined. The WG has already produced a problem statement > draft which has passed WGLC. you are right of course by problem i was meaning specific problems of the different real cases, =20= since as you mention, the problem space identifed in the RO pb =20 statement draft is simply to wide and many solutions fit as solutions =20= to this problem > > What is missing, which I do agree, is real requirements. Requirements > such as the acceptable signaling overhead, whether the MNNs should be > aware of the network mobility, whether the MNNs can implement new > functionalities to support a RO solution, etc. > > Now the car industry may have a set of requirements, the aviation > industry may have another set, and the digital broadcast industry may > have yet another set. If the world was a prefect ideal one, a single > solution would suffice to solve the problem of route optimization and > fulfill all requirements. Alas such a world doesn't exist. > > So, we do the next best thing. We have different types of solution > catered for different set of requirements. Selection of the approach > can be based on the solution space analysis that the WG has produced. > > But first, we need to get those requirements. exactly, before discussing any solution we need to find real application cases =20= and determine thier requirements only then we can start talking about solutions, because without these =20= use cases and requirements we cannot compare evaluate the ddifferent =20 proposals that are around. Do we agree that identifying use cases and requirements is not a nice =20= to have step but we must do this before start working on solutions? regards, marcelo > > /rgds > /cwng > > On Mon, 2006-09-25 at 11:32 +0200, marcelo bagnulo braun wrote: >> I am afraid i disagree completelly, >> >> I we cannot find users for the RO solutions we shouldn't be working = on >> this and we should close the wg until a real problem is identified. >> >> defining solution when we don't have any users that need it, makes no >> sense to me >> >> potential users are the ones that define the problem and provide >> requirements, not merely opinions. >> >> Regards, marcelo >> >> >> El 25/09/2006, a las 10:59, Eranga Perera escribi=F3: >> >>> >>> >>> As for opinions from actual users of RO solutions would be good. >>> However, if such comments are not forthcoming, then I don't think it >>> is a too difficult task to come up with realistic scenarios and >>> requirements. >>> >>> The point is by only rechartering for handling geographically >>> distributed HAs, other cases can not be voiced at all. >>> >>> -eranga >>> >>> >>> >>>> -----Original Message----- >>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>> Sent: Monday, 25 September 2006 6:37 PM >>>> To: Eranga Perera >>>> Cc: Alexandru Petrescu; ml-nemo WG; T.J. Kniveton >>>> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter >>>> update,continued) >>>> >>>> >>>> El 25/09/2006, a las 10:25, Eranga Perera escribi=F3: >>>> >>>>> >>>>> Marcelo, >>>>> I fully agree with your suggestion. This way everyone will get a >>>>> chance to voice out what they think needs addressing within the >>> scope >>>>> of RO. >>>>> >>>> >>>> a subtle point here, i would prefer to hear from actual potential >>> users >>>> of the RO solutions (like the people from the aviation or car >>> industry >>>> or others) rather than random opinions about what different = apporach >>>> should be better in the abstract >>>> >>>> i mean, what i would think is that way forward, i to get the >>> potential >>>> users, like aviation or car industry, to define their problem and =20= >>>> the >>>> requirements in an draft and then based on this define solutions = for >>>> the identified problems >>>> >>>> that i what i think should be in the charter, itmes to produce >>>> scenarrios and requiremets for RO >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>>> Cheers, >>>>> Eranga >>>>> >>>>>> -----Original Message----- >>>>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>>>> Sent: Monday, 25 September 2006 6:16 PM >>>>>> To: Alexandru Petrescu >>>>>> Cc: ml-nemo WG; T.J. Kniveton >>>>>> Subject: Re: RO for geographically dist'd HAs (was: [nemo] = Charter >>>>>> update,continued) >>>>>> >>>>>> My understanding of the comments in the last meeting was that we >>> were >>>>>> going _first_ to identify what are the relevant scenarios for >>> which we >>>>>> need to design RO solutions and their requirements and only >>> _after_ >>>>>> that we are going to work in actual solutions. >>>>>> >>>>>> I mean, my recollection of Thierry's suggestion was to have a >>> first >>>>>> rechartering where we include items about identifying relevant >>>>>> scenarios and requirements for RO and when this is done a new >>>>>> recharter, to include the design of solutions for the identified >>>>>> scenarios >>>>>> >>>>>> As i previously mentioned here, i think it is very hard to >>> evaluate >>>>>> how >>>>>> approapriate a solution is if we don't have explicitly fleshed = out >>>>>> what >>>>>> the problem and requiremnets are >>>>>> >>>>>> So i would suggest to remove the item >>>>>> >>>>>> Submit -00 draft on Route Optimization for geographically >>> distributed >>>>>> HAs >>>>>> >>>>>> And to include an item about providing a new ID -00 about >>> identifying >>>>>> scenarios and requirements for RO >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: >>>>>> >>>>>>> T.J. Kniveton wrote: >>>>>>>> Hi folks, I'm back.. >>>>>>>> Here is the current version of the charter. I am still making >>>>>>>> changes, and need to modify the milestones section. But wanted >>> to >>>>>>>> share what's there now and see if there are any comments. >>>>>>>> Please send comments directly to me, for the moment, and when I >>> have >>>>>>>> the next version we can discuss it on the list. >>>>>>>> http://www.mobilenetworks.org/nemo/charter2_3.txt >>>>>>> >>>>>>> Another remark on the Charter2_3. It has an item: >>>>>>> "??? 2006 Submit -00 draft on Route Optimization for >>>>>>> geographically distributed HAs" >>>>>>> >>>>>>> However, this is not currently a WG item (so can't be considered >>> as >>>>>>> "finishing ongoing WG documents") and has no other textual >>>>>>> description >>>>>>> in charter2_3. What is it about? Is it >>>>>>> draft-wakikawa-mip6-nemo-haha-01.txt or >>>>>>> draft-wakikawa-mip6-nemo-haha-spec-00? >>>>>>> >>>>>>> We've had a long discussion previously about the need and >>> feasibility >>>>>>> of >>>>>>> HAHA protocols. There may have been many conclusions, I don't >>>>>>> remember >>>>>>> all. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>> = ---------------------------------------------------------------------=20 >>> -- >>>>> --- >>>>> This email and any attachments may be confidential. They may >>> contain >>>>> legally >>>>> privileged information or copyright material. You should not read, >>>>> copy, >>>>> use or disclose them without authorisation. If you are not an >>> intended >>>>> recipient, please contact us at once by return email and then >>> delete >>>>> both >>>>> messages. We do not accept liability in connection with computer >>> virus, >>>>> data corruption, delay, interruption, unauthorised access or >>>>> unauthorised >>>>> amendment. This notice should not be removed. >>>>> >>> >> >> > From nemo-bounces@ietf.org Mon Sep 25 07:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRoIN-0003hd-6k; Mon, 25 Sep 2006 07:06:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRoIM-0003hX-6S for nemo@ietf.org; Mon, 25 Sep 2006 07:06:42 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRoIK-0000nb-I1 for nemo@ietf.org; Mon, 25 Sep 2006 07:06:42 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8PB6bu9025092; Mon, 25 Sep 2006 20:06:37 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8PB6bp09214; Mon, 25 Sep 2006 20:06:37 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k8PB6Yl19982; Mon, 25 Sep 2006 20:06:34 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 19:05:40 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 5552BD4221; Mon, 25 Sep 2006 19:08:40 +0800 (SGT) Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) From: Chan-Wah Ng To: marcelo bagnulo braun In-Reply-To: References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 19:08:39 +0800 Message-Id: <1159182519.982.289.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 25 Sep 2006 11:05:40.0979 (UTC) FILETIME=[89E23C30:01C6E092] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org On Mon, 2006-09-25 at 12:03 +0200, marcelo bagnulo braun wrote: > El 25/09/2006, a las 11:51, Chan-Wah Ng escribi=C3=B3: >=20 > > Hello all, > > > > I have to disagree on the part of problem definition. The problem has > > already been defined. The WG has already produced a problem statement > > draft which has passed WGLC. >=20 > you are right of course >=20 > by problem i was meaning specific problems of the different real cases, =20 > since as you mention, the problem space identifed in the RO pb =20 > statement draft is simply to wide and many solutions fit as solutions =20 > to this problem >=20 > > > > What is missing, which I do agree, is real requirements. Requirements > > such as the acceptable signaling overhead, whether the MNNs should be > > aware of the network mobility, whether the MNNs can implement new > > functionalities to support a RO solution, etc. > > > > Now the car industry may have a set of requirements, the aviation > > industry may have another set, and the digital broadcast industry may > > have yet another set. If the world was a prefect ideal one, a single > > solution would suffice to solve the problem of route optimization and > > fulfill all requirements. Alas such a world doesn't exist. > > > > So, we do the next best thing. We have different types of solution > > catered for different set of requirements. Selection of the approach > > can be based on the solution space analysis that the WG has produced. > > > > But first, we need to get those requirements. >=20 > exactly, >=20 > before discussing any solution we need to find real application cases =20 > and determine thier requirements >=20 > only then we can start talking about solutions, because without these =20 > use cases and requirements we cannot compare evaluate the ddifferent =20 > proposals that are around. >=20 > Do we agree that identifying use cases and requirements is not a nice =20 > to have step but we must do this before start working on solutions? >=20 This I agree ... but haven't Thierry already collected some information from different industries? He presented them in Montreal. I think all we need is to document them in an Internet draft, circulate the draft around the various concerned industries to review the documented requirements. (I think waiting for busy people from these industries to produce a draft on their own would take a long long time. It is better someone write it for them). /rgds /cwng From nemo-bounces@ietf.org Mon Sep 25 08:20:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpR3-0000OV-8C; Mon, 25 Sep 2006 08:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpR1-0000MQ-OQ for nemo@ietf.org; Mon, 25 Sep 2006 08:19:43 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRpQz-0000dp-9g for nemo@ietf.org; Mon, 25 Sep 2006 08:19:43 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 39DD717D56; Mon, 25 Sep 2006 14:19:40 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp03.uc3m.es (Postfix) with ESMTP id A3AAC17D87; Mon, 25 Sep 2006 14:19:38 +0200 (CEST) In-Reply-To: <1159182519.982.289.camel@localhost> References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> <1159182519.982.289.camel@localhost> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <428def2a1fc6efcf3954866504ddf10e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 14:20:24 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org El 25/09/2006, a las 13:08, Chan-Wah Ng escribi=F3: > This I agree ... but haven't Thierry already collected some = information > from different industries? He presented them in Montreal. I think all > we need is to document them in an Internet draft, circulate the draft > around the various concerned industries to review the documented > requirements. (I think waiting for busy people from these industries=20= > to > produce a draft on their own would take a long long time. It is = better > someone write it for them). > Of course i don't have any problem with who is the editor of such=20 documents Just want to be sure that those reflect real problems of real use cases=20= and that we are working in a solution that has potential users. So i=20 agree that the people from the industry that will use the solution=20 don't need to be the editors of the requirements and use cases draft, a=20= heavy involvment from their part is required in order to be sure that=20 this is what is needed. But i think we do have this here in the wg,=20 since several people from the aviation industry has been involved in=20 the discusssions and people from the car industry has also send some=20 emails. Their participation is critical for the usefulness of the=20 outcome of the work done here. so, imho we need a use case descrption and requirements for RO and real=20= users must be involved in the definition of these docuemtns and this is=20= a required before moving into the solution space Regards, marcelo > /rgds > /cwng > From nemo-bounces@ietf.org Mon Sep 25 09:17:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqLA-0008D2-IK; Mon, 25 Sep 2006 09:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqL9-0008Cw-Gd for nemo@ietf.org; Mon, 25 Sep 2006 09:17:43 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqL8-0005kC-2D for nemo@ietf.org; Mon, 25 Sep 2006 09:17:43 -0400 Received: from iseran-2.local (guest-rocq-135145.inria.fr [128.93.135.145]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8PDHUQZ023568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Sep 2006 15:17:31 +0200 Date: Mon, 25 Sep 2006 15:17:36 +0200 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20060925151736.368a398d.thierry.ernst@inria.fr> In-Reply-To: References: Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4517D6EA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [nemo] Charter update: RO between MR and foreign access 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: , Errors-To: nemo-bounces@ietf.org Dear all, I have been involved in some groups working on communication between vehicles and the roadside and vehicle-vehicle communications through the Internet. For their scenarios, 2 RO needs emerge: 1. The MR in the vehicle should be able to communicate with a CN on the roadside without going through the MR-HA tunnel. 2. A MR in a vehicle should be able to communicate with another MR in another vehicle via the Internet infrastructure but packets flowing via the HAs of both MRs should be avoided. May be we could have these listed in the new charter more explicitly. Thierry. On Tue, 19 Sep 2006 19:18:10 -0700 "T.J. Kniveton" wrote: > Hi folks, I'm back.. > > Here is the current version of the charter. I am still making > changes, and need to modify the milestones section. But wanted to > share what's there now and see if there are any comments. > > Please send comments directly to me, for the moment, and when I have > the next version we can discuss it on the list. > > http://www.mobilenetworks.org/nemo/charter2_3.txt > > TJ > -- Thierry ERNST, PhD http://www.nautilus6.org/~thierry IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair -- INRIA Rocquencourt Project-Team IMARA, France. +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Mon Sep 25 09:28:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqVH-0004z4-Cw; Mon, 25 Sep 2006 09:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqVG-0004yz-Dl for nemo@ietf.org; Mon, 25 Sep 2006 09:28:10 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqVF-00070f-6l for nemo@ietf.org; Mon, 25 Sep 2006 09:28:10 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5172989; Mon, 25 Sep 2006 09:28:06 -0400 In-Reply-To: <1159182519.982.289.camel@localhost> References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> <1159182519.982.289.camel@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marshall Eubanks Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 09:27:59 -0400 To: Chan-Wah Ng X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: marcelo bagnulo braun , ml-nemo WG , "T.J. Kniveton" , Alexandru Petrescu , Eranga Perera 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: , Errors-To: nemo-bounces@ietf.org Hello; On Sep 25, 2006, at 7:08 AM, Chan-Wah Ng wrote: > On Mon, 2006-09-25 at 12:03 +0200, marcelo bagnulo braun wrote: >> El 25/09/2006, a las 11:51, Chan-Wah Ng escribi=F3: >> >> before discussing any solution we need to find real application cases >> and determine thier requirements >> >> only then we can start talking about solutions, because without these >> use cases and requirements we cannot compare evaluate the ddifferent >> proposals that are around. >> >> Do we agree that identifying use cases and requirements is not a nice >> to have step but we must do this before start working on solutions? >> > > This I agree ... but haven't Thierry already collected some =20 > information > from different industries? He presented them in Montreal. I think all > we need is to document them in an Internet draft, circulate the draft > around the various concerned industries to review the documented > requirements. (I think waiting for busy people from these =20 > industries to > produce a draft on their own would take a long long time. It is =20 > better > someone write it for them). > > /rgds > /cwng > Was this a presentation ? Is it available somewhere ? I don't see it =20 in the proceedings - or is just the lists on pages 13-14-15 of http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf ? Regards Marshall= From nemo-bounces@ietf.org Mon Sep 25 09:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqa5-0006DM-3U; Mon, 25 Sep 2006 09:33:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqa4-0006DH-AG for nemo@ietf.org; Mon, 25 Sep 2006 09:33:08 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqa1-0007rn-QA for nemo@ietf.org; Mon, 25 Sep 2006 09:33:08 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 024D716F28; Mon, 25 Sep 2006 15:33:05 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp03.uc3m.es (Postfix) with ESMTP id 7EFD616FD3; Mon, 25 Sep 2006 15:33:04 +0200 (CEST) In-Reply-To: <20060925151736.368a398d.thierry.ernst@inria.fr> References: <20060925151736.368a398d.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4b11abb6996a6a8ff66cfd84c037f0cd@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Charter update: RO between MR and foreign access network Date: Mon, 25 Sep 2006 15:33:50 +0200 To: Thierry Ernst X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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: , Errors-To: nemo-bounces@ietf.org Hi Thierry, I thought that the new charter would only be tasked to identify the use=20= cases and requirements and that future rechartering was needed to=20 actually enter in the solution space. At least that was what i understood from your answer in the last=20 meeting when you said: " Thierry: For the new charter, I would have a doc on use-case, and that's=20 it." (from the montreal meeting in the RO discussion) I don't have a problem with dealing with the requirements that you=20 comment, which i guess are valid problems, but my understanding is that=20= we were going to describe these in a docuement that was to be produced=20= and disucssed in the wg, rather than in the charter... My point is, i would include a charter item that is to produce an ID=20 with the use cases (e.g. car industry) and their requirements (e.g.=20 those you mention below) rather than including these requirements in=20 the charter itself. Bottom line is that i guess that the discussion of the requirements=20 should not be part of the charter discusion but part of the=20 requirements/use case ID discussion. Regards, marcelo El 25/09/2006, a las 15:17, Thierry Ernst escribi=F3: > > Dear all, > > I have been involved in some groups working on communication between > vehicles and the roadside and vehicle-vehicle communications through > the Internet. For their scenarios, 2 RO needs emerge: > > 1. The MR in the vehicle should be able to communicate with a CN on = the > roadside without going through the MR-HA tunnel. > > 2. A MR in a vehicle should be able to communicate with another MR in > another vehicle via the Internet infrastructure but packets flowing = via > the HAs of both MRs should be avoided. > > May be we could have these listed in the new charter more explicitly. > > Thierry. > > > > > On Tue, 19 Sep 2006 19:18:10 -0700 > "T.J. Kniveton" wrote: > >> Hi folks, I'm back.. >> >> Here is the current version of the charter. I am still making >> changes, and need to modify the milestones section. But wanted to >> share what's there now and see if there are any comments. >> >> Please send comments directly to me, for the moment, and when I have >> the next version we can discuss it on the list. >> >> http://www.mobilenetworks.org/nemo/charter2_3.txt >> >> TJ >> > > > --=20 > Thierry ERNST, PhD > http://www.nautilus6.org/~thierry > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > -- > INRIA Rocquencourt Project-Team IMARA, France. > +33 1 39 63 59 30 (office) > > From nemo-bounces@ietf.org Mon Sep 25 09:37:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqeL-0000kA-9P; Mon, 25 Sep 2006 09:37:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqeK-0000k0-DV for nemo@ietf.org; Mon, 25 Sep 2006 09:37:32 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqeI-0000Ap-UQ for nemo@ietf.org; Mon, 25 Sep 2006 09:37:32 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 220EB75C6; Mon, 25 Sep 2006 15:37:30 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp03.uc3m.es (Postfix) with ESMTP id 3F80517787; Mon, 25 Sep 2006 15:37:27 +0200 (CEST) In-Reply-To: References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> <1159182519.982.289.camel@localhost> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <17ac37fdb389d7e0c003c558d2c52033@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 15:38:13 +0200 To: Marshall Eubanks X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , Chan-Wah Ng , 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: , Errors-To: nemo-bounces@ietf.org El 25/09/2006, a las 15:27, Marshall Eubanks escribi=F3: > Hello; > > On Sep 25, 2006, at 7:08 AM, Chan-Wah Ng wrote: > >> On Mon, 2006-09-25 at 12:03 +0200, marcelo bagnulo braun wrote: >>> El 25/09/2006, a las 11:51, Chan-Wah Ng escribi=F3: >>> > >>> before discussing any solution we need to find real application = cases >>> and determine thier requirements >>> >>> only then we can start talking about solutions, because without = these >>> use cases and requirements we cannot compare evaluate the ddifferent >>> proposals that are around. >>> >>> Do we agree that identifying use cases and requirements is not a = nice >>> to have step but we must do this before start working on solutions? >>> >> >> This I agree ... but haven't Thierry already collected some=20 >> information >> from different industries? He presented them in Montreal. I think = all >> we need is to document them in an Internet draft, circulate the draft >> around the various concerned industries to review the documented >> requirements. (I think waiting for busy people from these industries=20= >> to >> produce a draft on their own would take a long long time. It is=20 >> better >> someone write it for them). >> >> /rgds >> /cwng >> > > > Was this a presentation ? Is it available somewhere ? I don't see it=20= > in the proceedings - > or is just the lists on pages 13-14-15 of > http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf ? i guess this is it but there was also a nice email with requirements from the aviation=20 industry from Terry Davis from Boeing, but i guess they never put it as=20= an ID :-( the original message is=20 http://www1.ietf.org/mail-archive/web/nemo/current/msg03299.html regards, marcelo > > Regards > Marshall From nemo-bounces@ietf.org Mon Sep 25 09:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqn7-0003cU-39; Mon, 25 Sep 2006 09:46:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqn5-0003cO-NL for nemo@ietf.org; Mon, 25 Sep 2006 09:46:35 -0400 Received: from motgate6.mot.com ([129.188.136.10] helo=motgate.mot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqn4-0001xv-EJ for nemo@ietf.org; Mon, 25 Sep 2006 09:46:35 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id k8PDiNUg018658; Mon, 25 Sep 2006 06:44:28 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k8PDfAWV012632; Mon, 25 Sep 2006 08:41:15 -0500 (CDT) Message-ID: <4517DC72.5040006@motorola.com> Date: Mon, 25 Sep 2006 15:41:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> <1159182519.982.289.camel@localhost> In-Reply-To: <1159182519.982.289.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate.mot.com id k8PDiNUg018658 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: marcelo bagnulo braun , Eranga Perera , "T.J. Kniveton" , ml-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: , Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > On Mon, 2006-09-25 at 12:03 +0200, marcelo bagnulo braun wrote: >> El 25/09/2006, a las 11:51, Chan-Wah Ng escribi=C3=B3: >> >>> Hello all, >>> >>> I have to disagree on the part of problem definition. The problem ha= s >>> already been defined. The WG has already produced a problem statemen= t >>> draft which has passed WGLC. >> you are right of course >> >> by problem i was meaning specific problems of the different real cases= , =20 >> since as you mention, the problem space identifed in the RO pb =20 >> statement draft is simply to wide and many solutions fit as solutions = =20 >> to this problem >> >>> What is missing, which I do agree, is real requirements. Requirement= s >>> such as the acceptable signaling overhead, whether the MNNs should be >>> aware of the network mobility, whether the MNNs can implement new >>> functionalities to support a RO solution, etc. >>> >>> Now the car industry may have a set of requirements, the aviation >>> industry may have another set, and the digital broadcast industry may >>> have yet another set. If the world was a prefect ideal one, a single >>> solution would suffice to solve the problem of route optimization and >>> fulfill all requirements. Alas such a world doesn't exist. >>> >>> So, we do the next best thing. We have different types of solution >>> catered for different set of requirements. Selection of the approach >>> can be based on the solution space analysis that the WG has produced. >>> >>> But first, we need to get those requirements. >> exactly, >> >> before discussing any solution we need to find real application cases = =20 >> and determine thier requirements >> >> only then we can start talking about solutions, because without these = =20 >> use cases and requirements we cannot compare evaluate the ddifferent =20 >> proposals that are around. >> >> Do we agree that identifying use cases and requirements is not a nice = =20 >> to have step but we must do this before start working on solutions? >> >=20 > This I agree ... but haven't Thierry already collected some information > from different industries? He presented them in Montreal. Yes, it's at http://www.mobilenetworks.org/nemo/ietf66/nemo-ietf66-slides.pdf pp 12-15 Alex From nemo-bounces@ietf.org Mon Sep 25 09:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqvw-0000QJ-Kc; Mon, 25 Sep 2006 09:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqvu-0000QE-W2 for nemo@ietf.org; Mon, 25 Sep 2006 09:55:42 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqvt-0003ZM-GP for nemo@ietf.org; Mon, 25 Sep 2006 09:55:42 -0400 Received: from iseran-2.local (guest-rocq-135145.inria.fr [128.93.135.145]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8PDtefp031830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Sep 2006 15:55:40 +0200 Date: Mon, 25 Sep 2006 15:55:45 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Charter update: RO between MR and foreign access network Message-Id: <20060925155545.413f5937.thierry.ernst@inria.fr> In-Reply-To: <4b11abb6996a6a8ff66cfd84c037f0cd@it.uc3m.es> References: <20060925151736.368a398d.thierry.ernst@inria.fr> <4b11abb6996a6a8ff66cfd84c037f0cd@it.uc3m.es> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-j-chkmail-Score: MSGID : 4517DFDC.000 on concorde : j-chkmail score : XX : 5/20 0 X-Miltered: at concorde with ID 4517DFDC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id k8PDtefp031830 X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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: , Errors-To: nemo-bounces@ietf.org Hi Marcelo, True, that was my intention at first but it was also pointed out that TJ's draft charter was a good start and that we should detail it further and be more explicit. The RO problem is already discussed in the 2 drafts, so I think it is well understood enough. Regarding the use cases, these would surely help, but it appears that what is needed by the aviation industry is pretty far from NEMO Basic Support (i.e. not a mere optimization) and the car industry is still in the process of trying to understand what the IETF is (a bit like 3GPP a while ago if you see what I mean) so I wouldn't expect them to come up with a clear description of the use cases in the next 2 years (though they [=3Dsome organizations like ISO] DO work on an architecture based on NEMO and IPv6 but are still far from understanding the IETF folks could help and save them some mistakes in their architecture). So, with respect to what you concluded below, the new charter could list as deliverable a use case documents (but it is most likely to be produced by us targetted the organizations such as ISO than the other way round) and some solutions for the RO problem in which we have identified needs (the 2 I listed), which are reasonably easy to solve, and for which we possibly have candidate solutions. Thierry On Mon, 25 Sep 2006 15:33:50 +0200 marcelo bagnulo braun wrote: > Hi Thierry, >=20 > I thought that the new charter would only be tasked to identify the use= =20 > cases and requirements and that future rechartering was needed to=20 > actually enter in the solution space. >=20 > At least that was what i understood from your answer in the last=20 > meeting when you said: >=20 > " Thierry: > For the new charter, I would have a doc on use-case, and that's=20 > it." >=20 > (from the montreal meeting in the RO discussion) >=20 > I don't have a problem with dealing with the requirements that you=20 > comment, which i guess are valid problems, but my understanding is that= =20 > we were going to describe these in a docuement that was to be produced=20 > and disucssed in the wg, rather than in the charter... >=20 > My point is, i would include a charter item that is to produce an ID=20 > with the use cases (e.g. car industry) and their requirements (e.g.=20 > those you mention below) rather than including these requirements in=20 > the charter itself. >=20 > Bottom line is that i guess that the discussion of the requirements=20 > should not be part of the charter discusion but part of the=20 > requirements/use case ID discussion. >=20 > Regards, marcelo >=20 >=20 > El 25/09/2006, a las 15:17, Thierry Ernst escribi=F3: >=20 > > > > Dear all, > > > > I have been involved in some groups working on communication between > > vehicles and the roadside and vehicle-vehicle communications through > > the Internet. For their scenarios, 2 RO needs emerge: > > > > 1. The MR in the vehicle should be able to communicate with a CN on t= he > > roadside without going through the MR-HA tunnel. > > > > 2. A MR in a vehicle should be able to communicate with another MR in > > another vehicle via the Internet infrastructure but packets flowing v= ia > > the HAs of both MRs should be avoided. > > > > May be we could have these listed in the new charter more explicitly. > > > > Thierry. > > > > > > > > > > On Tue, 19 Sep 2006 19:18:10 -0700 > > "T.J. Kniveton" wrote: > > > >> Hi folks, I'm back.. > >> > >> Here is the current version of the charter. I am still making > >> changes, and need to modify the milestones section. But wanted to > >> share what's there now and see if there are any comments. > >> > >> Please send comments directly to me, for the moment, and when I have > >> the next version we can discuss it on the list. > >> > >> http://www.mobilenetworks.org/nemo/charter2_3.txt > >> > >> TJ > >> > > > > > > --=20 > > Thierry ERNST, PhD > > http://www.nautilus6.org/~thierry > > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > > -- > > INRIA Rocquencourt Project-Team IMARA, France. > > +33 1 39 63 59 30 (office) > > > > >=20 >=20 >=20 --=20 Thierry ERNST, PhD http://www.nautilus6.org/~thierry IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair -- INRIA Rocquencourt Project-Team IMARA, France. +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Mon Sep 25 10:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRr4W-0005x9-Nz; Mon, 25 Sep 2006 10:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRr4V-0005x1-LT for nemo@ietf.org; Mon, 25 Sep 2006 10:04:35 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRr4R-0005AW-46 for nemo@ietf.org; Mon, 25 Sep 2006 10:04:35 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k8PE4O2l000058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Sep 2006 07:04:30 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k8PE4Ofg025301 for ; Mon, 25 Sep 2006 07:04:24 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k8PE4GGe025010; Mon, 25 Sep 2006 07:04:24 -0700 (PDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 07:04:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 07:04:22 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD2763@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Thread-Index: AcbghW7/nrCw+6XMR76C5cd/knhtjAAJV27w From: "Davis, Terry L" To: "marcelo bagnulo braun" , "Eranga Perera" X-OriginalArrivalTime: 25 Sep 2006 14:04:23.0386 (UTC) FILETIME=[80EFB3A0:01C6E0AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: ml-nemo WG , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org Marcelo Any of the future communication systems for globally mobile systems = (like aircraft and ships) that use satellites and multiple ground = stations must have RO! This will be especially true if future air = traffic control systems use IP as we expect. =20 Take care Terry > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Monday, September 25, 2006 2:32 AM > To: Eranga Perera > Cc: ml-nemo WG; T.J. Kniveton; Alexandru Petrescu > Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > update,continued) >=20 > I am afraid i disagree completelly, >=20 > I we cannot find users for the RO solutions we shouldn't be working on > this and we should close the wg until a real problem is identified. >=20 > defining solution when we don't have any users that need it, makes no > sense to me >=20 > potential users are the ones that define the problem and provide > requirements, not merely opinions. >=20 > Regards, marcelo >=20 >=20 > El 25/09/2006, a las 10:59, Eranga Perera escribi=F3: >=20 > > > > > > As for opinions from actual users of RO solutions would be good. > > However, if such comments are not forthcoming, then I don't think it > > is a too difficult task to come up with realistic scenarios and > > requirements. > > > > The point is by only rechartering for handling geographically > > distributed HAs, other cases can not be voiced at all. > > > > -eranga > > > > > > > > > -----Original Message----- > > > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > > Sent: Monday, 25 September 2006 6:37 PM > > > To: Eranga Perera > > > Cc: Alexandru Petrescu; ml-nemo WG; T.J. Kniveton > > > Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > > > update,continued) > > > > > > > > > El 25/09/2006, a las 10:25, Eranga Perera escribi=F3: > > > > > > > > > > > Marcelo, > > > > I fully agree with your suggestion. This way everyone will get a > > > > chance to voice out what they think needs addressing within the > > scope > > > > of RO. > > > > > > > > > > a subtle point here, i would prefer to hear from actual potential > > users > > > of the RO solutions (like the people from the aviation or car > > industry > > > or others) rather than random opinions about what different = apporach > > > should be better in the abstract > > > > > > i mean, what i would think is that way forward, i to get the > > potential > > > users, like aviation or car industry, to define their problem and = the > > > requirements in an draft and then based on this define solutions = for > > > the identified problems > > > > > > that i what i think should be in the charter, itmes to produce > > > scenarrios and requiremets for RO > > > > > > Regards, marcelo > > > > > > > > > > > > > Cheers, > > > > Eranga > > > > > > > >> -----Original Message----- > > > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > > >> Sent: Monday, 25 September 2006 6:16 PM > > > >> To: Alexandru Petrescu > > > >> Cc: ml-nemo WG; T.J. Kniveton > > > >> Subject: Re: RO for geographically dist'd HAs (was: [nemo] = Charter > > > >> update,continued) > > > >> > > > >> My understanding of the comments in the last meeting was that = we > > were > > > >> going _first_ to identify what are the relevant scenarios for > > which we > > > >> need to design RO solutions and their requirements and only > > _after_ > > > >> that we are going to work in actual solutions. > > > >> > > > >> I mean, my recollection of Thierry's suggestion was to have a > > first > > > >> rechartering where we include items about identifying relevant > > > >> scenarios and requirements for RO and when this is done a new > > > >> recharter, to include the design of solutions for the = identified > > > >> scenarios > > > >> > > > >> As i previously mentioned here, i think it is very hard to > > evaluate > > > >> how > > > >> approapriate a solution is if we don't have explicitly fleshed = out > > > >> what > > > >> the problem and requiremnets are > > > >> > > > >> So i would suggest to remove the item > > > >> > > > >> Submit -00 draft on Route Optimization for geographically > > distributed > > > >> HAs > > > >> > > > >> And to include an item about providing a new ID -00 about > > identifying > > > >> scenarios and requirements for RO > > > >> > > > >> Regards, marcelo > > > >> > > > >> > > > >> El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: > > > >> > > > >>> T.J. Kniveton wrote: > > > >>>> Hi folks, I'm back.. > > > >>>> Here is the current version of the charter. I am still making > > > >>>> changes, and need to modify the milestones section. But = wanted > > to > > > >>>> share what's there now and see if there are any comments. > > > >>>> Please send comments directly to me, for the moment, and when = I > > have > > > >>>> the next version we can discuss it on the list. > > > >>>> http://www.mobilenetworks.org/nemo/charter2_3.txt > > > >>> > > > >>> Another remark on the Charter2_3.=A0 It has an item: > > > >>> "??? 2006=A0=A0=A0=A0=A0=A0=A0=A0 Submit -00 draft on Route = Optimization for > > > >>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = geographically distributed HAs" > > > >>> > > > >>> However, this is not currently a WG item (so can't be = considered > > as > > > >>> "finishing ongoing WG documents") and has no other textual > > > >>> description > > > >>> in charter2_3.=A0 What is it about?=A0 Is it > > > >>> draft-wakikawa-mip6-nemo-haha-01.txt or > > > >>> draft-wakikawa-mip6-nemo-haha-spec-00? > > > >>> > > > >>> We've had a long discussion previously about the need and > > feasibility > > > >>> of > > > >>>=A0 HAHA protocols.=A0 There may have been many conclusions, I = don't > > > >>> remember > > > >>> all. > > > >>> > > > >>> Alex > > > >>> > > > >> > > > > > > > > > > > > > > > > > > = ----------------------------------------------------------------------- > > > > --- > > > > This email and any attachments may be confidential. They may > > contain > > > > legally > > > > privileged information or copyright material. You should not = read, > > > > copy, > > > > use or disclose them without authorisation. If you are not an > > intended > > > > recipient, please contact us at once by return email and then > > delete > > > > both > > > > messages. We do not accept liability in connection with computer > > virus, > > > > data corruption, delay, interruption, unauthorised access or > > > > unauthorised > > > > amendment. This notice should not be removed. > > > > > > >=20 From nemo-bounces@ietf.org Mon Sep 25 10:07:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRr7H-0006Se-1U; Mon, 25 Sep 2006 10:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRr7F-0006SX-NG for nemo@ietf.org; Mon, 25 Sep 2006 10:07:25 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRr7E-0005cB-Cc for nemo@ietf.org; Mon, 25 Sep 2006 10:07:25 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k8PE6qBG020692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Sep 2006 07:06:53 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k8PE7LFv024176 for ; Mon, 25 Sep 2006 09:07:21 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k8PE7Hjj024048; Mon, 25 Sep 2006 09:07:20 -0500 (CDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 07:07:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 07:07:18 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A01BD2764@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <428def2a1fc6efcf3954866504ddf10e@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Thread-Index: AcbgnSK97W+hR/WiQVmCrhh5V6wTJQADo78w From: "Davis, Terry L" To: "marcelo bagnulo braun" , "Chan-Wah Ng" X-OriginalArrivalTime: 25 Sep 2006 14:07:19.0156 (UTC) FILETIME=[E9B41340:01C6E0AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org Marcelo Two documents from the aviation industry should be available in drafts = this week. A requirements document and a problem statement. I will = post the links when they are available. Take care Terry > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Monday, September 25, 2006 5:20 AM > To: Chan-Wah Ng > Cc: ml-nemo WG; Eranga Perera; T.J. Kniveton; Alexandru Petrescu > Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > update,continued) >=20 >=20 > El 25/09/2006, a las 13:08, Chan-Wah Ng escribi=F3: >=20 > > This I agree ... but haven't Thierry already collected some = information > > from different industries? He presented them in Montreal. I think = all > > we need is to document them in an Internet draft, circulate the = draft > > around the various concerned industries to review the documented > > requirements. (I think waiting for busy people from these = industries > > to > > produce a draft on their own would take a long long time. It is = better > > someone write it for them). > > > Of course i don't have any problem with who is the editor of such > documents >=20 > Just want to be sure that those reflect real problems of real use = cases > and that we are working in a solution that has potential users. So i > agree that the people from the industry that will use the solution > don't need to be the editors of the requirements and use cases draft, = a > heavy involvment from their part is required in order to be sure that > this is what is needed. But i think we do have this here in the wg, > since several people from the aviation industry has been involved in > the discusssions and people from the car industry has also send some > emails. Their participation is critical for the usefulness of the > outcome of the work done here. >=20 > so, imho we need a use case descrption and requirements for RO and = real > users must be involved in the definition of these docuemtns and this = is > a required before moving into the solution space >=20 > Regards, marcelo >=20 > > /rgds > > /cwng > > >=20 From nemo-bounces@ietf.org Mon Sep 25 10:12:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrBm-0007LH-G1; Mon, 25 Sep 2006 10:12:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrBl-0007KZ-94 for nemo@ietf.org; Mon, 25 Sep 2006 10:12:05 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrBj-0006HP-I9 for nemo@ietf.org; Mon, 25 Sep 2006 10:12:05 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A1F51179E7; Mon, 25 Sep 2006 16:12:00 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp03.uc3m.es (Postfix) with ESMTP id D9F45179D5; Mon, 25 Sep 2006 16:11:59 +0200 (CEST) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A01BD2763@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A01BD2763@XCH-NW-8V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <325254775525d59de595c2a78dce28a8@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 16:12:46 +0200 To: "Davis, Terry L" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org Terry, El 25/09/2006, a las 16:04, Davis, Terry L escribi=F3: > Marcelo > > Any of the future communication systems for globally mobile systems =20= > (like aircraft and ships) that use satellites and multiple ground =20 > stations must have RO! i compeltelly agree with this my only point is that before working on a solution, we need the =20 potential users to flesh out the requirements, so we can design a =20 proper soltion. If not, we may define a solution that does not solve =20 your problems and also it will be very hard to choose among the dozens =20= of proposed solutions that are around so, i am looking forward to work in this problem, just want to have a =20= clear problem definition for the particular cases and their =20 requirements So, i don't think we disagree here... Regards, marcelo > This will be especially true if future air traffic control systems =20= > use IP as we expect. > > Take care > Terry > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, September 25, 2006 2:32 AM >> To: Eranga Perera >> Cc: ml-nemo WG; T.J. Kniveton; Alexandru Petrescu >> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter >> update,continued) >> >> I am afraid i disagree completelly, >> >> I we cannot find users for the RO solutions we shouldn't be working = on >> this and we should close the wg until a real problem is identified. >> >> defining solution when we don't have any users that need it, makes no >> sense to me >> >> potential users are the ones that define the problem and provide >> requirements, not merely opinions. >> >> Regards, marcelo >> >> >> El 25/09/2006, a las 10:59, Eranga Perera escribi=F3: >> >>> >>> >>> As for opinions from actual users of RO solutions would be good. >>> However, if such comments are not forthcoming, then I don't think it >>> is a too difficult task to come up with realistic scenarios and >>> requirements. >>> >>> The point is by only rechartering for handling geographically >>> distributed HAs, other cases can not be voiced at all. >>> >>> -eranga >>> >>> >>> >>>> -----Original Message----- >>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>> Sent: Monday, 25 September 2006 6:37 PM >>>> To: Eranga Perera >>>> Cc: Alexandru Petrescu; ml-nemo WG; T.J. Kniveton >>>> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter >>>> update,continued) >>>> >>>> >>>> El 25/09/2006, a las 10:25, Eranga Perera escribi=F3: >>>> >>>>> >>>>> Marcelo, >>>>> I fully agree with your suggestion. This way everyone will get a >>>>> chance to voice out what they think needs addressing within the >>> scope >>>>> of RO. >>>>> >>>> >>>> a subtle point here, i would prefer to hear from actual potential >>> users >>>> of the RO solutions (like the people from the aviation or car >>> industry >>>> or others) rather than random opinions about what different = apporach >>>> should be better in the abstract >>>> >>>> i mean, what i would think is that way forward, i to get the >>> potential >>>> users, like aviation or car industry, to define their problem and =20= >>>> the >>>> requirements in an draft and then based on this define solutions = for >>>> the identified problems >>>> >>>> that i what i think should be in the charter, itmes to produce >>>> scenarrios and requiremets for RO >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>>> Cheers, >>>>> Eranga >>>>> >>>>>> -----Original Message----- >>>>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>>>> Sent: Monday, 25 September 2006 6:16 PM >>>>>> To: Alexandru Petrescu >>>>>> Cc: ml-nemo WG; T.J. Kniveton >>>>>> Subject: Re: RO for geographically dist'd HAs (was: [nemo] = Charter >>>>>> update,continued) >>>>>> >>>>>> My understanding of the comments in the last meeting was that we >>> were >>>>>> going _first_ to identify what are the relevant scenarios for >>> which we >>>>>> need to design RO solutions and their requirements and only >>> _after_ >>>>>> that we are going to work in actual solutions. >>>>>> >>>>>> I mean, my recollection of Thierry's suggestion was to have a >>> first >>>>>> rechartering where we include items about identifying relevant >>>>>> scenarios and requirements for RO and when this is done a new >>>>>> recharter, to include the design of solutions for the identified >>>>>> scenarios >>>>>> >>>>>> As i previously mentioned here, i think it is very hard to >>> evaluate >>>>>> how >>>>>> approapriate a solution is if we don't have explicitly fleshed = out >>>>>> what >>>>>> the problem and requiremnets are >>>>>> >>>>>> So i would suggest to remove the item >>>>>> >>>>>> Submit -00 draft on Route Optimization for geographically >>> distributed >>>>>> HAs >>>>>> >>>>>> And to include an item about providing a new ID -00 about >>> identifying >>>>>> scenarios and requirements for RO >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: >>>>>> >>>>>>> T.J. Kniveton wrote: >>>>>>>> Hi folks, I'm back.. >>>>>>>> Here is the current version of the charter. I am still making >>>>>>>> changes, and need to modify the milestones section. But wanted >>> to >>>>>>>> share what's there now and see if there are any comments. >>>>>>>> Please send comments directly to me, for the moment, and when I >>> have >>>>>>>> the next version we can discuss it on the list. >>>>>>>> http://www.mobilenetworks.org/nemo/charter2_3.txt >>>>>>> >>>>>>> Another remark on the Charter2_3.=A0 It has an item: >>>>>>> "??? 2006=A0=A0=A0=A0=A0=A0=A0=A0 Submit -00 draft on Route = Optimization for >>>>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = geographically distributed HAs" >>>>>>> >>>>>>> However, this is not currently a WG item (so can't be considered >>> as >>>>>>> "finishing ongoing WG documents") and has no other textual >>>>>>> description >>>>>>> in charter2_3.=A0 What is it about?=A0 Is it >>>>>>> draft-wakikawa-mip6-nemo-haha-01.txt or >>>>>>> draft-wakikawa-mip6-nemo-haha-spec-00? >>>>>>> >>>>>>> We've had a long discussion previously about the need and >>> feasibility >>>>>>> of >>>>>>> =A0 HAHA protocols.=A0 There may have been many conclusions, I = don't >>>>>>> remember >>>>>>> all. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>> = ---------------------------------------------------------------------=20 >>> -- >>>>> --- >>>>> This email and any attachments may be confidential. They may >>> contain >>>>> legally >>>>> privileged information or copyright material. You should not read, >>>>> copy, >>>>> use or disclose them without authorisation. If you are not an >>> intended >>>>> recipient, please contact us at once by return email and then >>> delete >>>>> both >>>>> messages. We do not accept liability in connection with computer >>> virus, >>>>> data corruption, delay, interruption, unauthorised access or >>>>> unauthorised >>>>> amendment. This notice should not be removed. >>>>> >>> >> > > From nemo-bounces@ietf.org Mon Sep 25 10:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrDF-0007kZ-NE; Mon, 25 Sep 2006 10:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrDE-0007kC-EF for nemo@ietf.org; Mon, 25 Sep 2006 10:13:36 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrDC-0006jD-VL for nemo@ietf.org; Mon, 25 Sep 2006 10:13:36 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5DA7F17B99; Mon, 25 Sep 2006 16:13:34 +0200 (CEST) Received: from [163.117.203.143] (unknown [163.117.203.143]) by smtp03.uc3m.es (Postfix) with ESMTP id 5E5A817A6E; Mon, 25 Sep 2006 16:13:32 +0200 (CEST) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A01BD2764@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A01BD2764@XCH-NW-8V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0eb99f052dc288189043a2a880a00ad1@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 16:14:19 +0200 To: "Davis, Terry L" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , Chan-Wah Ng , 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: , Errors-To: nemo-bounces@ietf.org Great, this is what i looking for i hope we can put an explicit charter item for this documents (yours or=20= similar ones if many are available, but i doubt it) Regards, marcelo El 25/09/2006, a las 16:07, Davis, Terry L escribi=F3: > Marcelo > > Two documents from the aviation industry should be available in drafts=20= > this week. A requirements document and a problem statement. I will=20= > post the links when they are available. > > Take care > Terry > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, September 25, 2006 5:20 AM >> To: Chan-Wah Ng >> Cc: ml-nemo WG; Eranga Perera; T.J. Kniveton; Alexandru Petrescu >> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter >> update,continued) >> >> >> El 25/09/2006, a las 13:08, Chan-Wah Ng escribi=F3: >> >>> This I agree ... but haven't Thierry already collected some=20 >>> information >>> from different industries? He presented them in Montreal. I think=20= >>> all >>> we need is to document them in an Internet draft, circulate the = draft >>> around the various concerned industries to review the documented >>> requirements. (I think waiting for busy people from these = industries >>> to >>> produce a draft on their own would take a long long time. It is=20 >>> better >>> someone write it for them). >>> >> Of course i don't have any problem with who is the editor of such >> documents >> >> Just want to be sure that those reflect real problems of real use=20 >> cases >> and that we are working in a solution that has potential users. So i >> agree that the people from the industry that will use the solution >> don't need to be the editors of the requirements and use cases draft,=20= >> a >> heavy involvment from their part is required in order to be sure that >> this is what is needed. But i think we do have this here in the wg, >> since several people from the aviation industry has been involved in >> the discusssions and people from the car industry has also send some >> emails. Their participation is critical for the usefulness of the >> outcome of the work done here. >> >> so, imho we need a use case descrption and requirements for RO and=20 >> real >> users must be involved in the definition of these docuemtns and this=20= >> is >> a required before moving into the solution space >> >> Regards, marcelo >> >>> /rgds >>> /cwng >>> >> > > From nemo-bounces@ietf.org Mon Sep 25 11:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsN1-0000jm-0R; Mon, 25 Sep 2006 11:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsMz-0000j5-Ff for nemo@ietf.org; Mon, 25 Sep 2006 11:27:45 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsMc-0007BD-GZ for nemo@ietf.org; Mon, 25 Sep 2006 11:27:45 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id k8PFMUkf003797; Mon, 25 Sep 2006 08:27:17 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k8PDfAWV012632; Mon, 25 Sep 2006 08:41:15 -0500 (CDT) Message-ID: <4517DC72.5040006@motorola.com> Date: Mon, 25 Sep 2006 15:41:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> <1159182519.982.289.camel@localhost> In-Reply-To: <1159182519.982.289.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate4.mot.com id k8PFMUkf003797 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: marcelo bagnulo braun , Eranga Perera , "T.J. Kniveton" , ml-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: , Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > On Mon, 2006-09-25 at 12:03 +0200, marcelo bagnulo braun wrote: >> El 25/09/2006, a las 11:51, Chan-Wah Ng escribi=C3=B3: >> >>> Hello all, >>> >>> I have to disagree on the part of problem definition. The problem ha= s >>> already been defined. The WG has already produced a problem statemen= t >>> draft which has passed WGLC. >> you are right of course >> >> by problem i was meaning specific problems of the different real cases= , =20 >> since as you mention, the problem space identifed in the RO pb =20 >> statement draft is simply to wide and many solutions fit as solutions = =20 >> to this problem >> >>> What is missing, which I do agree, is real requirements. Requirement= s >>> such as the acceptable signaling overhead, whether the MNNs should be >>> aware of the network mobility, whether the MNNs can implement new >>> functionalities to support a RO solution, etc. >>> >>> Now the car industry may have a set of requirements, the aviation >>> industry may have another set, and the digital broadcast industry may >>> have yet another set. If the world was a prefect ideal one, a single >>> solution would suffice to solve the problem of route optimization and >>> fulfill all requirements. Alas such a world doesn't exist. >>> >>> So, we do the next best thing. We have different types of solution >>> catered for different set of requirements. Selection of the approach >>> can be based on the solution space analysis that the WG has produced. >>> >>> But first, we need to get those requirements. >> exactly, >> >> before discussing any solution we need to find real application cases = =20 >> and determine thier requirements >> >> only then we can start talking about solutions, because without these = =20 >> use cases and requirements we cannot compare evaluate the ddifferent =20 >> proposals that are around. >> >> Do we agree that identifying use cases and requirements is not a nice = =20 >> to have step but we must do this before start working on solutions? >> >=20 > This I agree ... but haven't Thierry already collected some information > from different industries? He presented them in Montreal. Yes, it's at http://www.mobilenetworks.org/nemo/ietf66/nemo-ietf66-slides.pdf pp 12-15 Alex From nemo-bounces@ietf.org Mon Sep 25 12:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsvF-0000xM-8V; Mon, 25 Sep 2006 12:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsvE-0000wa-3y for nemo@ietf.org; Mon, 25 Sep 2006 12:03:08 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsvC-0003g6-8i for nemo@ietf.org; Mon, 25 Sep 2006 12:03:08 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1DC46E28DC; Mon, 25 Sep 2006 18:03:05 +0200 (CEST) Received: from [163.117.203.117] (unknown [163.117.203.117]) by smtp01.uc3m.es (Postfix) with ESMTP id 6A658E250C; Mon, 25 Sep 2006 18:03:04 +0200 (CEST) In-Reply-To: <20060925155545.413f5937.thierry.ernst@inria.fr> References: <20060925151736.368a398d.thierry.ernst@inria.fr> <4b11abb6996a6a8ff66cfd84c037f0cd@it.uc3m.es> <20060925155545.413f5937.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <41bbb7e8ce1bbaaf2ab2dc4bec19a71f@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Charter update: RO between MR and foreign access network Date: Mon, 25 Sep 2006 18:03:50 +0200 To: Thierry Ernst X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: ml-nemo WG , Hesham Soliman 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: , Errors-To: nemo-bounces@ietf.org El 25/09/2006, a las 15:55, Thierry Ernst escribi=F3: > > Hi Marcelo, > > True, that was my intention at first but it was also pointed out that > it is unfortunate that you have changed your mind... i thought there=20 was concesous in the meeting about following this approach (at least=20 the 3 people that commented seemed to agree with this approach, Jari,=20 Hesham (ccopied) and myself) > TJ's draft charter was a good start and that we should detail it=20 > further > and be more explicit. > > The RO problem is already discussed in the 2 drafts, so I think it is > well understood enough. > i agree that the problems resulting from not having RO are well=20 understood and also i think it is understood that there are many=20 solutions that provide different sets of features and deal with=20 differents parts of the problems resulting from not having RO it is also clear imho that no one size fit all solution to deal with=20 all the issues i guess that we also agree that we are not going to standarize alll the=20= existent proposals (i guess there are over 20 nemo RO proposals) so, how do we choose which solutions to standarize? a reasonable approach was to identify relevant use cases and provide=20 solutions for these. that is to define requirements for those use cases=20= that have potential users and then use these requirements as a=20 selection criteria to define which solutions to standarize but if we don't produce these requirements then we don't know which=20 solution we need so how do we proceed in this case? I guess that all the people that has proposed a solution has a=20 different idea of what is important and they have produced a solution=20 folloing these things they consider that are relevant. So each solution=20= will be superior to the others if the particular features provided are=20= considered relevant > Regarding the use cases, these would surely help, but it appears that > what is needed by the aviation industry is pretty far from NEMO Basic > Support (i.e. not a mere optimization) i dont see why this is a problem i mean, aviation seems to be one of the most relevant cases for=20 deploying moving networks and if they need a solution i would say that=20= the problem is relevant (especially considering what they do if we=20 don't provide an alternative solution, injecting BGP routes and=20 introducing bgp instability is not the best for the health of the=20 network i guess) so, i would take Terry's draft and try to figure out how can we provide=20= what they need using nemo and possible extensions. We can come to the=20 conclusion that nemo is not a good starting point and we need a=20 completelly different strategy (and then we need a different bof or=20 whatever) but i defnietely think we should try to figure out if it is=20 possible to fulfill their requirements making some nemo extensions. That's is why the idea of producing only requirements draft at this=20 rechartering stage was good. we can produce the requirements draft and=20= evaluate if we can provide what they need with nemo extensions. If we=20 can we recharter to do so, if not we should go for a bof > and the car industry is still in > the process of trying to understand what the IETF is (a bit like 3GPP = a > while ago if you see what I mean) so I wouldn't expect them to come up > with a clear description of the use cases in the next 2 years (though > they [=3Dsome organizations like ISO] DO work on an architecture based = on > NEMO and IPv6 but are still far from understanding the IETF folks = could > help and save them some mistakes in their architecture). > that is unfortunate also... but i thought some people from the car industry were trying to submit a=20= draft for the last ietf... > > So, with respect to what you concluded below, the new charter could=20 > list > as deliverable a use case documents (but it is most likely to be > produced by us targetted the organizations such as ISO than the other > way round) and some solutions for the RO problem in which we have > identified needs (the 2 I listed), which are reasonably easy to solve, > and for which we possibly have candidate solutions. how do we decide that we will focus in these particular needs and not=20 in other needs? i mean what we would be doing would be to determine that some of the=20 requirements are the ones that we will try to satisfy, but what are the=20= grounds to select these two requirements and not others? having a user requirements has the benefit that we the requirements=20 have been set up by a potential user that seems to have a real need... Regards, marcelo > Thierry > > > > > > > > > On Mon, 25 Sep 2006 15:33:50 +0200 > marcelo bagnulo braun wrote: > >> Hi Thierry, >> >> I thought that the new charter would only be tasked to identify the=20= >> use >> cases and requirements and that future rechartering was needed to >> actually enter in the solution space. >> >> At least that was what i understood from your answer in the last >> meeting when you said: >> >> " Thierry: >> For the new charter, I would have a doc on use-case, and that's >> it." >> >> (from the montreal meeting in the RO discussion) >> >> I don't have a problem with dealing with the requirements that you >> comment, which i guess are valid problems, but my understanding is=20 >> that >> we were going to describe these in a docuement that was to be = produced >> and disucssed in the wg, rather than in the charter... >> >> My point is, i would include a charter item that is to produce an ID >> with the use cases (e.g. car industry) and their requirements (e.g. >> those you mention below) rather than including these requirements in >> the charter itself. >> >> Bottom line is that i guess that the discussion of the requirements >> should not be part of the charter discusion but part of the >> requirements/use case ID discussion. >> >> Regards, marcelo >> >> >> El 25/09/2006, a las 15:17, Thierry Ernst escribi=F3: >> >>> >>> Dear all, >>> >>> I have been involved in some groups working on communication between >>> vehicles and the roadside and vehicle-vehicle communications through >>> the Internet. For their scenarios, 2 RO needs emerge: >>> >>> 1. The MR in the vehicle should be able to communicate with a CN on=20= >>> the >>> roadside without going through the MR-HA tunnel. >>> >>> 2. A MR in a vehicle should be able to communicate with another MR = in >>> another vehicle via the Internet infrastructure but packets flowing=20= >>> via >>> the HAs of both MRs should be avoided. >>> >>> May be we could have these listed in the new charter more = explicitly. >>> >>> Thierry. >>> >>> >>> >>> >>> On Tue, 19 Sep 2006 19:18:10 -0700 >>> "T.J. Kniveton" wrote: >>> >>>> Hi folks, I'm back.. >>>> >>>> Here is the current version of the charter. I am still making >>>> changes, and need to modify the milestones section. But wanted to >>>> share what's there now and see if there are any comments. >>>> >>>> Please send comments directly to me, for the moment, and when I = have >>>> the next version we can discuss it on the list. >>>> >>>> http://www.mobilenetworks.org/nemo/charter2_3.txt >>>> >>>> TJ >>>> >>> >>> >>> --=20 >>> Thierry ERNST, PhD >>> http://www.nautilus6.org/~thierry >>> IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair >>> -- >>> INRIA Rocquencourt Project-Team IMARA, France. >>> +33 1 39 63 59 30 (office) >>> >>> >> >> >> > > > --=20 > Thierry ERNST, PhD > http://www.nautilus6.org/~thierry > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > -- > INRIA Rocquencourt Project-Team IMARA, France. > +33 1 39 63 59 30 (office) > > From nemo-bounces@ietf.org Mon Sep 25 12:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRt5O-0007L1-En; Mon, 25 Sep 2006 12:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRt5M-0007Kh-AS for nemo@ietf.org; Mon, 25 Sep 2006 12:13:36 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRt5L-0005Cd-25 for nemo@ietf.org; Mon, 25 Sep 2006 12:13:36 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5173770; Mon, 25 Sep 2006 12:13:34 -0400 In-Reply-To: <4517DC72.5040006@motorola.com> References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> <1159182519.982.289.camel@localhost> <4517DC72.5040006@motorola.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marshall Eubanks Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 12:13:30 -0400 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: marcelo bagnulo braun , Eranga Perera , "T.J. Kniveton" , Chan-Wah Ng , ml-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: , Errors-To: nemo-bounces@ietf.org On Sep 25, 2006, at 9:41 AM, Alexandru Petrescu wrote: > Chan-Wah Ng wrote: >> On Mon, 2006-09-25 at 12:03 +0200, marcelo bagnulo braun wrote: >>> El 25/09/2006, a las 11:51, Chan-Wah Ng escribi=F3: >>> >>>> Hello all, >>>> >>>> I have to disagree on the part of problem definition. The =20 >>>> problem has >>>> already been defined. The WG has already produced a problem =20 >>>> statement >>>> draft which has passed WGLC. >>> you are right of course >>> >>> by problem i was meaning specific problems of the different real =20 >>> cases, since as you mention, the problem space identifed in the =20 >>> RO pb statement draft is simply to wide and many solutions fit =20 >>> as solutions to this problem >>> >>>> What is missing, which I do agree, is real requirements. =20 >>>> Requirements >>>> such as the acceptable signaling overhead, whether the MNNs =20 >>>> should be >>>> aware of the network mobility, whether the MNNs can implement new >>>> functionalities to support a RO solution, etc. >>>> >>>> Now the car industry may have a set of requirements, the aviation >>>> industry may have another set, and the digital broadcast =20 >>>> industry may >>>> have yet another set. If the world was a prefect ideal one, a =20 >>>> single >>>> solution would suffice to solve the problem of route =20 >>>> optimization and >>>> fulfill all requirements. Alas such a world doesn't exist. >>>> >>>> So, we do the next best thing. We have different types of solution >>>> catered for different set of requirements. Selection of the =20 >>>> approach >>>> can be based on the solution space analysis that the WG has =20 >>>> produced. >>>> >>>> But first, we need to get those requirements. >>> exactly, >>> >>> before discussing any solution we need to find real application =20 >>> cases and determine thier requirements >>> >>> only then we can start talking about solutions, because without =20 >>> these use cases and requirements we cannot compare evaluate the =20 >>> ddifferent proposals that are around. >>> >>> Do we agree that identifying use cases and requirements is not a =20 >>> nice to have step but we must do this before start working on =20 >>> solutions? >>> >> This I agree ... but haven't Thierry already collected some =20 >> information >> from different industries? He presented them in Montreal. > > Yes, it's at > http://www.mobilenetworks.org/nemo/ietf66/nemo-ietf66-slides.pdf > pp 12-15 > Which, BTW, are the same as http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf > Alex > Regards Marshall= From nemo-bounces@ietf.org Mon Sep 25 12:51:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtfk-0002x7-Pk; Mon, 25 Sep 2006 12:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtei-0002GH-7r for nemo@ietf.org; Mon, 25 Sep 2006 12:50:08 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrkB-0001pV-Mr for nemo@ietf.org; Mon, 25 Sep 2006 10:47:41 -0400 Received: from [10.1.210.1] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 07:46:05 -0700 Message-ID: <4517EBAE.1020303@azairenet.com> Date: Mon, 25 Sep 2006 07:46:06 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4513AE33.1090506@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Sep 2006 14:46:05.0086 (UTC) FILETIME=[5410D3E0:01C6E0B1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ml-nemo WG , "T.J. Kniveton" Subject: [nemo] Re: RO for geographically dist'd 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: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: > So i would suggest to remove the item > > Submit -00 draft on Route Optimization for geographically distributed HAs disagree. the "geographically distributed HAs" was a much more specific problem. it is not intended to be a general purpose route optimization solution. even when you have a route optimization solution, you would still need something to address distributed HAs. I actually dont mind removing the word "Route Optimization" from the above sentence. the fact is it does some sort of route optimization as a side effect. and it doesn't involve the mobile routers in route optimization. thats a good feature. :) Vijay > > And to include an item about providing a new ID -00 about identifying > scenarios and requirements for RO > > Regards, marcelo > > > El 22/09/2006, a las 11:34, Alexandru Petrescu escribió: > >> T.J. Kniveton wrote: >>> Hi folks, I'm back.. >>> Here is the current version of the charter. I am still making >>> changes, and need to modify the milestones section. But wanted to >>> share what's there now and see if there are any comments. >>> Please send comments directly to me, for the moment, and when I have >>> the next version we can discuss it on the list. >>> http://www.mobilenetworks.org/nemo/charter2_3.txt >> >> Another remark on the Charter2_3. It has an item: >> "??? 2006 Submit -00 draft on Route Optimization for >> geographically distributed HAs" >> >> However, this is not currently a WG item (so can't be considered as >> "finishing ongoing WG documents") and has no other textual description >> in charter2_3. What is it about? Is it >> draft-wakikawa-mip6-nemo-haha-01.txt or >> draft-wakikawa-mip6-nemo-haha-spec-00? >> >> We've had a long discussion previously about the need and feasibility of >> HAHA protocols. There may have been many conclusions, I don't remember >> all. >> >> Alex >> > > From nemo-bounces@ietf.org Mon Sep 25 17:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRy4m-0004y2-Si; Mon, 25 Sep 2006 17:33:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRy4l-0004sd-Hp for nemo@ietf.org; Mon, 25 Sep 2006 17:33:19 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRy4k-0008DA-5N for nemo@ietf.org; Mon, 25 Sep 2006 17:33:19 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5175275; Mon, 25 Sep 2006 17:33:17 -0400 In-Reply-To: <17ac37fdb389d7e0c003c558d2c52033@it.uc3m.es> References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> <1159182519.982.289.camel@localhost> <17ac37fdb389d7e0c003c558d2c52033@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <333D0B75-4369-469D-85F8-C74E791FC173@multicasttech.com> Content-Transfer-Encoding: quoted-printable From: Marshall Eubanks Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 17:33:16 -0400 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ml-nemo WG , Eranga Perera , "T.J. Kniveton" , Chan-Wah Ng , 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: , Errors-To: nemo-bounces@ietf.org On Sep 25, 2006, at 9:38 AM, marcelo bagnulo braun wrote: > > El 25/09/2006, a las 15:27, Marshall Eubanks escribi=F3: > >> Hello; >> >> On Sep 25, 2006, at 7:08 AM, Chan-Wah Ng wrote: >> >>> On Mon, 2006-09-25 at 12:03 +0200, marcelo bagnulo braun wrote: >>>> El 25/09/2006, a las 11:51, Chan-Wah Ng escribi=F3: >>>> >> >>>> before discussing any solution we need to find real application =20 >>>> cases >>>> and determine thier requirements >>>> >>>> only then we can start talking about solutions, because without =20 >>>> these >>>> use cases and requirements we cannot compare evaluate the =20 >>>> ddifferent >>>> proposals that are around. >>>> >>>> Do we agree that identifying use cases and requirements is not a =20= >>>> nice >>>> to have step but we must do this before start working on solutions? >>>> >>> >>> This I agree ... but haven't Thierry already collected some =20 >>> information >>> from different industries? He presented them in Montreal. I =20 >>> think all >>> we need is to document them in an Internet draft, circulate the =20 >>> draft >>> around the various concerned industries to review the documented >>> requirements. (I think waiting for busy people from these =20 >>> industries to >>> produce a draft on their own would take a long long time. It is =20 >>> better >>> someone write it for them). >>> >>> /rgds >>> /cwng >>> >> >> >> Was this a presentation ? Is it available somewhere ? I don't see =20 >> it in the proceedings - >> or is just the lists on pages 13-14-15 of >> http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf ? > > i guess this is it > > but there was also a nice email with requirements from the aviation =20= > industry from Terry Davis from Boeing, but i guess they never put =20 > it as an ID :-( It's coming... > > the original message is http://www1.ietf.org/mail-archive/web/nemo/=20 > current/msg03299.html > > regards, marcelo > > >> >> Regards >> Marshall > From nemo-bounces@ietf.org Mon Sep 25 19:01:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRzRZ-0003VI-5R; Mon, 25 Sep 2006 19:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRzRX-0003VD-9h for nemo@ietf.org; Mon, 25 Sep 2006 19:00:55 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRzRS-0003uK-EG for nemo@ietf.org; Mon, 25 Sep 2006 19:00:55 -0400 Received: from MONDAY (kona [147.46.240.223]) by popeye.snu.ac.kr (8.12.11/8.12.11) with SMTP id k8PN39pg031436 for ; Tue, 26 Sep 2006 08:03:09 +0900 Message-ID: <000a01c6e0f6$1326e2d0$dff02e93@MONDAY> From: "???" To: References: Date: Tue, 26 Sep 2006 07:58:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Subject: [nemo] unsubscribe 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: , Errors-To: nemo-bounces@ietf.org DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPG5lbW8tcmVxdWVzdEBpZXRm Lm9yZz4NClRvOiA8bmVtb0BpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI1LCAy MDA2IDEwOjU1IFBNDQpTdWJqZWN0OiBORU1PIERpZ2VzdCwgVm9sIDI5LCBJc3N1ZSA4DQoNCg0K PiBTZW5kIE5FTU8gbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQo+IG5lbW9AaWV0Zi5vcmcN Cj4gDQo+IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2Vi LCB2aXNpdA0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZW1vDQo+ IG9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxw JyB0bw0KPiBuZW1vLXJlcXVlc3RAaWV0Zi5vcmcNCj4gDQo+IFlvdSBjYW4gcmVhY2ggdGhlIHBl cnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KPiBuZW1vLW93bmVyQGlldGYub3JnDQo+IA0KPiBX aGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3Jl IHNwZWNpZmljDQo+IHRoYW4gIlJlOiBDb250ZW50cyBvZiBORU1PIGRpZ2VzdC4uLiINCj4gDQo+ IA0KPiBUb2RheSdzIFRvcGljczoNCj4gDQo+ICAgMS4gUmU6IFJPIGZvciBnZW9ncmFwaGljYWxs eSBkaXN0J2QgSEFzICh3YXM6IFtuZW1vXSBDaGFydGVyDQo+ICAgICAgdXBkYXRlLCBjb250aW51 ZWQpIChDaGFuLVdhaCBOZykNCj4gICAyLiBSZTogUk8gZm9yIGdlb2dyYXBoaWNhbGx5IGRpc3Qn ZCBIQXMgKHdhczogW25lbW9dIENoYXJ0ZXINCj4gICAgICB1cGRhdGUsIGNvbnRpbnVlZCkgKG1h cmNlbG8gYmFnbnVsbyBicmF1bikNCj4gICAzLiBDaGFydGVyIHVwZGF0ZTogUk8gYmV0d2VlbiBN UiBhbmQgZm9yZWlnbiBhY2Nlc3MgbmV0d29yaw0KPiAgICAgIChUaGllcnJ5IEVybnN0KQ0KPiAg IDQuIFJlOiBSTyBmb3IgZ2VvZ3JhcGhpY2FsbHkgZGlzdCdkIEhBcyAod2FzOiBbbmVtb10gQ2hh cnRlcg0KPiAgICAgIHVwZGF0ZSwgY29udGludWVkKSAoTWFyc2hhbGwgRXViYW5rcykNCj4gICA1 LiBSZTogQ2hhcnRlciB1cGRhdGU6IFJPIGJldHdlZW4gTVIgYW5kIGZvcmVpZ24gYWNjZXNzIG5l dHdvcmsNCj4gICAgICAobWFyY2VsbyBiYWdudWxvIGJyYXVuKQ0KPiAgIDYuIFJlOiBSTyBmb3Ig Z2VvZ3JhcGhpY2FsbHkgZGlzdCdkIEhBcyAod2FzOiBbbmVtb10gQ2hhcnRlcg0KPiAgICAgIHVw ZGF0ZSwgY29udGludWVkKSAobWFyY2VsbyBiYWdudWxvIGJyYXVuKQ0KPiAgIDcuIFJlOiBSTyBm b3IgZ2VvZ3JhcGhpY2FsbHkgZGlzdCdkIEhBcyAod2FzOiBbbmVtb10gQ2hhcnRlcg0KPiAgICAg IHVwZGF0ZSwgY29udGludWVkKSAoQWxleGFuZHJ1IFBldHJlc2N1KQ0KPiAgIDguIFJlOiBDaGFy dGVyIHVwZGF0ZTogUk8gYmV0d2VlbiBNUiBhbmQgZm9yZWlnbiBhY2Nlc3MgbmV0d29yaw0KPiAg ICAgIChUaGllcnJ5IEVybnN0KQ0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IE1lc3Nh Z2U6IDENCj4gRGF0ZTogTW9uLCAyNSBTZXAgMjAwNiAxOTowODozOSArMDgwMA0KPiBGcm9tOiBD aGFuLVdhaCBOZyA8Y2hhbndhaC5uZ0BzZy5wYW5hc29uaWMuY29tPg0KPiBTdWJqZWN0OiBSZTog Uk8gZm9yIGdlb2dyYXBoaWNhbGx5IGRpc3QnZCBIQXMgKHdhczogW25lbW9dIENoYXJ0ZXINCj4g dXBkYXRlLCBjb250aW51ZWQpDQo+IFRvOiBtYXJjZWxvIGJhZ251bG8gYnJhdW4gPG1hcmNlbG9A aXQudWMzbS5lcz4NCj4gQ2M6IG1sLW5lbW8gV0cgPG5lbW9AaWV0Zi5vcmc+LCBFcmFuZ2EgUGVy ZXJhDQo+IDxFcmFuZ2EuUGVyZXJhQG5pY3RhLmNvbS5hdT4sICJULkouIEtuaXZldG9uIiA8dGpA a25pdmV0b24uY29tPiwNCj4gQWxleGFuZHJ1IFBldHJlc2N1IDxhbGV4YW5kcnUucGV0cmVzY3VA bW90b3JvbGEuY29tPg0KPiBNZXNzYWdlLUlEOiA8MTE1OTE4MjUxOS45ODIuMjg5LmNhbWVsQGxv Y2FsaG9zdD4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04DQo+IA0K PiBPbiBNb24sIDIwMDYtMDktMjUgYXQgMTI6MDMgKzAyMDAsIG1hcmNlbG8gYmFnbnVsbyBicmF1 biB3cm90ZToNCj4+IEVsIDI1LzA5LzIwMDYsIGEgbGFzIDExOjUxLCBDaGFuLVdhaCBOZyBlc2Ny aWJpw7M6DQo+PiANCj4+ID4gSGVsbG8gYWxsLA0KPj4gPg0KPj4gPiBJIGhhdmUgdG8gZGlzYWdy ZWUgb24gdGhlIHBhcnQgb2YgcHJvYmxlbSBkZWZpbml0aW9uLiAgVGhlIHByb2JsZW0gaGFzDQo+ PiA+IGFscmVhZHkgYmVlbiBkZWZpbmVkLiAgVGhlIFdHIGhhcyBhbHJlYWR5IHByb2R1Y2VkIGEg cHJvYmxlbSBzdGF0ZW1lbnQNCj4+ID4gZHJhZnQgd2hpY2ggaGFzIHBhc3NlZCBXR0xDLg0KPj4g DQo+PiB5b3UgYXJlIHJpZ2h0IG9mIGNvdXJzZQ0KPj4gDQo+PiBieSBwcm9ibGVtIGkgd2FzIG1l YW5pbmcgc3BlY2lmaWMgcHJvYmxlbXMgb2YgdGhlIGRpZmZlcmVudCByZWFsIGNhc2VzLCAgDQo+ PiBzaW5jZSBhcyB5b3UgbWVudGlvbiwgdGhlIHByb2JsZW0gc3BhY2UgaWRlbnRpZmVkIGluIHRo ZSBSTyBwYiAgDQo+PiBzdGF0ZW1lbnQgZHJhZnQgaXMgc2ltcGx5IHRvIHdpZGUgYW5kIG1hbnkg c29sdXRpb25zIGZpdCBhcyBzb2x1dGlvbnMgIA0KPj4gdG8gdGhpcyBwcm9ibGVtDQo+PiANCj4+ ID4NCj4+ID4gV2hhdCBpcyBtaXNzaW5nLCB3aGljaCBJIGRvIGFncmVlLCBpcyByZWFsIHJlcXVp cmVtZW50cy4gIFJlcXVpcmVtZW50cw0KPj4gPiBzdWNoIGFzIHRoZSBhY2NlcHRhYmxlIHNpZ25h bGluZyBvdmVyaGVhZCwgd2hldGhlciB0aGUgTU5OcyBzaG91bGQgYmUNCj4+ID4gYXdhcmUgb2Yg dGhlIG5ldHdvcmsgbW9iaWxpdHksIHdoZXRoZXIgdGhlIE1OTnMgY2FuIGltcGxlbWVudCBuZXcN Cj4+ID4gZnVuY3Rpb25hbGl0aWVzIHRvIHN1cHBvcnQgYSBSTyBzb2x1dGlvbiwgZXRjLg0KPj4g Pg0KPj4gPiBOb3cgdGhlIGNhciBpbmR1c3RyeSBtYXkgaGF2ZSBhIHNldCBvZiByZXF1aXJlbWVu dHMsIHRoZSBhdmlhdGlvbg0KPj4gPiBpbmR1c3RyeSBtYXkgaGF2ZSBhbm90aGVyIHNldCwgYW5k IHRoZSBkaWdpdGFsIGJyb2FkY2FzdCBpbmR1c3RyeSBtYXkNCj4+ID4gaGF2ZSB5ZXQgYW5vdGhl ciBzZXQuICBJZiB0aGUgd29ybGQgd2FzIGEgcHJlZmVjdCBpZGVhbCBvbmUsIGEgc2luZ2xlDQo+ PiA+IHNvbHV0aW9uIHdvdWxkIHN1ZmZpY2UgdG8gc29sdmUgdGhlIHByb2JsZW0gb2Ygcm91dGUg b3B0aW1pemF0aW9uIGFuZA0KPj4gPiBmdWxmaWxsIGFsbCByZXF1aXJlbWVudHMuICBBbGFzIHN1 Y2ggYSB3b3JsZCBkb2Vzbid0IGV4aXN0Lg0KPj4gPg0KPj4gPiBTbywgd2UgZG8gdGhlIG5leHQg YmVzdCB0aGluZy4gIFdlIGhhdmUgZGlmZmVyZW50IHR5cGVzIG9mIHNvbHV0aW9uDQo+PiA+IGNh dGVyZWQgZm9yIGRpZmZlcmVudCBzZXQgb2YgcmVxdWlyZW1lbnRzLiAgU2VsZWN0aW9uIG9mIHRo ZSBhcHByb2FjaA0KPj4gPiBjYW4gYmUgYmFzZWQgb24gdGhlIHNvbHV0aW9uIHNwYWNlIGFuYWx5 c2lzIHRoYXQgdGhlIFdHIGhhcyBwcm9kdWNlZC4NCj4+ID4NCj4+ID4gQnV0IGZpcnN0LCB3ZSBu ZWVkIHRvIGdldCB0aG9zZSByZXF1aXJlbWVudHMuDQo+PiANCj4+IGV4YWN0bHksDQo+PiANCj4+ IGJlZm9yZSBkaXNjdXNzaW5nIGFueSBzb2x1dGlvbiB3ZSBuZWVkIHRvIGZpbmQgcmVhbCBhcHBs aWNhdGlvbiBjYXNlcyAgDQo+PiBhbmQgZGV0ZXJtaW5lIHRoaWVyIHJlcXVpcmVtZW50cw0KPj4g DQo+PiBvbmx5IHRoZW4gd2UgY2FuIHN0YXJ0IHRhbGtpbmcgYWJvdXQgc29sdXRpb25zLCBiZWNh dXNlIHdpdGhvdXQgdGhlc2UgIA0KPj4gdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgd2UgY2Fu bm90IGNvbXBhcmUgZXZhbHVhdGUgdGhlIGRkaWZmZXJlbnQgIA0KPj4gcHJvcG9zYWxzIHRoYXQg YXJlIGFyb3VuZC4NCj4+IA0KPj4gRG8gd2UgYWdyZWUgdGhhdCBpZGVudGlmeWluZyB1c2UgY2Fz ZXMgYW5kIHJlcXVpcmVtZW50cyBpcyBub3QgYSBuaWNlICANCj4+IHRvIGhhdmUgc3RlcCBidXQg d2UgbXVzdCBkbyB0aGlzIGJlZm9yZSBzdGFydCB3b3JraW5nIG9uIHNvbHV0aW9ucz8NCj4+IA0K PiANCj4gVGhpcyBJIGFncmVlIC4uLiBidXQgaGF2ZW4ndCBUaGllcnJ5IGFscmVhZHkgY29sbGVj dGVkIHNvbWUgaW5mb3JtYXRpb24NCj4gZnJvbSBkaWZmZXJlbnQgaW5kdXN0cmllcz8gIEhlIHBy ZXNlbnRlZCB0aGVtIGluIE1vbnRyZWFsLiBJIHRoaW5rIGFsbA0KPiB3ZSBuZWVkIGlzIHRvIGRv Y3VtZW50IHRoZW0gaW4gYW4gSW50ZXJuZXQgZHJhZnQsIGNpcmN1bGF0ZSB0aGUgZHJhZnQNCj4g YXJvdW5kIHRoZSB2YXJpb3VzIGNvbmNlcm5lZCBpbmR1c3RyaWVzIHRvIHJldmlldyB0aGUgZG9j dW1lbnRlZA0KPiByZXF1aXJlbWVudHMuICAoSSB0aGluayB3YWl0aW5nIGZvciBidXN5IHBlb3Bs ZSBmcm9tIHRoZXNlIGluZHVzdHJpZXMgdG8NCj4gcHJvZHVjZSBhIGRyYWZ0IG9uIHRoZWlyIG93 biB3b3VsZCB0YWtlIGEgbG9uZyBsb25nIHRpbWUuICBJdCBpcyBiZXR0ZXINCj4gc29tZW9uZSB3 cml0ZSBpdCBmb3IgdGhlbSkuDQo+IA0KPiAvcmdkcw0KPiAvY3duZw0KPiANCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IE1lc3NhZ2U6IDINCj4gRGF0ZTog TW9uLCAyNSBTZXAgMjAwNiAxNDoyMDoyNCArMDIwMA0KPiBGcm9tOiBtYXJjZWxvIGJhZ251bG8g YnJhdW4gPG1hcmNlbG9AaXQudWMzbS5lcz4NCj4gU3ViamVjdDogUmU6IFJPIGZvciBnZW9ncmFw aGljYWxseSBkaXN0J2QgSEFzICh3YXM6IFtuZW1vXSBDaGFydGVyDQo+IHVwZGF0ZSwgY29udGlu dWVkKQ0KPiBUbzogQ2hhbi1XYWggTmcgPGNoYW53YWgubmdAc2cucGFuYXNvbmljLmNvbT4NCj4g Q2M6IG1sLW5lbW8gV0cgPG5lbW9AaWV0Zi5vcmc+LCBFcmFuZ2EgUGVyZXJhDQo+IDxFcmFuZ2Eu UGVyZXJhQG5pY3RhLmNvbS5hdT4sICJULkouIEtuaXZldG9uIiA8dGpAa25pdmV0b24uY29tPiwN Cj4gQWxleGFuZHJ1IFBldHJlc2N1IDxhbGV4YW5kcnUucGV0cmVzY3VAbW90b3JvbGEuY29tPg0K PiBNZXNzYWdlLUlEOiA8NDI4ZGVmMmExZmM2ZWZjZjM5NTQ4NjY1MDRkZGYxMGVAaXQudWMzbS5l cz4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PUlTTy04ODU5LTE7IGZvcm1h dD1mbG93ZWQNCj4gDQo+IA0KPiBFbCAyNS8wOS8yMDA2LCBhIGxhcyAxMzowOCwgQ2hhbi1XYWgg TmcgZXNjcmliafM6DQo+IA0KPj4gVGhpcyBJIGFncmVlIC4uLiBidXQgaGF2ZW4ndCBUaGllcnJ5 IGFscmVhZHkgY29sbGVjdGVkIHNvbWUgaW5mb3JtYXRpb24NCj4+IGZyb20gZGlmZmVyZW50IGlu ZHVzdHJpZXM/ICBIZSBwcmVzZW50ZWQgdGhlbSBpbiBNb250cmVhbC4gSSB0aGluayBhbGwNCj4+ IHdlIG5lZWQgaXMgdG8gZG9jdW1lbnQgdGhlbSBpbiBhbiBJbnRlcm5ldCBkcmFmdCwgY2lyY3Vs YXRlIHRoZSBkcmFmdA0KPj4gYXJvdW5kIHRoZSB2YXJpb3VzIGNvbmNlcm5lZCBpbmR1c3RyaWVz IHRvIHJldmlldyB0aGUgZG9jdW1lbnRlZA0KPj4gcmVxdWlyZW1lbnRzLiAgKEkgdGhpbmsgd2Fp dGluZyBmb3IgYnVzeSBwZW9wbGUgZnJvbSB0aGVzZSBpbmR1c3RyaWVzIA0KPj4gdG8NCj4+IHBy b2R1Y2UgYSBkcmFmdCBvbiB0aGVpciBvd24gd291bGQgdGFrZSBhIGxvbmcgbG9uZyB0aW1lLiAg SXQgaXMgYmV0dGVyDQo+PiBzb21lb25lIHdyaXRlIGl0IGZvciB0aGVtKS4NCj4+DQo+IE9mIGNv dXJzZSBpIGRvbid0IGhhdmUgYW55IHByb2JsZW0gd2l0aCB3aG8gaXMgdGhlIGVkaXRvciBvZiBz dWNoIA0KPiBkb2N1bWVudHMNCj4gDQo+IEp1c3Qgd2FudCB0byBiZSBzdXJlIHRoYXQgdGhvc2Ug cmVmbGVjdCByZWFsIHByb2JsZW1zIG9mIHJlYWwgdXNlIGNhc2VzIA0KPiBhbmQgdGhhdCB3ZSBh cmUgd29ya2luZyBpbiBhIHNvbHV0aW9uIHRoYXQgaGFzIHBvdGVudGlhbCB1c2Vycy4gU28gaSAN Cj4gYWdyZWUgdGhhdCB0aGUgcGVvcGxlIGZyb20gdGhlIGluZHVzdHJ5IHRoYXQgd2lsbCB1c2Ug dGhlIHNvbHV0aW9uIA0KPiBkb24ndCBuZWVkIHRvIGJlIHRoZSBlZGl0b3JzIG9mIHRoZSByZXF1 aXJlbWVudHMgYW5kIHVzZSBjYXNlcyBkcmFmdCwgYSANCj4gaGVhdnkgaW52b2x2bWVudCBmcm9t IHRoZWlyIHBhcnQgaXMgcmVxdWlyZWQgaW4gb3JkZXIgdG8gYmUgc3VyZSB0aGF0IA0KPiB0aGlz IGlzIHdoYXQgaXMgbmVlZGVkLiBCdXQgaSB0aGluayB3ZSBkbyBoYXZlIHRoaXMgaGVyZSBpbiB0 aGUgd2csIA0KPiBzaW5jZSBzZXZlcmFsIHBlb3BsZSBmcm9tIHRoZSBhdmlhdGlvbiBpbmR1c3Ry eSBoYXMgYmVlbiBpbnZvbHZlZCBpbiANCj4gdGhlIGRpc2N1c3NzaW9ucyBhbmQgcGVvcGxlIGZy b20gdGhlIGNhciBpbmR1c3RyeSBoYXMgYWxzbyBzZW5kIHNvbWUgDQo+IGVtYWlscy4gVGhlaXIg cGFydGljaXBhdGlvbiBpcyBjcml0aWNhbCBmb3IgdGhlIHVzZWZ1bG5lc3Mgb2YgdGhlIA0KPiBv dXRjb21lIG9mIHRoZSB3b3JrIGRvbmUgaGVyZS4NCj4gDQo+IHNvLCBpbWhvIHdlIG5lZWQgYSB1 c2UgY2FzZSBkZXNjcnB0aW9uIGFuZCByZXF1aXJlbWVudHMgZm9yIFJPIGFuZCByZWFsIA0KPiB1 c2VycyBtdXN0IGJlIGludm9sdmVkIGluIHRoZSBkZWZpbml0aW9uIG9mIHRoZXNlIGRvY3VlbXRu cyBhbmQgdGhpcyBpcyANCj4gYSByZXF1aXJlZCBiZWZvcmUgbW92aW5nIGludG8gdGhlIHNvbHV0 aW9uIHNwYWNlDQo+IA0KPiBSZWdhcmRzLCBtYXJjZWxvDQo+IA0KPj4gL3JnZHMNCj4+IC9jd25n DQo+Pg0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IA0KPiBNZXNzYWdlOiAzDQo+IERhdGU6IE1vbiwgMjUgU2VwIDIwMDYgMTU6MTc6MzYgKzAyMDAN Cj4gRnJvbTogVGhpZXJyeSBFcm5zdCA8dGhpZXJyeS5lcm5zdEBpbnJpYS5mcj4NCj4gU3ViamVj dDogW25lbW9dIENoYXJ0ZXIgdXBkYXRlOiBSTyBiZXR3ZWVuIE1SIGFuZCBmb3JlaWduIGFjY2Vz cw0KPiBuZXR3b3JrDQo+IFRvOiBuZW1vQGlldGYub3JnDQo+IE1lc3NhZ2UtSUQ6IDwyMDA2MDky NTE1MTczNi4zNjhhMzk4ZC50aGllcnJ5LmVybnN0QGlucmlhLmZyPg0KPiBDb250ZW50LVR5cGU6 IHRleHQvcGxhaW47IGNoYXJzZXQ9VVMtQVNDSUkNCj4gDQo+IA0KPiBEZWFyIGFsbCwNCj4gDQo+ IEkgaGF2ZSBiZWVuIGludm9sdmVkIGluIHNvbWUgZ3JvdXBzIHdvcmtpbmcgb24gY29tbXVuaWNh dGlvbiBiZXR3ZWVuDQo+IHZlaGljbGVzIGFuZCB0aGUgcm9hZHNpZGUgYW5kIHZlaGljbGUtdmVo aWNsZSBjb21tdW5pY2F0aW9ucyB0aHJvdWdoDQo+IHRoZSBJbnRlcm5ldC4gRm9yIHRoZWlyIHNj ZW5hcmlvcywgMiBSTyBuZWVkcyBlbWVyZ2U6DQo+IA0KPiAxLiBUaGUgTVIgaW4gdGhlIHZlaGlj bGUgc2hvdWxkIGJlIGFibGUgdG8gY29tbXVuaWNhdGUgd2l0aCBhIENOIG9uIHRoZQ0KPiByb2Fk c2lkZSB3aXRob3V0IGdvaW5nIHRocm91Z2ggdGhlIE1SLUhBIHR1bm5lbC4gDQo+IA0KPiAyLiBB IE1SIGluIGEgdmVoaWNsZSBzaG91bGQgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB3aXRoIGFub3Ro ZXIgTVIgaW4NCj4gYW5vdGhlciB2ZWhpY2xlIHZpYSB0aGUgSW50ZXJuZXQgaW5mcmFzdHJ1Y3R1 cmUgYnV0IHBhY2tldHMgZmxvd2luZyB2aWENCj4gdGhlIEhBcyBvZiBib3RoIE1ScyBzaG91bGQg YmUgYXZvaWRlZC4NCj4gDQo+IE1heSBiZSB3ZSBjb3VsZCBoYXZlIHRoZXNlIGxpc3RlZCBpbiB0 aGUgbmV3IGNoYXJ0ZXIgbW9yZSBleHBsaWNpdGx5Lg0KPiANCj4gVGhpZXJyeS4NCj4gDQo+IA0K PiANCj4gDQo+IE9uIFR1ZSwgMTkgU2VwIDIwMDYgMTk6MTg6MTAgLTA3MDANCj4gIlQuSi4gS25p dmV0b24iIDx0akBrbml2ZXRvbi5jb20+IHdyb3RlOg0KPiANCj4+IEhpIGZvbGtzLCBJJ20gYmFj ay4uDQo+PiANCj4+IEhlcmUgaXMgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgY2hhcnRlci4g SSBhbSBzdGlsbCBtYWtpbmcgIA0KPj4gY2hhbmdlcywgYW5kIG5lZWQgdG8gbW9kaWZ5IHRoZSBt aWxlc3RvbmVzIHNlY3Rpb24uIEJ1dCB3YW50ZWQgdG8gIA0KPj4gc2hhcmUgd2hhdCdzIHRoZXJl IG5vdyBhbmQgc2VlIGlmIHRoZXJlIGFyZSBhbnkgY29tbWVudHMuDQo+PiANCj4+IFBsZWFzZSBz ZW5kIGNvbW1lbnRzIGRpcmVjdGx5IHRvIG1lLCBmb3IgdGhlIG1vbWVudCwgYW5kIHdoZW4gSSBo YXZlICANCj4+IHRoZSBuZXh0IHZlcnNpb24gd2UgY2FuIGRpc2N1c3MgaXQgb24gdGhlIGxpc3Qu DQo+PiANCj4+IGh0dHA6Ly93d3cubW9iaWxlbmV0d29ya3Mub3JnL25lbW8vY2hhcnRlcjJfMy50 eHQNCj4+IA0KPj4gVEoNCj4+IA0KPiANCj4gDQo+IC0tIA0KPiBUaGllcnJ5IEVSTlNULCBQaEQN Cj4gaHR0cDovL3d3dy5uYXV0aWx1czYub3JnL350aGllcnJ5DQo+IElFVEYgTkVNTyBXRyBDaGFp ciwgSUVURiBNb25BbWk2IENoYWlyLCBOYXV0aWx1czYgQ2hhaXINCj4gLS0NCj4gSU5SSUEgUm9j cXVlbmNvdXJ0IFByb2plY3QtVGVhbSBJTUFSQSwgRnJhbmNlLg0KPiArMzMgMSAzOSA2MyA1OSAz MCAob2ZmaWNlKQ0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IA0KPiBNZXNzYWdlOiA0DQo+IERhdGU6IE1vbiwgMjUgU2VwIDIwMDYgMDk6Mjc6NTkg LTA0MDANCj4gRnJvbTogTWFyc2hhbGwgRXViYW5rcyA8dG1lQG11bHRpY2FzdHRlY2guY29tPg0K PiBTdWJqZWN0OiBSZTogUk8gZm9yIGdlb2dyYXBoaWNhbGx5IGRpc3QnZCBIQXMgKHdhczogW25l bW9dIENoYXJ0ZXINCj4gdXBkYXRlLCBjb250aW51ZWQpDQo+IFRvOiBDaGFuLVdhaCBOZyA8Y2hh bndhaC5uZ0BzZy5wYW5hc29uaWMuY29tPg0KPiBDYzogbWFyY2VsbyBiYWdudWxvIGJyYXVuIDxt YXJjZWxvQGl0LnVjM20uZXM+LCBtbC1uZW1vIFdHDQo+IDxuZW1vQGlldGYub3JnPiwgIlQuSi4g S25pdmV0b24iIDx0akBrbml2ZXRvbi5jb20+LCBBbGV4YW5kcnUgUGV0cmVzY3UNCj4gPGFsZXhh bmRydS5wZXRyZXNjdUBtb3Rvcm9sYS5jb20+LCBFcmFuZ2EgUGVyZXJhDQo+IDxFcmFuZ2EuUGVy ZXJhQG5pY3RhLmNvbS5hdT4NCj4gTWVzc2FnZS1JRDogPEMwRjMxMzg5LTYzMkMtNDdBOS04MkRD LTNEQzFEMzM4RDMxRkBtdWx0aWNhc3R0ZWNoLmNvbT4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3Bs YWluOyBjaGFyc2V0PUlTTy04ODU5LTE7IGRlbHNwPXllczsgZm9ybWF0PWZsb3dlZA0KPiANCj4g SGVsbG87DQo+IA0KPiBPbiBTZXAgMjUsIDIwMDYsIGF0IDc6MDggQU0sIENoYW4tV2FoIE5nIHdy b3RlOg0KPiANCj4+IE9uIE1vbiwgMjAwNi0wOS0yNSBhdCAxMjowMyArMDIwMCwgbWFyY2VsbyBi YWdudWxvIGJyYXVuIHdyb3RlOg0KPj4+IEVsIDI1LzA5LzIwMDYsIGEgbGFzIDExOjUxLCBDaGFu LVdhaCBOZyBlc2NyaWJp8zoNCj4+Pg0KPiA8c25pcD4NCj4+PiBiZWZvcmUgZGlzY3Vzc2luZyBh bnkgc29sdXRpb24gd2UgbmVlZCB0byBmaW5kIHJlYWwgYXBwbGljYXRpb24gY2FzZXMNCj4+PiBh bmQgZGV0ZXJtaW5lIHRoaWVyIHJlcXVpcmVtZW50cw0KPj4+DQo+Pj4gb25seSB0aGVuIHdlIGNh biBzdGFydCB0YWxraW5nIGFib3V0IHNvbHV0aW9ucywgYmVjYXVzZSB3aXRob3V0IHRoZXNlDQo+ Pj4gdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgd2UgY2Fubm90IGNvbXBhcmUgZXZhbHVhdGUg dGhlIGRkaWZmZXJlbnQNCj4+PiBwcm9wb3NhbHMgdGhhdCBhcmUgYXJvdW5kLg0KPj4+DQo+Pj4g RG8gd2UgYWdyZWUgdGhhdCBpZGVudGlmeWluZyB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBp cyBub3QgYSBuaWNlDQo+Pj4gdG8gaGF2ZSBzdGVwIGJ1dCB3ZSBtdXN0IGRvIHRoaXMgYmVmb3Jl IHN0YXJ0IHdvcmtpbmcgb24gc29sdXRpb25zPw0KPj4+DQo+Pg0KPj4gVGhpcyBJIGFncmVlIC4u LiBidXQgaGF2ZW4ndCBUaGllcnJ5IGFscmVhZHkgY29sbGVjdGVkIHNvbWUgIA0KPj4gaW5mb3Jt YXRpb24NCj4+IGZyb20gZGlmZmVyZW50IGluZHVzdHJpZXM/ICBIZSBwcmVzZW50ZWQgdGhlbSBp biBNb250cmVhbC4gSSB0aGluayBhbGwNCj4+IHdlIG5lZWQgaXMgdG8gZG9jdW1lbnQgdGhlbSBp biBhbiBJbnRlcm5ldCBkcmFmdCwgY2lyY3VsYXRlIHRoZSBkcmFmdA0KPj4gYXJvdW5kIHRoZSB2 YXJpb3VzIGNvbmNlcm5lZCBpbmR1c3RyaWVzIHRvIHJldmlldyB0aGUgZG9jdW1lbnRlZA0KPj4g cmVxdWlyZW1lbnRzLiAgKEkgdGhpbmsgd2FpdGluZyBmb3IgYnVzeSBwZW9wbGUgZnJvbSB0aGVz ZSAgDQo+PiBpbmR1c3RyaWVzIHRvDQo+PiBwcm9kdWNlIGEgZHJhZnQgb24gdGhlaXIgb3duIHdv dWxkIHRha2UgYSBsb25nIGxvbmcgdGltZS4gIEl0IGlzICANCj4+IGJldHRlcg0KPj4gc29tZW9u ZSB3cml0ZSBpdCBmb3IgdGhlbSkuDQo+Pg0KPj4gL3JnZHMNCj4+IC9jd25nDQo+Pg0KPiANCj4g DQo+IFdhcyB0aGlzIGEgcHJlc2VudGF0aW9uID8gSXMgaXQgYXZhaWxhYmxlIHNvbWV3aGVyZSA/ IEkgZG9uJ3Qgc2VlIGl0ICANCj4gaW4gdGhlIHByb2NlZWRpbmdzIC0NCj4gb3IgaXMganVzdCB0 aGUgbGlzdHMgb24gcGFnZXMgMTMtMTQtMTUgb2YNCj4gaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvMDZqdWwvc2xpZGVzL25lbW8tMC5wZGYgPw0KPiANCj4gUmVnYXJkcw0KPiBNYXJz aGFsbA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gTWVz c2FnZTogNQ0KPiBEYXRlOiBNb24sIDI1IFNlcCAyMDA2IDE1OjMzOjUwICswMjAwDQo+IEZyb206 IG1hcmNlbG8gYmFnbnVsbyBicmF1biA8bWFyY2Vsb0BpdC51YzNtLmVzPg0KPiBTdWJqZWN0OiBS ZTogW25lbW9dIENoYXJ0ZXIgdXBkYXRlOiBSTyBiZXR3ZWVuIE1SIGFuZCBmb3JlaWduIGFjY2Vz cw0KPiBuZXR3b3JrDQo+IFRvOiBUaGllcnJ5IEVybnN0IDx0aGllcnJ5LmVybnN0QGlucmlhLmZy Pg0KPiBDYzogbmVtb0BpZXRmLm9yZw0KPiBNZXNzYWdlLUlEOiA8NGIxMWFiYjY5OTZhNmE4ZmY2 NmNmZDg0YzAzN2YwY2RAaXQudWMzbS5lcz4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBj aGFyc2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQNCj4gDQo+IEhpIFRoaWVycnksDQo+IA0K PiBJIHRob3VnaHQgdGhhdCB0aGUgbmV3IGNoYXJ0ZXIgd291bGQgb25seSBiZSB0YXNrZWQgdG8g aWRlbnRpZnkgdGhlIHVzZSANCj4gY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBhbmQgdGhhdCBmdXR1 cmUgcmVjaGFydGVyaW5nIHdhcyBuZWVkZWQgdG8gDQo+IGFjdHVhbGx5IGVudGVyIGluIHRoZSBz b2x1dGlvbiBzcGFjZS4NCj4gDQo+IEF0IGxlYXN0IHRoYXQgd2FzIHdoYXQgaSB1bmRlcnN0b29k IGZyb20geW91ciBhbnN3ZXIgaW4gdGhlIGxhc3QgDQo+IG1lZXRpbmcgd2hlbiB5b3Ugc2FpZDoN Cj4gDQo+ICIgIFRoaWVycnk6DQo+ICAgICAgRm9yIHRoZSBuZXcgY2hhcnRlciwgSSB3b3VsZCBo YXZlIGEgZG9jIG9uIHVzZS1jYXNlLCBhbmQgdGhhdCdzIA0KPiBpdC4iDQo+IA0KPiAoZnJvbSB0 aGUgbW9udHJlYWwgbWVldGluZyBpbiB0aGUgUk8gZGlzY3Vzc2lvbikNCj4gDQo+IEkgZG9uJ3Qg aGF2ZSBhIHByb2JsZW0gd2l0aCBkZWFsaW5nIHdpdGggdGhlIHJlcXVpcmVtZW50cyB0aGF0IHlv dSANCj4gY29tbWVudCwgd2hpY2ggaSBndWVzcyBhcmUgdmFsaWQgcHJvYmxlbXMsIGJ1dCBteSB1 bmRlcnN0YW5kaW5nIGlzIHRoYXQgDQo+IHdlIHdlcmUgZ29pbmcgdG8gZGVzY3JpYmUgdGhlc2Ug aW4gYSBkb2N1ZW1lbnQgdGhhdCB3YXMgdG8gYmUgcHJvZHVjZWQgDQo+IGFuZCBkaXN1Y3NzZWQg aW4gdGhlIHdnLCByYXRoZXIgdGhhbiBpbiB0aGUgY2hhcnRlci4uLg0KPiANCj4gTXkgcG9pbnQg aXMsIGkgd291bGQgaW5jbHVkZSBhIGNoYXJ0ZXIgaXRlbSB0aGF0IGlzIHRvIHByb2R1Y2UgYW4g SUQgDQo+IHdpdGggdGhlIHVzZSBjYXNlcyAoZS5nLiBjYXIgaW5kdXN0cnkpIGFuZCB0aGVpciBy ZXF1aXJlbWVudHMgKGUuZy4gDQo+IHRob3NlIHlvdSBtZW50aW9uIGJlbG93KSByYXRoZXIgdGhh biBpbmNsdWRpbmcgdGhlc2UgcmVxdWlyZW1lbnRzIGluIA0KPiB0aGUgY2hhcnRlciBpdHNlbGYu DQo+IA0KPiBCb3R0b20gbGluZSBpcyB0aGF0IGkgZ3Vlc3MgdGhhdCB0aGUgZGlzY3Vzc2lvbiBv ZiB0aGUgcmVxdWlyZW1lbnRzIA0KPiBzaG91bGQgbm90IGJlIHBhcnQgb2YgdGhlIGNoYXJ0ZXIg ZGlzY3VzaW9uIGJ1dCBwYXJ0IG9mIHRoZSANCj4gcmVxdWlyZW1lbnRzL3VzZSBjYXNlIElEIGRp c2N1c3Npb24uDQo+IA0KPiBSZWdhcmRzLCBtYXJjZWxvDQo+IA0KPiANCj4gRWwgMjUvMDkvMjAw NiwgYSBsYXMgMTU6MTcsIFRoaWVycnkgRXJuc3QgZXNjcmliafM6DQo+IA0KPj4NCj4+IERlYXIg YWxsLA0KPj4NCj4+IEkgaGF2ZSBiZWVuIGludm9sdmVkIGluIHNvbWUgZ3JvdXBzIHdvcmtpbmcg b24gY29tbXVuaWNhdGlvbiBiZXR3ZWVuDQo+PiB2ZWhpY2xlcyBhbmQgdGhlIHJvYWRzaWRlIGFu ZCB2ZWhpY2xlLXZlaGljbGUgY29tbXVuaWNhdGlvbnMgdGhyb3VnaA0KPj4gdGhlIEludGVybmV0 LiBGb3IgdGhlaXIgc2NlbmFyaW9zLCAyIFJPIG5lZWRzIGVtZXJnZToNCj4+DQo+PiAxLiBUaGUg TVIgaW4gdGhlIHZlaGljbGUgc2hvdWxkIGJlIGFibGUgdG8gY29tbXVuaWNhdGUgd2l0aCBhIENO IG9uIHRoZQ0KPj4gcm9hZHNpZGUgd2l0aG91dCBnb2luZyB0aHJvdWdoIHRoZSBNUi1IQSB0dW5u ZWwuDQo+Pg0KPj4gMi4gQSBNUiBpbiBhIHZlaGljbGUgc2hvdWxkIGJlIGFibGUgdG8gY29tbXVu aWNhdGUgd2l0aCBhbm90aGVyIE1SIGluDQo+PiBhbm90aGVyIHZlaGljbGUgdmlhIHRoZSBJbnRl cm5ldCBpbmZyYXN0cnVjdHVyZSBidXQgcGFja2V0cyBmbG93aW5nIHZpYQ0KPj4gdGhlIEhBcyBv ZiBib3RoIE1ScyBzaG91bGQgYmUgYXZvaWRlZC4NCj4+DQo+PiBNYXkgYmUgd2UgY291bGQgaGF2 ZSB0aGVzZSBsaXN0ZWQgaW4gdGhlIG5ldyBjaGFydGVyIG1vcmUgZXhwbGljaXRseS4NCj4+DQo+ PiBUaGllcnJ5Lg0KPj4NCj4+DQo+Pg0KPj4NCj4+IE9uIFR1ZSwgMTkgU2VwIDIwMDYgMTk6MTg6 MTAgLTA3MDANCj4+ICJULkouIEtuaXZldG9uIiA8dGpAa25pdmV0b24uY29tPiB3cm90ZToNCj4+ DQo+Pj4gSGkgZm9sa3MsIEknbSBiYWNrLi4NCj4+Pg0KPj4+IEhlcmUgaXMgdGhlIGN1cnJlbnQg dmVyc2lvbiBvZiB0aGUgY2hhcnRlci4gSSBhbSBzdGlsbCBtYWtpbmcNCj4+PiBjaGFuZ2VzLCBh bmQgbmVlZCB0byBtb2RpZnkgdGhlIG1pbGVzdG9uZXMgc2VjdGlvbi4gQnV0IHdhbnRlZCB0bw0K Pj4+IHNoYXJlIHdoYXQncyB0aGVyZSBub3cgYW5kIHNlZSBpZiB0aGVyZSBhcmUgYW55IGNvbW1l bnRzLg0KPj4+DQo+Pj4gUGxlYXNlIHNlbmQgY29tbWVudHMgZGlyZWN0bHkgdG8gbWUsIGZvciB0 aGUgbW9tZW50LCBhbmQgd2hlbiBJIGhhdmUNCj4+PiB0aGUgbmV4dCB2ZXJzaW9uIHdlIGNhbiBk aXNjdXNzIGl0IG9uIHRoZSBsaXN0Lg0KPj4+DQo+Pj4gaHR0cDovL3d3dy5tb2JpbGVuZXR3b3Jr cy5vcmcvbmVtby9jaGFydGVyMl8zLnR4dA0KPj4+DQo+Pj4gVEoNCj4+Pg0KPj4NCj4+DQo+PiAt LSANCj4+IFRoaWVycnkgRVJOU1QsIFBoRA0KPj4gaHR0cDovL3d3dy5uYXV0aWx1czYub3JnL350 aGllcnJ5DQo+PiBJRVRGIE5FTU8gV0cgQ2hhaXIsIElFVEYgTW9uQW1pNiBDaGFpciwgTmF1dGls dXM2IENoYWlyDQo+PiAtLQ0KPj4gSU5SSUEgUm9jcXVlbmNvdXJ0IFByb2plY3QtVGVhbSBJTUFS QSwgRnJhbmNlLg0KPj4gKzMzIDEgMzkgNjMgNTkgMzAgKG9mZmljZSkNCj4+DQo+Pg0KPiANCj4g DQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBNZXNzYWdl OiA2DQo+IERhdGU6IE1vbiwgMjUgU2VwIDIwMDYgMTU6Mzg6MTMgKzAyMDANCj4gRnJvbTogbWFy Y2VsbyBiYWdudWxvIGJyYXVuIDxtYXJjZWxvQGl0LnVjM20uZXM+DQo+IFN1YmplY3Q6IFJlOiBS TyBmb3IgZ2VvZ3JhcGhpY2FsbHkgZGlzdCdkIEhBcyAod2FzOiBbbmVtb10gQ2hhcnRlcg0KPiB1 cGRhdGUsIGNvbnRpbnVlZCkNCj4gVG86IE1hcnNoYWxsIEV1YmFua3MgPHRtZUBtdWx0aWNhc3R0 ZWNoLmNvbT4NCj4gQ2M6IG1sLW5lbW8gV0cgPG5lbW9AaWV0Zi5vcmc+LCBFcmFuZ2EgUGVyZXJh DQo+IDxFcmFuZ2EuUGVyZXJhQG5pY3RhLmNvbS5hdT4sICJULkouIEtuaXZldG9uIiA8dGpAa25p dmV0b24uY29tPiwNCj4gQ2hhbi1XYWggTmcgPGNoYW53YWgubmdAc2cucGFuYXNvbmljLmNvbT4s IEFsZXhhbmRydSBQZXRyZXNjdQ0KPiA8YWxleGFuZHJ1LnBldHJlc2N1QG1vdG9yb2xhLmNvbT4N Cj4gTWVzc2FnZS1JRDogPDE3YWMzN2ZkYjM4OWQ3ZTBjMDAzYzU1OGQyYzUyMDMzQGl0LnVjM20u ZXM+DQo+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1JU08tODg1OS0xOyBmb3Jt YXQ9Zmxvd2VkDQo+IA0KPiANCj4gRWwgMjUvMDkvMjAwNiwgYSBsYXMgMTU6MjcsIE1hcnNoYWxs IEV1YmFua3MgZXNjcmliafM6DQo+IA0KPj4gSGVsbG87DQo+Pg0KPj4gT24gU2VwIDI1LCAyMDA2 LCBhdCA3OjA4IEFNLCBDaGFuLVdhaCBOZyB3cm90ZToNCj4+DQo+Pj4gT24gTW9uLCAyMDA2LTA5 LTI1IGF0IDEyOjAzICswMjAwLCBtYXJjZWxvIGJhZ251bG8gYnJhdW4gd3JvdGU6DQo+Pj4+IEVs IDI1LzA5LzIwMDYsIGEgbGFzIDExOjUxLCBDaGFuLVdhaCBOZyBlc2NyaWJp8zoNCj4+Pj4NCj4+ IDxzbmlwPg0KPj4+PiBiZWZvcmUgZGlzY3Vzc2luZyBhbnkgc29sdXRpb24gd2UgbmVlZCB0byBm aW5kIHJlYWwgYXBwbGljYXRpb24gY2FzZXMNCj4+Pj4gYW5kIGRldGVybWluZSB0aGllciByZXF1 aXJlbWVudHMNCj4+Pj4NCj4+Pj4gb25seSB0aGVuIHdlIGNhbiBzdGFydCB0YWxraW5nIGFib3V0 IHNvbHV0aW9ucywgYmVjYXVzZSB3aXRob3V0IHRoZXNlDQo+Pj4+IHVzZSBjYXNlcyBhbmQgcmVx dWlyZW1lbnRzIHdlIGNhbm5vdCBjb21wYXJlIGV2YWx1YXRlIHRoZSBkZGlmZmVyZW50DQo+Pj4+ IHByb3Bvc2FscyB0aGF0IGFyZSBhcm91bmQuDQo+Pj4+DQo+Pj4+IERvIHdlIGFncmVlIHRoYXQg aWRlbnRpZnlpbmcgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgaXMgbm90IGEgbmljZQ0KPj4+ PiB0byBoYXZlIHN0ZXAgYnV0IHdlIG11c3QgZG8gdGhpcyBiZWZvcmUgc3RhcnQgd29ya2luZyBv biBzb2x1dGlvbnM/DQo+Pj4+DQo+Pj4NCj4+PiBUaGlzIEkgYWdyZWUgLi4uIGJ1dCBoYXZlbid0 IFRoaWVycnkgYWxyZWFkeSBjb2xsZWN0ZWQgc29tZSANCj4+PiBpbmZvcm1hdGlvbg0KPj4+IGZy b20gZGlmZmVyZW50IGluZHVzdHJpZXM/ICBIZSBwcmVzZW50ZWQgdGhlbSBpbiBNb250cmVhbC4g SSB0aGluayBhbGwNCj4+PiB3ZSBuZWVkIGlzIHRvIGRvY3VtZW50IHRoZW0gaW4gYW4gSW50ZXJu ZXQgZHJhZnQsIGNpcmN1bGF0ZSB0aGUgZHJhZnQNCj4+PiBhcm91bmQgdGhlIHZhcmlvdXMgY29u Y2VybmVkIGluZHVzdHJpZXMgdG8gcmV2aWV3IHRoZSBkb2N1bWVudGVkDQo+Pj4gcmVxdWlyZW1l bnRzLiAgKEkgdGhpbmsgd2FpdGluZyBmb3IgYnVzeSBwZW9wbGUgZnJvbSB0aGVzZSBpbmR1c3Ry aWVzIA0KPj4+IHRvDQo+Pj4gcHJvZHVjZSBhIGRyYWZ0IG9uIHRoZWlyIG93biB3b3VsZCB0YWtl IGEgbG9uZyBsb25nIHRpbWUuICBJdCBpcyANCj4+PiBiZXR0ZXINCj4+PiBzb21lb25lIHdyaXRl IGl0IGZvciB0aGVtKS4NCj4+Pg0KPj4+IC9yZ2RzDQo+Pj4gL2N3bmcNCj4+Pg0KPj4NCj4+DQo+ PiBXYXMgdGhpcyBhIHByZXNlbnRhdGlvbiA/IElzIGl0IGF2YWlsYWJsZSBzb21ld2hlcmUgPyBJ IGRvbid0IHNlZSBpdCANCj4+IGluIHRoZSBwcm9jZWVkaW5ncyAtDQo+PiBvciBpcyBqdXN0IHRo ZSBsaXN0cyBvbiBwYWdlcyAxMy0xNC0xNSBvZg0KPj4gaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvMDZqdWwvc2xpZGVzL25lbW8tMC5wZGYgPw0KPiANCj4gaSBndWVzcyB0aGlzIGlz IGl0DQo+IA0KPiBidXQgdGhlcmUgd2FzIGFsc28gYSBuaWNlIGVtYWlsIHdpdGggcmVxdWlyZW1l bnRzIGZyb20gdGhlIGF2aWF0aW9uIA0KPiBpbmR1c3RyeSBmcm9tIFRlcnJ5IERhdmlzIGZyb20g Qm9laW5nLCBidXQgaSBndWVzcyB0aGV5IG5ldmVyIHB1dCBpdCBhcyANCj4gYW4gSUQgOi0oDQo+ IA0KPiB0aGUgb3JpZ2luYWwgbWVzc2FnZSBpcyANCj4gaHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9uZW1vL2N1cnJlbnQvbXNnMDMyOTkuaHRtbA0KPiANCj4gcmVnYXJkcywg bWFyY2Vsbw0KPiANCj4gDQo+Pg0KPj4gUmVnYXJkcw0KPj4gTWFyc2hhbGwNCj4gDQo+IA0KPiAN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gTWVzc2FnZTogNw0K PiBEYXRlOiBNb24sIDI1IFNlcCAyMDA2IDE1OjQxOjA2ICswMjAwDQo+IEZyb206IEFsZXhhbmRy dSBQZXRyZXNjdSA8YWxleGFuZHJ1LnBldHJlc2N1QG1vdG9yb2xhLmNvbT4NCj4gU3ViamVjdDog UmU6IFJPIGZvciBnZW9ncmFwaGljYWxseSBkaXN0J2QgSEFzICh3YXM6IFtuZW1vXSBDaGFydGVy DQo+IHVwZGF0ZSwgY29udGludWVkKQ0KPiBUbzogQ2hhbi1XYWggTmcgPGNoYW53YWgubmdAc2cu cGFuYXNvbmljLmNvbT4NCj4gQ2M6IG1hcmNlbG8gYmFnbnVsbyBicmF1biA8bWFyY2Vsb0BpdC51 YzNtLmVzPiwgRXJhbmdhIFBlcmVyYQ0KPiA8RXJhbmdhLlBlcmVyYUBuaWN0YS5jb20uYXU+LCAi VC5KLiBLbml2ZXRvbiIgPHRqQGtuaXZldG9uLmNvbT4sDQo+IG1sLW5lbW8gV0cgPG5lbW9AaWV0 Zi5vcmc+DQo+IE1lc3NhZ2UtSUQ6IDw0NTE3REM3Mi41MDQwMDA2QG1vdG9yb2xhLmNvbT4NCj4g Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04OyBmb3JtYXQ9Zmxvd2VkDQo+ IA0KPiBDaGFuLVdhaCBOZyB3cm90ZToNCj4+IE9uIE1vbiwgMjAwNi0wOS0yNSBhdCAxMjowMyAr MDIwMCwgbWFyY2VsbyBiYWdudWxvIGJyYXVuIHdyb3RlOg0KPj4+IEVsIDI1LzA5LzIwMDYsIGEg bGFzIDExOjUxLCBDaGFuLVdhaCBOZyBlc2NyaWJpw7M6DQo+Pj4NCj4+Pj4gSGVsbG8gYWxsLA0K Pj4+Pg0KPj4+PiBJIGhhdmUgdG8gZGlzYWdyZWUgb24gdGhlIHBhcnQgb2YgcHJvYmxlbSBkZWZp bml0aW9uLiAgVGhlIHByb2JsZW0gaGFzDQo+Pj4+IGFscmVhZHkgYmVlbiBkZWZpbmVkLiAgVGhl IFdHIGhhcyBhbHJlYWR5IHByb2R1Y2VkIGEgcHJvYmxlbSBzdGF0ZW1lbnQNCj4+Pj4gZHJhZnQg d2hpY2ggaGFzIHBhc3NlZCBXR0xDLg0KPj4+IHlvdSBhcmUgcmlnaHQgb2YgY291cnNlDQo+Pj4N Cj4+PiBieSBwcm9ibGVtIGkgd2FzIG1lYW5pbmcgc3BlY2lmaWMgcHJvYmxlbXMgb2YgdGhlIGRp ZmZlcmVudCByZWFsIGNhc2VzLCAgDQo+Pj4gc2luY2UgYXMgeW91IG1lbnRpb24sIHRoZSBwcm9i bGVtIHNwYWNlIGlkZW50aWZlZCBpbiB0aGUgUk8gcGIgIA0KPj4+IHN0YXRlbWVudCBkcmFmdCBp cyBzaW1wbHkgdG8gd2lkZSBhbmQgbWFueSBzb2x1dGlvbnMgZml0IGFzIHNvbHV0aW9ucyAgDQo+ Pj4gdG8gdGhpcyBwcm9ibGVtDQo+Pj4NCj4+Pj4gV2hhdCBpcyBtaXNzaW5nLCB3aGljaCBJIGRv IGFncmVlLCBpcyByZWFsIHJlcXVpcmVtZW50cy4gIFJlcXVpcmVtZW50cw0KPj4+PiBzdWNoIGFz IHRoZSBhY2NlcHRhYmxlIHNpZ25hbGluZyBvdmVyaGVhZCwgd2hldGhlciB0aGUgTU5OcyBzaG91 bGQgYmUNCj4+Pj4gYXdhcmUgb2YgdGhlIG5ldHdvcmsgbW9iaWxpdHksIHdoZXRoZXIgdGhlIE1O TnMgY2FuIGltcGxlbWVudCBuZXcNCj4+Pj4gZnVuY3Rpb25hbGl0aWVzIHRvIHN1cHBvcnQgYSBS TyBzb2x1dGlvbiwgZXRjLg0KPj4+Pg0KPj4+PiBOb3cgdGhlIGNhciBpbmR1c3RyeSBtYXkgaGF2 ZSBhIHNldCBvZiByZXF1aXJlbWVudHMsIHRoZSBhdmlhdGlvbg0KPj4+PiBpbmR1c3RyeSBtYXkg aGF2ZSBhbm90aGVyIHNldCwgYW5kIHRoZSBkaWdpdGFsIGJyb2FkY2FzdCBpbmR1c3RyeSBtYXkN Cj4+Pj4gaGF2ZSB5ZXQgYW5vdGhlciBzZXQuICBJZiB0aGUgd29ybGQgd2FzIGEgcHJlZmVjdCBp ZGVhbCBvbmUsIGEgc2luZ2xlDQo+Pj4+IHNvbHV0aW9uIHdvdWxkIHN1ZmZpY2UgdG8gc29sdmUg dGhlIHByb2JsZW0gb2Ygcm91dGUgb3B0aW1pemF0aW9uIGFuZA0KPj4+PiBmdWxmaWxsIGFsbCBy ZXF1aXJlbWVudHMuICBBbGFzIHN1Y2ggYSB3b3JsZCBkb2Vzbid0IGV4aXN0Lg0KPj4+Pg0KPj4+ PiBTbywgd2UgZG8gdGhlIG5leHQgYmVzdCB0aGluZy4gIFdlIGhhdmUgZGlmZmVyZW50IHR5cGVz IG9mIHNvbHV0aW9uDQo+Pj4+IGNhdGVyZWQgZm9yIGRpZmZlcmVudCBzZXQgb2YgcmVxdWlyZW1l bnRzLiAgU2VsZWN0aW9uIG9mIHRoZSBhcHByb2FjaA0KPj4+PiBjYW4gYmUgYmFzZWQgb24gdGhl IHNvbHV0aW9uIHNwYWNlIGFuYWx5c2lzIHRoYXQgdGhlIFdHIGhhcyBwcm9kdWNlZC4NCj4+Pj4N Cj4+Pj4gQnV0IGZpcnN0LCB3ZSBuZWVkIHRvIGdldCB0aG9zZSByZXF1aXJlbWVudHMuDQo+Pj4g ZXhhY3RseSwNCj4+Pg0KPj4+IGJlZm9yZSBkaXNjdXNzaW5nIGFueSBzb2x1dGlvbiB3ZSBuZWVk IHRvIGZpbmQgcmVhbCBhcHBsaWNhdGlvbiBjYXNlcyAgDQo+Pj4gYW5kIGRldGVybWluZSB0aGll ciByZXF1aXJlbWVudHMNCj4+Pg0KPj4+IG9ubHkgdGhlbiB3ZSBjYW4gc3RhcnQgdGFsa2luZyBh Ym91dCBzb2x1dGlvbnMsIGJlY2F1c2Ugd2l0aG91dCB0aGVzZSAgDQo+Pj4gdXNlIGNhc2VzIGFu ZCByZXF1aXJlbWVudHMgd2UgY2Fubm90IGNvbXBhcmUgZXZhbHVhdGUgdGhlIGRkaWZmZXJlbnQg IA0KPj4+IHByb3Bvc2FscyB0aGF0IGFyZSBhcm91bmQuDQo+Pj4NCj4+PiBEbyB3ZSBhZ3JlZSB0 aGF0IGlkZW50aWZ5aW5nIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGlzIG5vdCBhIG5pY2Ug IA0KPj4+IHRvIGhhdmUgc3RlcCBidXQgd2UgbXVzdCBkbyB0aGlzIGJlZm9yZSBzdGFydCB3b3Jr aW5nIG9uIHNvbHV0aW9ucz8NCj4+Pg0KPj4gDQo+PiBUaGlzIEkgYWdyZWUgLi4uIGJ1dCBoYXZl bid0IFRoaWVycnkgYWxyZWFkeSBjb2xsZWN0ZWQgc29tZSBpbmZvcm1hdGlvbg0KPj4gZnJvbSBk aWZmZXJlbnQgaW5kdXN0cmllcz8gIEhlIHByZXNlbnRlZCB0aGVtIGluIE1vbnRyZWFsLg0KPiAN Cj4gWWVzLCBpdCdzIGF0DQo+IGh0dHA6Ly93d3cubW9iaWxlbmV0d29ya3Mub3JnL25lbW8vaWV0 ZjY2L25lbW8taWV0ZjY2LXNsaWRlcy5wZGYNCj4gcHAgMTItMTUNCj4gDQo+IEFsZXgNCj4gDQo+ IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBNZXNzYWdlOiA4 DQo+IERhdGU6IE1vbiwgMjUgU2VwIDIwMDYgMTU6NTU6NDUgKzAyMDANCj4gRnJvbTogVGhpZXJy eSBFcm5zdCA8dGhpZXJyeS5lcm5zdEBpbnJpYS5mcj4NCj4gU3ViamVjdDogUmU6IFtuZW1vXSBD aGFydGVyIHVwZGF0ZTogUk8gYmV0d2VlbiBNUiBhbmQgZm9yZWlnbiBhY2Nlc3MNCj4gbmV0d29y aw0KPiBUbzogbmVtb0BpZXRmLm9yZw0KPiBNZXNzYWdlLUlEOiA8MjAwNjA5MjUxNTU1NDUuNDEz ZjU5MzcudGhpZXJyeS5lcm5zdEBpbnJpYS5mcj4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWlu OyBjaGFyc2V0PUlTTy0yMDIyLUpQDQo+IA0KPiANCj4gSGkgTWFyY2VsbywNCj4gDQo+IFRydWUs IHRoYXQgd2FzIG15IGludGVudGlvbiBhdCBmaXJzdCBidXQgaXQgd2FzIGFsc28gcG9pbnRlZCBv dXQgdGhhdA0KPiBUSidzIGRyYWZ0IGNoYXJ0ZXIgd2FzIGEgZ29vZCBzdGFydCBhbmQgdGhhdCB3 ZSBzaG91bGQgZGV0YWlsIGl0IGZ1cnRoZXINCj4gYW5kIGJlIG1vcmUgZXhwbGljaXQuDQo+IA0K PiBUaGUgUk8gcHJvYmxlbSBpcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgMiBkcmFmdHMsIHNv IEkgdGhpbmsgaXQgaXMNCj4gd2VsbCB1bmRlcnN0b29kIGVub3VnaC4NCj4gDQo+IFJlZ2FyZGlu ZyB0aGUgdXNlIGNhc2VzLCB0aGVzZSB3b3VsZCBzdXJlbHkgaGVscCwgYnV0IGl0IGFwcGVhcnMg dGhhdA0KPiB3aGF0IGlzIG5lZWRlZCBieSB0aGUgYXZpYXRpb24gaW5kdXN0cnkgaXMgcHJldHR5 IGZhciBmcm9tIE5FTU8gQmFzaWMNCj4gU3VwcG9ydCAoaS5lLiBub3QgYSBtZXJlIG9wdGltaXph dGlvbikgYW5kIHRoZSBjYXIgaW5kdXN0cnkgaXMgc3RpbGwgaW4NCj4gdGhlIHByb2Nlc3Mgb2Yg dHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUgSUVURiBpcyAoYSBiaXQgbGlrZSAzR1BQIGEN Cj4gd2hpbGUgYWdvIGlmIHlvdSBzZWUgd2hhdCBJIG1lYW4pIHNvIEkgd291bGRuJ3QgZXhwZWN0 IHRoZW0gdG8gY29tZSB1cA0KPiB3aXRoIGEgY2xlYXIgZGVzY3JpcHRpb24gb2YgdGhlIHVzZSBj YXNlcyBpbiB0aGUgbmV4dCAyIHllYXJzICh0aG91Z2gNCj4gdGhleSBbPXNvbWUgb3JnYW5pemF0 aW9ucyBsaWtlIElTT10gRE8gd29yayBvbiBhbiBhcmNoaXRlY3R1cmUgYmFzZWQgb24NCj4gTkVN TyBhbmQgSVB2NiBidXQgYXJlIHN0aWxsIGZhciBmcm9tIHVuZGVyc3RhbmRpbmcgdGhlIElFVEYg Zm9sa3MgY291bGQNCj4gaGVscCBhbmQgc2F2ZSB0aGVtIHNvbWUgbWlzdGFrZXMgaW4gdGhlaXIg YXJjaGl0ZWN0dXJlKS4NCj4gDQo+IA0KPiBTbywgd2l0aCByZXNwZWN0IHRvIHdoYXQgeW91IGNv bmNsdWRlZCBiZWxvdywgdGhlIG5ldyBjaGFydGVyIGNvdWxkIGxpc3QNCj4gYXMgZGVsaXZlcmFi bGUgYSB1c2UgY2FzZSBkb2N1bWVudHMgKGJ1dCBpdCBpcyBtb3N0IGxpa2VseSB0byBiZQ0KPiBw cm9kdWNlZCBieSB1cyB0YXJnZXR0ZWQgdGhlIG9yZ2FuaXphdGlvbnMgc3VjaCBhcyBJU08gdGhh biB0aGUgb3RoZXINCj4gd2F5IHJvdW5kKSBhbmQgc29tZSBzb2x1dGlvbnMgZm9yIHRoZSBSTyBw cm9ibGVtIGluIHdoaWNoIHdlIGhhdmUNCj4gaWRlbnRpZmllZCBuZWVkcyAodGhlIDIgSSBsaXN0 ZWQpLCB3aGljaCBhcmUgcmVhc29uYWJseSBlYXN5IHRvIHNvbHZlLA0KPiBhbmQgZm9yIHdoaWNo IHdlIHBvc3NpYmx5IGhhdmUgY2FuZGlkYXRlIHNvbHV0aW9ucy4NCj4gDQo+IFRoaWVycnkNCj4g DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiBNb24sIDI1IFNlcCAyMDA2IDE1OjMz OjUwICswMjAwDQo+IG1hcmNlbG8gYmFnbnVsbyBicmF1biA8bWFyY2Vsb0BpdC51YzNtLmVzPiB3 cm90ZToNCj4gDQo+PiBIaSBUaGllcnJ5LA0KPj4gDQo+PiBJIHRob3VnaHQgdGhhdCB0aGUgbmV3 IGNoYXJ0ZXIgd291bGQgb25seSBiZSB0YXNrZWQgdG8gaWRlbnRpZnkgdGhlIHVzZSANCj4+IGNh c2VzIGFuZCByZXF1aXJlbWVudHMgYW5kIHRoYXQgZnV0dXJlIHJlY2hhcnRlcmluZyB3YXMgbmVl ZGVkIHRvIA0KPj4gYWN0dWFsbHkgZW50ZXIgaW4gdGhlIHNvbHV0aW9uIHNwYWNlLg0KPj4gDQo+ PiBBdCBsZWFzdCB0aGF0IHdhcyB3aGF0IGkgdW5kZXJzdG9vZCBmcm9tIHlvdXIgYW5zd2VyIGlu IHRoZSBsYXN0IA0KPj4gbWVldGluZyB3aGVuIHlvdSBzYWlkOg0KPj4gDQo+PiAiICBUaGllcnJ5 Og0KPj4gICAgICAgRm9yIHRoZSBuZXcgY2hhcnRlciwgSSB3b3VsZCBoYXZlIGEgZG9jIG9uIHVz ZS1jYXNlLCBhbmQgdGhhdCdzIA0KPj4gaXQuIg0KPj4gDQo+PiAoZnJvbSB0aGUgbW9udHJlYWwg bWVldGluZyBpbiB0aGUgUk8gZGlzY3Vzc2lvbikNCj4+IA0KPj4gSSBkb24ndCBoYXZlIGEgcHJv YmxlbSB3aXRoIGRlYWxpbmcgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgeW91IA0KPj4gY29t bWVudCwgd2hpY2ggaSBndWVzcyBhcmUgdmFsaWQgcHJvYmxlbXMsIGJ1dCBteSB1bmRlcnN0YW5k aW5nIGlzIHRoYXQgDQo+PiB3ZSB3ZXJlIGdvaW5nIHRvIGRlc2NyaWJlIHRoZXNlIGluIGEgZG9j dWVtZW50IHRoYXQgd2FzIHRvIGJlIHByb2R1Y2VkIA0KPj4gYW5kIGRpc3Vjc3NlZCBpbiB0aGUg d2csIHJhdGhlciB0aGFuIGluIHRoZSBjaGFydGVyLi4uDQo+PiANCj4+IE15IHBvaW50IGlzLCBp IHdvdWxkIGluY2x1ZGUgYSBjaGFydGVyIGl0ZW0gdGhhdCBpcyB0byBwcm9kdWNlIGFuIElEIA0K Pj4gd2l0aCB0aGUgdXNlIGNhc2VzIChlLmcuIGNhciBpbmR1c3RyeSkgYW5kIHRoZWlyIHJlcXVp cmVtZW50cyAoZS5nLiANCj4+IHRob3NlIHlvdSBtZW50aW9uIGJlbG93KSByYXRoZXIgdGhhbiBp bmNsdWRpbmcgdGhlc2UgcmVxdWlyZW1lbnRzIGluIA0KPj4gdGhlIGNoYXJ0ZXIgaXRzZWxmLg0K Pj4gDQo+PiBCb3R0b20gbGluZSBpcyB0aGF0IGkgZ3Vlc3MgdGhhdCB0aGUgZGlzY3Vzc2lvbiBv ZiB0aGUgcmVxdWlyZW1lbnRzIA0KPj4gc2hvdWxkIG5vdCBiZSBwYXJ0IG9mIHRoZSBjaGFydGVy IGRpc2N1c2lvbiBidXQgcGFydCBvZiB0aGUgDQo+PiByZXF1aXJlbWVudHMvdXNlIGNhc2UgSUQg ZGlzY3Vzc2lvbi4NCj4+IA0KPj4gUmVnYXJkcywgbWFyY2Vsbw0KPj4gDQo+PiANCj4+IEVsIDI1 LzA5LzIwMDYsIGEgbGFzIDE1OjE3LCBUaGllcnJ5IEVybnN0IGVzY3JpYmnzOg0KPj4gDQo+PiA+ DQo+PiA+IERlYXIgYWxsLA0KPj4gPg0KPj4gPiBJIGhhdmUgYmVlbiBpbnZvbHZlZCBpbiBzb21l IGdyb3VwcyB3b3JraW5nIG9uIGNvbW11bmljYXRpb24gYmV0d2Vlbg0KPj4gPiB2ZWhpY2xlcyBh bmQgdGhlIHJvYWRzaWRlIGFuZCB2ZWhpY2xlLXZlaGljbGUgY29tbXVuaWNhdGlvbnMgdGhyb3Vn aA0KPj4gPiB0aGUgSW50ZXJuZXQuIEZvciB0aGVpciBzY2VuYXJpb3MsIDIgUk8gbmVlZHMgZW1l cmdlOg0KPj4gPg0KPj4gPiAxLiBUaGUgTVIgaW4gdGhlIHZlaGljbGUgc2hvdWxkIGJlIGFibGUg dG8gY29tbXVuaWNhdGUgd2l0aCBhIENOIG9uIHRoZQ0KPj4gPiByb2Fkc2lkZSB3aXRob3V0IGdv aW5nIHRocm91Z2ggdGhlIE1SLUhBIHR1bm5lbC4NCj4+ID4NCj4+ID4gMi4gQSBNUiBpbiBhIHZl aGljbGUgc2hvdWxkIGJlIGFibGUgdG8gY29tbXVuaWNhdGUgd2l0aCBhbm90aGVyIE1SIGluDQo+ PiA+IGFub3RoZXIgdmVoaWNsZSB2aWEgdGhlIEludGVybmV0IGluZnJhc3RydWN0dXJlIGJ1dCBw YWNrZXRzIGZsb3dpbmcgdmlhDQo+PiA+IHRoZSBIQXMgb2YgYm90aCBNUnMgc2hvdWxkIGJlIGF2 b2lkZWQuDQo+PiA+DQo+PiA+IE1heSBiZSB3ZSBjb3VsZCBoYXZlIHRoZXNlIGxpc3RlZCBpbiB0 aGUgbmV3IGNoYXJ0ZXIgbW9yZSBleHBsaWNpdGx5Lg0KPj4gPg0KPj4gPiBUaGllcnJ5Lg0KPj4g Pg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBPbiBUdWUsIDE5IFNlcCAyMDA2IDE5OjE4OjEwIC0w NzAwDQo+PiA+ICJULkouIEtuaXZldG9uIiA8dGpAa25pdmV0b24uY29tPiB3cm90ZToNCj4+ID4N Cj4+ID4+IEhpIGZvbGtzLCBJJ20gYmFjay4uDQo+PiA+Pg0KPj4gPj4gSGVyZSBpcyB0aGUgY3Vy cmVudCB2ZXJzaW9uIG9mIHRoZSBjaGFydGVyLiBJIGFtIHN0aWxsIG1ha2luZw0KPj4gPj4gY2hh bmdlcywgYW5kIG5lZWQgdG8gbW9kaWZ5IHRoZSBtaWxlc3RvbmVzIHNlY3Rpb24uIEJ1dCB3YW50 ZWQgdG8NCj4+ID4+IHNoYXJlIHdoYXQncyB0aGVyZSBub3cgYW5kIHNlZSBpZiB0aGVyZSBhcmUg YW55IGNvbW1lbnRzLg0KPj4gPj4NCj4+ID4+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIGRpcmVjdGx5 IHRvIG1lLCBmb3IgdGhlIG1vbWVudCwgYW5kIHdoZW4gSSBoYXZlDQo+PiA+PiB0aGUgbmV4dCB2 ZXJzaW9uIHdlIGNhbiBkaXNjdXNzIGl0IG9uIHRoZSBsaXN0Lg0KPj4gPj4NCj4+ID4+IGh0dHA6 Ly93d3cubW9iaWxlbmV0d29ya3Mub3JnL25lbW8vY2hhcnRlcjJfMy50eHQNCj4+ID4+DQo+PiA+ PiBUSg0KPj4gPj4NCj4+ID4NCj4+ID4NCj4+ID4gLS0gDQo+PiA+IFRoaWVycnkgRVJOU1QsIFBo RA0KPj4gPiBodHRwOi8vd3d3Lm5hdXRpbHVzNi5vcmcvfnRoaWVycnkNCj4+ID4gSUVURiBORU1P IFdHIENoYWlyLCBJRVRGIE1vbkFtaTYgQ2hhaXIsIE5hdXRpbHVzNiBDaGFpcg0KPj4gPiAtLQ0K Pj4gPiBJTlJJQSBSb2NxdWVuY291cnQgUHJvamVjdC1UZWFtIElNQVJBLCBGcmFuY2UuDQo+PiA+ ICszMyAxIDM5IDYzIDU5IDMwIChvZmZpY2UpDQo+PiA+DQo+PiA+DQo+PiANCj4+IA0KPj4gDQo+ IA0KPiANCj4gLS0gDQo+IFRoaWVycnkgRVJOU1QsIFBoRA0KPiBodHRwOi8vd3d3Lm5hdXRpbHVz Ni5vcmcvfnRoaWVycnkNCj4gSUVURiBORU1PIFdHIENoYWlyLCBJRVRGIE1vbkFtaTYgQ2hhaXIs IE5hdXRpbHVzNiBDaGFpcg0KPiAtLQ0KPiBJTlJJQSBSb2NxdWVuY291cnQgUHJvamVjdC1UZWFt IElNQVJBLCBGcmFuY2UuDQo+ICszMyAxIDM5IDYzIDU5IDMwIChvZmZpY2UpDQo+IA0KPiANCj4g DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5FTU8gbWFpbGluZyBsaXN0 DQo+IE5FTU9AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmVtbw0KPiANCj4gRW5kIG9mIE5FTU8gRGlnZXN0LCBWb2wgMjksIElzc3VlIDgNCj4gKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio= From nemo-bounces@ietf.org Mon Sep 25 22:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS2XD-0003Uf-MJ; Mon, 25 Sep 2006 22:18:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS2XC-0003Ua-3e for nemo@ietf.org; Mon, 25 Sep 2006 22:18:58 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS2X5-0002g9-Rd for nemo@ietf.org; Mon, 25 Sep 2006 22:18:58 -0400 Received: from [203.178.139.215] (wifi-139-215.sfc.wide.ad.jp [203.178.139.215]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id AD48D4D95E for ; Tue, 26 Sep 2006 11:18:35 +0900 (JST) Message-ID: <45188DFB.9030002@sfc.wide.ad.jp> Date: Tue, 26 Sep 2006 11:18:35 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] Charter update: RO between MR and foreign access network References: <20060925151736.368a398d.thierry.ernst@inria.fr> In-Reply-To: <20060925151736.368a398d.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: nemo-bounces@ietf.org Dear Thierry, Thierry Ernst wrote: > Dear all, > > I have been involved in some groups working on communication between > vehicles and the roadside and vehicle-vehicle communications through > the Internet. For their scenarios, 2 RO needs emerge: > > 1. The MR in the vehicle should be able to communicate with a CN on the > roadside without going through the MR-HA tunnel. > > 2. A MR in a vehicle should be able to communicate with another MR in > another vehicle via the Internet infrastructure but packets flowing via > the HAs of both MRs should be avoided. > In both case RFC3963 allows the MR to use RO with a CN or another MR for its own local traffic. To avoid some confusion, I think it would be better to describe the requirements from the MNN point of view. Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Mon Sep 25 22:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS2Wi-0003JD-9a; Mon, 25 Sep 2006 22:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS2Wh-0003J8-EM for nemo@ietf.org; Mon, 25 Sep 2006 22:18:27 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS2Wf-0002ed-Rv for nemo@ietf.org; Mon, 25 Sep 2006 22:18:27 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8Q2I4CF019554; Tue, 26 Sep 2006 11:18:04 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k8Q2I6x29316; Tue, 26 Sep 2006 11:18:06 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k8Q2I0l17465; Tue, 26 Sep 2006 11:18:01 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 10:16:51 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 4F653D4221; Tue, 26 Sep 2006 10:19:56 +0800 (SGT) Subject: Re: [nemo] Re: RO for geographically dist'd HAs From: Chan-Wah Ng To: Vijay Devarapalli In-Reply-To: <4517EBAE.1020303@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 26 Sep 2006 10:19:55 +0800 Message-Id: <1159237195.982.305.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 26 Sep 2006 02:16:51.0550 (UTC) FILETIME=[D41557E0:01C6E111] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: marcelo bagnulo braun , ml-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: , Errors-To: nemo-bounces@ietf.org Hello Vijay, On Mon, 2006-09-25 at 07:46 -0700, Vijay Devarapalli wrote: > marcelo bagnulo braun wrote: > > So i would suggest to remove the item > > > > Submit -00 draft on Route Optimization for geographically distributed HAs > > disagree. the "geographically distributed HAs" was a > much more specific problem. it is not intended to be > a general purpose route optimization solution. even > when you have a route optimization solution, you > would still need something to address distributed HAs. > I actually dont mind removing the word "Route > Optimization" from the above sentence. the fact is it > does some sort of route optimization as a side effect. > and it doesn't involve the mobile routers in route > optimization. thats a good feature. :) > Perhaps Geographically Distributed HA has aspects which is not related to RO, but it has nothing specific to NEMO. MIP6 WG is already starting to look at HA reliability etc. If the item is not presented as an RO approach to the RO problem (which arguably would benefit NEMO more since it scales better with NEMO than with mobile hosts), I see no reason why NEMO WG should work on it. /rgds /cwng From nemo-bounces@ietf.org Mon Sep 25 23:12:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3MK-0002dN-Uu; Mon, 25 Sep 2006 23:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3MK-0002dI-3z for nemo@ietf.org; Mon, 25 Sep 2006 23:11:48 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS3MI-0003yj-FK for nemo@ietf.org; Mon, 25 Sep 2006 23:11:48 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6600CKTKDJLV@szxga02-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 11:29:43 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6600MNLKDIUR@szxga02-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 11:29:43 +0800 (CST) Received: from h50541 ([10.164.46.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6600GMGK3P7Z@szxml04-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 11:23:50 +0800 (CST) Date: Tue, 26 Sep 2006 11:10:52 +0800 From: Andy Huang Subject: Re: [nemo] Charter update: RO between MR and foreign access network To: Romain KUNTZ , nemo@ietf.org Message-id: <015301c6e119$602fb890$1d2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060925151736.368a398d.thierry.ernst@inria.fr> <45188DFB.9030002@sfc.wide.ad.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 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: , Errors-To: nemo-bounces@ietf.org I agree with you on the point that it will be better to replace MR with MNN in the requirements. But is there anything related to RO in RFC3963? I don't see anything about it. ----- Original Message ----- From: "Romain KUNTZ" To: Sent: Tuesday, September 26, 2006 10:18 AM Subject: Re: [nemo] Charter update: RO between MR and foreign access network > Dear Thierry, > > Thierry Ernst wrote: >> Dear all, >> >> I have been involved in some groups working on communication between >> vehicles and the roadside and vehicle-vehicle communications through >> the Internet. For their scenarios, 2 RO needs emerge: >> >> 1. The MR in the vehicle should be able to communicate with a CN on the >> roadside without going through the MR-HA tunnel. 2. A MR in a vehicle >> should be able to communicate with another MR in >> another vehicle via the Internet infrastructure but packets flowing via >> the HAs of both MRs should be avoided. >> > > In both case RFC3963 allows the MR to use RO with a CN or another MR for > its own local traffic. To avoid some confusion, I think it would be better > to describe the requirements from the MNN point of view. > > Regards, > > -- > Romain KUNTZ > kuntz@sfc.wide.ad.jp > > From nemo-bounces@ietf.org Mon Sep 25 23:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3Vg-0007Bc-Kf; Mon, 25 Sep 2006 23:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3Vf-00079j-Aj for nemo@ietf.org; Mon, 25 Sep 2006 23:21:27 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS3VZ-0005Kh-M6 for nemo@ietf.org; Mon, 25 Sep 2006 23:21:27 -0400 Received: from [203.178.139.215] (wifi-139-215.sfc.wide.ad.jp [203.178.139.215]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id BC5004D82F for ; Tue, 26 Sep 2006 12:21:01 +0900 (JST) Message-ID: <45189C9D.1000706@sfc.wide.ad.jp> Date: Tue, 26 Sep 2006 12:21:01 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] Charter update: RO between MR and foreign access network References: <20060925151736.368a398d.thierry.ernst@inria.fr> <45188DFB.9030002@sfc.wide.ad.jp> <015301c6e119$602fb890$1d2ea40a@china.huawei.com> In-Reply-To: <015301c6e119$602fb890$1d2ea40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: nemo-bounces@ietf.org Hello, In section 1: All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. This document does not describe route optimization of this traffic. In section 3: For traffic originated by itself, the Mobile Router can use either reverse tunneling or route optimization, as specified in [RFC3775]. romain Andy Huang wrote: > I agree with you on the point that it will be better to replace MR with > MNN in the requirements. > But is there anything related to RO in RFC3963? I don't see anything > about it. > > ----- Original Message ----- From: "Romain KUNTZ" > To: > Sent: Tuesday, September 26, 2006 10:18 AM > Subject: Re: [nemo] Charter update: RO between MR and foreign access > network > > >> Dear Thierry, >> >> Thierry Ernst wrote: >>> Dear all, >>> >>> I have been involved in some groups working on communication between >>> vehicles and the roadside and vehicle-vehicle communications through >>> the Internet. For their scenarios, 2 RO needs emerge: >>> >>> 1. The MR in the vehicle should be able to communicate with a CN on the >>> roadside without going through the MR-HA tunnel. 2. A MR in a vehicle >>> should be able to communicate with another MR in >>> another vehicle via the Internet infrastructure but packets flowing via >>> the HAs of both MRs should be avoided. >>> >> >> In both case RFC3963 allows the MR to use RO with a CN or another MR >> for its own local traffic. To avoid some confusion, I think it would >> be better to describe the requirements from the MNN point of view. >> >> Regards, >> >> -- >> Romain KUNTZ >> kuntz@sfc.wide.ad.jp >> >> > > > -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Mon Sep 25 23:22:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3Ws-0007dR-7S; Mon, 25 Sep 2006 23:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3Wq-0007cV-4b for nemo@ietf.org; Mon, 25 Sep 2006 23:22:40 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS3Wm-0005fT-Hh for nemo@ietf.org; Mon, 25 Sep 2006 23:22:40 -0400 Message-ID: <008a01c6e11b$329526c0$5e6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "marcelo bagnulo braun" , "Eranga Perera" References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) Date: Mon, 25 Sep 2006 20:23:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: ml-nemo WG , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org I agree. I think it would be worthwhile identifying actual customers for = RO=20 before putting it in the charter. If there is work that needs to be done in advance of any actual need, I=20 think that it could be done in IRTF, perhaps in the MOBOPTS RG. jak ----- Original Message -----=20 From: "marcelo bagnulo braun" To: "Eranga Perera" Cc: "ml-nemo WG" ; "T.J. Kniveton" ;=20 "Alexandru Petrescu" Sent: Monday, September 25, 2006 2:32 AM Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter=20 update,continued) I am afraid i disagree completelly, I we cannot find users for the RO solutions we shouldn't be working on this and we should close the wg until a real problem is identified. defining solution when we don't have any users that need it, makes no sense to me potential users are the ones that define the problem and provide requirements, not merely opinions. Regards, marcelo El 25/09/2006, a las 10:59, Eranga Perera escribi=F3: > > > As for opinions from actual users of RO solutions would be good. Howev= er,=20 > if such comments are not forthcoming, then I don't think it is a too=20 > difficult task to come up with realistic scenarios and requirements. > > The point is by only rechartering for handling geographically distribu= ted=20 > HAs, other cases can not be voiced at all. > > -eranga > > > > > -----Original Message----- > > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > Sent: Monday, 25 September 2006 6:37 PM > > To: Eranga Perera > > Cc: Alexandru Petrescu; ml-nemo WG; T.J. Kniveton > > Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > > update,continued) > > > > > > El 25/09/2006, a las 10:25, Eranga Perera escribi=F3: > > > > > > > > Marcelo, > > > I fully agree with your suggestion. This way everyone will get a > > > chance to voice out what they think needs addressing within the > scope > > > of RO. > > > > > > > a subtle point here, i would prefer to hear from actual potential > users > > of the RO solutions (like the people from the aviation or car > industry > > or others) rather than random opinions about what different apporach > > should be better in the abstract > > > > i mean, what i would think is that way forward, i to get the > potential > > users, like aviation or car industry, to define their problem and the > > requirements in an draft and then based on this define solutions for > > the identified problems > > > > that i what i think should be in the charter, itmes to produce > > scenarrios and requiremets for RO > > > > Regards, marcelo > > > > > > > > > Cheers, > > > Eranga > > > > > >> -----Original Message----- > > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > >> Sent: Monday, 25 September 2006 6:16 PM > > >> To: Alexandru Petrescu > > >> Cc: ml-nemo WG; T.J. Kniveton > > >> Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter > > >> update,continued) > > >> > > >> My understanding of the comments in the last meeting was that we > were > > >> going _first_ to identify what are the relevant scenarios for > which we > > >> need to design RO solutions and their requirements and only > _after_ > > >> that we are going to work in actual solutions. > > >> > > >> I mean, my recollection of Thierry's suggestion was to have a > first > > >> rechartering where we include items about identifying relevant > > >> scenarios and requirements for RO and when this is done a new > > >> recharter, to include the design of solutions for the identified > > >> scenarios > > >> > > >> As i previously mentioned here, i think it is very hard to > evaluate > > >> how > > >> approapriate a solution is if we don't have explicitly fleshed out > > >> what > > >> the problem and requiremnets are > > >> > > >> So i would suggest to remove the item > > >> > > >> Submit -00 draft on Route Optimization for geographically > distributed > > >> HAs > > >> > > >> And to include an item about providing a new ID -00 about > identifying > > >> scenarios and requirements for RO > > >> > > >> Regards, marcelo > > >> > > >> > > >> El 22/09/2006, a las 11:34, Alexandru Petrescu escribi=F3: > > >> > > >>> T.J. Kniveton wrote: > > >>>> Hi folks, I'm back.. > > >>>> Here is the current version of the charter. I am still making > > >>>> changes, and need to modify the milestones section. But wanted > to > > >>>> share what's there now and see if there are any comments. > > >>>> Please send comments directly to me, for the moment, and when I > have > > >>>> the next version we can discuss it on the list. > > >>>> http://www.mobilenetworks.org/nemo/charter2_3.txt > > >>> > > >>> Another remark on the Charter2_3. It has an item: > > >>> "??? 2006 Submit -00 draft on Route Optimization for > > >>> geographically distributed HAs" > > >>> > > >>> However, this is not currently a WG item (so can't be considered > as > > >>> "finishing ongoing WG documents") and has no other textual > > >>> description > > >>> in charter2_3. What is it about? Is it > > >>> draft-wakikawa-mip6-nemo-haha-01.txt or > > >>> draft-wakikawa-mip6-nemo-haha-spec-00? > > >>> > > >>> We've had a long discussion previously about the need and > feasibility > > >>> of > > >>> HAHA protocols. There may have been many conclusions, I don't > > >>> remember > > >>> all. > > >>> > > >>> Alex > > >>> > > >> > > > > > > > > > > > > > ----------------------------------------------------------------------- > > > --- > > > This email and any attachments may be confidential. They may > contain > > > legally > > > privileged information or copyright material. You should not read, > > > copy, > > > use or disclose them without authorisation. If you are not an > intended > > > recipient, please contact us at once by return email and then > delete > > > both > > > messages. We do not accept liability in connection with computer > virus, > > > data corruption, delay, interruption, unauthorised access or > > > unauthorised > > > amendment. This notice should not be removed. > > > > From nemo-bounces@ietf.org Mon Sep 25 23:25:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3Zq-0000iO-39; Mon, 25 Sep 2006 23:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3Zo-0000iJ-GM for nemo@ietf.org; Mon, 25 Sep 2006 23:25:44 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS3Zm-0005yv-SE for nemo@ietf.org; Mon, 25 Sep 2006 23:25:44 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J66000T5KIUIP@szxga03-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 11:32:54 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6600BAVKIT8S@szxga03-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 11:32:54 +0800 (CST) Received: from h50541 ([10.164.46.29]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J66005APK93FI@szxml03-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 11:27:04 +0800 (CST) Date: Tue, 26 Sep 2006 11:21:46 +0800 From: Andy Huang Subject: Re: [nemo] Re: RO for geographically dist'd HAs To: Chan-Wah Ng , Vijay Devarapalli Message-id: <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: marcelo bagnulo braun , ml-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: , Errors-To: nemo-bounces@ietf.org ----- Original Message ----- From: "Chan-Wah Ng" To: "Vijay Devarapalli" Cc: "marcelo bagnulo braun" ; "ml-nemo WG" ; "T.J. Kniveton" Sent: Tuesday, September 26, 2006 10:19 AM Subject: Re: [nemo] Re: RO for geographically dist'd HAs > Hello Vijay, > > On Mon, 2006-09-25 at 07:46 -0700, Vijay Devarapalli wrote: >> marcelo bagnulo braun wrote: >> > So i would suggest to remove the item >> > >> > Submit -00 draft on Route Optimization for geographically distributed >> > HAs >> >> disagree. the "geographically distributed HAs" was a >> much more specific problem. it is not intended to be >> a general purpose route optimization solution. even >> when you have a route optimization solution, you >> would still need something to address distributed HAs. > >> I actually dont mind removing the word "Route >> Optimization" from the above sentence. the fact is it >> does some sort of route optimization as a side effect. >> and it doesn't involve the mobile routers in route >> optimization. thats a good feature. :) >> > > Perhaps Geographically Distributed HA has aspects which is not related > to RO, but it has nothing specific to NEMO. MIP6 WG is already starting > to look at HA reliability etc. If the item is not presented as an RO > approach to the RO problem (which arguably would benefit NEMO more since > it scales better with NEMO than with mobile hosts), I see no reason why > NEMO WG should work on it. > > /rgds > /cwng > > In fact, a WG draft has been designed by DT in MIP6 WG. https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-00.txt Do you think we need a especial HA reliability protocol for NEMO? From nemo-bounces@ietf.org Mon Sep 25 23:30:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3es-0003Vi-IB; Mon, 25 Sep 2006 23:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS3er-0003Vd-NG for nemo@ietf.org; Mon, 25 Sep 2006 23:30:57 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS3en-0006Vs-9l for nemo@ietf.org; Mon, 25 Sep 2006 23:30:57 -0400 Message-ID: <00be01c6e11c$5b2df430$5e6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Thierry Ernst" , References: <20060925151736.368a398d.thierry.ernst@inria.fr> Subject: Re: [nemo] Charter update: RO between MR and foreign access network Date: Mon, 25 Sep 2006 20:32:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 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: , Errors-To: nemo-bounces@ietf.org This looks like a good start for a more specific set of requirements for RO. I don't think these requirements necessarily need to be in the charter, but I think the charter could be made more specific with respect to what particular cases will be used, for example this one. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Monday, September 25, 2006 6:17 AM Subject: [nemo] Charter update: RO between MR and foreign access network > > Dear all, > > I have been involved in some groups working on communication between > vehicles and the roadside and vehicle-vehicle communications through > the Internet. For their scenarios, 2 RO needs emerge: > > 1. The MR in the vehicle should be able to communicate with a CN on the > roadside without going through the MR-HA tunnel. > > 2. A MR in a vehicle should be able to communicate with another MR in > another vehicle via the Internet infrastructure but packets flowing via > the HAs of both MRs should be avoided. > > May be we could have these listed in the new charter more explicitly. > > Thierry. > > > > > On Tue, 19 Sep 2006 19:18:10 -0700 > "T.J. Kniveton" wrote: > >> Hi folks, I'm back.. >> >> Here is the current version of the charter. I am still making >> changes, and need to modify the milestones section. But wanted to >> share what's there now and see if there are any comments. >> >> Please send comments directly to me, for the moment, and when I have >> the next version we can discuss it on the list. >> >> http://www.mobilenetworks.org/nemo/charter2_3.txt >> >> TJ >> > > > -- > Thierry ERNST, PhD > http://www.nautilus6.org/~thierry > IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair > -- > INRIA Rocquencourt Project-Team IMARA, France. > +33 1 39 63 59 30 (office) > > From nemo-bounces@ietf.org Tue Sep 26 00:08:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS4FQ-0004NA-0h; Tue, 26 Sep 2006 00:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS4FP-0004N4-Ay for nemo@ietf.org; Tue, 26 Sep 2006 00:08:43 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS4FN-0003SQ-Lg for nemo@ietf.org; Tue, 26 Sep 2006 00:08:43 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8Q48XCk019475; Tue, 26 Sep 2006 13:08:33 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k8Q48Zx02466; Tue, 26 Sep 2006 13:08:35 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id k8Q48W105967; Tue, 26 Sep 2006 13:08:33 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 12:07:39 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 53F96D4221; Tue, 26 Sep 2006 12:10:44 +0800 (SGT) Subject: Re: [nemo] Re: RO for geographically dist'd HAs From: Chan-Wah Ng To: Andy Huang In-Reply-To: <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 26 Sep 2006 12:10:43 +0800 Message-Id: <1159243843.982.317.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 26 Sep 2006 04:07:39.0436 (UTC) FILETIME=[4E883EC0:01C6E121] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: marcelo bagnulo braun , ml-nemo WG , "T.J. Kniveton" , 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: , Errors-To: nemo-bounces@ietf.org Hello Andy On Tue, 2006-09-26 at 11:21 +0800, Andy Huang wrote: > > Hello Vijay, > > > > On Mon, 2006-09-25 at 07:46 -0700, Vijay Devarapalli wrote: > >> marcelo bagnulo braun wrote: > >> > So i would suggest to remove the item > >> > > >> > Submit -00 draft on Route Optimization for geographically distributed > >> > HAs > >> > >> disagree. the "geographically distributed HAs" was a > >> much more specific problem. it is not intended to be > >> a general purpose route optimization solution. even > >> when you have a route optimization solution, you > >> would still need something to address distributed HAs. > > > >> I actually dont mind removing the word "Route > >> Optimization" from the above sentence. the fact is it > >> does some sort of route optimization as a side effect. > >> and it doesn't involve the mobile routers in route > >> optimization. thats a good feature. :) > >> > > > > Perhaps Geographically Distributed HA has aspects which is not related > > to RO, but it has nothing specific to NEMO. MIP6 WG is already starting > > to look at HA reliability etc. If the item is not presented as an RO > > approach to the RO problem (which arguably would benefit NEMO more since > > it scales better with NEMO than with mobile hosts), I see no reason why > > NEMO WG should work on it. > In fact, a WG draft has been designed by DT in MIP6 WG. > https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-00.txt > > Do you think we need a especial HA reliability protocol for NEMO? > At a first glance, I don't see why NEMO need something different. Unless someone is deploying a home agent inside a mobile network, as illustrated in the nemo-use-case and nemo-ro-ps drafts. /rgds /cwng From nemo-bounces@ietf.org Tue Sep 26 02:01:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS60W-0007cS-Nh; Tue, 26 Sep 2006 02:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS60V-0007cK-Ov for nemo@ietf.org; Tue, 26 Sep 2006 02:01:27 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS60U-0002fu-D9 for nemo@ietf.org; Tue, 26 Sep 2006 02:01:27 -0400 Received: from [10.1.210.12] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 22:59:45 -0700 Message-ID: <4518C1CD.9050502@azairenet.com> Date: Mon, 25 Sep 2006 22:59:41 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andy Huang Subject: Re: [nemo] Re: RO for geographically dist'd HAs References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> In-Reply-To: <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2006 05:59:45.0202 (UTC) FILETIME=[F766B120:01C6E130] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ml-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: , Errors-To: nemo-bounces@ietf.org sigh... this is the third or the fourth time I am sending the following to the NEMO mailing list. people should really look up the archives before sending mails. there was one spec to start with. it was called the HAHA protocol. then it was split into three. one was base HAHA which defined messages that are exchanged between two home agents for binding cache sync, hello messages, etc. the second was local HAHA for HA reliability. third was global HAHA for geographically distributed HAs. note that all of them contribute to how the MIP6/NEMO home network is configured and operates. the base HAHA and the local HAHA contributed towards the HA reliability protocol that is being standardized in the MIP6 WG. the spec in the MIP6 WG assumes the HAs are still on the same home link. geographically distributed HAs are not addressed in that spec. there has always been a lot of interest in global HAHA in the NEMO WG whenever it has been presented. that is why it still appears in the NEMO WG. Andy Huang wrote: > In fact, a WG draft has been designed by DT in MIP6 WG. > https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-00.txt > > Do you think we need a especial HA reliability protocol for NEMO? if you take a look at the drafts, the messages used by global HA would be the same as the ones defined in draft-ietf-mip6-hareliability. the current DT draft does not address geographically distributed HAs. Vijay From nemo-bounces@ietf.org Tue Sep 26 02:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS6hP-0003uk-6T; Tue, 26 Sep 2006 02:45:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS6hN-0003ta-45 for nemo@ietf.org; Tue, 26 Sep 2006 02:45:45 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS6Zp-0006JQ-I8 for nemo@ietf.org; Tue, 26 Sep 2006 02:37:59 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k8Q6bj8n015403; Tue, 26 Sep 2006 15:37:45 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k8Q6bkM10649; Tue, 26 Sep 2006 15:37:46 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id k8Q6bid09869; Tue, 26 Sep 2006 15:37:44 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 14:36:50 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 5D054D4221; Tue, 26 Sep 2006 14:39:56 +0800 (SGT) Subject: Re: [nemo] Re: RO for geographically dist'd HAs From: Chan-Wah Ng To: Vijay Devarapalli In-Reply-To: <4518C1CD.9050502@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 26 Sep 2006 14:39:55 +0800 Message-Id: <1159252795.982.329.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 26 Sep 2006 06:36:50.0822 (UTC) FILETIME=[25F95A60:01C6E136] X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ml-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: , Errors-To: nemo-bounces@ietf.org On Mon, 2006-09-25 at 22:59 -0700, Vijay Devarapalli wrote: > sigh... this is the third or the fourth time I > am sending the following to the NEMO mailing > list. people should really look up the archives > before sending mails. > > there was one spec to start with. it was called > the HAHA protocol. then it was split into three. > one was base HAHA which defined messages that > are exchanged between two home agents for > binding cache sync, hello messages, etc. the > second was local HAHA for HA reliability. third > was global HAHA for geographically distributed > HAs. note that all of them contribute to how the > MIP6/NEMO home network is configured and > operates. > > the base HAHA and the local HAHA contributed > towards the HA reliability protocol that is > being standardized in the MIP6 WG. the spec in > the MIP6 WG assumes the HAs are still on the > same home link. geographically distributed HAs > are not addressed in that spec. > > there has always been a lot of interest in global > HAHA in the NEMO WG whenever it has been presented. > that is why it still appears in the NEMO WG. > > Andy Huang wrote: > > > In fact, a WG draft has been designed by DT in MIP6 WG. > > https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-00.txt > > > > Do you think we need a especial HA reliability protocol for NEMO? > > if you take a look at the drafts, the messages > used by global HA would be the same as the ones > defined in draft-ietf-mip6-hareliability. the > current DT draft does not address geographically > distributed HAs. > > Vijay > Hello Vijay, Thanks for clarifying ... and for sending the same mail 3 or 4 times :) However, it changes nothing. Global HAHA has nothing NEMO specific in terms of reliability (except when a HA is in a mobile network). In fact, since the base messages and the local scope version of the spec are being developed in MIP6, I seriously don't see any reason why the global version should be done in NEMO and not MIP6. Note that the above comment is in response to the treatment of Global HAHA as a HA reliability mechanism. If instead we are looking at route optimization problem, I would agree to looking into something I called "Infrastructure-based RO" where Global HAHA is clearly a candidate, but it shouldn't be identified as a charter item. /rgds /cwng From nemo-bounces@ietf.org Tue Sep 26 02:49:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS6lG-0005bT-Jw; Tue, 26 Sep 2006 02:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS6lE-0005bO-3t for nemo@ietf.org; Tue, 26 Sep 2006 02:49:44 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS6lC-0007XN-HA for nemo@ietf.org; Tue, 26 Sep 2006 02:49:44 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J66005JPUBO44@szxga02-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 15:04:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6600C5AUBN3B@szxga02-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 15:04:36 +0800 (CST) Received: from h50541 ([10.164.46.29]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6600A8CTP09C@szxml03-in.huawei.com> for nemo@ietf.org; Tue, 26 Sep 2006 14:51:01 +0800 (CST) Date: Tue, 26 Sep 2006 14:45:45 +0800 From: Andy Huang Subject: Re: [nemo] Re: RO for geographically dist'd HAs To: Vijay Devarapalli Message-id: <01c801c6e137$64da3230$1d2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ml-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: , Errors-To: nemo-bounces@ietf.org Hi, Vijay: I did remember you had explained the history of HAHA protocol when people discussed the proposed charter and global HAHA protocol in April. You emphasized that global HAHA is not a general RO solution for NEMO and RO is a side effect last time. It seems to me that there has been a kind of consensus about it at that time. Maybe I made a mistake. Regarding the proposed charter: 'Submit -00 draft on Route Optimization for geographically distributed HAs' Why do we discuss the same question once again? ----- Original Message ----- From: "Vijay Devarapalli" To: "Andy Huang" Cc: "Chan-Wah Ng" ; "ml-nemo WG" Sent: Tuesday, September 26, 2006 1:59 PM Subject: Re: [nemo] Re: RO for geographically dist'd HAs > sigh... this is the third or the fourth time I > am sending the following to the NEMO mailing > list. people should really look up the archives > before sending mails. > > there was one spec to start with. it was called > the HAHA protocol. then it was split into three. > one was base HAHA which defined messages that > are exchanged between two home agents for > binding cache sync, hello messages, etc. the > second was local HAHA for HA reliability. third > was global HAHA for geographically distributed > HAs. note that all of them contribute to how the > MIP6/NEMO home network is configured and > operates. > > the base HAHA and the local HAHA contributed > towards the HA reliability protocol that is > being standardized in the MIP6 WG. the spec in > the MIP6 WG assumes the HAs are still on the > same home link. geographically distributed HAs > are not addressed in that spec. > > there has always been a lot of interest in global > HAHA in the NEMO WG whenever it has been presented. > that is why it still appears in the NEMO WG. > > Andy Huang wrote: > >> In fact, a WG draft has been designed by DT in MIP6 WG. >> https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-00.txt >> >> Do you think we need a especial HA reliability protocol for NEMO? > > if you take a look at the drafts, the messages > used by global HA would be the same as the ones > defined in draft-ietf-mip6-hareliability. the > current DT draft does not address geographically > distributed HAs. > > Vijay > From nemo-bounces@ietf.org Tue Sep 26 03:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7Ar-00060u-0k; Tue, 26 Sep 2006 03:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7Ap-00060o-Lb for nemo@ietf.org; Tue, 26 Sep 2006 03:16:11 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS7Al-0002lw-1v for nemo@ietf.org; Tue, 26 Sep 2006 03:16:11 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0A399E2F35; Tue, 26 Sep 2006 09:16:06 +0200 (CEST) Received: from [163.117.203.240] (unknown [163.117.203.240]) by smtp01.uc3m.es (Postfix) with ESMTP id 0E52CE2F3E; Tue, 26 Sep 2006 09:16:04 +0200 (CEST) In-Reply-To: <00be01c6e11c$5b2df430$5e6015ac@dcml.docomolabsusa.com> References: <20060925151736.368a398d.thierry.ernst@inria.fr> <00be01c6e11c$5b2df430$5e6015ac@dcml.docomolabsusa.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1df9b932d070a49fde8efa5da88f37f5@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Charter update: RO between MR and foreign access network Date: Tue, 26 Sep 2006 09:16:50 +0200 To: "James Kempf" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: nemo@ietf.org, 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: , Errors-To: nemo-bounces@ietf.org El 26/09/2006, a las 5:32, James Kempf escribi=F3: > This looks like a good start for a more specific set of requirements=20= > for RO. I don't think these requirements necessarily need to be in the=20= > charter, but I think the charter could be made more specific with=20 > respect to what particular cases will be used, actually, in the last meeting in montreal, the consesous was that the=20 only item added to the charter was to identify RO use cases (like=20 aviation, or car industry) and define the specific requirements for the=20= identified use cases. After we have done that, we could recharter again the wg to produce the=20= actual RO solutions. At this point we would be in a very good shape to=20= select among the over a dozens RO proposals, since we would have the=20 requirements docuemtns as a selection criteria. This would allow us to: - produce solutions that have potential users and suit their=20 requirements - have an easy procedure to select among the existent proposals. I think this approach is much better than having the discussion on the=20= requirements now and include them in the charter, since i think that=20 the definition of requirements needs the review of a RFC rather than=20 the time required by a charter discussion Regards, marcelo > for example this one. > > jak > > ----- Original Message ----- From: "Thierry Ernst"=20 > > To: > Sent: Monday, September 25, 2006 6:17 AM > Subject: [nemo] Charter update: RO between MR and foreign access=20 > network > > >> >> Dear all, >> >> I have been involved in some groups working on communication between >> vehicles and the roadside and vehicle-vehicle communications through >> the Internet. For their scenarios, 2 RO needs emerge: >> >> 1. The MR in the vehicle should be able to communicate with a CN on=20= >> the >> roadside without going through the MR-HA tunnel. >> >> 2. A MR in a vehicle should be able to communicate with another MR in >> another vehicle via the Internet infrastructure but packets flowing=20= >> via >> the HAs of both MRs should be avoided. >> >> May be we could have these listed in the new charter more explicitly. >> >> Thierry. >> >> >> >> >> On Tue, 19 Sep 2006 19:18:10 -0700 >> "T.J. Kniveton" wrote: >> >>> Hi folks, I'm back.. >>> >>> Here is the current version of the charter. I am still making >>> changes, and need to modify the milestones section. But wanted to >>> share what's there now and see if there are any comments. >>> >>> Please send comments directly to me, for the moment, and when I have >>> the next version we can discuss it on the list. >>> >>> http://www.mobilenetworks.org/nemo/charter2_3.txt >>> >>> TJ >>> >> >> >> --=20 >> Thierry ERNST, PhD >> http://www.nautilus6.org/~thierry >> IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair >> -- >> INRIA Rocquencourt Project-Team IMARA, France. >> +33 1 39 63 59 30 (office) >> > > From nemo-bounces@ietf.org Tue Sep 26 03:20:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7El-0008WA-7t; Tue, 26 Sep 2006 03:20:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7Ej-0008Vb-DO for nemo@ietf.org; Tue, 26 Sep 2006 03:20:13 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS7Ei-0003Kv-1e for nemo@ietf.org; Tue, 26 Sep 2006 03:20:13 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 757B8E2FBA; Tue, 26 Sep 2006 09:20:11 +0200 (CEST) Received: from [163.117.203.240] (unknown [163.117.203.240]) by smtp01.uc3m.es (Postfix) with ESMTP id CA00AE2F72; Tue, 26 Sep 2006 09:20:08 +0200 (CEST) In-Reply-To: <4518C1CD.9050502@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Tue, 26 Sep 2006 09:20:54 +0200 To: Vijay Devarapalli X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ml-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: , Errors-To: nemo-bounces@ietf.org Hi Vijay, El 26/09/2006, a las 7:59, Vijay Devarapalli escribi=F3: > the base HAHA and the local HAHA contributed > towards the HA reliability protocol that is > being standardized in the MIP6 WG. the spec in > the MIP6 WG assumes the HAs are still on the > same home link. geographically distributed HAs > are not addressed in that spec. > so if the goal of global haha is neither RO and nor HA reliability, =20 what is the goal of global haha? I mean, my understanding is that the goal of global haha is reliabilty =20= when you have has distributed geographycally, but this is still HA =20 reliability, right? so, probably it makes sense to do all the work on reliability in the =20 same wg... regards, marcelo > there has always been a lot of interest in global > HAHA in the NEMO WG whenever it has been presented. > that is why it still appears in the NEMO WG. > > Andy Huang wrote: > >> In fact, a WG draft has been designed by DT in MIP6 WG. >> https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability=20 >> -00.txt >> >> Do you think we need a especial HA reliability protocol for NEMO? > > if you take a look at the drafts, the messages > used by global HA would be the same as the ones > defined in draft-ietf-mip6-hareliability. the > current DT draft does not address geographically > distributed HAs. > > Vijay > From nemo-bounces@ietf.org Tue Sep 26 05:04:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS8qs-000484-Gp; Tue, 26 Sep 2006 05:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS8qr-00047z-0s for nemo@ietf.org; Tue, 26 Sep 2006 05:03:41 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS8qn-0006M3-OK for nemo@ietf.org; Tue, 26 Sep 2006 05:03:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Sep 2006 02:03:38 -0700 X-IronPort-AV: i="4.09,219,1157353200"; d="scan'208"; a="43604593:sNHT32548984" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8Q93bU6032532; Tue, 26 Sep 2006 05:03:37 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8Q93Zg4013316; Tue, 26 Sep 2006 11:03:35 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 11:03:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs Date: Tue, 26 Sep 2006 11:03:26 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02BF4AED@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: RO for geographically dist'd HAs Thread-Index: AcbhPEHCCIZ9RkNVScavzHwYg0TXpAADI/vA From: "Pascal Thubert \(pthubert\)" To: "marcelo bagnulo braun" , "Vijay Devarapalli" X-OriginalArrivalTime: 26 Sep 2006 09:03:34.0848 (UTC) FILETIME=[A5951C00:01C6E14A] DKIM-Signature: a=rsa-sha1; q=dns; l=1080; t=1159261417; x=1160125417; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Re=3A=20RO=20for=20geographically=20dist'd=20HAs |To:=22marcelo=20bagnulo=20braun=22=20, =0A=20=20=20=20=2 0=20=20=20=22Vijay=20Devarapalli=22=20; X=v=3Dcisco.com=3B=20h=3DVScjeePx18YYodV64AmDAp3legs=3D; b=YP0SWPd2lkXRQIrgqg+IXoxsOp3ivQ/BNQu2g3oTql8vxFKPvIpLSLOjbJstjbUaFoOQuKiN 9cpbkgGOo4MLIF+ibAm4jS5ApLb1TIlTshcuxgz0TS0+766o25AUtiCl; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ml-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: , Errors-To: nemo-bounces@ietf.org > >I mean, my understanding is that the goal of global haha is reliabilty >when you have has distributed geographycally, but this is still HA >reliability, right? > [Pascal] Well no. reliability comes from local HAHA. Global HAHA distributes Home Agents over a wide area. This is the main goal. We try not to use the word RO because we do not fully optimize the path end to end, but still, with global HAHA, it is possible to deploy Home Agents in regions and thus cut the cost of the MRHA path. On top of that, the concept of proxy Home Agent introduced in global HAHA is designed for infrastructure-based route optimization, as Chan-Wah points out. With global HAHA, that (non totally optimized) RO is done WITHIN the infrastructure, where a trust model of some sort can be expected between the proxies. The NEMO specific point is that a proxy exposes an MR's MNP to other proxies at the RO setup. Doing this solves a security problem that is very difficult to tackle cleanly end to end, the problem of adapting the RR test for NEMO prefixes. Pascal From nemo-bounces@ietf.org Tue Sep 26 05:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9D4-0006eI-CV; Tue, 26 Sep 2006 05:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9D3-0006eC-1c for nemo@ietf.org; Tue, 26 Sep 2006 05:26:37 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS9D1-0000bJ-M1 for nemo@ietf.org; Tue, 26 Sep 2006 05:26:37 -0400 Received: from iseran-2.local (dhcp-rocq-97.inria.fr [128.93.62.97]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8Q9QM33015165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Sep 2006 11:26:22 +0200 Date: Tue, 26 Sep 2006 11:26:28 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Charter update: RO between MR and foreign access network Message-Id: <20060926112628.617eab1f.thierry.ernst@inria.fr> In-Reply-To: <45188DFB.9030002@sfc.wide.ad.jp> References: <20060925151736.368a398d.thierry.ernst@inria.fr> <45188DFB.9030002@sfc.wide.ad.jp> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 4518F23E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: nemo-bounces@ietf.org > > I have been involved in some groups working on communication between > > vehicles and the roadside and vehicle-vehicle communications through > > the Internet. For their scenarios, 2 RO needs emerge: > > > > 1. The MR in the vehicle should be able to communicate with a CN on the > > roadside without going through the MR-HA tunnel. > > > > 2. A MR in a vehicle should be able to communicate with another MR in > > another vehicle via the Internet infrastructure but packets flowing via > > the HAs of both MRs should be avoided. > > > > In both case RFC3963 allows the MR to use RO with a CN or another MR for > its own local traffic. To avoid some confusion, I think it would be > better to describe the requirements from the MNN point of view. Hi Romain, Your are right, I was implicitly refering to the traffic originated from the MNN which has to be sent over the bidirectional tunnel. On the other hand, if we do consider the case where the MR is originating the traffic, yes, the MR could use the CoA as the source address. In this case, these packets are not sent over the bidirectional tunnel. But this raises an interesting issue. What if the MR move again and want to maintain the connection originated from the previous CoA ? It needs to register with a HA in the previous visted network. Thierry. From nemo-bounces@ietf.org Tue Sep 26 05:57:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9gW-0004DU-6X; Tue, 26 Sep 2006 05:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9gU-0004DP-KJ for nemo@ietf.org; Tue, 26 Sep 2006 05:57:02 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS9gT-0003uI-57 for nemo@ietf.org; Tue, 26 Sep 2006 05:57:02 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5E70CE3240; Tue, 26 Sep 2006 11:57:00 +0200 (CEST) Received: from [163.117.203.240] (unknown [163.117.203.240]) by smtp01.uc3m.es (Postfix) with ESMTP id BF16FE3200; Tue, 26 Sep 2006 11:56:57 +0200 (CEST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC02BF4AED@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC02BF4AED@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <34abdee49ed8066bd57336b87f62f7eb@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Tue, 26 Sep 2006 11:57:45 +0200 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org El 26/09/2006, a las 11:03, Pascal Thubert (pthubert) escribi=F3: > >> >> I mean, my understanding is that the goal of global haha is = reliabilty >> when you have has distributed geographycally, but this is still HA >> reliability, right? >> > [Pascal] Well no. reliability comes from local HAHA. So global HAHA is NOT for reliability? > Global HAHA > distributes Home Agents over a wide area. This is the main goal. We = try > not to use the word RO because we do not fully optimize the path end = to > end, but still, with global HAHA, it is possible to deploy Home Agents > in regions and thus cut the cost of the MRHA path. > so the goal of global HAHA is to provide infrastrucutre based RO, even=20= if the result is that the performance is not complete RO, this is the=20 main goal of global HAHA? i mean, we need to distinguish which is the=20 main goal of the protocol and how successfull is the protocol achiving=20= the goal. so the goal of global HAHA is to provide RO but it doesn't provide full=20= RO (the reasons for this is the design choices made, e.g. it is based=20 in the infrastrcuture rather than in the end nodes, which provides some=20= additional benefits, but results in less than optimal RO), is this=20 correct? i mean if the goal of global HAHA is RO, then we need to evaluate it=20 along with other RO proposals and figure out which are the best=20 tradeoffs that we choose. > On top of that, the concept of proxy Home Agent introduced in global > HAHA is designed for infrastructure-based route optimization, as > Chan-Wah points out. With global HAHA, that (non totally optimized) RO > is done WITHIN the infrastructure, where a trust model of some sort = can > be expected between the proxies. > > The NEMO specific point is that a proxy exposes an MR's MNP to other > proxies at the RO setup. Doing this solves a security problem that is > very difficult to tackle cleanly end to end, the problem of adapting=20= > the > RR test for NEMO prefixes. > as i mention, these may be excelent design choices and the resulting=20 features may be what the wg needs. But what we need to understand at=20 this point is what is the goal of global HAHA, RO or HA reliability? If it is HA reliability, probably this work would need to be carried=20 out in the mip6 wg, where they are working on the HA reliability topic If it is RO, we should consider global HAHA as any other RO proposal,=20 and we need to analyze the whole RO problem together, so i don't see=20 any reason why include it in the charter as a separate item regards, marcelo > Pascal > > From nemo-bounces@ietf.org Tue Sep 26 06:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9s7-0002Kr-IY; Tue, 26 Sep 2006 06:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9s5-0002Kj-T2 for nemo@ietf.org; Tue, 26 Sep 2006 06:09:02 -0400 Received: from mail125.messagelabs.com ([85.158.136.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GS9s1-0005CP-Do for nemo@ietf.org; Tue, 26 Sep 2006 06:09:01 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-125.messagelabs.com!1159265331!15576558!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2590 invoked from network); 26 Sep 2006 10:08:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-125.messagelabs.com with SMTP; 26 Sep 2006 10:08:51 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k8QA8akm028727; Tue, 26 Sep 2006 03:08:36 -0700 (MST) Received: from [10.161.194.36] (ZFR27-0387.ea.mot.com [10.161.194.36]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k8QA8YU3026310; Tue, 26 Sep 2006 05:08:34 -0500 (CDT) Message-ID: <4518FC11.3040202@motorola.com> Date: Tue, 26 Sep 2006 12:08:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: RO for geographically dist'd HAs (was: [nemo] Charter update, continued) References: <09D3F703EF3B0A4CBE28449EA9F3D32003EC33DE@nicta-atp-mail.in.nicta.com.au> <3111d23d0f29a60437cbb0a658b47c67@it.uc3m.es> <1159177908.982.283.camel@localhost> <1159182519.982.289.camel@localhost> <17ac37fdb389d7e0c003c558d2c52033@it.uc3m.es> <333D0B75-4369-469D-85F8-C74E791FC173@multicasttech.com> In-Reply-To: <333D0B75-4369-469D-85F8-C74E791FC173@multicasttech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 1.8 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: marcelo bagnulo braun , Eranga Perera , "T.J. Kniveton" , Chan-Wah Ng , ml-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: , Errors-To: nemo-bounces@ietf.org Marshall Eubanks wrote: > > On Sep 25, 2006, at 9:38 AM, marcelo bagnulo braun wrote: > >> >> El 25/09/2006, a las 15:27, Marshall Eubanks escribió: >> >>> Hello; >>> >>> On Sep 25, 2006, at 7:08 AM, Chan-Wah Ng wrote: >>> >>>> On Mon, 2006-09-25 at 12:03 +0200, marcelo bagnulo braun wrote: >>>>> El 25/09/2006, a las 11:51, Chan-Wah Ng escribió: >>>>> >>> >>>>> before discussing any solution we need to find real application cases >>>>> and determine thier requirements >>>>> >>>>> only then we can start talking about solutions, because without these >>>>> use cases and requirements we cannot compare evaluate the ddifferent >>>>> proposals that are around. >>>>> >>>>> Do we agree that identifying use cases and requirements is not a nice >>>>> to have step but we must do this before start working on solutions? >>>>> >>>> >>>> This I agree ... but haven't Thierry already collected some information >>>> from different industries? He presented them in Montreal. I think all >>>> we need is to document them in an Internet draft, circulate the draft >>>> around the various concerned industries to review the documented >>>> requirements. (I think waiting for busy people from these >>>> industries to >>>> produce a draft on their own would take a long long time. It is better >>>> someone write it for them). >>>> >>>> /rgds >>>> /cwng >>>> >>> >>> >>> Was this a presentation ? Is it available somewhere ? I don't see it >>> in the proceedings - >>> or is just the lists on pages 13-14-15 of >>> http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf ? >> >> i guess this is it >> >> but there was also a nice email with requirements from the aviation >> industry from Terry Davis from Boeing, but i guess they never put it >> as an ID :-( > > It's coming... What happened to MPI pre-bar-bof? Any relationship to what we should expecte here? http://www.arkko.com/publications/ietf-67/mpi/draft-ivancic-mobile-platforms-problem-00.txt http://www1.tools.ietf.org/bof/trac/wiki Alex From nemo-bounces@ietf.org Tue Sep 26 06:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9yJ-0004Ut-Ef; Tue, 26 Sep 2006 06:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS9yH-0004Uj-Ox for nemo@ietf.org; Tue, 26 Sep 2006 06:15:25 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GS9yG-0005rT-Ey for nemo@ietf.org; Tue, 26 Sep 2006 06:15:25 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1159265722!1066979!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13233 invoked from network); 26 Sep 2006 10:15:22 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 26 Sep 2006 10:15:22 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k8QAFLms029936; Tue, 26 Sep 2006 03:15:21 -0700 (MST) Received: from [10.161.194.36] (ZFR27-0387.ea.mot.com [10.161.194.36]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k8QAFKgr029298; Tue, 26 Sep 2006 05:15:20 -0500 (CDT) Message-ID: <4518FDB5.1060700@motorola.com> Date: Tue, 26 Sep 2006 12:15:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Re: RO for geographically dist'd HAs References: <7892795E1A87F04CADFCCF41FADD00FC02BF4AED@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC02BF4AED@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: marcelo bagnulo braun , ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: >> I mean, my understanding is that the goal of global haha is >> reliabilty when you have has distributed geographycally, but this >> is still HA reliability, right? >> > [Pascal] Well no. reliability comes from local HAHA. Global HAHA > distributes Home Agents over a wide area. This is the main goal. We > try not to use the word RO because we do not fully optimize the path > end to end, but still, with global HAHA, it is possible to deploy > Home Agents in regions and thus cut the cost of the MRHA path. > > On top of that, the concept of proxy Home Agent introduced in global > HAHA is designed for infrastructure-based route optimization, as > Chan-Wah points out. Ah, terminology... A "proxy HA"? Is a "proxy HA" run Proxy-MIP? > With global HAHA, that (non totally optimized) RO is done WITHIN the > infrastructure, where a trust model of some sort can be expected > between the proxies. > > The NEMO specific point is that a proxy exposes an MR's MNP to other > proxies at the RO setup. Doing this solves a security problem that is > very difficult to tackle cleanly end to end, the problem of adapting > the RR test for NEMO prefixes. That is a valid problem. It's why RO for NEMO MR can't be designed as RR tests were for MIP6 MN. However, not very sure what a proxy "agent" can become in the wider context of netlmm, mip6, nemov6 and pmipv6. Alex From nemo-bounces@ietf.org Tue Sep 26 06:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSA7P-0001rL-OV; Tue, 26 Sep 2006 06:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSA7O-0001qB-5j for nemo@ietf.org; Tue, 26 Sep 2006 06:24:50 -0400 Received: from mail125.messagelabs.com ([85.158.136.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GSA7M-0007Wh-OP for nemo@ietf.org; Tue, 26 Sep 2006 06:24:50 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-125.messagelabs.com!1159266287!15577566!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18623 invoked from network); 26 Sep 2006 10:24:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-125.messagelabs.com with SMTP; 26 Sep 2006 10:24:47 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k8QAOk0d001667; Tue, 26 Sep 2006 03:24:46 -0700 (MST) Received: from [10.161.194.36] (ZFR27-0387.ea.mot.com [10.161.194.36]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k8QAOjQx029794; Tue, 26 Sep 2006 05:24:45 -0500 (CDT) Message-ID: <4518FFEA.1080403@motorola.com> Date: Tue, 26 Sep 2006 12:24:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Charter update: RO between MR and foreign access network References: <20060925151736.368a398d.thierry.ernst@inria.fr> <45188DFB.9030002@sfc.wide.ad.jp> <20060926112628.617eab1f.thierry.ernst@inria.fr> In-Reply-To: <20060926112628.617eab1f.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: >>> I have been involved in some groups working on communication >>> between vehicles and the roadside and vehicle-vehicle >>> communications through the Internet. For their scenarios, 2 RO >>> needs emerge: >>> >>> 1. The MR in the vehicle should be able to communicate with a CN >>> on the roadside without going through the MR-HA tunnel. A netlmm solution could work for this? >>> 2. A MR in a vehicle should be able to communicate with another >>> MR in another vehicle via the Internet infrastructure but packets >>> flowing via the HAs of both MRs should be avoided. Must the two talking vehicles be within the wifi range? (cca 50m). If yes, it may be that the requirement does not involve supporting IP mobility: if the two vehicles move further from each other they probably don't need to talk to each other. What does the application look like in these requirements? Video stream? Bumper radar approaching? Road side emergency call? These are three very different types of applications with respect to networking behaviour. Video stream between two cars is continuous packet flow, unidirectional. Bumper radar approaching is messages sent periodically. Emergency call is voip duplex continuous exchanges. For some IP mobility is needed, for others not (bumper approaching is one example). >> In both case RFC3963 allows the MR to use RO with a CN or another >> MR for its own local traffic. To avoid some confusion, I think it >> would be better to describe the requirements from the MNN point of >> view. > > Hi Romain, > > Your are right, I was implicitly refering to the traffic originated > from the MNN which has to be sent over the bidirectional tunnel. > > On the other hand, if we do consider the case where the MR is > originating the traffic, yes, the MR could use the CoA as the source > address. In this case, these packets are not sent over the > bidirectional tunnel. But this raises an interesting issue. What if > the MR move again and want to maintain the connection originated > from the previous CoA ? It needs to register with a HA in the > previous visted network. The apps run on MR can do 3775 RO, using MR's Home Address and RR tests. Using a CoA as src address of app packets on MR is not a solution that supports mobility, as you say. Alex From nemo-bounces@ietf.org Tue Sep 26 11:27:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEpR-0006xV-39; Tue, 26 Sep 2006 11:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEpP-0006xD-Rb for nemo@ietf.org; Tue, 26 Sep 2006 11:26:35 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSEpJ-0000Kt-8S for nemo@ietf.org; Tue, 26 Sep 2006 11:26:35 -0400 Received: from [192.168.1.105] ([24.6.251.221]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 08:24:50 -0700 Message-ID: <45194642.4020202@azairenet.com> Date: Tue, 26 Sep 2006 08:24:50 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] Charter update: RO between MR and foreign access network References: <20060925151736.368a398d.thierry.ernst@inria.fr> <00be01c6e11c$5b2df430$5e6015ac@dcml.docomolabsusa.com> <1df9b932d070a49fde8efa5da88f37f5@it.uc3m.es> In-Reply-To: <1df9b932d070a49fde8efa5da88f37f5@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2006 15:24:50.0399 (UTC) FILETIME=[E8792EF0:01C6E17F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: nemo@ietf.org, 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: , Errors-To: nemo-bounces@ietf.org hi Marcelo, marcelo bagnulo braun wrote: > actually, in the last meeting in montreal, the consesous was that the > only item added to the charter was to identify RO use cases (like > aviation, or car industry) and define the specific requirements for the > identified use cases. I saw hardly a couple of folks go to the mike. and since when did whatever was decided at a meeting override whats been discussed on the mailing list so far. infact Pascal wasn't at the meeting. you would have heard a few things from him. :) I didnt bother going to the mike. RO has been discussed for a long time on the mailing list. its got more history than what was just discussed at the last meeting. Vijay > After we have done that, we could recharter again the wg to produce the > actual RO solutions. At this point we would be in a very good shape to > select among the over a dozens RO proposals, since we would have the > requirements docuemtns as a selection criteria. > > This would allow us to: > - produce solutions that have potential users and suit their requirements > - have an easy procedure to select among the existent proposals. > > > I think this approach is much better than having the discussion on the > requirements now and include them in the charter, since i think that the > definition of requirements needs the review of a RFC rather than the > time required by a charter discussion > > Regards, marcelo > >> for example this one. >> >> jak >> >> ----- Original Message ----- From: "Thierry Ernst" >> >> To: >> Sent: Monday, September 25, 2006 6:17 AM >> Subject: [nemo] Charter update: RO between MR and foreign access network >> >> >>> >>> Dear all, >>> >>> I have been involved in some groups working on communication between >>> vehicles and the roadside and vehicle-vehicle communications through >>> the Internet. For their scenarios, 2 RO needs emerge: >>> >>> 1. The MR in the vehicle should be able to communicate with a CN on the >>> roadside without going through the MR-HA tunnel. >>> >>> 2. A MR in a vehicle should be able to communicate with another MR in >>> another vehicle via the Internet infrastructure but packets flowing via >>> the HAs of both MRs should be avoided. >>> >>> May be we could have these listed in the new charter more explicitly. >>> >>> Thierry. >>> >>> >>> >>> >>> On Tue, 19 Sep 2006 19:18:10 -0700 >>> "T.J. Kniveton" wrote: >>> >>>> Hi folks, I'm back.. >>>> >>>> Here is the current version of the charter. I am still making >>>> changes, and need to modify the milestones section. But wanted to >>>> share what's there now and see if there are any comments. >>>> >>>> Please send comments directly to me, for the moment, and when I have >>>> the next version we can discuss it on the list. >>>> >>>> http://www.mobilenetworks.org/nemo/charter2_3.txt >>>> >>>> TJ >>>> >>> >>> >>> -- >>> Thierry ERNST, PhD >>> http://www.nautilus6.org/~thierry >>> IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair >>> -- >>> INRIA Rocquencourt Project-Team IMARA, France. >>> +33 1 39 63 59 30 (office) >>> >> >> > > From nemo-bounces@ietf.org Tue Sep 26 13:22:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSGdO-0006Nf-A8; Tue, 26 Sep 2006 13:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSGdN-0006Na-7z for nemo@ietf.org; Tue, 26 Sep 2006 13:22:17 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSGdL-000724-Ti for nemo@ietf.org; Tue, 26 Sep 2006 13:22:17 -0400 Received: from [10.1.201.27] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 10:20:36 -0700 Message-ID: <451961C5.2050905@azairenet.com> Date: Tue, 26 Sep 2006 10:22:13 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2006 17:20:36.0702 (UTC) FILETIME=[14CAE7E0:01C6E190] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ml-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: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: > so if the goal of global haha is neither RO and nor HA reliability, what > is the goal of global haha? > > I mean, my understanding is that the goal of global haha is reliabilty > when you have has distributed geographycally, but this is still HA > reliability, right? no. it is more about getting the geographically distributed HAs to provide mobility for the same set of MNs/MRs. here is a realistic scenario. an operator in the US can have multiple home agents distributed geographically. they won't be all in the same room. you can allocate the home agents dynamically based on the MN/MR location. you can also dynamically switch HAs with global HAHA. > so, probably it makes sense to do all the work on reliability in the > same wg... I guess you haven't gone through the draft. Vijay > > regards, marcelo > >> there has always been a lot of interest in global >> HAHA in the NEMO WG whenever it has been presented. >> that is why it still appears in the NEMO WG. >> >> Andy Huang wrote: >> >>> In fact, a WG draft has been designed by DT in MIP6 WG. >>> https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-00.txt >>> >>> >>> Do you think we need a especial HA reliability protocol for NEMO? >> >> if you take a look at the drafts, the messages >> used by global HA would be the same as the ones >> defined in draft-ietf-mip6-hareliability. the >> current DT draft does not address geographically >> distributed HAs. >> >> Vijay >> > From nemo-bounces@ietf.org Tue Sep 26 23:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSQR1-0002F3-F5; Tue, 26 Sep 2006 23:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSQR0-0002Ev-I3 for nemo@ietf.org; Tue, 26 Sep 2006 23:50:10 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSQQy-0007Mh-So for nemo@ietf.org; Tue, 26 Sep 2006 23:50:10 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8R3o0Zf005785; Wed, 27 Sep 2006 12:50:00 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8R3o3328931; Wed, 27 Sep 2006 12:50:03 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k8R3o1l14154; Wed, 27 Sep 2006 12:50:01 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 11:49:08 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 0A8E8D4223; Wed, 27 Sep 2006 11:59:09 +0800 (SGT) Subject: Re: [nemo] Re: RO for geographically dist'd HAs From: Chan-Wah Ng To: Vijay Devarapalli In-Reply-To: <451961C5.2050905@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 27 Sep 2006 11:59:08 +0800 Message-Id: <1159329548.9531.34.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 27 Sep 2006 03:49:08.0141 (UTC) FILETIME=[E28FD5D0:01C6E1E7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: marcelo bagnulo braun , ml-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: , Errors-To: nemo-bounces@ietf.org Hello all, On Tue, 2006-09-26 at 10:22 -0700, Vijay Devarapalli wrote: > marcelo bagnulo braun wrote: > > > so if the goal of global haha is neither RO and nor HA reliability, what > > is the goal of global haha? > > > > I mean, my understanding is that the goal of global haha is reliabilty > > when you have has distributed geographycally, but this is still HA > > reliability, right? > > no. it is more about getting the geographically > distributed HAs to provide mobility for the same > set of MNs/MRs. > > here is a realistic scenario. an operator in the > US can have multiple home agents distributed > geographically. they won't be all in the same > room. you can allocate the home agents dynamically > based on the MN/MR location. you can also > dynamically switch HAs with global HAHA. > > > so, probably it makes sense to do all the work on reliability in the > > same wg... > > I guess you haven't gone through the draft. > As a co-author, perhaps you want to point out where in the draft covers NEMO-specific content? You use the term MN/MR, suggesting that it is catered for mobile node (host+router) in general. On Tue, 2006-09-26 at 08:24 -0700, Vijay Devarapalli wrote: > hi Marcelo, > > marcelo bagnulo braun wrote: > > actually, in the last meeting in montreal, the consesous was that the > > only item added to the charter was to identify RO use cases (like > > aviation, or car industry) and define the specific requirements for the > > identified use cases. > > I saw hardly a couple of folks go to the mike. > and since when did whatever was decided at a > meeting override whats been discussed on the > mailing list so far. infact Pascal wasn't at > the meeting. you would have heard a few things > from him. :) I didnt bother going to the mike. > > RO has been discussed for a long time on the > mailing list. its got more history than what was > just discussed at the last meeting. Vijay brought out a good point, people have been talking about RO since even before the WG was formed. So, interest in standardizing it is definitely there. However, pulling the discussion back on topic, I still see nothing NEMO-specific in terms of global HAHA as a HA reliability protocol. If the WG decides that it wants to go straight into standardizing RO solutions, I am fine with it. But then, global HAHA should not be singled out. It is merely a candidate solution for a particular class of RO solution. In summary, IMHO: (1) global HAHA for HA reliability in general should not be included as a NEMO WG charter item (as there is nothing NEMO-specific); (2) NEMO-specific HA reliability (eg. HA in NEMO) may be considered as a NEMO WG charter item (problem statement first); (3) If WG decides to add RO solutions into WG charter, no RO solution proposal should be singled out as a WG charter item at this stage. Instead, a few classes of RO solution should be included, such as: (a) Nested Tunnel Optimization (b) Infrastructure-based Optimization (c) MR providing RO for legacy (MIP6 included) MNNs (4) If WG decides it's still too early (after all, we have been talking about RO for close to 5 years now) to add RO solutions into WG charter, a WG charter item should be added to document RO requirements from various industries. /rgds /cwng From nemo-bounces@ietf.org Wed Sep 27 21:54:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSl5d-00038O-P9; Wed, 27 Sep 2006 21:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSl5c-00038G-BO for nemo@ietf.org; Wed, 27 Sep 2006 21:53:28 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSl5b-00070x-2l for nemo@ietf.org; Wed, 27 Sep 2006 21:53:28 -0400 Received: from [10.1.201.27] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 18:51:43 -0700 Message-ID: <451B2AA0.3050807@azairenet.com> Date: Wed, 27 Sep 2006 18:51:28 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: RO for geographically dist'd HAs References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <1159329548.9531.34.camel@localhost> In-Reply-To: <1159329548.9531.34.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2006 01:51:43.0059 (UTC) FILETIME=[A5C76230:01C6E2A0] X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: marcelo bagnulo braun , ml-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: , Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > As a co-author, perhaps you want to point out where in the draft covers > NEMO-specific content? You use the term MN/MR, suggesting that it is > catered for mobile node (host+router) in general. I am not so particular where its done in this case. so is "why not in MIP6 WG" your main reason for objecting to this work? Vijay From nemo-bounces@ietf.org Wed Sep 27 22:31:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSlgO-0007vk-7N; Wed, 27 Sep 2006 22:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSlgM-0007uD-Ky for nemo@ietf.org; Wed, 27 Sep 2006 22:31:26 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSlgL-00066r-0h for nemo@ietf.org; Wed, 27 Sep 2006 22:31:26 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k8S2VKpv008652 for ; Thu, 28 Sep 2006 11:31:20 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k8S2VLc18648 for ; Thu, 28 Sep 2006 11:31:21 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id k8S2VJW17402 for ; Thu, 28 Sep 2006 11:31:19 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 10:30:24 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 32D08D4223; Thu, 28 Sep 2006 10:40:33 +0800 (SGT) Subject: Re: [nemo] Re: RO for geographically dist'd HAs From: Chan-Wah Ng To: IETF NEMO WG In-Reply-To: <451B2AA0.3050807@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <1159329548.9531.34.camel@localhost> <451B2AA0.3050807@azairenet.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 28 Sep 2006 10:40:33 +0800 Message-Id: <1159411233.9531.67.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 28 Sep 2006 02:30:24.0378 (UTC) FILETIME=[0D648DA0:01C6E2A6] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: nemo-bounces@ietf.org On Wed, 2006-09-27 at 18:51 -0700, Vijay Devarapalli wrote: > Chan-Wah Ng wrote: > > > As a co-author, perhaps you want to point out where in the draft covers > > NEMO-specific content? You use the term MN/MR, suggesting that it is > > catered for mobile node (host+router) in general. > > I am not so particular where its done in this case. > so is "why not in MIP6 WG" your main reason for > objecting to this work? I think NEMO WG is formed to work on items specific to Mobile Networks or Mobile Routers, and something that is general to mobile nodes should be done in MIP6, MIPSHOP, or MOBOPS. True, its doesn't matter to people like you and me where the work is done. But in terms of getting public review, where the work is done is important. Take the multihoming work I have been doing for instance. The WG has been stressing that only issues that are specific to NEMO should be considered in NEMO WG, this is one of factor leading to the formation of Monami6. HA reliability is no different. But I am curious as to why global HA reliability was not worked on by the MIP6 WG? /rgds /cwng From nemo-bounces@ietf.org Thu Sep 28 00:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnq3-0006Vn-4k; Thu, 28 Sep 2006 00:49:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSnq1-0006Vi-SQ for nemo@ietf.org; Thu, 28 Sep 2006 00:49:33 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSnq0-0002V5-IO for nemo@ietf.org; Thu, 28 Sep 2006 00:49:33 -0400 Received: from [10.1.210.14] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 21:47:48 -0700 Message-ID: <451B53F2.7080909@azairenet.com> Date: Wed, 27 Sep 2006 21:47:46 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Re: RO for geographically dist'd HAs References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <1159329548.9531.34.camel@localhost> <451B2AA0.3050807@azairenet.com> <1159411233.9531.67.camel@localhost> In-Reply-To: <1159411233.9531.67.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2006 04:47:48.0216 (UTC) FILETIME=[3F1A6780:01C6E2B9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Errors-To: nemo-bounces@ietf.org Chan-Wah Ng wrote: > On Wed, 2006-09-27 at 18:51 -0700, Vijay Devarapalli wrote: >> Chan-Wah Ng wrote: >> >>> As a co-author, perhaps you want to point out where in the draft covers >>> NEMO-specific content? You use the term MN/MR, suggesting that it is >>> catered for mobile node (host+router) in general. >> I am not so particular where its done in this case. >> so is "why not in MIP6 WG" your main reason for >> objecting to this work? > > I think NEMO WG is formed to work on items specific to Mobile Networks > or Mobile Routers, and something that is general to mobile nodes should > be done in MIP6, MIPSHOP, or MOBOPS. > > True, its doesn't matter to people like you and me where the work is > done. But in terms of getting public review, where the work is done is > important. > > Take the multihoming work I have been doing for instance. The WG has > been stressing that only issues that are specific to NEMO should be > considered in NEMO WG, this is one of factor leading to the formation of > Monami6. HA reliability is no different. > > But I am curious as to why global HA reliability was not worked on by > the MIP6 WG? because global HAHA is not about HA reliability. It was really done to remove the dependency on link local mechanisms like ICMPv6 options for building the home agent list. These mechanisms don't work if the HAs are distributed geographically. frankly global HAHA has not been proposed in the MIP6 WG. only HA reliability work has been proposed there. even that was first presented in NEMO WG since it was felt NEMO needs HA reliability mechanisms more than MIP6. Vijay From nemo-bounces@ietf.org Thu Sep 28 01:59:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSov4-0007AW-Sg; Thu, 28 Sep 2006 01:58:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSov3-0007AR-3k for nemo@ietf.org; Thu, 28 Sep 2006 01:58:49 -0400 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GSouy-0006lr-DV for nemo@ietf.org; Thu, 28 Sep 2006 01:58:49 -0400 Received: (qmail 503 invoked from network); 28 Sep 2006 14:58:31 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 28 Sep 2006 14:58:31 +0900 To: nemo@ietf.org From: "K.Kawaguchi" References: <200609201718.HAJ30652.JLUVBXHB@ysknet.co.jp> In-Reply-To: <200609201718.HAJ30652.JLUVBXHB@ysknet.co.jp> Message-Id: <200609281458.IIE26588.HUVJBBXL@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Thu, 28 Sep 2006 14:58:28 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ryuji@sfc.wide.ad.jp Subject: [nemo] About Test Specification in IPv6 Ready Logo 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: , Errors-To: nemo-bounces@ietf.org Hi, We will begin IPv6 Ready Logo of RFC3963 (NEMO basic support). This is a program of the confidence to the NEMO product based on RFC3963. We want to hear your opinion in regard to the test condition in this test specification. We have opened the preparation version of the test specification to the public. http://www.ipv6ready.org/announcement/public_review20060621_nemo.html The point that we want to hear the opinion is the following parts. http://cert.v6pc.jp/nemo/phase2/public_review/pdf/nemo_phase2policy-v1_0_b2.pdf --------------------------------------------------------------------- 3. Policy for Basic and Advanced Functions Here shows the view of satisfaction of the functions belonging to Basic Function (Priority A1) and Advanced Function (Priority A2) for Home Agent and Mobile Router. - HA (Home Agent) - Router functions defined in "Test Specifications for the IPv6 Core Protocols" MUST be supported. - Mobile network prefix registration supporting all of explicit mode, implicit mode, home address derived from the Mobile Network Prefix, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ home address derived from the Home Network Prefix is a Basic Function (A1). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ --------------------------------------------------------------------- * supplementation) keywords Basic Function (Priority A1) : It is defined as indispensable function. It is always to be tested in Logo. Advance Function (Priority A2): It is defined as enhanced feature. It is tested by selection in Logo. RFC3963 has not described which method is a 'MUST'. Therefore, we had equally treated both. However, the operation is possible by either one. And a lot of venders might implement only one of methods. Now, we think that it is too rich to demand both from all products. We will put the bias. Two alternatives without mandating either make non-interoperable world. So, mandating one is very reasonable. We think naturally that home Address be configured from Home Link Prefix is basic method same as MIPv6. We change the above-mentioned part as follows. --------------------------------------------------------------------- - HA (Home Agent) - Router functions defined in "Test Specifications for the IPv6 Core Protocols" MUST be supported. - Mobile network prefix registration supporting all of explicit mode, implicit mode, is a Basic Function (A1). - Mobile network prefix registration supporting home address derived from the Home Network Prefix is a Basic Function (A1). - Mobile network prefix registration supporting home address derived from the Mobile Network Prefix an Advanced Function (A2). --------------------------------------------------------------------- We want to hear your opinion. Do you think it is unquestionable for this priority level in which it is made to bias in Logo? Relational part of RFC3963 --------------------------------------------------------------------- 6.2. Mobile Network Prefix Registration (snip) - Mobile IPv6 specification [1] requires that the Home Address in the Binding Update be configured from a prefix advertised on the home link. Otherwise the Binding Update is rejected with status value 132 [1]. This specification relaxes this requirement so that the Home Agent rejects the Binding Update only if the Home Address does not belong to the prefix that the Home Agent is configured to serve. --------------------------------------------------------------------- Best regards --- Kiyoaki KAWAGUCHI From nemo-bounces@ietf.org Thu Sep 28 06:19:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSszB-00037O-5m; Thu, 28 Sep 2006 06:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSsz9-00037J-0P for nemo@ietf.org; Thu, 28 Sep 2006 06:19:19 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSsz4-00014G-Fx for nemo@ietf.org; Thu, 28 Sep 2006 06:19:18 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 390DEA150E; Thu, 28 Sep 2006 12:19:09 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp02.uc3m.es (Postfix) with ESMTP id 19A24A151C; Thu, 28 Sep 2006 12:19:08 +0200 (CEST) In-Reply-To: <45194642.4020202@azairenet.com> References: <20060925151736.368a398d.thierry.ernst@inria.fr> <00be01c6e11c$5b2df430$5e6015ac@dcml.docomolabsusa.com> <1df9b932d070a49fde8efa5da88f37f5@it.uc3m.es> <45194642.4020202@azairenet.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <9a6d30e53308cae4bd5cacba1e267e34@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Charter update: RO between MR and foreign access network Date: Thu, 28 Sep 2006 12:19:59 +0200 To: Vijay Devarapalli X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: nemo@ietf.org, 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: , Errors-To: nemo-bounces@ietf.org El 26/09/2006, a las 17:24, Vijay Devarapalli escribi=F3: > hi Marcelo, > > marcelo bagnulo braun wrote: >> actually, in the last meeting in montreal, the consesous was that the=20= >> only item added to the charter was to identify RO use cases (like=20 >> aviation, or car industry) and define the specific requirements for=20= >> the identified use cases. > > I saw hardly a couple of folks go to the mike. > and since when did whatever was decided at a > meeting override whats been discussed on the > mailing list so far. infact Pascal wasn't at > the meeting. you would have heard a few things > from him. :) I didnt bother going to the mike. > > RO has been discussed for a long time on the > mailing list. its got more history than what was > just discussed at the last meeting. > agree still it is a bit strange that in the meeting the wg chairs propose an=20= approach to continue with the wg work, all the people that go to the=20 mike agree (there were few of them, i agree, but one of them was the AD=20= in charge) (this means that none oppose to the wg chair proposal), and=20= next the wg chair continue in a different direction (without any=20 (public) request from anyone in the wg ml)... do you agree that this is=20= somehow surprising regards, marcelo > Vijay > >> After we have done that, we could recharter again the wg to produce=20= >> the actual RO solutions. At this point we would be in a very good=20 >> shape to select among the over a dozens RO proposals, since we would=20= >> have the requirements docuemtns as a selection criteria. >> This would allow us to: >> - produce solutions that have potential users and suit their=20 >> requirements >> - have an easy procedure to select among the existent proposals. >> I think this approach is much better than having the discussion on=20 >> the requirements now and include them in the charter, since i think=20= >> that the definition of requirements needs the review of a RFC rather=20= >> than the time required by a charter discussion >> Regards, marcelo >>> for example this one. >>> >>> jak >>> >>> ----- Original Message ----- From: "Thierry Ernst"=20 >>> >>> To: >>> Sent: Monday, September 25, 2006 6:17 AM >>> Subject: [nemo] Charter update: RO between MR and foreign access=20 >>> network >>> >>> >>>> >>>> Dear all, >>>> >>>> I have been involved in some groups working on communication = between >>>> vehicles and the roadside and vehicle-vehicle communications = through >>>> the Internet. For their scenarios, 2 RO needs emerge: >>>> >>>> 1. The MR in the vehicle should be able to communicate with a CN on=20= >>>> the >>>> roadside without going through the MR-HA tunnel. >>>> >>>> 2. A MR in a vehicle should be able to communicate with another MR=20= >>>> in >>>> another vehicle via the Internet infrastructure but packets flowing=20= >>>> via >>>> the HAs of both MRs should be avoided. >>>> >>>> May be we could have these listed in the new charter more=20 >>>> explicitly. >>>> >>>> Thierry. >>>> >>>> >>>> >>>> >>>> On Tue, 19 Sep 2006 19:18:10 -0700 >>>> "T.J. Kniveton" wrote: >>>> >>>>> Hi folks, I'm back.. >>>>> >>>>> Here is the current version of the charter. I am still making >>>>> changes, and need to modify the milestones section. But wanted to >>>>> share what's there now and see if there are any comments. >>>>> >>>>> Please send comments directly to me, for the moment, and when I=20 >>>>> have >>>>> the next version we can discuss it on the list. >>>>> >>>>> http://www.mobilenetworks.org/nemo/charter2_3.txt >>>>> >>>>> TJ >>>>> >>>> >>>> >>>> --=20 >>>> Thierry ERNST, PhD >>>> http://www.nautilus6.org/~thierry >>>> IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair >>>> --=20 >>>> INRIA Rocquencourt Project-Team IMARA, France. >>>> +33 1 39 63 59 30 (office) >>>> >>> >>> > From nemo-bounces@ietf.org Thu Sep 28 06:31:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GStAe-0001v5-J9; Thu, 28 Sep 2006 06:31:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GStAd-0001v0-Fh for nemo@ietf.org; Thu, 28 Sep 2006 06:31:11 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GStAb-0003Tg-CD for nemo@ietf.org; Thu, 28 Sep 2006 06:31:10 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 83F3FA1568; Thu, 28 Sep 2006 12:31:08 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp02.uc3m.es (Postfix) with ESMTP id EB4EDA1560; Thu, 28 Sep 2006 12:31:06 +0200 (CEST) In-Reply-To: <1159329548.9531.34.camel@localhost> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <1159329548.9531.34.camel@localhost> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <40abea72677cff0a9680c44d09f50a2f@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Thu, 28 Sep 2006 12:31:57 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ml-nemo WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > In summary, IMHO: > > (1) global HAHA for HA reliability in general should not be included as > a NEMO WG charter item (as there is nothing NEMO-specific); > > (2) NEMO-specific HA reliability (eg. HA in NEMO) may be considered as > a > NEMO WG charter item (problem statement first); > > (3) If WG decides to add RO solutions into WG charter, no RO solution > proposal should be singled out as a WG charter item at this stage. > Instead, a few classes of RO solution should be included, such as: > (a) Nested Tunnel Optimization > (b) Infrastructure-based Optimization > (c) MR providing RO for legacy (MIP6 included) MNNs > > (4) If WG decides it's still too early (after all, we have been talking > about RO for close to 5 years now) to add RO solutions into WG charter, > a WG charter item should be added to document RO requirements from > various industries. > i agree with Chan-Wah in all the above points i would prefer 4 rather than 3, but... regards, marcelo > /rgds > /cwng > From nemo-bounces@ietf.org Thu Sep 28 08:35:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSv6F-0003Ae-49; Thu, 28 Sep 2006 08:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSv6E-0003A5-3J for nemo@ietf.org; Thu, 28 Sep 2006 08:34:46 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSv3e-00054t-MB for nemo@ietf.org; Thu, 28 Sep 2006 08:32:07 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8SCVxl2031059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Sep 2006 05:32:00 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8SCVtxY024366; Thu, 28 Sep 2006 05:31:58 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 05:31:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs Date: Thu, 28 Sep 2006 05:31:52 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A1E91E8@NAEX14.na.qualcomm.com> In-Reply-To: <40abea72677cff0a9680c44d09f50a2f@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: RO for geographically dist'd HAs thread-index: Acbi6WsvKzR9uefpTw+pGABZlQ5PVgAEI4eg From: "Soliman, Hesham" To: "marcelo bagnulo braun" , "Chan-Wah Ng" X-OriginalArrivalTime: 28 Sep 2006 12:31:55.0552 (UTC) FILETIME=[1568AA00:01C6E2FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ml-nemo WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > In summary, IMHO: > > > > (1) global HAHA for HA reliability in general should not=20 > be included as > > a NEMO WG charter item (as there is nothing NEMO-specific); > > > > (2) NEMO-specific HA reliability (eg. HA in NEMO) may be=20 > considered as=20 > > a > > NEMO WG charter item (problem statement first); > > > > (3) If WG decides to add RO solutions into WG charter, no=20 > RO solution > > proposal should be singled out as a WG charter item at this stage. > > Instead, a few classes of RO solution should be included, such as: > > (a) Nested Tunnel Optimization > > (b) Infrastructure-based Optimization > > (c) MR providing RO for legacy (MIP6 included) MNNs > > > > (4) If WG decides it's still too early (after all, we have=20 > been talking > > about RO for close to 5 years now) to add RO solutions=20 > into WG charter, > > a WG charter item should be added to document RO requirements from > > various industries. > > >=20 >=20 > i agree with Chan-Wah in all the above points >=20 > i would prefer 4 rather than 3, but... =3D> Me too.=20 Hesham >=20 > regards, marcelo >=20 >=20 >=20 > > /rgds > > /cwng > > >=20 >=20 >=20 From nemo-bounces@ietf.org Thu Sep 28 09:42:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSw9t-00027r-El; Thu, 28 Sep 2006 09:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSw9s-00027h-UX for nemo@ietf.org; Thu, 28 Sep 2006 09:42:36 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSw9r-0008B2-F4 for nemo@ietf.org; Thu, 28 Sep 2006 09:42:36 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C1D8AA162F; Thu, 28 Sep 2006 15:42:34 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp02.uc3m.es (Postfix) with ESMTP id 9CC91A162D; Thu, 28 Sep 2006 15:42:34 +0200 (CEST) In-Reply-To: <451961C5.2050905@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <50f59c75bf6f0543717ab855f5d79d81@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Thu, 28 Sep 2006 15:43:25 +0200 To: Vijay Devarapalli X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ml-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: , Errors-To: nemo-bounces@ietf.org El 26/09/2006, a las 19:22, Vijay Devarapalli escribi=F3: > marcelo bagnulo braun wrote: > >> so if the goal of global haha is neither RO and nor HA reliability, =20= >> what is the goal of global haha? >> I mean, my understanding is that the goal of global haha is =20 >> reliabilty when you have has distributed geographycally, but this is =20= >> still HA reliability, right? > > no. it is more about getting the geographically > distributed HAs to provide mobility for the same > set of MNs/MRs. > but why do you want to do this? the motivations that i can see for doing this is to achieve RO or HA =20 reliability, what else can be the motivations for this? > here is a realistic scenario. an operator in the > US can have multiple home agents distributed > geographically. they won't be all in the same > room. you can allocate the home agents dynamically > based on the MN/MR location. you can also > dynamically switch HAs with global HAHA. yes, this seems indeed a reasonable scenario, but what is the ISP after =20= in this setup? again, RO and HA reliability come to my mind... =20 something else that i am missing? Regards, marcelo > >> so, probably it makes sense to do all the work on reliability in the =20= >> same wg... > > I guess you haven't gone through the draft. > > Vijay > >> regards, marcelo >>> there has always been a lot of interest in global >>> HAHA in the NEMO WG whenever it has been presented. >>> that is why it still appears in the NEMO WG. >>> >>> Andy Huang wrote: >>> >>>> In fact, a WG draft has been designed by DT in MIP6 WG. >>>> https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability=20= >>>> -00.txt >>>> >>>> Do you think we need a especial HA reliability protocol for NEMO? >>> >>> if you take a look at the drafts, the messages >>> used by global HA would be the same as the ones >>> defined in draft-ietf-mip6-hareliability. the >>> current DT draft does not address geographically >>> distributed HAs. >>> >>> Vijay >>> > > From nemo-bounces@ietf.org Thu Sep 28 13:41:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSzsP-0001Ob-I0; Thu, 28 Sep 2006 13:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSzsO-0001Mi-1R for nemo@ietf.org; Thu, 28 Sep 2006 13:40:48 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSzsM-00023Q-LT for nemo@ietf.org; Thu, 28 Sep 2006 13:40:48 -0400 Received: from [10.1.201.0] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 10:38:59 -0700 Message-ID: <451C083C.4080405@azairenet.com> Date: Thu, 28 Sep 2006 10:37:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <50f59c75bf6f0543717ab855f5d79d81@it.uc3m.es> In-Reply-To: <50f59c75bf6f0543717ab855f5d79d81@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2006 17:38:59.0472 (UTC) FILETIME=[FAEBC100:01C6E324] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ml-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: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: > but why do you want to do this? > > the motivations that i can see for doing this is to achieve RO or HA > reliability, what else can be the motivations for this? > >> here is a realistic scenario. an operator in the >> US can have multiple home agents distributed >> geographically. they won't be all in the same >> room. you can allocate the home agents dynamically >> based on the MN/MR location. you can also >> dynamically switch HAs with global HAHA. > > yes, this seems indeed a reasonable scenario, but what is the ISP after > in this setup? again, RO and HA reliability come to my mind... something > else that i am missing? not have all home agents in one room, but still provide the same set of services from the same packet data network. current MIPv6/NEMO specs restrict the HAs to the same home link. can't be distributed geographically. Vijay > > Regards, marcelo > > >> >>> so, probably it makes sense to do all the work on reliability in the >>> same wg... >> >> I guess you haven't gone through the draft. >> >> Vijay >> >>> regards, marcelo >>>> there has always been a lot of interest in global >>>> HAHA in the NEMO WG whenever it has been presented. >>>> that is why it still appears in the NEMO WG. >>>> >>>> Andy Huang wrote: >>>> >>>>> In fact, a WG draft has been designed by DT in MIP6 WG. >>>>> https://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-00.txt >>>>> >>>>> >>>>> Do you think we need a especial HA reliability protocol for NEMO? >>>> >>>> if you take a look at the drafts, the messages >>>> used by global HA would be the same as the ones >>>> defined in draft-ietf-mip6-hareliability. the >>>> current DT draft does not address geographically >>>> distributed HAs. >>>> >>>> Vijay >>>> >> >> > From nemo-bounces@ietf.org Thu Sep 28 13:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT01S-0007ZI-6p; Thu, 28 Sep 2006 13:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT01Q-0007ZD-6Q for nemo@ietf.org; Thu, 28 Sep 2006 13:50:08 -0400 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT01O-0002fu-R9 for nemo@ietf.org; Thu, 28 Sep 2006 13:50:08 -0400 Received: from [10.1.201.0] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 10:48:20 -0700 Message-ID: <451C0A6F.1070306@azairenet.com> Date: Thu, 28 Sep 2006 10:46:23 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <1159329548.9531.34.camel@localhost> <40abea72677cff0a9680c44d09f50a2f@it.uc3m.es> In-Reply-To: <40abea72677cff0a9680c44d09f50a2f@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2006 17:48:20.0783 (UTC) FILETIME=[497D03F0:01C6E326] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ml-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: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: >> (4) If WG decides it's still too early (after all, we have been talking >> about RO for close to 5 years now) to add RO solutions into WG charter, >> a WG charter item should be added to document RO requirements from >> various industries. > > i agree with Chan-Wah in all the above points > > i would prefer 4 rather than 3, but... requirements are useful, yes. however, the problem is well known. there are two main scenarios 1. route optimization for the nodes in the mobile network 2. route optimization for traffic between the two MNNs in the same mobile network. (global HAHA is separate). we document the problem and figured out what scenarios need solutions. http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-03.txt there is also a document that does an excellent analysis of the solution space. http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-03.txt personally I believe it is time to standardize solutions that at least address the two main scenarios identified above. at the same time, yes lets collect the requirements from the industry and see if the solution we are standardizing does meet those requirements. hopefully the requirements gathering phase does not become a rat-hole. Vijay From nemo-bounces@ietf.org Thu Sep 28 21:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT76p-0000Yy-Qk; Thu, 28 Sep 2006 21:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT76o-0000Ys-Pz for nemo@ietf.org; Thu, 28 Sep 2006 21:24:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT76n-0006pR-IN for nemo@ietf.org; Thu, 28 Sep 2006 21:24:10 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2006 21:24:09 -0400 X-IronPort-AV: i="4.09,232,1157342400"; d="scan'208"; a="104939275:sNHT51811836" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8T1O8hV026033; Thu, 28 Sep 2006 21:24:09 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8T1O7g2017789; Fri, 29 Sep 2006 03:24:07 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 03:24:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 03:24:06 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02C47365@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: RO for geographically dist'd HAs Thread-Index: AcbhUiLHqUjNKpT+RfCfkzefaCtgpACEXgbA From: "Pascal Thubert \(pthubert\)" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 29 Sep 2006 01:24:07.0051 (UTC) FILETIME=[F5225DB0:01C6E365] DKIM-Signature: a=rsa-sha1; q=dns; l=1045; t=1159493049; x=1160357049; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Re=3A=20RO=20for=20geographically=20dist'd=20HAs |To:=22marcelo=20bagnulo=20braun=22=20; X=v=3Dcisco.com=3B=20h=3DVScjeePx18YYodV64AmDAp3legs=3D; b=dXQ53Wy2rL/sNTKmpnlDPFyg+Rvl6EndMe1MevOmaVAcEQdT/wO81uBHK9o1vRlK+L+YSwbU 6TXlvQuInvcC3GDQSIAFiqNwcw105qiuGO3ugVFOmkYbqmqg5BIKGBTv; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org >as i mention, these may be excelent design choices and the resulting >features may be what the wg needs. But what we need to understand at >this point is what is the goal of global HAHA, RO or HA reliability? > >If it is HA reliability, probably this work would need to be carried >out in the mip6 wg, where they are working on the HA reliability topic > >If it is RO, we should consider global HAHA as any other RO proposal, >and we need to analyze the whole RO problem together, so i don't see >any reason why include it in the charter as a separate item > > [Pascal] Hi Marcelo, Maybe being able to distribute the HA is a goal in itself, and the main reason for doing so on a global scale is a shorter path between the mobile nodes; so global HAHA is more of a RO thing than a high availability thing. In the partitioned deployment that we elaborate on, a site is primary for a range of prefixes, and thus the site should not die. If you want to duplicate a site, you need to sync the copies with local HAHA. Pascal From nemo-bounces@ietf.org Thu Sep 28 21:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT76r-0000bm-6I; Thu, 28 Sep 2006 21:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT76p-0000Yx-PK for nemo@ietf.org; Thu, 28 Sep 2006 21:24:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT76o-0006qA-Hn for nemo@ietf.org; Thu, 28 Sep 2006 21:24:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2006 21:24:10 -0400 X-IronPort-AV: i="4.09,232,1157342400"; d="scan'208"; a="104939276:sNHT53074836" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8T1O9kw017107; Thu, 28 Sep 2006 21:24:10 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8T1O9g2017794; Fri, 29 Sep 2006 03:24:09 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 03:24:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 03:24:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02C47366@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: RO for geographically dist'd HAs Thread-Index: AcbhVLQsrvNcLYKEQ7Si4+piXPAyEgCD+8Gw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 29 Sep 2006 01:24:08.0801 (UTC) FILETIME=[F62D6510:01C6E365] DKIM-Signature: a=rsa-sha1; q=dns; l=1156; t=1159493050; x=1160357050; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Re=3A=20RO=20for=20geographically=20dist'd=20HAs |To:=22Alexandru=20Petrescu=22=20; X=v=3Dcisco.com=3B=20h=3DVScjeePx18YYodV64AmDAp3legs=3D; b=OnyM4dAAEBPCZdbZtVZkJ73kMeSFqlgd5OE+JfhYYjSWSHc0oo1dp+FVvylgi6HHv16LVcXO WbahHfGKfzFs+2wQD1P+fgO5Uv7nedkYbLeVC8fJaYwqrl8q3lekRAxt; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: marcelo bagnulo braun , ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org and thus cut the cost of the MRHA path. >> >> On top of that, the concept of proxy Home Agent introduced in global >> HAHA is designed for infrastructure-based route optimization, as >> Chan-Wah points out. > >Ah, terminology... A "proxy HA"? Is a "proxy HA" run Proxy-MIP? [Pascal] Confusing isn't it? There's a chapter about it, to avoid confusion between the PMIP function in NETLMM and global HAHA's proxy. Those beasts are compatible and could be collocated but they play a different game. See: 4. A proxy for Mobile IP The draft references extensively a MIP proxy HA function. The word proxy, here, is taken in a classical sense, like, for instance, a web proxy: a MIP proxy Home Agent acts as a HA for the MN and as a MN for the HA, the CN, and other proxies. In particular, the MIP proxy terminates the MR-HA tunnel and the associated encryption, extracts the packets, and reencapsulates them to the destination. This differs from a proxy-MIP function, which performs the Mobile Node operation on behalf of a non MIP-enabled node, in order to manage its mobility transparently. Pascal From nemo-bounces@ietf.org Thu Sep 28 21:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT76p-0000Yy-Qk; Thu, 28 Sep 2006 21:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT76o-0000Ys-Pz for nemo@ietf.org; Thu, 28 Sep 2006 21:24:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT76n-0006pR-IN for nemo@ietf.org; Thu, 28 Sep 2006 21:24:10 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2006 21:24:09 -0400 X-IronPort-AV: i="4.09,232,1157342400"; d="scan'208"; a="104939275:sNHT51811836" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8T1O8hV026033; Thu, 28 Sep 2006 21:24:09 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8T1O7g2017789; Fri, 29 Sep 2006 03:24:07 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 03:24:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 03:24:06 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02C47365@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: RO for geographically dist'd HAs Thread-Index: AcbhUiLHqUjNKpT+RfCfkzefaCtgpACEXgbA From: "Pascal Thubert \(pthubert\)" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 29 Sep 2006 01:24:07.0051 (UTC) FILETIME=[F5225DB0:01C6E365] DKIM-Signature: a=rsa-sha1; q=dns; l=1045; t=1159493049; x=1160357049; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Re=3A=20RO=20for=20geographically=20dist'd=20HAs |To:=22marcelo=20bagnulo=20braun=22=20; X=v=3Dcisco.com=3B=20h=3DVScjeePx18YYodV64AmDAp3legs=3D; b=dXQ53Wy2rL/sNTKmpnlDPFyg+Rvl6EndMe1MevOmaVAcEQdT/wO81uBHK9o1vRlK+L+YSwbU 6TXlvQuInvcC3GDQSIAFiqNwcw105qiuGO3ugVFOmkYbqmqg5BIKGBTv; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org >as i mention, these may be excelent design choices and the resulting >features may be what the wg needs. But what we need to understand at >this point is what is the goal of global HAHA, RO or HA reliability? > >If it is HA reliability, probably this work would need to be carried >out in the mip6 wg, where they are working on the HA reliability topic > >If it is RO, we should consider global HAHA as any other RO proposal, >and we need to analyze the whole RO problem together, so i don't see >any reason why include it in the charter as a separate item > > [Pascal] Hi Marcelo, Maybe being able to distribute the HA is a goal in itself, and the main reason for doing so on a global scale is a shorter path between the mobile nodes; so global HAHA is more of a RO thing than a high availability thing. In the partitioned deployment that we elaborate on, a site is primary for a range of prefixes, and thus the site should not die. If you want to duplicate a site, you need to sync the copies with local HAHA. Pascal From nemo-bounces@ietf.org Thu Sep 28 21:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT76r-0000bm-6I; Thu, 28 Sep 2006 21:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT76p-0000Yx-PK for nemo@ietf.org; Thu, 28 Sep 2006 21:24:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT76o-0006qA-Hn for nemo@ietf.org; Thu, 28 Sep 2006 21:24:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2006 21:24:10 -0400 X-IronPort-AV: i="4.09,232,1157342400"; d="scan'208"; a="104939276:sNHT53074836" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8T1O9kw017107; Thu, 28 Sep 2006 21:24:10 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8T1O9g2017794; Fri, 29 Sep 2006 03:24:09 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 03:24:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 03:24:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02C47366@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: RO for geographically dist'd HAs Thread-Index: AcbhVLQsrvNcLYKEQ7Si4+piXPAyEgCD+8Gw From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 29 Sep 2006 01:24:08.0801 (UTC) FILETIME=[F62D6510:01C6E365] DKIM-Signature: a=rsa-sha1; q=dns; l=1156; t=1159493050; x=1160357050; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Re=3A=20RO=20for=20geographically=20dist'd=20HAs |To:=22Alexandru=20Petrescu=22=20; X=v=3Dcisco.com=3B=20h=3DVScjeePx18YYodV64AmDAp3legs=3D; b=OnyM4dAAEBPCZdbZtVZkJ73kMeSFqlgd5OE+JfhYYjSWSHc0oo1dp+FVvylgi6HHv16LVcXO WbahHfGKfzFs+2wQD1P+fgO5Uv7nedkYbLeVC8fJaYwqrl8q3lekRAxt; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: marcelo bagnulo braun , ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org and thus cut the cost of the MRHA path. >> >> On top of that, the concept of proxy Home Agent introduced in global >> HAHA is designed for infrastructure-based route optimization, as >> Chan-Wah points out. > >Ah, terminology... A "proxy HA"? Is a "proxy HA" run Proxy-MIP? [Pascal] Confusing isn't it? There's a chapter about it, to avoid confusion between the PMIP function in NETLMM and global HAHA's proxy. Those beasts are compatible and could be collocated but they play a different game. See: 4. A proxy for Mobile IP The draft references extensively a MIP proxy HA function. The word proxy, here, is taken in a classical sense, like, for instance, a web proxy: a MIP proxy Home Agent acts as a HA for the MN and as a MN for the HA, the CN, and other proxies. In particular, the MIP proxy terminates the MR-HA tunnel and the associated encryption, extracts the packets, and reencapsulates them to the destination. This differs from a proxy-MIP function, which performs the Mobile Node operation on behalf of a non MIP-enabled node, in order to manage its mobility transparently. Pascal From nemo-bounces@ietf.org Thu Sep 28 21:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT7HY-0006Z5-Lv; Thu, 28 Sep 2006 21:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT7HX-0006Yt-7d for nemo@ietf.org; Thu, 28 Sep 2006 21:35:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT7HU-00089b-W1 for nemo@ietf.org; Thu, 28 Sep 2006 21:35:15 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 Sep 2006 18:35:13 -0700 X-IronPort-AV: i="4.09,232,1157353200"; d="scan'208"; a="44060883:sNHT53105984" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8T1ZCO6020009; Thu, 28 Sep 2006 21:35:12 -0400 Received: from xbh-ams-331.emea.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 k8T1ZCg2019035; Fri, 29 Sep 2006 03:35:12 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 03:35:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 03:35:04 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02C4736B@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: RO for geographically dist'd HAs Thread-Index: Acbh6GseYquS1864TjKYpJiD0Vnw/QBfPg5Q From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah Ng" , "Vijay Devarapalli" X-OriginalArrivalTime: 29 Sep 2006 01:35:11.0411 (UTC) FILETIME=[811FA830:01C6E367] DKIM-Signature: a=rsa-sha1; q=dns; l=1279; t=1159493712; x=1160357712; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Re=3A=20RO=20for=20geographically=20dist'd=20HAs |To:=22Chan-Wah=20Ng=22=20, =0A=20=20=20=20=20=2 0=20=20=22Vijay=20Devarapalli=22=20; X=v=3Dcisco.com=3B=20h=3DVScjeePx18YYodV64AmDAp3legs=3D; b=LYJmF7A7fElIby0JDFL7Qf55VmSV2AeY/wiaTxxulejhLZF0EyW7CXW6n/iocMEvNne8fvGx apzW5/BwS5eSqzMVUlvIRS3qnsnFe6wUvGLll5+k4E6264+pMt06XBSx; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: marcelo bagnulo braun , ml-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: , Errors-To: nemo-bounces@ietf.org > >As a co-author, perhaps you want to point out where in the draft covers >NEMO-specific content? You use the term MN/MR, suggesting that it is >catered for mobile node (host+router) in general. > > [Pascal] Hi Chan-Wah: Please consider the text that follows 3. Rationale for the proposed solution For the time being, the precise flows are not elaborated. One idea is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly in the registration phase. Another is that HAs should be proactively preassigned to receive a given set of registration, in order to allow a certain degree of aggregation within sites and in between site. Finally, the concept of proxy is introduced to limit the number of primary sites (to 1?) and as a key element for an upcoming NEMO route optimization scheme, where routes can be exchanged in a trusted fashion between proxies. The NEMO problem for RO is to provide a NEMO version of the RR test so that the other party can trust that a prefix is over a RO'ed tunnel. Global HAHA introduces the route projection in a trusted manner because it does it in the infrastructure... If you consider the text itself, it mentions MRs throughout because it was thought for NEMO. Pascal From nemo-bounces@ietf.org Thu Sep 28 22:38:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT8G5-00037p-GV; Thu, 28 Sep 2006 22:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT8G3-00034E-3R for nemo@ietf.org; Thu, 28 Sep 2006 22:37:47 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT8G0-0000la-DR for nemo@ietf.org; Thu, 28 Sep 2006 22:37:47 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k8T2bWLc014816; Fri, 29 Sep 2006 11:37:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8T2bYC09844; Fri, 29 Sep 2006 11:37:34 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id k8T2bX528675; Fri, 29 Sep 2006 11:37:33 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 10:36:37 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id B84C6D4223; Fri, 29 Sep 2006 10:46:54 +0800 (SGT) Subject: Re: [nemo] Re: RO for geographically dist'd HAs From: Chan-Wah Ng To: Vijay Devarapalli In-Reply-To: <451C0A6F.1070306@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <1159329548.9531.34.camel@localhost> <40abea72677cff0a9680c44d09f50a2f@it.uc3m.es> <451C0A6F.1070306@azairenet.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 29 Sep 2006 10:46:54 +0800 Message-Id: <1159498014.9531.107.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 29 Sep 2006 02:36:37.0679 (UTC) FILETIME=[164F83F0:01C6E370] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: marcelo bagnulo braun , ml-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: , Errors-To: nemo-bounces@ietf.org On Thu, 2006-09-28 at 10:46 -0700, Vijay Devarapalli wrote: > marcelo bagnulo braun wrote: > > >> (4) If WG decides it's still too early (after all, we have been talking > >> about RO for close to 5 years now) to add RO solutions into WG charter, > >> a WG charter item should be added to document RO requirements from > >> various industries. > > > > i agree with Chan-Wah in all the above points > > > > i would prefer 4 rather than 3, but... > > requirements are useful, yes. however, the problem is well > known. there are two main scenarios 1. route optimization > for the nodes in the mobile network 2. route optimization > for traffic between the two MNNs in the same mobile network. > (global HAHA is separate). > I sort of agree with Vijay here, clearly the gathering of requirements is a step towards standardizing a solution. I would prefer 3 instead of 4, which is why I ordered them that way ;) > we document the problem and figured out what scenarios need > solutions. > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-03.txt > there is also a document that does an excellent analysis > of the solution space. > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-03.txt > > personally I believe it is time to standardize solutions > that at least address the two main scenarios identified > above. at the same time, yes lets collect the requirements > from the industry and see if the solution we are > standardizing does meet those requirements. hopefully the > requirements gathering phase does not become a rat-hole. > If indeed the various recent promises of drafts from different industries are true, then it may not be a rat-hole. If we are going to have requirements in the charter, I would further suggest that we have a strict deadline for this work item to complete (and this time, adhere to it for a change). I don't see why this couldn't be finished before Mar 2007, if the WG and the chairs put in adequate effort. If one think along this line, then what Vijay suggest on adding both requirements and RO solutions to the charter now make sense. Are we going to go through this rechartering business again in Mar 2007? Might as well add RO solutions to the charter right now. /rgds /cwng From nemo-bounces@ietf.org Thu Sep 28 22:57:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT8Z7-0005ip-MD; Thu, 28 Sep 2006 22:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT8Z6-0005ik-CT for nemo@ietf.org; Thu, 28 Sep 2006 22:57:28 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT8Z4-000502-NP for nemo@ietf.org; Thu, 28 Sep 2006 22:57:28 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k8T2vEMf017324; Fri, 29 Sep 2006 11:57:14 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k8T2vF927644; Fri, 29 Sep 2006 11:57:15 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id k8T2vD121746; Fri, 29 Sep 2006 11:57:13 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 10:56:18 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id C4B9CD4223; Fri, 29 Sep 2006 11:06:35 +0800 (SGT) Subject: RE: [nemo] Re: RO for geographically dist'd HAs From: Chan-Wah Ng To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC02C4736B@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC02C4736B@xmb-ams-337.emea.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 29 Sep 2006 11:06:35 +0800 Message-Id: <1159499195.9531.123.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-OriginalArrivalTime: 29 Sep 2006 02:56:18.0593 (UTC) FILETIME=[D630B110:01C6E372] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: marcelo bagnulo braun , ml-nemo WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello Pascal, On Fri, 2006-09-29 at 03:35 +0200, Pascal Thubert (pthubert) wrote: > > > >As a co-author, perhaps you want to point out where in the draft covers > >NEMO-specific content? You use the term MN/MR, suggesting that it is > >catered for mobile node (host+router) in general. > > > > > [Pascal] Hi Chan-Wah: > > Please consider the text that follows > > 3. Rationale for the proposed solution > > For the time being, the precise flows are not elaborated. One idea > is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly > in the registration phase. Another is that HAs should be proactively > preassigned to receive a given set of registration, in order to allow > a certain degree of aggregation within sites and in between site. > Finally, the concept of proxy is introduced to limit the number of > primary sites (to 1?) and as a key element for an upcoming NEMO route > optimization scheme, where routes can be exchanged in a trusted > fashion between proxies. > > > The NEMO problem for RO is to provide a NEMO version of the RR test so > that the other party can trust that a prefix is over a RO'ed tunnel. > Global HAHA introduces the route projection in a trusted manner because > it does it in the infrastructure... If you consider the text itself, it > mentions MRs throughout because it was thought for NEMO. > Yeah, right, and isn't that Route Optimization? If I understand the intention of global HAHA protocol correctly, it is to provide (a) HA reliability and (b) route optimization. So far nothing you or Vijay put forth had convinced me (a) is specific to or at least of more interest for NEMO rather than MIP6. To help you along, I myself had put forth a NEMO-specific scenario (HA in a NEMO), but it seems you guys are not even interested in it ;) I agree (b) is of interest to NEMO, but as I say, why should NEMO-WG add (only) this particular protocol to its charter? And why a candidate solution? Why is it not "Infrastructure-based RO"? And why only this form of RO? How about other forms of RO? I'd reiterated my stand on this a few times, and I say it again: I am all supportive of RO solutions being added to the WG charter, but it should not be a single candidate solution (like global HA HA). It should be a few different approaches of RO. /rgds /cwng From nemo-bounces@ietf.org Fri Sep 29 04:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDdx-000828-Gp; Fri, 29 Sep 2006 04:22:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDdv-00081j-IH for nemo@ietf.org; Fri, 29 Sep 2006 04:22:47 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTDdu-0004rw-2M for nemo@ietf.org; Fri, 29 Sep 2006 04:22:47 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EF67DE372F; Fri, 29 Sep 2006 10:22:42 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp01.uc3m.es (Postfix) with ESMTP id D03C5E368A; Fri, 29 Sep 2006 10:22:42 +0200 (CEST) In-Reply-To: <451C083C.4080405@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <50f59c75bf6f0543717ab855f5d79d81@it.uc3m.es> <451C083C.4080405@azairenet.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 10:23:35 +0200 To: Vijay Devarapalli X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ml-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: , Errors-To: nemo-bounces@ietf.org El 28/09/2006, a las 19:37, Vijay Devarapalli escribi=F3: > marcelo bagnulo braun wrote: > >> but why do you want to do this? >> the motivations that i can see for doing this is to achieve RO or HA =20= >> reliability, what else can be the motivations for this? >>> here is a realistic scenario. an operator in the >>> US can have multiple home agents distributed >>> geographically. they won't be all in the same >>> room. you can allocate the home agents dynamically >>> based on the MN/MR location. you can also >>> dynamically switch HAs with global HAHA. >> yes, this seems indeed a reasonable scenario, but what is the ISP =20 >> after in this setup? again, RO and HA reliability come to my mind... =20= >> something else that i am missing? > > not have all home agents in one room, exactly, and why do you want that for? usually, people ask for this in =20= order to achieve reliability or RO and other benefit you would obtain =20= from this setup? Regards, marcelo > but still provide > the same set of services from the same packet data > network. current MIPv6/NEMO specs restrict the HAs to > the same home link. can't be distributed geographically. > > Vijay > > >> Regards, marcelo >>> >>>> so, probably it makes sense to do all the work on reliability in =20= >>>> the same wg... >>> >>> I guess you haven't gone through the draft. >>> >>> Vijay >>> >>>> regards, marcelo >>>>> there has always been a lot of interest in global >>>>> HAHA in the NEMO WG whenever it has been presented. >>>>> that is why it still appears in the NEMO WG. >>>>> >>>>> Andy Huang wrote: >>>>> >>>>>> In fact, a WG draft has been designed by DT in MIP6 WG. >>>>>> https://www.ietf.org/internet-drafts/draft-ietf-mip6-=20 >>>>>> hareliability-00.txt >>>>>> >>>>>> Do you think we need a especial HA reliability protocol for NEMO? >>>>> >>>>> if you take a look at the drafts, the messages >>>>> used by global HA would be the same as the ones >>>>> defined in draft-ietf-mip6-hareliability. the >>>>> current DT draft does not address geographically >>>>> distributed HAs. >>>>> >>>>> Vijay >>>>> >>> >>> > From nemo-bounces@ietf.org Fri Sep 29 04:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDn1-0003nd-Uo; Fri, 29 Sep 2006 04:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDmz-0003nN-Pj for nemo@ietf.org; Fri, 29 Sep 2006 04:32:09 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTDmy-0005iR-7r for nemo@ietf.org; Fri, 29 Sep 2006 04:32:09 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CAB93E3905; Fri, 29 Sep 2006 10:32:01 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp01.uc3m.es (Postfix) with ESMTP id C9004E36B0; Fri, 29 Sep 2006 10:32:00 +0200 (CEST) In-Reply-To: <451C0A6F.1070306@azairenet.com> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <1159329548.9531.34.camel@localhost> <40abea72677cff0a9680c44d09f50a2f@it.uc3m.es> <451C0A6F.1070306@azairenet.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <70941be08c35e31c937dd86b7ea3201e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 10:32:53 +0200 To: Vijay Devarapalli X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ml-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: , Errors-To: nemo-bounces@ietf.org El 28/09/2006, a las 19:46, Vijay Devarapalli escribi=F3: > marcelo bagnulo braun wrote: > >>> (4) If WG decides it's still too early (after all, we have been =20 >>> talking >>> about RO for close to 5 years now) to add RO solutions into WG =20 >>> charter, >>> a WG charter item should be added to document RO requirements from >>> various industries. >> i agree with Chan-Wah in all the above points >> i would prefer 4 rather than 3, but... > > requirements are useful, yes. however, the problem is well > known. there are two main scenarios 1. route optimization > for the nodes in the mobile network you mean RO between a MNN and an external node? I agree this is a problem and it is well defined. The problem that i find here, if we don't provide additional =20 requirements, it will be extremely hard to select among the over a =20 dozen proposed solutions for this. that is why i think that defining =20 the use cases before is needed. Use cases impose requirmeents that =20 allow us to select among the different solution with a somehow =20 objective criteria how do you choose between a solution that makes RO based in the =20 infrastructure and an end to end RO solution? does the MR needs to do =20= alll the work or is it ok to allow the MNN to be involved? Each of =20 these different approaches provide benefits and drawbacks, and these =20 are more or less critical depending in the application scenario that =20 you have in mind. My concern is that if we just state in the cahrter =20 that we will standarize a solution to provide RO between the MNN and =20 the nodes on the internet, we won't have reasonable objective criteria =20= to select one of the dozens proposed approaches ( and i guess we don't =20= want to stadnarize them all) Does any agree that this may be a problem or do you have any mechanisms =20= to select among the proposed cirteria other than cherry picking? > 2. route optimization > for traffic between the two MNNs in the same mobile network. > (global HAHA is separate). this otoh, seems to me a more defined problem and maybe it is easier to =20= tackle, so we could go directly to it... > > we document the problem and figured out what scenarios need > solutions. > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-=20 > statement-03.txt > there is also a document that does an excellent analysis > of the solution space. > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis=20= > -03.txt > > personally I believe it is time to standardize solutions > that at least address the two main scenarios identified > above. at the same time, yes lets collect the requirements > from the industry and see if the solution we are > standardizing does meet those requirements. what if they don't? > hopefully the > requirements gathering phase does not become a rat-hole. > yes i am afraid of that too regards, marcelo > Vijay > From nemo-bounces@ietf.org Fri Sep 29 04:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDns-00046n-PQ; Fri, 29 Sep 2006 04:33:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDns-00046W-6v for nemo@ietf.org; Fri, 29 Sep 2006 04:33:04 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTDnq-0005kz-SH for nemo@ietf.org; Fri, 29 Sep 2006 04:33:04 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4E314E3969; Fri, 29 Sep 2006 10:33:02 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp01.uc3m.es (Postfix) with ESMTP id 12F1FE34D9; Fri, 29 Sep 2006 10:33:02 +0200 (CEST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC02C47365@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC02C47365@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <277128c19f090c4fbc99e6c5ef11c1a5@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 10:33:54 +0200 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org El 29/09/2006, a las 3:24, Pascal Thubert (pthubert) escribi=F3: >> as i mention, these may be excelent design choices and the resulting >> features may be what the wg needs. But what we need to understand at >> this point is what is the goal of global HAHA, RO or HA reliability? >> >> If it is HA reliability, probably this work would need to be carried >> out in the mip6 wg, where they are working on the HA reliability = topic >> >> If it is RO, we should consider global HAHA as any other RO proposal, >> and we need to analyze the whole RO problem together, so i don't see >> any reason why include it in the charter as a separate item >> >> > [Pascal] Hi Marcelo, > > Maybe being able to distribute the HA is a goal in itself, and the = main > reason for doing so on a global scale is a shorter path between the > mobile nodes; so global HAHA is more of a RO thing than a high > availability thing. so we do agree that the reasons for global haha are reliability and RO,=20= right? Regards, marcelo > In the partitioned deployment that we elaborate on, > a site is primary for a range of prefixes, and thus the site should = not > die. If you want to duplicate a site, you need to sync the copies with > local HAHA. > > Pascal > From nemo-bounces@ietf.org Fri Sep 29 04:39:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDtt-0006sM-A7; Fri, 29 Sep 2006 04:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDtr-0006r7-PM for nemo@ietf.org; Fri, 29 Sep 2006 04:39:15 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTDtq-0006AC-FG for nemo@ietf.org; Fri, 29 Sep 2006 04:39:15 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A88F1E3485; Fri, 29 Sep 2006 10:39:10 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp01.uc3m.es (Postfix) with ESMTP id 852C9E3A55; Fri, 29 Sep 2006 10:39:08 +0200 (CEST) In-Reply-To: <1159498014.9531.107.camel@localhost> References: <4513AE33.1090506@motorola.com> <4517EBAE.1020303@azairenet.com> <1159237195.982.305.camel@localhost> <016001c6e11a$e624f9a0$1d2ea40a@china.huawei.com> <4518C1CD.9050502@azairenet.com> <451961C5.2050905@azairenet.com> <1159329548.9531.34.camel@localhost> <40abea72677cff0a9680c44d09f50a2f@it.uc3m.es> <451C0A6F.1070306@azairenet.com> <1159498014.9531.107.camel@localhost> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <52ef6eb8038d2e0401c2d515e8a0e2ef@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 10:40:00 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ml-nemo WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 29/09/2006, a las 4:46, Chan-Wah Ng escribi=F3: > > If indeed the various recent promises of drafts from different > industries are true, then it may not be a rat-hole. > > If we are going to have requirements in the charter, I would further > suggest that we have a strict deadline for this work item to complete > (and this time, adhere to it for a change). I don't see why this > couldn't be finished before Mar 2007, if the WG and the chairs put in > adequate effort. > > If one think along this line, then what Vijay suggest on adding both > requirements and RO solutions to the charter now make sense. Are we > going to go through this rechartering business again in Mar 2007? =20 > Might > as well add RO solutions to the charter right now. > again agree with Chan-Wah here. i don't have a problem with including both the use cases/requirements=20 definitions and the solutions in the charter regards, marcelo > /rgds > /cwng > From nemo-bounces@ietf.org Fri Sep 29 04:40:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDvH-0007wk-So; Fri, 29 Sep 2006 04:40:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDvH-0007wf-6N for nemo@ietf.org; Fri, 29 Sep 2006 04:40:43 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTDvF-0006Fu-Sd for nemo@ietf.org; Fri, 29 Sep 2006 04:40:43 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 53174E3A6C; Fri, 29 Sep 2006 10:40:41 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp01.uc3m.es (Postfix) with ESMTP id 2A90EE3A63; Fri, 29 Sep 2006 10:40:41 +0200 (CEST) In-Reply-To: <1159499195.9531.123.camel@localhost> References: <7892795E1A87F04CADFCCF41FADD00FC02C4736B@xmb-ams-337.emea.cisco.com> <1159499195.9531.123.camel@localhost> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6581df334c5f1f4f3a27283cc85a7c68@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 10:41:33 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ml-nemo WG , "Pascal Thubert \(pthubert\)" , 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: , Errors-To: nemo-bounces@ietf.org El 29/09/2006, a las 5:06, Chan-Wah Ng escribi=F3: > > Yeah, right, and isn't that Route Optimization? If I understand the > intention of global HAHA protocol correctly, it is to provide (a) HA > reliability and (b) route optimization. > > So far nothing you or Vijay put forth had convinced me (a) is specific > to or at least of more interest for NEMO rather than MIP6. To help = you > along, I myself had put forth a NEMO-specific scenario (HA in a NEMO), > but it seems you guys are not even interested in it ;) > > I agree (b) is of interest to NEMO, but as I say, why should NEMO-WG=20= > add > (only) this particular protocol to its charter? And why a candidate > solution? Why is it not "Infrastructure-based RO"? And why only this > form of RO? How about other forms of RO? I'd reiterated my stand on > this a few times, and I say it again: I am all supportive of RO > solutions being added to the WG charter, but it should not be a single > candidate solution (like global HA HA). It should be a few different > approaches of RO. > again i fully agree with Chan-Wah here Regards, marcelo > /rgds > /cwng > > > > > > From nemo-bounces@ietf.org Fri Sep 29 07:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTGNV-0005qO-Nx; Fri, 29 Sep 2006 07:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTGNT-0005qI-RL for nemo@ietf.org; Fri, 29 Sep 2006 07:17:59 -0400 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTGNM-0000Ci-Gf for nemo@ietf.org; Fri, 29 Sep 2006 07:17:59 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 530BBEC8A1; Fri, 29 Sep 2006 20:17:19 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 784FAEC843; Fri, 29 Sep 2006 20:17:18 +0900 (JST) Received: from [127.0.0.1] (watari-desktop.ddns.hsc.kddilabs.jp [172.19.72.153]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 637F52E04A; Fri, 29 Sep 2006 20:12:28 +0900 (JST) Date: Fri, 29 Sep 2006 20:16:13 +0900 From: Masafumi Watari To: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Organization: KDDI R&D Laboratories Inc. In-Reply-To: <70941be08c35e31c937dd86b7ea3201e@it.uc3m.es> References: <451C0A6F.1070306@azairenet.com> <70941be08c35e31c937dd86b7ea3201e@it.uc3m.es> Message-Id: <20060929194841.6730.WATARI@kddilabs.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org On Fri, 29 Sep 2006 10:32:53 +0200 marcelo bagnulo braun wrote: > > El 28/09/2006, a las 19:46, Vijay Devarapalli escribi$B".(B > > > marcelo bagnulo braun wrote: > > > >>> (4) If WG decides it's still too early (after all, we have been > >>> talking > >>> about RO for close to 5 years now) to add RO solutions into WG > >>> charter, > >>> a WG charter item should be added to document RO requirements from > >>> various industries. > >> i agree with Chan-Wah in all the above points > >> i would prefer 4 rather than 3, but... > > > > requirements are useful, yes. however, the problem is well > > known. there are two main scenarios 1. route optimization > > for the nodes in the mobile network > > you mean RO between a MNN and an external node? > > I agree this is a problem and it is well defined. > The problem that i find here, if we don't provide additional > requirements, it will be extremely hard to select among the over a > dozen proposed solutions for this. that is why i think that defining > the use cases before is needed. Use cases impose requirmeents that > allow us to select among the different solution with a somehow > objective criteria > how do you choose between a solution that makes RO based in the > infrastructure and an end to end RO solution? does the MR needs to do > alll the work or is it ok to allow the MNN to be involved? Each of > these different approaches provide benefits and drawbacks, and these > are more or less critical depending in the application scenario that > you have in mind. My concern is that if we just state in the cahrter > that we will standarize a solution to provide RO between the MNN and > the nodes on the internet, we won't have reasonable objective criteria > to select one of the dozens proposed approaches ( and i guess we don't > want to stadnarize them all) > > Does any agree that this may be a problem or do you have any mechanisms > to select among the proposed cirteria other than cherry picking? If we consider the solution as more like an enhancement to NEMO BS, then we would probably want to leave those MNNs untouched - RO would be to bypass those HAs and make it MR to MR (Vehicle to vehicle, plane to plane). Now, if we start thinking about nesting of mobility protocols, obviously there would be a lot more thinking to do. My personal opinion however is that we should work on the nested case after we understand its needs. Having said that, I tend to agree with Vijay. > > 2. route optimization > > for traffic between the two MNNs in the same mobile network. > > (global HAHA is separate). > > this otoh, seems to me a more defined problem and maybe it is easier to > tackle, so we could go directly to it... I'm not sure about that - to me this involves a lot more complexity. But I do agree that these two are the cases we should look into. watari > > > > we document the problem and figured out what scenarios need > > solutions. > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem- > > statement-03.txt > > there is also a document that does an excellent analysis > > of the solution space. > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis > > -03.txt > > > > personally I believe it is time to standardize solutions > > that at least address the two main scenarios identified > > above. at the same time, yes lets collect the requirements > > from the industry and see if the solution we are > > standardizing does meet those requirements. > > what if they don't? > > > hopefully the > > requirements gathering phase does not become a rat-hole. > > > > yes i am afraid of that too > > regards, marcelo > > > > Vijay > > > From nemo-bounces@ietf.org Fri Sep 29 09:31:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIRl-0001VG-5p; Fri, 29 Sep 2006 09:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIRj-0001Tc-Q1 for nemo@ietf.org; Fri, 29 Sep 2006 09:30:31 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTIRi-0004wl-9Q for nemo@ietf.org; Fri, 29 Sep 2006 09:30:31 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 49D78E392D; Fri, 29 Sep 2006 15:30:27 +0200 (CEST) Received: from [163.117.139.53] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.53]) by smtp01.uc3m.es (Postfix) with ESMTP id F2A24E3962; Fri, 29 Sep 2006 15:30:24 +0200 (CEST) In-Reply-To: <20060929194841.6730.WATARI@kddilabs.jp> References: <451C0A6F.1070306@azairenet.com> <70941be08c35e31c937dd86b7ea3201e@it.uc3m.es> <20060929194841.6730.WATARI@kddilabs.jp> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 15:31:16 +0200 To: Masafumi Watari X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org El 29/09/2006, a las 13:16, Masafumi Watari escribi=F3: > > If we consider the solution as more like an enhancement to NEMO BS,=20 > then > we would probably want to leave those MNNs untouched - RO would be to > bypass those HAs and make it MR to MR (Vehicle to vehicle, plane to > plane). > two comments: - first, i agree that MR to MR (or MNN and MNN of different nemos) RO=20 makes sense, but don't you think that RO between MNN and a fixed node=20 in the internet is also required? and what about MNN and a mobile Node=20= RO, does is this required? -second, of course not having to modify the MNN is useful, specially in=20= terms of deployment. But these type of solutions have their own=20 drawbacks also (no solution has all the pros, i guess) so deciding that=20= we will keep the MNN unmodified fits some unstated requirements and=20 probably fits some unstated requirements. Again, this may be exactly=20 what we are looking for, but it is extremely hard imho to be able to=20 evaluate the different solutions and the different tradeoffs until the=20= exact requirements for the use case that we have in mind have been=20 written down. For instance, a solution that does requires modification=20= to the MNN but provides RO between the MNN and the fixed nodes of the=20 internet, without requiring modifications to the fixed nodes (which are=20= of course much more than the MNN) is better or worse than the a=20 solution that does not requires modification of the MNN but does not=20 provides RO with the fixed nodes? again it depends on the use cases=20 that you have in mind and the requirements of these use cases, i=20 guess... or do you have any other criteria to select among different=20 approaches? > Now, if we start thinking about nesting of mobility protocols,=20 > obviously > there would be a lot more thinking to do. My personal opinion however > is that we should work on the nested case after we understand its=20 > needs. > i am fine with this too i have thought less in this case than in the previous one, so i am=20 probably underestiamting its difficulty. I am perfectly okey to work in=20= requirements and use cases or whatever it takes to understand this case=20= in more depth and include this work in the charter Regards, marcelo > Having said that, I tend to agree with Vijay. > >>> 2. route optimization >>> for traffic between the two MNNs in the same mobile network. >>> (global HAHA is separate). >> >> this otoh, seems to me a more defined problem and maybe it is easier=20= >> to >> tackle, so we could go directly to it... > > I'm not sure about that - to me this involves a lot more complexity. > But I do agree that these two are the cases we should look into. > > watari > >>> >>> we document the problem and figured out what scenarios need >>> solutions. >>> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem- >>> statement-03.txt >>> there is also a document that does an excellent analysis >>> of the solution space. >>> = http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis >>> -03.txt >>> >>> personally I believe it is time to standardize solutions >>> that at least address the two main scenarios identified >>> above. at the same time, yes lets collect the requirements >>> from the industry and see if the solution we are >>> standardizing does meet those requirements. >> >> what if they don't? >> >>> hopefully the >>> requirements gathering phase does not become a rat-hole. >>> >> >> yes i am afraid of that too >> >> regards, marcelo >> >> >>> Vijay >>> >> > > > > From nemo-bounces@ietf.org Fri Sep 29 10:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJgn-0007RM-6v; Fri, 29 Sep 2006 10:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJgg-0007Il-MS; Fri, 29 Sep 2006 10:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTJgg-00077P-EK; Fri, 29 Sep 2006 10:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6589E26E42; Fri, 29 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GTJgg-0000ah-9h; Fri, 29 Sep 2006 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 29 Sep 2006 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-02.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, P. Thubert Filename : draft-ietf-nemo-dhcpv6-pd-02.txt Pages : 11 Date : 2006-9-29 One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-dhcpv6-pd-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-29042047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-dhcpv6-pd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-29042047.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Fri Sep 29 17:28:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPtM-00078g-3L; Fri, 29 Sep 2006 17:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPtK-00076F-6b for nemo@ietf.org; Fri, 29 Sep 2006 17:27:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTPtI-0007Qy-V1 for nemo@ietf.org; Fri, 29 Sep 2006 17:27:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Sep 2006 17:27:29 -0400 X-IronPort-AV: i="4.09,238,1157342400"; d="scan'208"; a="105071965:sNHT51575428" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TLRSjC002901; Fri, 29 Sep 2006 17:27:28 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TLRQg2002844; Fri, 29 Sep 2006 23:27:26 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 23:27:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: RO for geographically dist'd HAs Date: Fri, 29 Sep 2006 23:27:18 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02C47716@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: RO for geographically dist'd HAs Thread-Index: AcbjoedbYfO0rf7WS824dGv1Xvh4qAAazwHw From: "Pascal Thubert \(pthubert\)" To: "marcelo bagnulo braun" , "Chan-Wah Ng" X-OriginalArrivalTime: 29 Sep 2006 21:27:26.0421 (UTC) FILETIME=[0F4FF050:01C6E40E] DKIM-Signature: a=rsa-sha1; q=dns; l=822; t=1159565248; x=1160429248; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Re=3A=20RO=20for=20geographically=20dist'd=20HAs |To:=22marcelo=20bagnulo=20braun=22=20, =0A=20=20=20=20=2 0=20=20=20=22Chan-Wah=20Ng=22=20; X=v=3Dcisco.com=3B=20h=3DVScjeePx18YYodV64AmDAp3legs=3D; b=VPXy3tSs6Xt7NenLxBAmeiiMFKw2kmpIGV14QW9P1CzVkG4Toi7GrxRFsHqnySodUpao1lHO aZB06RBo6rEbTDCrDy33C8iAOejhsHU0RHd5If22CBGhVFV3C3TRioNU; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ml-nemo WG , Vijay Devarapalli , 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: , Errors-To: nemo-bounces@ietf.org >>> >> [Pascal] Hi Marcelo, >> >> Maybe being able to distribute the HA is a goal in itself, and the main >> reason for doing so on a global scale is a shorter path between the >> mobile nodes; so global HAHA is more of a RO thing than a high >> availability thing. > >so we do agree that the reasons for global haha are reliability and RO, >right? > [Pascal] In my mind, as Chan-Wah points out, the focus for global HAHA is an infrastructure-based RO rather than the availability. Global HAHA does not describe how you handle site duplication since early in the draft, the assumption is to partition the Aggregation into sites. To get a site level Home Agent High Availability you need to duplicate a site but the method would still be as described in local HAHA, but over a longer distance. Pascal From nemo-bounces@ietf.org Fri Sep 29 18:54:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRFB-0006AX-IX; Fri, 29 Sep 2006 18:54:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRF9-0006A9-Th for nemo@ietf.org; Fri, 29 Sep 2006 18:54:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTRF6-0004x5-U5 for nemo@ietf.org; Fri, 29 Sep 2006 18:54:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Sep 2006 18:54:05 -0400 X-IronPort-AV: i="4.09,238,1157342400"; d="scan'208"; a="105077754:sNHT57464308" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TMs4ar029311 for ; Fri, 29 Sep 2006 18:54:04 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TMs4g2014174 for ; Sat, 30 Sep 2006 00:54:04 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Sep 2006 00:54:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Sep 2006 00:52:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02C47725@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posting of draft-thubert-nemo-reverse-routing-header-06.txt Thread-Index: Acbj1pTT8ZrqTkfOQM+veA50OkB9XAAQwt+Q From: "Pascal Thubert \(pthubert\)" To: "ml-nemo WG" X-OriginalArrivalTime: 29 Sep 2006 22:54:03.0889 (UTC) FILETIME=[293E9E10:01C6E41A] DKIM-Signature: a=rsa-sha1; q=dns; l=889; t=1159570444; x=1160434444; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:Posting=20of=20draft-thubert-nemo-reverse-routing-header-06.txt=20 |To:=22ml-nemo=20WG=22=20; X=v=3Dcisco.com=3B=20h=3DA0F4zefuIXXybYvMfF2pWYc6ebU=3D; b=oDbrNEZMjnKzS/t56dqIrM4mRJiJ/gFpgrMm3xb90z5iyOqnyMviJmb6GKmtV+c8nqWrgbHq fWQ7rNvERjZWb3CmWhVnT0JKdDvrQqZCqDWRpusSJ21Qk31H61x/5TLW; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [nemo] Posting of draft-thubert-nemo-reverse-routing-header-06.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: , Errors-To: nemo-bounces@ietf.org Hi Reverse Routing Header is a Loose Source Record Route technique for nested NEMO RO. I refreshed it a bit since nested NEMO RO might become a relevant subject for the WG. Pascal -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat-reply@ietf.org]=20 Sent: Friday, September 29, 2006 7:50 AM To: Pascal Thubert (pthubert) Cc: Marco Molteni (mmolteni) Subject: Posting of draft-thubert-nemo-reverse-routing-header-06.txt=20 As you requested, draft-thubert-nemo-reverse-routing-header-06.txt, an updated version of an expired Internet-Drafts, has been posted. The draft will expire on April 2, 2007 unless it is replaced by an updated version, or the Secretariat has been notified that the document is under official review by the IESG or has been passed to the RFC Editor for review and/or publication as an RFC. The IETF Secretariat. From nemo-bounces@ietf.org Fri Sep 29 18:54:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRFB-0006AQ-AV; Fri, 29 Sep 2006 18:54:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRF9-0006A8-Th for nemo@ietf.org; Fri, 29 Sep 2006 18:54:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTRF6-0004wx-L0 for nemo@ietf.org; Fri, 29 Sep 2006 18:54:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2006 15:54:04 -0700 X-IronPort-AV: i="4.09,238,1157353200"; d="scan'208"; a="44197913:sNHT56018624" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TMs3lF006443 for ; Fri, 29 Sep 2006 18:54:04 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TMs3g2014171 for ; Sat, 30 Sep 2006 00:54:03 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Sep 2006 00:54:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Sep 2006 00:53:59 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02C47724@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posting of draft-thubert-nemo-global-haha-02.txt Thread-Index: Acbj1pmKX/QNkEm0SPmAwh3tMAkm0AAQu9MQ From: "Pascal Thubert \(pthubert\)" To: "ml-nemo WG" X-OriginalArrivalTime: 29 Sep 2006 22:54:03.0373 (UTC) FILETIME=[28EFE1D0:01C6E41A] DKIM-Signature: a=rsa-sha1; q=dns; l=821; t=1159570444; x=1160434444; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:Posting=20of=20draft-thubert-nemo-global-haha-02.txt=20 |To:=22ml-nemo=20WG=22=20; X=v=3Dcisco.com=3B=20h=3DZybohHyB+CArO9XQIB+Laz1vqjM=3D; b=f2Q/iWPwNWOVVl6Kc7lzKMKlMRDyXbl5Sy8REJvN/oRdrZFVjYQrqTmwXciGF9VGEijsDxjP G8GET41L8mdVC7jkrvMpfE7J/wc28e3B5hzwrKL0RU1Kl/YfH+d9aYB3; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [nemo] Posting of draft-thubert-nemo-global-haha-02.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi The update of global HAHA is now available. There's little change from 01, mostly fixes about the scale of the DFZ impacts, thanks to Marcelo's comments. Pascal -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat-reply@ietf.org]=20 Sent: Friday, September 29, 2006 7:50 AM To: Pascal Thubert (pthubert) Subject: Posting of draft-thubert-nemo-global-haha-02.txt=20 As you requested, draft-thubert-nemo-global-haha-02.txt, an updated version of an expired Internet-Drafts, has been posted. The draft will expire on April 2, 2007 unless it is replaced by an updated version, or the Secretariat has been notified that the document is under official review by the IESG or has been passed to the RFC Editor for review and/or publication as an RFC. The IETF Secretariat. From nemo-bounces@ietf.org Sat Sep 30 04:16:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa0u-0006tL-2s; Sat, 30 Sep 2006 04:16:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa0t-0006sg-6b for nemo@ietf.org; Sat, 30 Sep 2006 04:15:59 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTa0r-0006dY-Or for nemo@ietf.org; Sat, 30 Sep 2006 04:15:59 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A5DDCE3470; Sat, 30 Sep 2006 10:15:56 +0200 (CEST) Received: from [163.117.203.192] (unknown [163.117.203.192]) by smtp01.uc3m.es (Postfix) with ESMTP id 69426E3681; Sat, 30 Sep 2006 10:15:54 +0200 (CEST) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC02C47716@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC02C47716@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4924130b36db71e4b154e5fc078ddc82@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Re: RO for geographically dist'd HAs Date: Sat, 30 Sep 2006 10:14:38 +0200 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ml-nemo WG , Chan-Wah Ng , 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: , Errors-To: nemo-bounces@ietf.org El 29/09/2006, a las 23:27, Pascal Thubert (pthubert) escribi=F3: >>>> >>> [Pascal] Hi Marcelo, >>> >>> Maybe being able to distribute the HA is a goal in itself, and the > main >>> reason for doing so on a global scale is a shorter path between the >>> mobile nodes; so global HAHA is more of a RO thing than a high >>> availability thing. >> >> so we do agree that the reasons for global haha are reliability and=20= >> RO, >> right? >> > [Pascal] In my mind, as Chan-Wah points out, the focus for global HAHA > is an infrastructure-based RO rather than the availability. Global = HAHA > does not describe how you handle site duplication since early in the > draft, the assumption is to partition the Aggregation into sites. To=20= > get > a site level Home Agent High Availability you need to duplicate a site > but the method would still be as described in local HAHA, but over a > longer distance. > good now, relating this to the charter, i don't see why global HAHA should=20 be included as an explicit charter item and not any of the other RO=20 solutions I guess we should work on RO solutions in general and not pick any=20 specific solution in the charter. rahter than that we should define=20 particular problems about RO that we want to solve Regards, marcelo > Pascal >